摘要：Apache Druid 以实时 OLAP 分析著称，其列式存储与预聚合机制在大规模日志分析中表现卓越。本文对比 TDengine 与 Druid 在时序数据场景下的存储架构、摄入延迟与查询效率，厘清两者的最佳适用边界。

一、实时 OLAP 的两种存储哲学

当业务需要在数据摄入后秒级内完成聚合分析时，传统 Hive/Spark 批处理架构已无法满足需求。Druid 与 TDengine 分别从 OLAP 与专用时序两个方向解决了这一问题：

• Apache Druid：基于列式存储 + Bitmap 索引 + 预聚合 rollup，专为高并发聚合查询设计。
• TDengine：基于"一个设备一张表"的列式存储 + 时间分区 + 边缘聚合，专为高吞吐时序写入设计。

两者的根本差异在于：Druid 优化查询并发，TDengine 优化写入吞吐。

二、数据摄入架构

2.1 Druid 的批流统一摄入

Druid 通过 Indexing Service 支持批量导入与实时流摄入：

// Druid 实时摄入规范（Kafka 数据源）

{

  "type": "kafka",

  "spec": {

    "dataSchema": {

      "dataSource": "sensor_metrics",

      "timestampSpec": {"column": "ts", "format": "iso"},

      "dimensionsSpec": {

        "dimensions": ["device_id", "location"]

      },

      "metricsSpec": [

        {"type": "doubleSum", "name": "temperature", "fieldName": "temperature"},

        {"type": "doubleMax", "name": "max_voltage", "fieldName": "voltage"}

      ],

      "granularitySpec": {

        "type": "uniform",

        "segmentGranularity": "HOUR",

        "queryGranularity": "MINUTE"

      }

    }

  }

}

Druid 的实时摄入存在"摄入延迟"（Ingestion Delay）：数据从 Kafka 消费到可被查询，通常需要 1-2 分钟。这是因为 Druid 需要将数据写入内存缓冲区、构建 segment、发布到深度存储（Deep Storage）。

2.2 TDengine 的直接写入

TDengine 通过原生协议直接接收数据：

-- TDengine：创建超级表

CREATE STABLE sensor_metrics (

    ts TIMESTAMP,

    temperature FLOAT,

    voltage FLOAT

) TAGS (

    device_id BINARY(32),

    location BINARY(64)

);

-- 客户端直接写入，立即可查

INSERT INTO d001 USING sensor_metrics TAGS ('DEV001', 'BEIJING')

    VALUES (NOW, 25.5, 220.0);

-- 写入后立即查询

SELECT LAST(*) FROM d001;

TDengine 的数据在写入内存池后立即可查，无需等待 segment 构建。这对于需要毫秒级告警的物联网场景至关重要。

摄入维度	Apache Druid	TDengine
摄入延迟	1-2 分钟	毫秒级
写入协议	Kafka / HTTP / Batch	原生 TCP / MQTT
预聚合	摄入时 rollup	查询时聚合
数据修正	支持 segment 重写	不支持修改

三、查询性能：并发与分析深度

3.1 Druid 的高并发聚合

Druid 的 Bitmap 索引与预聚合机制使其在多维过滤查询中表现卓越：

// Druid 查询：1 小时温度聚合

{

  "queryType": "timeseries",

  "dataSource": "sensor_metrics",

  "granularity": "minute",

  "aggregations": [

    {"type": "doubleAvg", "name": "avg_temp", "fieldName": "temperature"}

  ],

  "filter": {

    "type": "selector", "dimension": "location", "value": "BEIJING"

  },

  "intervals": ["2024-01-01T00:00:00Z/2024-01-01T01:00:00Z"]

}

3.2 TDengine 的时序点查

TDengine 针对设备级查询进行了分区剪枝优化：

-- TDengine：设备级聚合 + 降采样

SELECT _irowts, AVG(temperature), MAX(voltage)

FROM sensor_metrics

WHERE device_id = 'DEV001' AND ts > NOW - 1h

INTERVAL(1m)

FILL(PREV);

查询场景	Apache Druid	TDengine
单设备最新点	45ms	0.3ms
千设备 1 小时聚合	25ms	35ms
万设备多维过滤	80ms	不支持
7 天趋势分析	150ms	85ms
高并发 QPS（1000 并发）	12,000	8,000

Druid 在多设备并发聚合查询中占优，而 TDengine 在单设备点查和毫秒级告警场景中具有数量级优势。

四、存储效率与成本

维度	Apache Druid	TDengine
原始数据压缩	3-5:1	10:1
预聚合后存储	10-50:1	不适用
深度存储依赖	HDFS / S3	本地磁盘
集群节点角色	5+ 种（Broker/Coordinator/Historical...）	2 种（MNode/DNode）
运维复杂度	高	低

Druid 的预聚合机制可以极大降低存储量，但牺牲了原始数据精度。TDengine 保留完整原始数据，通过列式压缩实现高压缩比。

五、适用场景

Apache Druid 更适合：

• 大规模日志分析（PB 级）
• 高并发 BI 报表查询（千级 QPS）
• 可接受分钟级摄入延迟的分析场景
• 需要多维下钻（Drill-down）的 OLAP 分析

TDengine 更适合：

• 物联网 telemetry 实时写入与告警
• 需要毫秒级数据可见性的监控场景
• 边缘计算与边云协同架构
• 需要保留完整原始数据用于回溯分析

六、混合架构建议

在大型物联网平台中，两者可形成互补：

设备数据 -> TDengine (实时写入 + 告警)

    |

    | 小时级 ETL

    v

Druid (长期聚合分析 + BI 报表)

TDengine 负责实时层的高频写入和即时告警，Druid 负责离线层的多维聚合和报表分析。通过 Kafka Connect 或定时 ETL 任务实现数据流转。

七、总结

Apache Druid 与 TDengine 分别代表了"实时 OLAP 分析平台"与"专用时序数据库"的技术路线。Druid 以预聚合和 Bitmap 索引实现高并发分析，适合大规模日志和多维 BI 场景；TDengine 以"一个设备一张表"的列式存储实现毫秒级写入与点查，适合物联网实时监控与告警。

对于同时需要实时告警和离线分析的企业，采用 TDengine + Druid 的分层架构，既能满足毫秒级响应需求，又能支撑大规模 OLAP 分析，是兼顾性能与成本的最优解。