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

《ClickHouse为啥在字节跳动能这么火？.docx》由会员分享，可在线阅读，更多相关《ClickHouse为啥在字节跳动能这么火？.docx（7页珍藏版）》请在淘文阁 - 分享文档赚钱的网站上搜索。

1、ClickHouse开源于2016年，在一众大数据计算引擎里算是个后起之秀。但凭借性能方面的突出优势，这几年ClickHouse在分析型数据库领域可谓风 生水起。作为ClickHouse深度用户，字节跳动拥有国内规模最大的ClickHouse集 群。根据官方提供的最新数据，截至2022年2月底，字节跳动内部的 ClickHouse节点总数已经超过18000个，管理总数据量超过700PB,最大的 集群规模在2400余个节点。在这之上，承载着字节跳动广泛的业务增长分析 工作。熟悉ClickHouse的开发者可能会知道，虽然ClickHouse性能强大，但可扩 展性、易用性却差强人意，随着使用不断深

2、入、集群规模不断扩大，使用和 运维的技术门槛会变得越来越高。不支持弹性扩缩容更是一个长期被诟病的 问题。为了解决实际业务场景对ClickHouse的需求，字节跳动基于开源的 ClickHouse做了大量二次开发和深度投入。这局部投入到今天也还在继续， 使得字节跳动在ClickHouse的积累上相对领先业界，并最终沉淀出了去年在 火山引擎平台正式发布的商业化产品ByteHouseo从ClickHouse到ByteHouse,经历了怎样的演进历程？ClickHouse节点增长 至近2万台这一路，技术团队遇到了哪些挑战？ ClickHouse云原生化改造是 如何展开的？本文深度采访了火山引擎Byte

3、House团队核心成员，试图更清 晰地呈现出ClickHouse在字节跳动内部的“进化”之路。01试水 ClickHouse字节跳动最早开始接触ClickHouse是在2017年年底。对于字节来说，用户增长分析的重要性不言而喻。这是一项十分考验运营团 队能力的工作，怎么衡量不同运营方法的有效性、该考量哪些数据指标、如 何对指标的波动进行更深层次的原因分析等等，其中涉及大量数据分析，对 于分析的实时性也有很高的要求，这些都离不开一个好用的实时数据分析平 台的支撑。在字节内部第一个“吃螃蟹、试水ClickHouse的业务场景，恰恰就是用户增 长分析，直到现在它也依然是字节ClickHouse最重要

4、的业务场景之一。其实在尝试ClickHouse之前，为了解决数据量和分析效率的问题，字节的工 程师们已经在数据分析引擎层面做了不少探索，当然也经历了一些曲折。在OLAP引擎上，团队尝试过Kylin、Druid、Spark等。这些不同的尝试， 也是根据当时面临的最迫切的问题做出的选择。比方一开始，最需要解决的 是“快”，所以团队选了 Kylin,它的优点是能够提供毫秒级别的查询延时。但 Kylin也存在需要预聚合、需要提前定义数据模型和无法进行交互式分析等问 题，随着数据量变大反而会导致返回结果慢，所以后来团队又改用Spark来 解决问题。但Spark同样存在不少问题困扰着团队，比方查询速度不够

5、快、 资源使用率高、稳定性不够好，以及无法支持更长时间的数据等。这时候团队开始反思：现有的查询引擎是否能持续支撑后续业务高速开展？ 我们要从什么维度来考虑？是从我们现有什公样的技术能力，还是从我们需 要什么样的技术能力？基于这个选型思路的转变，团队开始不设边界来看，对于OLAP来说，需要 考量哪些因索？一是对OLAP非常朴素乂简单的要求：高可用和强性能。不管给OLAP加上 多少复用、赋予多少身份，最核心且首要的诉求是能存储足够多的数据、足 够稳定，并且可以非常快地查到数据。这是第一个要求要好用，即满足 海量数据卜交互式分析的性能要求，到达秒级响应。二是复用。在好用的基础上，团队希望能尽量用一套

