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

最新推荐文章于 2024-09-14 09:43:04 发布

ClickHouseDB

最新推荐文章于 2024-09-14 09:43:04 发布

阅读量620

点赞数 10

分类专栏：生态合作文章标签： clickhouse

本文链接：https://blog.csdn.net/ClickHouseDB/article/details/138302680

版权

生态合作专栏收录该内容

3 篇文章 0 订阅

订阅专栏

本文字数：1619；估计阅读时间：5 分钟

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

本文在公众号【ClickHouseInc】首发

背景

作为中国IT运维监控和可观测性领域领导者，博睿数据（股票代码：688229）凭借打造的Bonree ONE一体化智能可观测平台，蝉联APM（应用性能监控）中国市场第一，真正实现全栈、全链路、全场景的智能可观测，故障根因定位和决策支持，提升业务连续性。Bonree ONE作为领先的可观测性平台，融合了指标、调用链、日志、会话、事件等多种数据。

但历史上，我们的庞大多样性数据存储到多种存储里，比如，指标数据在Apache Druid存储里，日志、调用链、会话的数据存到了Elasticsearch，AI训练数据存到了HDFS，这就导致客户申请的资源过多、性能不好、关联数据受限、运维困难，尤其私有化混部的场景。痛定思痛，我们在近一年的时间里，经过系统改造瘦身和选型对比，我们将Driud、Elasticsearch、HDFS这些重组件存储的所有可观测性信号数据全部迁移到了ClickHouse。本期先介绍Druid迁移ClickHouse的部分。

从Druid迁移到ClickHouse

在第一版瘦身里，我们重点先把用于可观测性分析的指标类数据从Druid存储迁移到Clickhouse。底层架构基于开源的Clickhouse，自研了ck-consumer和ck-manager组件。ck-consumer用于控制攒批写入和限流防护，提高写入性能；ck-manager用于集群的管理。

以下是我们当时分析ClickHouse的优势：

数据平台组件较少，OLAP引擎只有ClickHouse单个组件，在写入和元数据协同上各有一个组件，且都支持高可用。
在POC场景下，ClickHouse精简部署，写入效率完全达到业务需要。
在小型集群的场景下，ClickHouse只需要单shard部署，在满足性能的前提下，支持高可用。
在晚回数据场景下，ClickHouse天然支持分区，在历史数据和实时数据上，没有区别对待，效率上是等同的。
在ClickHouse上，通过物化视图和多粒度表的支持，较大范围时间的查询效率同样可以在毫秒级别完成，且是稳定的。

我们围绕开发的一些feature能力：

写入资源平衡。
表粒度入库攒批控制。
多租户的支持。
数据自治理。
复杂数据类型上查询效率的改进。
持续优化读写性能，和资源瘦身。
数据重分布特性，针对数据扩容情况下的数据分布改进。
扩展DDL能力，可以在线支持针对物化视图、projection的动态加减列。
轻量级运维能力建设。

效果

从内存看：
1. POC配置规格从单机64G降到32G，单机可以支持运行100探针，运行时内存消耗在23G左右。
2. 指标存储底座从Druid切换到ClickHouse，内存资源降了60%（集群版和POC版都适用）。
从磁盘看：
1. ClickHouse没有Druid的二级hadoop存储占用（集群版和POC版都适用）。
2. ClickHouse本身较Druid压缩比会好些，各业务表的压缩比在8到20倍（集群版和POC版都适用）。
从性能看：
1. 拿公有云统计性能数据，基于ClickHouse的底座P99查询性能比历史Druid架构提高了6倍以上，平均耗时从秒级降到了毫秒级。
2. 同时在晚回数据场景，稳定性和效率比Druid体现的更加优秀，维护成本为0。

最后

第一阶段我们从Druid迁移到ClickHouse，效果比较明显。后续我们可以再分享从Elasticsearch迁移到ClickHouse、从Zookeeper迁移到HouseKeeper的经历。

征稿启示

面向社区长期正文，文章内容包括但不限于关于 ClickHouse 的技术研究、项目实践和创新做法等。建议行文风格干货输出&图文并茂。质量合格的文章将会发布在本公众号，优秀者也有机会推荐到 ClickHouse 官网。请将文章稿件的 WORD 版本发邮件至：Tracy.Wang@clickhouse.com