面试考察点
- 是否区分 Distributed 逻辑表与各节点本地表。
- 能否设计均匀且支持查询裁剪的分片键。
- 是否理解分布式聚合、网络和一致性成本。
核心答案
Distributed 表本身通常不存业务数据，而是把写入路由到分片的本地 MergeTree 表，并把查询下发到相关分片后汇总结果。分片键决定数据分布，副本配置决定同一分片内的冗余与读取选择。
随机分片分布简单但难以裁剪；按租户或业务键分片可让相关查询落在少数分片，却要防止大租户热点。
查询流程
协调节点改写并下发查询，各分片执行局部过滤和聚合，再返回中间结果进行最终合并。应尽量把过滤和预聚合下推，避免跨网络传输大量明细。
本地表与 Distributed 表的职责
客户端 -> Distributed 表（路由/聚合）
↓
shard 1 本地 MergeTree + replicas
shard 2 本地 MergeTree + replicas
shard 3 本地 MergeTree + replicas
本地表负责真实数据存储、排序、分区和副本复制；Distributed 表是逻辑入口，包含集群拓扑、目标表和分片表达式。运维时要确认每个节点本地表定义一致，Distributed 表不会替你自动修复底层 schema 漂移。
写入模式对比
直接由应用按路由写本地表，路径短、失败可见，但客户端要掌握拓扑和重试；写 Distributed 表可由服务端根据分片键转发，某些配置下支持本地队列异步投递，客户端简单，但要监控队列积压、目标不可达与重复投递语义。
无论哪种，重试都可能造成重复数据。事实表应携带事件 ID、版本或采用可最终去重的表设计；不能因为“插入成功超时”就盲目无限重发。
分片键与查询裁剪
如果按 cityHash64(tenant_id) 分片，大多数带 tenant_id 的点查可以用 optimize_skip_unused_shards 等能力减少扇出，前提是查询条件和分片表达式可推导。若 SQL 没有分片键，协调节点通常要广播到所有分片。
分片键同时决定均衡性和局部性。按时间分片便于冷热存储但当前时间写热点明显；按租户哈希均匀但跨租户报表需要全分片聚合。不要只看数据量均匀，还要看 CPU、QPS 和磁盘 I/O 是否均匀。
分布式聚合与 JOIN
分片先完成局部 group by、filter 和 partial aggregate，协调节点再汇总。尽量让局部阶段减少数据量；在 SELECT * 大明细、全局排序、大 offset、精确 distinct 上，网络和协调节点内存可能成为瓶颈。
跨分片 JOIN 的语义和代价要明确。小维表可复制到每个分片或使用字典；大表广播会爆炸。GLOBAL 相关行为会把右表结果传到各分片，不可在大数据集上盲用。
故障与可观测性
查询失败时区分单副本不可用、单分片无副本、协调节点过载和网络超时。监控每分片扫描行数、返回字节、队列、replication lag 和热点，平均集群 QPS 健康不代表单一分片没有倾斜。
工程边界
写入可直接写本地表并由应用路由，也可写 Distributed 表异步转发；两种方式在失败重试、落盘队列和可观测性上不同。副本表还需正确配置一致的拓扑宏和复制路径。
常见误区
增加分片不一定让查询更快，扇出、网络和最终聚合可能增加延迟。GLOBAL JOIN 等操作可能广播数据，应控制右表大小并优先通过建模减少跨分片连接。
高频追问与参考回答
追问：分片键怎么选？
在均匀分布、查询局部性和扩展性之间权衡，用真实租户规模和查询模式验证，必要时为超大租户单独路由。
追问：Distributed 表可以当作高可用代理吗？
它可按拓扑选择副本并路由，但高可用还依赖本地表副本配置、网络、协调节点容量和客户端重试。不能只部署一台协调节点。
追问：为什么一个查询比单机更慢？
分布式查询增加扇出、网络、局部/全局归并和慢分片拖尾。若数据量不大或过滤无法下推，单机可能更快。
追问：如何避免跨分片 JOIN？
用小维表复制、字典、预聚合宽表、物化视图或在 ETL 阶段完成关联。核心原则是让在线分析查询尽量局部完成。
总结
Distributed 表负责路由和汇总，性能取决于分片键、下推比例、网络数据量和协调节点压力。
机制全景图
下面把「ClickHouse Distributed 表如何分片和查询？」从输入到结果压缩成一条可复述的主链路。面试时先用图建立全局坐标，再进入局部实现，能避免只背零散结论。
flowchart LR
A["客户端访问 Distributed 表"]
A --> B["按 sharding_key 选分片"]
B --> C["发送到本地表副本"]
C --> D["查询各分片并行执行"]
D --> E["协调节点合并结果"]
完整链路：从输入到结果
沿着「客户端访问 Distributed 表 → 按 sharding_key 选分片 → 发送到本地表副本 → 查询各分片并行执行 → 协调节点合并结果」观察输入、状态与输出，下面每个阶段都对应一个可以在源码、日志或系统表中验证的位置。
1. 客户端访问 Distributed 表
Distributed 表通常不存数据，只保存集群、远端数据库表和分片规则。
2. 按 sharding_key 选分片
写入根据 sharding_key 权重路由，键选择决定数据倾斜和同一实体是否聚合在单片。
3. 发送到本地表副本
数据真正落在各节点的本地 MergeTree，副本负责高可用而分片负责容量。
4. 查询各分片并行执行
查询下推到所有相关分片并行执行，缺少分片裁剪时每次都广播。
5. 协调节点合并结果
协调节点汇总聚合、排序和限制，中间结果过大会成为网络与内存瓶颈。
源码与实现定位
| 入口 | 阅读重点 |
|---|---|
| system.clusters | 分片副本拓扑 |
| system.distribution_queue | 异步分布写队列 |
源码或系统表应按上表顺序追踪：先确认入口实际走到哪条路径，再用运行时数据验证，而不是仅凭类名或配置推测。
参数配置与可复现实验
SELECT shard_num,replica_num,host_name FROM system.clusters WHERE cluster='prod';
制造倾斜 Key 与节点扩容，比较各分片行数、QPS 和协调内存。
验证步骤与预期结果
1. 固定输入和基线
先在没有故障注入的环境执行上述配置，固定数据规模、并发度、运行时版本和预热时间。以「max/avg shard rows」为主基线，记录值应满足「记录稳态基线」；同时保存 分片行数/字节偏差、远程读写延迟，使后续变化能够回到同一时间轴比较。
2. 从实现入口确认路径
在「system.clusters」确认请求确实进入「分片副本拓扑」对应的实现，再沿「system.distribution_queue」观察「异步分布写队列」。如果入口路径都未命中，就不应继续调整下游参数，而应先检查调用条件、版本或路由是否与假设一致。
3. 注入本文特有的失败模式
优先复现「sharding_key 低基数造成倾斜」，并把单一变量逐级放大，直到「max/avg shard rows」越过「>1.5」。随后再分别验证「协调节点承担大结果集合并」和「误以为增加副本能提升分片总容量」，三类故障分开执行，避免多个变量同时变化而无法归因。
4. 执行止损和根因修复
第一轮只应用「稳定 sharding_key」，确认它能控制影响范围；第二轮应用「协调聚合前下推」，验证核心链路恢复；最后落实「扩容用槽迁移/核对」，消除同类问题再次出现的条件。每一步都保留变更前后数据，不用“感觉变快了”替代测量。
5. 通过退出条件
实验只有同时满足三项才算通过：「max/avg shard rows」回到「记录稳态基线」、「max/avg shard rows P99」回到「同负载可复现」、「结果核对」回到「差异为 0」，并且业务结果差异为零。若性能恢复但结果不一致，仍应视为失败；若指标恢复后很快再次越线，则说明只完成了临时止损，没有消除根因。
量化基线
| 指标 | 样例基线/口径 | 风险线 | 结论 |
|---|---|---|---|
| max/avg shard rows | 记录稳态基线 | >1.5 | 分片倾斜 |
| max/avg shard rows P99 | 同负载可复现 | 超过基线 2 倍 | 分片倾斜 |
| 结果核对 | 差异为 0 | 任意非零 | 停止切换并修复 |
这些数值是实验口径或示例告警线，不是可复制到所有系统的固定答案；上线阈值应由本系统稳态、峰值和故障演练共同确定。
事故复盘：新增节点后历史与新数据分布不一致
简单取模分片在节点数变化后路由改变，历史数据没有自动重平衡，同一用户跨多个分片。扩容前设计稳定分片槽或显式迁移，并用查询路由兼容过渡期。
| 失败模式 | 首要证据 | 第一处置动作 |
|---|---|---|
| sharding_key 低基数造成倾斜 | 分片行数/字节偏差 | 稳定 sharding_key |
| 协调节点承担大结果集合并 | 远程读写延迟 | 协调聚合前下推 |
| 误以为增加副本能提升分片总容量 | 协调节点内存 | 扩容用槽迁移/核对 |
发布与回滚检查点
- 发布前：确认「system.clusters」对应实现和上述配置在目标版本仍然有效，并保存「max/avg shard rows」基线。
- 灰度中：同时观察 分片行数/字节偏差、远程读写延迟、协调节点内存；任一指标越过表中风险线，就停止继续扩量。
- 回滚时：先执行「稳定 sharding_key」控制影响，再回退代码或参数；涉及持久状态时必须额外核对结果差异。
- 发布后：至少覆盖一个完整峰值周期，确认「sharding_key 低基数造成倾斜」没有再次出现，才关闭变更观察窗口。
方案对比与选型
| 方案 | 更适合的场景 | 主要收益 | 代价与边界 |
|---|---|---|---|
| 随机分片 | 无实体局部性要求的明细流 | 写入均匀 | 按实体查询需广播 |
| 业务键哈希 | 同实体聚合和局部查询 | 可减少跨片 | 超级实体可能热点 |
| 预定义槽/权重 | 需要可控扩容迁移 | 路由稳定、可逐槽搬迁 | 管理元数据与迁移复杂 |
选型至少带上 日增量、分区规模、查询并发、扫描行数和压缩比，并用上面的量化基线验证；未知数据应明确为待测假设。
设计边界与工程取舍
分片和副本职责不同：分片扩容量，副本提可用与部分读能力；Distributed 查询仍要为网络与聚合成本付费。
工程落地遵循：以数据布局减少扫描，以批量写入减少小 Part，避免照搬行存思路。回答时直接引用「system.clusters」、配置实验和事故数据，比复述固定模板更有说服力。