干货 | ByteHouse：基于ClickHouse 的实时计算能力升级

原创 ByeHouse 字节跳动数据平台

ByteHouse是火山引擎数智平台旗下云原生数据分析平台，为用户带来极速分析体验，能够支撑实时数据分析和海量离线数据分析；便捷的弹性扩缩容能力，极致的分析性能和丰富的企业级特性，助力客户数字化转型。

本文为字节跳动数据平台超话数据直播回顾文章，全篇将从字节内部发展链路、选择ClickHouse原因，基于ClickHouse的四个维度优化、多场景实践四个版块，介绍ByteHouse基于ClickHouse的实时计算能力升级。

文 | 沈瞳 来自火山引擎ByteHouse团队

从2017年开始，字节内部的整体数据量不断上涨，为了支撑实时分析的业务，字节内部开始了对各种数据库的选型。经过多次实验，在实时分析版块，字节内部决定开始试水ClickHouse。

2018年到2019年，字节内部的ClickHouse业务从单一业务，逐步发展到了多个不同业务，适用到更多的场景，包括BI 分析、A/B测试、模型预估等。

在上述这些业务场景的不断实践之下，研发团队基于原生ClickHouse做了大量的改造，同时又开发了大量的优化特性。

2020年， ByteHouse正式在字节跳动内部立项，2021年通过火山引擎对外服务。

截止2022年3月，ByteHouse在字节内部总节点数达到18000个，而单一集群的最大规模是2400个节点。可以想象，2400台服务器同时堆在一起是怎样一副壮观的景象。ByteHouse管理的总数据量超700PB，自上线以来，支持了80%大家非常耳熟能详的字节跳动业务。

/ 选择原因 /

那么，字节为什么会选择ClickHouse作为内部分析型数据库的基础呢？

2017 年，基于众多的业务场景以及海量分析数据，字节内部对于实时数仓的要求也越来越高。

事实上，要同时满足图上所示的这些要求有着相当大的难度。

首先，要解决数据量大的问题，同时这个数据量还会不断地增长，2019年，字节内部每天新增的数据量就达到了 100 个TB。其次，在数据量大的基础上，仍要保有包含以下三个方向非常强的灵活性：

● 数据源头的灵活性。也同时去支持批示数据和流式数据的导入，实现批流一体。

● 查询性能的多样性。希望同时能够支持到明细数据和聚合查询，不希望在数据库当中只存聚合的数据。

● 交互式分析需求的灵活性。数千个维度都要能够达到秒级的快速响应。

最后，在满足前述两点基础上，还要做到成本可控。最开始，团队内部其实也列出了很多开源解决方案，例如Redis、Apache Kylin等等，这些方案其实都可以满足上述要求中的一点到两点。

但如果要去维护不同的开源数据库，成本就会变得非常高，团队希望尽量选择一款可以避免成本无限扩展的计算引擎。

与此同时，团队也希望数据整体成本可控的，服务器成本的增加是线性的，而不是指数的。

● 线性：数据存储都通过磁盘来进行

● 指数：指数通过内存来进行（快但贵）

最后，团队发现作为开源产品的ClickHouse，竟然能够同时满足所有的要求——性能强劲，灵活支持，主要依赖磁盘，成本相对可控，真正做到了All In One。

/ 多快好省——ClickHouse基础能力介绍 /

ClickHouse是一个用于联机分析处理（OLAP）的列式数据库管理系统，源自俄罗斯的搜索引擎Yandex。它的最大特点可以概括为”多快好省“。

● “多”——指集群规模多。在字节内部，最大的集群规模达到2400台。

● “快”——在大数据规模下，ClickHouse也能提供秒级的单表查询性能，性能强。

● “好”——指无入侵式架构，可以轻松集成到现有的系统，可复用性好。

● “省”——ClickHouse使用磁盘作为性能的基准，不使用内存，成本随着规模的扩展，可控性强。

/ 开源ClickHouse的瓶颈 /

当字节内部的整体使用规模到了18000台服务器之后，其实也发现ClickHouse一些瓶颈，比如：

1. OLAP能力不够好用。在一些特定的场景下，半结构化数据的分析能力不足……原生ClickHouse能力难以支持。

2. ClickHouse在单表性能上非常的强劲，但多表能力非常局限，且对标准SQL兼容性低。

3. 缺乏成熟运维管理工具，运维复杂程度高，需要投入极大的人力，这是一个很大的缺陷。

4.ClickHouse是MPP架构（存算一体架构），性能和扩展性极强，但缺陷也很明显：

● 横向扩容成本非常高，增加一个节点要进行数据重新分布。

● 隔离性差，单一用户的查询会非常容易打满整个集群，导致ClickHouse并发度不高。

