企业官网建设流程全解析

这两年被问得最多的一个问题，不是“Hadoop怎么学”，而是“我们那一批传感器每天上报几百亿条数据，写入没问题，但想查点什么，一个查询跑半小时，怎么办”。物联网的传感器数据跟传统互联网日志完全不是一回事——设备数量动辄百万级，每台设备几秒一条数据，一天下来就是几百亿条记录，而且数据格式五花八门，时序特征极强，还有大量噪音和缺失。很多人一开始用传统数据库扛，扛到几千万条就明显卡顿，换时序数据库能解决一部分，但涉及复杂分析、历史归档、跟业务数据做关联，又力不从心。这时候，Hadoop生态的价值就体现出来了——它不是为了存数据而存数据，而是为了让你在几十亿条传感器记录上还能跑出个结果来。

这篇文章我从实际项目的角度，把“Hadoop+物联网传感器数据”这个组合拆开讲：数据链路怎么搭、清洗策略怎么做、存储模型怎么建、跑分析时有哪些坑，最后用一个典型场景复盘收尾。适合正在做物联网平台、准备上Hadoop处理设备数据的团队，也适合毕业设计选了物联网方向的同学们参考。

1. 物联网传感器数据的四种“脾气”：为什么非Hadoop不可

搞过物联网的人都有体会：传感器数据跟人工录入的“业务数据”完全两个物种。我经常打比方，传感器数据像是流水线上的零件——每个单独看起来都差不多，数量却大到吓人；而业务数据像是档案室里的文件——数量少，但每份都很重要，格式也要精雕细琢。拿处理文件的方式去处理零件，必然出问题。

1.1 高频写入：几秒钟一条，量级跟日志没法比

传统互联网日志写入峰值，一台服务器每秒钟几百条就算高了；但一台工业网关后面挂了上百个传感器，每个传感器3秒上报一次，这个网关每秒就有几十条数据。一个中型工厂几百台网关，就是每秒上万条写入。这还不算共享单车、智慧路灯、环境监测这类全国性场景。我见过一个项目，40万个设备，每2秒一条心跳数据，光是一天的数据量就是17亿条，2TB压缩后。这是物联网数据跟普通日志最本质的区别——持续不断，从不睡觉，全年无休。

这种高频写入场景下，传统关系型数据库的瓶颈很明显：每一行插入都要走索引、走日志，写入吞吐上不去。Hadoop生态里的HDFS解决了存储层的大规模吞吐问题（靠的是大块顺序写），而Kafka这种消息中间件则解决了“接入层削峰”的问题——后面细说。

1.2 时序特征极强：每条数据都带着时间戳，但时间戳最不可信

传感器数据本质上是时序数据：一个设备ID + 一个时间戳 + 一个或多个测量值。这个特性决定了存储模型可以高度简化——按设备分桶，按时间排序，所有查询要么是按设备查一段历史，要么是按时间范围跨设备扫描。跟业务数据那种多表关联的复杂结构比起来，传感器数据的模型简单得多，但数据量却大几个量级。

但这里有个反直觉的坑：时间戳看起来是数据自带的属性，实际上恰恰是传感器数据里最不靠谱的字段。设备时钟漂移、网关缓存重传、网络延迟，都会让数据到达时间和数据产生时间出现偏差，有的甚至差几个小时。我在后面有一节专门讲这个问题，这里先提个醒——如果你把入库时间当成了传感器产生时间，那后面的分析结果会很离谱。

1.3 格式参差不齐：几十种设备，几十种协议，聚在一起就是烂摊子

一个项目里很少只有一种传感器。温度传感器、湿度传感器、振动传感器、能耗表计、定位追踪器……每种的报文格式都不一样。有的上报字段叫temp，有的叫temperature，有的干脆是data: {v: 23.5}这种嵌在JSON里的。更过分的是，不同批次的固件版本，字段含义还会变。这不是代码规范问题，而是设备厂商太多、协议标准跟不上的现实。

这部分脏活累活，在Hadoop架构里通常拆成两层解决：接入层做“格式归一化”，把乱七八糟的报文解析成统一的JSON或Avro格式；分析层再做“字段标准化”，把历史数据统一到一个口径。这也是为什么我在下一节强调Kafka的schema管理能力。

