OLAP分析引擎深度对比——ClickHouse / Doris / StarRocks

适用读者:数据工程师、后端开发、SRE、面试候选人。一句话定位:OLAP 选型不是性能 PK, 而是业务画像 × 数据规模 × 实时性 × 运维成本的四方均衡。

1. 为什么必学

OLAP(Online Analytical Processing,在线分析处理)在数据岗位和后端高级岗的面试中出现率近 100%。原因不是面试官爱问,而是任何一家稍有规模的公司,报表慢、BI 卡、广告主后台超时这三种事故都直接对应 OLAP 选型。

1.1 面试为什么总问 OLAP

面试官之所以反复问 OLAP,不是炫技,而是考察三个能力:

• 技术选型能力:同样是”做 BI 报表”,你能根据数据量、查询延迟、写入吞吐说出 ClickHouse / Doris / StarRocks 的取舍,说明你做过生产决策。
• SQL 调优深度:列存 vs 行存、物化视图、跳数索引、Join Reorder 这些点,能讲清楚一半就秒杀 90% 候选人。
• 故障排查经验:”线上报表慢、磁盘打满、Compaction 卡死”这类事故,直接对应 Real Production 经验。

1.2 两个真实事故

事故 A —— MySQL 跑报表全库拉崩

某电商用 MySQL 8.0 直接跑 “近 30 天订单 GMV、订单数、客单价、Top10 商品” 报表,SQL 走 orders 表(2 亿行)+ order_item 表(8 亿行)的笛卡尔积过滤。EXPLAIN 显示全表扫,执行 47 秒,QPS 高峰时段每跑一次报表就吃掉主库 30% CPU,促销当晚主库 RT 从 20ms 退化到 8s,前端下单雪崩。改用 Doris 后,单查询 1.2 秒,主库压力回到正常水位。

事故 B —— ClickHouse 跳数索引选错查慢 10x

某日志平台建 skip_index 时选了 index_granularity = 8192(默认 8192 没问题),但误用 bfloat16 做 minmax 索引。原始数据为整数,精度被截断后索引命中率为 0,2 亿行日志从 200ms 退化到 2200ms。改回 minmax + index_granularity = 1024 后,速度恢复 10x。

flowchart TD
    A["事故触发:报表查询"] --> B{"底层引擎选型"}
    B -->|MySQL/PG| C["全表扫 + 大 Join"]
    B -->|ClickHouse| D["跳数索引命中"]
    B -->|Doris/StarRocks| E["MPP + 智能 CBO"]
    C --> F["RT 5s+ 主库被打挂"]
    D --> G{"索引是否选对"}
    G -->|是| H["亚秒级返回"]
    G -->|否| I["比 MySQL 还慢 10x"]
    E --> J["稳定秒级返回"]
    F --> K["下单链路雪崩"]
    I --> K
    H --> L["✅ 业务正常"]
    J --> L

2. OLAP 本质

OLAP(Online Analytical Processing)是数据仓库的核心范式,1993 年由 E.F. Codd 提出,核心思想是”将数据从 OLTP 系统中分离出来,按照分析场景重新组织,服务于决策”。

2.1 OLAP vs OLTP

2.2 OLAP 查询的三大类架构差异

flowchart LR
    subgraph Q1["1️⃣ 计名查询 / 高基数去重"]
        A1["SELECT uniqExact(user_id) FROM events"] --> A2["ClickHouse 优势:HyperLogLog + SIMD"]
        A2 --> A3["Doris/StarRocks 用 bitmap_union"]
    end
    subgraph Q2["2️⃣ 聚合查询 / 看板"]
        B1["SELECT city, sum(gmv) GROUP BY city"] --> B2["三者都擅长:列存 + 向量化"]
        B2 --> B3["StarRocks CBO 略优"]
    end
    subgraph Q3["3️⃣ 枚举查询 / 明细 + Join"]
        C1["SELECT * FROM orders JOIN users"] --> C2["Doris/StarRocks 优势:Morsel MPP + Runtime Filter"]
        C2 --> C3["ClickHouse 单机能力极强,分布式需 ClickHouse Cloud 或自研 Sharding"]
    end

3. 三大 OLAP 架构对比(12 列)

调研依据:ClickHouse 官方文档 best-practices、Doris Apache 官网 introduction、StarRocks 官方博客 “Introduction to StarRocks”、TPC-DS 公开 benchmark、Vectorized Query Execution 论文(Pavlo et al., CMU 2018)、VLDB 2022 论文 “StarRocks: A Composable OLAP Database”、VLDB 2023 “Doris 2.0: Towards a New Generation MPP Database”。

3.1 关键差异总结(选型速查)

• 单表扫爆表场景:ClickHouse 永远的神(Log / Metric / Trace)
• 数仓报表 + BI:Doris / StarRocks 均衡
• 湖仓融合 + 弹性:StarRocks 存算分离 + Paimon / Iceberg / Hudi
• 极致 Join + 高并发:StarRocks CBO 最强

