字节跳动数据库的过去、现状与未来

2022 年 6 月 01 日
本文字数：6121 字
阅读完需：约 20 分钟

数据库技术一直是信息技术中极其重要的一环，在步入云原生时代后，云基础设施和数据库进一步整合，弥补了传统数据库的痛点，带来了高可扩展性、全面自动化、快速部署、节约成本、管理便捷等优势。

从 2018 到 2021 年，伴随业务和数据的迅猛增长，字节跳动的分布式数据库系统取得了令人振奋的发展。如下图所示，在这 4 年间，公司应用侧容器数量从 5 万个增长到了 750 万个，截至目前已经突破 1000 万。这 1000 万个容器筑成了字节跳动坚实的云原生基础设施，支撑着整个业务体系的发展。

从在线数据角度看，1000 万个容器构成了超过 10 万个微服务，这些微服务在线上运行期间会产生大量数据。在 2020 年，字节跳动的在线数据量级达到 EB 级；到 2021 年 5 月份，字节跳动数据库团队已支撑超过 10 EB 的存储规模。

面对如此庞大的应用规模和数据规模，如何在数据库领域进行数据管理和数据治理，成了摆在数据库团队面前的巨大难题。而在字节跳动内部，数据库建设主要面临三大挑战：

业务种类繁多。 以抖音为例，为了管理用户之间复杂的社交关系，同时根据用户点赞、关注等行为进行智能推荐，我们需要用图进行管理。再如抖音电商商城设计订单、库存等数据，这些信息适合用关系型结构化的结构表达。除此之外抖音还存在大量结构化和非结构化数据，如用户上传的图片、视频，这些信息适合用云存储、对象存储这样的系统来管理。

业务增速快，诉求不断变化。 如上图所示，近 3 年内，字节跳动的数据量迎来了近 100 倍的增长，业务对数据的诉求也产生了一些变化。一开始客户只需要几 TB 或几十 GB 的数据，到一年两年后，他们就要求基础架构能应对数十 TB 甚至数百 TB 的数据量级。如何快速满足应用侧的数据容量需求、吞吐需求变化，是我们遇到的第二个挑战。

数据存量太多，成本居高不下。 随着业务的快速发展，如何管理庞大的结构化和非结构化数据，并有效应对高昂的成本，对我们而言也十分具有挑战性。

字节跳动数据库的演进

字节跳动数据库经历了以下三个阶段：

2015 - 2017 年：刀耕火种的石器时代。 在这一阶段，字节跳动的业务量级比较小，主要的 App 是今日头条，因此数据库的实例大概在 1~2k 量级，产品主要以开源的 MySQL 和 MyRocks 为主，运维体系主要是依靠人工和脚本。

2018 - 2021 年：标准化、系统化。 随着抖音的快速发展，字节的业务规模也迎来快速增长，达到数千套库和数万个数据库实例，原有产品体系已难以解决用户需求，因此我们引入了类似 MongoDB 等开源方案。此外，我们也从 2019 年开始研发云原生分布式数据库产品 veDB 。 我们还更新了运维体系，由原来半自动化半人工的状态逐渐走向平台化，大大提升运营效率。

2021 年底至今：融合智能化。 当前，字节跳动内部已经开始研发数据库的第三代产品技术体系。在未来几年内，我们预计公司业务规模会上升到数万套库、数十万数据库实例，因此在原有产品体系基础上，我们引入了 HTAP、Serverless DB、MemDB 等产品和技术，在运维体系上，也引入 AI 技术，使得运维更加智能化。

字节跳动数据库的“过去”

第一代数据库系统架构主要分三层，示意图如下：

Application 层： 前文提到的 1000 万个容器及其构成的 10 万个微服务都部署在应用层；
Proxy 层： 代理层主要负责数据库的一些接入工作，比如鉴权、流量染色、流量分发等；
Database 层： 这一层部署着数据库的一些实例，通过数据库的 Binlog 实现数据的同步、高可用。

整体来讲，第一代数据库系统架构以开源 MySQL 为主，通过分库分表中间件为用户提供较好的服务，以人工为主、脚本为辅进行运维。它主要存在以下三个问题：