1.4 数据的价值密度低，但分析需求却很高

单条传感器数据的价值密度极低——“设备A在10:03:27时刻的温度是26.1℃”——这条信息基本没用。但成百上千设备的时间序列拼在一起，就能看出设备是否异常、产线是否过载、能源消耗是否异常。也就是说，物联网数据的特点是：单体没用，聚合才有价值。

这个特性决定了存储不能丢，但又不能粒度太细地长期全保留；分析既要能全量扫描（比如找出上个月所有设备的温升曲线），又要能快速定位（比如查某个设备3小时前的瞬时值）。Hadoop生态可以同时满足这两类需求：HDFS/HBase管存储，Hive/Spark管全量分析，HBase或Redis管点查加速。这也是为什么我不建议只上一个时序数据库——时序库确实在写入和点查上有优势，但跨设备复杂聚合分析、跟其他系统的数据做关联，还是Hadoop生态更顺手。

2. 整条数据链路怎么搭：传感器、网关、Kafka到HDFS

先给一个我自己惯用的参考架构，再挨个拆解每一层为什么要这么选。

传感器设备 → 边缘网关 → Kafka（数据接入层）→ 流处理/清洗 → HDFS/HBase（数据存储层）→ Hive/Spark（分析层）→ 应用

2.1 为什么中间非要加一层Kafka：入湖和入库是两件事

很多第一次做物联网数据平台的同学会问：传感器数据直接写到HDFS不就行了？干嘛要在中间加一个Kafka？答案是——HDFS适合“批量落盘”，不适合“每秒钟几万条实时写入”。HDFS的优势是大块顺序写、高吞吐批量导入，每来一条就写入一次，会产生大量小文件，后面专门讲。而Kafka的作用就是缓冲和削峰：传感器数据先冲到Kafka里，下游不管是用Flume还是用Spark Streaming，按自己的节奏批量写入HDFS。

这样做还有另一层好处：数据入湖和数据处理解耦了。设备不用关心下游存储系统的死活，Kafka里的数据可以先攒着，哪怕下游HDFS集群重启、跑批任务挂了，数据一条不丢。Kafka默认保留策略是7天，这7天就是你的“后悔药窗口”和“追数窗口”。

2.2 选型对比：Flume还是Kafka Connector？

有了Kafka之后，从Kafka到HDFS这一段，有三个方案经常被拿来比：Flume、Kafka Connect（特别是HDFS Sink Connector）、以及直接用Spark Streaming写。我列个表，用实际项目经验说话：

我自己的偏好是：管道简单就用Flume，管道逻辑复杂就直接Spark Structured Streaming，Kafka Connect反而用得少——因为它把很多处理逻辑限制在了配置层，一旦遇到业务字段映射这类需求，配置比写代码还痛苦。不过这是个人喜好，团队技术栈不同选择不同，有一点是公认的：从Kafka到HDFS的这层管道，一定要支持按批提交、失败重试和流量监控，缺一个后面都会很被动。

2.3 存储层选择：HDFS还是HBase？两条腿走路

物联网传感器数据的存储，我建议两条腿走路：一份放HDFS，一份放HBase（或者用其他列式存储）。

• HDFS + Parquet/ORC：用于历史归档和批量分析。按时间分区存储，保留周期可以很长（一年甚至几年）。分析任务是读这类数据。
• HBase：用于最近N天的点查和实时查询。比如“查某个设备当前状态”、“查某个设备最近一小时曲线”，走HBase的RowKey索引非常快。RowKey设计一般是设备ID逆序 + 时间戳，避免热点（后面细说）。

如果你不想引入HBase，也可以用HDFS + Hive直接扛点查——建好分区表，用Spark SQL按分区过滤查，千万级设备量下响应一般在秒级到十秒级，很多场景够用了。非要说什么时候必须上HBase，那只有“查询要求毫秒到百毫秒级”的场景，比如实时告警联动、大屏点查。

3. 让数据“干净”地入库：传感器数据的清洗策略与实操