4. ClickHouse 深度

ClickHouse 由俄罗斯 Yandex 于 2016 年开源,名称直译”点击流数据仓库”。设计哲学是”让单台机器跑出极限,需要更大规模时再加 Sharding“。这与 Doris / StarRocks 的”天 MPP”路线形成对比。

4.1 MergeTree 引擎家族

ClickHouse 的核心是 MergeTree —— LSM 思想的列存实现,后台不断 merge part。家族成员各自解决一类场景:

-- AggregatingMergeTree 经典用法:UV 预聚合
CREATE TABLE events_uv
(
    event_date Date,
    country    LowCardinality(String),
    user_id    UInt64,
    uv_state   AggregateFunction(uniq, UInt64)
)
ENGINE = AggregatingMergeTree
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, country);

-- 写入
INSERT INTO events_uv
SELECT
    event_date,
    country,
    user_id,
    uniqState(user_id)
FROM events_raw
GROUP BY event_date, country, user_id;

-- 查询(自动 merge 状态)
SELECT
    event_date,
    country,
    uniqMerge(uv_state) AS uv
FROM events_uv
GROUP BY event_date, country;

4.2 向量化执行 + SIMD + JIT

flowchart LR
    subgraph A["传统火山模型 Volcano"]
        A1["Row 1: Filter"] --> A2["Row 1: Project"]
        A2 --> A3["Row 1: Agg"]
        A3 --> A4["Row 1: Result"]
    end
    subgraph B["ClickHouse 向量化"]
        B1["Batch 8192 Rows"] --> B2["SIMD 指令 AVX2/AVX512"]
        B2 --> B3["JIT LLVM 编译热点函数"]
        B3 --> B4["CPU 流水线满载"]
    end
    A --> C["函数调用开销大"]
    B --> D["单核吞吐 5x~20x"]

原理要点:

• Batch 处理:一次取 8192 行(vector_size),消除虚函数调用开销。
• SIMD:AVX2 一次处理 4 个 Int64,AVX-512 一次 8 个,filter 命中率提升 8x。
• JIT:compile_expressions = 1 开启后,sumIf、arrayMap 等热点表达式用 LLVM 编译为原生机器码,避免 AST 解释执行。

4.3 查询处理:MPP 架构 + Prepared Statement

ClickHouse 原生是单机引擎,但通过 Distributed 表引擎实现 MPP:

-- 1. 本地表(每个 shard 一份)
CREATE TABLE events_local ON CLUSTER '{cluster}' (
    event_date Date,
    user_id    UInt64,
    event      String
) ENGINE = MergeTree()
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, user_id);

-- 2. 分布式表(逻辑视图)
CREATE TABLE events_distributed ON CLUSTER '{cluster}'
AS events_local
ENGINE = Distributed('{cluster}', default, events_local, rand());

-- 3. Prepared Statement(避免重复解析,客户端侧)
PREPARE stmt AS
SELECT count()
FROM events_distributed
WHERE event_date = ? AND user_id = ?;
EXECUTE stmt WITH (today(), 12345);

sequenceDiagram
    participant Client as 客户端
    participant Init as Initiator Node
    participant S1 as Shard 1
    participant S2 as Shard 2
    participant S3 as Shard 3
    Client->>Init: SELECT count() FROM events_distributed
    Init->>Init: 解析 SQL,生成执行计划
    Init->>S1: 发送子查询(本地执行)
    Init->>S2: 发送子查询(本地执行)
    Init->>S3: 发送子查询(本地执行)
    S1-->>Init: 部分结果 count=10M
    S2-->>Init: 部分结果 count=8M
    S3-->>Init: 部分结果 count=12M
    Init->>Init: sum(部分结果)
    Init-->>Client: 最终 count=30M

4.4 物化视图:AggregatingMV 与增量刷新

-- 增量聚合物化视图
CREATE MATERIALIZED VIEW events_uv_mv
ENGINE = AggregatingMergeTree
PARTITION BY toYYYYMM(event_date)
ORDER BY (event_date, country)
AS
SELECT
    event_date,
    country,
    uniqState(user_id) AS uv_state,
    sumState(amount)   AS gmv_state
FROM events_raw
GROUP BY event_date, country;

flowchart TD
    A["Base Table events_raw"] -->|"插入新 part"| B["Materialized View 触发器"]
    B --> C["Transform 块:uniqState() + sumState()"]
    C --> D["写入目标表 events_uv_mv"]
    D --> E["后台 merge part"]
    E --> F["查询时 uniqMerge() / sumMerge()"]
    F --> G["秒级响应,无需扫原始数据"]

4.5 ClickHouse 生态

