TL;DR

• 场景：实时/时序 OLAP，亿级明细，低延迟看板与多维分析。

• 结论：按时间 Chunk→Segment 列存 + Roll-up + Bitmap 索引 + mmap + 多级缓存；索引服务 Overlord/MiddleManager/Peon 负责摄入与任务。

• 产出：存储/查询机制要点、检查清单、常见坑位修复思路。

数据存储

Druid 的数据存储架构

Druid 中的数据存储采用分层逻辑结构，主要包含以下几个层次：

1. DataSource（数据源）

• 概念类比：DataSource 类似于关系型数据库(RDBMS)中的 Table 或数据表

• 功能定位：作为数据的顶层容器，一个 DataSource 包含特定业务领域的所有相关数据

• 示例：电商网站可能创建"user_behavior"、"product_inventory"等 DataSource 来存储不同业务数据

2. Chunk（时间块）

• 时间分区：每个 DataSource 的数据按照时间范围划分，形成 Chunk

• 分区粒度：可根据业务需求配置不同的时间粒度：

• 常见配置：天(1d)、小时(1h)、周(1w)等

• 示例：按天分区时，2023-01-01 就是一个独立的 Chunk

• 查询优势：这种按时间划分的结构使时间范围查询非常高效

3. Segment（数据段）

• 物理存储：Segment 是数据的实际物理存储单元，每个 Segment 都是一个独立文件

• 数据规模：一个 Segment 通常包含几百万行数据(约 500 万行)

• 文件特性：Segment 文件采用列式存储格式，具有压缩和索引特性

• 并行处理：Druid 可以并行加载和处理多个 Segment

数据分布机制

• 时间顺序：Segment 严格按照时间先后顺序组织在 Chunk 中

• 分布式存储：Segment 会被分布式存储在 Druid 集群的多个节点上

• 副本机制：为确保高可用，每个 Segment 会有多个副本(通常 2-3 个)存储在不同节点

查询优化

• 时间过滤：查询时系统首先确定涉及的时间范围(Chunk)

• Segment 筛选：然后只加载相关 Chunk 中的 Segment 文件

• 性能优势：这种机制大幅减少了需要扫描的数据量，特别适合时间序列数据分析场景

实际应用示例

1. 监控系统：每分钟生成一个 Segment，每小时形成一个 Chunk

2. IoT 数据处理：按设备 ID+时间双重维度组织 Segment

3. 广告分析：每天创建一个 Chunk，按广告主 ID 进一步细分 Segment

通过这种分层存储结构，Druid 能够高效处理大规模时间序列数据，同时保持良好的查询性能。

数据分区

• Druid 处理的是事件数据，每条数据都会带有一个时间戳，可以使用时间进行分区

• 上图指定了分区粒度为天，那么每天的数据都会被单独存储和查询

Segment 内部存储

• Druid 采用列式存储，每列数据都是在独立的结构中存储

• Segment 中的数据类型主要分为三种：

• 类型 1 时间戳：每一行数据，都必须有一个 TimeStamp，Druid 一定会基于事件戳来分片

• 类型 2 维度列：用来过滤 Fliter 或者组合 GroupBY 的列，通过是 String、Float、Double、Int 类型

• 类型 3 指标列：用来进行聚合计算的列，指定的聚合函数 sum、average 等

MiddleManger 节点接受到 Ingestion 的任务之后，开始创建 Segment：

• 转换成列式存储格式

• 用 bitmap 来建立索引（对所有的 dimension 列建立索引）

• 使用各种压缩算法

• 算法 1：所有的使用 LZ4 压缩

• 算法 2：所有的字符串采用字典编码、标识以达到最小化存储

• 算法 3：对位图索引使用位图压缩

Segment 创建完成之后，Segment 文件就是不可更改的，被写入到深度存储（目的是为了防止 MiddleManager 节点宕机后，Segment 丢失）。然后 Segment 加载到 Historicaljiedian，Historical 节点可以直接加载到内存中。同时，Metadata store 也会记录下这个新创建的 Segment 的信息，如结构、尺寸、深度存储的位置等等 Coordinator 节点需要这些元数据来协调数据的查找。

索引服务

索引服务是数据导入并创建 Segment 数据文件的服务索引服务是一个高可用的分布式服务，采用主从结构作为架构模式，索引服务由三大组件构成：

• overlord 作为主节点

• MiddleManage 作为从节点

• peon 用于运行一个 Task

索引服务架构图如下图所示：

服务构成

Overlord 组件

负责创建 Task、分发 Task 到 MiddleManger 上运行，为 Task 创建锁以及跟踪 Task 运行状态并反馈给用户

MiddleManager 组件

作为从节点，负责接收主节点分配的任务，然后为每个 Task 启动一个独立的 JVM 进程来完成具体的任务

Peon（劳工）组件

由 MiddleManager 启动的一个进程用于一个 Task 任务的运行

对比 YARN

• Overlord 类似 ResourceManager 负责集群资源管理和任务分配

• MiddleManager 类似 NodeManager 负责接收任务和管理本节点的资源

• Peon 类似 Container 执行节点上具体的任务

Task 类型

• index hadoop task：Hadoop 索引任务，利用 Hadoop 集群执行 MapReduce 任务以完成 Segment 数据文件的创建，适合体量较大的 Segments 数据文件的创建任务

• index kafka task：用于 Kafka 数据的实时摄入，通过 Kafka 索引任务可以在 Overlord 上配置一个 KafkaSupervisor，通过管理 Kafka 索引任务的创建和生命周期来完成 Kafka 数据的摄取

