企业官网建设流程全解析

我第一次把物联网设备的数据塞进Hadoop的时候，其实挺狼狈的。当时手头是一个智慧停车场的项目，车位传感器每隔两秒上报一次状态，一天就是几十万条记录，一个月攒下来几千万条，原先的MySQL直接卡到报表都跑不出来。后来把整条链路切到Hadoop生态，才真正意识到，物联网这种"又大、又杂、又急"的数据，天生就适合分布式存储和分布式计算。

这篇指南不是教科书式的概念堆砌，而是把我从零装环境、接数据、做分析到踩坑排错的全过程梳理了一遍。涉及的内容包括Hadoop伪分布式搭建、集群模式切换、与Zookeeper整合、Flume数据接入、Hive分析，以及作业提交到YARN的完整流程，最后还整理了物联网场景下最常见的报错和调优手段。适合刚入门的数据工程师、正在做课程设计的在校生，还有所有被传感器数据报表折磨过的开发者。

1. 物联网数据为什么非得上Hadoop

1.1 物联网数据的三座大山

物联网数据有很明显的三个特征，我一般跟同事开玩笑叫"三座大山"，你一开始做这个方向就知道它们有多难缠。

第一是数据量大。假设你管着1万个设备，每5秒上报一条状态，算下来一天就是1728万条，一年就是60多亿条。这个量级放在单机数据库里基本是无解的，正常聚合查询都要扫全表，更别提还要保留三到五年的原始数据做回溯分析。别觉得1万个设备很多，现实中一个中等规模智慧园区的传感器数量就能轻松超过这个数。

第二是格式杂。不同厂商的设备上报格式完全不一样，有的是JSON，有的是CSV，还有的是走二进制私有协议。即使都是JSON，字段也经常对不齐，有的设备会多出几个扩展字段，有的值会丢失。传统数据库在上游格式频繁变化的时候，改表结构会改到怀疑人生，而Hadoop的"先存储后解析"模式天然能容忍这种混乱。

第三是持续不断。物联网系统不像电商交易有明确的晚高峰，设备是7×24小时在线的，数据永远在增长。你没法用"今天下班后跑个批量"这种思路去应对，因为每时每刻都有新数据进来。这个时候，一个能线性扩展的存储底座就非常重要了，加机器就能加容量，这个特性对IoT业务来说几乎算刚需。

1.2 传统架构在哪里卡住

很多人一开始都会想，MySQL数据量大就分库分表嘛，或者上MongoDB不行吗？这条路我不是没走过，但代价很高，最后发现都不是最优解。

MySQL在千万级数据量下，建了索引之后单条查询还凑合，但一旦要做GROUP BY这类聚合，索引基本失效，全表扫描加上临时文件排序，慢得让人绝望。分库分表确实能缓解写入压力，可跨库聚合、全局排序、动态扩容这些问题，每一个都能让开发团队陷入泥潭，而且设备产生的数据是按时间顺序疯狂增长的，分库键怎么选都能遇到热点问题。

MongoDB这类文档数据库在写入和单条查询上表现不错，但它擅长的是面向应用的点查，而不是面向分析的大规模聚合。你让它统计"过去一个月每小时的温度平均值"，它一样要把文档都扫出来，性能并不比MySQL好到哪里去。而且它占用的存储空间普遍比列式存储大不少，对IoT这种海量数据的存储成本不太友好。

Hadoop方案的核心思路是"把数据分散到一堆廉价机器上，并行处理"。HDFS负责把大文件切成块存到多个节点，MapReduce或者Hive再把计算任务也分发下去，每个节点只处理自己那一份数据，最后把结果汇总。这种横向扩展的模式，加机器就能提升容量和吞吐，正好对得上物联网数据一路疯涨的节奏。理解这个思路后，你就明白为什么很多物联网数据平台选择以Hadoop为底座了。

1.3 Hadoop生态组件选型

