​DolphinDB 物联网数据平台全景：一份从架构到落地的实践地图

摘要

工业物联网普遍陷入"数据采得起、却治不动"的困境：传感器越装越多、采集频率越提越高，原始数据却堆成山、查询越来越慢、磁盘越扩越大。根因往往不是数据库不够先进，而是治理没跟上。

本文以 DolphinDB 一体化时序数据平台为对象，把物联网数据从"采得进来"到"用得起来"的整条链路拆成五个阶段——采集接入、存储治理、实时计算、分析挖掘、协同运维——逐阶段讲清架构选型与设计原则。全文提炼出"分区是地基、高频必降采样、TTL 删分区、流批一体、库内分析不搬数据、断网续传三件套"等七条可落地设计原则，并给出选型建议。

决定一个物联网平台能否长期跑下去的，是治理有没有跟上，而非某项功能是否先进。

一、引言：物联网的"治理鸿沟"

工业物联网做久了会出现一个反直觉的现象：传感器越装越多、采集频率越提越高，数据真正能用起来的比例反而越来越低。原始数据堆成山，查询越来越慢，磁盘越扩越大，可业务侧要"昨天某台设备每分钟的振动趋势"，还是要等十几秒甚至超时。

这背后的根因，往往不是数据库选得不够"先进"，而是治理没跟上。一个物联网平台能不能长期跑下去，取决于那些"脏活累活"有没有做对：分区怎么切、高频数据怎么降采样、过期数据怎么清、查询怎么不退化、断网时数据会不会丢。

本文要回答的核心问题是：DolphinDB 作为一体化时序数据平台，如何把这条从采集到落地的链路收拢，让物联网数据"治得动、用得起、跑得稳"。

二、物联网数据的四重矛盾

理解任何技术选型，先要理解它要解决的问题。物联网数据呈现四重矛盾，传统"拼装式"架构几乎每一重都会踩坑：

围绕这三组问题（带宽/延迟/可靠性，外加存储成本与查询退化），业界形成了若干工程共识。本文把它们组织成一条五阶段链路，每个阶段对应一组设计原则。

三、五阶段链路与平台全景

一条物联网数据，从产生到产生价值，要走完五个阶段：

① 采集接入  →  ② 存储治理  →  ③ 实时计算  →  ④ 分析挖掘  →  ⑤ 协同运维
 (协议/云边)   (分区/降采样/TTL)  (流批一体)    (库内分析/ML)   (多中心/信创)

DolphinDB 的差异化在于：这五个阶段由同一个引擎、一份存储、一套 SQL 承载，而不是由五六个独立组件拼起来。这正是它 "DATABASE + ANALYTICS + STREAMING" 三位一体定位的实质含义。

img

平台层面的关键能力清单：

• 多模存储引擎：TSDB（时序）、OLAP（分析）、IMOLTP 三种引擎各司其职，共用分布式存储。
• 流批一体：批计算研发的指标代码可直接用于流计算，无需两套代码。
• SQL + JIT：标准 SQL 交互，关键算子即时编译加速。
• 工业协议原生接入：MQTT、OPC UA/DA、Modbus、IEC 104 直达引擎，省去中间网关。
• 丰富 API 与生态：C++/Java/C#/Python/Go/R/JavaScript/Rust 接口；对接 Grafana、SmartBI、Kafka、HDFS、Prometheus 等。
• 信创国产化：适配龙芯/鲲鹏/飞腾/兆芯/海光 CPU 与统信 UOS/银河麒麟等 OS，满足自主可控。

下面逐阶段展开。

四、采集接入：协议直达与云边协同

4.1 设计原则

1. 协议原生接入，少一跳：让工业协议数据直达数据库引擎，而非"PLC → 边缘网关 → Kafka → 时序库"三跳。每少一跳，就少一个故障点和一层延迟。
2. 原始数据不全量上云：边缘先做数据瘦身，把高频原始数据降采样成低频特征再上云。一座 200 万测点的水电站，全量直传带宽成本不可接受。
3. 断网时现场不停：边缘必须能独立完成本地实时决策；断网期间数据缓存，恢复后自动补传、不丢不重。

