很多人问我物联网大数据平台到底怎么搭。我的回答一般不是直接给架构图而是先放一段我自己的踩坑经历。前几年有个工厂监控项目最开始接到需求是“几百台设备数据存下来看曲线”我们直接用了传统 Web 方案的思路设备通过 MQTT 上报后端接收后写 MySQL。前半年很稳一切看起来没什么问题。直到规模涨到一万台上报频率从一分钟改成三秒MySQL 写不进去了查询接口动辄十几秒大屏卡成 PPT。那次重构让我意识到物联网数据链路和传统业务系统有本质区别必须把接入、消息、存储、计算、展示拆开设计而不是所有东西塞到一个数据库里。这篇文章就是我基于那次重构以及后来多个物联网数据项目的完整总结。内容适合三类人刚接触物联网平台的后端开发、准备做物联网相关毕业设计的学生、以及公司里要从零搭一套设备数据平台的技术负责人。我会按真实的落地顺序来讲从需求分析到架构分层、从技术选型到具体采集链路、从实时计算到可视化最后专门讲部署上线后我踩过的那些坑。这里不会有“一步到位”的大而全方案只有一套能在自己服务器上跑通、并且有扩展空间的完整路径。1. 先想清楚平台要解决的四个问题1.1 数据从哪儿来物联网平台的数据来源比大多数系统复杂常见的就有温湿度传感器、烟感/水浸、PLC、智能电表、车载终端、环境采集仪、第三方系统通过 API 推送的工单数据等等。这些设备有各自的协议和报文格式有的支持 MQTT有的只支持 Modbus还有的老设备只能通过网关转出来。在设计平台之前我建议先把设备的数量、测点数、上报频率列成一张表。业内常用“每秒写入点数”来预估压力计算公式很简单写入点数/秒 设备数量 × 单台设备测点数 × 上报频率(次/秒)举个例子1 万台设备每台有温湿度、电压、功率 5 个测点每 10 秒上报一次那么写入负载就是 10000 × 5 ÷ 10 5000 点/秒。如果上报频率改成每 3 秒一次直接变成 16666 点/秒。很多平台崩溃不是“设备太多”而是“上报频率设计不合理”所以这个数字必须在写架构之前算清楚。1.2 数据要存多久物联网数据的生命周期和业务数据差别很大。原始高频数据体积增长极快但实际价值往往集中在最近几天到三个月。我的习惯是拆成三层热数据最近 7 天保留原始粒度用于实时查询和告警温数据3 个月到 1 年降采样到分钟级或小时级平均值用于趋势分析冷数据超过保留周期后归档到对象存储必要时再取出来分析。保留时长不是拍脑袋定的。国家或行业对部分领域有明确的数据留存要求企业内部财务、质检等部门也会有自己的合规策略。建议在项目初期找业务方确认“原始数据最少要留多久”不要等上线后才发现要改存储方案。1.3 数据给谁用同一个数据不同人用法完全不一样。车间值班人员要看实时曲线和大屏告警设备工程师要查某一个设备的历史运行状态管理层要的是日报、月报统计后续做预测性维护的话算法团队还要拿到高质量的历史样本。这些用途决定了平台必须有“实时链路”和“离线分析链路”两条腿。只做实时不做离线报表永远做不出来只做离线不做实时告警就是摆设。我在设计数据模型时会同时保留实时流转用的消息和一份由流式计算生成的聚合结果两边互不干扰。1.4 想清楚再动手别被“大数据”三个字绑架还有个很容易犯的错误项目名字里有“大数据”就一上来部署 Hadoop、Spark、Hive 全家桶。物联网场景维护成本最高的从来不是单机性能不够而是组件过多、没人会运维。判断要不要上重量级组件直接看数据量一套 500 台设备、每天增量 5GB 的监控系统真不需要 Hadoop 集群。但如果日增量达到 TB 级需要跑复杂的离线分析那就另说。架构要跟着数据和业务走不是跟着名字走。2. 平台架构分层从感知层到数据服务的完整链路物联网平台最常见的是三层架构——感知层、网络层、应用层。但在落地时我会在这个基础上扩展出一个边缘层因为设备量上来之后所有东西都直连云平台会出大问题。2.1 感知层与边缘层的分工感知层就是设备本身包括传感器、执行器、PLC、单片机等等。边缘层则是设备与云端的中间地带通常是一台网关设备或一个本地服务它负责三件事协议转换、数据缓存、本地规则。为什么要加这一层最直观的原因是有线网络和无线网络都会有抖动。假设一条生产线上的 PLC 通过内部网络上报数据理想情况每秒一条但接入网关重启期间设备端不会等云端恢复它会持续产生数据。如果网关没有本地缓存这一段数据就丢了。有了边缘层网络恢复后能自动补传数据完整性才有保障。边缘层还可以做轻量过滤。比如某些电表每分钟会把同一个功率值连续上报 6 次对存储来说这就是浪费在网关侧做“变化才上报否则只上报心跳”的规则能直接削减一半以上无效数据。2.2 网络层接入协议选型MQTT 是主力其他协议靠网关适配设备接入层的协议选择直接决定后续链路形态。我做过几次选型对比主流选项基本是三个MQTT基于发布/订阅长连接协议轻量支持 QoS 等级非常适合大量设备高频双向通信CoAP基于 UDP更轻量适合低功耗、弱网环境但调试和应用生态没 MQTT 丰富HTTP无状态短连接实现简单但每个请求都有握手开销不适合高频批量上报。实际项目里最省事的做法是让设备都走 MQTT 接入差异协议由边缘网关统一转换成 MQTT 再上送。这样云端只维护一条标准链路不用为每一种设备单独开发接入服务。有人总想用更重的消息队列直接给设备用我的意见是设备侧做减法平台侧做加法MQTT 做接入、Kafka 做缓冲各司其职。2.3 设备直接 IP 连接还是 DNS 解析这个话题被问得很多“物联网设备一般用 IP 直连还是 DNS 解析”。我的结论很明确生产环境尽量用域名接入小规模测试可以用 IP。原因很简单。平台集群难免要扩容、迁移、更换负载均衡如果用 IP 直连每一次变动都要重新刷设备固件。已经出厂的设备又不能远程改 IP只能派人现场刷机。域名接入只需要在 DNS 层面切解析能省掉大量运维成本。设备端记住一个域名连接失败时用指数退避策略重试不要每秒都去解析一次更不要在断连时同时重连造成“重连风暴”。移动网络下设备 IP 经常变所以设备认证要靠签名或密钥不能靠 IP 白名单这一点后面还会展开。3. 技术栈选型自研还是开源组件拼装IoT 平台没有银弹我从来不建议从头写接入服务和存储引擎。开源生态已经很成熟正确做法是选好组件拼装把精力放在业务逻辑和数据质量上。3.1 接入层和消息中间件的分工设备接入层我首选 EMQX它是基于 Erlang/OTP 的 MQTT Broker开源、单机即可支撑百万级连接社区活跃遇到问题容易查到方案。小项目也可以考虑 Mosquitto功能更简单但集群能力弱。设备数据到达 Broker 之后要不要再放一个 Kafka是很多团队纠结的地方。我的判断标准是如果每秒写入点数只有几百直接用 EMQX 规则引擎写入时序库就够但当你开始做实时计算、告警、数据回放或者打算接多个下游系统时Kafka 就该加入进来了。Kafka 像一个巨大的蓄水池解决的是“上游突发流量”和“下游消费能力不一致”的问题。设备量突然翻倍时EMQX 可以继续吞吐数据先进 Kafka下游实时计算或者入库任务按照自己的节奏拉取不会把数据库打垮。另一个好处是可以重放某个 Flink 任务出了问题改完代码后可以从之前的 offset 重新消费一段数据这在直接写库的方案里很难做到。3.2 存储选型时序库和关系库各司其职时序数据一定要进时序数据库硬塞 MySQL 的教训我在开头已经讲过。小规模场景我用 InfluxDB它安装简单自带连续查询和降采样Grafana 支持也最好。大规模场景我推荐 ClickHouse它的列式存储和压缩特性让相同数据量占用的磁盘远小于普通数据库聚合查询速度也快很多。重要的一点时序库里只放测点数据设备档案、项目信息、用户权限、告警记录这些业务数据还是放 PostgreSQL 或 MySQL。两者是互补关系而不是替代关系。拿设备表举例设备 ID、名称、型号、安装位置属于元数据放关系库这些设备的生产指标随时间变化的值才放时序库。这样查询起来边界清晰不会出现“一张表什么都有”的烂摊子。3.3 实时计算和离线计算怎么选实时链路主流是 Flink它能持续从 Kafka 消费数据做窗口聚合、状态管理再输出到外部存储或告警服务。如果还没有到几十万点/秒的规模直接用轻量规则引擎加 Grafana 告警也能应付不需要一上来就上 Flink。离线链路我一般用 Spark。它适合每天定时跑批量任务计算设备日运行时长、平均负荷、电量趋势再把结果写回 ClickHouse 或 MySQL 供报表使用。也有人问为什么不上 Hive因为大部分物联网离线任务的数据量并没有大到需要 Hive 做 SQL on Hadoop 的程度Spark SQL 足够运维成本却低很多。3.4 可视化组件可视化我会分两层。内部运维和快速展示用 Grafana直接配好时序数据源就能看曲线和告警很多时候业务方看了 Grafana 大屏后连定制开发的需求都砍了一半。面向客户或高层汇报的定制大屏用 ECharts 做前端图表后端接口从聚合数据中取数。Grafana 也不是万能的多项目权限体系和复杂布局还是需要研发投入。4. 设备接入与数据采集从 MQTT 到时序数据库的完整链路这一节是全文最核心的实操部分。我会以一个温湿度监控为例把设备端从上电到数据可查的完整链路走一遍。4.1 统一数据模型是第一步物联网设备五花八门但上报数据的语义可以统一。我建议项目一开始就定义“物模型”把设备能力抽象成三部分属性当前状态、可读可写、事件告警、上下线、服务远程指令。上报报文统一成 JSON最核心的几个字段固定设备标识、事件时间、属性和数据质量。下面是一个简化的温湿度上报 payload{ device_id: env-011, ts: 1700000000000, props: { temperature: 25.3, humidity: 62.1 }, quality: 1 }字段含义不用我多说关键点是 ts 必须用毫秒时间戳而且统一为 UTC。我在项目里见过不少把“本地时间字符串”直接塞进 payload 的设备换时区、混夏令时之后数据根本没法对齐。宁可让采集端多做一个转换也要保证平台侧只认一种时间格式。4.2 Topic 和 QoS 设计的经验MQTT 的 Topic 结构建议带有产品标识和设备标识例如prodA/env-011/properties/post为什么要拆这么细因为规则引擎可以只订阅某个产品、某类事件的 Topic不用在大量业务代码里做过滤。设备端和平台端约定好层级含义以后增加设备类型、增加事件类型都不会破坏已有链路。QoS 等级方面默认用 QoS 1 即可保证消息至少到达一次QoS 2 会带来额外的握手开销设备弱网时反而更容易堆积消息。因为 Kafka 和时序库都有幂等机制重复消息在写入时通过(device_id, ts, prop)去重就能处理。4.3 规则引擎把 MQTT 消息转成标准数据设备消息进入 EMQX 后我不会让每个业务系统直接读 Topic而是用规则引擎做一次解析、过滤和字段映射。例如SELECT payload.device_id AS device_id, payload.ts AS ts, payload.props.temperature AS temperature, payload.props.humidity AS humidity FROM prodA//properties/post WHERE payload.quality 1这条规则有两个效果一是把嵌套 JSON 的字段拍平后续写入 ClickHouse 或 Kafka 时字段名简单二是过滤掉质量标记异常的数据。在车辆、电力这类场景中质量位很常见比如瞬时数据带 0 表示无效不在入口处过滤后面每个分析任务都要重复处理脏数据。4.4 写入时序库批量优先失败可追溯从规则引擎可以直接桥接到 Kafka也可以直接桥接到 InfluxDB。我建议中间走一次 Kafka这样下游写入任务可以做成批量模式。举个例子Flink 读到 Kafka 原始数据后攒 5000 条或 5 秒写一次 ClickHouse能明显减少数据库的小文件和高频锁竞争。同时Kafka Topic 建议按场景拆分原始数据进raw_telemetry归一化数据进processed_telemetry质量有问题但还需要审计的进dead_letter。这样实时计算和报表任务各取所需坏了某条消费链路其他消费者不受影响。5. 实时计算与离线分析数据不只是存起来很多入门项目做到“数据能查曲线”就结束了但物联网平台的真正价值在于让数据产生决策帮助。实时告警和离线报表是两条必须打通的路。5.1 用 Flink 做实时告警拿工厂空压机运行温度举例单看瞬时温度超过 80 度并不一定是故障持续 5 分钟高温才是严重告警。这种“窗口内持续满足条件”的判断用普通 SQL 很难实现Flink 就很顺手。简化后的逻辑像这样DataStreamTelemetry stream env.addSource(kafkaSource); stream .keyBy(t - t.getDeviceId()) .timeWindow(Time.minutes(1)) .aggregate(new AvgTempAggregate()) .filter(avg - avg.getAvgTemp() 80.0) .map(avg - buildAlarm(avg)) .addSink(alarmSink);实际项目里还会加上温度上升速率、连续时间窗口等更复杂的规则。要注意的是Flink 的状态管理和 checkpoint 一定要配置好否则任务重启后会重复发送告警或丢数据。独立项目如果规模不大用 EMQX 规则引擎里的阈值判断加 Kafka Bridge 也能实现简单告警不必照搬整套 Flink 架构。5.2 用 Spark 算日报和月度指标离线计算通常做三件事统计类指标、质量类指标、预测模型的训练样本提取。比如早上 8 点定时跑 Spark 任务从 Kafka 重放昨天的数据算出每台设备最近 24 小时的运行时长、平均功率、温度波动峰值结果写回 MySQL 或 ClickHouse。业务方看报表时只需查聚合结果不需要扫原始表。这也是为什么我在第 3 节强调“不要一上来就 Hadoop”很多物联网平台的离线任务一天跑一次数据量在几百 GB 以内一台 Spark Standalone 集群足够架构更大只会带来多出几倍的 Hadoop 运维负担。等真正需要海量历史数据关联分析的时候再升级集群也不迟。5.3 数据质量检查要前置数据质量检查框架不是可有可无的点缀而是平台上线后最容易被忽略又最后悔不做的事。设备在恶劣环境下经常损坏传感器老化、接线松动、信号遮挡都会让上报值变成垃圾但如果不做检查报表和模型都会被带偏。我常用的质量规则大概如下检查项规则示例处理策略缺失率单台设备 1 小时上报条数低于预期 80%产生设备离线/采集异常告警越界值温度超过量程上限或低于下限打质量标签且不参与聚合重复率同一设备连续 10 条数据完全一致且非心跳周期提示传感器可能卡死时间漂移事件时间与接收时间差超过 30 秒标记为乱序单独审计质量检查任务可以每天跑一次也可以由 Flink 在实时链路上给每条数据打quality_flag。建议两条腿都走实时打标用于告警离线复核用于生成月度质量报告。有了这个框架后期做预测性维护才能拿到真正可用的训练数据。6. 数据可视化与对外服务接口6.1 先搞清楚大屏只是门面不是平台本身我见过不少团队把“可视化大屏”当成物联网平台的核心工作花几个月做炫酷动画结果业务人员连设备离线列表都查不到。真实项目里最先要解决的是三个高频需求设备实时状态、历史曲线查询、告警列表。Grafana 配合时序库半天就能把这三个能力搭起来再决定要不要做定制大屏。如果确实需要定制大屏前端用 ECharts 画折线图、热点图都方便。配合 WebSocket 推送实时数据大屏就能做到秒级刷新。需要特别提醒的是大屏的数据接口尽量用聚合数据不要直接在大屏代码里查原始明细1 万个点的散点图会把浏览器卡死。6.2 统一数据 API 层的权限边界设备数据是系统型资产不可能让每个业务系统直接连 Kafka 或者 ClickHouse。正常情况下我会在数据平台之上提供一层统一 APIGET /api/telemetry/latest?deviceIdenv-011 GET /api/telemetry/history?deviceIdenv-011start...end...agg1m GET /api/alarms?project...page1API 层的价值不只是格式统一更重要的是权限控制哪些用户可以看哪些项目、哪些设备写接口还要做调用频率限制。多项目共用平台时权限尤其重要。我的习惯是“以项目为控制主体”用户在 API Token 上绑定可见项目集合后端每个查询自动追加项目过滤条件而不是靠前端隐藏页面。6.3 WebSocket 做实时推送看板、App、微信告警推送都需要主动推送能力。通常我用 Redis 做订阅集合实时计算任务产生新结果后把消息推到 Redis ChannelAPI 网关通过 WebSocket 推给前端。Kafka 也能做推送传输但它更适合服务端到服务端的可靠流转直接连浏览器并不合适。把推送逻辑单独拆成一个轻服务扩展多个前端项目会更方便。7. 上线部署踩坑实录那些折腾到半夜的问题7.1 设备端时间不一致导致乱序第一次上线时我发现曲线偶尔往回走查了一夜发现是设备本地时钟不准。有的设备用网络对时有的完全没有任何同步各台设备时间差最多能到几十秒。数据写入库之后按时间排序就乱套了。后来我在数据模型里加了两个时间字段event_time设备事件时间和arrive_time平台接收时间。告警和趋势分析都用 event_time但校验会参考 arrive_time设备端全部配置 NTP 对时采集程序启动时先检查本地时间偏差超过 5 秒直接拒绝发送。没有这一步后面的窗口计算全是错的。7.2 Kafka 分区数只增不减启动前就要规划我遇到过业务增长后消费者 Lag 涨到几百万加消费者进程却发现并发上不去的场景。原因很简单Kafka 一个分区同时只能被同一消费组的一个消费者消费消费者数超过分区数时多余消费者只能闲着。分区数虽然可以后续增加但增加后分区之间的数据分布不会自动重新平衡且分区数只能增不能减。所以刚搭 Kafka 时就要按未来一年设备量估算分区数。我的经验是分区数至少是消费并行度的 3 倍宁可多一点。如果 Topic 已建好最好在一开始就把分区设置成 12 或 24而不是到了生产环境再临时改。7.3 网络抖动引发“重连风暴”第一次把平台从几百台设备扩容到几千台时恰好赶上工厂网络调整EMQX 集群瞬间涌入大量连接请求CPU 拉满部分设备连接失败后又立刻重连雪球越滚越大。这个问题的根因是设备端的重连策略太简单失败就毫秒级重试。正确做法是让设备端采用退避重连第一次失败等 1 秒第二次等 2 秒、4 秒、8 秒最多到 60 秒并在每次重试前加一个 0.5 到 1 秒的随机抖动。这样几千台设备不会同时撞在同一个时间点发起连接Broker 的压力会平摊开。7.4 时序库写入磁盘 IO 过高数据量上来之后ClickHouse 的写入性能看起来没问题但磁盘 IO 报警却很频繁。排查下来是日志、合并任务和多路写入互相抢 IO加上机械硬盘本身吞吐有限。之后我把数据盘换成了 SSD并把写入任务做了合并单次写入行数尽量在 5000 以上。时序库“频繁小批量写”是性能杀手这一点无论用 InfluxDB 还是 ClickHouse 都一样。8. 资源评估与成本控制8.1 从数据量估算服务器配置不要按“别人用了什么配置”来买机器要按实际数据量算。估算公式每天数据量(GB) ≈ 每秒写入点数 × 平均单点字节数(B) × 86400 ÷ 1024 ÷ 1024 × 压缩系数举一个具体例子每秒 5000 点每条消息含设备信息大约 200 字节一天原始数据约 80GB如果压缩比按 5:1 算落到 ClickHouse 大约 16GB保留 30 天需要约 500GB 存储。对照这个结论初期一台 16 核 64G 的机器加两块 SSD 就能跑起来根本不需要一开始就配一个六节点集群。规模建议最低配置组件千台设备级分钟级上报2 台 8C16GEMQX Kafka InfluxDB Grafana万台设备级秒级上报4~6 台 16C64GEMQX 集群 Kafka 集群 ClickHouse Flink十万台设备级亚秒级按 TPS 单独压测所有组件集群化 专职运维8.2 冷热分层是最省钱的优化手段很多平台运行半年后磁盘吃紧就是因为原始数据舍不得删又没有配置降采样。我的方案是原始数据保留 7 天随后把分钟级、小时级聚合数据保留一年一年后的数据压缩后存入对象存储。这样热数据的查询性能不会因为历史数据膨胀而下降成本也大幅降低。InfluxDB 的 Continuous Query 和 ClickHouse 的物化视图都能实现自动降采样配置好一次以后就定期执行。8.3 先跑通最小闭环再逐步加组件最后聊一下实施节奏。我的建议是按这个顺序走每一阶段都在真实可用后再进入下一阶段EMQX 时序库 Grafana先用脚本模拟 100 台设备上报跑通端到端加自动化告警和消息通知让监控真正可用当设备量翻倍、入库成为瓶颈时加入 Kafka 做缓冲开始有复杂实时计算需求时再引入 Flink报表需求明确后再加 Spark 离线任务。这套路径的好处是每个阶段的系统都能独立工作不会出现“平台还没建完数据已经堆积成山”的尴尬。实际项目里真正需要全套大数据组件的平台比例并不高大部分场景跑到第 2 步就已经覆盖了核心需求。最后再分享一条个人经验。我做了几年物联网数据相关项目最大的体会是平台的价值不在于用了多少“大数据”组件而在于数据链路是否稳定、数据质量是否可信、业务方能否快速拿到想要的答案。从零开始搭建时把需求和数据量先算清楚选择简单可靠的技术栈保持每一环都可拆解、可扩展比一开始就追求集群规模要重要得多。希望这篇指南能让你少走几步弯路。