搭建之前要先理解每个组件的角色，不然会陷入"装了Hadoop却不知道用哪个"的尴尬。Hadoop不是一个单一软件，而是一整套生态，每个成员各管一段。

HDFS负责存储，相当于整个系统的大硬盘；YARN负责资源调度，相当于操作系统里的进程管理器；MapReduce是默认的批处理引擎；Hive是SQL化入口，让你不用手写Java代码也能做分析；Zookeeper是分布式协调服务，专门管像NameNode高可用这类"多个节点需要商量着办事"的场景；Flume和Kafka负责数据接入，把设备端的数据搬到HDFS里。

具体到物联网项目，我最常用的组合是Flume+Kafka+HDFS+Hive。如果实时性要求不高，就砍掉Kafka，设备上报直接打到Flume的HTTP源或者日志源，Flume再落地到HDFS。如果后续要做秒级实时监控，再引入Kafka和Spark Streaming，Hadoop这条链路仍然可以作为离线的数据底座。Kafka在这里的意义不只是缓冲，它还能解耦设备和存储，设备端消费波动不会直接冲击HDFS的写入。

选型建议是先跑通最简单的链路，不要一开始就堆组件。后面我写的实战部分，也是按简化版的架构来的，等你跑通之后再逐步升级，每一步都有迹可循。

2. 从零开始搭建Hadoop环境

2.1 环境规划与版本选择

先说版本。Hadoop现在稳定版是3.3.x，我建议直接用3.3.6或者更新的小版本，JDK用8就行，Hadoop 3对这些版本的兼容性很稳，不需要去追JDK 17踩兼容性的坑。很多人一开始追求新版本，结果各种依赖不匹配，反而浪费大量时间。

机器配置方面，如果只是学习，虚拟机给4GB内存就能跑伪分布式；想在课程设计里演示完整集群的话，至少准备三台虚拟机，每台8GB内存，主节点跑NameNode和ResourceManager，另外两台跑DataNode和NodeManager。磁盘不用太大，每台40GB足够，主要是放模拟数据和计算结果。

操作系统我推荐Ubuntu 22.04 LTS，包管理方便，遇到问题网上的资料也多。Windows上虽然也能跑，但脚本兼容和文件配置的坑比较多，新手别在这上面浪费时间。用虚拟机软件装三个Ubuntu实例并不复杂，基本就是Clone两下的事，但比单机伪分布式能演示的东西多很多。

2.2 伪分布式搭建全过程

伪分布式就是在一台机器上同时跑所有Hadoop角色，主要用来学习原理、调试代码和跑小规模数据。很多热门的教程都把它作为第一步，因为它能把Hadoop的核心进程都拉起来，又不需要多台服务器。我下面把步骤完整列出来，每一步都可以直接照着敲。

先建一个专用用户，避免直接用root导致权限问题。

sudo useradd -m hadoop sudo passwd hadoop su - hadoop ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys chmod 600 ~/.ssh/authorized_keys ssh localhost

这里生成SSH免密是为了让Hadoop的脚本能无密码登录本机去启动节点进程。集群模式下，这台机器还要能免密登录其他所有节点，所以在伪分布式阶段就把免密配好，是给后面升级集群打基础。

下载并解压Hadoop：

wget https://dlcdn.apache.org/hadoop/common/hadoop-3.3.6/hadoop-3.3.6.tar.gz sudo tar -zxvf hadoop-3.3.6.tar.gz -C /opt/hadoop

建议解压到 /opt/hadoop 下，然后配置环境变量：

export HADOOP_HOME=/opt/hadoop/hadoop-3.3.6 export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin export JAVA_HOME=/usr/lib/jvm/java-8-openjdk-amd64

把这些写到 ~/.bashrc 里，再执行 source ~/.bashrc。JAVA_HOME 要根据实际JDK路径改，这一步很多人会漏掉，导致后面Hadoop脚本起不来。启动脚本里默认不读系统JAVA_HOME的情况不少，官方文档也反复强调要显式配置。

