字节 clickhouse_去字节跳动工作好吗

字节 clickhouse_去字节跳动工作好吗更多技术交流、求职机会,欢迎关注字节跳动数据平台微信公众号,回复【1】进入官方交流群 相信大家都对大名鼎鼎的ClickHouse有一定的了解了,它强大的数据分析性能让人印象深刻。但在字节大量生产使用中

字节跳动基于ClickHouse优化实践之“高可用”

更多技术交流、求职机会,欢迎关注字节跳动数据平台微信公众号,回复【1】进入官方交流群

 

相信大家都对大名鼎鼎的ClickHouse有一定的了解了,它强大的数据分析性能让人印象深刻。但在字节大量生产使用中,发现了ClickHouse依然存在了一定的限制。本篇将详细介绍我们是如何为ClickHouse增强高可用能力的。

字节遇到的ClickHouse可用性问题

随着字节业务的快速发展,产品快速扩张,承载业务的ClickHouse集群节点数也快速增加。另一方面,按照天进行的数据分区也快速增加,一个集群管理的库表特别多,开始出现元数据不一致的情况。两方面结合,导致集群的可用性极速下降,以至于到了业务难以接受的程度。直观的问题有三类:

1、故障变多

典型的例子如硬件故障,几乎每天都会出现。另外,当集群达到一定的规模,Zookeeper会成为瓶颈,增加故障发生频率。

2、故障恢复时间长

因为数据分区变多,导致一旦发生故障,恢复时间经常会需要1个小时以上,这是业务方完全不能接受的。

3、运维复杂度提升

以往只需要一个人负责运维的集群,由于节点增加和分区变多,运维复杂度和难度成倍的增加,目前运维人数增加了几人也依然拙荆见肘,依然难保证集群的稳定运行。

可用性问题已经成为制约业务发展的重要问题,因此我们决定将影响高可用的问题一一拆解,并逐个解决。

提升高可用能力的方案

一、降低Zookeeper压力

问题所在:

原生ClickHouse 使用 ReplicatedMergeTree 引擎来实现数据同步。原理上,ReplicatedMergeTree 基于 ZooKeeper 完成多副本的选主、数据同步、故障恢复等功能。由于 ReplicatedMergeTree 对 ZooKeeper 的使用比较重,除了每组副本一些表级别的元信息,还存储了逻辑日志、part 信息等潜在数量级较大的信息。Zookeeper并不是一个能做到良好线性扩展的系统,当ZooKeeper 在相对较高的负载情况下运行时,往往性能表现并不佳,甚至会出现副本无法写入,数据也无法同步的情况。在字节内部实际使用和运维 ClickHouse 的过程中,ZooKeeper 也是非常容易成为一个瓶颈的组件。

改造思路:

ReplicatedMergeTree 支持 insert_quorum,insert_quorum 是指如果副本数为3,insert_quorum=2,要成功写入至少两个副本才会返回写入成功。

新分区在副本之间复制的流程如下:

字节 clickhouse_去字节跳动工作好吗

 

 

可以看到,反复在 zookeeper 中进行分发日志、数据交换等步骤,这正是引起瓶颈的原因之一。

为了降低对 ZooKeeper 的负载,在ByteHouse中重新实现了一套 HaMergeTree 引擎。通过HaMergeTree降低对 ZooKeeper 的请求次数,减少在 ZooKeeper 上存储的数据量,新的 HaMergeTree 同步引擎:

1)保留ZooKeeper上表级别的元信息;

2)简化逻辑日志的分配;

3)将 part 信息从 ZooKeeper 日志移除。

字节 clickhouse_去字节跳动工作好吗

 

 

HaMergeTree 减少了操作日志等信息在zookeeper里面的存放,来减少zookeeper的负载,zookeeper里面只是存放log LSN, 具体日志在副本之间通过gossip协议同步回放。

在保持和ReplicatedMergeTree完全兼容的前提下,新的 HaMergeTree 极大减轻了对 ZooKeeper 的负载,实现了 ZooKeeper 集群的压力与数据量不相关。上线后,因Zookeeper导致的异常大量减少。无论是单集群几百甚至上千节点,还是单节点上万张表,都能保障良好的稳定性。

二、提升故障恢复能力

问题所在:

虽然所有数据从业者都在做各种努力,想要保证线上生产环境不出故障,但是现实中还是难以避免会遇到各式各样的问题。主要是由下面这几种因素引起的:

软件缺陷:软件设计本身的Bug引起的系统非正常终止,或依赖的组件兼容引发的问题。

硬件故障:常见的有磁盘损坏、内容故障、CPU故障等,当集群规模扩大后发生的频率也线性增加。

内存溢出导致进程被停止:在OLAP数据库中经常发生。

意外因素:如断电、误操作等引发的问题。

由于原生ClickHouse希望达到极致性能的初衷,所以在ClickHouse系统中元数据常驻于内存中,这导致了ClickHouse server重启时间非常长。因而当故障发生后,恢复的时间也很长,动辄一到两个小时,相当于业务也要中断一到两个小时。当故障频繁出现,造成的业务损失是无法估量的。

改造思路:

为了解决上述问题,在ByteHouse中采用了元数据持久化的方案,将元数据持久化到RocksDB, Server启动时直接从RocksDB加载元数据,内存中也仅仅存放必要的Part信息。因此可以减少元数据对内存的占用,以及加速集群的启动以及故障恢复时间。

如下图所示,元数据持久化整体上采用了RocksDB+Meta in Memory的方式,每个Table都会对应一个RocksDB数据库存放该表所有Part的元信息。Table首次启动时,从文件系统中加载的Part元数据将被持久化到RocksDB中;之后重启时就可以直接从RocksDB中加载Part。每个表从RocksDB或者文件系统加载的Part将只在内存中存放必要的Part信息。在实际使用Part时,将通过内存中存放的Part元信息去RocksDB中读取并加载对应Part。

字节 clickhouse_去字节跳动工作好吗

 

 

完成元数据持久化后,在性能基本无损失的情况下,单机支持的part不再受内存容量的限制,可以达到100万以上。最重要的是,故障恢复的时间显著缩短,只需要此前的几十分之一的时间就可以完成。例如在原生ClickHouse中需要一到两个小时的恢复时间,在ByteHouse中只需要3分钟,大大提高的系统的高可用能力,为业务提供了坚实保障。

三、其他方面

除了以上两点,在ByteHouse中在其他很多方面都为高可用能力做了增强,如通过HaKafka引擎提升了数据写入的高可用性,提升实时数据写入的容错率,可自动切换主备写入;增加了监控运维平台,实现对关键指标的监控、告警;增加多种问题诊断工具,能实现故障的快速定位。

对于数据分析平台来说,稳定性是重中之重。我们对ByteHouse的高可用能力的提升是不会停止的,在极致性能的背后,力图为用户提供最强有力的稳定性保障。

 

立即跳转火山引擎ByteHouse官网了解详情

原文地址:https://www.cnblogs.com/bytedata/archive/2022/09/15/16696415.html

版权声明:本文内容由互联网用户自发贡献,该文观点仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 举报,一经查实,本站将立刻删除。
转载请注明出处: https://daima100.com/4769.html

(0)
上一篇 2023-06-05
下一篇 2023-06-05

相关推荐

发表回复

您的电子邮箱地址不会被公开。 必填项已用*标注