“脏数据进库，分析结果就是垃圾。”这句废话在物联网领域尤其重要——因为这行业的数据脏法跟别处不一样：不是人为录入错误，而是设备层面的物理性失真。采集环节不可控，所以清洗策略必须在入库前做扎实。

3.1 三类最常见的传感器“脏数据”及判据

我归纳下来，传感器数据清洗主要解决三类问题：

1）重复数据：同一时刻同一设备上报了两条一模一样的记录。原因一般是设备的重传机制（网络抖动导致ACK没到，设备重发），或者网关转发了两次。判据就是：设备ID + 来源时间戳这两列组合去重。特别注意：去重不能只看JSON是否完全一样，因为两次重传的数据可能部分字段不同（比如接收时间不同），要用业务主键去重。

2）离群值/超范围值：温度传感器报了500℃，湿度报了-20%，这种数据明显不物理。判定方法是给每个测点配置合理的上下限。但这里有个容易踩的坑——不同应用场景的阈值不一样。同一块温度传感器，用在常温厂房（0~40℃）和用在冷链（-30~10℃）上，正常范围完全不一样。所以阈值配置必须跟着设备类型走，不能写死在处理代码里。

3）缺失数据与虚假数据：设备掉线会导致一段时间完全没有数据；设备故障则可能反复上报同一个值（比如一直报24.0）。缺失数据还好办，补一个空或标记缺失即可；虚假数据最难搞，要结合“数值随时间是否变化”来判定。我在项目里用过最简单的判据：同一测点连续10条数据值完全一样，就标记为“疑似异常值”，写入清洗表里，人工抽检。

3.2 清洗在哪个环节做？端侧、接入层、还是分析层？

三处都有活干，但职责不同：

• 端侧（边缘网关）：做格式解析、协议转换、基础校验（必填字段是否缺失、报文是否合法）。这里不做复杂逻辑，因为网关算力有限，而且升级困难——尽量少给端侧加戏。
• 接入层（清洗任务/流处理）：做去重、时间口径统一、字段标准化、值域校验。这一层是清洗的主战场，因为数据到了这里才被集中看到，可以做跨设备或按设备类型的规则判断。
• 分析层：做深度清洗和异常检测。比如后面要训练模型或做设备健康度评估，这时才做滑动窗口、趋势判断等复杂逻辑。

一个具体的实操建议：在接入层做“标准时间”字段。设备上报的device_time（设备本地时间）和receive_time（网关/平台接收时间）都要保留，但下游统一用event_time作为事件时间，等于在清洗时就明确时间口径。我在清洗任务里一般这样规定：优先用设备本地时间，但如果设备时钟偏差（跟接收时间比）超过10分钟，则标记为时钟漂移数据，改用接收时间，并将原始时间放device_raw_time字段备查。后面讲Spark Structured Streaming时再说watermark怎么配合这个口径。

3.3 清洗SQL长什么样：一段可以直接抄的示例

假设清洗后统一输出到Hive的ODS层表ods_sensor_data，上游Kafka里的原始数据是JSON字符串，我用Spark Structured Streaming做实时清洗，核心逻辑如下（省去环境初始化和参数配置，只看清洗主体）：

// Spark Structured Streaming 消费 Kafka，清洗后写入HDFS val raw = spark .readStream .format("kafka") .option("kafka.bootstrap.servers", "kfk01:9092,kfk02:9092") .option("subscribe", "sensor_raw") .load() val parsed = raw .selectExpr("CAST(value AS STRING) as json_str") .select(from_json($"json_str", sensorSchema).as("data")) .select( $"data.device_id".as("device_id"), $"data.temp".as("temp_raw"), // 时间口径统一：设备时间优先，漂移则用接收时间 when( abs(unix_timestamp($"data.sensor_time") - unix_timestamp($"data.receive_time")) < 600, $"data.sensor_time" ).otherwise($"data.receive_time").cast("timestamp").as("event_time"), // 值域校验 when($"data.temp".between(-40, 85), $"data.temp").otherwise(lit(null)).as("temp"), // 去重 $"data.msg_id".as("dedup_key") ) // 以 msg_id 为主键做去重（用stateful操作）

