从 ES 到 CK：信息技术发展的新浪潮

背景

Bonree ONE 是博睿数据发布的国内首个一体化智能可观测平台。会话数据是 Bonree ONE 平台重要的业务模块，在切换到 Clickhouse 之前是基于 ElasticSearch 进行存储的。ElasticSearch（下文简称 ES）是一种基于 Lucene 的分布式全文搜索引擎，主要使用场景在全文检索方向。

ES 存储会话数据的痛点

会话数据的写入量很大，而且涉及一些联动数据，比如基于对象存储的快照数据，查询效率要求在秒级到亚秒级返回，在日志场景，ES 存在以下痛点：

• 写入同步慢、写入效率差，业务写入会话数据到 ES 的同时，相关联的快照数据写入对象存储系统，相对于快照数据的写入时间，ES 数据写入返回响应需要等待至少亚秒级的延迟，导致产品上会有查询不到数据的现象，影响体验。

• 数据占用存储多，压缩不好，随着数据量的上涨，成本会越来越高。

• 查询效率低，海量数据近 30 天经常查不出来。

• 维护成本高，IO 资源开销大，尤其私有化混部场景，对部署在同一个机器上的其他组件，影响较大。

ES 存在的诸多问题，使得我们迫切寻找一个新的存储方案来进行升级，解决写入和查询的性能问题以及集群管理。

为什么选择 Clickhouse

新的存储方案需要具备高写入吞吐、高读取效率、集群管理方便的特点。

• 写入效率：Clickhouse 写入可以达到 100M/秒，同时在延迟性上，受攒批效率的影响，实现了亚秒级别的数据写入延迟，而且稳定性相对于 ES 来说更强。在 ES 里，随着数据量积累增加，索引的更新成本是在逐步增长的相对的，写入稳定性也在受影响。

• 读取效率：在会话场景里，业务查询数据的时间范围以及对应的统计分析都是不确定的，Clickhouse 基于高频查询确认主键字段，基于常用高优查询指定索引等优化手段，保证查询效率稳定。而 ES 在应对非固定查询的场景下，会占用大量内存，同时由于索引块换入换出的问题，会引起 IO 较高的问题。

• 集群管理：我们自研了 Clickhouse 集群的管理平台，支持对 Clickhouse 服务的数据写入、读取、节点状态等的监控，以及常用运维操作，比如扩缩容、数据均衡等。在 ES 的集群管理上，没有足够的手段覆盖到监控、数据迁移等运维操作。

• 易用性：Clickhouse 基于 sql 查询，业务接入直接基于 jdbc 的方式或者 http 的方式就可以直接使用。在 ES 中，大段的 Json 格式的查询，有一定的学习门槛。

基于 ES 存储数据的架构如下：

基于 Clickhouse 存储会话的架构如下：

使用基于 Clickhouse 的方式进行存储，实现了多租户管理、查询资源管控、业务写入追踪和个性化调优等手段，让业务在写入效率和查询效率上提升明显。

Clickhouse 关键的参数调优

• parts_to_throw_insert：表分区之中活跃 part 数目超过多少，会抛出异常。针对不同的业务量，这个数字应该是不同的，用来保证相应的资源匹配相应的写入量级。

• max_threads：用于控制一个用户的查询线程数。

• max_execution_time：单个查询最大执行时间。一般跟业务相关，是业务可容忍的最大查询时间。

• background_pool_size：表引擎操作后台的线程数。太大会影响 cpu 资源，太小会影响 parts 数量，从而可能触发 parts_to_throw_insert 的异常。

• max_memory_usage：单个查询最多能够使用的内存大小，应对不同的硬件配置以及不同的用户会配置不同的内存大小。

遇到了哪些问题

问题一：too many parts

当写入超过 Clickhouse 服务承受的上限的时候，就会出现 too many parts 异常。这个异常的本意是防止 Clickhouse 服务在超负载的情况下挂掉，同时给维护人一个信号。因此，出现 too many parts 异常的时候，维护人就要关注当前服务是不是遇到超高峰数据的写入了。此时可以关注的指标如下：

• 当前服务占用的 cpu 是不是超预期了。

关注 merge 任务是不是占满队列，通常写入超预期的情况下，parts 数量也是暴涨，Clickhouse 为了保证查询效率，merge 任务就会暴涨，而 merge 任务是消耗硬件资源的，如果资源不够，merge 任务运行缓慢，就会降低 parts 数量的减少效率，从而导致 parts 数量缓慢增加，当增加到 parts_to_throw_insert 的数值时，就会产生 too many parts 的异常。

• 关注写入数据攒批的状态，如果写入频繁，单批次数量较小，会导致 parts 数量增长很快，很容易触发到 merge 任务运行的最大值，从而引发 too many parts 异常。

问题二：重启耗时很长

当集群容纳的数据量比较多的时候，Clickhouse 的重启耗时会比较长，通常会达到几十分钟到小时级别不等。重启服务时间过长，对于整个服务的高可用会挑战很大，写入端的稳定性、容错性以及实时性，都会受到挑战。Clickhouse 本身在解决超大容量服务时，也提供了解决方案，即元数据缓存。

效果展示

用 Clickhouse 存储会话模块的数据，存储资源节省明显，计算资源同样收益可观，解决了在 ES 存储方案中遇到的性能瓶颈和集群管理问题，同时在易用性上降低了门槛，让业务更加亲和地进行存储切换。

将会话数据从 ES 切换到 Clickhouse，总体运维成本更低，而且提升了写入和查询效率，在用户进行会话数据统计分析和明细时，查询稳定性提升明显，用户体验得到大幅改善。

未来，我们会更加专注 Clickhouse 集群的精细化管理和优化，主要聚焦在以下方向：

• merge 的效率提升。

• 存算分离。

• 高并发查询的优化。

以上三个方向的优化与完善都能够进一步巩固 Clickhouse 集群的稳定性，帮助我们应对更多的业务场景，让业务发展稳中提效。