img

4.2 平台支撑

• 协议层原生支持 MQTT / OPC UA/DA / Modbus / IEC 104，覆盖绝大多数工业现场。
• 边缘节点是一个完整但轻量（部署包几十 MB）的数据库实例，可与云端共用同一套脚本。边缘用时间序列聚合引擎做实时降采样，把上云数据量压几个数量级。
• 跨集群流订阅是上云主干道：云端订阅边缘聚合流，配合 reconnect（断线重连）与 offset（断点续传），实现断网续传。
• 断网续传的可靠性靠三件套：边缘持久化流表兜底、订阅位点续传、云端 PKEY 引擎幂等去重。

跨集群订阅的"断网续传"，核心就靠下面两个参数：

// 云端订阅边缘聚合流：reconnect 断线重连 + offset 从上次断点续传
subscribeTable(host="edge-site-01", port=8848, tableName="aggStream",
    actionName="collectFromEdge",
    handler=tableInsert{loadTable("dfs://cloud", "siteAgg")},
    msgAsTable=true, reconnect=true, offset=-1)
// 配合边缘持久化流表，断网期间数据缓存、重连后补传，云端 PKEY 主键去重保证不重不漏

五、存储治理：让数据"治得动"

这是最容易被忽视、却决定平台能跑多久的一环。宣传册与工程实践都指向同一组原则。

5.1 设计原则

1. 分区是查询性能的地基：DolphinDB 查询性能七成取决于分区设计。工业场景的标准范式是日期 VALUE + 设备 HASH 复合分区——日期分区支撑时间范围裁剪与按天 TTL，设备 HASH 分区支撑按设备并行计算。
2. 高频数据必须分层降采样：原始层只留近期（7~30 天）供故障回溯，分钟层/小时层供长期趋势分析。把所有分析都跑在原始高频数据上，查询慢且存储成本失控。
3. TTL 靠删分区实现：按天分区的直接好处是过期清理只需 dropPartition 删整个分区文件，秒级完成，远比逐行 delete 轻量。
4. 列存压缩是隐形的成本杠杆：工业时序数据时间连续、数值渐变，列式压缩（Delta-of-Delta/CHIMP/ZSTD）实测可达 10:1~20:1，直接决定存储成本是"能接受"还是"吓人"。
5. 分区粒度有甜区：单分区数据量控制在 1~10GB 比较稳妥；太细元数据膨胀，太粗裁剪后仍要扫太多数据。

把"分区是地基"和"高频必降采样"落到代码上，大致是这样：

// 复合分区：一级日期 VALUE（支撑时间裁剪与按天 TTL）+ 二级设备 HASH（支撑并行）
db1 = database("", VALUE, 2024.01.01..2025.12.31)
db2 = database("", HASH, [SYMBOL, 20])
db  = database("dfs://iot", COMPO, [db1, db2])

// 降采样管道：每天凌晨把昨日原始数据聚合成分钟级，长期保留
def downsampleToMinute() {
    result = select minute(ts) as ts, deviceId,
                   avg(vibration) as vibMean, percentile(vibration, 95) as vibP95
            from loadTable("dfs://iot", "sensor")
            where date(ts) = date(now()) - 1
            group by minute(ts), deviceId
    loadTable("dfs://iot_min", "sensor_min").append!(result)
}
scheduleJob("downsampleMin", "raw to minute", downsampleToMinute, 01***)

5.2 平台支撑

• TSDB 引擎为行列混存（PAX）+ 列式压缩，自动选择最优压缩算法。
• COMPO 复合分区 + 分区裁剪，让"带时间条件"的查询只扫目标分区。
• 冷热分层：不同分区可配置不同存储介质（SSD/HDD/对象存储），热数据快、冷数据省。