• merge task：合并索引任务，将多个 Segment 数据文件按照指定的聚合方法合并为一个 segments 数据文件

• kill task：销毁索引任务，将执行时间范围内的数据从 Druid 集群的深度存储中删除

Druid 高性能查询机制详解

Druid 之所以能够实现低延迟、高性能的查询，主要依赖于以下五个关键技术点：

1. 数据预聚合

Druid 在数据摄入阶段就进行预聚合处理，这显著减少了查询时需要处理的数据量。系统支持多种聚合方式：

• 计数(count)

• 求和(sum)

• 最大值(max)

• 最小值(min)

• 近似基数(hyperloglog)等例如，针对网站访问日志数据，Druid 可以在数据摄入时就预先计算好每分钟的 PV、UV 等指标，避免查询时进行全量计算。

2. 列式存储与数据压缩

Druid 采用列式存储架构，配合多种压缩算法：

• 字符串类型：字典编码(dictionary encoding)压缩

• 数值类型：

• 位压缩(bit compression)

• LZ4 压缩

• ZSTD 压缩这种存储方式不仅减少了 I/O 操作，还能显著提高压缩率，例如时间戳列通常可以获得 10 倍以上的压缩比。

3. Bitmap 索引

Druid 为每个维度列都建立了 Bitmap 索引：

• 对每个维度值生成对应的 bitmap

• 支持快速的 AND/OR/NOT 等位运算

• 特别适合高基数维度的过滤查询例如，对"浏览器类型"维度进行"Chrome OR Firefox"的查询，可以直接通过 bitmap 的 OR 运算快速定位到相关数据行。

4. 内存文件映射(mmap)

Druid 使用 mmap 技术来访问磁盘数据：

• 将索引文件和数据文件映射到内存地址空间

• 操作系统自动管理内存页的加载和回收

• 避免传统 I/O 的系统调用开销

• 支持热数据的自动缓存这种机制使得查询可以像访问内存一样快速，同时由操作系统智能管理缓存。

5. 查询结果缓存

Druid 实现了多级缓存机制：

• 中间结果缓存：存储部分查询结果

• 查询结果缓存：完整查询结果的缓存

• 支持基于时间的缓存失效策略

• 对于相同查询模式的重复请求可立即返回例如，仪表盘常见的"最近 1 小时数据"查询，在缓存有效期内可直接返回结果，无需重新计算。

数据预聚合

• Druid 通过一恶搞 RollUp 的处理，将原始数据在注入的时候就进行了汇总处理

• RollUp 可以压缩我们需要保存的数据量

• Druid 会把选定的相同维度的数据进行聚合操作，可以存储的大小

• Druid 可以通过 queryGranularity 来控制注入数据的粒度，最小的 queryGranularity 是 millisecond（毫秒级别）

Roll-Up

聚合前：

聚合后：

位图索引

Druid 在摄入的数据示例：

• 第一列为时间，Appkey 和 Area 都是维度列，Value 为指标列

• Druid 会在导入阶段自动对数据进行 RollUp，将维度相同组合的数据进行聚合处理

• 数据聚合的粒度根据业务需要确定

按天聚合后的数据如下：

Druid 通过建立位图索引，实现快速数据查找。BitMap 索引主要为了加速查询时有条件过滤的场景，Druid 生成索引文件的时候，对每个列的每个取值生成对应的 BitMap 集合：

索引位图可以看作是：HashMap<String, BitMap>

• Key 就是维度的值

• Value 就是该表中对应的行是否有该维度的值

SQL 查询

SELECT sum(value) FROM tab1WHERE time='2020-01-01'AND appkey in ('appkey1', 'appkey2')AND area='北京'

执行过程分析：

• 根据时间段定位到 Segment

• appkey in ('appkey1', 'appkey2') and area='北京' 查到各自的 bitmap

• （appkey1 or appkey2）and 北京

• (110000 or 001100) and 101010 = 111100 and 101010 = 101000

• 符合条件的列为：第一行 & 第三行，这几行 sum(value)的和为 40

GroupBy 查询

SELECT area, sum(value)FROM tab1WHERE time='2020-01-01'AND appkey in ('appkey1', 'appkey2')GROUP BY area

该查询与上面的查询不同之处在与将符合条件的列：

• appkey1 or appkey2

• 110000 or 001100 = 111100

• 将第一行到第四行取出来

• 在内存中做分组聚合，结果为：北京 40、深圳 60

错误速查

其他系列

🚀 AI 篇持续更新中（长期更新）

AI 炼丹日志-29 - 字节跳动 DeerFlow 深度研究框斜体样式架 私有部署 测试上手 架构研究，持续打造实用 AI 工具指南！AI 研究-127 Qwen2.5-Omni 深解：Thinker-Talker 双核、TMRoPE 与流式语音🔗 AI模块直达链接

💻 Java 篇持续更新中（长期更新）

Java-174 FastFDS 从单机到分布式文件存储：实战与架构取舍 MyBatis 已完结，Spring 已完结，Nginx 已完结，Tomcat 已完结，分布式服务已完结，Dubbo 已完结，MySQL 已完结，MongoDB 已完结，Neo4j 已完结，FastDFS 正在更新，深入浅出助你打牢基础！🔗 Java模块直达链接

📊 大数据板块已完成多项干货更新（300 篇）：

包括 Hadoop、Hive、Kafka、Flink、ClickHouse、Elasticsearch 等二十余项核心组件，覆盖离线+实时数仓全栈！大数据-278 Spark MLib - 基础介绍 机器学习算法 梯度提升树 GBDT 案例 详解🔗 大数据模块直达链接