6、技术栈解决大局部问题 甚至是所有问题，这就需要引擎是可定制的，能让开发人员在这套技术栈上 搭建各种面向场景化的应用。三是易用，能让用户更加自主地把产品使用起来。最终，经过对当时市面上已有的多款开源引擎的调研和测试，团队最终选择 采用ClickHouse作为OLAP查询引擎，并开始基于此不断迭代。在早期试水阶段，团队的基本思路是先提供基础能力，满足特定业务场景用 户的基本使用需求，然后在用户使用过程中一边收集反应一边做优化。要让业务方用起来，首先得为ClickHouse补上原来缺失的数据生命周期管理 能力，提供数据接入的基本功能。这样一来，业务方只需要在数据接入服务 中注册并进行配置，服务就会自

7、动完成元数据管理和导入任务的调度，每次 当外部数据源就绪后，接入服务会自动触发，并将相应的数据转储和格式化 到ClickHouse中。调度任务执行完毕后，业务方用户就可以直接在平台上进 行查询分析。然后是提升SQL-based指标计算的执行效率，包括UD(A)F增 强、SQL语法增强等，另外在数据可视化组件开发匕团队也费了不少功 夫。通过早期试水，ClickHouse整体方案的可行性在实际业务应用中得到了验 证，它能够满足交互式响应的用户体验需求，数据产品迭代较快且稳定性基 本满足耍求。同时，方案整体架构的水平扩展能力，也经历了从几卜台机器 扩大到几百台机器规模的考验。虽然彼时ClickHou

8、se还只是一个能够解决单一应用性能问题、满足特定业务 场景需求的引擎，但团队看到了这套方案的可能性，并为其设定了新的目 标：打造成一个公司级别通用的OLAP系统。ClickHouse很快进入在字节内 部大规模应用的新阶段，新的问题和挑战也随之而来。02规模扩大：从单一业务到全公司随着ClickHouse支持的业务场景从用户增长分析这个单一应用，扩展到B1 分析、AB测试、模型预估等多个场景，需求方不断增多，不同业务需求对技 术的要求也发生了比拟大的变化。通用的技术已经很难解决所有需求，这就 要求团队针对不同的应用场景抽象出对应解决方案，其中涉及不少自底向上 的白研功能。与此同时，ClickHo

9、use集群规模扩张了至少一个数量级，暴露 出了 ClickHouse在应对大数据量和高可用等方面的缺乏。首先，ClickHouse本身是存储计算紧耦合架构，本地存储容量比拟有限，一 般单节点存储大约只有几十TB。伴随用户数增长而来的海量数据很容易让原 来就有限的本地存储更加捉襟见肘。虽然增加外部存储空间可以解决局部问 题，但无限制扩容也不现实。其次，数据最大了之后，数据写入对查询服务 的影响巳经无法完全忽略。针对本地存储局限问题，团队采用了冷热数据分级存储的解决思路，也就是 把长期不查的数据放到底层的冷库存里，远程的计算资源可以出让给其他业 务，而本地存储只管理日常需要查询的近几个月数据。对于

10、数据写入影响查询服务性能的问题，那么考虑把数据写入服务放到查询服 务外部。当导入数据量比拟小的时候，直接用引擎自身的资源格式化之后放 到本地存储；当数据量很大的时候，那么由数据导入服务负责把外部数据源格 式化ClickHouse能够识别的形式，完成数据排序、compressed等构建工作， 然后把结果写回共享存储里面，此时ClickHouse只需要把格式化好的源数据 拉取过去注册一卜.就可以查询九 当数据到达一定的生命周期、查询频率降 低后，再把数据重新down到HDFS上。这套方案解决了数据量变大时导入服务和查询之间的资源竞争问题，同时也 让按需补充计算资源和存储资源变得可行，不再需要因为流

11、量:峰值或波动就 动不动扩展集群规模。虽然现在看来，这套方案还存在一些缺乏，也没有做到完全的弹性架构，但 已经朝着完全弹性的方向迈出了重要的一步。除了海量数据带来的挑战，当集群扩展到一定规模之后，可用性问题也越来 越棘手。产品扩张导致数据分区变多、节点数变多、故障变多，最常见的硬 盘故障几乎每天都会发生。从可用性的视角来看，ClickHouse社区版本的复 制方案R叩licaledMergeTree (ZK)已经面临瓶颈；而增多的数据分区会导致 故障恢复时间变长，乂进一步增加了运维的复杂度与难度。ClickHouse社区版原生的Replication方案有太多的信息存在ZooKeeper上，

