在大数据架构选型中，提到'海量时序数据存储'，传统方案往往是 Hadoop + HBase + OpenTSDB。这套组合在互联网时代表现尚可，但在工业物联网（IIoT）、车联网及新能源场景下，显得过于沉重。
从架构演进和底层原理来看，Apache IoTDB 正逐渐成为下一代时序数据库的优选。它不再依赖庞大的 Hadoop 生态，单机即可运行，同时也支持分布式集群扩展。
一、传统 NoSQL 方案的痛点
早期为了存储传感器数据，我们曾维护过庞大的 Hadoop 集群。虽然 HBase 写入性能强悍，但实际运维中存在明显瓶颈：
- 架构过重：存储电表数据需维护 HDFS、Zookeeper、HBase RegionServer 等组件，任一环节抖动都可能导致写入失败。
- 压缩率不足：HBase 本质是 KV 存储，不理解时序特征。即便使用 Snappy/Gzip，面对浮点数序列，压缩效果远不如专用的二阶差分算法。
- 聚合查询慢：查询'过去一年平均温度'时，OpenTSDB 需扫描所有点再计算，I/O 开销巨大。
二、原生 TSDB 的破局之道
1. 核心架构：为时序而生的 LSM 树
IoTDB 对 LSM-Tree 进行了针对性改造，将数据分为顺序数据（Sequence）和乱序数据（Unsequence）：
- 顺序数据：直接追加写入，吞吐量极高。
- 乱序数据：处理设备时钟不同步或网络延迟导致的迟到数据，写入乱序空间，通过后台 Compaction 机制异步合并。
这种分离设计保证了在处理高达 90% 的顺序写入场景下，磁盘几乎全是顺序写，性能直接拉满。
2. 存储黑科技：TsFile 文件结构
如果说 LSM 是骨架，TsFile 就是灵魂。不同于 Parquet 或 ORC，TsFile 专为时序设计：
- Page：最小数据块，存储压缩后的时间值对。
- Chunk：由多个 Page 组成，存储一段时间内某个传感器的数据。
- ChunkGroup：对应一个设备（Device），包含该设备下所有传感器在同一时间段的 Chunk。
这种'以设备为中心'的物理存储结构，使得查询'某台设备的所有状态'时，磁盘 I/O 极其连续，效率极高。
三、查询性能与代码实战
选型时不能只看写入，查询性能才是决定业务响应速度的关键。
降采样查询（Downsampling）
在可视化大屏展示'过去 24 小时'温度曲线时，通常不需要秒级数据，只需'每分钟一个点'。在传统数据库中，这需要应用层查全量后自行计算。
IoTDB 支持数据库层面的降采样聚合，数据在磁盘读取阶段就被聚合，传输到应用层的数据量仅为原来的 1/60。以下是使用 Java Session API 进行降采样查询的示例：
import org.apache.iotdb.session.Session;
import org.apache.iotdb.tsfile.read.common.RowRecord;
import org.apache.iotdb.isession.SessionDataSet;
public class IoTDBQueryDemo {
public static void main(String[] args) throws Exception {
// 1. 构建连接
(, , , );
session.open();
+
;
( session.executeQueryStatement(sql)) {
System.out.println();
System.out.println();
(dataSet.hasNext()) {
dataSet.next();
System.out.println(rowRecord.getTimestamp() + + rowRecord.getFields().get().getStringValue());
}
}
session.close();
}
}
