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

　　日前，位元組跳動技術社群 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。我們可以把這些租戶的資料庫例項執行在容器中，動態地做計算資源調配，根據業務的高峰期和低谷期提供不同大小的資料庫例項來實現彈性。在這種大一統運營模式之下，我們就可以擺脫以往獨立物理機數量不足的窘境，利用公司百萬級伺服器實現算力複用。

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