在过去的大数据架构选型中,当我们提到'海量时序数据存储'时,脑海中浮现的第一个方案往往是:Hadoop + HBase + OpenTSDB。
这套方案在互联网时代通过了考验,但在面对工业物联网(IIoT)、车联网以及新能源场景时,却显得越来越'重'。
今天,我想从架构演进和底层原理的角度,聊聊为什么 Apache IoTDB 会成为下一代时序数据库选型的'版本答案'。

一、传统 NoSQL 方案的'隐形债务'
在 2015 年左右,为了存储传感器数据,我们维护了一套庞大的 Hadoop 集群。虽然 HBase 的写入性能强悍,但我们在实际运维中遇到了一系列痛点:
- 架构过重,运维噩梦:为了存点电表数据,我们需要维护 HDFS、Zookeeper、HBase RegionServer 等一系列组件。任何一个环节抖动,都会导致写入失败。
- 压缩率不够极致:HBase 本质上是 KV 存储,它并不理解'时间序列'数据的特征。虽然有 Snappy/Gzip,但面对浮点数(Float/Double)序列,压缩效果远不如专用的二阶差分算法。
聚合查询慢:如果我想查询'过去一年的平均温度',OpenTSDB 需要把所有点扫描出来再计算,I/O 开销巨大。

二、原生 TSDB 的破局之道:轻量与极致
Apache IoTDB (Internet of Things Database) 的出现,恰恰解决了上述痛点。它不再依赖 Hadoop 生态,单机即可运行,同时也支持分布式集群。
1. 核心架构:为时序而生的 LSM 树
不同于通用的 RocksDB 或 HBase,IoTDB 对 LSM-Tree (Log-Structured Merge Tree) 进行了针对性改造。它将数据分为顺序数据(Sequence)和乱序数据(Unsequence)。
- 顺序数据:直接追加写入,吞吐量极高。
- 乱序数据:当设备时钟不同步或网络延迟导致数据迟到时,数据会写入乱序空间,通过后台的 Compaction 机制异步合并。
内存满 写入请求 预写日志 WAL MemTable 内存表 刷盘操作 顺序 TsFile 乱序 TsFile 合并 Compaction 合并后的 TsFile
这种分离设计,保证了在处理高达 90% 的顺序写入场景下,磁盘几乎全是顺序写(Sequential Write),性能直接拉满。
2. 存储黑科技:TsFile 文件结构
如果说 LSM 是骨架,那么 TsFile 就是 IoTDB 的灵魂。
很多数据库底层还在用 Parquet 或 ORC,但 TsFile 是专门为时序设计的。它的层级结构如下:
- Page: 最小的数据块,直接存储压缩后的时间值对。
- Chunk: 由多个 Page 组成,存储一段时间内某个传感器的数据。
- ChunkGroup: 对应一个设备(Device),包含该设备下所有传感器在同一时间段的 Chunk。



