简介基于Hadoop的疾病信息统计平台是一份面向大数据学习者与Java开发者的完整项目源码重点解决医疗疾病数据从采集、存储到分布式分析与可视化的工程实现问题。压缩包约10.87MB共41个文件以25个Java源文件为核心配合6个XML配置、2个properties配置文件、2个jar包以及yml、arff等辅助文件覆盖Maven工程结构、运行脚本、数据集样本与日志配置等典型模块。目前已有84人学习下载。项目展现出清晰的Hadoop生态整合思路HDFS负责底层存储MapReduce承担并行计算同时可看到HBase实时查询、Hive数据仓库、YARN资源调度等组件的配置痕迹arff文件提供可加载的疾病数据集便于直接运行验证。源码中涉及Java面向对象、多线程、异常处理及MapReduce编程模型适合正在做课程设计、毕业设计或希望上手Hadoop实战的读者参考也可作为搭建类似统计平台的脚手架与排错蓝本。1. 基于Hadoop的疾病信息统计平台拆开压缩包之后先想清楚这三件事如果你拿到的是一份叫基于hadoop的疾病信息统计平台.zip的项目第一反应通常是解压、找文档、看代码。但我建议你先别急着点开先想清楚三件事第一这个平台的核心不是网站界面而是Hadoop集群上的统计计算链路第二疾病信息统计的数据特征是条数多、维度杂、按时间持续累积这正是HDFS加MapReduce/Hive的典型适用场景第三你要交付的不只是能跑的代码而是一套从原始数据到统计报表的完整流水线。这篇文章就按这个思路把环境搭建、表设计、ETL清洗、作业调优到结果落地的整条路走一遍中间标注哪些地方最容易翻车。适合正在做Hadoop课程设计、或者想把大数据技术落到医疗数据统计场景的从业者。2. 为什么疾病统计会选Hadoop数据特征与平台架构拆解2.1 疾病登记数据的四个特征决定了技术选型疾病信息统计跟普通业务系统不一样。普通业务系统是一个用户一条记录查询以点查为主而疾病统计是一段时间内全量记录聚合查询以面查为主。具体拆开看有四个特征第一量大。地市级疾控中心或三甲医院的信息科一天新增的门诊、住院、传染病上报记录可以达到几十万条。放到一个区县级别几年下来就是几亿条。MySQL单表在亿级数据上做 group by 不是不能跑但跑一次全量周报要几分钟甚至更久而且会把业务库的IO拖垮。第二维度多。一张疾病登记表至少涉及病种编码、患者年龄、性别、户籍地、发病地、就诊医院等级、报告日期、确诊日期、转归情况。任何一个维度都可能要单独出统计口径组合起来就是几十组聚合SQL。第三脏数据比例不低。医院HIS系统导出的数据里病种编码有空值、年龄字段出现负数、日期格式不统一、同一患者重复登记这些在真实数据里几乎天天见。第四统计有周期性。日报、周报、月报、季度研判每次都是全量重算。这种批量计算模型跟MapReduce、Hive这种离线批处理引擎天然匹配。基于这四点HDFS做存储层、MapReduce或Hive做计算层、结果物化到MySQL供报表查询是这条技术方向上最常见的成熟方案。不是说MySQL不能做而是在数据量过亿、统计维度又多又杂的场景下Hadoop的横向扩展能力和离线批量计算模型更省心。2.2 平台模块划分采集、存储、计算、服务四层我一般会把一个Hadoop统计平台按职责拆成四层这样不管是写文档还是后面维护边界都很清楚。采集层负责把医院HIS导出文件、上报系统的CSV、手工填报的Excel统一转换成带分隔符的文本文件落到HDFS的原始目录。这个环节可以用Flume监听目录也可以用shell脚本配合hdfs put命令看现场环境而定。存储层是HDFS按日期和数据类型分目录比如 /disease/raw/2025/01/ 下面放原始文件/disease/clean/ 放清洗后的数据。注意HDFS不适合存大量小文件原始文件如果都是一两MB的碎片后面计算会很痛苦这点到第5章避坑部分再细说。计算层用MapReduce或Hive完成清洗去重、维度归并、指标聚合。课程设计阶段用Hive SQL最省时间因为写一遍SQL就能出结果不用像原生MapReduce那样写几百行Java。如果平台里已经接了Tez或者Spark底层引擎可以换但Hive SQL这层对外接口可以保持不变。服务层把计算结果导出到MySQL或者直接生成CSV给报表前端或者BI工具查询。Hadoop这边提供的是批量计算能力不是实时查询所以一定不要想着让前端直接查HDFS延迟和并发都顶不住。2.3 Hadoop组件选型HDFS、YARN、MapReduce、Hive和ZooKeeper的取舍一个完整的Hadoop生态组件可以很多但做疾病统计平台真正离不开的就五个HDFS、YARN、MapReduce、Hive元数据库、ZooKeeper。HDFS负责存原始数据和中间结果YARN负责调度计算资源MapReduce是默认的计算引擎Hive把SQL翻译成MapReduce作业降低统计SQL的编写成本。ZooKeeper分两种情况如果集群是单NameNode的伪分布式或完全分布式ZooKeeper不是必须的但如果要做NameNode高可用也就是两个NameNode一主一备自动切换那就一定要搭ZooKeeper。这里有个常见的认知误区以为Hadoop必须装ZooKeeper才能跑。实际上伪分布式单机环境里不装ZooKeeper完全没问题Hive的元数据默认存Derby或者换成MySQL也行。真正需要ZooKeeper的是YARN ResourceManager HA、HDFS NameNode HA这些场景。如果只是课程设计用单NameNode加一个SecondaryNameNode做检查点备份就够了别把架构搞复杂。组件选型的取舍上我建议是Hive表的元数据库用MySQL不要用Derby。Derby的问题是同一时间只允许一个Hive会话访问元数据你用JDBC跑一次、再用beeline跑一次很可能直接报锁冲突。把元数据库切到MySQL是一劳永逸的做法在后面搭建章节会给出具体配置。3. 在本地把Hadoop跑起来伪分布式环境搭建与第一个统计任务3.1 环境准备JDK版本、免密登录和时钟同步搭建之前先确认基础环境。JDK一定要用Hadoop官方支持版本比如Hadoop 3.3.x配JDK 8或JDK 11。这里踩过坑的人不少JDK版本太高Hadoop的HDFS启动时直接报UnsupportedClassVersionError版本太低又可能遇到Crypto代码的兼容问题。建议装JDK 8稳定省事。第二件事是免密登录。伪分布式虽然只有一台机器但启动脚本默认会用SSH连接localhost启动各个进程不配免密的话启动时会卡住要求输密码。执行# 生成密钥对一路回车即可 ssh-keygen -t rsa -P -f ~/.ssh/id_rsa # 把公钥加到authorized_keys cat ~/.ssh/id_rsa.pub ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys # 验证免密是否生效 ssh localhost echo ok输出 ok 说明免密成功了。这里 -P 表示空密码省略以后SSH不用输密码。注意伪分布式和完全分布式都必须做这一步很多Hadoop启动失败的案例就出在SSH这一步start-dfs.sh 脚本明明已经执行但DataNode一直没有启动去日志里看全是Connection refused。第三件事是时钟同步。虽然单机伪分布式不明显但后面扩到多节点时节点间时钟差超过阈值HDFS会判定节点失联。可以用ntpdate同步一次再配crontab定期同步。疾病统计里时间字段特别重要如果各节点时间不一致按天分区统计时数据可能落到前一天这个隐患很隐蔽。3.2 核心配置文件core-site.xml、hdfs-site.xml、yarn-site.xmlHadoop的配置集中在 etc/hadoop/ 目录下伪分布式最少改三个文件。先看core-site.xmlconfiguration !-- 指定NameNode的RPC地址伪分布式一般就用localhost -- property namefs.defaultFS/name valuehdfs://localhost:9000/value /property !-- HDFS文件系统临时目录需要手动创建并给权限 -- property namehadoop.tmp.dir/name value/data/hadoop/tmp/value /property /configurationfs.defaultFS 是客户端访问HDFS的入口地址端口9000是NameNode的RPC端口别改成8020还是什么的纠结保持默认就行。hadoop.tmp.dir 是元数据存储的根目录一定要手动新建并确保当前用户有写权限Hadoop不会自动创建。再看hdfs-site.xmlconfiguration !-- 伪分布式只有一台机器副本数必须设为1否则DataNode会一直尝试复制到第二个节点 -- property namedfs.replication/name value1/value /property !-- 关闭权限检查开发环境省去chown的麻烦 -- property namedfs.permissions.enabled/name valuefalse/value /property /configuration如果这里不把副本数改成1伪分布式下文件状态会一直是 under replicated虽然不影响读取但每次运行hdfs dfsadmin -report都看到一堆警告。另外dfs.permissions.enabled关掉是给课程设计环境省事生产环境别关。然后是yarn-site.xmlconfiguration property nameyarn.nodemanager.aux-services/name valuemapreduce_shuffle/value /property !-- 给NodeManager分配可用内存单位是MB伪分布式按机器实际内存来 -- property nameyarn.nodemanager.resource.memory-mb/name value8192/value /property /configurationaux-services配成mapreduce_shuffle是让YARN能跑MapReduce作业的必要条件漏配的话作业提交后Container会一直处于INIT状态然后失败。memory-mb的值看机器内存我本地机器是16G内存就给8G给太多会把系统本身的内存挤爆。3.3 HDFS命令集把疾病登记文件传上去配置改完后第一次启动HDFS之前要格式化NameNode。这个操作要谨慎它会在namenode目录下初始化元数据重复执行会清掉旧的元数据信息导致DataNode和NameNode的集群ID不一致后面启动报错。# 格式化NameNode只有首次安装或元数据损坏时才执行 hdfs namenode -format # 启动HDFS和YARN start-dfs.sh start-yarn.sh # 用jps看进程有NameNode、DataNode、ResourceManager、NodeManager就基本正常 jps格式化日志里会出现 Storage directory ... has been successfully formatted看到这句再继续。不要迷信某些教程说每次改完配置都要格式化那是翻车的常见原因——格式化太多次会让DataNode的namespaceID对不上NameNode日志里疯狂报Incompatible clusterIDs。进程起来后把疾病数据文件传上去# 创建HDFS原始数据目录按日期分层管理 hdfs dfs -mkdir -p /disease/raw/2025/01 # 把本地的门诊登记CSV上传到对应日期目录 hdfs dfs -put ./outpatient_202501.csv /disease/raw/2025/01/ # 确认文件落位 hdfs dfs -ls -R /disease/raw上传完成后可以顺手跑一个MapReduce自带的WordCount做冒烟测试确认整个计算链路通不通。但上传的文件如果数据量太小只有几十KBMap任务可能只有1个这是正常的别急着调参数。3.4 用Hive做疾病统计的第一条SQLHive装完以后第一步是把元数据库从默认Derby切到MySQL。做法是在hive-site.xml里配置javax.jdo.option.ConnectionURL、ConnectionDriverName、ConnectionUserName、ConnectionPassword然后在MySQL里建好metastore库和账号。启动Hive初始化# 初始化元数据库结构Derby换MySQL后必须执行一次 schematool -dbType mysql -initSchema # 启动Hive服务然后进入beeline或hive命令行 hive --service metastore hive在Hive命令行里建一张外部表指向HDFS上的疾病原始数据。外部表的意思是Hive只管表结构映射不管数据文件生命周期drop表不会删HDFS文件。这一点在原始数据管理上很重要。CREATE EXTERNAL TABLE IF NOT EXISTS disease_raw ( patient_id STRING, disease_code STRING, disease_name STRING, province STRING, city STRING, age INT, gender STRING, report_date STRING ) ROW FORMAT DELIMITED FIELDS TERMINATED BY , STORED AS TEXTFILE LOCATION /disease/raw/2025/01;建表后跑一条最简单的统计——按省份统计病例数SELECT province, COUNT(*) AS cnt FROM disease_raw GROUP BY province ORDER BY cnt DESC;这条SQL会被翻译成MapReduce作业Map端按province分组Reduce端做计数汇总。如果表里数据量是几十万条跑起来应该一到两分钟就结束。如果卡了很久回去检查YARN的资源参数大概率是内存给少了。4. 疾病统计平台的表设计与ETL从原始登记到可计算的维度表4.1 源数据字段长什么样目标表怎么设计医院或疾控导出的原始登记表常见字段大致是流水号、患者姓名部分脱敏、身份证号、性别、出生日期、年龄、疾病ICD编码、疾病名称、诊断日期、报告日期、户籍省市区、就诊医院名称、医院等级、联系电话之类。真实场景里还会混入备注文本里面什么都有。设计Hive表时我建议把字段分成三类。标识类patient_id、report_no用来去重维度类disease_code、province、city、gender、age_group、hospital_level用来group by事实类report_date、confirm_date用来做时间窗口。不要把备注、详细信息这些自由文本一股脑塞进统计表既占存储又容易在序列化时引入解析错误。年龄字段建议在ETL阶段就换算成年龄分组比如 0-17、18-44、45-64、65及以上。因为在SQL里每次动态算年龄再分组代码重复不说口径分散在各个SQL里后面业务方问一句你们年龄分段标准是什么还得去翻代码。提前物化成一个age_group字段所有统计SQL直接 group by 它口径统一。4.2 建立Hive外部表用日期分区管理增量数据统计平台的数据是持续增长的每天都有新文件上传所以目标表一定要做分区。最常见的就是按天分区分区字段叫dt类型是STRING值就是 yyyy-MM-dd。CREATE EXTERNAL TABLE IF NOT EXISTS disease_clean ( patient_id STRING, disease_code STRING, disease_name STRING, province STRING, city STRING, gender STRING, age_group STRING, hospital_level STRING ) PARTITIONED BY (dt STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY \001 STORED AS TEXTFILE;这里有个细节字段分隔符我用了 \001也就是ASCII的1号控制符。为什么不用逗号因为疾病名称、医院名称这些字段里可能自带逗号用逗号分隔极容易错位。\001在真实文本里几乎不会出现是Hive社区常用的安全分隔符。数据加载时原始CSV要先经过清洗脚本把逗号换成\001再加载进表。建表之后要手动把分区的元数据注册进去# 为dt2025-01-15创建分区 hdfs dfs -mkdir -p /disease/clean/dt2025-01-15 # 将清洗好的数据文件传入分区目录 hdfs dfs -put ./clean_20250115.csv /disease/clean/dt2025-01-15/ # 在Hive中注册分区让表能读到这个目录的数据 ALTER TABLE disease_clean ADD PARTITION (dt2025-01-15);注意顺序先建目录、放文件再ADD PARTITION。如果先ADD PARTITION然后发现文件没传对修复起来更麻烦。Hive不会自动扫描HDFS上新出现的目录除非开msck repair table但手动管理分区更直观尤其在自动化脚本里每一步都可控。4.3 ETL清洗去重、空值、非法日期清洗逻辑是统计平台正确性的生命线。我基于真实落地经验把清洗分成四步每一步在Hive SQL里对应一段明确逻辑。第一步去重。同一患者同一天因同一种疾病可能登记两次按业务规则保留最早一条即可INSERT OVERWRITE TABLE disease_clean PARTITION (dt2025-01-15) SELECT patient_id, disease_code, disease_name, province, city, gender, age_group, hospital_level FROM ( SELECT *, ROW_NUMBER() OVER (PARTITION BY patient_id, disease_code, report_date ORDER BY report_no) AS rn FROM disease_raw ) t WHERE rn 1;这里 ROW_NUMBER() 按 patient_id、disease_code、report_date 分组组内按 report_no 排序rn1 保留的就是同一天同病种的第一条记录。这个写法在数据量几亿的时候会触发一次全量排序但这是必要的去重不做后续所有指标都会虚高。第二步处理空值。病种编码为空或者为NULL的直接算无效数据统计时排除年龄为空且无法推算的归到未知组不要直接丢弃因为业务方想知道到底有多少数据是缺失的。-- 过滤严格无效的数据保留年龄缺失但病种有效的记录 INSERT OVERWRITE TABLE disease_clean PARTITION (dt2025-01-16) SELECT ... FROM disease_raw WHERE disease_code IS NOT NULL AND disease_code ! ;第三步处理非法日期。report_date不是标准格式的要么用正则截取要么直接置NULL。日期错误的数据在按周/月统计时会落到错误的分区这个错误非常隐蔽。第四步统一编码。疾病名称可能有乙肝和乙型肝炎两种写法统计时按ICD编码归并不能按中文名group by。4.4 统计指标口径发病率、地区分布、年龄分层清洗完数据统计SQL就相对简单了。按月统计各地区新发病例数SELECT substr(dt, 1, 7) AS month, province, COUNT(*) AS case_cnt FROM disease_clean WHERE dt 2025-01-01 AND dt 2025-01-31 GROUP BY substr(dt, 1, 7), province ORDER BY month, case_cnt DESC;如果要做发病率需要一张人口基数维度表按省、市、年存常住人口数。发病率 新发病例数 / 该地区人口数 × 100000这是流行病学里常用的十万分率口径。注意人口表是按年更新的Join时要按统计年份关联不要用最新一年的人口数去算过去年份的发病率口径会偏。年龄分层统计也一样直接group by age_groupSELECT age_group, gender, COUNT(*) AS case_cnt FROM disease_clean WHERE dt 2025-01-15 GROUP BY age_group, gender;到这一步平台的统计能力已经打通了。但千万记住一点Hive表里的数据是原始快照不是实时更新的统计结果是否可信取决于ETL清洗规则和分区管理是否严格。这也是为什么下一章要把最常见的故障场景单独拿出来讲。5. Hadoop平台排查与避坑五个让新手翻车的点5.1 NameNode启动失败格式化两次导致的集群ID错乱现象start-dfs.sh 执行后NameNode进程起来了jps也能看到但客户端执行 hdfs dfs -ls / 一直报 Connection refused查看NameNode日志发现 Incompatible clusterIDs。原因安装过程中多次执行 hdfs namenode -format。每次格式化都会重新生成一个集群ID但DataNode首次启动后就把旧集群ID存在自己的data目录里。下一次NameNode用了新集群IDDataNode还用旧ID两边对不上NameNode拒绝让DataNode注册整个集群实际处于半瘫痪状态。解决最稳妥的办法是清空NameNode和DataNode的数据目录也就是hadoop.tmp.dir配置的目录然后只格式化一次再重启。操作前确认数据已备份。# 停掉所有Hadoop进程 stop-dfs.sh; stop-yarn.sh # 删掉元数据和数据目录注意目录路径要和core-site.xml里配置一致 rm -rf /data/hadoop/tmp mkdir -p /data/hadoop/tmp # 重新格式化注意数据会被清空只适合开发环境 hdfs namenode -format start-dfs.sh start-yarn.sh血的教训别一遇到启动失败就格式化。正确顺序永远是先看日志日志在 $HADOOP_HOME/logs/ 目录下hadoop-hdfs-namenode-主机名.log。绝大多数NameNode起不来的问题都是配置路径写错、端口被占或者权限不足格式化是最后手段。5.2 小文件太多导致Map任务数量爆炸现象往HDFS传了上千个几KB的CSV文件跑一次统计SQLMap任务启动了几百上千个每个任务执行时间只有几秒大部分时间浪费在任务调度和启动Container上整个作业跑了很久还没结束。原因MapReduce默认一个文件或一个文件块对应一个Map任务。大量小文件意味着大量Map任务而每个Map任务的启动开销远大于任务本身的执行时间。疾病数据从医院HIS导出时经常一个科室一个文件攒一年就是几千个小文件。解决两个层面。入口层上传前先合并文件把一天的多个CSV合并成一个文本文件再put计算层在Hive里开小文件合并参数-- 控制Map输入合并让多个小文件合并成一个分片 SET hive.input.formatorg.apache.hadoop.hive.ql.io.CombineHiveInputFormat; -- 控制Map端输出小文件合并 SET hive.merge.mapfilestrue; SET hive.merge.size.per.task256000000;第一行参数最关键CombineHiveInputFormat会把同一目录下多个小文件合并成一个逻辑分片Map任务数从几百降到个位数。后面两个是Hive在作业结束时合并输出小文件的参数target大小按256MB设置。这也是为什么我在前面强调原始目录按日期分层因为EASILY合并时按目录处理最顺手。5.3 中文乱码Hive表字段和源文件编码不一致现象从CSV导入的数据查询时中文全部显示为乱码或者统计出来的省份名称是????。原因源CSV文件是GBK编码而Hive表默认按UTF-8解析两边不一致导致字节解析错误。解决第一步把源文件统一转码后再上传这是最彻底的办法。用iconv命令# 把GBK编码的文件转成UTF-8避免Hive读取时乱码 iconv -f GBK -t UTF-8 ./outpatient_20250115.csv ./outpatient_20250115_utf8.csv第二步是建表时显式声明字符集。如果是外部表配合MySQL元数据库还要确认MySQL的连接参数里 characterEncoding 配成 utf8否则Hive的元数据里的注释、分区信息也会乱。第三步是如果数据已经进HDFS了不要指望Hive能把脏数据变干净得从源头清洗重跑。这里有个很多人忽略的细节用OpenCSVSerde还是LazySimpleSerDe。OpenCSVSerde天然处理CSV里的引号转义但对编码的处理能力和普通SerDe一样都要源文件编码正确。不要以为换了SerDe就能解决乱码治本还是统一转UTF-8。5.4 数据倾斜按地区统计时单个Reduce卡死现象一条统计SQL99%的Map任务都跑完了但有一个Reduce任务长时间卡在99%作业迟迟不结束。日志显示某个Reduce吸收了上千万条key。原因数据分布不均。比如按省份统计病例数时某些人口大省的病例数可能是小省的几十倍Hash分区把大量key分到同一个Reduce这个Reduce成为瓶颈。疾病统计里某些高发病种或特定地区的key倾斜尤其严重。解决第一招给倾斜的key加随机前缀打散统计完再去掉前缀。比如按省份统计时对省份字段拼接一个随机数SELECT province, SUM(case_cnt) AS total_cnt FROM ( SELECT case when province XX省 then concat(province, _, floor(rand()*10)) else province end as province, COUNT(*) AS case_cnt FROM disease_clean WHERE dt 2025-01-01 GROUP BY province, CASE WHEN province XX省 THEN concat(province, _, floor(rand()*10)) ELSE province END ) t GROUP BY province;内层先把热点省份的数据随机拆成10份分别聚合外层再汇总一次。注意rand()乘以10的范围决定了拆分的份数热点越严重这个数值越大。第二招是调整Reduce个数set mapreduce.job.reduces200 把数据分散到更多Reduce上缓解但不根治。第三招是用Hive的SKEW JOIN hint但那是针对Join场景的group by倾斜仍然得靠加盐手法。血泪经验数据倾斜不会在测试环境暴露因为测试数据量小且均匀生产数据一上来就现原形。设计阶段就要评估团伙key的体量差异。5.5 YARN容器被kill内存参数配置不合理现象作业提交后Container反复被NodeManager杀死日志报 Container killed on request. Exit code is 143 或者物理内存超限。原因YARN的虚拟内存检测或物理内存检测把容器杀掉了。伪分布式下最常见的情况是机器物理内存16G给NodeManager的resource.memory-mb配了12G同时预留的内存不足系统内存吃紧后NodeManager开始杀Container。另一个原因是mapreduce.map.memory.mb和reduce内存参数没配MapReduce默认的1G内存跑大文件时不够。解决先把总预算算清楚。NodeManager的可用内存不能超过物理内存减去系统运行所需通常留25%-30%给系统。然后按比例配Map和Reduce内存# yarn-site.xml中NodeManager可用内存给物理内存的70%左右 # mapreduce配置中Map任务内存给1-2GReduce任务给2-4G在mapred-site.xml中property namemapreduce.map.memory.mb/name value1536/value /property property namemapreduce.reduce.memory.mb/name value3072/value /property !-- 关闭虚拟内存检测开发环境常用手段 -- property nameyarn.nodemanager.vmem-check-enabled/name valuefalse/value /property虚拟内存检测关掉能解决一部分莫名被kill的问题因为JVM在Linux上占用的虚拟内存常常远超物理内存检测一开就容易误杀。但关闭检测只是治标Map和Reduce实际所需内存得根据数据量调。一个小技巧一个Map任务默认处理128MB数据如果每个Map都处理大量复杂计算1536MB不够就提到2048MB或更大同时保证NodeManager的总量能覆盖所有并发任务的和否则内存会超卖。6. 结果物化、调度与校验把统计结果交到业务手上6.1 把Hive统计结果导出到MySQLHadoop这边的统计结果在HDFS上业务系统不会直接来查。常见的落地做法是用Sqoop把Hive表或者指定查询结果导出到MySQLsqoop export \ --connect jdbc:mysql://localhost:3306/disease_report \ --username root --password ****** \ --table stats_month_province \ --export-dir /disease/result/month_province \ --fields-terminated-by \001 \ --batchexport-dir指向的是Hive结果表在HDFS上的目录--fields-terminated-by必须跟Hive表的分隔符一致。如果环境里没有Sqoop就退一步把结果INSERT OVERWRITE到一个指定目录然后用 hdfs dfs -getmerge 合并下载再用mysql客户端load进去。Sqoop导出时最常见的问题就是MySQL表字段顺序跟结果文件列顺序不一致导出前先用一条同名SQL查一下结果目录的文件头确认列顺序再执行。6.2 定时调度crontab加shell脚本是零成本方案疾病统计的日报月报是周期性任务。生产环境可以用Apache Airflow或者DolphinScheduler做可视化调度但课程设计或小团队场景crontab加一套shell脚本反而更实用没有额外组件要维护。# 每天凌晨2点跑前一天的数据ETL和统计 0 2 * * * /home/hadoop/bin/run_disease_report.sh脚本内部按四步走上传原始文件到HDFS分区调用Hive SQL跑清洗调用统计SQL生成结果表调用Sqoop导出到MySQL。每一步结束后检查退出码失败就写日志并退出避免出现上游失败了下游跑出空结果的连锁问题。6.3 结果校验不要相信第一次跑出来的数字平台上线前一定要做结果校验。我的做法是选两个已知结果的月份比如某地区官方发布的月度发病数用平台重算一遍对不上就查口径差异。另外随机抽某个分区数据用原生SQL在MySQL里手工group by一遍跟Hive结果做diff。Hadoop平台最容易出的问题不是算错而是口径不一致比如去重逻辑改了但老分区的数据没有重跑导致月度累加和日报对不上。我个人的习惯是每个统计结果表都带一个run_date字段记录生成该结果的批次日期任何时候重算都写入新的分区不覆盖旧结果。这样业务方看到哪个批次跑出来的数据回溯也有据可查。这套习惯帮我挡过不止一次数据对不上的质疑。希望帮到你。本文还有配套的精品资源点击获取