ClickHouse为啥在字节跳动能这么火？

hzbooks

于 2022-04-18 08:00:00 发布

阅读量726

点赞数

文章标签：运维大数据分布式编程语言 hadoop

原文链接：https://mp.weixin.qq.com/s?__biz=Mzg5MDU5NTM1NQ==&mid=2247545215&idx=2&sn=19b35aab21719bdb1f6df48fd5a03155&chksm=cfd8400bf8afc91d67e05231abd31c0fd180cbfd4890cc03765a15f30c4931dcf600e0c3031d&scene=126&&sessionid=0

版权

作者 | 蔡芳芳

采访嘉宾 | 陈星、邵祎旸、海书山

ClickHouse 开源于 2016 年，在一众大数据计算引擎里算是一个后起之秀。但凭借性能方面的突出优势，这几年 ClickHouse 在分析型数据库领域可谓风生水起。

作为 ClickHouse 深度用户，字节跳动拥有国内规模最大的 ClickHouse 集群。根据官方提供的最新数据，截至 2022 年 2 月底，字节跳动内部的 ClickHouse 节点总数已经超过 18000 个，管理总数据量超过 700PB，最大的集群规模在 2400 余个节点。在这之上，承载着字节跳动广泛的业务增长分析工作。

熟悉 ClickHouse 的开发者可能会知道，虽然 ClickHouse 性能强大，但可扩展性、易用性却差强人意，随着使用不断深入、集群规模不断扩大，使用和运维的技术门槛会变得越来越高。不支持弹性扩缩容更是一个长期被诟病的问题。

为了解决实际业务场景对 ClickHouse 的需求，字节跳动基于开源的 ClickHouse 做了大量二次开发和深度投入。这部分投入到今天也还在继续，使得字节跳动在 ClickHouse 的积累上相对领先业界，并最终沉淀出了去年在火山引擎平台正式发布的商业化产品 ByteHouse。

从 ClickHouse 到 ByteHouse，经历了怎样的演进历程？ClickHouse 节点增长至近 2 万台这一路，技术团队遇到了哪些挑战？ClickHouse 云原生化改造是如何展开的？本文深度采访了火山引擎 ByteHouse 团队核心成员，试图更清晰地呈现出 ClickHouse 在字节跳动内部的“进化”之路。

试水 ClickHouse

字节跳动最早开始接触 ClickHouse 是在 2017 年年底。

对于字节来说，用户增长分析的重要性不言而喻。这是一项十分考验运营团队能力的工作，怎么衡量不同运营方法的有效性、该考量哪些数据指标、如何对指标的波动进行更深层次的原因分析等等，其中涉及大量数据分析，对于分析的实时性也有很高的要求，这些都离不开一个好用的实时数据分析平台的支撑。

在字节内部第一个“吃螃蟹”、试水 ClickHouse 的业务场景，恰恰就是用户增长分析，直到现在它也依然是字节 ClickHouse 最重要的业务场景之一。

其实在尝试 ClickHouse 之前，为了解决数据量和分析效率的问题，字节的工程师们已经在数据分析引擎层面做了不少探索，当然也经历了一些曲折。

在 OLAP 引擎上，团队尝试过 Kylin、Druid、Spark 等。这些不同的尝试，也是根据当时面临的最迫切的问题做出的选择。比如一开始，最需要解决的是“快”，所以团队选了 Kylin，它的优点是能够提供毫秒级别的查询延时。但 Kylin 也存在需要预聚合、需要提前定义数据模型和无法进行交互式分析等问题，随着数据量变大反而会导致返回结果慢，所以后来团队又改用 Spark 来解决问题。但 Spark 同样存在不少问题困扰着团队，比如查询速度不够快、资源使用率高、稳定性不够好，以及无法支持更长时间的数据等。

这时候团队开始反思：现有的查询引擎是否能持续支撑后续业务高速发展？我们要从什么维度来考虑？是从我们现有什么样的技术能力，还是从我们需要什么样的技术能力？

基于这个选型思路的转变，团队开始不设边界来看，对于 OLAP 来说，需要考量哪些因素？