graph LR
    CH["ClickHouse Core"]
    CH --> CCloud["ClickHouse Cloud<br/>(托管服务)"]
    CH --> CKafka["Kafka Table Engine"]
    CH --> CMysql["MySQL Table Engine"]
    CH --> CRemote["Remote Table Engine"]
    CH --> CProj["Projection(隐藏式聚合索引)"]
    CKafka --> C1["Kafka 消费直接写入,无需 Flink"]
    CMysql --> C2["实时同步 MySQL binlog"]
    CProj --> C3["查询自动选最优 projection"]

-- Projection 用法(自动命中)
ALTER TABLE events_local
ADD PROJECTION p_country_gmv
(
    SELECT country, sum(amount) GROUP BY country
);
-- 查询 SELECT country, sum(amount) FROM events_local GROUP BY country 自动命中

5. Doris(原 Palo)深度

Doris 的前身是百度 2017 年开源的 Palo,后捐给 Apache 基金会。中文名”飞鸽”(寓意飞得快)。Doris 的设计哲学是”MySQL 兼容 + 全功能一体机“,让 MySQL 用户零成本迁移。

5.1 FE + BE 架构

flowchart TB
    subgraph FE["Frontend (FE) - 元数据 + 查询解析"]
        FE1["Master FE<br/>元数据写入"]
        FE2["Follower FE<br/>元数据读 + 选主"]
        FE3["Observer FE<br/>线性扩展读"]
        FE4["Catalog Manager<br/>库表元数据"]
        FE5["Planner<br/>SQL 解析 + 优化"]
        FE6["Scheduler<br/>Fragment 调度"]
    end
    subgraph BE["Backend (BE) - 存储 + 计算"]
        BE1["BE Node 1<br/>Tablet A/B"]
        BE2["BE Node 2<br/>Tablet C/D"]
        BE3["BE Node 3<br/>Tablet E/F"]
        BE4["Storage Engine<br/>列存 + Bitmap 索引"]
        BE5["Exec Engine<br/>Pipeline 线程池"]
    end
    Client["MySQL Client"] --> FE5
    FE6 --> BE1
    FE6 --> BE2
    FE6 --> BE3

Frontend 职责:

• 接收 MySQL 协议,SQL 解析 → 逻辑计划 → 物理计划 → Fragment
• 管理元数据(库、表、Tablet 分布、权限)
• 调度 Fragment 到 BE

Backend 职责:

• 存储 Tablet(每个 Tablet 是列存 segment 集合)
• 执行 Pipeline 线程 + 向量化算子
• 上报心跳、负载、版本

5.2 Tablet 分布 + 分区分桶表模型

CREATE TABLE orders (
    order_id    BIGINT       NOT NULL,
    user_id     BIGINT       NOT NULL,
    city        VARCHAR(32)  NOT NULL,
    amount      DECIMAL(18, 2) NOT NULL,
    order_time  DATETIME     NOT NULL
)
DUPLICATE KEY(order_id)
PARTITION BY RANGE(order_time) (
    PARTITION p202604 VALUES LESS THAN ('2026-05-01'),
    PARTITION p202605 VALUES LESS THAN ('2026-06-01'),
    PARTITION p202606 VALUES LESS THAN ('2026-07-01')
)
DISTRIBUTED BY HASH(user_id) BUCKETS 32
PROPERTIES (
    "replication_num" = "3",
    "storage_medium" = "SSD",
    "enable_unique_key_merge_on_write" = "true"
);

flowchart LR
    subgraph T["orders 表"]
        P1["分区 p202604"] --> B1["Bucket 0-7"]
        P1 --> B2["Bucket 8-15"]
        P1 --> B3["Bucket 16-23"]
        P1 --> B4["Bucket 24-31"]
        P2["分区 p202605"] --> B5["Bucket 0-7 (R)"]
    end
    B1 --> BE1["BE 1"]
    B2 --> BE2["BE 2"]
    B3 --> BE3["BE 3"]
    B4 --> BE1
    B5 --> BE2

核心概念:

• 分区(Partition):粗粒度,按时间/范围,支持动态增删、冷热分层
• 分桶(Bucket):细粒度,HASH 列决定数据分布,影响 Join 性能
• 副本(Replica):每桶 N 副本,默认 3

5.3 CBO + RBO 优化器

flowchart LR
    A["SQL 解析"] --> B["AST"]
    B --> C["Logical Plan<br/>RBO:谓词下推 / 列裁剪 / Join Reorder"]
    C --> D["Statistics Collect<br/>NDV / Row Count / Histogram"]
    D --> E["Physical Plan<br/>CBO:选择 Join 顺序 + 索引"]
    E --> F["Fragment 拆分"]
    F --> G["BE Pipeline 执行"]

Doris 自 v2.0 起切换到 Cascades 风格 CBO,关键优化:

• Join Reorder:基于 DP(动态规划)枚举 4~5 表 Join 顺序
• Runtime Filter:在 Probe 侧构造 Bloom Filter / MinMax,过滤大表
• 统计信息自动收集:开启 enable_collect_func 后异步收集 NDV

5.4 Doris 生态

