从ES到ClickHouse，Bonree ONE平台更轻更快！

本文字数：8052；估计阅读时间：21 分钟

作者：博睿数据  李骅宸（太道）& 娄志强（冬青）

本文在公众号【ClickHouseInc】首发

本系列第一篇内容：

100%降本增效！Bonree ONE平台通过ClickHouse实现了可观测信号数据的统一！

一、背景

Bonree ONE是博睿数据发布的一体化智能可观测平台，融合了指标、调用链、日志、会话、事件等多种数据。早期时候，调用链、会话、日志的数据存到了Elasticsearch。我们历史架构如下图，大数据团队需要维护多种存储。比如，告警业务A说要做AI训练，就得自己加工一份时序数据到HDFS，指标中心业务B说加工指标，就自己加工一条链路到ClickHouse，DEM业务C想做会话分析，APM业务D又想做调用链分析，日志业务E还想做日志分析，那么业务C、D、E就分别加工各自数据到ES，这就导致完全各自业务各自加工存储。这样烟囱式的发展到一定程度后，数据不好管理，资源浪费严重，并且各业务之间数据很难做关联式的统计和分析（比如用户的网络请求和后端调用链关联的多端打通场景），产品迭代越来越重。即使在产品web页面看起来能展示到一起，但下面架构和数据已经到了盘根错节的程度，对于千亿级、万亿级甚至更多的数据非常难治理，产品在私有化大B客户项目交付时更成为不可控的空中楼阁。

使用ES过程中我们也遇到了以下痛点：

1. 数据割裂。由于可观测性的业务特性，数据融合是真正的能力，像历史烟囱式的异构存储给我们的数据融合本身就带来了阻碍。可观测性场景里有很多互相关联的分析场景（比如前后端数据融合打通业务和系统去做根因分析），这就导致要么多端数据可能不一致，要么做不到真正的关联分析或关联加工成本很高。

2. 效率差。比如业务写入会话数据到ES的同时，相关联的快照数据写入对象存储系统，相对于快照数据的写入时间，ES数据写入响应时间需要等待至少亚秒级的延迟，导致产品上会有查询不到数据而出现天窗问题，影响体验。

3. 分析效率低。产品有搜索+统计分析的结合场景，海量数据近30天的统计经常查不出来。

4. 资源成本高。数据占用存储资源多，压缩效果不好，随着数据量的上涨，成本会越来越高。

5. 维护成本高。IO资源开销大，尤其私有化混部场景，对部署在同一个机器上的其他组件，影响较大。我们经常发现很多B端用户混部时，因为ES的IO占用过高影响了其他组件的稳定性，尤其金融类大客户对稳定性要求极高，我们需要经常驻场排障。

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

二、为什么选择ClickHouse

新的存储方案需要具备高写入吞吐、高读取效率、集群管理方便的特点。我们选中了ClickHouse是因为：

1. 写入效率：ClickHouse写入可以达到100M/秒，同时在延迟性上，