第 1 章 · ClickHouse 是什么 & 为什么快

三个交互演示：① 行存 vs 列存的 IO 差异 · ② 向量化批处理流水线 · ③ OLAP 数据库定位象限

同一张表，行存和列存读多少字节？

调一下「行数 / 列数 / 查询使用的列」，看左右两边「磁盘上真正读的数据量」差多少倍。一句话理解：OLAP 查询大多只用 5~10 列，但行存逼你把所有列都搬到内存里再丢。

🐬 行存（MySQL InnoDB） 所有列连续

— 磁盘读取量
— 3 GB/s SSD 估算耗时
— 浪费比例

⚡ 列存（ClickHouse） 每列单独成 .bin

— 磁盘读取量（含 LZ4）
— 3 GB/s SSD 估算耗时
— 相对行存加速比
关键直觉： 用「数据全本」的视角想 —— 行存读了 整本书（所有列都搬上来再丢），列存只读了 用到的几页。再叠加 LZ4 压缩（典型 3~5 倍），列存的真实 IO 又能打个 1/4 折。
实测参考（Web 日志 1 亿行，20 列）：MySQL SELECT SUM(amount) ~ 8.3 秒；ClickHouse 同 SQL ~ 56 毫秒；约 150 倍差距。

1024 行一批走流水线 vs 一行一行送进去

ClickHouse 内部所有数据以 Block（默认 65535 行 × N 列的列式批量）为单位流动。点「▶ 启动流水线」看 8 个 Block 依次走完 4 个算子；右侧「逐行模式」对比 —— 同样 4096 行，逐行模式要走 4096 次循环，向量化只走 4 次。

📥 Source
读 Block 列文件
▶
🔍 Filter
WHERE 过滤
▶
∑ Aggregate
SIMD 求和
▶
📤 Sink
输出
已生成的 Block（按批切分总行数）：
⚡ 向量化模式
批数：— 函数调用：— SIMD：YES
累计耗时：—
🐢 逐行模式
批数：1 行 / 批 函数调用：— SIMD：NO
累计耗时：—
面试要点： 向量化的关键在「摊薄准备开销」—— 函数调用、分支判断、内存分配只发生 N/65536 次而非 N 次；同时连续内存访问让 CPU 缓存命中率从 ~50% 飙到 95%+，再加上 SIMD 一条指令算 8 个，合计能把同样 SQL 提速 50~100 倍。

OLAP 数据库的世界版图

横轴是「查询并发 / 实时性」（越往右越实时、越能扛高 QPS），纵轴是「写入吞吐 / 单机性能」（越往上越能扛大数据量）。点圆点看每个数据库的定位与差异化能力。

查询并发 / 实时性 →
↑ 写入吞吐 / 单机性能
📦 传统 MPP / 数仓
大批量 ETL，离线分析
⚡ 实时 OLAP（CK 主场）
秒级响应 + 大数据量
📊 离线数仓 / Lakehouse
分钟～小时延迟
🔍 KV / 嵌入式
点查 / 单机轻量
ClickHouse 同类 OLAP 云原生 / Serverless 传统 MPP / 离线
👉 点击任意圆点查看详情

每个 OLAP 系统都有自己的强项 —— ClickHouse 主打「单机暴力 + 简单粗暴 + 极致压缩」；Doris 主打「JOIN 强 + MPP 优化器」；Druid 主打「实时摄入 + 预聚合」；Snowflake 主打「云原生 + Serverless 弹性」。选型时先想清场景，再选合适的工具。

📊 ClickHouse vs MySQL/PG vs 同类 OLAP 速查

能力MySQL/PGClickHouseDoris/StarRocksDruid
存储模型行存列存列存列存 + 倒排
单机扫描性能★★★★★★★★★★★★★★
JOIN 能力★★★★★★★ (弱，靠字典)★★★★✗ 不支持
事务★★★★★仅单分区原子弱无
实时摄入—★★★★ (Kafka 引擎)★★★★★★★★★
UPDATE/DELETE实时Mutation 异步Mutation 异步不支持
压缩比低极高 (5~20×)高高
SQL 标准遵循★★★★★★★ (方言)★★★★★★ (DSL)
运维复杂度低低 (单机猛)中高