一是对 OLAP 非常朴素又简单的要求：高可用和强性能。不论给 OLAP 加上多少复用、赋予多少身份，最核心且首要的诉求是能存储足够多的数据、足够稳定，并且可以非常快地查到数据。这是第一个要求——要好用，即满足海量数据下交互式分析的性能要求，达到秒级响应。

二是复用。在好用的基础上，团队希望能尽量用一套技术栈解决大部分问题甚至是所有问题，这就需要引擎是可定制的，能让开发人员在这套技术栈上搭建各种面向场景化的应用。

三是易用，能让用户更加自主地把产品使用起来。

最终，经过对当时市面上已有的多款开源引擎的调研和测试，团队最终选择采用 ClickHouse 作为 OLAP 查询引擎，并开始基于此不断迭代。

在早期试水阶段，团队的基本思路是先提供基础能力，满足特定业务场景用户的基本使用需求，然后在用户使用过程中一边收集反馈一边做优化。

要让业务方用起来，首先得为 ClickHouse 补上原来缺失的数据生命周期管理能力，提供数据接入的基本功能。这样一来，业务方只需要在数据接入服务中注册并进行配置，服务就会自动完成元数据管理和导入任务的调度，每次当外部数据源就绪后，接入服务会自动触发，并将相应的数据转储和格式化到 ClickHouse 中。调度任务执行完毕后，业务方用户就可以直接在平台上进行查询分析。然后是提升 SQL-based 指标计算的执行效率，包括 UD(A)F 增强、SQL 语法增强等，另外在数据可视化组件开发上，团队也费了不少功夫。

通过早期试水，ClickHouse 整体方案的可行性在实际业务应用中得到了验证，它能够满足交互式响应的用户体验需求，数据产品迭代较快且稳定性基本满足要求。同时，方案整体架构的水平扩展能力，也经历了从几十台机器扩大到几百台机器规模的考验。

虽然彼时 ClickHouse 还只是一个能够解决单一应用性能问题、满足特定业务场景需求的引擎，但团队看到了这套方案的可能性，并为其设定了新的目标：打造成一个公司级别通用的 OLAP 系统。ClickHouse 很快进入在字节内部大规模应用的新阶段，新的问题和挑战也随之而来。

规模扩大：从单一业务到全公司

随着 ClickHouse 支持的业务场景从用户增长分析这个单一应用，扩展到 BI 分析、AB 测试、模型预估等多个场景，需求方不断增多，不同业务需求对技术的要求也发生了比较大的变化。通用的技术已经很难解决所有需求，这就要求团队针对不同的应用场景抽象出对应解决方案，其中涉及不少自底向上的自研功能。与此同时，ClickHouse 集群规模扩张了至少一个数量级，暴露出了 ClickHouse 在应对大数据量和高可用等方面的不足。

首先，ClickHouse 本身是存储计算紧耦合架构，本地存储容量比较有限，一般单节点存储大约只有几十 TB。伴随用户数增长而来的海量数据很容易让原来就有限的本地存储更加捉襟见肘。虽然增加外部存储空间可以解决部分问题，但无限制扩容也不现实。其次，数据量大了之后，数据写入对查询服务的影响已经无法完全忽略。

针对本地存储局限问题，团队采用了冷热数据分级存储的解决思路，也就是把长期不查的数据放到底层的冷库存里，远程的计算资源可以出让给其他业务，而本地存储只管理日常需要查询的近几个月数据。

对于数据写入影响查询服务性能的问题，则考虑把数据写入服务放到查询服务外部。当导入数据量比较小的时候，直接用引擎自身的资源格式化之后放到本地存储；当数据量很大的时候，则由数据导入服务负责把外部数据源格式化 ClickHouse 能够识别的形式，完成数据排序、compressed 等构建工作，然后把结果写回共享存储里面，此时 ClickHouse 只需要把格式化好的源数据拉取过去注册一下就可以查询了。当数据达到一定的生命周期、查询频率降低后，再把数据重新 down 到 HDFS 上。

这套方案解决了数据量变大时导入服务和查询之间的资源竞争问题，同时也让按需补充计算资源和存储资源变得可行，不再需要因为流量峰值或波动就动不动扩展集群规模。

虽然现在看来，这套方案还存在一些不足，也没有做到完全的弹性架构，但已经朝着完全弹性的方向迈出了重要的一步。

