最强OLAP分析引擎-Clickhouse快速上手五--持续更新

七、生产常见问题

1、Clickhouse的数据一致性问题

在生产环境中，数据一致性的重要性，不论如何强调都不过分。而clickhouse在进行数据变更时，都会产生一个临时分区，而不会更改原始数据文件，对数据文件的修改操作会要等到数据合并时才进行。所以clickhouse只能保证数据的最终一致性，而不能保证强一致性。很可能数据变更后，程序通过clickhouse查到之前的错误数据。因此使用clickhouse，要尽量比较数据的增删改这类数据变更操作。但是实际使用时，又不可避免的要使用数据变更操作。这时就需要有一套策略来全面处理数据一致性问题。

首先，对于分布式表，最好的办法是尽量避免使用。如果非要使用分布式表，一定要打开internal_replication。每个分片一定要配置多副本机制，使用副本机制来保证副本之间的数据一致性。

一般来说，分布式表会带来非常多的问题。往分布式表中导入数据时，数据是异步写入到不同的分片当中的，这样数据写入过程中就不可避免的有先有后。在最后一个分片的数据写入完成之前，不可避免的就会产生数据一致性的问题。

另外，对于分布式表，如果在数据写入时，这个分片的服务宕机了，那么插入的数据就有可能会丢失。clickhouse的做法是将这个数据分片转移到broken子目录中，并不再使用这个数据分片。也就是说，这时，clickhouse这一次的数据写入操作ius丢失了。造成的结果就是有可能就是一次update操作要更新1000条数据，但是最终却只更新了900条。

然后，对于本地的数据库，也一定要注意多副本造成的数据一致性问题。clickhouse中，即使是提供了去重功能的ReplacingMergeTree，他只能保证在数据合并时会去重，只能保证数据的最终一致性，而不能保证强一致性。

对于MergeTree系列引擎，要注意他的合并操作不是定时的，是后台定时任务去自动进行merge合并操作。这个任务执行时间是无法设置或者掌控的。一般merge时间是在写入操作完成后的10~15分钟。但是如果某个分区一直不写入新的数据，那也有可能这个分区一直不会merge。这个时候，也只能通过optimize语句手动进行更新。

但是optimize语句强制合并数据CPU重操作，数据量大时，会非常消耗CPU资源，影响到线上的查询功能。因此，建议在晚上系统负载比较小的时候执行。另外，merge合并操作是没有锁的概念的，合并过程中依然可以正常写入。

实际生产中，在某些对数据一致性要求比较高的场景，可以自行采用乐观锁来屏蔽数据一致性的问题。例如，在创建一张表时，增加两个字段 sign和 version。sign表示这条数据是否删除，version数据表示这条数据的更新版本。像这样：

create table A
(
xxx,
_sign UInt8,
_version UInt32
)

当进行数据更新时，不再进行更新操作，改为插入一条新的数据，同时version版本号加1。这样查询时，只要过滤verion版本号最大的一条数据就可以查询到最新的数据。

对于删除操作，同样改为新插入一条数据，version版本号加1的同时，把sign设置为-1，表示已删除。查询时，同样是找到版本号最大的这条数据，通过判断sign是不是等于-1，就能判断出这条数据是否被删除了。

但是这种方案需要注意过期数据要另行定期删除。

2、多副本表，尽量固定写入的节点

为了保证服务的高可用，企业使用clickhouse基本都会使用多副本的复制表。在clickhouse的复制表中，多个副本的地位是平等的，并没有主从之分。理论上写入任何一个节点都是可以的。clickhouse的副本之间会通过复制数据的方式进行同步。

但是，考虑到副本之间复制数据有可能会失败，在实际使用中，还是建议固定一个写入节点，作为主节点。因为当clickhouse服务出问题了，导致某一批次数据写入操作失败时，clickhouse只能保证数据块的写入是原子性的，而并不保证整批数据是原子性的。这样当服务恢复过来后，就可能造成有些数据写成功了，有些数据写失败了。这时就需要将这些写入成功的数据块还原回去，才能对这一批次数据重
新进行写入。

这时，可以从副本中对数据进行全量恢复。恢复的方法很简单，将主节点的metadata和data目录全部清空，然后将副本节点的metadata和data目录拷贝过来，然后重启数据库就可以了。

3、Zookeeper数据丢失导致副本表无法启动

clickhouse的副本表需要由zookeeper提供集群信息。这时，如果zookeeper服务出问题了，导致丢失了一部分副本表的表信息，而clickhouse的metadata元数据中依然存在zookeeper的信息，就会导致启动报错。

Can’t get data for node /clickhouse/tables/01-
02/xxxxx/xxxxxxx/replicas/xxx/metadata: node doesn’t exist (No node):
Cannot attach table xxxxxxx

这时就需要手动重建zookeeper里的信息。手动恢复当然不太可能。这时可以移除问题节点上的metadata中对应表的结构文件，将clickhouse服务启动起来。启动完成后，重新创建表即可。建表的语句可以从metadata中的表结构文件中获取，也可以从其他正常节点上执行 show create table 语句获取。

而clickhouse中对应的表数据，会在表重建后重新下载。这样过一段时间再来验
证一下数据是否一致就可以了。

最后，关于clickhouse常见的一些问题，可以参考下阿里云中提供的常见问题列
表。https://help.aliyun.com/document_detail/162815.html。

八、clickhouse总结

整体来看，clickhouse以一己之力，就足够支撑一个完整的数仓功能。这与hadoop体系需要非常多的组件通力合作，形成了鲜明的对比。

clickhouse极大的挖掘了服务器的性能。强大的数据写入性能、极其高效的查询性能、高效的压缩存储以及大数据查询的强大吞吐量 ，这些特点使得clickhouse即使单机部署，也丝毫不逊色于传统的大数据集群。而他的集群功能也只需要通过zookeeper将单机节点松散的组合到一起，这使得他的水平扩展比常见的一些大数据平台更为简单高效。

在clickhouse极强性能的背后，他的使用体验相比于其他大数据产品，却显得极为简单直接。所有功能都是从几个极少的扩展点有序的堆叠扩展。clickhouse的使用体验也是非常舒适自然。使用体验简单的背后，其实也代表着运维的工作相当轻松。相比Hadoop体系以及其他大数据产品各种各样的参数调优，版本兼容，clickhouse的运维工作就显得简单多了。

另外，最重要的是，clickhouse的版本更迭相当的迅速。BUG修复速度非常快，并且新功能也层出不穷。目前体现出来的很多实验阶段的特性都非常有吸引力。而clickhouse主动兼容jdbc、mysql和postgresql这些成熟产品，也使得他的周边生态非常成熟。使用clickhouse基本没有什么技术门槛，当然，要用好还是没那么简单的。

综合这些显著的特点，clickhouse非常适合用来搭建数据仓库。未来进行数仓产品选型时，clickhouse是一个不得不考虑比较的重要产品。