简介一份基于 Hadoop 的游戏数据分析系统源码包面向 Hadoop 大数据初学者、Java 开发者和游戏运营分析人员完整演示如何利用 HDFSMapReduce 对游戏日志进行清洗、统计与可视化。资源共 20 个文件以 6 个 JSP 页面、Java 类与 SQL 脚本为主体辅以前端 CSS/JS 样式和 JAR 依赖包整体仅 2.1MB适合快速阅读与二次开发。项目内置玩家活跃度、付费行为、游戏习惯、新用户分析等模块打通从 MySQL 表结构、后台逻辑到 Web 展示的完整链路可直接导入 IDE 运行。压缩包目录包含源码、数据库脚本、配置与文档虽体量小巧但结构清晰能帮助理解游戏用户画像与关键指标计算思路。已有 220 人学习下载适合想通过实际案例快速掌握 HadoopJava 数据分析流程的开发者。1. 游戏日志一上量单机分析就先顶不住了“基于 Hadoop 的游戏数据分析系统”这类项目常见于两类场景一类是小团队拿到一款有百万级 DAU 的游戏后需要统计留存、付费、关卡通过率另一类是课程设计或实训环境里要求用 Hadoop 生态完成一套“日志采集→存储→分析→报表”的闭环。无论哪种真正的难点都不在 Hive SQL 本身而在当登录、充值、对战日志以每天几十 GB 的速度增长时原来的 MySQL 和 Excel 方案已经算不动了。Hadoop 在这个场景里给出的是一套确定性方案HDFS 负责把 TB 级日志以极低成本存下来Yarn 负责把分析任务拆给多台机器同时跑Hive 则让分析师用 SQL 而不是写 Java MapReduce 去完成指标计算。本文按一个真实项目最常走的路径来组织先在单机伪分布式上跑通再扩展成小集群然后把游戏日志整入 HDFS、建 Hive 分层表、算核心指标最后落到定时调度和数据校验上。2. Hadoop 集群搭建从单机伪分布式到三节点分布式2.1 先判断规模再决定是伪分布式还是真集群日日志量在几十 GB 以内、团队只有一台开发机时伪分布式已经能完成绝大部分开发验证。伪分布式模式下NameNode、DataNode、ResourceManager 运行在同一台机器的独立进程中行为与真实集群几乎一致换到多节点只需要改配置文件和 hosts。数据量进入每日几百 GB、或者需要多人同时跑分析任务时三节点是性价比最高的起步配置一台跑 NameNode 加 ResourceManager两台跑 DataNode 加 NodeManager。这里有一个容易犯的认知错误伪分布式不能验证“多机并行”的效果但它能验证 ETL 逻辑、分区设计、数据倾斜问题是否会出现——因为任务最终还是按 MapReduce 模型调度过度追求一台真实集群反而会让环境问题掩盖业务问题。第一步先把 Hadoop 安装与配置做扎实后面所有分析工作才有可靠底座。2.2 Hadoop 安装与配置Ubuntu 下伪分布式的最小可运行配置JDK 使用 8 或 11Hadoop 3.x 版本要求 JDK 8 以上。安装包解压到 /opt/hadoop-3.3.6并把目录 owner 改为 hadoop 用户不要放在 /root 下否则后面 DataNode 写入权限问题会让排查成本翻倍。SSH 免密配置完成后进入核心配置文件修改环节。core-site.xml 里的两个属性决定整个集群的入口configuration property namefs.defaultFS/name valuehdfs://localhost:9000/value /property property namehadoop.tmp.dir/name value/opt/hadoop-3.3.6/data/tmp/value /property /configurationfs.defaultFS 是 HDFS 的地址伪分布式写 localhost:9000真实集群要换成主节点主机名。hadoop.tmp.dir 指向 namenode 元数据和 datanode 数据块的根目录格式化时生成的元数据会落在这里如果格式化后移动目录再启动会报 NameNode is not formatted。接着是 hdfs-site.xml伪分布式最关键的是把副本数设为 1configuration property namedfs.replication/name value1/value /property property namedfs.namenode.name.dir/name valuefile:///opt/hadoop-3.3.6/data/name/value /property property namedfs.datanode.data.dir/name valuefile:///opt/hadoop-3.3.6/data/data/value /property /configuration副本数不设成 1 的话伪分布式只有一台 DataNode第二副本永远处于 under-replicated 状态50070 页面上会一直显示黄色告警。真实集群中副本数统一设 3兼顾容错和存储成本。yarn-site.xml 和 mapred-site.xml 负责让 MapReduce 任务跑在 Yarn 上configuration property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property property nameyarn.resourcemanager.hostname/name valuelocalhost/value /property /configurationconfiguration property namemapreduce.framework.name/name valueyarn/value /property /configuration配置文件改完后执行格式化与启动bin/hdfs namenode -format sbin/start-dfs.sh sbin/start-yarn.sh jps注意 namenode -format 只在首次启动前执行。第二次格式化会重新生成 cluster ID导致 DataNode 里已存在的 block 无法关联整个文件系统报错。jps 输出中应看到 NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager 五个进程。用hdfs dfsadmin -report查看容量用 WordCount 验证计算链路hadoop jar share/hadoop/mapreduce/hadoop-mapreduce-examples-2.10.2.jar wordcount /input /output其中 /input 必须已存在于 HDFS/output 必须不存在否则任务拒绝执行。这一步能同时验证 HDFS 读写、Yarn 调度、MapReduce 执行三个阶段。2.3 从伪分布式改成三节点集群的四个差异点伪分布式跑通后上真实集群不需要重装 Hadoop只改四处。第一每台机器的 /etc/hosts 配齐三台节点主机名映射第二core-site.xml 的 fs.defaultFS 从 localhost 改成 master 节点主机名第三workers 文件3.x 之前的 slaves 文件里写入两台 DataNode 主机名每行一个第四需要把 master 上配置好的 hadoop 目录完整同步到两台 worker 节点并确认 owner 和启动用户一致。常见做法是直接在 hadoop 用户下用 rsync 同步rsync -avz /opt/hadoop-3.3.6/ hadoopnode01:/opt/hadoop-3.3.6/如果分析任务对可靠性要求高比如凌晨的 ETL 不能被单点故障打断则需要引入 ZooKeeper 做 NameNode 高可用也就是把 Active NameNode 和 Standby NameNode 的选主交给 ZooKeeper。Hadoop 和 ZooKeeper 整合实战在刚起步的游戏分析系统里可以后置先保证副本数和节点角色正确可用性靠定时备份元数据来兜底。伪分布式与真实集群的对应关系可以按下面这张表记忆角色伪分布式三节点集群NameNodelocalhostmaster 节点DataNodelocalhostnode01、node02ResourceManagerlocalhostmaster 节点NodeManagerlocalhostnode01、node02副本数133. 游戏日志的采集与 HDFS 存储设计埋点规范决定分析上限3.1 游戏日志在 Hadoop 生态里从哪一环进来一套完整的游戏日志管道通常长这样游戏客户端或服务端把日志写到本地文件Flume 或 Logstash 负责从文件目录里读取经过简单过滤后写入 Kafka 做消峰缓冲再由下游任务写入 HDFS。对于“游戏数据分析系统”这个标题来说Kafka 可以先不引入日志量在每天百万级事件以下时Flume 直写 HDFS 更简单少一个组件就少一类故障。埋点字段质量决定了留存和付费分析能算到什么程度。最基础的游戏日志至少要覆盖事件名、时间戳、玩家 ID、服务器 ID、渠道 ID 和事件内容。下表是常见的三类日志关键字段日志类型关键字段典型事件登录日志uid, server_id, channel, device, ip, tslogin, logout充值日志uid, order_id, amount, pay_type, status, tspay_success关卡日志uid, level_id, server_id, success, duration, tslevel_start, level_finish字段命名尽量用统一前缀和类型。ts 统一用毫秒时间戳不要时而用字符串时而又用 10 位秒级时间戳否则后面时区转换和留存窗口计算会不停出 bug。3.2 用 Flume Spooldir 把游戏服务器日志送进 HDFS游戏服务器生成的日志通常是滚动文件比如每小时切分一个 log 文件。Flume 的 spooldir source 监控一个目录目录里的文件一旦写完被放进来就会被自动消费处理完成后文件名加上 .COMPLETED 后缀。配置如下agent1.sources gameLog agent1.sinks hdfsSink agent1.channels ch1 agent1.sources.gameLog.type spooldir agent1.sources.gameLog.spoolDir /data/game/logs agent1.sources.gameLog.fileSuffix .COMPLETED agent1.sinks.hdfsSink.type hdfs agent1.sinks.hdfsSink.hdfs.path hdfs://master:9000/game/ods/login/dt%Y%m%d agent1.sinks.hdfsSink.hdfs.fileType DataStream agent1.sinks.hdfsSink.hdfs.rollInterval 300 agent1.sinks.hdfsSink.hdfs.rollSize 134217728 agent1.sinks.hdfsSink.hdfs.rollCount 0 agent1.channels.ch1.type memory agent1.channels.ch1.capacity 20000 agent1.channels.ch1.transactionCapacity 8000 agent1.sources.gameLog.channels ch1 agent1.sinks.hdfsSink.channel ch1关键参数说明rollInterval 是文件滚动周期设 300 表示每 5 分钟强制关闭当前文件生成新文件rollSize 按字节滚动134217728 即 128MB与 HDFS 块大小保持一致rollCount 设为 0 表示不按事件数滚动。三个参数不要同时生效否则日志量一旦上来会产生大量几十 KB 的小文件给后续 Hive 查询带来严重性能问题。如果游戏日志本身就是 JSON可以先用 Text 格式完整落 ODS清洗时再解析。3.3 HDFS 目录分区规划多层搭建不要一张表打天下HDFS 上的目录规划直接对应数据分层常见做法是按下表拆成 ODS、DWD、ADS 三层层级路径示例存储内容ODS/game/ods/login/dt2024-06-01原始日志JSON 原样存储DWD/game/dwd/t_player_login/dt2024-06-01清洗、解析、过滤后的明细ADS/game/ads/dau/dt2024-06-01DAU、留存、ARPPU 等结果指标分区粒度按天路径里写死 dt%Y%m%d。如果同时接多款游戏路径里还要加一层 game_id比如 /game/ods/ingame01/login/dt2024-06-01不要把所有游戏日志混在一个目录里。DWD 层尽量做列裁剪和字段改名ODS 保留原始全量字段用于回溯。3.4 小文件问题的合并处理ODS 层由 Flume 写入受 rollInterval 影响产生的文件粒度通常还好。真正容易爆小文件的是 DWD 层一旦 SQL 里用了动态分区且分区数量多每个 reduce 生成的文件又小HDFS 在几天内就可能堆出几十万个文件。常用做法是开启 Hive 的自动合并SET hive.merge.mapfilestrue; SET hive.merge.mapredfilestrue; SET hive.merge.size.per.task256000000; SET hive.merge.smallfiles.avgsize160000000;然后重新执行一次 INSERT OVERWRITEHive 会在任务结束后自动启动一个额外 Map 任务把同一分区下的小文件合并成大文件。如果表是 ORC 格式还可以直接执行ALTER TABLE game_dwd.t_player_login PARTITION(dt2024-06-01) CONCATENATE;ORC 表的 CONCATENATE 不会重新执行 MapReduce而是直接合并 stripe速度很快。这一步做完再用hdfs fsck /game/dwd/t_player_login -files检查文件分布如果每个分区只剩下个位数的大文件说明已经符合查询要求。4. Hive 建模与指标分析留存、付费、关卡难度4.1 DWD 清洗从原始 JSON 日志抽出一张玩家状态表ODS 表可以直接以整行 String 类型存储建表最简单的方式是外部表CREATE EXTERNAL TABLE game_ods.login_json ( line STRING ) PARTITIONED BY (dt STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY \n LOCATION /game/ods/login;表建好后先加载分区MSCK REPAIR TABLE game_ods.login_json;这一步会扫描 HDFS 路径下已有的 dt 目录并自动加载分区是数据入仓后最容易忘的动作。接着用 get_json_object 把 JSON 里的字段抽出来写进 DWD 表INSERT OVERWRITE TABLE game_dwd.t_player_login PARTITION(dt) SELECT get_json_object(line, $.uid) AS uid, get_json_object(line, $.server_id) AS server_id, get_json_object(line, $.channel) AS channel, get_json_object(line, $.ts) AS ts FROM game_ods.login_json WHERE dt 2024-06-01 AND get_json_object(line, $.uid) IS NOT NULL AND length(get_json_object(line, $.uid)) 0 AND get_json_object(line, $.ts) 1717171200000;清洗逻辑里必须过滤三件事uid 为空、时间戳明显小于开服时间戳、测试账号前缀。get_json_object 每次调用都会重新解析整行 JSON字段多时性能会明显下降可以在子查询里先把 line 解析成 struct再在外部查询引用。DWD 层建表时加上正确字段类型ts 用 BIGINT金额用 DECIMALCREATE EXTERNAL TABLE game_dwd.t_player_login ( uid STRING COMMENT 玩家ID, server_id STRING COMMENT 服务器ID, channel STRING COMMENT 渠道ID, ts BIGINT COMMENT 毫秒时间戳, dt STRING COMMENT 业务日期 ) PARTITIONED BY (dt STRING) STORED AS ORC LOCATION /game/dwd/t_player_login;ODS 层用 TextFile 保留原始 jsonDWD 层切换到 ORC这一步能把查询扫描的数据量压到四分之一以下。4.2 DAU 与次留指标先定口径再写 SQLDAU 在游戏业务里的口径通常是“当日有登录事件的去重用户数”写起来直接SELECT dt, COUNT(DISTINCT uid) AS dau FROM game_dwd.t_player_login WHERE dt BETWEEN 2024-06-01 AND 2024-06-07 GROUP BY dt;次日留存的计算要同时用到首日登录集合和次日登录集合标准写法是先算首登日再与原表关联SELECT first_login.first_dt, COUNT(DISTINCT first_login.uid) AS new_users, COUNT(DISTINCT IF(login.uid IS NOT NULL, first_login.uid, NULL)) AS next_day_remain, ROUND(COUNT(DISTINCT IF(login.uid IS NOT NULL, first_login.uid, NULL)) / COUNT(DISTINCT first_login.uid), 4) AS next_day_rate FROM ( SELECT uid, dt AS first_dt FROM game_dwd.t_player_login WHERE dt 2024-06-01 AND dt 2024-06-07 GROUP BY uid, dt ) first_login LEFT JOIN ( SELECT DISTINCT uid FROM game_dwd.t_player_login WHERE dt 2024-06-02 ) login ON first_login.uid login.uid GROUP BY first_login.first_dt;这段 SQL 的关键在 GROUP BY uid, dt它把同一用户一天内的多次登录压缩成一条保证 DAU 去重正确。LEFT JOIN 一侧用 DISTINCT 去重避免一个用户次日登录两次导致用户被重复计数。4.3 付费分析与关卡难度分析付费分析常用指标是付费率当日付费人数除以当日活跃人数。付费订单里 status 字段必须过滤为支付成功状态SELECT pay.dt, COUNT(DISTINCT pay.uid) AS pay_users, ROUND(COUNT(DISTINCT pay.uid) / COUNT(DISTINCT active.uid), 4) AS pay_rate FROM ( SELECT uid, dt FROM game_dwd.t_pay_order WHERE status 1 GROUP BY uid, dt ) pay LEFT JOIN ( SELECT uid, dt FROM game_dwd.t_player_login GROUP BY uid, dt ) active ON pay.uid active.uid AND pay.dt active.dt GROUP BY pay.dt;ARPPU 则用当日充值总额除以当日付费人数。关卡难度更合适用漏斗方式观察每关的“到达人数”通过 level_start 事件计算“通过人数”通过 level_finish 且 success1 计算两个数相除得到通过率。4.4 数据倾斜与 MapReduce 的硬瓶颈游戏数据分析里最容易出现的数据倾斜场景是热门服务器。某个老区的活跃用户数占全天 30%按 server_id 做 group by 时所有日志落到同一个 reduce任务卡在 99% 不动。最直接的解法是给小维表加 MapJoin 暗示SELECT /* MAPJOIN(server_dim) */ agg.server_id, server_dim.server_name FROM ( SELECT server_id, COUNT(*) AS pv FROM game_dwd.t_player_login WHERE dt 2024-06-01 GROUP BY server_id ) agg LEFT JOIN game_dim.server_dim server_dim ON agg.server_id server_dim.server_id;MAPJOIN 会把 server_dim 这张小表分发到每个 map 端reduce 阶段不再按 server_id 收集数据。日常报表如果只在凌晨跑Hive 已经够用但如果运营要求分钟级刷新付费看板再上 Spark on Yarn。批处理链路稳定运维的优先级高于计算引擎的先进性这段话在 Hadoop 面试题里也是同样结论。5. 从跑通到跑稳调度、结果导出与数据质量校验5.1 把分析链路串成定时任务生产环境里Hive SQL 的执行顺序必须严格可控DWD 清洗跑完才能跑 ADS 指标指标跑完才能导出结果。Azkaban 常用作正式调度它把每个 SQL 脚本或 shell 脚本定义成一个 job用依赖关系串成 flow。开发期或者实训环境里crontab 加 shell 脚本更直接#!/bin/bash # 每天凌晨2点执行前一天的批处理 beeline -u jdbc:hive2://localhost:10000 -n hadoop \ --hivevar biz_date$(date -d yesterday %F) \ -f /opt/sql/game_dwd.sql beeline -u jdbc:hive2://localhost:10000 -n hadoop \ --hivevar biz_date$(date -d yesterday %F) \ -f /opt/sql/game_dws_dau.sqlcrontab 里这样注册30 2 * * * /opt/scripts/game_etl.sh /var/log/game_etl.log 21整个脚本里所有 Hive 任务必须都写成 INSERT OVERWRITE保证任务重跑时不会产生重复数据。biz_date 用 date -d yesterday 从系统时钟推导比在 SQL 里写死日期要安全得多。5.2 结果导出与数据质量校验ADS 层结果如果存在 HDFS 上报表系统无法直接访问常见做法是再用 sqoop 或脚本把结果导出到 MySQL。导出后立刻做一次“对拍”拿 Hive 直接 count 结果与 MySQL 报表数字对比一致后再对外发布。数据质量脚本里至少要检查三件事本次任务涉及的分区文件是否完整生成、DWD 行数是否为 0、DWD 行数对比昨天波动是否超过合理阈值。ROW_CNT$(beeline --silent -e SELECT COUNT(*) FROM game_dwd.t_player_login WHERE dt$BIZ_DATE) if [ $ROW_CNT -eq 0 ]; then echo ETL_FAIL: empty partition on $BIZ_DATE exit 1 fi把这样的检查放在每个 flow 的末尾失败时立即退出并告警比在报表上发现数据异常再回头翻日志要省时间。数据管道的稳定性靠的不是 Hadoop 本身而是在它外围维护的这套约束与校验逻辑。本文还有配套的精品资源点击获取