OLAP 数据库篇：ClickHouse、Doris、StarRocks 与分析型数据库选择

OLAP 是 Online Analytical Processing，在线分析处理。它和 OLTP 的问题完全不同。OLTP 关心一次订单状态修改是否正确，OLAP 关心的是能不能在几百亿行历史数据里快速算出趋势、分布、排行和指标。

报表、BI、实时大屏、用户行为分析、日志分析、指标平台、数据仓库，这些都是典型 OLAP 场景。

Rendering diagram...

OLAP 的查询特点

OLAP 查询通常会扫描大量数据，但只读取部分列。例如统计每天 GMV，可能只需要 event_date、amount、status 三列，而不需要读取订单表里的收货地址、备注、物流单号等字段。

OLAP 查询经常包含聚合、过滤、分组、排序和 Join。它关注吞吐和整体扫描效率，而不是单行事务更新。

OLAP 写入通常是批量写入、流式写入或微批写入。它可以接受一定程度的数据延迟，但希望查询速度足够快。

为什么 OLAP 喜欢列式存储

列式存储把同一列的数据放在一起。这样查询少数列时，只需要读相关列。列数据类型相同，也更容易压缩。

列式存储对聚合非常友好。比如求 sum(amount)，系统可以连续读取 amount 列并批量计算，而不必把每一行完整取出来。

列存的代价是单行更新通常不如行存自然。因为一行数据分散在多个列文件或列块里，频繁更新会让写路径更复杂。因此 OLAP 数据库通常更适合追加写、批量导入、异步合并和分析查询。

ClickHouse：高性能列式分析数据库

ClickHouse 是非常典型的列式 OLAP 数据库。它的核心优势是高吞吐扫描、列式存储、压缩、向量化执行，以及围绕 MergeTree 家族表引擎建立的一整套数据组织方式。

MergeTree 是 ClickHouse 最重要的表引擎家族。它支持分区、排序键、稀疏主键索引、数据跳过索引等能力。合理设计 PARTITION BY 和 ORDER BY，往往决定了 ClickHouse 查询性能的上限。

ClickHouse 特别适合日志分析、行为分析、宽表分析、指标聚合、明细数据查询和大吞吐报表。它的性能很强，但也要求使用者理解表引擎、分区、排序键、数据合并和写入批量。

ClickHouse 的常见使用方式是把数据整理成宽表或明细表，通过排序键提升过滤效率，通过物化视图或聚合表承接部分高频指标。

一个 ClickHouse 明细表例子：

CREATE TABLE user_events
(
  event_date Date,
  event_time DateTime,
  user_id UInt64,
  event_name LowCardinality(String),
  page String,
  properties String
)
ENGINE = MergeTree
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_name, event_date, user_id);

它的挑战包括：复杂更新能力不是传统 OLTP 风格；高频小批量写入可能造成较多 parts；分布式集群运维需要理解副本、分片和合并行为；复杂多表 Join 场景需要谨慎建模。

Apache Doris：实时数仓与易用性取向

Apache Doris 是面向实时分析的数据仓库系统，采用 MPP 架构，强调简单易用、实时写入、报表分析和高并发查询。

Doris 的一个重要特点是把很多数据仓库能力做成相对一体化的系统。它支持多种数据模型，比如明细模型、聚合模型、主键模型等，适合承接不同分析场景。

在实时数仓场景里，Doris 经常被用来接 Kafka、Flink、CDC 或批量导入，把业务数据、日志数据和指标数据放进统一的分析库中。

Doris 比较适合希望快速搭建实时数仓、报表系统和多维分析平台的团队。它在数据导入、SQL 查询、物化视图、主键更新、聚合模型等方面提供了较完整的工程能力。

一个 Doris 明细模型例子：

CREATE TABLE dwd_order_detail (
  order_date DATE,
  order_id BIGINT,
  user_id BIGINT,
  sku_id BIGINT,
  channel VARCHAR(64),
  pay_amount DECIMAL(12, 2)
)
DUPLICATE KEY(order_date, order_id)
PARTITION BY RANGE(order_date) ()
DISTRIBUTED BY HASH(order_id) BUCKETS 16;

它的挑战在于：系统能力较多，需要理解不同表模型的适用边界；高并发、实时写入和复杂查询同时存在时，需要认真设计分区、分桶、模型和资源隔离。

StarRocks：强调极速查询、CBO 和湖仓分析

StarRocks 同样是 MPP 架构的分析型数据库，强调向量化执行、列式存储、成本优化器 CBO、物化视图、实时更新和数据湖分析能力。

StarRocks 的一个突出方向是高性能多维分析和复杂查询。它希望在宽表查询、Join、聚合、实时更新和湖仓查询上提供较好的统一体验。