然后修改四个配置文件，它们的路径都在 $HADOOP_HOME/etc/hadoop/ 下。

core-site.xml 配置文件系统默认地址：

<configuration> <property> <name>fs.defaultFS</name> <value>hdfs://localhost:9000</value> </property> </configuration>

hdfs-site.xml 配置副本数和数据目录：

<configuration> <property> <name>dfs.replication</name> <value>1</value> </property> <property> <name>dfs.namenode.name.dir</name> <value>/opt/hadoop/data/namenode</value> </property> <property> <name>dfs.datanode.data.dir</name> <value>/opt/hadoop/data/datanode</value> </property> </configuration>

mapred-site.xml 让MapReduce跑在YARN上：

<configuration> <property> <name>mapreduce.framework.name</name> <value>yarn</value> </property> </configuration>

yarn-site.xml 配置辅助服务，MR的shuffle要依赖它：

<configuration> <property> <name>yarn.nodemanager.aux-services</name> <value>mapreduce_shuffle</value> </property> </configuration>

配置完成后的启动命令是固定的三步：

hdfs namenode -format start-dfs.sh start-yarn.sh

用 jps 查看进程，正常情况下能看到 NameNode、DataNode、SecondaryNameNode、ResourceManager、NodeManager 这五个Java进程。Web界面可以访问 http://localhost:9870 查看HDFS状态，YARN的界面在8088端口。

有一个坑必须提醒：NameNode格式化只能在第一次启动前做，以后每次重新启动集群都不要再去格式化，否则会把元数据清掉，DataNode和NameNode的集群ID对不上，后面会报一堆Inconsistent FS State错误。很多人第一次遇到这个问题就是手滑重新格式化了。如果确实遇到集群ID不一致，最干净的办法是停掉全部进程，把NameNode和DataNode的数据目录都清空，然后只格式化一次再启动，注意这台机器上已有的HDFS数据会全部丢失。

2.3 伪分布式升级到集群模式

伪分布式跑通之后，很多课程设计或者真实项目需要三节点集群。这时候要把机器名规划好，我习惯用 master、node1、node2 这样的命名，分别对应一台主节点和两台从节点。

修改 $HADOOP_HOME/etc/hadoop/workers 文件，写入所有DataNode的主机名：

node1 node2

然后保证master可以免密登录node1和node2，方法跟前面一样，把master的公钥追加到各从节点的authorized_keys里。三台机器的 /etc/hosts 都要互相写上主机名和IP的映射，例如：

192.168.1.10 master 192.168.1.11 node1 192.168.1.12 node2

这一步看着不起眼，却特别关键。集群模式下，NameNode会按主机名去访问DataNode，如果主机名解析不了，DataNode进程明明拉起来了，NameNode的页面上却永远看不到它，排查起来很折磨人。

配置文件基本不变，但要把core-site.xml里的 fs.defaultFS 从 localhost 改成 master。然后你需要把整套配置文件同步到所有机器，最简单的办法是用scp把整个 etc/hadoop 目录复制过去。启动时在master上执行 start-dfs.sh 和 start-yarn.sh 就行，脚本会自动通过SSH连到其他机器启动对应进程。

集群模式还有一个容易忽略的点：SecondaryNameNode在一台机器上，它和NameNode的职责容易搞混。NameNode负责管理元数据，SecondaryNameNode只是定期合并编辑日志的辅助角色，不是备份节点，千万别指望它能做高可用。真要做高可用，得用下面说的Zookeeper方案。

2.4 Hadoop与Zookeeper整合的实战价值

很多教程把Zookeeper和Hadoop的整合留到很后面才讲，但物联网场景我做下来感觉这一点特别值得提前学习。原因是单NameNode一旦挂掉，整个HDFS就不可用，而物联网数据7×24小时产生，高可用几乎是个硬需求。设备端还在不停上报，存储端却罢工了，这对生产系统来说是不能接受的。

