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

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

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

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

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

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

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

在字节内部第一个“吃螃蟹”、试水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能够识别的形式，完成数据排序、

转载请注明:http://www.aideyishus.com/lkjg/136.html