Apache Druid® 是 Metamarkets 2012 年开源的实时 OLAP 数据库（2015 年进入 Apache 孵化，2018 年晋升顶级项目）；Apache Pinot® 是 LinkedIn + Uber 2014 年开源的实时 OLAP（2017 进入 Apache 孵化）。两个项目都是 Apache-2.0 + Java + 事件流式分析专精——区别于 ClickHouse / StarRocks 的 ” 通用 OLAP”。本文带你深入 Druid + Pinot 的核心能力、架构差异、商业化路径，以及跟 ClickHouse / StarRocks / Doris / TDengine 的对比选型。
写在前面
“ 实时事件流分析 ”——这是 IoT、监控、广告、用户行为分析场景的核心需求。
老的做法是 Lambda 架构：Kafka + Storm/Flink + HBase + Hive + Presto——3-5 个系统拼起来。
新一代是 统一实时 OLAP 数据库——一个系统搞定批 + 流：
- Apache Druid（14K stars / Imply 商业化）—— Lambda 架构原生支持
- Apache Pinot（6.1K stars / StarTree 商业化）—— 用户导向实时分析
- ClickHouse（49K stars / Yandex 出身）—— 通用 OLAP，事件分析也行但非专精
- StarRocks（12K stars / Doris fork）—— 通用 MPP，实时更新
- Apache Doris（~30K stars / 百度出身）—— 同上
- TDengine（~23K stars / 涛思数据）—— IoT 时序专精
Druid 和 Pinot 都是 ” 事件流式 OLAP 专精 ”——它们跟 ClickHouse / StarRocks 的 差异化 就在这里：
| 维度 | Druid / Pinot（实时 OLAP） | ClickHouse / StarRocks（通用 OLAP） |
|---|---|---|
| 优化场景 | 事件流、监控、用户行为、广告 | 通用分析、数仓、BI |
| 数据模型 | 时间分区 + 维度列（schema 固定） | 通用 SQL 表 |
| 摄取 | 流式原生（Kafka / Kinesis） | 通用 ETL（Airbyte） |
| 索引 | Bitmap / Star-Tree（针对维度） | MinMax / Bloom / 主键 |
| 延迟 | 亚秒级（事件入库即可查） | 秒级（需要 Routine Load / Stream Load） |
| 用户场景 | 高并发查询 API + 实时看板 | 数据仓库 + 多维分析 |
飞熊做 AI + IoT 技术咨询，Druid + Pinot 是事件流式场景的必讲项目——尤其是客户做点击流分析、广告监控、IoT 时序。
一、它解决什么问题
一句话 ：Druid / Pinot 让你在 毫秒到秒级延迟 内，流式摄取 （Kafka / Kinesis）+ 亚秒级查询 + 高并发 API（10K+ QPS）的事件流数据。
| 场景 | 例子 | Druid / Pinot 表现 |
|---|---|---|
| 点击流分析 | 网站 / App 用户行为 | 亚秒级 funnel / retention / path |
| 广告监控 | 实时 CTR / CPC / ROI | 毫秒级聚合 + 维度组合 |
| IoT 时序 | 传感器 / 设备数据 | 时序索引 + 流式摄取 |
| 监控告警 | 服务日志 / 指标 | 实时聚合 + 告警触发 |
| 用户画像 API | 实时查询用户标签 | 高 QPS + 低延迟 |
| 风控反欺诈 | 实时交易数据查询 | 毫秒级响应 + 流式计算 |
Apache Druid 基本信息
| 维度 | 数据 |
|---|---|
| GitHub | apache/druid |
| Stars | 14,042 |
| Forks | 3,793 |
| Open Issues | 777（最健康） |
| License | Apache-2.0 ✅ |
| 首次 commit | 2012-10-23（14 年老兵，实时 OLAP 最老） |
| 最近 commit | 2026-08-16（今天还在推代码） |
| 仓库大小 | 414 MB（Java 巨型单体） |
| 主语言 | Java 90%+ |
| 出身 | Metamarkets（2012 开源）→ Apache 孵化（2015）→ Apache 顶级（2018） |
| 商业实体 | Imply（2018 创立） |
| 文档 | druid.apache.org |
Apache Pinot 基本信息
| 维度 | 数据 |
|---|---|
| GitHub | apache/pinot |
| Stars | 6,121 |
| Forks | 1,500 |
| Open Issues | 1,428 |
| License | Apache-2.0 ✅ |
| 首次 commit | 2014-05-19（12 年老兵） |
| 最近 commit | 2026-08-16（今天还在推代码） |
| 仓库大小 | 354 MB |
| 主语言 | Java 90%+ |
| 出身 | LinkedIn + Uber（2014）→ Apache 孵化（2017） |
| 商业实体 | StarTree（2020 创立） |
| 文档 | pinot.apache.org |
二、核心能力全景：12 维对比
| 维度 | Apache Druid | Apache Pinot |
|---|---|---|
| 架构 | Lambda 架构（Historical + Middle Manager + Broker + Coordinator + Overlord） | Controller + Broker + Server + Minion |
| 存储 | 列存 + segment（按时间分区） | 列存 + segment（按时间分区） |
| 摄取 | 流式原生（Kafka / Kinesis）+ 批量（S3 / HDFS） | 流式原生（Kafka / Kinesis）+ 批量（S3 / HDFS） |
| 索引 | Bitmap（倒排）/ Concise / Roaring | Star-Tree 索引（核心创新）/ Bitmap / Range / Inverted |
| 查询延迟 | 亚秒级 | 毫秒级（更快） |
| 查询语言 | Druid SQL（ANSI SQL 子集）+ JSON-native | Pinot SQL（ANSI SQL 子集）+ JSON-native |
| JOIN 支持 | ⚠️ 有限（partial JOIN） | ⚠️ 有限（partial JOIN） |
| 多租户 | ✅ Tenant 隔离 | ✅ Tenant 隔离 |
| 高可用 | ✅ 主从 + 自动故障转移 | ✅ 主从 + 自动故障转移 |
| Cloud-native | ✅ K8s Operator | ✅ K8s Operator + Helm |
| 可视化 | ✅ 内置 Web Console | ✅ 内置 Web Console |
| 生态 | Apache Superset 深度集成 | Apache Superset / StarTree Cloud |
三、差异化能力：Druid vs Pinot 各 3 个杀手锏
Apache Druid 的 3 个杀手锏
1. Lambda 架构原生支持
Druid 的架构就是为 Lambda 架构（批 + 流）设计的：
[Kafka] ──► [Indexer / Middle Manager] ──► [Real-time Segments] ──┐
├──► [Historical] ──► [Query] ──► [Broker]
[S3 / HDFS] ──► [Batch Ingestion] ──► [Historical Segments] ─────┘
- 流式：从 Kafka 直接摄取，构建 real-time segments
- 批量：从 S3 / HDFS 批量导入，构建 historical segments
- 合并：后台自动 merge real-time → historical
2. Bitmap 索引（Bitmap Indexing）⭐ Druid 招牌
Druid 对 所有维度列 自动建 Bitmap 索引：
SELECT country, count(*) FROM events
WHERE country IN ('US', 'CN') AND event_type = 'click'
GROUP BY country;
Bitmap 索引 让 WHERE country IN ('US', 'CN') 直接用 位运算 完成过滤——比通用 B-Tree 索引快 100 倍。
适合 维度基数低 （<1000 万不同值）+ 过滤查询多 的场景。
3. 深度分片（Deep Storage + Tiered Storage）
- Deep Storage（S3 / HDFS）：冷数据存档
- Hot Tier（本地 + 内存）：热数据查询
- 查询自动路由：根据时间 / 频次路由到 hot / cold
适合 数据量大 + 时间跨度长 + 冷热分化 的场景。
Apache Pinot 的 3 个杀手锏
1. Star-Tree 索引 ⭐ Pinot 招牌
Pinot 的 Star-Tree 索引 是预聚合索引——提前计算聚合结果：
SELECT city, count(*), sum(revenue)
FROM events
GROUP BY city;
- 没有 Star-Tree：每次查询扫描原始数据
- 有 Star-Tree：直接查预聚合结果，毫秒级响应
Pinot 是 唯一在 OLAP 领域实现 Star-Tree 索引商用化 的项目——基于 LinkedIn 2016 paper。
2. 用户导向实时分析（User-Facing Analytics）⭐ Pinot 差异化定位
Pinot 的核心场景是 “user-facing analytics”——给终端用户用的实时分析：
- LinkedIn “Who Viewed Profile”（用户查谁看了我）
- LinkedIn “Company Analytics”（HR 查员工分析）
- UberEats Restaurant Manager（餐厅老板查实时订单）
- 50+ LinkedIn 内部产品用 Pinot
特征：
–
高 QPS（10K+ QPS）
–
低延迟（P99 <100ms）
–
强 SLA（99.9% 可用）
–
多租户（不同用户不同隔离）
3. 实时摄入 + 立即可查（毫秒延迟）
-- 实时表配置
{
"tableName": "sensor_events",
"tableType": "REALTIME",
"ingestionConfig": {
"streamIngestionConfig": {
"streamConfigMaps": [{
"streamType": "kafka",
"topicName": "sensor-data"
}]
}
}
}
- 数据从 Kafka 进入 Pinot 到可查询：10-30 秒
- 对比 Druid：接近（同级别）
- 对比 ClickHouse：快 5-10 倍
适合 实时监控 + 用户行为实时反馈 场景。
Druid vs Pinot 核心差异
| 维度 | Druid | Pinot |
|---|---|---|
| 核心定位 | Lambda 架构 + 批流一体 | User-facing analytics |
| 主打索引 | Bitmap（过滤快） | Star-Tree（聚合快） |
| 数据延迟 | 亚秒级 | 毫秒级（更快） |
| 聚合查询 | ⚠️ 中等 | ✅ 极快（Star-Tree 预聚合） |
| 过滤查询 | ✅ 极快（Bitmap） | ✅ 快 |
| JOIN | ⚠️ 有限 | ⚠️ 有限 |
| 运维复杂度 | ⚠️ 高（架构复杂） | ✅ 中等（架构清晰） |
| 多租户 | ✅ | ✅ |
| 典型用户 | 字节跳动 / Splunk / 网易 | LinkedIn / Uber / Stripe / Slack |
四、生态系统：商业化 + 集成 + 用户
Apache Druid 生态
| 集成 | 详情 |
|---|---|
| Apache Superset (270) | ✅ 深度集成（Druid 原生 SQL） |
| Apache Kafka | ✅ 流式摄取 |
| Apache Spark / Flink | ✅ 批量摄取 |
| AWS / GCP / Azure | ✅ 云部署 |
| Imply | ✅ 商业版（Imply Cloud / Imply Enterprise） |
Imply 商业化：
– 2018 年 Imply 创立（Druid 核心团队）
–
Imply Cloud（SaaS）/ Imply Enterprise（私有部署）
– Imply Polaris（统一分析平台）
Apache Pinot 生态
| 集成 | 详情 |
|---|---|
| Apache Superset (270) | ✅ 集成 |
| Apache Kafka / Pulsar / Kinesis | ✅ 流式摄取 |
| Apache Spark / Flink | ✅ 批量摄取 |
| Presto / Trino (328) | ✅ 联邦查询 Pinot |
| AWS / GCP / Azure | ✅ 云部署 |
| StarTree | ✅ 商业版 |
StarTree 商业化：
– 2020 年 StarTree 创立（Pinot 核心团队）
–
StarTree Cloud（SaaS）/ StarTree Enterprise（私有部署）
– 重点是
user-facing analytics 场景
用户案例
Druid 头部用户
| 公司 | 场景 |
|---|---|
| 字节跳动 | 内部监控 / 广告分析 |
| Splunk | 日志分析（Splunk 商业版底层用 Druid） |
| 网易 | 游戏数据分析 |
| Cisco | 网络监控 |
| Salesforce | 客户分析 |
Pinot 头部用户
| 公司 | 场景 |
|---|---|
| 50+ 内部产品（Who Viewed Profile / Company Analytics / Talent Insights） | |
| Uber | UberEats Restaurant Manager |
| Stripe | 财务分析 |
| Slack | 工作区分析 |
| DoorDash | 订单分析 |
| Microsoft | 服务监控 |
五、对比 ClickHouse / StarRocks / Doris / TDengine
| 维度 | Druid | Pinot | ClickHouse | StarRocks | Doris | TDengine |
|---|---|---|---|---|---|---|
| Stars | 14,042 | 6,121 | 49,269 | 12K | ~30K | ~23K |
| 协议 | Apache-2.0 ✅ | Apache-2.0 ✅ | Apache-2.0 ✅ | Apache-2.0 ✅ | Apache-2.0 ✅ | AGPL-3.0 ⚠️ |
| 类型 | 实时 OLAP | 实时 OLAP | 通用 OLAP | 通用 MPP | 通用 MPP | IoT 时序 |
| 架构 | Lambda | Controller + Server | Shared-Nothing | MPP FE/BE | MPP FE/BE | 集群 |
| 索引 | Bitmap | Star-Tree | MinMax/Bloom | ZoneMap | ZoneMap | 时序专用 |
| 摄取 | Kafka / Kinesis | Kafka / Kinesis | 多种 | Routine Load | Routine Load | 多种 |
| 延迟 | 亚秒级 | 毫秒级 | 秒级 | 秒级 | 秒级 | 毫秒级 |
| JOIN | ⚠️ 有限 | ⚠️ 有限 | ⚠️ 弱 | ✅ 强 | ✅ 强 | ⚠️ 弱 |
| 高并发 API | ✅ 强 | ✅ 极强 | ⚠️ 中 | ✅ 强 | ✅ 强 | ✅ 强 |
| 用户场景 | 监控 / 广告 | user-facing | 通用 | 实时数仓 | 实时数仓 | IoT |
| 数据湖 | ⚠️ 弱 | ⚠️ 弱 | ⚠️ 实验 | ✅ 强 | ✅ 中等 | ❌ |
| 运维复杂度 | ⚠️ 高 | ⚠️ 中 | ⚠️ 中 | ⚠️ 中 | ✅ 低 | ✅ 低 |
结论怎么选：
| 你的场景 | 选谁 |
|---|---|
| 事件流式 + Lambda 架构 + 批流一体 | Druid ✅ |
| 用户导向实时分析 + 高 QPS API + Star-Tree 聚合 | Pinot ✅ |
| 通用 OLAP + 极致单表聚合 | ClickHouse |
| 湖仓原生 + 多表 JOIN + 实时数仓 | StarRocks / Doris |
| IoT 时序专精 + 国产可控 | TDengine ⚠️（AGPL 风险） |
对比已调研的飞熊 8 月 BI 栈：
| 已调研项目 | 跟 Druid / Pinot 的关系 |
|---|---|
| ClickHouse (322) | 互补——ClickHouse 是通用 OLAP，Druid/Pinot 是事件流式专精 |
| Apache Doris (296) | 互补——Doris 是通用 MPP，Druid/Pinot 是实时 OLAP |
| StarRocks (332) | 互补——StarRocks 是 MPP 数仓，Druid/Pinot 是事件流 |
| Trino (328) | 上游 / 补充——Trino 可以联邦查询 Druid 和 Pinot |
| Apache ECharts (324) | 下游可视化——Druid/Pinot 查结果用 ECharts 渲染 |
| Apache Superset (270) | 下游可视化——Superset 原生支持 Druid 和 Pinot |
| Airbyte (326) | 上游 ETL——Airbyte 拉数据 → Druid/Pinot 实时摄取 |
| Apache Kafka | 上游摄取——Druid/Pinot 直接从 Kafka 摄取（不是 ETL） |
| DataHub (330) | 元数据——DataHub ingestion Druid / Pinot 的元数据 |
| Streamlit (334) | 下游应用——Streamlit + Pinot 高 QPS API 是 user-facing 黄金组合 |
Druid / Pinot 在飞熊 BI 栈的位置：
事件流（Kafka / IoT / App）↓
Druid / Pinot（实时 OLAP）⭐实时层
↓
├──► 高 QPS API（Pinot 黄金场景）├──► 实时看板（Superset 270）├──► AI 训练数据（Streamlit 334）└──► DataHub (330) 元数据（跟通用 OLAP 栈互补，不是替代）数据仓库（ClickHouse 322 / Doris 296 / StarRocks 332）↓
BI 仪表盘（Superset 270 / Metabase 274 / Lightdash 272 / Evidence 314）↓
可视化（ECharts 324）六、实战：3 步跑通 Druid + Pinot
Step 1：Apache Druid 实战（Kafka 摄取 + 实时查询）
# 1. 下载 Druid
wget https://dlcdn.apache.org/druid/30.0.0/apache-druid-30.0.0-bin.tar.gz
tar -xzf apache-druid-30.0.0-bin.tar.gz
cd apache-druid-30.0.0
# 2. 启动（单机模式）./bin/start-micro-quickstart
# 访问 Web Console: http://localhost:8888
-- 3. 摄取配置（Kafka → Druid）{
"type": "kafka",
"spec": {
"dataSchema": {
"dataSource": "clickstream",
"timestampSpec": {
"column": "timestamp",
"format": "auto"
},
"dimensionsSpec": {
"dimensions": [
"user_id",
"page_url",
"country",
"device_type"
]
},
"metricsSpec": [{"type": "count", "name": "count"},
{"type": "longSum", "name": "total_duration", "fieldName": "duration"}
]
},
"ioConfig": {
"type": "kafka",
"kafka.topic": "click-events",
"kafka.consumer.group.id": "druid-clickstream"
},
"tuningConfig": {
"type": "kafka",
"intermediatePersistPeriod": "PT10M"
}
}
}
-- 4. 实时查询（Druid SQL）SELECT
country,
COUNT(*) AS event_count,
SUM(total_duration) AS total_duration
FROM clickstream
WHERE __time >= CURRENT_TIMESTAMP - INTERVAL '1' HOUR
GROUP BY country
ORDER BY event_count DESC
LIMIT 10;
Step 2：Apache Pinot 实战（Kafka 摄取 + 高 QPS API）
# 1. 启动 Pinot（Docker）docker run -d --name pinot \
-p 9000:9000 -p 8000:8000 \
apachepinot/pinot:latest QuickStart
# 访问 Web UI: http://localhost:9000
-- 2. 表配置（实时表 + Kafka 摄取）{
"tableName": "user_events",
"tableType": "REALTIME",
"segmentsConfig": {
"timeColumnName": "ts",
"timeType": "MILLISECONDS",
"retentionTimeUnit": "DAYS",
"retentionTimeValue": "30"
},
"tableIndexConfig": {
"loadMode": "MMAP",
"starTreeIndexConfigs": [{"dimensions": ["country", "device_type"],
"functionColumnPairs": [["COUNT(*)", "count"], ["SUM(revenue)", "total_revenue"]]
}],
"invertedIndexColumns": ["user_id", "country"]
},
"ingestionConfig": {
"streamIngestionConfig": {
"streamConfigMaps": [{
"streamType": "kafka",
"topicName": "user-events",
"consumer.factory.class.name": "org.apache.pinot.plugin.stream.kafka20.KafkaConsumerFactory"
}]
}
}
}
-- 3. 高 QPS 查询
SELECT
country,
COUNT(*) AS event_count,
SUM(revenue) AS total_revenue
FROM user_events
WHERE ts >= ago('PT1H')
GROUP BY country
LIMIT 10;
Step 3：用户导向实时 API（Pinot + Streamlit）
# streamlit_app.py
import streamlit as st
import requests
st.title("🚀 实时用户分析（Pinot 后端）")
# Pinot 查询 API
@st.cache_data(ttl=10) # 10 秒缓存
def query_pinot(sql):
response = requests.post(
"http://pinot-broker:8000/query/sql",
json={"sql": sql}
)
return response.json()
# 实时国家分布
countries = query_pinot("""
SELECT country, COUNT(*) AS cnt
FROM user_events
WHERE ts >= ago('PT1H')
GROUP BY country
ORDER BY cnt DESC
LIMIT 10
""")
st.metric(" 过去 1 小时事件数 ", countries["result"][0][1] if countries["result"] else 0)
st.bar_chart({" 国家 ": [c[0] for c in countries["result"]],
" 事件数 ": [c[1] for c in countries["result"]]})
# 实时 refresh
import time
st_autorefresh = st.empty()
for sec in range(60, 0, -1):
st_autorefresh.write(f" 下次刷新：{sec}s")
time.sleep(1)
st.rerun()
七、风险与坑
1. Druid 架构复杂
Druid 至少需要 5 个组件（Historical + Middle Manager + Broker + Coordinator + Overlord + Router + Peon）——单机模式适合测试，生产集群运维复杂。
缓解：用 Imply Cloud / Polaris（托管服务）
2. Pinot JOIN 有限
Pinot 不支持完整的多表 JOIN——JOIN 场景需要预处理（数据建模阶段打宽表）。
缓解：在 ingestion 阶段 JOIN，或者用 Trino(328) 联邦查询
3. Schema 变更不灵活
Druid / Pinot 都是 schema-on-write——数据摄入前必须定义 schema，schema 变更需要重新摄取。
缓解：提前建模 / 用 Kafka Schema Registry
4. 1,428 open issues（Pinot 量更大）
Pinot issue 量比 Druid 多——主要是因为生态年轻。
5. 414 MB + 354 MB 巨型仓库
clone 慢，build 慢。
缓解：用 Docker 镜像（apache/druid / apachepinot/pinot）
6. 中文文档相对薄弱
虽然都是 Apache 顶级项目，但中文教程不如 ClickHouse / Doris 丰富。
缓解：看官方英文 docs + Imply / StarTree 商业支持
7. 内存占用高
实时节点需要内存缓存最近 segments——高吞吐场景需要大内存。
8. Lambda 架构成本
Druid 的 Lambda 架构（流 + 批两套摄取）成本高于 ClickHouse / StarRocks 的 单一摄取。
八、总结
Druid 和 Pinot 都不是 ”ClickHouse 替代品 ”——它们是 事件流式 OLAP 专精 的细分市场老大，跟 ClickHouse / StarRocks 形成 互补不是替代。
Druid 的 3 个最值得用的理由：
- Lambda 架构原生支持：流 + 批一体，Apache-2.0 ✅ + Apache 顶级 2018 + 14 年老兵 + Imply 商业化
- Bitmap 索引 （过滤查询快 100 倍）：适合 维度基数低 + 过滤查询多 的场景
- 深度分片 + 冷热分层 ：适合 数据量大 + 时间跨度长 的场景（Splunk / 字节跳动 / Cisco 都用）
Pinot 的 3 个最值得用的理由：
- Star-Tree 索引 （聚合查询快）：基于 LinkedIn 2016 论文， 预聚合索引 + 毫秒级响应 + 唯一商用化
- User-facing analytics（用户导向实时分析）：LinkedIn 50+ 内部产品用，高 QPS + 低延迟 + 强 SLA
- 实时摄入 + 立即可查 （10-30 秒）：适合 实时监控 + 用户行为实时反馈
1 句建议：
如果你的场景是事件流式 + Kafka 摄入 + 高 QPS + 亚秒级延迟——用 Apache Druid 或 Apache Pinot（两者都是 Apache-2.0 ✅，看具体场景选 Druid 还是 Pinot）。
如果你的场景是 Lambda 架构 + 批流一体 + 过滤查询多——选 Druid（Imply 商业）。
如果你的场景是 user-facing analytics + 高 QPS API + Star-Tree 预聚合——选 Pinot（StarTree 商业）。
如果你的场景是通用 OLAP + 极致单表聚合——看 ClickHouse (322)。
如果你的场景是湖仓原生 + 多表 JOIN + 实时数仓——看 StarRocks (332) / Apache Doris (296)。
如果你的场景是 IoT 时序专精——看 TDengine ⚠️（AGPL 风险）。
飞熊做 AI + IoT 技术咨询，事件流式场景（IoT 数据 / 用户行为 / 监控告警）建议推荐 Druid / Pinot——尤其是客户已经用 Kafka 做消息队列的场景，直接 Kafka 摄取，0 ETL 是核心卖点。
参考
- Apache Druid GitHub · 14K stars / Apache-2.0 / Java
- Apache Druid 官方文档 · 完整架构 + 摄取
- Apache Pinot GitHub · 6.1K stars / Apache-2.0 / Java
- Apache Pinot 官方文档 · 完整架构 + 摄取
- Imply · Druid 商业化公司
- StarTree · Pinot 商业化公司
- Star-Tree 论文 · LinkedIn 2016 VLDB 论文
- Druid vs Pinot 对比 · StarTree 官方对比
- Lambda 架构 · 实时 OLAP 理论基础
- Apache Superset Druid 集成 · 270 已调研
- Trino Pinot Connector · 328 已调研
- Splunk + Druid · 商业集成