Zookeeper在Hadoop里的作用是提供分布式锁和选主机制。配置了HA之后，两台NameNode里最多只有一个处于Active状态，另一个处于Standby，两台NameNode通过JournalNode共享编辑日志。一旦Active节点崩溃，Zookeeper会在几秒内通知Standby切换成Active，客户端无感知，整个过程有点像两套引擎的热备切换，备机时刻都在同步数据，随时准备接管。

部署整合至少要三个Zookeeper节点形成ZooKeeper集群，然后在core-site.xml里配置多个NameNode的地址，在hdfs-site.xml里指定nameservices、journalnode地址和ZKFC相关的参数。ZKFC是高可用自动切换的核心，每个NameNode上都要启动一个独立的ZKFC进程来跟Zookeeper通信，它负责检测本节点状态并参与选主。

我第一次配置HA的时候，卡了很久才意识到一个问题：两台NameNode格式化之前，必须先启动JournalNode，而且只能格式化一次，否则集群ID不一致，切换也没用。这个顺序问题在官方文档里写得不算醒目，但实际项目中十个人有八个会踩。你想象一下，所有配置都检查过了，Active和Standby却始终不同步，费半天劲才发现是格式化的时机不对，那种滋味真的很酸爽。

3. 物联网数据的接入与存储设计

3.1 用Flume把设备数据搬进HDFS

数据接入层是物联网数据平台最容易被人忽略、也最容易在后期翻车的地方。很多同学把大量精力花在配置Hadoop、跑分析上，却忽略了数据到底怎么进来。其实接入层设计得好不好，直接决定后面分析层是否好写。如果只是用脚本把设备数据一条条往HDFS里写，很快就会遇到两个问题：一是并发能力不够，二是产生海量小文件。Flume这类工具的价值在于，它能在采集端做缓冲、封装成批次、按时间滚动写入HDFS，从源头控制文件数量。

我给一个可以拿来就改着用的Flume配置。场景是设备通过HTTP接口上报JSON，Flume监听5140端口接收。配置文件放在Flume的conf目录下，取名 iot_http.conf。

agent1.sources = httpSrc agent1.channels = fileCh agent1.sinks = hdfsSink agent1.sources.httpSrc.type = http agent1.sources.httpSrc.port = 5140 agent1.sources.httpSrc.bind = 0.0.0.0 agent1.channels.fileCh.type = file agent1.channels.fileCh.checkpointDir = /opt/flume/checkpoint agent1.channels.fileCh.dataDirs = /opt/flume/mydata agent1.sinks.hdfsSink.type = hdfs agent1.sinks.hdfsSink.hdfs.path = /iot/raw/%Y%m%d/%H agent1.sinks.hdfsSink.hdfs.filePrefix = iot- agent1.sinks.hdfsSink.hdfs.rollInterval = 3600 agent1.sinks.hdfsSink.hdfs.rollSize = 134217728 agent1.sinks.hdfsSink.hdfs.rollCount = 0 agent1.sinks.hdfsSink.hdfs.fileType = DataStream

几个关键参数说一下。hdfs.path 里的 %Y%m%d 和 %H 是时间格式，Flume会自动按系统时间生成目录，这样HDFS天然按小时分目录，后面做分区裁剪很方便。rollInterval=3600 表示一小时滚动一次文件，rollSize=134217728 是当文件到达128MB提前滚动，两个条件谁先满足都行。rollCount一定要设成0，代表不按条数滚动，否则默认10条就滚动一次，小文件会爆炸。这个参数是很多物联网项目的噩梦源头，不信你可以试试不设置rollCount，跑半天去看HDFS，满坑满谷都是几百KB的小文件。

启动命令是：

/opt/flume/bin/flume-ng agent --conf /opt/flume/conf -f /opt/flume/conf/iot_http.conf -n agent1 -Dflume.root.logger=INFO,console

