📚 课程目录第1章 Druid初探

1. Druid初探：实时OLAP引擎的定位与核心特性，Druid vs ClickHouse vs Elasticsearch选型对比

大家好，我是这次课程的主讲。做了这么多年大数据架构，我接触过不少实时分析场景。今天咱们先聊聊Druid——这个在实时OLAP领域里，地位很特殊的引擎。

你可能会问：市面上有ClickHouse、有Elasticsearch，为什么还要学Druid？说实话，我刚接触时也有这个疑问。但深入用下来才发现，它们各自的“战场”其实不太一样。

Druid是一个高性能的实时分析数据库。它的核心定位是：对大规模事件流进行快速聚合查询。

我习惯把它理解成一个“时间序列+OLAP”的混合体。它特别擅长处理带有时间戳的事件数据——比如用户点击流、监控指标、广告曝光日志。

举个例子。你在做一个实时大屏，每秒涌入几万条用户行为数据。你想知道“过去5分钟，每个省份的PV和UV是多少”。用传统关系型数据库？扛不住。用Hadoop？延迟太高。这时候Druid就派上用场了。

Druid的核心能力：

咱们把Druid的几个关键特性掰开揉碎了讲。这些特性决定了它适合什么场景，不适合什么场景。

Druid把数据按时间范围切分成一个个Segment。每个Segment是一个独立的数据文件，包含了某个时间窗口内的所有数据。

为什么要这么做？因为大多数分析查询都带有时间范围。比如“查询昨天的数据”，Druid只需要扫描昨天对应的那几个Segment，其他时间段的Segment直接跳过。这比全表扫描快得多。

我记得在某个项目中，用户查询跨度3个月的数据，Druid只用了不到1秒就返回了聚合结果。换成Hive跑了快两分钟。

这是Druid最核心的优化手段。在数据摄入时，Druid会按照指定的维度（比如省份、浏览器、操作系统）对指标（比如PV、UV）进行预聚合。

说白了，就是“先算好，存起来”。查询时直接读取聚合后的结果，不需要再扫描原始数据。

我的建议：Rollup粒度要合理。粒度过细，预聚合效果不明显；粒度过粗，查询灵活性下降。我一般建议按分钟或小时做预聚合，同时保留原始数据用于明细查询。

Druid采用列式存储，每个列独立压缩存储。查询时只需要读取涉及的列，IO开销大大降低。

同时，Druid对维度列构建了位图索引。比如“省份=广东”这个条件，Druid通过位图索引能快速定位到哪些行满足条件，然后只扫描这些行对应的指标列。

这两种技术叠加，让Druid在过滤和聚合场景下表现非常出色。

Druid支持两种数据摄入方式：

两种方式可以共存。实时数据流处理当前事件，批量任务补充历史数据。这在实践中非常常见。

这三个引擎经常被放在一起比较。我根据自己的实战经验，整理了一个对比表格。

特性	Druid	ClickHouse	Elasticsearch
核心定位	实时OLAP分析	列式OLAP分析	全文搜索与日志分析
数据模型	时间序列+维度+指标	宽表+列式存储	文档+倒排索引
实时摄入	原生支持，秒级延迟	需借助外部工具，秒级延迟	原生支持，近实时
聚合查询	极快（预聚合+位图索引）	极快（列式+向量化）	一般（需脚本聚合）
全文搜索	不支持	有限支持	极强（核心能力）
数据更新	不支持单行更新	支持更新/删除	支持更新/删除
扩展性	水平扩展，自动均衡	水平扩展，需手动分片	水平扩展，自动分片
典型场景	实时大屏、用户行为分析、广告分析	BI报表、监控分析、AB测试	日志搜索、全文检索、安全分析

看完表格，你可能还是有点懵。我再说说我的选型经验。

避坑提醒：我曾经见过一个团队，用Elasticsearch做实时聚合大屏。数据量一上来，聚合查询慢得离谱。后来换成Druid，同样的查询从10秒降到了0.5秒。选型时一定要搞清楚自己的核心场景。

在深入细节之前，我们先从宏观上看看Druid的架构。这有助于你理解后面章节的内容。

这个架构图展示了Druid的几个核心组件：

嗯，这个架构看起来组件不少。但别担心，后面我们会逐一深入讲解每个组件的配置和调优。

这一章我们主要做了三件事：