简介这是一份以网站日志分析为背景的大数据离线处理综合案例文档适合正在学习Hadoop生态或准备大数据实战项目的读者。内容围绕某技术论坛的Apache日志展开完整覆盖项目介绍、日志数据格式、关键KPI定义与计算方式以及开发全流程从日志上传HDFS、MapReduce数据清洗、Hive统计分析到Sqoop导出结果至MySQL并设计了MySQL指标表和HBase明细表的存储结构。文档还详细说明了PV、注册用户数、独立IP数、跳出率、板块热度排行榜等核心指标的业务含义与统计口径能帮助读者建立离线日志分析项目的整体思路。资源为单个docx文档体积约1013KB结构清晰便于按章节阅读和复盘。已有1402人学习/下载适合大数据初学者、竞赛备赛者及需要完成类似实训项目的人员参考。1. 网站日志分析这个大数据综合案例到底在解决什么问题我接过不少应急工单最常见的一种是半夜磁盘告警登上服务器一看全是 Nginx 访问日志把 /tmp 和 /data 塞满了。更尴尬的是业务方第二天来问“昨天首页 UV 是多少”你只能临时写个脚本一台一台机器去 grep跑完再手工拼结果。网站日志分析这个大数据综合案例做的就是把这堆散落在几十台服务器上的访问日志统一收进一个地方清洗成能直接算指标的结构化数据再产出 PV、UV、来源渠道、热门页面这类业务报表。它的价值不在“用了哪些组件”而在把一条从采集到展示的完整链路打通让任何时候的“昨天发生了什么”都能在几分钟内回答。这个案例适合谁去落地如果你的环境里已经有几台虚拟机或一套测试集群恰好线上又有 Nginx 日志这个现成数据源练手成本就很低。你不需要等待业务部门配合日志天天在产生把链路搭好就能看到数据流起来。下面我按我自己的实施顺序来讲先讲链路选型再逐个环节落地最后把最容易翻车的几个地方单独拎出来说。2. 链路整体设计与组件选型先定大局再动手网站日志分析并不需要上来就把 HBase、ClickHouse、Flink 全部堆上。按我经手的项目经验一个能稳定跑、也能讲清楚原理的最小闭环是Nginx 日志 → Flume 采集 → Kafka 缓冲 → HDFS 存储 → Hive 建仓 → Spark 离线计算 → MySQL 结果表 → 报表展示。这条链路里每一个环节都有明确的职责换掉任何一个组件都要有充分理由。2.1 为什么采集端用 Flume而不是直接把日志打进 Elasticsearch很多人一上来就用 Filebeat 或 Logstash 把日志送到 Elasticsearch然后 Kibana 上看看图表这对小规模排查确实够用。但把它当成“大数据案例”来跑问题会出现在两方面一是缺少独立的缓冲层Elasticsearch 一旦写入变慢或集群抖动采集端就会直接反压日志开始积压在本地文件里恢复后追数据非常麻烦二是原始日志没有落地到数据仓库后续要做 7 天、30 天维度的趋势分析时ES 里的数据成本和查询性能都不划算。Flume 的 Taildir Source 在这里有不可替代的优势它按文件位置记录读取偏移量写到本地 JSON 文件里Agent 重启后能接着上次的位置继续读不会重复也不会漏。这一点对 Nginx 这种按天滚动、还会被 logrotate 改名的情况非常关键。Flume 自身不重不轻配置简单适合做“文件 → 缓冲层”这件事。如果你现场已经部署了 Logstash也不是不能用但要在 Logstash 端做好死信队列防止 ES 抖动时丢数据成本其实比多部署一个 Flume 高。2.2 Kafka 在链路里到底承担了什么能不能省掉直接回答不能省。Kafka 在这里起的是削峰填谷和事故隔离的作用。日志量是突发的比如早上 10 点和凌晨 3 点差了十倍而下游 HDFS 的写入能力相对稳定如果采集端直接写 HDFS高峰期必然出现延迟。数据先进 Kafka消费端按自己的节奏往下游写两端速度就解耦了。还有一个容易被忽略的价值重放。下游清洗作业如果出了 bug只要 Kafka 里的数据还没过期可以重置消费位点重新消费这在排查问题时相当于后悔药。Topic 分区数设计上我一般按下游消费者并行度来定。如果下游用一组 Flume 消费写 HDFS消费者线程数通常不会太多Topic 设置 12 到 24 个分区已经足够。分区数不是越大越好太多分区会让 Kafka 的元数据和文件句柄压力上升小集群反而得不偿失。副本数至少设 2条件允许就设 3。这里不要为了省磁盘把副本设成 1日志数据虽然可以重新生成但重建链路的时间成本远超那点磁盘费用。2.3 存储与仓库层为什么是 HDFS 加 Hive而不是直接上数据库有一部分人喜欢把清洗后的数据直接写 MySQL 或 PostgreSQL然后报表工具直接查。放到百万级 UV 的场景下这个方案很快就会撞墙——明细数据量太大关系型数据库的统计查询性能扛不住而且存储成本也比 HDFS 高一个数量级。HDFS 加 Hive 的组合本质上是用“便宜的大容量存储 延迟容忍的批量计算”来换成本。原始 Nginx 日志用 ORC 格式加 Snappy 压缩后体积能降到文本格式的四分之一左右一天的日志量如果只有几十 GB存一年也用不了多少存储。也说一下为什么不上 Elasticsearch 做长期存储ES 适合检索不适合全量扫描做聚合。网站日志分析的核心场景是“按天/小时做 GROUP BY 聚合”这正是 Hive 和 Spark 的强项。HDFS 上的数据可以分分区管理冷数据可以单独迁移或清理这个弹性在对象存储和数据库里都不好实现。链路确定后下面的实施顺序建议是先把 Kafka 和 HDFS 这对基础设施打通再往上建表、写作业。别一上来就调 UI 或写报表底层数据还没进仓库上层做得再漂亮也是空中楼阁。3. 日志采集与传输Flume 到 Kafka 的配置与实战这一章解决的是“日志怎么安全、不丢、不重地进入 Kafka”。我会给出可直接改用的配置并解释每个参数背后的考虑。如果你现场已经有用 Logstash 或 Filebeat 采集日志的环境也建议看完这部分因为断点续传和通道容量这两个设计在任何采集方案里都是通用的。3.1 Flume Taildir Source 的最小可用配置假设 Nginx 日志写在/data/nginx/logs/目录下文件名的滚动规律是access.log加日期后缀比如access.2024-11-20.log。新建一个配置文件flume-kafka.conf# 定义 agent 的三大组件名称 a1.sources r1 a1.channels c1 a1.sinks k1 # r1 使用 TAILDIR 类型支持断点续传 a1.sources.r1.type TAILDIR a1.sources.r1.positionFile /data/flume/taildir_position.json a1.sources.r1.filegroups f1 a1.sources.r1.filegroups.f1 /data/nginx/logs/access.*\\.log a1.sources.r1.fileHeader true a1.sources.r1.maxBatchCount 500 a1.sources.r1.channels c1 # c1 使用内存通道兼顾吞吐与简单性 a1.channels.c1.type memory a1.channels.c1.capacity 100000 a1.channels.c1.transactionCapacity 10000 # k1 是 Kafka Sink将数据写入指定 topic a1.sinks.k1.type org.apache.flume.sink.kafka.KafkaSink a1.sinks.k1.kafka.topic weblog-topic a1.sinks.k1.kafka.bootstrap.servers kafka-1:9092,kafka-2:9092,kafka-3:9092 a1.sinks.k1.kafka.flumeBatchSize 1000 a1.sinks.k1.channels c1几个关键点说一下。positionFile是 Taildir 的“记忆”文件它记录每个文件当前读到的字节偏移量。这个文件的目录要提前建好并保证磁盘空间否则 Flume 起不来或者重启后丢失位置。filegroups.f1的值是一个正则注意里面\.要转义写access.*\\.log在配置文件里才正确匹配到带日期的日志文件。maxBatchCount控制单次最多读多少条不用设得太大500 比较稳妥。capacity和transactionCapacity是通道容量前者是通道里最多能积压的事件数后者是单次事务最多能处理的事件数后者一定要小于等于前者这两个值太低会在大流量时出现 channel 满导致 Source 暂停读取。启动命令是flume-ng agent \ --name a1 \ --conf-file /opt/flume/conf/flume-kafka.conf \ --conf /opt/flume/conf启动后观察日志看到TaildirSource started并且没有 ERROR 就说明采集端起来了。这时可以手动往日志文件里追加几行测试数据再到 Kafka 里消费验证kafka-console-consumer.sh \ --bootstrap-server kafka-1:9092,kafka-2:9092,kafka-3:9092 \ --topic weblog-topic \ --from-beginning --max-messages 10能看到 10 条原始日志就代表链路通了。3.2 通道选型内存通道还是文件通道内存通道的读写速度快但进程一旦重启通道里还没发出去的数据就会丢。文件通道File Channel把数据落盘重启不丢但吞吐量会下降三分之一甚至更多。我一般这样选如果 Flume 和 Kafka 之间的网络很稳定且 Kafka 端有多副本保障用内存通道就够了因为数据从 Flume 发出后进没进 Kafka 是可以感知的网络抖动时可以靠 Kafka 端的重试来补偿。只有对“一条都不能丢”有严格要求的场景才上文件通道但那样同时要把 Kafka 的 acks 设成 all代价是写入延迟上升。这里有一个隐藏的坑替大家先踩了JVM 堆内存。Flume 默认启动脚本只给 2G 堆内存如果你的capacity设到了几十万堆内存不够就会频繁 Full GC表现为采集吞吐突然掉到零。建议把JAVA_OPTS里的-Xmx调到 4G 以上并加上-XX:UseG1GC。调整后通道容量和堆内存的配比控制在“容量 × 单条消息大小 × 3 不超过堆内存”的范围内。3.3 日志发往 Kafka 时的分区顺序问题Kafka 默认的分区器是按 key 的 hash 取模如果你不指定 key就是轮询或随机分区。对日志分析来说单条日志的顺序其实不重要但同一个用户的日志如果分散到不同分区后续做会话划分时就要跨分区拉数据。建议在 Flume 的 Kafka Sink 里配置一个自定义 key最简单的做法是拿日志里的 IP 或 cookie 字段的前几位当 key。生产环境我常用的是一个九位的 hash 值作为 key这样同一个用户总是进同一个分区后续做 session 切割会省很多事。这里要留意Kafka Sink 的配置项里没有直接的 key 字段设置需要写一个简单的拦截器从 body 里提取字段放 header 里再用kafka.key指定 header 的 key 名。这个操作不复杂但能省掉下游按时间重排序的麻烦。4. 数据仓库建模与装载Hive 分区表和 ORC 格式落地日志进入 Kafka 后下一步是把它们搬进 HDFS 并建好表。这一步做得对不对直接决定后续计算作业写起来顺不顺手。仓库分层这里我按最常见的做法来讲ODS 层放原始日志DWD 层放清洗后的明细ADS 层放聚合指标。不要嫌三层麻烦如果没有 DWD 层业务口径变了你就要去翻原始日志重跑有了 DWD 层重跑成本会低很多。4.1 ODS 层建表原样保留按天分区ODS 层要做的是把 Kafka 里的原始日志原封不动存下来不做任何过滤和解析。按照这个设计原则表结构如下CREATE EXTERNAL TABLE ods_weblog_raw ( line STRING ) PARTITIONED BY (dt STRING) STORED AS ORC LOCATION hdfs:///warehouse/ods/weblog_raw;这里有两个容易被质疑的点我解释一下。第一为什么只用一个line字段而不是把日志拆成 IP、时间、URL 等字段因为 ODS 层的主要职责是保留原始数据如果解析逻辑在这里就写死后面发现解析规则有漏洞要改的是整张表。把原始行留着DWD 层哪怕重写解析逻辑也只需要从 ODS 重跑不需要回 Kafka 找数据。第二为什么用 ORC 而不是纯文本同样是存一天日志ORC 加 Snappy 压缩后体积不到文本的四分之一而且后续 Spark 读 ORC 支持谓词下推过滤分区时能少读大量无用数据。装载数据这一步需要在 Flume 的 HDFS Sink 侧配好路径。如果选择用第二组 Flume 消费 Kafka 再写 HDFS路径格式配成/warehouse/ods/weblog_raw/dt%Y-%m-%d这样数据落地后 Hive 的ALTER TABLE ADD PARTITION就能直接对上。注意dt这个分区字段的取值建议统一用日志时间而不是采集时间不然凌晨补数据时会出现“昨天的日志落在今天分区”的混乱。4.2 DWD 层明细表解析字段与分区粒度选择DWD 层才是真正干活的地方。这里我把一条 Nginx 日志拆成可查询的字段CREATE EXTERNAL TABLE dwd_weblog_detail ( cookie_id STRING, session_id STRING, remote_addr STRING, request_time TIMESTAMP, request_method STRING, request_uri STRING, request_protocol STRING, status INT, body_bytes_sent INT, http_referer STRING, user_agent STRING ) PARTITIONED BY (dt STRING, hour STRING) STORED AS ORC LOCATION hdfs:///warehouse/dwd/weblog_detail;分区选择是dt加hour两级原因是线上排查问题时常说“今天 10 点到 11 点之间发生了什么”有一小时粒度会快很多。代价是分区数变多文件数量也可能变多但 ORC 加合适的文件大小控制后这个问题可控。如果你的场景没有小时级排查需求可以只保留dt分区减少小文件带来的 NameNode 压力。这里插一个字段设计的经验cookie_id是后续 UV 统计的核心一定要在 DWD 层就把它算好。常见的生成规则是优先取日志里的 Cookie 值没有 Cookie 时用remote_addr user_agent做哈希。规则要固定并写在代码注释里否则换个开发接手口径一改同一个用户就会被算成好几个人UV 直接翻倍。4.3 装载作业动态分区与文件大小控制从 ODS 往 DWD 洗数据的作业常见做法是写一个 Spark SQL 脚本用INSERT OVERWRITE配合动态分区。核心逻辑如下SET spark.sql.shuffle.partitions200; INSERT OVERWRITE TABLE dwd_weblog_detail PARTITION (dt, hour) SELECT cookie_id, session_id, remote_addr, request_time, request_method, request_uri, request_protocol, status, body_bytes_sent, http_referer, user_agent, dt, hour FROM ( SELECT ... -- 解析逻辑 FROM ods_weblog_raw WHERE dt ${bizdate} ) t;动态分区的关键是PARTITION (dt, hour)这两个字段要作为 SELECT 列的末尾两列输出。spark.sql.shuffle.partitions设成 200 是我在中等规模集群上的常用值它决定 Shuffle 后的任务数也决定输出文件数量的上限。文件大小最佳实践是单个文件 256MB 左右如果发现落地文件大量只有几 MB就调小shuffle.partitions相反如果每个文件到了 1GB 以上就调大它。切忌不看文件大小盲目改参数这是很多集群“小文件过多导致查询变慢”的根源。5. 指标计算与 Spark 作业从明细到业务报表数据进了 DWD 层接下来就是写各种统计口径的指标。这里我不去列一大堆 SQL只讲两个核心场景PV/UV 统计和热门页面 TopN因为这两个是日志分析最常见、也最能体现坑的。5.1 从明细算 PV 和 UV近似去重要敢用PV 很好算直接对明细表按时间分组计数就行。UV 稍微麻烦一点需要对cookie_id去重。如果数据量在千万级以内直接写COUNT(DISTINCT cookie_id)也没问题但到了亿级别这个操作会触发大量的数据倾斜和内存压力。这时候我一般用approx_count_distinct它基于 HyperLogLog 算法误差在 2% 以内但速度和资源消耗能降低一个量级。业务方要的 UV 本来就带有统计性质2% 的误差完全可接受。SELECT dt, COUNT(*) AS pv, COUNT(DISTINCT cookie_id) AS uv_exact, approx_count_distinct(cookie_id) AS uv_approx FROM dwd_weblog_detail WHERE dt 2024-11-20 GROUP BY dt;实际项目中我在同一张表上对比过精确值和近似值结果是约等于精确值而且作业运行时间从 40 分钟缩短到 12 分钟。没有特殊审计要求的地方全部改用近似去重即可。5.2 会话划分没有这个人均浏览页数就算不出来人均浏览页数这个指标需要先把“会话”切出来。业界标准做法是同一个用户两次请求间隔超过 30 分钟就认为会话中断新的请求开启新会话。Spark SQL 里用LAG窗口函数实现SELECT cookie_id, request_uri, request_time, SUM(session_flag) OVER ( PARTITION BY cookie_id ORDER BY request_time ) AS session_id FROM ( SELECT cookie_id, request_uri, request_time, CASE WHEN request_time - LAG(request_time) OVER ( PARTITION BY cookie_id ORDER BY request_time ) INTERVAL 30 MINUTES THEN 1 ELSE 0 END AS session_flag FROM dwd_weblog_detail WHERE dt 2024-11-20 ) t;这段逻辑有一个隐蔽的坑会话 ID 是基于SUM OVER生成的如果同一个用户在一分钟内并发请求了 100 条日志这些日志的request_time相同窗口内的LAG取到的值是一样的排序不稳定可能导致分到的会话不同。解决方法是把排序字段从request_time改成request_time 行号或者使用ROW_NUMBER() OVER (PARTITION BY cookie_id ORDER BY request_time, ...)做次序号。这个细节不处理会话数会偏高。5.3 Spark 作业的常用调优参数如果你是第一次写这类作业在提交脚本时这几个参数值得优先调整spark-submit \ --class WeblogAnalysis \ --master yarn \ --deploy-mode cluster \ --executor-memory 8g \ --num-executors 20 \ --executor-cores 4 \ --conf spark.sql.shuffle.partitions200 \ --conf spark.sql.adaptive.enabledtrue \ --conf spark.sql.adaptive.coalescePartitions.enabledtrue \ weblog-analysis.jarspark.sql.adaptive.enabled这个参数很值得打开它会根据 shuffle 数据的实际大小动态调整 reduce 端并行度能在很大程度上缓解数据倾斜问题。我见过不少作业运行慢的案例最后定位到的问题是shuffle.partitions写死成 1000大量空任务空跑开启 adaptive 之后自动合并分区时间缩短一半。另外--executor-cores不要超过 5超过之后 CPU 资源竞争反而拖慢整体进度。6. 避坑指南网站日志分析最容易踩的四个坑这一章写的是我反复踩过、也看别人踩过的坑。每条都按“现象 → 原因 → 解决”来写希望你少走这几段弯路。6.1 服务器时间不准分区数据张冠李戴有一回跑出来的日报和周报数据对不上后来一查发现集群里有几台机器的时间快了 20 分钟。采集端 Flume 用系统时间给 HDFS 路径命名分区那几台机器的日志就落到了后一个小时的目录里DWD 层按小时统计时数据就偏了。原因不复杂就是 NTP 同步没做或者失效了。解决方法是两件事一是统一在采集端用日志里的时间字段解析后传给 HDFS Sink而不是用服务器本地时间二是给所有节点配上 NTP 定时同步并在监控里加上时间偏移告警。我现在的习惯是任何日志采集项目落地前先检查所有节点的时间差这个检查 5 分钟就能做完但能省掉很多说不清的数据问题。6.2 UV 越算越大cookie_id 散了业务反馈 UV 数据比后台统计高一倍。排查后发现问题出在 cookie_id 的生成规则不统一一部分日志走了 A 规则另一部分走了 B 规则同一个用户在两种规则下生成了不同的 IDUV 自然就被拆分了。最常见的做法是“优先取 Cookie取不到再生成哈希 ID”但两套逻辑同时存在时就会出乱子。解决方法是把 cookie_id 的生成逻辑收敛成一个统一的 UDF 函数只保留一份实现并且把测试 case 提前写好——比如同一台 PC 上 Chrome 和 Firefox 的标识差异、无 Cookie 环境下的 IP 加 UA 哈希。可以接受口径有偏差但不能接受口径天天变。6.3 小文件太多NameNode 先扛不住了有段时间集群整体变慢NameNode 的 RPC 处理时间飙升进入 Active 节点的日志全是Block相关告警。最终定位是 Flume 的 HDFS Sink 每 10 分钟就滚动一次文件而且每个文件只有 50MB 左右一天下来产生了几千个小文件NameNode 内存被文件元数据占满。解决方法是改掉滚动策略把rollInterval从 10 分钟改成 1 小时同时设置rollSize为 256MB让文件尽量按大小滚动而不是按时间滚动。另外在 DWD 层装载时配合coalesce或repartition控制输出文件数量。这个坑几乎每个做日志分析的人都会遇到一次早改早省心。6.4 Kafka 消费滞后数据晚了两个小时才入库另一个常见求助是“报表延迟太严重”排查发现 Kafka 消费者组的 lag 一直在涨。原因往往是下游清洗作业的并行度不够一个分区只有一个消费者线程在跑。解决方法不是盲目增加 Spark 作业的并发而是先看 topic 的分区数——如果分区数是 10消费者并行度设成 20 也没有意义最多只有 10 个线程在干活。在确保分区数足够的情况下再去调消费者的线程数。如果没有改分区数的权限还有一个变通做法在 Flume 消费 Kafka 写 HDFS 的环节直接多启几个 Agent 实例配合 Kafka 的 group 机制实现并行消费效果一样。最后说一个我自己的习惯每次在日志分析链路上做完改动第一件事不是看报表数字而是对比前一天同时段的数据量是否在合理范围内。数据量骤降或者骤升多半是链路出了问题比任何指标都敏感。这个习惯帮我抓出过不少配置错误。日志分析这个方向组件选型其实不算难难的是口径一致和数据稳定。把采集、存储、计算、口径这几件事做扎实这个综合案例就算真正落地了希望帮到你。本文还有配套的精品资源点击获取