设备基数很大、每秒上万条上报的时候，单个Flume agent可能撑不住，这时候通常在Flume前面再放一层Kafka做削峰缓冲。设备数据进Kafka，下游再消费Kafka写入Hive表对应的目录。Kafka的分区机制天然保证了同一设备的数据按分区有序，多个Flume实例同时写也不会乱。实时性要求高的场景，Kafka同时也能喂给Spark Streaming，一套数据两套用途，这也是我在真实项目里最偏好的一条路。

3.2 HDFS目录与分区策略

接入之后，最要紧的是先把目录规划做好。我见过很多新手直接把所有数据塞进一个目录，后面想按天查数据只能全量扫描，神仙来了也救不了。

建议至少分三层：原始层、明细层、汇总层。

/iot/raw/ 存放设备上报的原始数据，不解析、不修改 /iot/ods/ 清洗后的明细数据，按时间分区 /iot/ads/ 统计分析后的结果，供报表使用

以原始层为例，按设备类型和时间两级分区：

/iot/raw/temperature/20241001/10 /iot/raw/humidity/20241001/10

这样设计有两个原因。第一，按设备类型分开，后续单个类型的数据做分析或者做训练时，不用每次Filter全量目录；第二，按时间分区，Hive查询只需要读取对应分区，扫描量能缩小几十倍。比如你要查某一天的数据，Hive会在文件路径层面直接锁定那一天的目录，跟传统数据库走索引一个逻辑。

在代码里写路径时，推荐约定日期用UTC还是本地时间要写清楚。这个问题我在几个项目里都遇到过，设备端默认上报UTC时间，而服务器和业务系统用的都是北京时间，两者差了8个小时。有人直接把UTC时间拼进目录，到了做报表的时候才发现数据整体漂移，小时报表全是错位的。我一般会在Flume里加一个时间拦截器，统一转成服务器本地时区，再生成目录名称，这样后面分析层做日期过滤就省心很多了。

3.3 数据格式怎么选

数据格式选得好，后面查询快一倍、磁盘省一半，这话一点不夸张。很多物联网新手习惯把所有数据都堆成JSON，正是因为这个导致了查询效率低。

原始层的格式我建议保留JSON。因为上游设备格式变动频繁，JSON的冗余字段不会破坏行结构，字段缺失也不影响其他字段的解析。这个阶段不用太在意存储空间，重点是保真。你会发现设备厂商偶尔新增一个字段或者改一个字段名，如果用的是严格的结构化格式，整条链路都要跟着改，而JSON完全没这个烦恼。

清洗后的明细层就不要再存JSON了，用Parquet这类列式存储更合适。Parquet按列压缩，查询时只读取涉及的列，不用像行式存储那样把整行load进来。比如你只需要温度列做平均，Parquet可以只扫那一列的数据，IO量小得多。我做过对比，同一个数据集的同一句SQL，存JSON和存Parquet的查询耗时差距经常有3倍以上。

一个典型的表结构设计会把原始层建成外部表，然后通过Hive或者Spark的ETL任务把JSON解析成Parquet，落到明细层分区。格式选型对照我整理成了一张表：

Avro我单独说一下，它虽然查询性能不如Parquet，但支持schema演化，写入速度也快，适合对写入延迟敏感的场景。物联网数据如果直接通过Kafka Connect进HDFS，用Avro会更顺手，因为上游schema变化时不必同步改表结构。总的来说，分析层优先Parquet，流式写入优先Avro，原始保留用JSON，这个经验可以直接抄作业。

4. 数据处理与分析实战

4.1 用Hadoop Streaming写一个真实统计任务

环境搭好、数据也进来了，接下来就是重头戏：跑一个真正能说明问题的统计任务。我以"统计每台设备每天上报了多少条数据"为例，这个需求在物联网项目里太常见了，相当于最基础的在线率度量。写MapReduce用Java比较啰嗦，要改写的模板代码很多，用Hadoop Streaming配合Python脚本会更直观，也适合快速验证思路。

Mapper脚本 mapper.py：