StarRocks 提供多种表类型，包括明细表、主键表、聚合表、更新表，用来适配原始明细、实时更新、预聚合等不同场景。主键表对实时更新和部分更新场景比较关键。

一个 StarRocks 主键表例子：

CREATE TABLE order_wide (
  order_id BIGINT,
  user_id BIGINT,
  order_status VARCHAR(32),
  pay_amount DECIMAL(12, 2),
  updated_at DATETIME
)
PRIMARY KEY(order_id)
DISTRIBUTED BY HASH(order_id) BUCKETS 16;

如果你的场景里 Join 较多、实时更新较多、希望较好地支持湖仓分析，StarRocks 往往会进入候选名单。

它的挑战在于：要真正发挥性能，需要理解表类型、排序键、分区分桶、物化视图改写、CBO 统计信息和资源管理。越强的系统，越需要正确的建模和治理。

ClickHouse、Doris、StarRocks 的差异

ClickHouse 的气质更像“极致列式分析引擎”。它在大宽表、日志、明细分析、聚合扫描上非常强，适合能接受围绕 MergeTree 建模和调优的团队。

Doris 的气质更像“实时数仓一体化平台”。它强调易用、导入、表模型、物化视图和报表服务，适合希望较快搭建实时数仓和 BI 分析的团队。

StarRocks 的气质更像“高性能 MPP 分析引擎 + 湖仓查询层”。它强调 CBO、向量化、Join、实时更新和数据湖分析，适合复杂查询和实时分析并重的场景。

简单说：

• 大规模日志和明细宽表分析，可以优先看 ClickHouse。
• 实时数仓、报表服务、一体化易用性，可以重点看 Doris。
• 复杂 Join、实时更新、湖仓查询和高性能交互分析，可以重点看 StarRocks。

这不是绝对边界。三者都在快速演进，能力也有重叠。真实选型要结合数据量、查询形态、写入方式、团队经验和运维能力。

维度	ClickHouse	Apache Doris	StarRocks
核心气质	高性能列式分析引擎	实时数仓一体化	高性能 MPP + 湖仓分析
常见强项	明细宽表、日志、聚合扫描	报表、实时数仓、易用导入	Join、CBO、实时更新、湖仓查询
表设计重点	MergeTree、分区、排序键	数据模型、分区分桶、物化视图	表类型、分区分桶、统计信息
写入关注点	批量写入、parts 合并	实时导入和模型选择	主键更新、导入与查询并发
适合团队	能围绕 ClickHouse 深度调优	希望快速搭实时数仓	复杂查询和实时分析并重

OLAP 表设计建议

第一，先理解查询，再设计表。OLAP 表不是把 OLTP 表原样搬过去。报表查询关心哪些维度、指标和过滤条件，表结构就应该围绕这些访问模式设计。

第二，明细表和聚合表要分工。明细表保留可追溯数据，聚合表服务高频指标。不要指望所有查询都扫明细。

第三，时间分区通常很重要。大多数分析查询都有时间范围，按天、月或业务周期分区可以显著减少扫描。

第四，排序键要服务过滤和聚合。用户 ID、商家 ID、事件时间、渠道、状态等字段是否适合做排序键，要看查询条件和数据分布。

第五，实时写入要控制批量。OLAP 数据库一般不喜欢极端零散的小写入，Kafka、Flink、批量导入和微批攒批都很常见。

OLAP 常见坑

第一个坑是直接照搬业务库表结构。业务库是为事务设计的，分析库是为查询设计的。很多时候需要宽表、快照字段和预聚合。

第二个坑是指标口径不统一。技术架构再漂亮，如果 GMV、UV、转化率的定义不一致，报表就会互相打架。

第三个坑是忽视数据延迟。实时分析系统不是只看查询速度，也要看采集、传输、计算、写入、查询整条链路的延迟。

第四个坑是只追求 benchmark。公开 benchmark 很有参考价值，但真实业务的数据分布、查询模式、并发模式和运维能力更重要。

小结

OLAP 数据库不是更快的 MySQL，而是面向分析问题重新设计的一类系统。它用列式存储、压缩、向量化执行、分布式计算、物化视图和预聚合来解决大规模查询问题。

ClickHouse、Doris、StarRocks 都是优秀的 OLAP 选择，但它们的工程侧重点不同。选型时不要先问“哪个最快”，而要先问：我的数据怎么写入，查询怎么发生，是否需要实时更新，Join 多不多，团队能不能长期维护。

参考链接

• ClickHouse Docs: What Is a Columnar Database?
• ClickHouse Docs: MergeTree Engine Family
• Apache Doris Docs: Introduction to Apache Doris
• StarRocks Docs: Shared-nothing deployment overview
• StarRocks Docs: Database Features
• StarRocks Docs: Table overview

社区讨论参考

• 知乎：ClickHouse vs StarRocks 选型对比
• 知乎：如何选择分析型数据库？