系统弹性较差。 首先是容量难以得到灵活扩展，抖音这类 App 通常都由数万个微服务构成，当微服务的数据量从早期的数十 GB 发展到之后的数十 TB，我们不得不需要花费大量时间拆解原先的库；其次，吞吐量弹性不如人意，互联网行业经常会有春晚、电商促销等活动，我们需要提前进行扩容以应对流量洪峰，活动过后，数据库难以立即收缩，也需要团队花费时间搬迁大量数据；
研发效率问题。 在用户侧，从申请数据库到数据库上线，期间会经过漫长的讨论谈判，因此如何提高数据库的研发效率也是我们着重考虑的问题。此外，运维效率也有待提升——大量的拆库和合并工作会为研发带来不小的负担；
综合成本偏高。 第一代数据库系统架构为了 reserve CPU 和存储资源以应对流量洪峰和业务增长，早期 CPU 使用率十分低下，比如 MySQL 数据库的 CPU 使用率通常只有 10%，有些节点甚至长期在 5% 以下；存储空间也非常浪费，整个空间的利用率只有 20%-30%。

字节跳动数据库的“现在”

为了解决这三个问题，数据库团队开发了第二代数据库，围绕标准化和系统化构建了庞大的产品矩阵和运维平台。

如上图所示，当前字节跳动数据库体系呈现产品多样化、产品智能化两个特征，其中矩阵底层的 Inf-Brain 是数据库管理大脑，主要承担流量预测、熔断预测、智能参数调优等能力。上层各模块则是各细分产品，比如智能运维、分布式中间件、分布式缓存、KV、图等，也有云数据库方向的 veDB、HTAP 相关的一些技术。

veDB 主体架构

veDB 自身即一个较大的产品矩阵。它除了提供 MySQL、PG、MongoDB，也在字节跳动内部研发扩展了 Elastic Search 服务，包括自研的、用于处理 TP/AP 相关事务的产品 HTAP。数据库团队在设计上采用了分层式架构，由高性能网络连接上层的数据库和底层的分布式存储引擎平台。

整个 veDB 的架构遵循的基本哲学是分离。

首先是计算和存储的分离。如下图所示，veDB 分为计算层和存储层，其中计算层又被拆分出负责数据库流量调度、接入、鉴权的代理层以及数据库计算层。计算层中是数据库的一些运行实例，它兼容 MySQL、PG 和 MongoDB 等数据库引擎，是无状态的，可以动态地在数据中心里做分布和调度。最下方是存储层，我们把数据库日志、数据库 Page 和对应的处理逻辑都卸载到里面，它支持 HDD、SSD、PM。

其次是日志和数据的分离。我们把数据库的 Wal 和 Page 放到不同介质里，来实现成本和性能之间的平衡。

第三是读写分离。我们最大可以支持一组 15 从的配比，当读流量比较大时，用户可以通过弹性扩充应对读的负载，这在字节跳动内部已经被大规模应用了。

基于以上设计，veDB 呈现 6 大特点：

灵活性强： veDB 基于 shared-storage 架构，实现了计算存储分离，业务方可以按需弹性使用存储容量，解决了存储成本比较高的问题；
兼容性好： 目前 veDB 基本上已做到 100% 兼容 MySQL 8.0 和 PostgreSQL 12，现已兼容 MongoDB 4.0；
高可用性： 存储层多副本，支持单 AZ/跨 3 AZ 强一致部署，既保持了灵活性，又解决了传统通过 Binlog 跨多数据中心异步复制带来的 RPO 无法等于 0 的问题；
高性能： 数据库团队做了大量优化工作，使 veDB 在高并发集群模式下的吞吐量 QPS 远超传统单机数据库；
成本低： 按需独立扩缩计算/存储，存储层高压缩比，把存储空间利用率从第一代系统的 20%-30% 提升到了现在的 70%；
超大容量： 单表 64 TB，并支持 PB-level 解决方案。

业务实践

在业务实践层面，数据库团队主要面对以下三种类型。