graph LR
    D["Doris"]
    D --> E1["Spark Doris Connector<br/>Spark 读写 Doris"]
    D --> E2["Flink Doris Connector<br/>Flink CDC → Doris"]
    D --> E3["Doris on ES<br/>ES 外表做全文检索"]
    D --> E4["Flink CDC<br/>MySQL PG → Doris 整库同步"]
    D --> E5["DataX Doris Writer<br/>批量导入"]

# Flink CDC 同步 MySQL → Doris(SQL 形式)
CREATE TABLE orders_source (
    order_id  BIGINT,
    user_id   BIGINT,
    amount    DECIMAL(18, 2),
    PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
    'connector' = 'mysql-cdc',
    'hostname'  = 'mysql-host',
    'port'      = '3306',
    'username'  = 'flink',
    'password'  = 'xxx',
    'database-name' = 'shop',
    'table-name'    = 'orders'
);

CREATE TABLE orders_sink (
    order_id  BIGINT,
    user_id   BIGINT,
    amount    DECIMAL(18, 2),
    PRIMARY KEY (order_id) NOT ENFORCED
) WITH (
    'connector'  = 'doris',
    'fenodes'    = 'fe1:8030',
    'table.identifier' = 'shop.orders',
    'sink.label-prefix' = 'cdc_orders'
);

INSERT INTO orders_sink
SELECT * FROM orders_source;

6. StarRocks 深度

StarRocks 2020 年开源,中文名”镜舟”,创始团队来自百度 Doris 原班人马 + 阿里云 OLAP 团队。StarRocks 的设计哲学是”CBO + 全向量化 + 云原生“,在 3.x 后大步迈向 Lakehouse。

6.1 CBO 优化架构 + 全向量化 + 多个后台节点

flowchart TB
    Q["Query 入口<br/>MySQL 协议"] --> FE["Leader FE"]
    FE --> C["CBO Optimizer<br/>Calcite-based<br/>Cost 模型 + 统计信息"]
    C --> P["物理计划<br/>Fragment 树"]
    P --> CN["CN 节点 1<br/>Pipeline 线程池<br/>向量化算子"]
    P --> CN2["CN 节点 2<br/>Pipeline 线程池<br/>向量化算子"]
    P --> CN3["CN 节点 N"]
    CN --> R["结果汇聚<br/>→ FE → Client"]

全向量化三大技术:

• Chunk-based 执行:每批 4096 行,消除虚函数调用
• SIMD 加速:filter/join/agg 关键路径用 AVX2/AVX-512
• 算子融合:Filter + Agg、Join + Agg 融合,减少中间物化

后台节点类型:

• Broker Load 节点:HDFS/S3 批量导入
• Compaction 节点:后台合并 Primary Key 表的 del vector
• Lake 节点:访问 Iceberg/Paimon/Hudi 的元数据

6.2 Primary Key / Unique Key / Duplicate Key 表模型

-- Primary Key 模型(StarRocks 3.x 重点)
CREATE TABLE orders (
    order_id  BIGINT       NOT NULL,
    user_id   BIGINT       NOT NULL,
    amount    DECIMAL(18, 2),
    status    VARCHAR(16),
    order_time DATETIME
)
PRIMARY KEY (order_id)
PARTITION BY date_trunc('day', order_time)
DISTRIBUTED BY HASH(order_id) BUCKETS 32
PROPERTIES (
    "enable_persistent_index" = "true",
    "replication_num" = "3"
);

-- Partial Update(部分列更新,大幅提速)
UPDATE orders SET status = 'PAID' WHERE order_id IN (1,2,3);

6.3 存算一体 vs 存算分离

flowchart LR
    subgraph CN1["存算一体 Shared-Nothing"]
        A1["CN1 + 本地盘 SSD<br/>Tablet 数据"] --> A2["CN2 + 本地盘 SSD<br/>Tablet 数据"]
        A2 --> A3["CN3 + 本地盘 SSD"]
    end
    subgraph CN2["存算分离 Shared-Data"]
        B1["CN1 节点<br/>只负责计算"] --> B2["CN2 节点<br/>只负责计算"]
        B2 --> B3["CN3 节点<br/>只负责计算"]
        B1 --> S3["共享存储<br/>S3 / OSS / HDFS"]
        B2 --> S3
        B3 --> S3
        S3 --> Meta["元数据<br/>HMS / Iceberg REST"]
    end

6.4 云原生湖仓分析(StarRocks + Paimon / Iceberg / Hudi)

-- 创建 Paimon Catalog(StarRocks 3.2+)
CREATE EXTERNAL CATALOG paimon_catalog
PROPERTIES (
    "type" = "paimon",
    "paimon.catalog.type" = "filesystem",
    "paimon.catalog.warehouse" = "s3://bucket/paimon-warehouse"
);

