Bonree ONE 是博睿数据发布的国内首个一体化智能可观测平台。会话数据是 Bonree ONE 平台重要的业务模块，在切换到 Clickhouse 之前是基于 ElasticSearch 进行存储的。ElasticSearch（下文简称 ES）是一种基于 Lucene 的分布式全文搜索引擎，主要使用场景在全文检索方向。
会话数据的写入量很大，而且涉及一些联动数据，比如基于对象存储的快照数据，查询效率要求在秒级到亚秒级返回，在日志场景，ES 存在以下痛点：
ES 存在的诸多问题，使得我们迫切寻找一个新的存储方案来进行升级，解决写入和查询的性能问题以及集群管理。
新的存储方案需要具备高写入吞吐、高读取效率、集群管理方便的特点。
基于 ES 存储数据的架构如下：
基于 Clickhouse 存储会话的架构如下：
使用基于 Clickhouse 的方式进行存储，实现了多租户管理、查询资源管控、业务写入追踪和个性化调优等手段，让业务在写入效率和查询效率上提升明显。
问题一：too many parts
当写入超过 Clickhouse 服务承受的上限的时候，就会出现 too many parts 异常。这个异常的本意是防止 Clickhouse 服务在超负载的情况下挂掉，同时给维护人一个信号。因此，出现 too many parts 异常的时候，维护人就要关注当前服务是不是遇到超高峰数据的写入了。此时可以关注的指标如下：
关注 merge 任务是不是占满队列，通常写入超预期的情况下，parts 数量也是暴涨，Clickhouse 为了保证查询效率，merge 任务就会暴涨，而 merge 任务是消耗硬件资源的，如果资源不够，merge 任务运行缓慢，就会降低 parts 数量的减少效率，从而导致 parts 数量缓慢增加，当增加到 parts_to_throw_insert 的数值时，就会产生 too many parts 的异常。
问题二：重启耗时很长
当集群容纳的数据量比较多的时候，Clickhouse 的重启耗时会比较长，通常会达到几十分钟到小时级别不等。重启服务时间过长，对于整个服务的高可用会挑战很大，写入端的稳定性、容错性以及实时性，都会受到挑战。Clickhouse 本身在解决超大容量服务时，也提供了解决方案，即元数据缓存。
|
查询效率提升数倍不止 |
用 Clickhouse 存储会话模块的数据，存储资源节省明显，计算资源同样收益可观，解决了在 ES 存储方案中遇到的性能瓶颈和集群管理问题，同时在易用性上降低了门槛，让业务更加亲和地进行存储切换。
将会话数据从 ES 切换到 Clickhouse，总体运维成本更低，而且提升了写入和查询效率，在用户进行会话数据统计分析和明细时，查询稳定性提升明显，用户体验得到大幅改善。
未来，我们会更加专注 Clickhouse 集群的精细化管理和优化，主要聚焦在以下方向：
以上三个方向的优化与完善都能够进一步巩固 Clickhouse 集群的稳定性，帮助我们应对更多的业务场景，让业务发展稳中提效。
