更多技术沟通、求职时机，欢迎关注字节跳动数据渠道微信公众号，回复【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云原生数据仓库 了解更多