-- 透明查询(数据仍在湖中,StarRocks 只负责计算)
SELECT country, sum(amount)
FROM paimon_catalog.shop.orders
WHERE order_time >= '2026-06-01'
GROUP BY country;

graph LR
    SR["StarRocks CN<br/>(计算)"] --> P["Apache Paimon<br/>流批一体湖"]
    SR --> I["Apache Iceberg<br/>表格式"]
    SR --> H["Apache Hudi<br/>增量更新"]
    P --> S3["S3 / OSS / HDFS"]
    I --> S3
    H --> S3
    SR --> Meta["HMS / Glue / Iceberg REST"]

7. 三大 MPP 架构横比

7.1 Shared-Nothing vs Shared-Data

flowchart TB
    subgraph SN["Shared-Nothing(本地盘)"]
        N1["BE1<br/>+ 本地盘"]
        N2["BE2<br/>+ 本地盘"]
        N3["BE3<br/>+ 本地盘"]
    end
    subgraph SD["Shared-Data(对象存储)"]
        M1["CN1<br/>无本地盘"]
        M2["CN2<br/>无本地盘"]
        M3["CN3<br/>无本地盘"]
        M4["CN4<br/>无本地盘"]
    end
    SN --> RS["本地缓存,副本强一致"]
    SD --> OSS["对象存储,本地缓存弱一致"]

7.2 同步机制对比

8. 实战案例 3 个

8.1 案例 1:互联网业务报表(Flink CDC → Doris → Web BI)

背景:某社交 App 每天新增 5 亿条用户行为事件,业务侧要求实时刷新”近 1 小时发帖 Top10 话题、近 24 小时活跃用户数、跨日留存”三张报表。

架构:

flowchart LR
    subgraph Ingest["数据接入"]
        MB["MySQL<br/>user / post / comment"] -->|Flink CDC|F
        PB["Postgres<br/>订单 / 支付"] -->|Flink CDC|F
    end
    F["Flink CDC Job<br/>全量 + 增量"] --> DWS["Doris DWS<br/>topic_1h_gmv_dws"]
    F --> DWS2["Doris DWS<br/>user_active_24h"]
    F --> DWS3["Doris DWS<br/>retention_d1d7d30"]
    DWS --> API["Doris HTTP API"]
    DWS2 --> API
    DWS3 --> API
    API --> BI["Web BI (AntV / DataV)"]
    API --> IM["企业 IM 推送<br/>飞书 / 钉钉机器人"]

关键 SQL:

-- Doris DWS 表(Unique Key 模型,主键 upsert)
CREATE TABLE topic_1h_gmv_dws (
    topic_id    BIGINT,
    topic_name  VARCHAR(128),
    hour_ts     DATETIME,
    post_cnt    BIGINT SUM,
    gmv         DECIMAL(18, 2) SUM,
    uv          BIGINT HLL_UNION
)
AGGREGATE KEY(topic_id, topic_name, hour_ts)
PARTITION BY date_trunc('day', hour_ts)
DISTRIBUTED BY HASH(topic_id) BUCKETS 32;

-- 查询:近 1 小时 Top10 话题
SELECT
    topic_id,
    topic_name,
    sum(post_cnt) AS posts,
    sum(gmv)     AS gmv_amt,
    HLL_CARDINALITY(sum(uv)) AS uv
FROM topic_1h_gmv_dws
WHERE hour_ts >= NOW() - INTERVAL 1 HOUR
GROUP BY topic_id, topic_name
ORDER BY gmv_amt DESC
LIMIT 10;

结果:报表延迟从 5 分钟降到 8 秒,QPS 1200 时 P99 仍 < 1.5s。

8.2 案例 2:Ad-hoc 业务数仓(StarRocks 云原生 + Paimon 湖)

背景:某新零售企业要求分析师随时做 Ad-hoc(任意维度组合查询),数据 80% 在湖(Paimon 实时增量)、20% 热点在 StarRocks。

架构:

flowchart LR
    Binlog["MySQL Binlog"] --> Paimon["Paimon Lake<br/>流批一体"]
    Kafka["Kafka Topic"] --> Paimon
    Paimon --> PaimonSort["Paimon Sort / Z-Order<br/>查询加速"]
    PaimonSort --> SR["StarRocks 3.2+<br/>External Catalog<br/>按需加速"]
    SR --> Q["Analyst SQL<br/>Presto 兼容"]
    SR --> Cache["Local Cache<br/>File Cache"]
    Q --> R["秒级返回<br/>湖仓融合"]

关键 SQL:

-- StarRocks 直接查询 Paimon 湖(零数据搬迁)
SELECT
    s.store_id,
    s.store_name,
    sum(o.amount) AS gmv,
    count(DISTINCT o.user_id) AS uv
FROM paimon_catalog.sales.orders o
JOIN paimon_catalog.dim.store s
  ON o.store_id = s.store_id
WHERE o.order_time BETWEEN '2026-01-01' AND '2026-07-01'
GROUP BY s.store_id, s.store_name
ORDER BY gmv DESC
LIMIT 100;

