作者|张雷日前，字节跳动技术社区ByteTech举办的第四届字节跳动技术沙龙圆满落幕。本次沙龙的主题是《字节云数据库架构设计与实战》。沙龙中，字节跳动基础数据库高级工程师张磊为大家分享了《字节跳动数据库的过去、现状与未来》，本文就是根据分享整理而成。数据库技术一直是信息技术中极为重要的组成部分。进入云原生时代后，云基础设施与数据库进一步融合，弥补传统数据库的痛点，带来高扩展性、全面自动化、快速部署、节约成本、便捷管理等优势。从2018年到2021年，随着业务和数据的快速增长，字节跳动的分布式数据库系统取得了令人振奋的发展。如下图所示，在过去的四年里，公司应用端容器的数量从5万个增长到750万个，目前已经超过1000万个。这1000万个容器构建了字节跳动坚实的云原生基础设施，支撑着整个业务体系的发展。从线上数据来看，1000万个容器构成了10万多个微服务，在线运行时会产生大量的数据。2020年字节跳动在线数据量将达到EB级；到2021年5月，字节跳动数据库团队已经支持超过10EB的存储规模。面对如此庞大的应用规模和数据规模，如何在数据库领域对数据进行管理和管理成为摆在数据库团队面前的一个巨大难题。在字节跳动内部，数据库建设主要面临三大挑战：业务种类繁多。以抖音为例，为了管理用户之间复杂的社交关系，并根据用户的喜好、关注等行为进行智能推荐，我们需要使用图来进行管理。又如抖音电商商城设计的订单、库存等数据，适合用关系型结构化结构表达。此外，抖音还有大量结构化和非结构化数据，如用户上传的图片、视频等，适合云存储、对象存储等系统管理。业务发展迅速，需求不断变化。如上图所示，过去三年，字节跳动的数据量迎来了近百倍的增长，业务对数据的需求也发生了一些变化。一开始，客户只需要几TB或几十GB的数据。一两年后，他们需要基础架构来处理数十TB甚至数百TB的数据。如何快速满足应用端的数据容量需求和吞吐量需求变化，是我们遇到的第二个挑战。数据存储太多，成本居高不下。随着业务的快速发展，如何管理庞大的结构化和非结构化数据，有效应对高昂的成本，对我们来说也是非常具有挑战性的。字节跳动数据库的演变字节跳动数据库经历了以下三个阶段：2015-2017：刀耕火种的石器时代。现阶段字节跳动的业务量比较小，主要app是今日头条，所以数据库实例大概1~2k。产品主要是开源的MySQL和MyRocks，运维系统主要靠人和脚本。2018-2021：标准化、系统化。随着?的快速发展，字节跳动的业务规模也迎来了飞速增长，达到了数千个库和数万个数据库实例。原有的产品体系已经难以满足用户的需求，所以我们推出了MongoDB等开源计划。另外，我们也在2019年开始研发云原生分布式数据库产品veDB，我们也更新了运维系统，从原来的半自动化、半人工状态逐步走向平台化，大大提高了运营效率。2021年底至今：融合智能。目前，字节跳动已经着手开发数据库第三代产品技术体系。未来几年，我们预计公司的业务规模将上升到数万个数据库和数十万个数据库实例。因此，我们在原有产品体系的基础上，引入了HTAP、ServerlessDB、MemDB等产品和技术。此外，还引入了AI技术，让运维更加智能。字节跳动数据库“过去”的第一代数据库系统架构主要分为三层，如图示意图所示：应用层：上面提到的1000万个容器，以及它们构成的10万个微服务，都部署在应用层；代理层：代理层主要负责数据库的一些访问工作，比如鉴权、流量着色、流量分发等；数据库层：该层部署了数据库的一些实例，通过数据库的Binlog实现数据同步和高可用。一般来说，第一代数据库系统架构是基于开源的MySQL，通过分库分表中间件为用户提供更好的服务，并以手动操作和脚本作为辅助操作。它主要存在以下三个问题：系统灵活性差。首先，容量难以灵活扩展。抖音这种类型的应用程序通常由数以万计的微服务组成。拆除原有数据库需要时间；二是吞吐量弹性不理想。互联网行业经常有春晚、电商促销等活动。我们需要提前扩容以应对流量高峰。移动大量数据的时间；研发效率问题。在用户方面，从应用程序到数据库启动将进行漫长的讨论和谈判。因此，如何提高数据库研发的效率也是我们关注的问题。此外，运维效率有待提升——大量的拆解和合并工作会给研发带来很大的负担；总体成本比较高。第一代数据库系统架构旨在预留CPU和存储资源，以应对流量高峰和业务增长。早期的CPU使用率非常低。比如MySQL数据库的CPU占用率通常只有10%，有的节点甚至长期低于5%；存储空间也很浪费，整个空间的利用率只有20%-30%。字节跳动数据库的“现在”为了解决这三个问题，数据库团队开发了二代数据库，并围绕标准化、系统化构建了庞大的产品矩阵和运维平台。如上图所示，目前的字节跳动数据库系统呈现出产品多元化和产品智能化两大特点。其中，位于矩阵底部的Inf-Brain是数据库管理大脑，主要负责流量预测、断路器预测、智能调参等。上层的模块是细分的产品，比如智能运维、分布式中间件、分布式缓存、KV、Graph等，还有一些云数据库方向的veDB、HTAP相关的技术。veDB主要结构veDB本身就是一个庞大的产品矩阵。除了提供MySQL、PG、MongoDB外，还开发和扩展了字节跳动内部的ElasticSearch服务，包括自主研发的处理TP/AP相关交易的产品HTAP。数据库团队在设计上采用分层架构，高性能网络连接上层数据库和底层分布式存储引擎平台。整个veDB架构遵循的基本理念就是分离。首先是计算和存储的分离。如下图所示，veDB分为计算层和存储层，计算层拆分为负责数据库流量调度、访问和认证的代理层和数据库计算层。在计算层是数据库的一些运行实例。兼容MySQL、PG、MongoDB等数据库引擎。它是无状态的，可以在数据中心动态分布和调度。底部是存储层。我们将数据库日志、数据库页面和相应的处理逻辑卸载到其中。它支持HDD、SSD和PM。二是日志和数据分离。我们将数据库的Wal和Page放到不同的介质中，以达到成本和性能的平衡。三是读写分离。我们最多可以支持15个从站。当读流量比较大时，用户可以通过弹性扩容来应对读负载。这在字节跳动内部已经大规模应用。基于以上设计，veDB呈现出六大特点：强大的灵活性：veDB基于共享存储架构，实现了计算和存储的分离，业务方可以按需灵活使用存储容量，解决了上述问题相对较高的存储成本；兼容性好：目前veDB基本100%兼容MySQL8.0和PostgreSQL12，现已兼容MongoDB4.0；高可用：存储层多副本，支持单AZ/跨3AZ强一致部署，既保持了灵活性，又解决了传统异步复制跨多个导致的RPO不能等于0的问题数据中心通过Binlog；高性能：数据库团队做了大量的优化工作，使得veDB在高并发集群模式下的吞吐量QPS远超传统单机数据库；低成本：计算/存储可按需独立伸缩，存储层压缩比高，存储空间利用率从第一代系统的20%-30%提高到现在的70%；大容量：单表64TB，支持PB级方案。业务实践在业务实践层面，数据库团队主要面临以下三种类型。第一类是基于容量的实例。比如一些电商订单虽然吞吐量不大，但是数据量却极其庞大，远远超过了之前2T-3T的单机容量。基于第二代数据库系统，在计算和存储层面之后，存储层可以无限扩展，让用户无需为数据库操心，只需要专注于业务发展。第二种是QPS实例。2021年春晚，数据库团队支持某中台推送业务，目标用户量（设备）高达10亿。最终我们的峰值吞吐量超过600万QPS，整体数据量超过20TB。事后，由于计算节点是无状态的，数据放在共享存储层，我们轻松完成了节点下线，为公司节省了大量的计算资源。第三类是小实例。字节跳动的在线实例大多是小实例，QPS相对较低，数据量在GB级别。这些类型的实例可以通过虚拟化、混合化和容器等技术降低计算成本。在数据量方面，他们还可以通过共享存储空间来降低整体存储成本。字节跳动数据库的“未来”未来数据库的场景预测随着业务的发展，我们预计2022年之后，字节跳动数据库的规模将达到数万套库和数十万实例。如何更好地支持业务发展，如何建立和管理这几万个库的力量，成为我们下一代技术关注的话题——前面提到，在产品方面，数据库团队会不断推出更多的产品和新技术的引入使得产品类型和协议有一定程度的集成；在运维方面，团队也会引入AI技术来解决当前的痛点。在谈未来之前，我们可以先回顾两个问题：数据库服务产品解决什么问题？数据库服务产品面临的新环境是什么？对于问题一，2018年，数据库团队面临的问题是，有多少业务需要不同类型的数据，但当时的产品无法提供相应的支持；发展至今，现在字节跳动的数据库产品矩阵越来越丰富，我们新的挑战变成了如何帮助用户选择合适的数据库。关于问题2，早期因为数据规模不大，数据库团队关注的是如何预留一些存储和计算资源，用于运行环境的运维体系建设；现在我们拥有数以百万计的服务器，如何利用这些资源和环境下构建数据库产品的服务成为了我们新的探索方向。数据库管理领域的发展概况如果我们回顾数据库技术领域的整体发展，不难发现这样的发展规律。自20世纪80年代DBMS出现以来，IBM等商业公司都在早期推出了OLTP类型的数据库。这一时期数据库的典型特征是解决应用开发过程中管理数据的复杂性。随着时间的推移，在1990年代，企业开始有大量的数据分析需求，比如银行对账单，这催生了新的支线OLAP。到21世纪初，互联网行业迎来了大规模爆发。OLTP开始不能满足企业对在线数据的一些管理需求，OLAP也难以管理离线分析和作业处理系统上的数据。成本是企业难以承受的，以NoSQL、BigData为代表的数据库革命正式爆发。无论是Google开源的HDFS、Bigtable，还是HBase、MongoDB，都是为了解决OLTP类数据库吞吐量和扩展性不足的问题。到2010年，谷歌开始大量使用NoSQL和BigData数据库系统，但很快发现了很多问题，比如NoSQL不支持事务，各个产品的NoSQL接口不一样，给应用迁移和学习带来很大的挑战。因此，它发展了一个新的分支NewSQL。总体来看，数据库在短短20到30年的演进过程中出现了大量分支，技术和产品也越来越复杂。今天大家觉得这些东西太复杂了，开始简单化。比如2015年左右，AWS发布了结合OLTP和云原生的分布式数据库Aurora，发布了结合OLAP和云原生的Redshift，包括BigData。概念的组合产生了一些新的形式。此外，近几年HTAP再次在业界流行起来，将云、OLAP、BigData有机结合，让数据库不仅可以处理复杂的查询，还可以支持在线业务需求。那么这种三合一是不是未来的发展趋势呢？我们不知道。数据库团队的两次观察和思考。数据库领域的技术和产品经历了从简单到复杂再到简单的过程。复杂的分支只是增加了用户选择技术的难度。是否可以不选择性地解决一些问题，而是构建一个大而全的系统来解决问题？能否为用户提供统一的数据管理服务？即使我们现在做不到，我们能不能提供尽可能少的数据管理服务来简化研发人员的研发成本，包括用户使用成本和学习成本？基于以上考虑，字节跳动数据库团队产生了两个重要的观察结果：应用场景融合：提升用户效率，降低用户访问和使用成本；基础设施层面的分离与整合：提高系统级效率，降低系统级成本，对用户有利。一是探索横向整合，简化业务应用数据管理体系。比如过去构建微服务时，数据层必须同时考虑在线数据和离线数据，这就不可避免地涉及到多个数据库的管理，每个数据库下都有不同的表，导致在线应用的复杂度很高。同时，从线上的数据生成到线下的分析，数据的可见度通常是按天、小时、分钟来统计的。在数据ETL过程中，如何保证数据的完整性也是一个非常大的挑战。字节跳动数据库团队一直在尝试通过技术整合来简化线上应用的数据管理。例如，veDB正在探索将MySQL和ESProtocols协议集成到数据库中，以支持事务处理、分析查询、搜索等融合任务，让应用端只需要关注数据本身，而无需关注数据本身。需要关注数据，维护各种数据库。在事务处理层面，veDB已经能够做到秒级的数据可见性和强一致性，支持快照隔离级别。通过存储层的技术整合，veDB还大大优化了数据的存储成本，显着降低了数据冗余系数。二是探索垂直整合，重塑应用缓存和数据库的边界。在单体和微服务时代，用户在使用数据库的时候，需要在前面挂一个Redis，因为数据库的吞吐量通常不能做的很大，很容易被QPS过高挂掉.当企业架构从单体时代发展到在线微服务时代，这种方式会带来很多缓存系统和数据库类型的复杂管理问题。因此，我们希望通过一个系统重塑应用缓存和数据库，给用户带来便利。比如我们在veDB做一些软件和技术硬件方面的探索，尽可能的降低用户的数据管理成本和学习成本，同时免去用户的多级数据流管理，让用户专注于业务逻辑，并帮助他们消除原始数据缓存不一致等行业问题。三是分离与融合：新变种、新硬件、新系统。除了用户层面的一些应用场景的融合，我们也看到了公司基础设施体系内部的一些分离和融合，比如软件、硬件、操作系统。下图左侧是数据库模块，从上到下分别是SQL层、事务层、缓存层和存储层；右边是应用在云数据中心的运行环境，比如公司大部分的微服务都运行在K8s上，在硬件层面，新的算力、新的互联、新的存储都在与时俱进。以算力为例，从只有CPU到CPU+GPU+DPU+FPGA，数据库团队一直在尝试把压缩、加密、解密等需要算力的复杂操作放到FPGA中。当公司的CPU算力从96c增长到192c甚至超过300c时，如何重塑数据库中的索引和事务处理也是我们需要提前思考的问题。第四个是分离和集成：当前云数据中心的构建块。一般来说，数据库也是一种软件。能否利用云中心的硬件和运行环境，让数据库更加强大和灵活，也是一个重要的方向。数据库团队在软件和系统层面做了很多工作，比如将数据库做成Serverless，将数据库中的状态放入分布式PersistentMemory构建的高性能存储引擎，在存储层实现自动分层.通过这个，我们可以让计算层更加灵活。以下图为例，共有三个租户，租户A需要一些MySQL和PG。我们可以将这些租户的数据库实例运行在容器中，动态分配计算资源，根据业务高峰和低谷提供不同规模的数据库实例，实现弹性。在这种统一的运行模式下，我们可以摆脱以往独立物理机的不足，利用公司的百万级服务器实现算力复用。未来，数据库团队将围绕应用场景融合、技术垂直融合、硬件与系统融合重构云数据库，使其回归用户价值，帮助用户提升开发效率、运营效率、运营效率，并降低学习和使用等成本。