这一段可以直接做骨架去扩展。有几点值得说明：

• from_json解析时一定要定义好sensorSchema，字段变更时要做好兼容，否则一个新设备类型上来就全管道崩了。
• 去重用msg_id而不是设备ID+时间戳拼接，是因为不同批次/不同协议下msg_id的生成规则可能不同。最稳妥的做法是设备ID+传感器时间戳+随机数三段拼一个唯一ID。
• 对于断言失败的异常值，我没直接丢弃而是置NULL——这样后面做分析时能区分“没数据”和“数值不合法”，两种含义不同。

4. 查得快才算数：Hive分区建模与Spark分析实践

数据入库只是第一步。真正的价值在“查”——但很多人发现，数据是存进去了，Hive表也建了，跑一个统计查询要半小时，Spark任务动不动OOM。这大概率是数据模型设计出了问。题传感器数据的查询模式高度固定，设计好了，90%的分析查询都能走分区裁剪，速度能差几十倍。

4.1 分区策略：按时间分区，还是按设备分组？我的建议

传感器数据查询有两个天然维度：设备维度和时间维度。Hive表怎么做分区，直接决定了查询效率。

**按时间分区（如按小时/天分区）**是默认方案，绝大多数场景都适用。原因很简单：传感器数据分析里，跨设备的时间范围扫描是最常见的查询——比如“查全天所有设备的平均温度”、“查最近7天某型号设备的异常率”，都是时间维度主导。按时间分区后，这类查询只需读取对应分区的数据，扫描量从“全表”降到“一天的量”。

但这里有几个实操层面的建议：

• 分区粒度不要太小。监控数据量不大的场景按天分区够了，量太大再考虑按小时。我见过有人按5分钟分区，结果一个查询要合并几千个分区文件，MapReduce的启动开销比实际计算还大，得不偿失。
• 分区列不要用dt这样没意义的字段，干脆就叫event_date，直接用清洗后的event_time来分区。这样查询时WHERE event_date = '2024-06-01'，优化器能精确裁剪。
• 如果单体设备数据量极大（比如一台设备每天上千万条记录），可以考虑“设备ID哈希分桶+按时间分区”的双层结构。分桶字段是设备ID，查询某个设备的完整历史时就能跳过大量不相关文件。但注意，分桶数不能乱设，要与文件大小匹配，否则小文件问题会变本加厉。

下面是建表模板，可以直接抄：

CREATE TABLE dwd_sensor_data ( device_id STRING, device_type STRING, event_time TIMESTAMP, temp DOUBLE, humidity DOUBLE, vibration DOUBLE, ... ) PARTITIONED BY (event_date STRING) STORED AS PARQUET TBLPROPERTIES ('parquet.compression'='SNAPPY');

4.2 列式存储+压缩：让单条记录再瘦一圈

同样的数据，用TEXT存和用Parquet+Snappy存，查询性能可以差5倍以上，存储空间可以压缩60%以上。原理不复杂：列式存储只在读取查询涉及到的列时读取对应数据块，而传感器数据一张表动辄几十个字段，多数查询只用其中两三个字段——行式存储要把一整行读完才能拿到一个列的值。这就像你从一叠定制的纸质表格里查所有人的手机号，行式存储要求翻完每一张完整表格，列式存储直接把“手机号”那一列抽出来。

注意Parquet的另一个好处是内置schema（列名、列类型），用Hive/Spark读时不用再指定分隔符和字段顺序，少了不少解析错误。我用的是Snappy压缩——压缩率比Gzip差一点，但解压速度快，适合查询频繁的场景。冷数据想压得更狠，可以直接换ORC+Zlib，但ORC在Spark里的支持没Parquet那么顺滑，要看你的分析引擎主要用什么。

4.3 Spark读Hive数据，两个最常见的性能杀手

讲个真实数据：一台Spark任务读1TB的Hive表做设备聚合分析，第一次跑了一个多小时，第二次五个小时，第三次直接OOM。根因两个：

