2. 实时OLAP核心技术栈选型

实时OLAP引擎的选型，本质上不是“谁性能最强”的排名问题，而是“谁的架构约束与我的数据形态、查询模式、运维能力最匹配”的适配问题。ClickHouse、Doris、StarRocks、Druid、Pinot、Kylin 这六款引擎在存储结构、计算模型、数据更新能力和运维复杂度上差异显著，理解这些差异的根源，比记住基准测试数字更重要。

一、从架构根上区分：三类存储与计算组织方式

这六款引擎可以按“数据如何组织、计算如何调度”归为三条技术路线。

第一类是 MPP + 列式存储的自管理引擎，代表是 ClickHouse、Doris、StarRocks。它们把数据按列存进本地或共享存储，查询时多个节点并行扫描、聚合，再汇总结果。ClickHouse 采用 Shared-Nothing 架构，每个节点独立管理自己的分片，写入靠 MergeTree 系列表引擎完成，擅长单表宽表的高吞吐扫描，但多表 Join 和分布式事务能力较弱，数据更新依赖 ALTER 或 ReplacingMergeTree 这类异步合并机制。Doris 和 StarRocks 则引入了 FE（前端元数据与查询规划）与 BE（后端存储与执行）分离的架构，支持标准 SQL、多表 Join 和主键模型更新，StarRocks 还通过全局字典、CBO 优化器和向量化执行进一步强化了复杂查询能力。三者都适合“数据可批量导入、查询以聚合和明细扫描为主”的场景。

第二类是 Lambda 架构的预聚合与流式摄入引擎，代表是 Druid 和 Pinot。它们的设计目标不是通用 SQL 分析，而是“高并发、低延迟的时序与事件分析”。Druid 把数据分为实时摄入段和 Historical 历史段，查询时 Broker 合并两段结果；Pinot 则用 Controller 管理表、Broker 路由查询、Server 存储段，并支持实时与离线混合。两者都依赖预聚合、倒排索引和位图索引来压缩扫描范围，适合用户行为、广告点击、监控指标这类“写入持续、查询模式相对固定”的场景，但 SQL 兼容性和 Join 能力弱于 MPP 引擎。

第三类是预计算 Cube 引擎，代表是 Kylin。它不在查询时扫描原始明细，而是提前把维度组合聚合成 Cube，查询时直接命中预计算结果。Kylin 的亚秒级响应来自“空间换时间”，代价是 Cube 构建耗时、维度组合爆炸、对即席查询和明细查询支持有限。它适合维度相对稳定、指标可枚举、对延迟极敏感的固定报表场景。

二、选型对比维度：把“性能”拆成可判断的指标

生产选型不能只看 QPS 或扫描速度，建议按以下六个维度建立评分表，每个维度给出权重，再逐项打分。

三、生产决策方法：从场景反推引擎

实际决策时，建议先锁定“最不可妥协的约束”，再排除不满足的引擎。例如：

• 场景 A：实时看板，要求秒级更新、多表 Join、MySQL 生态兼容。优先考虑 Doris 或 StarRocks。若并发在数百以内、团队熟悉 MySQL，Doris 的运维负担更轻；若需要更高并发和复杂 CBO 优化，StarRocks 更合适。
• 场景 B：海量日志宽表，写入吞吐极高，查询以单表聚合和明细过滤为主。ClickHouse 是首选。需接受其 Join 弱、更新异步的特点，通常配合 Flink 做预聚合或宽表化。
• 场景 C：广告点击流、监控指标，写入持续、查询模式固定、要求万级 QPS。Druid 或 Pinot 更匹配。若已深度使用 Kafka 且需要灵活索引，Pinot 集成更顺；若需要成熟的实时段与历史段自动切换，Druid 生态更完整。
• 场景 D：固定维度报表，维度可枚举，要求亚秒响应且能接受 T+1 构建。Kylin 的 Cube 预计算能显著降低查询成本，但需评估维度组合数量，避免 Cube 膨胀。

四、一个可执行的选型评分示例

假设某团队要建设用户行为分析平台，核心需求为：日增 50 亿条事件、支持实时 Upsert 用户标签、查询以多维聚合和漏斗分析为主、峰值并发 300、团队有 MySQL 和 Flink 经验。按权重打分（1–5 分，5 为最优）可得到如下参考：

维度            权重   ClickHouse  Doris  StarRocks  Druid  Pinot  Kylin
实时更新        0.20      2          5        5         3      3      1
多表Join        0.15      2          4        5         2      2      1
高并发          0.15      3          4        5         5      5      4
查询延迟        0.15      4          4        5         5      5      5
运维成本        0.15      3          4        4         2      3      2
SQL/生态兼容    0.20      3          5        5         2      2      2
加权总分                  2.75       4.35     4.85      3.20   3.35   2.45

该示例中 StarRocks 与 Doris 领先，但最终决策还需结合团队现有技术栈和 PoC 结果。评分表的价值在于把模糊的“感觉”变成可讨论、可追溯的判断依据，而不是替代实际验证。

总结来看，六款引擎没有绝对优劣，只有与场景的匹配度。ClickHouse 强在单表扫描与写入吞吐，Doris/StarRocks 强在实时更新与 SQL 生态，Druid/Pinot 强在高并发时序分析，Kylin 强在预计算极速响应。生产决策的正确姿势是：先明确不可妥协的约束，再用多维度评分缩小范围，最后用真实数据和查询做 PoC 验证，而不是直接照搬 benchmark 排名。