考察点
面试官想看你是否真的建过表、踩过引擎选错的坑。光背引擎名字分数不高，能讲清「为什么 MergeTree 是核心、各变体在 merge 时分别做了什么」才是关键。追问常落在 ReplacingMergeTree 的去重时机、AggregatingMergeTree 配合物化视图的用法，以及 ReplicatedMergeTree 的副本机制。
参考答案
家族总览：四大类
ClickHouse 的引擎名字很多，归下类就清楚了。MergeTree 家族是生产上唯一的主力，负责本地持久化存储；Log 家族（TinyLog、Log）是玩具级的轻量引擎，适合临时小表；集成引擎（Kafka、MySQL、JDBC、HDFS、S3）用来对接外部系统，Kafka 引擎配物化视图是实时接入的经典组合；特殊引擎里 Distributed 是分布式查询的入口，本身不存数据，只是路由到各分片的本地表，还有 Memory、Buffer、Dictionary 这些辅助角色。面试把主线放在 MergeTree 上就够了。
MergeTree 变体：区别全在后台 merge 干什么
基础 MergeTree 只做排序和合并 part，不做任何数据处理。变体们的差别是后台 merge 时对「排序键相同的多行」怎么处理：
| 引擎 | merge 时的行为 | 典型用途 |
|---|---|---|
| MergeTree | 不动，全保留 | 明细日志、事件流 |
| ReplacingMergeTree | 保留 version 最大的一行 | 去重、维表镜像 |
| SummingMergeTree | 数值列相加合并成一行 | 简单预聚合 |
| AggregatingMergeTree | 按聚合函数的中间状态合并 | 物化视图表、精细预聚合 |
| CollapsingMergeTree | 按 Sign 列 +1/-1 对冲删除 | 有状态变更的流水 |
| VersionedCollapsingMergeTree | 带版本的对冲折叠 | 乱序的状态变更 |
ReplacingMergeTree 的坑必须知道
它只在后台 merge 时去重，而 merge 时机不可控，所以查出来的数据可能还有重复。生产上两种应对：查询时加 FINAL（实时去重，慢），或者用 GROUP BY + argMax(col, version) 手动取最新。另外它按整个 ORDER BY 键判断「同一行」，不是按业务主键——键设计错了会丢掉不该丢的行。这类细节一讲出来，面试官就知道你用过。
AggregatingMergeTree + 物化视图：预聚合标准姿势
明细表照常接原始数据，建一张 AggregatingMergeTree 的聚合表，物化视图在写入时把聚合中间状态（AggregateFunction 类型，比如 sumState、uniqState）写进聚合表。查询时用对应的 -Merge 函数（sumMerge、uniqMerge）把状态合并出最终结果。注意存的不是最终值而是中间状态，这样多维度随意下钻再聚合都是对的——比如 uniqState 存的是去重计数的中间结构，任意时间段合并都能得到正确的 UV。大数据量下存储和查询都能省一个量级。
副本与分片
生产集群用 ReplicatedMergeTree（所有变体都有 Replicated 前缀版本），副本间通过 ZooKeeper（新版本可用 ClickHouse Keeper）同步 part 元数据，数据本身在副本间互相拉取，不设主从——每个副本都能写，ZK 只协调元信息。分片则靠建表时的 sharding key，查询走 Distributed 表广播聚合。选型顺序一般是：先确定 MergeTree 变体，再套 Replicated 做副本，最后用 Distributed 拼成分布式表。
选型速查
原始日志明细——MergeTree；CDC 同步过来的业务库镜像——ReplacingMergeTree；按天的固定维度报表——AggregatingMergeTree 加物化视图；账户流水这类会冲正的数据——CollapsingMergeTree；小工具临时表——Log 或 Memory。实话说 SummingMergeTree 现在用得越来越少，能力基本被 AggregatingMergeTree 覆盖且后者更灵活。
可能的追问
- ReplacingMergeTree 能保证查询结果一定去重吗？—— 不能，merge 是后台异步的。要么查询加 FINAL 牺牲性能，要么 GROUP BY 配合 argMax 手动取最新版本。
- ReplicatedMergeTree 的副本一致性怎么做？—— ZooKeeper/Keeper 存 part 元数据和复制日志，副本间对等拉数据，无主架构。写入只落一个副本，其余副本异步追平，所以默认是最终一致。
- Kafka 引擎表为什么查一次数据就没了？—— Kafka 引擎本质是消费者，数据不落地。标准用法是 Kafka 引擎表 + 物化视图 + MergeTree 落地表，消费即转发存储。