大家好，我是考100分的小小码 ，祝大家学习进步，加薪顺利呀。今天说一说字节 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，要成功写入至少两个副本才会返回写入成功。
新分区在副本之间复制的流程如下：
可以看到，反复在 zookeeper 中进行分发日志、数据交换等步骤，这正是引起瓶颈的原因之一。
为了降低对 ZooKeeper 的负载，在ByteHouse中重新实现了一套 HaMergeTree 引擎。通过HaMergeTree降低对 ZooKeeper 的请求次数，减少在 ZooKeeper 上存储的数据量，新的 HaMergeTree 同步引擎：
1）保留ZooKeeper上表级别的元信息；
2）简化逻辑日志的分配；
3）将 part 信息从 ZooKeeper 日志移除。
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。
完成元数据持久化后，在性能基本无损失的情况下，单机支持的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