杀手一：读出来的宽表。原始表有30个字段，但分析只需要device_id、event_time、temp三个字段。代码里如果有人用了SELECT *或者Spark的“谓词下推”没生效，整表都被读进来了。解决办法：分析SQL里显式写出需要的列，不要图省事写*；检查Spark物理计划里PushedFilters是否生效。

杀手二：不合理的join策略。用Hive做设备基础信息表和传感器数据表的关联，如果基础表只有几万行，而传感器表有几十亿行，默认的Shuffle Join会把几十亿行全部shuffle到所有节点，传输量巨大。正确做法是广播小表：

-- 使用Broadcast Join提示，避免大表Shuffle SELECT /*+ BROADCAST(dim) */ s.device_id, d.region_name, AVG(s.temp) AS avg_temp FROM dwd_sensor_data s JOIN dim_device d ON s.device_id = d.device_id WHERE s.event_date = '2024-06-01' GROUP BY s.device_id, d.region_name;

/*+ BROADCAST(dim) */这个提示能强制Spark把dim_device分发给每个Executor，传感器大表在本地完成关联，省掉一次几亿行的Shuffle。我见过很多团队优化半天没效果，最后就是加了这个提示瞬间提升性能。

4.4 实时分析怎么做：Structured Streaming与“延迟数据”处理

物联网场景里，实时和准实时是一对绕不开的需求。要么是“设备数据延迟多久能看到”，要么是“告警规则能不能在秒级触发”。我的经验是：绝大部分物联网场景不需要真正的毫秒级实时流处理，秒级到分钟级的准实时就够了。

我也是这么落地的：Kafka里取数据，Spark Structured Streaming每30秒触发一次micro batch，做清洗和简单聚合后写入结果表。关键在哪？延迟数据。设备掉线一段时间后重新上线，会把历史缓存数据一股脑传上来，导致流任务里出现“昨天的事件今天才到达”。处理不好，聚合结果会来回跳，看板上的数字忽高忽低。

解决方法是watermark（水印机制）——告诉流引擎“允许迟到多久”，超时的一律丢弃或单独走补偿流程。我一般设10分钟的watermark，跟前面清洗时“设备时钟漂移超过10分钟改用接收时间”的口径保持一致：

// 水印机制处理延迟数据 events .withWatermark("event_time", "10 minutes") .groupBy(window($"event_time", "1 minute"), $"device_id") .agg(avg($"temp").as("avg_temp"))

5. 上线后才会遇到的三个经典坑：时钟漂移、小文件与写入热点

这一节写的都是我在生产环境里真实踩过的坑，踩一次抖三抖的那种。前两个讲了理论基础，这里专门讲故障现场和修复过程。

5.1 坑一：设备时钟漂移，把“峰值分析”做成了“灾难现场”

有个项目做工厂电力负荷分析，目标是看设备集群在“哪个时间段”用电最猛。上线两周后，BI团队反馈说数据完全没法看——凌晨3点出现用电高峰，白天反而波谷，这跟工厂作息完全不符。

排查过程是这样的：先看Kafka里的原始数据，设备时间戳是正常的白天8点；再查Hive表，发现event_time字段竟然变成了凌晨3点。问题出在清洗任务——我用的是unix_timestamp($"data.sensor_time") - unix_timestamp($"data.receive_time")来判断时钟偏差，大于10分钟就改用接收时间。但有个批次的网关固件有Bug，每次重启后本地时钟会回退8小时。这些设备上报的sensor_time比服务器的receive_time晚8小时——注意，是晚（数值小），绝对值差刚好480分钟。我的代码里判断条件是绝对值大于600秒，只能识别“设备时间超前”，识别不了“设备时间落后8小时”这种情况。结果这批设备的所有数据都被当成漂移数据处理，用接收时间替换了传感器时间，可接收时间却是服务器收到的时刻——凌晨3点。

修复思路：把“基于单条记录的时钟漂移判断”改成“基于设备维度的连续漂移监控”。对每台设备持续统计receive_time - sensor_time的差值分布，如果这个差值在一段时间内稳定在一个非0值附近，就说明设备时钟存在固定偏移，应该按补偿量修正，而不是直接丢弃。另外，最终判断永远以业务上“用电高峰在白天”这条规则校验数据是否符合正常模式——这类简单的业务合理性检查往往能最快发现问题。

