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

更多技术交流、求职机会，欢迎关注字节跳动数据平台微信公众号，回复【1】进入官方交流群

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

ByteHouse 在字节跳动的发展历程

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

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

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

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

截止 2022 年 3 月，ByteHouse 在字节内部总节点数达到 18000 个，而单一集群的最大规模是 2400 个节点。

可以想象，2400 台服务器同时堆在一起是怎样一副壮观的景象。ByteHouse 支撑的最大数据量可达 700 个 PB，自上线以来，支持了 80%大家非常耳熟能详的字节跳动业务。

选择 ClickHouse 作为实时分析的基建

选择原因

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

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

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

首先，要解决数据量大的问题，同时这个数据量还会不断地增长，2019 年，字节内部每天新增的数据量就达到了 100 个 TB。

其次，在数据量大的基础上，仍要保有包含以下三个方向非常强的灵活性：

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

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

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

最后，在满足前述两点基础上，还要做到成本可控。最开始，团队内部其实也列出了很多开源解决方案，例如 Redis、Apache 等等，这些方案其实都可以实现上述要求的一点到两点。但如果要去维护不同的开源数据库，成本就会变得非常高，团队希望尽量选择一款可以避免成本无限扩展的计算引擎。与此同时，团队也希望数据整体成本可控的，服务器成本的增加是线性的，而不是指数的。

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

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

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

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

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

• “多”——指集群规模多。在字节内部最大的集群规模是 2400 台，ClickHouse 可以完全支持。

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

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

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

开源 ClickHouse 的瓶颈

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

1. OLAP 能力不够好用。在一些特定的场景下，如 upset 场景，实时数据更新场景……原生 ClickHouse 能力难以支持。

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

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

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

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

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

ByteHouse：实时场景全面进化

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

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

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

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

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

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

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

相比 ClickHouse，ByteHouse 在这四个引擎加持下，整体使用场景做到了大幅的增强。

比如在有一些场景下面，实时消费的性能是不够的，需要做到 At—least once 或者 Exactly once 语义，社区版的 ClickHouse 是做不到的，而 ByteHouse 可以；又比如用户希望导入之后能做到实时地去重，而不希望等到 Merge 之后才能去重，ClickHouse 同样做不到，而 ByteHouse 可以做到。

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

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

优化器

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

• 多表性能差。

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

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

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

全局字典、索引支持

参考大量不同的 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 在实时场景上最典型的应用就是实时监控业务。

比如在抖音的线上活动当中，经常会有数据实时监控需求，从生产到数据展现在大屏上，往往达到分钟级甚至秒级的数据延迟。而 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 有更多维度的查询能力和非常快的响应能力，所以用户的每一条查询链路，从输入到输出，都能在一秒钟之内得到响应。所以用户的思维是可以不断地去激发，不断地去创造，不断地去迭代的，这条数据链路精准营销的价值得到不断地提升，最终能够带来生产上的真实产品价值和真实业务价值。

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

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

点击跳转 ByteHouse云原生数据仓库 了解更多