在过去的大数据架构选型中，当我们提到'海量时序数据存储'时，脑海中浮现的第一个方案往往是：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。