六、实时计算：流批一体与实时告警

6.1 设计原则

1. 流批一体，一套代码两用：实时流与历史批处理共用同一套指标代码，避免"实时一套、离线一套"的双份维护。
2. 时域走流、频域走定时：计算量小、对延迟敏感的特征（如峭度）挂流引擎做亚毫秒级预警；计算量大、需完整波形的分析（如 FFT）走定时批量。这是工程上务实的实时化分层。
3. 增量计算保住实时性：窗口函数（mavg/mstd/msum）通过维护累加状态把每窗口计算压到 O(1)，使高阶统计量也能实时。

增量计算 + 保序的写法，要点都藏在一行 context by ... csort ... 里：

// context by 按 deviceId 分组，csort 保证组内时间有序；
// mavg/mstd 内部增量计算，复杂度 O(n) 而非 O(n*k)
select deviceId, ts,
       mavg(vibration, 60) as vib_ma60,
       mstd(vibration, 60) as vib_std60
from sensor
where date(ts) = 2024.06.15
context by deviceId csort ts   -- 少了 csort，移动窗口结果会错

6.2 平台支撑与案例

img

宣传册中的无人工厂案例很有代表性：

• 集群规模：3 台 4 核 32GB 服务器（双副本）；
• 写入吞吐：实时写入 32.4 万点/秒，满足每秒 30 万+ 写入需求；
• 查询性能：百亿数据量级下即席查询毫秒级响应；
• 异常检测：实时计算引擎用简单表达式定义复杂异常规则，主动推送；
• 高可用：元数据/数据/客户端三层高可用，容忍单机故障。

这个案例的核心价值是轻量集群扛住高吞吐——用很小的硬件投入满足实时监控，而非堆硬件。

七、分析挖掘：从监控到预测性维护

实时告警解决"有没有问题"，预测性维护要回答"是什么问题、什么时候坏"。这要求把分析能力沉到数据所在的地方。

7.1 设计原则

1. 库内分析，避免数据搬运：把分析逻辑跑在数据所在的库内，而不是"波形存 A、转速存 B、FFT 导到 C、结果回 D"。链路一长，实时性、可靠性、开发效率全下来。
2. 时域筛异常、频域定病因：时域特征（峭度、峰值因子）对早期轴承故障最敏感，用来筛可疑设备；频域 FFT 把特征频率找出来，定位故障类型。
3. 变工况必须先对齐：设备转速随负载波动，固定转频做频域诊断会错得离谱。用 asof join 把高频振动与低频工况在原始层对齐，再按工况分桶诊断。

工况对齐与频域诊断，都能在库内一行脚本完成，不必把波形导到外部工具：