字节内部针对ClickHouse的很多特性进行了全新的研发，推出了ByteHouse产品，在实时场景上全面实现了进化。

/ OLAP能力进化：丰富的自研表引擎 /

ClicHouse本身就可以支持非常丰富的表引擎，但ByteHouse在此基础上逐渐弥补了各种表引擎的不足，衍生出更多全新的表引擎，使ByteHouse能够做很多开源ClickHouse做不到的场景。

● 高可用表引擎：相比社区的ReplicatedMergeTree，高可用表引擎支持的整体表数量更多，支持的集群规模更大，稳定性更高。

● 实时数据引擎：ByteHouse的实时数据引擎相比起社区所支持的数据实时数据引擎，消费能力更强，并且能够支持At—Least once 语义，能够解决社区版Kafka单点写入的性能瓶颈问题。

● Unique 引擎：这是最关键的一点，它解决了社区版Replacing Merge实时更新延迟问题，真正能够做到实时upset。

● Bitmap引擎：它可以在特定的场景（如用户圈选）当中，支持大量的“交并补”，做到10倍到50倍的性能提升。

/ 性能优化：优化器、字典、索引支持 /

ClickHouse最大的特点是单表性能强劲，但多表性能存在极大的缺陷。

1.优化器

主要的问题在于ClickHouse不支持优化器。众所周知，在MySQL、PGSQL、 Oracle 这类传统数据库当中，优化器对于多表的性能优化起到了非常大的作用。此外，优化器还有一个非常关键的作用，就是它能改写SQL。

在不支持优化器的前提下，产生了两个比较大的缺陷：

● 多表性能差。

● 从MySQL或者很多传统数据库迁移到开源ClickHouse之后，要做很多SQL的改写。

而ByteHouse自研了基于CBO和RBO（基于代价和基于规则的优化器），同时支持了很多优化器的多如牛毛的特性，包括多层嵌套的下推、Join子查询的下推、Join-Reorder、Bucket Join、Runtime Filter等。

在做到整体优化器的支持之后，ByteHouse它能够做到TPC-DS的性能，在覆盖率层面，可以达到99条sql100%覆盖，每一条的查询都比社区版ClickHouse要更快。

2.全局字典、索引支持

参考大量不同的OLAP或者OLTP数据库，ByteHouse还做了很多的优化。比如支持了全局字典，支持了更多的索引，如Bitmap index，可以让查询效率更快。开源ClickHouse所具备的“多快好省”，在ByteHouse的优化之下，让快更快，以快至快。

/ 运维进化：集群运维能力 & 稳定性优化 /

第一是集群运维能力优化。之前提到，在更多的服务器场景下面，急需运维工具，使得SRE或者Devops 运维人员的人效更高。

为了解决这些问题，ByteHouse提供了以下工具：

● 标准化运维工具。比如像在白屏上自动下发配置的工具，在白屏上进行版本自助升级的工具，节点重启、替换等等标准化运维工具。

● 集群健康度的检测工具。相当于集群的实时巡检，可以报告当前集群是健康状态还是有问题的状态，这些问题是什么？这些问题怎么解决？更大程度地把问题前置化，避免在紧急的时刻要去处理大量的问题。

● 当问题发生时的诊断工具。比如大查询的诊断，和集群当时负载的诊断。

通过这三个方向的工具，能够让整体的运维效率达到非常高的程度，并且达到可复制化。（在字节跳动内部，总共18000 个节点，只有不到 10 个运维人员的支持。通过ByteHouse这些工具，能够做到自动化、高效化、可复制化)

第二方面是稳定性优化。在长达6年多的ByteHouse集群运营当中，研发团队发现ClickHouse存在大量的稳定性痛点。而ByteHouse优化到了代码根本层面的修复，包括云数据的持久化，包括主备同步查询，包括慢节点模式， Zookeeper的自动的清理和修复等等。

当这些问题不再发生后，运维同学可以节省出大量的人力用于工具的开发，最终能够形成一个完整的产品、非常高的人效以及整体非常好的终端用户查询性能的正向循环。

/ 架构进化：存算分离 /

在MPP 1. 0存算一体的模式下面，有着隔离比较困难以及扩容比较困难的瓶颈。ByteHouse基于这些痛点做了非常大的投入，直接研发出了MPP 2. 0 的架构，也就是存算分离架构。

简单来说，存算分离架构——就是计算层Shared Nothing，存储层Shared Everything。这样做的好处可以分成两个层次。

● 第一层：更好地做到资源隔离。每一个计算任务都会提交到不同的计算资源上面去，不同用户之间不会有影响的。随时能够扩容计算资源和存储资源，也能够缩容计算资源。结合云计算一些按秒计费的策略，最终能做到用户的成本进一步的降低。

