日前，字節跳動技術社區 ByteTech 舉辦的第四期字節跳動技術沙龍圓滿落幕，本期沙龍以《字節雲數據庫架構設計與實戰》為主題。在沙龍中，字節跳動基礎架構數據庫資深工程師張雷，跟大家分享了《字節跳動數據庫的過去、現狀與未來》，本文根據分享整理而成。

數據庫技術一直是信息技術中極其重要的一環，在步入雲原生時代後，雲基礎設施和數據庫進一步整合，彌補了傳統數據庫的痛點，帶來了高可擴展性、全面自動化、快速部署、節約成本、管理便捷等優勢。

從 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 自身即一個較大的産品矩陣。它除了提供 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。我們可以把這些租戶的數據庫實例運行在容器中，動态地做計算資源調配，根據業務的高峰期和低谷期提供不同大小的數據庫實例來實現彈性。在這種大一統運營模式之下，我們就可以擺脫以往獨立物理機數量不足的窘境，利用公司百萬級服務器實現算力複用。

未來，數據庫團隊會圍繞應用場景層面的融合、縱向的技術整合以及硬件和系統的整合，重新構建雲數據庫，使它能夠回歸用戶價值，幫助用戶提升開發效率、運行效率和運營效率，降低學習和使用等各類成本。

Database & Cloud Storage Team，服務于字節跳動全系産品。在這裡，我們有豐富的雲存儲産品，負責治理數十 EB 級别的海量數據；有多種數據庫産品，提供極緻時延、超大吞吐的雲原生數據庫服務；有前沿的技術研究，探索新硬件與新軟件架構的融合，打造下一代革命性的雲存儲與數據庫産品。

更多精彩资讯请关注tft每日頭條，我们将持续为您更新最新资讯!