除了海量数据带来的挑战，当集群扩展到一定规模之后，可用性问题也越来越棘手。产品扩张导致数据分区变多、节点数变多、故障变多，最常见的硬盘故障几乎每天都会发生。从可用性的视角来看，ClickHouse 社区版本的复制方案 ReplicatedMergeTree（ZK）已经面临瓶颈；而增多的数据分区会导致故障恢复时间变长，又进一步增加了运维的复杂度与难度。

ClickHouse 社区版原生的 Replication 方案有太多的信息存在 ZooKeeper 上，为了保证服务，一般会有一个或者几个副本，在字节内部主要是两个副本的方案。

早期内部曾有一个 400 个节点的集群，只存了半年的数据。突然有一天团队发现服务特别不稳定，ZK 的响应经常超时，table 可能变成只读模式，发现 znode 太多。而且 ZK 并不是可水平扩展的框架，按照当时的数据预估，整个服务很快就会不可用了。

团队分析后得出结论，实际上 ClickHouse 把 ZK 当成了三种服务的结合，而不仅把它当作一个 Coordinate service，可能这也是大家使用 ZK 的常用用法。ClickHouse 还会把它当作 Log Service，很多行为日志等数字的信息也会存在 ZK 上；还会作为表的 catalog service，像表的一些 schema 信息也会在 ZK 上做校验，这就会导致 ZK 上接入的数量与数据总量会成线性关系。按照这样的数据增长预估，ClickHouse 可能就根本无法支撑头条、抖音的全量需求。

为了解决问题，团队基于 MergeTree 存储引擎开发了一套自己的高可用方案，思路就是把更多 ZK 上的信息卸载下来，ZK 只作为 coordinate Service。只让它做三件简单的事情：行为日志的 Sequence Number 分配、Block ID 的分配和数据的元信息，这样就能保证数据和行为在全局内是唯一的。

关于节点，它维护自身的数据信息和行为日志信息，Log 和数据的信息在一个 shard 内部的副本之间，通过 Gossip 协议进行交互。保留原生的 multi-master 写入特性，这样多个副本都是可以写的，好处是能够简化数据导入。下图是一个简单的框架图。

HaMergeTree 简单框架

改造完成后，服务的高可用基本上得到了保障，ZooKeeper 压力也不会随着数据增加而增加。这让 ClickHouse 更大规模使用变得可能，即使是一个集群上千台机器或者一个节点有几千张表，改造后的服务都可以 Hold 住。

针对故障恢复时间长的问题，团队也做了一些优化和改进。比如 ClickHouse 社区版为了极致的性能优化，将元数据存储在内存中，但因此会在实际使用中带来服务重启等各种异常。对应地，团队做了元数据持久化的改进，将故障重启时间从小时级降到分钟级，减少对实际业务的影响，从而有效提升 SLA 到 99.95% 的级别。

与此同时，团队逐步为 ClickHouse 社区版补齐了运维支持能力。从安装部署层面的自动化配置，到日常运维层面的故障节点替换、健康度检测、故障预警等功能，将原生的引擎升级为企业版产品，从而极大降低产品使用和运维过程中对人的依赖，也降低了业务接入成本。通过界面化的建表等 DDL 操作，抽象 ClickHouse 社区版复杂的底表逻辑，进一步降低业务用户的上手和理解成本。此外，提供了多种实时与离线的数据源接入方式，规范化数据写入，减少人为错误或不当使用。

整体而言，团队将大部分基于 ClickHouse 的使用经验和最佳实践都产品化，沉淀为服务和工具，提升了业务用户的易用性；同时，通过提供可视化的运维与监控界面，降低了黑屏操作和重复排障的频率，系统管理员的可管理性也得到加强。这些都让曾经使用和运维难度都极高的 ClickHouse 变得更加“易用”。

借助产品化的运维能力，如今即使面对上万台的集群规模，字节内部也仅需要几位 SRE 就能完成集群的日常运维工作。当然，这是后话了。

从初步试水到大规模应用，团队围绕字节跳动真实业务场景，一边解决技术挑战一边打磨产品，基于 ClickHouse 做了大量二次开发和深度优化。这套基于 ClickHouse 长出来的实时数据分析系统，跟 ClickHouse 社区版相比，已经进化出了很多不一样的地方。