● 第二层：真正做到云原生（Cloud native），ByteHouse的存储层既支持HDFS，也支持S3对象或者其他的对象存储，比如火山的TOS。这样可以支持MPP2. 0架构下的ByteHouse，真正能够实现云原生的部署。

/ 场景一：实时监控 /

ByteHouse在实时场景上最典型的应用就是实时监控业务。

比如在抖音的线上活动当中，经常会有数据实时监控需求，从生产到数据展现在大屏上，往往达到分钟级甚至秒级的数据延迟。而ByteHouse加入其中，带来了以下价值。

1. 非常高的吞吐性能。实时的线上数据都能够被ByteHouse的计算引擎所接收到，而最终能够达到250W/写入TPS的性能指标。

2. 非常高的查询性能。ByteHouse可以使数据从输入端到输出端的流程达到秒级。

3. 数据保障。ByteHouse能够最终保障到Exactly Once的语义，保证数据不丢失，也不会重复。最终达到数据是高效存储的，准确的，可以在秒级被查询到的。

/ 场景二：行为分析 /

在行为分析的场景下，可以结合到运维同学非常熟悉的一些产品，类似一些事件分析、留存分析、转化分析、各种漏斗图表等等产品功能的底层，其实都非常适合ByteHouse作为支撑的。

事实上，在2017年，ByteHouse最早支撑的内部场景也是行为分析场景。行为分析场景需要非常大数据量的存储、非常高的数据读取、响应的要求，以及非常大的成本诉求。ByteHouse的优势价值有以下三点。

1. 支撑大集群。ByteHouse通过HaMergeTree引擎的支持，通过集群扩容能力的研发，最终才能够让个场景能够支撑到2400台集群的极大规模。

2. 秒级响应。想做到秒级响应，就需要做到不断地优化支持——通过字典编码来进行减少序列化和反序列化的开销，查询性能才能得到提升。最终达到的效果是 90% 的查询场景能够在 5 秒钟~ 7 秒钟之间得到返回。在这么大一个量级下面，ByteHouse仍然能够达到 10 秒钟之内的响应，是一个非常了不起的成果。

3. 降本增效。数据量级怎样能够做到进一步的降低成本？事实上，用户每天访问一定是有热数据的，也有着一些长期需要被查询的冷数据。在ClickHouse的基础上面， ByteHouse做了二次迭代开发——在 HDFS 上面进行冷热的分存。

热数据存储在本地，在SSD 磁盘上加快响应；冷数据放在 HDFS 上来进行存储成本的降低。不仅可以做到大集群规模响应很快，它的成本仍然能够保持，非常具有性价比。

/ 场景三：精准营销 /

最后是精准营销场景。这个场景其实在生产场景下面非常的普遍，每一个产品都需要精准营销，每个产品都需要画大量的漏斗图。在精准营销的背后，如果使用 ByteHouse来进行数据支撑，会有三个非常重要的优化节点。

1. 秒级响应。ByteHouse的优化器支持对于秒级响应做到了很大的优化。在优化器的加持下面，能够做到P95的整个时长响应能够在一秒之内，甚至能够在半秒钟之内，满足了用户实时看数，实时分析市场行情的需求。

2. 交并补计算。因为人群的圈选，事实上在用户打了大量的标签，这些标签就是 0 和1。这些 0 和 1 在进行交并补的计算之后，最终效果可以达到 10 倍到 50 倍的性能提升。

3. 激发效应。因为ByteHouse有更多维度的查询能力和非常快的响应能力，所以用户的每一条查询链路，从输入到输出，都能在一秒钟之内得到响应。所以用户的思维是可以不断地去激发，不断地去创造，不断地去迭代的，这条数据链路精准营销的价值得到不断地提升，最终能够带来生产上的真实产品价值和真实业务价值。

关注字节跳动数据平台公众号，回复“0404”领取本次分享完整PPT

为了助力企业抓稳数字化发展机遇，加速企业数智能力升级，自2023年2月1日开始，火山引擎ByteHouse特别推出为期一年的企业级特惠活动。

企业通过本次活动购买ByteHouse服务，包年1年可享8.3折，包年2年可享7折，包年3年可享5折。除基础优惠之外，企业包年购买后，还可获得大量额外资源免费赠送，买二送一，买三送二，买五送三（赠送资源与包年使用期限一致），且以上两项优惠可叠加享受！

产品介绍

火山引擎ByteHouse

统一的大数据分析平台。目前提供企业版和云数仓两种版本，企业版是基于开源的企业级分析型数据库，支持用户交互式分析PB级别数据，通过多种自研表引擎，灵活支持各类数据分析和应用；云数仓版作为云原生的数据分析平台，实现统一的离线和实时数据分析，并通过弹性扩展的计算层和分布式存储层，有效降低企业大数据分析。后台回复数字“6”了解产品

继续滑动看下一个