5.2 坑二：Kafka+Flume写入HDFS导致的小文件堆成山

小文件问题是Hadoop环境里的经典杀手。当时用的Flume从Kafka拉数据，默认每500条提交一次，每提交一次就到HDFS写一个文件——数据量一大，一天就产生几万个“小文件”。HDFS的NameNode每个文件大约占150字节元数据内存，几千万个文件就能吃掉几个GB内存；更重要的是，Spark/Hive跑分析时要列出和处理几十万个文件，光打开文件的时间就比计算时间长。

我定位到的根因是两层：Flume的batchSize设得太小（500条），hdfsSink的分区策略又按时间分了太细。解决过程用了三板斧：

1. 加大Flume的batchSize到1000~5000，让每个批次攒更多数据再提交。
2. 调整hdfsSink的rollInterval和rollSize——不要让文件每几分钟就滚动一次，设置成“文件超过128MB或30分钟才滚一次”，充分利用大块写入保证吞吐。
3. 上完这两步还没根治，后来加了一层HBase做缓冲层：数据先写入HBase，HBase再定期合并Compaction后输出HFile到HDFS，完全绕开“Kafka到HDFS直写”的小文件问题。

现在这个项目中，我们最推荐的做法是Kafka → Spark Streaming → HDFS的方式，写入时直接用coalesce控制输出分区数，强制生成足够大的文件。同一批数据，不控制分区数可能生成几百个小文件，coalesce(4)直接把输出收敛为4个大文件。问题看上去是“文件多”，本质是“提交粒度太碎”，理解了这一点，就明白各种方案的本质都指向同一个方向——提高单文件体积。

5.3 坑三：写入热点——RowKey设计失败导致HBase单节点被打爆

HBase处理实时数据时，RowKey设计是性命攸关的事情。我们曾直接用了设备ID + 时间戳作RowKey。看起来没毛病——但传感器数据的时间是持续递增的，于是所有写入都集中在同一个Region Server上。那是单Region热点，直接导致某个节点负载极高，其他节点闲着。

修复方案是把RowKey改成设备ID逆序 + 时间戳。比如设备ID从device_000000000001变成100000000000_device，再拼上时间戳。这样相同设备的不同时间点在主键上分布到了不同的Region，写压力同时分摊到集群里的多个节点上。另一个常见备选方案是在RowKey前面加一个随机前缀（比如把device_id哈希后取前两位），但这么做的代价是查询时不知道前缀，Scan就不连贯。设备ID逆序是“分散写”和“方便查”之间比较平衡的方案——反查时我们知道完整的设备ID，照样能直接命中RowKey前缀，不会牺牲查询性能。

修复之后，监控图上写吞吐从“一个Region扛”变成“几个Region平摊”，P99延迟从200ms降到40ms。这个经验后来也验证了设计中另一个判断：物联网高吞吐场景下，热点问题本来就是第一杀手，RowKey设计永远要先想写热点，再想查便利性。

6. 完整案例复盘：一个百万级环境监测平台从数据接入到分析落地的全过程

前面讲了这么多方法论和坑，最后用一个我参与过的真实项目把这些串起来。这个项目不需要透露具体甲方名字，就讲场景和数据。

项目背景：几十个城市、上万个监测点，每个监测点部署PM2.5、温湿度、风速风向、噪声等7种传感器，每10秒上报一条数据。全部设备累计每天产生约8亿条数据，单条原始报文是一条JSON字符串，大小约300字节。这么算下来，一天原始数据约24GB，一年接近9TB。

目标有三：

• 实时大屏：分钟级展示各城市平均PM2.5，实时告警（浓度超阈值触发预警）；
• 离线分析：按周/月输出空气质量趋势报告，评估不同区域污染源影响；
• 历史追溯：对任意监测点，查询任意过去一天的分钟级曲线，响应5秒内。

6.1 数据流转链路和核心参数