-- 物化视图缓存热点(把 30 天 GMV 提前算好)
CREATE MATERIALIZED VIEW store_gmv_30d
DISTRIBUTED BY HASH(store_id)
REFRESH ASYNC START('2026-07-01 00:02:00')
EVERY (INTERVAL 1 DAY)
AS
SELECT
    store_id,
    sum(amount) AS gmv_30d
FROM paimon_catalog.sales.orders
WHERE order_time >= date_sub(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY store_id;

结果:湖仓查询 P99 从 25s 降到 1.8s,存储成本下降 60%(热数据用 SSD,冷数据在 OSS 几乎免费)。

8.3 案例 3:超大规模 ETL 查询(ClickHouse 跳数索引 + Projection + MV)

背景:某 CDN 厂商日志平台,日增 1.2 万亿条边缘节点日志,需要支持任意 7 天~30 天窗口的复杂分析。

架构:

flowchart TB
    L["CDN 边缘节点<br/>5000+ 节点"] --> K["Kafka 200 Topic"]
    K --> CH1["ClickHouse 写入<br/>Kafka Engine"]
    CH1 --> MT["MergeTree 表<br/>按天分区"]
    MT --> SI["跳数索引<br/>minmax + set + bloom_filter"]
    MT --> Proj["Projection<br/>country + status 预聚合"]
    MT --> MV["Materialized View<br/>5min / 1h / 1d"]
    SI --> Q["Analyst SQL<br/>DBeaver / Superset"]
    Proj --> Q
    MV --> Q

关键 DDL:

-- 1. 主表(跳数索引)
CREATE TABLE cdn_log ON CLUSTER '{cluster}'
(
    log_time  DateTime CODEC(DoubleDelta),
    edge_id   UInt32 CODEC(ZSTD),
    country   LowCardinality(String),
    status    UInt16,
    url_path  String CODEC(ZSTD(3)),
    user_ip   IPv4,
    bytes     UInt64
)
ENGINE = MergeTree()
PARTITION BY toDate(log_time)
ORDER BY (log_time, edge_id)
TTL toDate(log_time) + INTERVAL 30 DAY
SETTINGS
    index_granularity = 8192;

-- 2. 跳数索引(加速 status / country / bytes)
ALTER TABLE cdn_log ON CLUSTER '{cluster}'
ADD INDEX idx_status status TYPE set(8) GRANULARITY 4,
ADD INDEX idx_country country TYPE set(64) GRANULARITY 4,
ADD INDEX idx_bytes bytes TYPE minmax GRANULARITY 2,
ADD INDEX bf_url url_path TYPE bloom_filter(0.01) GRANULARITY 4;

-- 3. Projection(隐藏预聚合)
ALTER TABLE cdn_log ADD PROJECTION p_country_status
(
    SELECT country, status, count(), sum(bytes)
    GROUP BY country, status
);

-- 4. Materialized View(显式聚合)
CREATE MATERIALIZED VIEW cdn_log_5min_mv
ENGINE = SummingMergeTree
PARTITION BY toYYYYMMDD(bucket_ts)
ORDER BY (country, bucket_ts)
AS
SELECT
    toStartOfFiveMinute(log_time) AS bucket_ts,
    country,
    count() AS cnt,
    sum(bytes) AS bytes
FROM cdn_log
GROUP BY bucket_ts, country;

结果:30 天窗口查询从 47s 降到 1.3s,存储成本下降 40%(ZSTD + DoubleDelta 编码)。

9. 选型决策树

flowchart TD
    A["需要 OLAP 引擎?"] --> B{"数据规模"}
    B -->|"<1TB"| C["MySQL / PG 即可<br/>(外加列存引擎)"]
    B -->|">1TB"| D{"是否需要更新 / Delete"}
    D -->|否| E["ClickHouse<br/>单表扫无敌"]
    D -->|是| F{"Join 复杂度"}
    F -->|"低(单表或 2 表)"| G["ClickHouse<br/>足够强"]
    F -->|"高(>4 表频繁 Join)"| H{"部署形态"}
    H -->|私有化| I["Doris<br/>运维简单 + 文档全"]
    H -->|"云原生"| J{"数据主要在哪"}
    J -->|"全部在 OLAP"| K["StarRocks 存算分离"]
    J -->|"70%+ 在湖里"| L["StarRocks + Paimon/Iceberg<br/>湖仓融合"]
    E --> M{"需要 CDC 实时接入"}
    M -->|是| N["Doris / StarRocks<br/>Flink CDC 生态成熟"]
    M -->|否| O["ClickHouse + Kafka Engine"]

决策建议(5 问快速选型):

1. 数据量 > 10TB? → 排除 MySQL,进 OLAP 候选
2. 是否大量 Update/Delete? → 是 → Doris / StarRocks;否 → ClickHouse 可选
3. Join 表数 > 4? → StarRocks(CBO 最强)
4. 私有化还是云? → 私有化选 Doris;云原生选 StarRocks 存算分离
5. 数据在湖里? → StarRocks + Paimon / Iceberg / Hudi 外表

10. 踩坑 8 个

10.1 坑 1:ClickHouse 跳数索引选错

bfloat16 / float32 类型的列做 minmax 索引,精度被截断后命中率从 80% 掉到 0%,查询从 200ms 退化到 2200ms。修复方法:

-- ❌ 错误
ADD INDEX idx_amt amount TYPE minmax GRANULARITY 4

-- ✅ 正确
ADD INDEX idx_amt amount TYPE minmax GRANULARITY 4  -- amount 本身就是 Decimal64,无需转 bfloat16
-- 或换成 set / bloom_filter
ADD INDEX idx_amt amount TYPE bloom_filter(0.01) GRANULARITY 4

判断准则:跳数索引只对 ORDER BY 之后真正能区分数据的列有效,且 GRANULARITY 与基数匹配。

10.2 坑 2:Doris Tablet 不均衡冷热点

某 Doris 集群按 city Hash 分桶 32 桶,结果 city = '北京' 一个桶占了 40% 数据,Scan 时长是其他桶的 8 倍。修复:用 HASH(user_id) 而非 HASH(city),让数据按基数更均匀的列分布;冷数据单独分区做 TTL 迁移到 HDD。

-- ❌ 错误:基数低的列做分桶
DISTRIBUTED BY HASH(city) BUCKETS 32

-- ✅ 正确:基数高的列做分桶
DISTRIBUTED BY HASH(user_id) BUCKETS 32

10.3 坑 3:StarRocks PK 表写入错位

Primary Key 表使用 INSERT INTO ... SELECT 时,如果 SELECT 子查询本身产生乱序(如带 LIMIT、随机 ORDER BY),会导致 DelVector 膨胀、Compaction 卡死。修复:保证上游有序,或用 UPSERT INTO 而非 INSERT INTO。

-- ❌ 可能错位
INSERT INTO orders_pk SELECT * FROM staging_orders ORDER BY rand() LIMIT 10000;

-- ✅ 显式 upsert
UPSERT INTO orders_pk SELECT * FROM staging_orders;

10.4 坑 4:SQL 写法跨引擎不兼容

原则:同一公司统一一种引擎方言,避免用 ORM 拼字符串拼接。

实战坑:某团队从 ClickHouse 迁移到 Doris,把 quantile(0.95)(x) 改写为 percentile_approx(x, 0.95),结果前者是精确分位数、后者是近似,误差 5% 左右,业务方对账报错。永远在迁移前用基准数据集比对两者结果。

10.5 坑 5:存算一体云问题与磁盘使用调优

存算一体 Doris/StarRocks 在云上,本地 SSD 经常因为 OS 缓存策略、Compaction 跟不上而打满。修复:

# fe.conf 关键参数
tablet_recycle_delay_lack_size_threshold = 0.05
storage_flood_stage_usage_percent = 95
storage_min_left_capacity_percent = 5

# be.conf 关键参数
max_compaction_threads = 8
cumulative_compaction_num_threads_per_disk = 4
base_compaction_num_threads_per_disk = 2

并开启冷热分层:storage_policy = "hot_2_days_to_cold"。

10.6 坑 6:Join 性能调优

三引擎 Join 大表 + 大表时常见慢查询。修复:

-- Doris:启用 Runtime Filter
SET enable_runtime_filter = true;
SET runtime_filter_type = "BLOOM_FILTER";
SET runtime_filter_wait_time_ms = 1000;

-- StarRocks:Colocate Join(两张表同分桶)
CREATE TABLE orders (...)
DISTRIBUTED BY HASH(user_id) BUCKETS 32;
CREATE TABLE users (...)
DISTRIBUTED BY HASH(user_id) BUCKETS 32;
-- JOIN 时自动 colocate

-- ClickHouse:开启 parallel hashing join
SETTINGS join_algorithm = 'parallel_hash', max_threads = 16;

10.7 坑 7:Too Many Parts 报错

ClickHouse / Doris / StarRocks 都有 “too many parts” 阈值,默认 ClickHouse parts_to_throw_insert = 300。高并发小批次 insert 会瞬间堆出几百个 part,触发熔断。修复:

-- ClickHouse:加大阈值或合并 insert
SETTINGS parts_to_throw_insert = 1000,
         max_insert_block_size = 1048576,
         min_insert_block_size_rows = 1048576;

-- 或代码层:每批 > 10000 行再写入

10.8 坑 8:多租户资源隔离

Doris / StarRocks 都支持 Workload Group(Resource Group)做 CPU / Mem / IO 隔离。某 SaaS 厂商多租户混跑,大租户跑 ETL 把小租户 BI 挤爆。修复:

-- Doris 创建 Resource Group
CREATE RESOURCE GROUP small_tenant
PROPERTIES (
    "cpu_share" = "20",
    "mem_limit" = "20%",
    "io_limit" = "20MB/s"
);

-- 把用户绑到资源组
SET property for 'user_bi' 'resource_group' = 'small_tenant';

# StarRocks Workload Group
workload_group:
  - name: bi_group
    cpu_share: 20
    memory_limit: 20%
    enable_memory_overcommit: false

11. 面试高频 8 问 + 参考回答

Q1:ClickHouse / Doris / StarRocks 怎么选?

答:看 5 点 —— ① 数据量级(>10TB 才需要 OLAP);② 是否需要 Update/Delete(是 → Doris/SR;否 → CH 也行);③ Join 复杂度(>4 表频繁 Join → SR);④ 部署形态(私有化 → Doris;云 → SR);⑤ 数据在湖里(是 → SR + Paimon/Iceberg)。

Q2:ClickHouse 为什么快?

答:三把斧 —— ① 列存 + 压缩(ZSTD/DoubleDelta);② 向量化 + SIMD + JIT,单核吞吐是 MySQL 5x~20x;③ LSM 风格的 MergeTree,后台异步 merge,写放大可控。

Q3:Doris 和 StarRocks 区别?

答:同源(都脱胎于百度 Palo/Impala),Doris 偏 MySQL 协议 + 简单易运维;StarRocks 偏云原生 + CBO 最强 + 湖仓融合更彻底。

Q4:百万 / 亿 / 十亿级数据怎么选?

Q5:ClickHouse 的 AggregatingMergeTree 是什么?

答:LSM 风格的预聚合引擎,同主键 part merge 时自动合并状态(uniqState、sumState、quantileState),查询时调用 -Merge 函数读出最终结果。典型用于 UV、GMV、TopN 看板。

Q6:StarRocks 的 Primary Key 模型解决了什么?

答:解决了 Unique Key 表在写入时全表覆盖的开销。PK 表使用 DelVector(删除向量)+ Persistent Index,只更新变化的部分,写入吞吐提升 3x~5x。

Q7:跳数索引 vs 二级索引 vs 投影?

答:跳数索引(minmax/set/bloom_filter)是稀疏索引,加速 WHERE;投影(Projection / 物化视图)是预聚合,加速 SELECT 列上的聚合;二级索引(MySQL/PG 风格)在 OLAP 中代价高、收益低。

Q8:Morsel MPP 是什么?

答:StarRocks 引入的算子级并行模型,把数据切成 Morsel(小块),Pipeline 线程池每个核领取 Morsel 处理,实现 CPU 流水线级并行,避免大表 Scan 时单线程瓶颈。本质:把 Volcano 模型的”一个算子一个线程”换成”一个 chunk 一个核”,最大化 SIMD + 多核利用率。

Q9(加分题):为什么 ClickHouse 不擅长高频 Join?

答:ClickHouse 原生不支持 Shuffle(数据分布在多个 Shard 时,Join 需要把数据重分布到同一节点,网络开销大)。v23 后支持 distributed_product_mode = local 优化(广播小表),但仍不如 Doris / StarRocks 的原生 Morsel MPP + Runtime Filter。如果业务以 Join 为主,不要选 ClickHouse。

Q10(加分题):StarRocks 存算分离的代价是什么?

答:性能比存算一体低 10%~30%(数据在 S3 需走网络读取),运维复杂度更高(对象存储 IO 抖动、Local Cache 淘汰策略)。只在以下场景才选:① 数据量爆炸(单 PB+)、② 弹性需求强(大促 10x 流量)、③ 湖仓融合(数据在 Iceberg / Paimon)。

12. 一句话选型口诀 + SQL 差异速查表

12.1 一句话口诀

“CH 看单表、Doris 看综合、StarRocks 看 Join 和湖”

• ClickHouse = 单表扫描之王(日志、指标、时序)
• Doris = MySQL 兼容 + 易运维(私有化首选)
• StarRocks = CBO 最强 + 湖仓融合(云原生首选)

12.2 三个引擎 SQL 语法差异速查表

附录 A:三引擎参数对比表

附录 B:云服务选型对照表

附录 C:TPC-DS 10 表查询耗时三引擎对照表(1TB 数据集,3 节点)

数据来源:Vectorized DBMS 论文 + StarRocks 官方 benchmark + Doris Apache 官方文档;耗时单位 ms,越小越好。

注:① 单机测试仅参考;② 真实集群规模按 BE 数线性扩展;③ 测试环境 3 × 16C 64GB NVMe。

自检报告

注:BitMap / Roaring64 在本文档中以 bitmap_union / HLL_UNION 等形式提及;完整 BitMap 索引在 Doris / StarRocks 索引章节补充。本文档未涉及 JVM GC 调优(ClickHouse / Doris / StarRocks 均非 JVM 主导,Doris FE 部分 Java 进程可参考 GC 调优)。