ClickHouse集群为什么建议写分布式表

ClickHouse集群为什么建议写分布式表，实际上这也跟数量有关系，如果预估自己的业务数据量日增不到千万行, 那么写分布式表和本地表都可以, 但要注意如果选择写本地表, 请保证每次写入数据都建立新的连接, 且每个连接写入的数据量基本相同。如果业务日增千万以上, 并发插入大于10, 那么请写本地表。
主要的原因跟官方说的原理有关：

Data is written asynchronously. When inserted in the table, the data block is just written to the local file system. The data is sent to the remote servers in the background as soon as possible. The period for sending data is managed by the distributed_directory_monitor_sleep_time_ms and distributed_directory_monitor_max_sleep_time_ms settings. The Distributed engine sends each file with inserted data separately, but you can enable batch sending of files with the distributed_directory_monitor_batch_inserts setting. This setting improves cluster performance by better utilizing local server and network resources. You should check whether data is sent successfully by checking the list of files (data waiting to be sent) in the table directory: /var/lib/clickhouse/data/database/table/.
If the server ceased to exist or had a rough restart (for example, after a device failure) after an INSERT to a Distributed table, the inserted data might be lost. If a damaged data part is detected in the table directory, it is transferred to the ‘broken’ subdirectory and no longer used.

简单来说就是假设此时有两个分片节点，数据块当前写入分片节点1的本地文件系统，而属于分片2的数据会写入节点1的临时目录中，并且数据会尽快在后台通过建立tcp连接异步发送到分片节点2的远程服务器，在这个机制下会产生三个问题：

资源消耗问题：在分片2的数据写入临时目录中会产生写放大现象，会大量消耗分片节点1多余cpu和磁盘等资源。
数据准确性和一致性问题： 在写入节点2的时候，节点1或节点2的不正常都会导致数据问题（节点1挂了数据丢失，节点2挂了或者节点2表删了节点1会无限制重试，占用资源）
集群shard数过多问题 ： 一般来说一个 ClickHouse 集群会配置多个 shard，每个 shard 都会建立 MergeTree 表和对应的分布式表。如果直接把数据写入分布式表，数据就可能会分发给每个 shard。假设有 N 个节点，每个节点每秒收到一个 INSERT Query，分发 N 次之后，一共就是每秒生成 NxN 个 part 目录。集群 shard 数越多，分发产生的小文件也会越多（如果写本地表就会相对集中些），最后会导致你写入到 MergeTree 的 Part 的数会特别多，最后会拖垮整个文件的系统。

而且，因此综合以上三个方面考虑都不建议写入分布式表，而是采用客户端通过一定算法向集群中的节点写入数据，同时也要注意数据量的写入均衡问题，每次写入都新建连接，每次新建连接设置的batch_size都平均，不要出现第一次10000第二次10的情况。