import sys import json for line in sys.stdin: line = line.strip() if not line: continue try: obj = json.loads(line) device_id = obj["deviceId"] day = obj["timestamp"][:10] print(f"{day}_{device_id}\t1") except Exception: continue

Reducer脚本 reducer.py：

import sys current_key = None current_count = 0 for line in sys.stdin: key, count = line.strip().split("\t", 1) if key != current_key: if current_key: print(f"{current_key}\t{current_count}") current_key = key current_count = 0 current_count += int(count) if current_key: print(f"{current_key}\t{current_count}")

提交命令：

hadoop jar /opt/hadoop/hadoop-3.3.6/share/hadoop/tools/lib/hadoop-streaming-3.3.6.jar \ -input /iot/raw \ -output /iot/result/device_count \ -mapper mapper.py \ -reducer reducer.py \ -file mapper.py \ -file reducer.py

输出结果在HDFS的 /iot/result/device_count 目录下，用 hdfs dfs -cat 查看。第一次跑的时候注意，输出目录不能和输入目录重叠，而且必须不存在，否则作业会直接报错。每次重新跑要么删掉旧目录，要么换个新路径。这个规则刚接触时不适应，但养成习惯就好了，本质上是为了防止覆盖已有结果。

Streaming方式适合快速验证逻辑，但生产环境里我更推荐用Hive或者Spark，代码可维护性高，处理复杂逻辑时也不容易写出一堆难以调试的脚本。MapReduce本身作为原理学习是很重要的，它让你理解分布式计算里的分治思想，后面用Hive或者Spark心里都有底。你会发现所谓的Hive查询，底层其实还是转化成MapReduce或Tez来执行的，逻辑完全相通。

4.2 用Hive做物联网数据分析

Hive是把SQL翻译成MapReduce/Tez任务执行的引擎。物联网场景里，写SQL做分析远比手写Java和Python脚本高效。它不仅好写，还容易让业务同学参与进来，毕竟很多人都会SQL，但不会Java。

先建一张明细表，对应清洗后的Parquet数据：

CREATE EXTERNAL TABLE iot_sensor_detail ( device_id STRING, device_type STRING, status INT, temperature DOUBLE, humidity DOUBLE, ts STRING ) PARTITIONED BY (dt STRING, hour STRING) STORED AS PARQUET LOCATION '/iot/ods/sensor';

注意分区字段dt和hour没有出现在普通字段列表里，数据文件里也不含这两列，它们是靠目录名决定的。查询时用分区字段过滤，Hive会先做分区裁剪，只扫描匹配的目录。如果直接在WHERE里写 ts 的字符串过滤，反而不会触发分区裁剪，因为分区字段是dt和hour，一个是日期一个是小时。

比如看某天每个小时的上报量分布：

SELECT dt, hour, COUNT(*) AS total FROM iot_sensor_detail WHERE dt = '2024-10-01' GROUP BY dt, hour;

统计温度异常的告警设备：

SELECT device_id, COUNT(*) AS alarm_cnt FROM iot_sensor_detail WHERE dt = '2024-10-01' AND temperature > 65 GROUP BY device_id ORDER BY alarm_cnt DESC LIMIT 20;

物联网数据分析还有一个高频需求是补全缺失时间点。设备断网或者信号弱的时候，某个小时可能完全没有数据，直接GROUP BY看不出"缺失"，只能看到数量少。处理方式通常是生成一张完整的时间维度表，再LEFT JOIN上去。比如构建一个包含当天24个小时的临时表，然后和上报数据做关联，就能看到哪些小时没有该设备的数据，这一步对在线率计算非常关键，很多教程不讲，我建议在自己项目里提前把这个时间维度表建好。

Hive的默认执行引擎是MapReduce，如果想快一点，可以在会话里切换成Tez：

SET hive.execution.engine=tez;

