ClickHouse 的 MergeTree 引擎读写流程
前言
本文隶属于专栏《大数据技术体系》，该专栏为笔者原创，引用请注明来源，不足和错误之处请在评论区帮忙指出，谢谢！
本专栏目录结构和参考文献请见大数据技术体系
MergeTree 数据写人流程
单机写入流程
MergeTree 只能按分区聚合数据，当每一批数据落盘时，都会生成一个新的分区目录，属于相同分区的目录会依照规则合并到一起，然后按照设置的表属性 index_granularity ，会分别生成一级素引文件
多机 Shard 写人流程
多机 Shard 写人一般有以下两种方案。
方案一
在 ClickHouse 外部，事先将数据均匀分片，再写人 ClickHlouse 集群的各个本地表，这种方案有更好的写人性能。
方案二
某个 ClickHouse Server 节点实时写人数据并落盘，根据分区规则，如果是写人本地的数据，则直接写人本地分区的临时目录；如果是写到远程的数据，则会落到一个带远程信息的本地临时目录，完成后发送到远程节点，远程节点收到数据后写人本地分区，最终确认一致性并完成。
多机 Shard 多副本写人流程
ClickHouse 的多副本写人机制依赖于 ZooKeeper 服务。
接收数据的主节点在写人完成后，会向 ZooKeeper 的 /log 目录发送一个 LogEntry ，从节点监听到 /log 目录的变化后，会去主节点上拉取数据并写人本地；主节点发起 Merge 操作时，也会向 /log 目录上发送 LogEntry ，其他从节点监听到，则会触发相同的 Merge 操作来保证数据的一致性。
MergeTree 数据查询流程
单机查询流程
对于单机表，用户通过 connector 发送 SQL 到 ClickHouse Server，然后经 Parser 和 Intercepter 的解析选择读取的 MergeTree 数据。
多机 Shard 查询流程
一条查询分布式表的 SQL ，会被接收到该 SQL 的 ClickHouse Server，解析为在多个节点执行 SQL ，所有拥有分片的节点执行完对应的 SQL 后，将数据返回给发起查询的节点，该节点对数据进行汇总计算并返回结果。
以上流程可以发现，在大数据场景下对全局其列数据做 Count Distint 基本不可能，如果返回所有该列的详细数据可能导致汇总节点内存谥出（ OOM )，目前一般使用 HyperLogLog 来做近似统计。
其他类似 TopN 等聚合函数在分布式场景也只能做近似计算。
ioin 操作在多机 Shard 场景也非常不方便， join 的底层实现都是哈希 join ，需要右表是一张小表，并将右表分发到所有 Shard 节点上进行 join 操作。
如果两张表都是分布式表，最好的连接方案是连接的 key 使用相同 Shard 算法，将对应的数据分到相同的 Shard 节点上。
多机 Shard 多副本查询流程
多机 Shard 多副本的查询流程只比多机 Shard 查询多一个步骤，就是判断选取哪个副本的数据；当前是选取出错次数最小的副本，可以配置在相同出错次数下的策略。