資料庫前沿

❶ 位元組跳動資料庫的過去、現狀與未來

日前，位元組跳動技術社區 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主體架構

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 級別的海量數據；有多種資料庫產品，提供極致時延、超大吞吐的雲原生資料庫服務；有前沿的技術研究，探索新硬體與新軟體架構的融合，打造下一代革命性的雲存儲與資料庫產品。

以上內容整理自第四期位元組跳動技術沙龍《位元組雲資料庫架構設計與實戰》，獲取講師 PPT 和回放視頻，請在公眾號「位元組跳動技術團隊」後台回復關鍵詞「0416」。

原文：https://juejin.cn/post/7101968489170567181