ClickHouse
列式存储 + 向量化执行，亿级数据秒级聚合
ClickHouse 是俄罗斯 Yandex 为自家分析系统造的列式数据库。它只读需要的列、按批向量化计算、用稀疏索引跳过无关数据块，所以一条 group by 扫几亿行能在秒级出结果。代价是：join 弱、更新难、并发不高。
它解决什么问题
MySQL 上一条按天分组的统计要跑十几分钟，而且会拖垮业务库；Hive 又慢到分钟级。运营要的是“点一下，两秒出图”。
真实场景：典型场景：埋点数据每秒几万条写进 ClickHouse，运营后台按渠道、机型、时间筛选，图表 1~2 秒刷新，一天查几千次。
核心概念
每个概念一句话 + 一个类比。点击卡片看更详细的解释。
列式存储
同一列的数据连续存放，查询只读用到的列
类比：按科目分册的成绩单，查数学只翻数学那本
看概念详情MergeTree
ClickHouse 最核心的表引擎，写入生成 part，后台不断合并
类比：收快递时先堆着，晚上统一按楼栋上架
看概念详情排序键
建表时定的排序键，决定稀疏索引能不能跳过数据
类比：电话簿按姓氏排，找“王”直接翻到 W 段
看概念详情分区
按时间等维度切目录，查询时先裁剪掉无关分区
类比：按月分文件夹存账单
看概念详情向量化执行
一次处理一批（如 8192 行）而不是一行，充分利用 CPU 缓存
类比：流水线批量打包，比一件件手拿快得多
看概念详情数据流转动画
跟着步骤看一条数据从进入系统到被处理完的完整路径，可以暂停、重播和调速。
写入一个 part，到查询扫出结果
← 左右滑动查看完整流程图 →
客户端一次提交 10 万行，ClickHouse 按列拆开、分别压缩，比逐行写快几个数量级。
提示：ClickHouse 的写入永远是“追加生成新 part”，从不在原地改；查询靠排序键 + 分区把扫描量砍到极小。 悬停图中的节点可以看概念解释。
优劣势
短句说清适合什么、不适合什么，选型时先看这一栏。
- 亿级数据聚合秒级返回，单机就能跑出很高的 QPS
- 压缩比高（列存 + 专用编码），存储成本比行存低 5~10 倍
- SQL 支持好，窗口函数、物化视图、近似去重都有
- 部署简单，单机 binary 就能跑，不依赖 Hadoop 生态
- 不支持高频单行更新/删除，只能异步 mutation 或重建 part
- join 能力弱，大表 join 容易 OOM，需要提前打宽表
- 并发不高，官方建议单机 QPS 在百级，不适合高并发点查
- 没有真正的事务，跨表一致性要业务自己保证
常见使用场景
每个场景都配一句「为什么用它」。
用户行为分析
埋点数据写入，按渠道 / 版本 / 时间多维下钻，做漏斗和留存。
为什么用它：列存只读需要的列，多维聚合正好是它最擅长的。
监控与日志分析
替代 ELK 做指标聚合，日志按天分区，保留半年。
为什么用它：同样的数据量，ClickHouse 的存储和查询成本都低得多。
实时大屏的查询层
Flink 算好的指标写进 ClickHouse，大屏每秒刷新。
为什么用它：写入批量、查询聚合，两边都能扛住。
同类对比
和同赛道的组件并排看，差异一目了然。
三者常常同时存在：Hive 存原始与明细、Doris 做实时报表、ClickHouse 扛大屏聚合。选型先问「查询长什么样、并发多少、要不要更新」，再比性能。
常见问题
上手第一个月最容易卡住的地方。
Q1ClickHouse 为什么这么快？
四件事叠加：列存只读用到的列；数据按排序键有序存放，稀疏索引能跳过整块；向量化执行一次算一批而不是一行；高压缩比让 IO 量变小。所以它快在“扫描型聚合”，不是快在“点查”。
Q2能当业务库用吗？
不建议。它不支持高频单行更新、没有事务、并发能力有限，点查（按主键取一行）反而不如 MySQL。定位是“分析型副本”：业务数据同步一份过来做分析，主库仍然是 MySQL。
Q3Too many parts 是什么错？
每次 INSERT 都会生成一个 part，写入太频繁（比如每秒一条）就会堆积成几千上万个 part，后台合并跟不上。解决办法：客户端攒批（每批 ≥ 1 万行）、用 Kafka 引擎表缓冲、或者调大 parts_to_throw_insert 并观察合并速度。
Q4ClickHouse 和 Doris 怎么选？
纯分析、数据量极大、能接受单表宽表模型，ClickHouse 更快更省；需要多表 join、高并发点查、要用标准 SQL 和事务性导入，Doris 更合适。很多公司两个都上：Doris 做报表，ClickHouse 做明细大屏。