1. 项目概述：这是一个什么样的系统
1.1 航班分析系统要解决什么问题
做这个项目之前，我先问了自己一个问题：航空公司每天产出海量航班数据，但真正能把这些数据用起来的人有多少？答案是很有限的。航班准点率、航线热度、延误原因分布、高峰时段分析，这些指标如果只靠Excel或者单机数据库来处理，一旦数据量到百万级，查询就会慢得让人抓狂，更别说做多维度的关联统计了。
Hadoop和航班分析系统放到一起，核心目的就是解决三个问题：一是海量航班数据的分布式存储，让几十GB甚至TB级的数据不再依赖单块硬盘；二是批量计算能力，通过MapReduce和Hive把过去跑几个小时的统计任务压到分钟级别；三是一套可复用的分析流程，把原始航班数据清洗、入库、统计、展示全链路打通，而不是今天写一个脚本明天写一个脚本，结果谁都不知道数据口径是什么。
这个项目适合的人群比较明确：正在做大数据课程设计的学生、准备大数据方向毕业设计的同学、以及刚接触Hadoop生态想找一个完整落地案例的初级开发。它不是那种只讲概念的PPT项目，而是真正能在你机器上跑起来、能看到统计结果、能给你面试时讲清楚细节的完整系统。做完这个项目，你对HDFS、MapReduce、Hive、HBase这些组件的理解会从“背面试题”变成“我真的用过”。
1.2 系统功能范围和适用场景
整个系统我最终敲定的功能范围包括五大块：数据采集与上传、数据预处理、离线统计分析、结果存储、可视化展示。
数据采集这一块，用的是公开的航班数据集（CSV格式），通过脚本上传到HDFS；预处理环节做了脏数据过滤、字段补齐、格式统一；离线统计是重头戏，包括航班准点率、平均延误时长、航线流量Top10、机场吞吐量、月度延误趋势等指标；统计结果写入HBase和MySQL，其中HBase负责存明细和键值类结果，MySQL存最终报表数据；可视化层用Spring Boot提供接口，前端用ECharts画柱状图、折线图和地图热力图。
这套设计的好处是每一层都能单独替换。比如你不想用HBase，可以把结果全部落到MySQL；不想写Java Web可视化，可以用Hue或者Grafana直接连Hive。我第一次做的时候就是先跑通了Hive统计，再用最笨的Hue看结果，最后才补的可视化，这样每一步都有阶段性产出，不会到最后才发现自己统计口径错了。
1.3 技术栈选型：为什么是Hadoop而不是其他方案
很多人问过我：处理几百万行航班数据，MySQL加上索引完全够用，为什么非要上Hadoop？这个问题问得对，但如果你的数据量不是几百万而是几亿条，比如把过去十年全球航班数据全部导入，那单机的瓶颈就出来了。更重要的是，这个项目的定位本来就不是“最佳性能方案”，而是“大数据技术栈的综合演练”，它的目的是让你把分布式存储、分布式计算、数据仓库这些概念真正在项目中用一遍。
在具体组件选择上，HDFS负责底层存储，把文件切块分布到多台机器，这样单个文件超过磁盘容量也能存下；MapReduce负责实现自定义统计逻辑，特别是那些SQL不好表达的复杂处理；Hive负责把SQL翻译成MapReduce任务，适合快速做日常统计分析；HBase提供随机读写能力，用来支撑查询延迟要求较高的场景。四个组件各司其职，对应了大数据处理链路中最典型的几种角色。
有一点我要特别说明：Hadoop生态的组件非常多，Flume、Kafka、Spark、Flink各有各的用处，但一个课程设计级别的项目没必要全部塞进去。能用最少的组件把链路跑通，并且能讲清楚每个组件在这里面承担什么角色，比堆砌一堆框架名次要实在得多。
2. 整体架构与数据流设计
2.1 系统分层架构和关键设计思路
整个系统的架构，按数据流动方向可以划分为五层：数据源层、存储层、计算层、服务层、展示层。数据源层是航班CSV原始文件；存储层有三块，HDFS存原始文件和中间结果，HBase存需要随机查询的统计明细，MySQL存最终报表；计算层由MapReduce任务和Hive SQL组成；服务层就是Spring Boot写的REST API；展示层是浏览器端的ECharts页面。
这个架构不是拍脑袋定的，它反映了一个很实际的数据处理流程：原始数据先原封不动落到HDFS，这是“数据湖”的思路，不管你以后想算什么指标，原始数据都在；计算层负责把原始数据变成结构化结果，这一步是“数据仓库”的过程；最终结果放到查询友好的存储里给应用层使用，这是“数据集市”的定位。这样分层之后，每一层之间只通过数据文件或表结构交互，耦合度很低。
图就不画了，我用文字描述一下数据流向，你理解了这个顺序，后面每一步就都有位置感了。航班CSV文件在本地生成后，用hdfs dfs -put命令上传到HDFS；然后写MapReduce任务做清洗和指标计算，输出结果到HDFS的指定目录；接着在Hive里建表，通过LOAD DATA INPATH将HDFS上的结果载入Hive表；Hive SQL继续做多维度统计，结果导出到MySQL或者HBase；最后Spring Boot读取MySQL和HBase的数据，前端页面通过接口拉取数据绘图。我用的HBase部分存储了日航班明细，用航班号加日期作为RowKey，这样按航班号查历史记录时基本是毫秒级返回。
2.2 核心指标口径设计
做数据分析项目最容易踩的坑就是指标口径不统一。同一个“准点率”，有人按起飞时间算，有人按到达时间算，还有人把取消航班也算进去，结果完全不一样。所以在动手写代码之前，我先把指标口径用文档固定下来。
这个项目我定义了以下核心指标：准点率等于准点航班数除以总航班数乘以100%，其中准点定义为实际起飞或到达时间比计划时间晚不超过15分钟（国内通行的标准口径）；平均延误时长只计算有延误的航班，不包括提前到达的航班；航线流量按起飞机场到到达机场的配对统计，双向航线视为同一条航线。最容易被忽略的一点是时区问题，航班数据里记录的往往是当地时间，如果你把不同时区的数据混在一起统计，结果就会错得离谱。我在预处理阶段统一转成UTC时间存储，展示的时候再转回本地时区，这个细节让我避免了很多莫名其妙的Bug。
2.3 目录结构与数据分区规划
HDFS上的目录规划我在项目一开始就定了规矩，不然文件一多就会变成一团乱麻。我的目录结构是这样的：/flightdata/raw存放每次上传的原始CSV文件，按日期分子目录，比如/flightdata/raw/2025-01-15/；/flightdata/cleaned存放清洗后的数据，按年和月再分一层；/flightdata/output存放MapReduce的统计结果；Hive的外部表指向这些目录，而不是把数据复制到Hive自己的仓库目录，这样HDFS上的文件只有一份，不会浪费存储。
分区策略上，Hive表按照year、month、day三级分区，查询某一天的数据时只需要扫描对应分区，极大减少了全表扫描的开销。需要注意的是HDFS不适合存大量小文件，每个文件的block大小是128MB，如果你存一万个几KB的小文件，NameNode的压力会非常大。我当时的做法是尽量合并CSV文件再上传，小文件先在本机用命令合并成大文件，或者上传后用Hive的INSERT OVERWRITE重写一次来合并小文件。
3. Hadoop环境准备与集群搭建
3.1 环境规划与版本选择
做这个项目之前，环境搭建是最劝退新手的环节，因为网上教程版本参差不齐，照着做一半就报错，心态很容易崩。我给出的建议是：先想清楚是三台机器做完全分布式，还是一台机器做伪分布式。如果只是课程设计交差、跑通流程，伪分布式足够；如果真想模拟生产环境、体验DataNode挂掉对集群的影响，至少准备三台虚拟机，Master节点跑NameNode和ResourceManager，两台Slave节点跑DataNode和NodeManager。
版本选择我用的是自己实际跑通的组合：Linux用CentOS 7.9，JDK用1.8（不要用太高版本，很多组件对JDK版本敏感），Hadoop用3.3.x版本，Hive用3.1.x版本，HBase用2.4.x版本，ZooKeeper用3.7.x版本。这里有个经验是Hadoop和Hive的版本要兼容，Hive 3.1.x和Hadoop 3.x搭配是经过大量验证的稳定组合。MySQL用5.7版本，作为Hive的元数据库和最终结果存储。
虚拟机配置方面，每台机器分配2核CPU、4GB内存就够了，不要贪多，一台笔记本带三台虚拟机火力全开会卡到你怀疑人生。所有节点之间配置SSH免密登录，这是必须的第一步，否则每次启动集群都要输密码。
3.2 从零搭建完全分布式集群的关键步骤
很多教程把搭建过程写成了“复制粘贴命令”就能完成的事，但实际执行时每个环节都可能有坑。我把关键步骤和容易出错的地方列一下：
第一步是修改每台机器的主机名和/etc/hosts文件，保证互相之间能通过主机名通信。这里经常有人踩坑的是只修改当前机器而不注意其他机器上的hosts也要同步，导致DataNode启动后连不上NameNode。
第二步是JDK安装和环境变量配置。JDK的安装路径不要带空格和中文，JAVA_HOME要写绝对路径，并且在/etc/profile里export。
第三步是Hadoop的配置文件修改，核心是core-site.xml、hdfs-site.xml、yarn-site.xml、mapred-site.xml四个文件。core-site.xml里配置NameNode的地址；hdfs-site.xml里配置副本数（三台机器就设3）、NameNode的namenode目录和datanode目录；yarn-site.xml里配置ResourceManager的地址，还要注意设置yarn.nodemanager.vmem-check-enabled为false，否则虚拟内存超限会频繁杀掉Container；mapred-site.xml里指定用YARN作为MapReduce的运行框架。
第四步是格式化NameNode。这一步执行hdfs namenode -format之前一定要确认HADOOP_HOME环境变量已经正确设置。格式化完成后，目录结构就已经生成了，反复格式化是不推荐的，会导致DataNode的clusterID和NameNode不一致，启动时报错。如果确实需要重新格式化，记得同时删除所有节点的name和data目录再重建。
第五步是启动集群，先启动HDFS再启动YARN，用jps命令检查各节点的进程是否正常。
我实操中最常遇到的情况是：NameNode进程起来了，DataNode没起来。排错顺序一般是先看日志文件/usr/local/hadoop/logs/hadoop-hadoop-datanode-xxx.log，十有八九是clusterID不一致，解决办法是检查dfs.namenode.name.dir下current/VERSION里的clusterID和DataNode的VERSION是否相同，不同就改成一致。
3.3 Hadoop集群的关键配置参数清单
我整理了一份配置参数清单，你按这份配置基本能一次跑通。注意Hadoop 3.x的默认端口是9870（NameNode Web UI），如果访问不了先查防火墙再查端口占占用。
在core-site.xml里主要配置fs.defaultFS为hdfs://master:9000，以及临时文件目录hadoop.tmp.dir。在hdfs-site.xml里，副本数dfs.replication设为节点数，NameNode和DataNode的目录单独建。如果虚拟机磁盘只有20GB，建议把dfs.blocksize调小到64MB，这样小文件也能占用完整的块语义，做实验时更直观。
YARN的资源分配上，如果你只是跑MapReduce任务，把yarn.nodemanager.resource.memory-mb改为2048，yarn.scheduler.maximum-allocation-mb也改成2048，给每台虚拟机留出足够的内存给操作系统和HDFS。不然的话，默认配置会尝试申请8GB内存，小机器直接被资源不足的报错卡死。
3.4 伪分布式模式适合什么场景
如果你的机器配置实在带不动三台虚拟机，伪分布式是完全可以接受的。伪分布式的意思是在单台机器上同时运行NameNode、DataNode、ResourceManager、NodeManager，每个进程都是一个独立的Java进程，但共享一台机器的资源。
伪分布式模式下有一件重要的事：副本数一定要设为1。如果你保持默认的3，数据会因为只有一台DataNode而持续处于副本不足状态，NameNode会一直打印告警。另外伪分布式的hdfs-site.xml里dfs.replication设为1，然后启动后存放数据时要注意HDFS的文件路径和本地文件系统路径的区别，很多新手会把hdfs dfs -put localfile /user/data写成put localfile加本地路径，导致文件根本不在HDFS上。
4. 数据源获取与预处理
4.1 航班数据集字段设计
我用的航班数据集是从公开数据源整理的，模拟了一份包含约120万条记录的旅客航班数据，格式是CSV，每条记录包含：航班号、航空公司、起飞机场（三字码）、到达机场（三字码）、计划起飞时间、实际起飞时间、计划到达时间、实际到达时间、飞行距离、延误原因、航班状态（正常/取消/备降）。这些字段覆盖了后续做准点率、延误、航线流量统计所需的全部维度。
字段的实际格式长这样：CA1831,中国国际航空,PEK,SHA,2025-01-15 08:00:00,2025-01-15 08:12:00,2025-01-15 10:20:00,2025-01-15 10:45:00,1080,天气,正常。看到这里你应该就明白了，这个项目的重中之重是时间字段的处理，后面清洗环节很大一部分工作都是解析各种时间格式。
4.2 CSV数据入库HDFS的完整流程
数据准备阶段，我用脚本模拟生成CSV文件，为了避免HDFS小文件过多的问题，每500万条合并成一个文件。上传操作是通过命令行完成的：先创建目录，再上传，最后检查文件是否完整。
hdfs dfs -mkdir -p /flightdata/raw/2025-01 hdfs dfs -put /home/user/data/flight_202501.csv /flightdata/raw/2025-01/ hdfs dfs -ls -lh /flightdata/raw/2025-01/注意一点：hdfs dfs -put上传时会做数据切块和冗余复制，所以上传速度取决于网络和副本数。三台机器都在本机跑的话，上传1GB文件大概需要几十秒到几分钟。上传完成后，用hdfs dfs -cat查看前几行确认数据没有损坏，这对后面做MapReduce很重要。
4.3 数据清洗策略：去重、格式统一、脏数据过滤
原始数据质量是影响分析结果的核心因素。我的清洗任务通过MapReduce完成，清洗逻辑包括：
时间的标准化。原始数据里有2025-01-15 08:00、2025/1/15 8:00、2025-01-15T08:00:00Z各种格式，统一用SimpleDateFormat解析为yyyy-MM-dd HH:mm:ss，解析失败标记为脏数据。
航班号的规范化。把全角字母数字统一转半角，例如ＣＡ１８３１转成CA1831，并把统一大小写。
停用和取消航班处理。航班状态为取消的，时间字段是空的，这类记录不做丢弃，单独打上标记，在统计准点率时区分处理，如果不加区分会导致准点率被虚高。
去重逻辑基于航班号加计划起降时间作为唯一键，重复记录保留第一条并输出一条告警日志到WARN文件。我用了一个计数器来追踪清洗率，MapReduce框架自带的Counter可以统计输入记录数和输出记录数，一眼就看出清洗掉了多少数据。
我用MapReduce做清洗，还有一个很重要的原因：MapReduce天然并行处理HDFS上的大文件，洗120万条记录在集群上也就一两分钟，比单脚本跑快得多。
5. 系统核心实现
5.1 MapReduce实现航班延误统计的完整代码拆解
MapReduce任务是本项目的重头戏，我需要实现的是统计每条航线的平均延误时间。整个Job分为Mapper和Reducer两个阶段。在Mapper阶段，逐行读取CSV，解析字段后以“起飞机场_到达机场”作为输出的Key，以延误时间作为Value；在Reducer阶段，对同一航线的延误时间求和后取平均值。
下面这段是Mapper的核心代码，我加了详细注释，方便你对照跑。
public class FlightDelayMapper extends Mapper<Object, Text, Text, DoubleWritable> { private Text routeKey = new Text(); private DoubleWritable delayValue = new DoubleWritable(); @Override protected void map(Object key, Text value, Context context) throws IOException, InterruptedException { String[] fields = value.toString().split(","); if (fields.length < 9) { return; // 字段不足，跳过脏数据 } String flightNo = fields[0].trim(); String depAirport = fields[2].trim(); String arrAirport = fields[3].trim(); String planDepTime = fields[4].trim(); String actualDepTime = fields[5].trim(); String status = fields[8].trim(); // 只统计正常运行且实际起飞时间有效的航班 if ("正常".equals(status) || "延误".equals(status)) { try { SimpleDateFormat sdf = new SimpleDateFormat("yyyy-MM-dd HH:mm:ss"); long planTime = sdf.parse(planDepTime).getTime(); long actualTime = sdf.parse(actualDepTime).getTime(); long delayMinutes = (actualTime - planTime) / 60000; routeKey.set(depAirport + "_" + arrAirport); delayValue.set(delayMinutes); context.write(routeKey, delayValue); } catch (ParseException e) { // 时间解析失败，忽略该条记录 } } } }Reducer这边，逻辑非常简单，就是把同一航线的所有延误时间加起来求平均。这里有一个重要的优化点：如果你现在执行这个任务，数据量只有120万条，Reducer的输入数据量不大，但如果数据量上亿，就需要在Mapper后面增加一个Combiner，先在每个Map节点本地做一次求和，减少shuffle阶段的数据传输量。
Combiner的实现代码和Reducer几乎一样，只要设置job.setCombinerClass(FlightDelayReducer.class)。这样做能显著降低网络IO，我在这个项目里实际测过，加了Combiner之后整体任务时间缩短了差不多30%。你也可以在Reducer阶段做更复杂的统计，比如分别统计平均延误时间和延误率，只需要自定义一个自定义对象作为Value，在Reducer里维护两个累加器。
5.2 Hive数据仓库构建与统计分析SQL
MapReduce适合做特定逻辑的ETL和统计，但如果要灵活地多维度分析，用Hive更方便。Hive的原理是把SQL翻译成MapReduce作业，所以比手写Java要灵活得多，但这也是它慢的原因。
我先创建一张外部表，指向HDFS上的清洗后数据。因为数据是CSV格式，我建表时指定了行分隔符和字段分隔符，注意这里有个常见的坑：CSV字段内如果含有逗号（比如某些原因描述字段），直接按逗号分割会导致字段错位。我生成数据时专门避开了这个坑，用制表符作为字段分隔符。
CREATE EXTERNAL TABLE flight_clean ( flight_no STRING, airline STRING, dep_airport STRING, arr_airport STRING, plan_dep_time STRING, actual_dep_time STRING, plan_arr_time STRING, actual_arr_time STRING, distance INT, delay_reason STRING, status STRING ) PARTITIONED BY (year STRING, month STRING, day STRING) ROW FORMAT DELIMITED FIELDS TERMINATED BY '\t' STORED AS TEXTFILE LOCATION '/flightdata/cleaned';建表之后，需要执行分区恢复命令，让Hive元数据里出现分区信息。如果你直接把文件传到HDFS上然后查询，会发现没有数据，就是因为还没有执行MSCK REPAIR TABLE flight_clean;，执行完就能识别到日期目录下的文件了。
分区表建好以后，统计准点率就变成了一条简单SQL。准点的定义是实际到达时间比计划到达时间晚不超过15分钟，这个口径和民航局公布的数据口径是一致的。SQL写法是把小时差精确算出来：用unix_timestamp函数把时间字符串转成秒数，然后计算差值除60得到分钟数，再做条件判断。
SELECT dep_airport, arr_airport, SUM(CASE WHEN (unix_timestamp(actual_arr_time) - unix_timestamp(plan_arr_time)) / 60 <= 15 THEN 1 ELSE 0 END) * 100.0 / COUNT(*) AS punctuality_rate FROM flight_clean WHERE status = '正常' GROUP BY dep_airport, arr_airport ORDER BY punctuality_rate DESC LIMIT 10;执行这条SQL时有一点需要注意：Hive默认会把COUNT(*)当成整型，和一整列比较会出现类型不匹配的警告，建议用CAST(COUNT(*) AS DOUBLE)来转换。另外，如果做多条件分组统计，SQL变得复杂，可以依赖Hive的分区裁剪，比如SQL的where条件中带上year='2025' and month='01'这样的过滤条件，Hive在生成MapReduce任务时就会跳过已经不满足条件的分区文件，大幅减少扫描量。
5.3 HBase表设计和数据导入实战
HBase在系统里的定位是存储近期的航班明细数据，提供按航班号查询历史记录的能力。为什么不用Hive来支撑这个场景？因为Hive的查询延迟是秒到分钟级别的，而HBase的单行查询是毫秒级，对用户来说体验完全不同。
HBase表设计的关键是RowKey的设计，这一点直接决定性能。我用的RowKey规则是：倒置航班号加日期时间，比如航班号CA1831、日期2025-01-15，存储的RowKey是1831CA_20250115。倒置航班号的原因是为了让同一个航空公司的航班记录在RowKey前缀上尽量分散，避免所有写入都打在同一个Region上形成热点。如果按原来的航班号作为前缀，同一个航空公司的航班就会连续写入同一个Region，只有一台机器处理请求，其他机器空闲。
建表时预分区也很重要。我先预估了数据量，10个Region就够了，于是把HBase表按16进制前缀0_到f_预先划分为16个Region，避免了自动分区的热点问题。下面这段是建表Shell脚本：
create 'flight_detail', {NAME => 'info', VERSIONS => 1, COMPRESSION => 'SNAPPY'}, {NUMREGIONS => 16, SPLITALGO => 'HexStringSplit'}数据写入环节，我写了一个Java类读取Hive清洗结果，批量写入HBase。写入方式用HBase的Put对象，启用了自动Flush的批量提交，在客户端设置setWriteBufferSize(6MB)再flushCommits()。小批量写入的配置写起来比较容易，但是如果每条都调用一次put然后flush，写入速度会慢到无法接受。这个项目里写入100万条记录，批量提交大概用了几分钟，单条提交则要四十多分钟，差距巨大。
HBase查询的时候，Shell里可以快速验证：get 'flight_detail', '1831CA_20250115'，能看到这一航班当天的详细信息。如果要按时间范围扫描某一天的所有航班，可以用scan配合startRow和stopRow，因为RowKey里含日期，范围扫描可以精确落到指定日期区间。
5.4 可视化展示：从数据到图表
最后一步是把统计结果展示给用户。项目前端采用ECharts，后端用Spring Boot提供REST接口，接口从MySQL和HBase中读取数据并返回JSON，前端用Ajax拉取并渲染图表。这样做的好处是后端可以换成任何你熟悉的技术栈，比如Flask、Node.js都行，关键是前后端通过接口解耦。
页面设计我做了三个模块：第一个模块是总览面板，展示某个月的总航班量、准点率、平均延误时间这几个核心数字；第二个模块是航线分析，用柱状图展示准点率最高的Top10航线和流量最大的Top10航线；第三个模块是延误原因占比，用饼图展示天气、航空管制、机械故障等各类原因的比例。
最麻烦的是地图热力图。ECharts的地图组件需要GeoJSON格式的国内机场坐标数据，我用了公开的机场坐标数据，并把它映射到省份，然后根据吞吐量填充颜色。这个功能对展示效果提升非常明显，你会看到珠三角、长三角和京津冀三个区域的颜色明显比别的地方深，一眼就能看出哪些地区是航空流量核心区。
6. 项目常见问题与排查技巧实录
6.1 MapReduce任务的典型报错
先说一个出现频率最高的报错：提交作业时提示jar does not exist or is not a normal file: /usr/local/hadoop/share/hadoop/m...。这个问题我见过很多次，也帮同学排查过很多次，原因在于执行hadoop jar命令时，参数写法不对或者路径写错了。正确格式是hadoop jar 你的jar包路径 主类名，不要把主类名放在jar包前面，也不要在jar包路径里带上相对路径。如果你是用yarn jar提交的，也要注意同样的问题。遇到这类报错，直接ls -l看看jar包是否存在、权限是否可读，先把低级问题排除掉。
第二个经典问题是Container内存超限，报错信息类似Container [pid=xxxx] is running beyond virtual memory limits。这是因为YARN对每个Container有虚拟内存限制，而虚拟机本身物理内存不大，默认比例反而会误杀。解决办法是在yarn-site.xml中设置yarn.nodemanager.vmem-check-enabled为false（我前面提过），或者调大yarn.nodemanager.vmem-pmem-ratio到10。生产中建议保留检查，但自己练习的集群直接关掉更省事。
第三个是Reduce阶段数据倾斜。统计航线流量时，如果某些航线（比如北京到上海）航班量特别多，单个Reducer要处理的key数量远大于其他Reducer，整个任务卡在最慢的那个Reducer上。解决办法有两个思路：加一个随机前缀把key先打散做一轮局部聚合并；或者改用Hive，用GROUP BY时开hive.groupby.skewindata=true，Hive会自动做两轮聚合。这个场景我强烈建议你用Hive，因为手写MapReduce处理数据倾斜要写很多代码，而Hive一个参数就解决了。
6.2 HDFS和Hive的坑
HDFS最常见的两个问题，一个是启动后DataNode起不来，查日志发现clusterID不一致，解决办法是把DataNode目录下的VERSION和NameNode下的VERSION改成一致，或者把两边的data目录都清了重新格式化。另一个是磁盘空间满了，NameNode会自动进入安全模式，表现为上传文件时报Cannot create file... NameNode is in safe mode。这时候用hdfs dfsadmin -safemode leave可以强制退出，但最好是清理磁盘上不需要的临时文件。
Hive这边，最常见的坑是连不上元数据库，报Unable to instantiate org.apache.hadoop.hive.ql.metadata.SessionHiveMetaStoreClient。检查顺序：MySQL服务有没有启动，hive-site.xml里连接配置的用户名密码对不对，网络能不能通。如果是在伪分布式或者单机环境，记得先启动hive --service metastore，然后另开终端使用hive命令，我第一次就是因为没启动metastore服务，折腾了一下午。
6.3 数据统计结果不对的排查思路
程序没报错，但统计结果明显不合理，这种情况比报错更让人崩溃。我总结了一套排查顺序：先查输入数据是否有脏数据，比如时间和延误时长有没有负数；再查SQL和MapReduce的统计口径是否一致，比如一个用了到达延误，另一个用了起飞延误；最后查是不是有重复统计，比如同一份数据被重复加载。
举个例子，我早期统计平均延误时间时，发现结果比民航公布数据高出很多。后来检查发现是把备降航班也算进去了，备降航班的延误时间经常是好几个小时，直接拉高了平均值。修正方法是在统计SQL里加入AND status != '备降'条件，结果一下就正常了。这种问题，光靠代码查不出来，必须去看数据样本。
6.4 伪分布式环境资源不足的应对方案
很多人在自己电脑上跑伪分布式，最头疼的问题是内存不足。NameNode默认堆内存1GB，DataNode默认1GB，ResourceManager和NodeManager各1GB，加上Hive的metastore，一台8GB内存的机器根本跑不动。我的应对方案是调低各组件的内存参数。
Hadoop的hadoop-env.sh里设置HADOOP_NAMENODE_OPTS=-Xmx512m，DataNode设成256m；YARN的yarn-env.sh里设置YARN_RESOURCEMANAGER_OPTS=-Xmx512m和YARN_NODEMANAGER_OPTS=-Xmx256m。Hive的HIVE_HEAPSIZE默认是1024，调成512。这样整套集群跑起来内存占用控制在4GB左右，日常写代码和跑任务都不卡。
6.5 生产环境和企业项目中的进阶注意事项
课程设计你可以用最简配置把项目跑通，但如果你把这个项目当作面试项目来介绍，最好还能说出一些面向生产的思考。
生产环境中，数据导入HDFS阶段通常不是用hdfs dfs -put直接传，而是通过Flume采集日志数据实时落入HDFS，或者用Sqoop从关系型数据库导入数据，数据流是自动化的。生产环境中也不会有人工执行MapReduce任务，而是使用AzKaban或Apache DolphinScheduler做工作流调度，每天自动跑数据清洗和报表生成。你可以在项目文档里提一下“当前系统通过手动命令或者脚本定时触发，DolphinScheduler作为后续扩展方向”，这比硬编一个不上线的调度框架要有说服力得多。
生产环境还有一个重要差异是数据压缩。Hive建表时，生产几乎不用TEXTFILE，而是用ORC或Parquet格式，配合SNAPPY压缩。同样的数据量，TEXTFILE存了1GB，ORC格式压缩下来大概400MB，查询速度也提升好几倍。我后来把这个优化加进去，数据的存储成本直线下降，压缩后查询性能也上来了，具体做法就是在建表语句里STORED AS ORC加TBLPROPERTIES ('orc.compress'='SNAPPY')。
7. 项目扩展方向和优化思路
项目本身跑通只是第一步，如果你想让这个项目在面试中更有亮点，这里有几个经过验证的扩展方向。
实时计算方向。现在Hadoop离线分析处理的是历史数据，但是航班数据本身是持续产生的，可以考虑引入Kafka加Flink做实时数据处理。业务场景是实时监控当前航班的准点状态，一旦某个航班延误超过2小时就触发告警推送。Flink从Kafka消费航班实时动态，然后在内存窗口内计算准点率，写入Redis供前端展示。这个扩展能体现你掌握了流批一体思路，比单纯做离线项目加分不少。
OLAP方向。如果面试岗位偏数据分析，可以加一层ClickHouse或者Doris，把Hive中计算好的结果同步到OLAP引擎中。原因很直接：Hive跑批是分钟级，而用户在前端做交互式筛选时希望秒级返回，OLAP引擎才能扛住这种查询压力。此时架构就变成了Hive做离线ETL，ClickHouse做指标查询，前端直接对接ClickHouse。
最后再分享一下我对这个项目的整体心得。做完这个系统，我最深的感受是：大数据项目的难点不在于某一个框架有多难学，而在于把整个链路串起来的时候，你会遇到各种系统性的问题——磁盘不够了、进程挂了、数据对不上了、内存爆了。每一个问题都逼着你去读日志、查配置、翻官方文档，这种解决问题的能力是纯背面试题得不到的。如果你正在做类似的项目，不要怕踩坑，在我列出的这些问题清单上，省下几天的排错时间是实实在在的收益。祝你也能早日跑通自己的Hadoop项目。