12、为了保证服务，一般会有一个或者几个副本，在字节内部主要是两个副本的 方案。早期内部曾有一个400个节点的集群，只存了半年的数据。突然有一天团队 发现服务特别不稳定，ZK的响应经常超时，table可能变成只读模式，发现znode太多。而且ZK并不是可水平扩展的框架，按照当时的数据预估，整个 服务很快就会不可用了。团队分析后得出结论，实际上ClickHouse把ZK当成了三种服务的结合，而 不仅把它当作一个Coordinate service,可能这也是大家使用ZK的常用用 法。ClickHouse还会把它当作Log Service,很多行为H志等数字的信息也会 存在ZK上;还会作为表的catal

13、og service,像表的一些schema信息也会在 ZK上做校验，这就会导致ZK上接入的数量与数据总量会成线性关系。按照 这样的数据增长预估，ClickHouse可能就根本无法支撑头条、抖音的全量需 求。为了解决问题，团队基于MergeTree存储引擎开发了一套自己的高可用方 案，思路就是把更多ZK上的信息卸载下来,ZK只作为coordinate Service。 只让它做三件简单的事情：行为日志的Sequence Number分配、Block ID的 分配和数据的元信息，这样就能保证数据和行为在全局内是唯一的。关于节点，它维护自身的数据信息和行为H志信息，Log和数据的信息在一 个sha

14、rd内部的副本之间，通过Gossip协议进行交互。保存原生的multi- master写入特性，这样多个副本都是可以写的，好处是能够简化数据导入。 下列图是一个简单的框架图。ZK (LSN/ID alloc,metadata)InsertHaMergeTrce简单框架改造完成后，服务的高可用基本上得到了保障，ZooKccpcr压力也不会随着 数据增加而增加。这让ClickHouse更大规模使用变得可能，即使是一个集群 上千台机器或者一个节点有几千张表，改造后的服务都可以Hold住。针对故障恢复时间长的问题，团队也做了一些优化和改进。比方ClickHouse 社区版为了极致的性能优化，将元数据存

15、储在内存中，但因此会在实际使用 中带来服务重启等各种异常。对应地，团队做了元数据持久化的改进，将故 障重启时间从小时级降到分钟级，减少对实际业务的影响，从而有效提升 SLA到99.95%的级别。与此同时，团队逐步为ClickHouse社区版补齐了运维支持能力。从安装部署 层面的自动化配置，到日常运维层面的故障节点替换、健康度检测、故障预 警等功能，将原生的引擎升级为企业版产品，从而极大降低产品使用和运维 过程中对人的依赖，也降低了业务接入成木。通过界面化的建表等DDL操 作，抽象ClickHouse社区版复杂的底表逻辑，进一步降低业务用户的上手和 理解本钱。此外，提供了多种实时与离线的数据源接

16、入方式，规范化数据写 入，减少人为错误或不当使用。整体而言，团队将大局部基于ClickHouse的使用经验和最正确实践都产品化， 沉淀为服务和工具，提升了业务用户的易用性；同时，通过提供可视化的运 维与监控界而，降低了黑屏操作和重复排障的频率，系统管理员的可管理性 也得到加强。这些都让曾经使用和运维难度都极高的ClickHouse变得更加 “易用”。借助产品化的运维能力，如今即使面对上万台的集群规模，字节内部也仅需 要几位SRE就能完成集群的日常运维工作。当然，这是后话了。从初步试水到大规模应用，团队围绕字节跳动真实业务场景，一边解决技术 挑战一边打磨产品，基于ClickHouse做了大量二次开发和深度优化。这套基 ClickHouse长出来的实时数据分析系统，跟ClickHouse社区版相比，已 经进化出了很多不一样的地方。