Tez比MapReduce快不少，尤其是多阶段JOIN任务，它的DAG执行模型减少了很多中间落盘。前提是你装好了Tez并配置了对应的依赖目录，纯Hadoop环境里不能直接用。如果你跑的是课程设计或者小数据量实验，MapReduce引擎也没啥问题，但作业一旦涉及多个JOIN，你会发现Tez的提速非常明显。

4.3 作业提交到YARN的完整流程

把作业跑起来的全过程，其实就是跟YARN打交道的过程。理解这个流程，遇到作业卡住、资源不够、Container反复被杀这些问题时，你才能一眼猜到原因。很多人只会执行命令，出问题后完全不知道去看哪些日志，原因就是没有建立起这个执行模型。

流程大致是这样的：

1. 客户端把作业的jar包、配置、依赖打包，提交给ResourceManager。
2. ResourceManager分配一个Container给ApplicationMaster，启动它。
3. ApplicationMaster启动后，向ResourceManager注册，并请求运行MapTask和ReduceTask需要的Container资源。
4. ResourceManager根据各个NodeManager上报的可用资源情况，分配Container。
5. NodeManager在各个节点上启动对应的任务进程。Map任务读HDFS数据，处理完在本地做shuffle，Reduce任务拉取结果做最终计算。
6. 所有任务完成后，ApplicationMaster向ResourceManager注销，作业状态变为成功。

这个机制用餐厅来类比会好懂很多。ResourceManager是餐厅前台，只负责接单和下派任务；ApplicationMaster是某一桌专属服务员，负责那桌客人从点菜到上菜的全流程；NodeManager是后厨，真正把菜做出来。节点上每个Container就是灶台上一个可用锅位，锅位不够了就只能排队等，等久了就是作业堆积。

实际操作中，查看作业状态用：

yarn application -list yarn application -status application_xxx yarn logs -applicationId application_xxx

排查问题的时候，优先看两个地方：ApplicationMaster有没有正常注册，Map任务是不是卡在某个节点反复重试。前者通常是自己提交姿势不对，后者往往是数据或者代码的锅。比如某个节点上的任务反复失败，十有八九是那台机器上数据有问题，或者内存不够Container被反复Kill。有了这个排查路径，就不至于在HDFS和YARN界面之间乱点。

5. 常见问题排查与性能调优

5.1 小文件问题：物联网场景的隐形杀手

物联网数据接入里最高频的问题就是小文件。设备多、上报频繁，如果不做批次控制，HDFS里到处都是几KB、几十KB的小文件，NameNode内存直接爆炸，计算任务也会因为每个小文件都要启动一个MapTask而慢得出奇。可以说十个物联网Hadoop项目，九个被小文件折磨过。

解决思路有三个方向。第一，从源头控制，Flume的rollInterval、rollSize、rollCount三个参数要调好，默认配置几乎必定产生海量小文件。第二，定期合并，对已有的HDFS目录用DistCp搬数据，或者在Hive里设置自动合并，跑一轮INSERT OVERWRITE就把小文件聚成几个大文件。第三，分区设计要克制，不要按分钟甚至按秒建目录，小时和天是最合理的粒度，过于精细的分区虽然查询方便，但分区数量太多也会给小文件问题火上浇油。

Hive里常用的合并参数：

SET hive.merge.mapfiles=true; SET hive.merge.size.per.task=256000000; SET hive.merge.smallfiles.avgsize=16000000;

这套组合执行时间较长，我习惯放到凌晨的调度任务里做。另外要注意，合并的过程会重新读写一遍数据，如果原始数据量很大，会占用较多集群资源，所以一般安排在业务低峰期，避免影响白天的实时写入和统计作业。

5.2 数据倾斜：作业卡死的元凶

数据倾斜在物联网场景里特别常见，原因很简单，因为设备不是均匀的。一台热门设备的传感器可能每分钟上报10次，另一台冷门设备可能一天只报3次。GROUP BY device_id的时候，热门设备对应的Reduce任务要处理的数据量可能是其他任务的几十倍，整个作业就被这一个任务拖死，现象就是界面上一堆Reduce任务早完成了，唯独一个卡在那里转圈。