第一类是容量型实例，比如电商某些订单虽然吞吐量不大，但数据量特别大，远超以往 2T-3T 的单机容量。基于第二代数据库系统，在计算存储分级之后，存储层可以无限扩容，使得用户无需担心数据库，只需聚焦业务开发。

第二类是 QPS 型实例。2021 年春晚，数据库团队支持了某中台的推送业务，目标用户量（设备）高达 10 亿级。最终我们的峰值吞吐量超过了 600 万 QPS，整体数据量也超过了 20TB。活动结束后，因为计算节点都是无状态的，且数据都放在共享存储层，我们轻松完成了节点下线，帮助公司节省了大量计算资源。

第三类是小型实例。字节跳动大部分线上实例都是小型实例，QPS 比较低，数据量也在 GB 级别，这类型的实例可以通过虚拟化、混部、容器等技术降低计算成本。在数据量层面，它们也可以通过共享存储空间降低整体存储成本。

字节跳动数据库的“未来”

未来数据库的情景预测

伴随业务的发展，我们预计在 2022 年以后，字节跳动的数据库规模会达到数万套库、数十万实例。如何更好地支持业务的发展，如何建立管理这数万套库的实力，成了我们下一代技术重点关注的话题——如前所述，在产品方面，数据库团队会持续推出更多产品和引入新技术，使得产品在种类和协议上能出现一定的融合；在运维方面，团队也会引入 AI 技术解决着力解决当前的痛点。

在谈及未来之前，首先我们可以回顾两个问题：

数据库服务产品解决的问题是什么？
数据库服务产品面临的新环境是什么？

对于问题一，在 2018 年，数据库团队面临的问题是业务需要多种类型的数据，但当时的产品无法提供相应支持；发展至今，现在字节跳动已拥有日渐丰富的数据库产品矩阵，我们的新挑战变成了如何帮助用户选择合适的数据库。

对于问题二，早期因为数据规模不大，数据库团队关注的是怎么保留一些存储、计算资源用于构建运营环境的运维体系；现在我们已经拥有百万级服务器规模，如何利用这些资源、在云环境下构建数据库产品的服务成了我们的新探索方向。

数据库管理领域的发展概览

如果我们回顾数据库技术领域的整体发展情况，不难发现这样的发展规律。

自 1980s DBMS 出现以来，IBM 等商业化公司在早期纷纷推出 OLTP 型数据库，这一时期数据库的典型特征是为了解决应用程序开发过程中管理数据的复杂性问题。随着时间的推移，1990s 企业开始出现大量数据分析型需求，比如银行报表，这催生了一个新的分支 OLAP。

到 21 世纪初，互联网行业迎来大规模爆发，OLTP 开始无法满足企业对于在线数据的一些管理诉求，OLAP 也难以管理离线分析、作业处理系统上的数据，加之商业化数据库和存储带来的巨大成本使企业难以承受，以 NoSQL 和 BigData 为代表的数据库革命正式爆发，无论是 Google 开源的 HDFS、Bigtable，还是 HBase、MongoDB，它们都旨在解决 OLTP 型数据库吞吐量、扩展性不足的问题。

到 2010 年，Google 开始大量使用 NoSQL 和 BigData 数据库系统，但很快它就发现了不少问题，比如 NoSQL 不支持事务且每个产品的 NoSQL 接口都不一样，这给应用程序迁移和学习带来了极大的成本，为此它又开发了 NewSQL 这一新分支。

整体来看，数据库在短短二三十年演进过程出现了大量分支，技术和产品也越来越复杂。到今天，大家又觉得这些东西太复杂，开始着手去做简化，比如 2015 年左右，AWS 结合 OLTP 和云原生发布了分布式数据库 Aurora，结合 OLAP 与云原生发布 Redshift，包括 BigData 也正与数据湖概念结合，衍生出一些新形态。

除此之外，近几年行业又开始流行 HTAP，把云、OLAP、BigData 做有机结合，使数据库既能处理复杂的 query，又能支持在线业务诉求。那么这样的三合一是不是未来的发展趋势呢？我们不知道。

数据库团队的两个观察和思考

