简介这份资源是基于Hadoop的疾病信息统计平台完整项目源码面向具备Java与大数据基础、希望实践分布式数据处理的学习者与开发者可用于公共卫生数据采集、存储、分析与可视化等场景的二次开发与课程设计。压缩包共41个文件约10.87MB以25个Java源文件为核心实现业务逻辑辅以6个XML配置与2个properties参数文件另有jar依赖、yml、arff数据集及mvnw构建脚本等结构清晰便于按模块研读。目前已有84人学习下载。项目围绕HDFS分布式存储与MapReduce并行计算展开涉及数据采集、HBase实时查询、Hive数据仓库、YARN资源调度及Kerberos安全机制等知识点读者可借此理解Hadoop生态各组件的协作方式掌握从数据接入到统计展示的完整链路并参考其容错与扩展设计思路快速搭建可运行的疾病信息分析原型。1. 疾病信息统计平台为什么值得用 Hadoop 重做一遍疾控和医院信息科的人大多遇到过这种场面一个市级传染病上报系统三年攒下几千万条门诊诊断记录领导要按街道、年龄段、病种做交叉统计MySQL 跑一个 group by 直接卡死加索引也救不回来。这不是 SQL 写得差是单机关系库的横向扩展天花板到了。基于 Hadoop 的疾病信息统计平台本质就是把「海量疾病明细数据的存储 离线聚合统计」这两件事从单机数据库搬到分布式文件系统和计算框架上让千万级甚至亿级的确诊、疑似、症状、转归记录能按维度快速出报表。它适合两类人一类是做大数据课程设计、需要一套能跑通全流程的实战项目另一类是信息科工程师手里真有历史数据积压、想验证 Hadoop 路线到底能不能落地。下面按「先立住原理、再动手复现、最后讲坑」的顺序拆开讲。2. 疾病数据上 Hadoop 前先想清楚存什么、怎么切2.1 疾病信息统计平台的数据模型与分层疾病信息统计平台的数据不像电商订单那么规整它的字段带着强烈的公共卫生语义。一条典型的疾病上报记录至少包含患者编号、性别、出生日期、身份证脱敏串、诊断编码ICD-10、疾病名称、发病日期、确诊日期、上报机构、所在区县、转归状态。这些字段决定了后面统计的维度——按时间、按地域、按人群、按病种。在 Hadoop 里我不会把这些字段一股脑塞进一张宽表而是按数仓分层来组织。常见做法是三层ODS 层存原始上报明细一行一条记录不做任何清洗DWD 层做去重、字段标准化、日期格式统一DWS/ADS 层才是按维度聚合好的统计结果直接喂给前端报表。这样分层的好处是原始数据永远可回溯统计口径变了只需要重跑 DWD 往上的部分不用动 ODS。为什么强调分层因为疾病数据有个特点上报口径会变。今天按发病日期统计明天可能要求按确诊日期今天算疑似和确诊合并明天要拆开。如果一开始就把聚合结果写死改口径等于重做。分层之后ODS 是黑匣子里的原始凭证DWD 是干净的事实表聚合逻辑放在最上层改起来代价小得多。2.2 为什么选 Hive 而不是手写 MapReduce标题里是 Hadoop但真正落地统计时绝大多数人不会去手写 MapReduce。原因很直接疾病统计的查询模式是典型的 SQL 聚合——count、sum、group by、多表 join用 MapReduce 写一遍 group by 要几百行调试成本极高。Hive 把 SQL 翻译成 MapReduce 或 Tez/Spark 执行开发效率高一个数量级。我一般会这样选数据量在千万级、统计维度固定、团队 SQL 功底强直接上 Hive如果还要做实时预警或流式上报才考虑在 Hadoop 之上叠 Spark Streaming 或 Flink。对于「疾病信息统计平台」这个定位离线批处理是主战场Hive 是性价比最高的选择。Hadoop 提供 HDFS 存储和 YARN 资源调度Hive 提供 SQL 层这套组合是课程设计和中小规模生产环境里最稳的。提示不要为了炫技在统计平台里硬上 HBase。HBase 擅长按行键随机读写而疾病统计是典型的全表扫描加聚合HBase 的 scan 性能反而不如 Hive 走 HDFS 顺序读。2.3 伪分布式环境的最小搭建步骤热词里「hadoop伪分布式搭建」出现频率很高说明很多人卡在环境这一步。伪分布式是单机模拟多节点NameNode、DataNode、ResourceManager、NodeManager 都跑在一台机器上适合开发和课程设计。下面是我常用的最小步骤基于 Linux 虚拟机。# 1. 安装 JDKHadoop 3.x 需要 JDK 8 或 11 sudo apt install openjdk-8-jdk -y java -version # 2. 下载并解压 Hadoop版本按自己课程要求选这里以 3.3.x 为例 tar -zxvf hadoop-3.3.6.tar.gz -C /opt/ mv /opt/hadoop-3.3.6 /opt/hadoop # 3. 配置环境变量写入 ~/.bashrc export HADOOP_HOME/opt/hadoop export PATH$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin export JAVA_HOME/usr/lib/jvm/java-8-openjdk-amd64 source ~/.bashrc环境变量配好后核心是改四个配置文件。core-site.xml指定 HDFS 的默认地址hdfs-site.xml设副本数为 1伪分布式只有一台机器mapred-site.xml指定用 YARN 跑 MapReduceyarn-site.xml配 ResourceManager 地址。改完执行hdfs namenode -format格式化再start-dfs.sh和start-yarn.sh启动。用jps能看到 NameNode、DataNode、ResourceManager、NodeManager、SecondaryNameNode 五个进程就算搭好了。参数上最容易翻车的是fs.defaultFS写成file:///而不是hdfs://localhost:9000这样 Hive 建表时会写到本地文件系统后面查数据发现表是空的。另一个是 SSH 免密没配start-dfs.sh会反复要密码。这两点后面避坑章节还会展开。3. 把疾病明细灌进 Hive建表、分区与统计 SQL3.1 建一张分区化的疾病明细表疾病数据天然带时间属性按日期分区是最合理的。分区字段不能出现在表字段里它是目录结构的一部分。下面这张 ODS 表按上报日期分区存储格式用 ORC压缩比和查询性能都比 TextFile 好。CREATE TABLE ods_disease_report ( patient_id STRING COMMENT 患者编号, gender STRING COMMENT 性别, birth_date STRING COMMENT 出生日期, icd_code STRING COMMENT ICD-10诊断编码, disease_name STRING COMMENT 疾病名称, onset_date STRING COMMENT 发病日期, confirm_date STRING COMMENT 确诊日期, report_org STRING COMMENT 上报机构, district STRING COMMENT 所在区县, outcome STRING COMMENT 转归状态 ) COMMENT 疾病上报原始明细 PARTITIONED BY (report_date STRING COMMENT 上报日期 yyyy-MM-dd) STORED AS ORC TBLPROPERTIES (orc.compressSNAPPY);逻辑说明分区字段report_date单独拎出来数据加载时按日期落到不同目录查询时加WHERE report_date2024-01-01就能做分区裁剪只扫一个目录。参数上orc.compress选 SNAPPY 是折中方案压缩率够用且解压快如果磁盘紧张可以换 ZLIB但查询会慢一些。字段全部用 STRING 是 ODS 层的惯例清洗放到 DWD 做避免加载时因为类型转换失败丢数据。3.2 从 CSV 批量加载与动态分区实际数据多半是 CSV 或从旧系统导出的文本。加载方式有两种LOAD DATA适合文件已经在 HDFS 上INSERT INTO ... SELECT适合边转换边加载。下面用动态分区把一批 CSV 按上报日期自动分到不同分区。-- 开启动态分区 SET hive.exec.dynamic.partitiontrue; SET hive.exec.dynamic.partition.modenonstrict; -- 假设 CSV 已上传到 /input/disease/ 目录字段顺序与表一致 INSERT INTO TABLE ods_disease_report PARTITION (report_date) SELECT patient_id, gender, birth_date, icd_code, disease_name, onset_date, confirm_date, report_org, district, outcome, report_date FROM temp_disease_stage;逻辑说明动态分区要求分区字段放在 SELECT 的最后一位Hive 按这一列的值决定写入哪个分区目录。nonstrict模式允许所有分区字段都是动态的不加这个设置会报错。参数上要注意hive.exec.max.dynamic.partitions默认是 1000如果一天的数据跨了很多日期可能超限需要调大。加载完成后用SHOW PARTITIONS ods_disease_report确认分区目录生成正确。3.3 三个核心统计维度的 SQL 写法疾病统计平台最常出的报表就三类按病种统计发病数、按地域统计分布、按年龄段统计构成。下面给出可直接套用的 SQL。-- 1. 按病种统计月度发病数 SELECT disease_name, substr(onset_date, 1, 7) AS month, COUNT(*) AS case_count FROM ods_disease_report WHERE report_date BETWEEN 2024-01-01 AND 2024-12-31 GROUP BY disease_name, substr(onset_date, 1, 7) ORDER BY case_count DESC; -- 2. 按区县统计确诊数 SELECT district, COUNT(*) AS confirm_count FROM ods_disease_report WHERE confirm_date IS NOT NULL AND confirm_date ! GROUP BY district; -- 3. 按年龄段统计构成 SELECT CASE WHEN cast(year(current_date()) - substr(birth_date,1,4) AS INT) 18 THEN 0-17 WHEN cast(year(current_date()) - substr(birth_date,1,4) AS INT) 40 THEN 18-39 WHEN cast(year(current_date()) - substr(birth_date,1,4) AS INT) 65 THEN 40-64 ELSE 65 END AS age_group, COUNT(*) AS cnt FROM ods_disease_report GROUP BY CASE WHEN cast(year(current_date()) - substr(birth_date,1,4) AS INT) 18 THEN 0-17 WHEN cast(year(current_date()) - substr(birth_date,1,4) AS INT) 40 THEN 18-39 WHEN cast(year(current_date()) - substr(birth_date,1,4) AS INT) 65 THEN 40-64 ELSE 65 END;逻辑说明第一条用substr截取年月做分组比用to_date再格式化更省 CPU。第二条过滤掉确诊日期为空的记录避免把疑似算进确诊。第三条的年龄段分桶是公共卫生统计的常见口径实际项目里分界点可能按需求调整改 CASE 里的数字即可。参数上如果数据量特别大可以在 GROUP BY 前先做一次DISTRIBUTE BY disease_name让相同病种落到同一 reducer减少数据倾斜。注意year(current_date())在 Hive 里每次调用都会求值如果表有上亿行建议先算好当前年份存成变量或者用unix_timestamp做日期差避免重复计算拖慢查询。4. 统计结果怎么落库、怎么给前端用4.1 聚合结果导出到 MySQL 做报表Hive 查出来的结果前端不能直接读通常要同步到 MySQL 或 PostgreSQL 这类关系库再由 Web 层查询。同步方式常见两种Sqoop 导出或者用 Hive 的INSERT OVERWRITE DIRECTORY落地成文件再批量导入。Sqoop 更省事一条命令搞定。# 把 Hive 统计结果导出到 MySQL sqoop export \ --connect jdbc:mysql://localhost:3306/disease_stat \ --username root --password ****** \ --table stat_by_disease \ --export-dir /user/hive/warehouse/ads_stat_by_disease \ --input-fields-terminated-by \001 \ --update-mode allowinsert \ --update-key disease_name,month逻辑说明--export-dir指向 Hive 表在 HDFS 上的目录--input-fields-terminated-by \001是 Hive 默认分隔符写错会导致字段错位。--update-mode allowinsert配合--update-key实现按主键更新重复跑不会产生重复行。参数上 MySQL 连接串要确认驱动 jar 在 Sqoop 的 lib 目录下否则报 ClassNotFound。4.2 用 Azkaban 或 crontab 做定时调度统计平台不能靠人手动跑 SQL。课程设计里可以用 crontab 简单调度生产环境一般上 Azkaban 或 DolphinScheduler。核心是把「加载 → 清洗 → 聚合 → 导出」串成工作流每天凌晨跑一次。# crontab 示例每天凌晨 2 点跑统计脚本 0 2 * * * /opt/hadoop/bin/hive -f /opt/scripts/daily_stat.sql /var/log/disease_stat.log 21逻辑说明hive -f执行 SQL 文件输出重定向到日志便于排查。参数上要注意 crontab 的环境变量和登录 shell 不同HADOOP_HOME、JAVA_HOME必须在脚本里显式 export否则会报找不到命令。这是新手最常踩的调度坑。4.3 统计口径变更时怎么重跑前面强调分层这里就体现价值了。如果统计口径从「按发病日期」改成「按确诊日期」只需要改 ADS 层的聚合 SQL重跑 ADS 任务ODS 和 DWD 不动。重跑前用INSERT OVERWRITE而不是INSERT INTO保证结果表是幂等的不会叠加旧数据。INSERT OVERWRITE TABLE ads_stat_by_disease SELECT disease_name, substr(confirm_date,1,7) AS month, COUNT(*) AS case_count FROM dwd_disease_clean WHERE confirm_date IS NOT NULL GROUP BY disease_name, substr(confirm_date,1,7);逻辑说明INSERT OVERWRITE会先清空目标表或分区再写入适合每天全量重算的场景。如果表很大只想更新某个月可以配合分区INSERT OVERWRITE TABLE ... PARTITION(month2024-01)只覆盖单月分区省时间。5. 疾病统计平台落地时的避坑清单5.1 小文件过多拖垮 NameNode现象跑了一周定时任务后HDFS 上出现几十万个小文件NameNode 内存飙升查询越来越慢。原因每次调度都往分区目录写一批小文件动态分区按天切分后每个分区文件数爆炸。解决在 Hive 里开启合并SET hive.merge.mapfilestrue; SET hive.merge.size.per.task256000000;或者定期用ALTER TABLE ... CONCATENATE合并 ORC 文件。更彻底的做法是调度任务里加一步hadoop fs -getmerge再重新上传。5.2 数据倾斜导致某个 reducer 卡死现象统计 SQL 跑了两个小时99% 的 reducer 早就完成就剩一两个一直卡在 99%。原因某个疾病名称或某个区县的数据量远超其他全部落到同一个 reducer。解决先SELECT disease_name, COUNT(*) FROM ... GROUP BY disease_name ORDER BY 2 DESC LIMIT 10找出倾斜键然后对这些键加随机前缀打散或者开启SET hive.groupby.skewindatatrue;让 Hive 自动做两阶段聚合。5.3 日期格式不统一导致统计漏数现象月度报表数字明显偏少排查发现部分记录的onset_date是2024/01/15格式部分是2024-01-15substr截取后分组错乱。原因不同医院上报系统导出的日期格式不一致。解决在 DWD 层统一用regexp_replace(onset_date, /, -)标准化再做长度校验非法日期落到脏数据表人工核对。这个坑血泪经验最多因为不报错只是数字悄悄变少。5.4 伪分布式内存不足导致任务被 kill现象跑大查询时 Container 被 YARN kill日志报Container killed on request. Exit code is 137。原因虚拟机内存给小了NodeManager 可用内存不够或者 mapper/reducer 的堆内存设太大。解决调小mapreduce.map.memory.mb和mapreduce.reduce.memory.mb同时确认yarn.nodemanager.resource.memory-mb不超过虚拟机物理内存。课程设计的虚拟机建议至少 4G 内存2G 跑大查询必翻车。5.5 Hive 元数据没启动导致连不上现象hive命令进去后执行任何 SQL 都报Unable to instantiate org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClient。原因Hive 的元数据库通常是 MySQL没启动或者hive-site.xml里的连接串配错。解决先确认 MySQL 服务在跑再检查javax.jdo.option.ConnectionURL、用户名密码、驱动类名三项。元数据是 Hive 的黑匣子连不上时优先查这三项别急着重装。6. 让统计结果可验证对账技巧与一个我常留的习惯平台跑起来只是第一步真正让人信服的是统计结果能对上账。我一般会留一个「对账脚本」用同一批数据在 MySQL 和 Hive 里各算一遍比对总数。如果两边差在千分之一以内说明加载和聚合逻辑没问题差得多就去查分区有没有漏、日期格式有没有混。-- Hive 侧总数 SELECT COUNT(*) AS total FROM ods_disease_report WHERE report_date2024-01-01; -- MySQL 侧总数假设原始数据也导了一份到 MySQL 做对照 SELECT COUNT(*) AS total FROM raw_disease_report WHERE report_date2024-01-01;逻辑说明对账的关键是两边用完全相同的过滤条件。参数上注意 Hive 的COUNT(*)会扫全表大表上跑之前先确认分区裁剪生效。如果两边数字对不上先查 CSV 里有没有带表头行被当成数据加载进去这是最常见的假差异。再进阶一点可以用 Hive 的EXPLAIN看执行计划确认分区裁剪和谓词下推有没有生效。下面这个命令能看出查询扫了哪些分区。EXPLAIN SELECT district, COUNT(*) FROM ods_disease_report WHERE report_date2024-01-01 GROUP BY district;逻辑说明输出里关注Partition部分如果列出了所有分区而不是只有report_date2024-01-01说明分区裁剪没生效通常是 WHERE 条件里对分区字段做了函数运算。参数上hive.optimize.ppdtrue要确保开启谓词下推能把过滤尽量推到 map 阶段减少 shuffle 数据量。我自己的习惯是每建一张新表先灌 100 行测试数据把三类统计 SQL 各跑一遍确认结果和手算一致再灌全量。这个习惯帮我省过好几次「跑了一晚上发现口径错了」的后悔药。疾病数据涉及公共卫生数字错了不是小事宁可前期慢一点也别让报表带着错误上线。希望帮到你。本文还有配套的精品资源点击获取