常规解法是加盐打散。把device_id拼接一个随机数或者取模值，让数据先均匀散到多个Reduce，然后再做一次聚合去掉盐。这就是所谓的两阶段聚合，第一次聚合把大Key打散，第二次聚合再合并中间结果。代价是会多跑一轮任务，但对于热点数据，这个代价完全值得，否则作业压根跑不完。

Hive里可以用统一配置开启倾斜连接自动处理：

SET hive.optimize.skewjoin=true;

另外，把热点设备单独拆出来处理也能解决问题。比如统计设备在线率时，把每天上报量超过百万的热点设备单独拉出来，走一个专门的作业，正常设备走常规作业，最后再合并结果。这样做的好处是热点作业单独调优，不会拖累整体。我在真实项目里经常用这个思路，因为物联网里的热点设备往往是固定的一小撮，识别出来并不难。

5.3 常见报错速查表

我把物联网Hadoop项目里最常踩的几个错误整理成一张表，基本覆盖了新手到入门会遇到的70%问题。这张表我自己带新人的时候偶尔也会直接发给对方，省得一遍遍解释。

做第一个Hadoop项目时，记得给每个关键配置留好备份。很多报错其实是改了一半配置、重新格式化导致的，有一个能回滚的配置版本，能省掉大量无谓的排查时间。我曾经踩过最哭笑不得的坑是：为了优化参数，一口气改了五个配置项，后来作业挂了，完全不知道是哪一项引起的，最后只能逐个回滚定位。

5.4 物联网Hadoop项目的课程设计与面试要点

这段时间不少同学在准备Hadoop相关的课程设计，也有人是为了应付面试。物联网数据这个方向其实很讨巧，数据特征明显、业务场景直观，用来做课程设计能展示的东西很多。

如果做课程设计，建议选一个具体场景，比如"基于Hadoop的交通信息分析系统"或者"仓储环境监测平台"。思路分成几段：环境搭建、数据模拟接入、离线统计、可视化展示。数据量不用真的一万台设备，可以写个Python脚本模拟生成即可，但ETL和分析链路要走通。答辩时重点讲清楚分区设计、小文件控制、数据倾斜处理这三个点，老师就会觉得你是真做过，而不是照着教程跑了一遍。

面试方面，围绕Hadoop和物联网结合的高频问题有这些：数据倾斜怎么解决、NameNode高可用怎么实现、HDFS写入流程、MapReduce的Shuffle过程、YARN的资源调度机制。物联网背景会多问一句"设备上报数据量很大时，你会怎么设计接入层"，这时候把Flume缓冲、Kafka削峰、按时间滚动写HDFS这套方案讲清楚，基本就能过关。注意别只背概念，最好能带上自己实操时的具体参数，比如Flume的rollSize设成多少、Kafka分区数怎么定，一听就知道是做过项目的。

我自己面试别人的时候，最喜欢听的是候选人承认"某次作业卡了很久，后来发现是某台设备数据特别多导致倾斜"。有具体案例比背一堆八股有用得多，因为面试官想看到的不是"我知道这个概念"，而是"我知道怎么用这个概念解决真实问题"。

这篇指南写得比预期长不少，不过都是我在物联网和Hadoop交叉项目里反复趟出来的经验。如果让我只留一句话给后来者，那就是：先把最小链路跑通，再把细节磨干净。环境卡住的时候去看看配置备份，作业卡住的时候先怀疑数据倾斜和小文件，别急着怪框架。

最后再分享一个每天都在用的习惯：新项目里，我会花半天时间把设备上报时间的时区问题彻底确认清楚，接入层统一做一次时间标准化。这个动作看起来不起眼，但能省掉后面报表阶段无穷无尽的日期对齐烦恼。物联网数据项目从来不是一次性的，链路跑起来了，后面才有资格谈优化。