// asof join：为每条高频振动记录，找同设备、时间不晚于它的最近一条转速
select ts, xAxis, rpm from aj(
    loadTable("dfs://vib", "vibration"),
    loadTable("dfs://vib", "condition"), `deviceId)
// 对齐后按转速分桶做 FFT：取一段波形 → fft → imax 定位主频
mainFreq = imax(abs(fft(wave))[0 : n/2]) * sampleRate / n

7.2 平台支撑与案例

• signal 插件集成 FFTW3，内置 fft/ifft/小波变换，全部向量化优化；内置 kurtosis/skew/imax 等高阶统计与索引函数。
• 机器学习插件（xgboost、svm）、信号算法（FilterPicker、RTSeis、TensorFlow）可在库内完成特征提取与模型推理。

img

几个体现"库内分析 + 架构收敛"价值的案例：

八、协同运维：性能、规模与多中心

8.1 性能与规模底座

img

车联网案例给出了 DolphinDB 在极端规模下的表现：

• 写入速率：1.8 亿点/秒不间断写入，且支持乱序数据写入；
• 资源效率：写入过程中资源利用率稳定在 40% 左右，保证稳定性；
• 查询延迟：单点查询平均 100ms 以内；
• 宽表支持：单车测点达 7000，需大宽表存储与计算支持；
• 实时预警：异常检测引擎毫秒级输出告警。

这套底座让"海量轨迹存储 + 车辆/订单关联聚合 + 结果直接输出"的完整流程在一个轻量化架构内跑通。

8.2 异地多中心与容灾

对于跨地域的大型企业，数据中台还要解决多中心协同。某世界 500 强企业的案例：

• 跨集群异步复制：以事务为单位，同时支持 DDL 与 DML，保障多集群数据一致性；
• 规模：集群间同步超 4000 张表，单表数据量最高达千亿级；
• 低延时同步：百万级数据毫秒级同步延迟；
• 运维体系：备份恢复、实时校验、数据补差、权限认证、安全机制、高可用集群、异地容灾一体化。

九、整体架构与数据流转全景

把五个阶段拼起来，就是以 DolphinDB 为底座的物联网数据平台整体架构：

img

• 数据源层：IoT 终端、ERP/RDBMS 业务系统、CSV/XML/文档等异构来源。
• 接入层：TCP/IP、FTP、JDBC、API、HDFS；实时流可经 Kafka；调度由 DolphinScheduler/Airflow 等协同。
• DolphinDB 底座：统一完成实时入库、流计算、ETL、历史存储与分析查询，替代传统链路中"消息队列 + 缓存 + 时序库 + 数仓"的多重组件。
• 消费层：经 JDBC/API 对接 MongoDB、ElasticSearch、HDFS、Neo4j、MySQL 等下游，支撑 BI 报表、监控大屏、业务应用。

这张图的关键价值是纵向打通、横向收敛：一条数据从设备到应用不再多次落盘搬运；实时与离线、交易与分析共用同一平台，从根本上消除 ETL 搬运的延迟与一致性风险。

十、选型建议与七条设计原则

10.1 何时该用，何时不必

客观地说，DolphinDB 并非所有 IoT 场景的最优解（三篇专题的"局限"章节都有论述）：

• 该用：数据量大、计算复杂、需长期治理、多站点云边协同、需库内信号处理/机器学习的规模化场景。
• 不必用：几十个传感器、只需 Grafana 看板、阈值告警即可的轻量场景——InfluxDB + Grafana 更轻、上手更快。
• 不适用：要求云边/多系统强一致（金融级）的场景，最终一致架构本身不合适。

10.2 七条设计原则

1. 协议直达，少一跳——工业协议原生接入，省网关、省延迟、省故障点。
2. 分区是地基——日期 VALUE + 设备 HASH 复合分区，单分区控制在 1~10GB。
3. 高频必降采样——原始层短期 + 降采样层长期，成本与价值兼顾。
4. TTL 删分区——按天分区让过期清理秒级完成。
5. 流批一体，时域走流频域走定时——一套代码两用，实时化分层务实。
6. 库内分析，不搬数据——把分析沉到数据所在地，链路收敛保实时。
7. 断网三件套 + 心跳监控——持久化流表、offset 续传、PKEY 幂等去重，外加心跳兜底，做到不丢不重不断可监控。

十一、总结

物联网数据的价值，取决于能否在海量、高速、繁杂的条件下，依然做到实时可见、可算、可用。DolphinDB 以一体化时序数据平台为定位，把存储、流计算与分析合而为一，从协议接入到库内机器学习，全链路收敛技术栈。

但真正决定一个平台能不能长期跑下去的，不是某一项功能的"先进"，而是治理有没有跟上——分区、降采样、TTL、断网续传、工况对齐，这些工程细节组合起来，决定了一个物联网平台是"跑 demo 很炫、上线三个月就卡"，还是"能稳定承载长期业务"。

数据治理这件事，没有什么惊天动地的黑科技，全是把对的细节在对的地方做对。希望这张全景地图，能帮你在选型与落地时少走弯路。