• 采集端：网关统一上报到MQTT Broker，Broker直接转发到Kafka的sensor_raw主题。不直接让设备连Kafka，因为Kafka是TCP协议，设备用MQTT连接生态更成熟。这就是协议转换标准做法：设备→MQTT，平台内部→Kafka，两者在Broker层对接。
• 接入清洗：Spark Structured Streaming消费sensor_raw，做去重、值域校验、时钟漂移修正，并补上event_date分区字段（用event_time转换），写入HDFS的ODS层，按天分区。
• 实时部分：同一个流任务同时做分钟级聚合，写入HBase + Redis（缓存最近5分钟数据供大屏点查）。
• 离线分析：夜里用Spark SQL从ODS层读全量原始数据，做多维度聚合到DWD层（按城市、小时、测点类型分层），报表和趋势分析直接查DWD层，秒级响应。

Kafka的配置也有讲究——关键topic分区数设为24个（等于Broker数），保证写入不倾斜且消费并发可以到24。HDFS块大小用默认的128MB，清洗任务输出文件控制在128MB以上这个目标，所以Spark写入时用repartition(24)。

6.2 上线的时踩过的三个小问题

第一个问题是MQTT到Kafka的链路丢数据。设备重连时网关会补传断点数据，但Broker转发到Kafka时又用了异步send，缺少ACK确认，压力大时有几条消息被丢掉。排查后发现是Broker的QoS设置是“发完不管”，改成QoS1（至少一次）和Kafka的ack=all，补上了丢弃缺口。

第二个是Spark处理数据倾斜。某几个工业区的监测点数量明显多于普通区域，按区域聚合时出现了少数组件处理多倍数据的现象。解决办法是按“城市+小时”做二次worker分配——代价是多一次shuffle，但从结果看这点额外消耗完全值得。

第三个是HBase的Compaction风暴。高峰期大量Region同时做Compaction，导致某个RegionServer的IO被打满，反而降低查询TPS。后来错峰合并：把HBase的自动Compaction关掉，每天凌晨用运维脚本按RegionServer逐个手动执行Major Compaction，问题就平了。这也是运维层面一个合理的取舍——牺牲一点自动性，换取全天服务稳定。

6.3 大盘数据长什么样

上线稳定几周后，我摘过几个关键数据：全链路端到端延迟平均30秒左右（传感器到平台可查），大屏数据秒级更新；离线每天刷数任务2小时完成（8亿条原始数据），Hive查询分钟级的趋势分析0.8秒到3秒；存储空间方面，ODS层原始数据压缩后4.3GB/天，DWD层聚合数据仅500MB/天，但已经能满足95%以上的查询需求。这个压比其实很典型——原始数据全量保存一份（便宜），精细分析集做一份（快），两层都保住。

7. 一些经验沉淀：给后续做同类项目的人几点忠告

全项目走完一遍，我个人最大的体会有三条：

第一，“接入容易治理难”。传感器数据的接入环节看上去每个设备都连好就行，实际上治理工作要占整个项目的70%以上——而且这些工作如果没有事先规划，等到数据上线之后再做，成本和被动程度都远超想象。清洗规则、主键设计、时间口径，应该在数据流向设计阶段就定下来，而不是上线了再返工。

第二，“能落到HDFS的绝不浪费在内存”。物联网数据的体量决定了内存很贵，把几百亿行数据长期放Redis或内存数据库，财力上往往撑不住。HDFS和对象存储都用压缩配合，是最划算的历史存储方式。而内存、SSD这些高速资源只留给最需要点查和分析的层。

第三，“所有问题都能在监控里现原形”。我们吃了不少“数据错了但没人发现”的亏——不是任务报错，而是结果不合常识。后来给Kafka lag、HDFS文件数、Region热点、Spark任务失败率都做了实时监控和告警，并对“峰值温度是否异常偏移”这类业务结果设置了规则校验。数据平台最怕的不是坏，是坏了没人知道。

这个架构可能不是最优解，但它是经过了生产环境验证和故障打磨的。物联网数据处理没有银弹，核心是抓住自己的场景特性：高吞吐、时间序列、多源异构、低价值密度——把存储、清洗、分析都围绕这四个特征去设计，整体不会跑偏。