数据库领域的技术和产品经历了从简单到复杂再到简单的过程，但如果审视做数据管理的真实初衷，恐怕大家的目标都是为了方便用户——而各种复杂分支恰恰让用户更难做技术选型。

我们能不能不要选择性地去解决一部分问题，而是构建一个大而全的系统去解决问题？我们能否为用户提供统一的数据管理服务？即使现在做不到，那我们能不能提供尽量少的数据管理服务，去简化研发人员的研发成本，包括用户的使用成本和学习成本？

基于以上思考，字节跳动数据库团队产生了两个重要的观察思考：

应用场景方面的融合：提升用户效率，降低用户的接入和使用成本；
基础设施层面的分离和整合：提升系统层面的效率，降低系统层面的成本，可以为用户让利。

首先是横向融合探索，简化业务应用数据管理体系。举个例子，过去构建一个微服务，数据层既要考虑在线数据，也会考虑离线数据，不可避免会涉及多种数据库及每种数据库下不同的表的管理，导致在线应用的复杂度较高。同时从在线数据生成到离线分析，数据的可见性通常会以天、小时、分钟级别计数。在数据 ETL 过程中，数据的 integrity 如何去保证，这也是一个非常大的挑战。

字节跳动数据库团队一直在尝试通过技术上的融合简化在线应用的数据管理，例如 veDB 正在探索把 MySQL、ES Protocols 的协议集成到数据库里，支持事务处理、分析查询、搜索等融合任务，使应用侧只需关注数据本身，无需关注数据和维护多种数据库。在事务处理层面，veDB 已经能做到数据可见性秒级，并且强一致，支持 snapshot 隔离级别。通过存储层的技术整合，veDB 也大幅优化了数据的存储成本，显著降低了数据冗余系数。

其次是纵向融合探索，重塑应用缓存和数据库边界。 单体和微服务时代，用户在使用数据库时，需要在前面挂一个 Redis，因为数据库的吞吐量通常不能够做得很大，容易被过高的 QPS 打挂。当企业架构从单体时代发展到在线微服务时代，这种做法会带来大量缓存系统和数据库类型的复杂管理难题，因此我们希望通过一套系统重塑应用缓存和数据库，为用户带来便捷。比如我们正在 veDB 中做一些软件和技术硬件层面的探索，尽可能减少用户的数据管理成本和学习成本，同时消除用户 multi-tiering 数据流动管理，让用户聚焦业务逻辑，也帮助他们消除了原先数据与缓存不一致性等业界难题。

第三是分离和整合：新的变量、硬件和系统。 除了用户层面一些应用场景的融合，我们也在公司基础架构体系内部看到了一些分离和整合的内容，比如软件、硬件和操作系统。下图左侧是数据库模块，从上到下分别是 SQL 层、事务层、缓存层和存储层；右侧则是云数据中心里应用的运行时环境，比如公司大部分微服务都跑在 K8s 上，硬件层面的新算力、新互联、新存储都在与时俱进地发生变化。

以算力为例，从只有 CPU 到发展到 CPU+GPU+DPU+FPGA，数据库团队一直在尝试把压缩、加密解密等复杂的、需要消耗算力的作业放到 FPGA 里去。当公司 CPU 算力从 96c 发展到 192c 甚至超过 300c，如何重塑数据库里的索引、事务处理也是我们要提前思考的问题。

第四是分离与整合：当前云数据中心的 building blocks。

总的来讲，数据库也是一种软件，当前我们能不能利用云中心里的硬件和运行时环境使数据库变得更强大、更弹性，也是一个重要方向。

数据库团队在软件、系统层面做了非常多的工作，比如把数据库 Severless 化，把数据库里的状态放到分布式的 Persistent Memory 构建的高性能存储引擎里，在存储层实现自动分层分级。通过这样，我们可以把计算层做得更加弹性。

以下图为例，有三个租户，其中租户 A 需要一些 MySQL 和 PG。我们可以把这些租户的数据库实例运行在容器中，动态地做计算资源调配，根据业务的高峰期和低谷期提供不同大小的数据库实例来实现弹性。在这种大一统运营模式之下，我们就可以摆脱以往独立物理机数量不足的窘境，利用公司百万级服务器实现算力复用。