日前，字節(jié)跳動技術(shù)社區(qū) ByteTech 舉辦的第四期字節(jié)跳動技術(shù)沙龍圓滿落幕，本期沙龍以《字節(jié)云數(shù)據(jù)庫架構(gòu)設(shè)計與實戰(zhàn)》為主題。在沙龍中，字節(jié)跳動基礎(chǔ)架構(gòu)數(shù)據(jù)庫資深工程師張雷，跟大家分享了《字節(jié)跳動數(shù)據(jù)庫的過去、現(xiàn)狀與未來》，本文根據(jù)分享整理而成。

數(shù)據(jù)庫技術(shù)一直是信息技術(shù)中極其重要的一環(huán)，在步入云原生時代后，云基礎(chǔ)設(shè)施和數(shù)據(jù)庫進(jìn)一步整合，彌補(bǔ)了傳統(tǒng)數(shù)據(jù)庫的痛點，帶來了高可擴(kuò)展性、全面自動化、快速部署、節(jié)約成本、管理便捷等優(yōu)勢。

從 2018 到 2021 年，伴隨業(yè)務(wù)和數(shù)據(jù)的迅猛增長，字節(jié)跳動的分布式數(shù)據(jù)庫系統(tǒng)取得了令人振奮的發(fā)展。如下圖所示，在這 4 年間，公司應(yīng)用側(cè)容器數(shù)量從 5 萬個增長到了 750 萬個，截至目前已經(jīng)突破 1000 萬。這 1000 萬個容器筑成了字節(jié)跳動堅實的云原生基礎(chǔ)設(shè)施，支撐著整個業(yè)務(wù)體系的發(fā)展。

從在線數(shù)據(jù)角度看，1000 萬個容器構(gòu)成了超過 10 萬個微服務(wù)，這些微服務(wù)在線上運(yùn)行期間會產(chǎn)生大量數(shù)據(jù)。在 2020 年，字節(jié)跳動的在線數(shù)據(jù)量級達(dá)到 EB 級；到 2021 年 5 月份，字節(jié)跳動數(shù)據(jù)庫團(tuán)隊已支撐超過 10 EB 的存儲規(guī)模。

面對如此龐大的應(yīng)用規(guī)模和數(shù)據(jù)規(guī)模，如何在數(shù)據(jù)庫領(lǐng)域進(jìn)行數(shù)據(jù)管理和數(shù)據(jù)治理，成了擺在數(shù)據(jù)庫團(tuán)隊面前的巨大難題。而在字節(jié)跳動內(nèi)部，數(shù)據(jù)庫建設(shè)主要面臨三大挑戰(zhàn)：

業(yè)務(wù)種類繁多。以抖音為例，為了管理用戶之間復(fù)雜的社交關(guān)系，同時根據(jù)用戶點贊、關(guān)注等行為進(jìn)行智能推薦，我們需要用圖進(jìn)行管理。再如抖音電商商城設(shè)計訂單、庫存等數(shù)據(jù)，這些信息適合用關(guān)系型結(jié)構(gòu)化的結(jié)構(gòu)表達(dá)。除此之外抖音還存在大量結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，如用戶上傳的圖片、視頻，這些信息適合用云存儲、對象存儲這樣的系統(tǒng)來管理。

業(yè)務(wù)增速快，訴求不斷變化。如上圖所示，近 3 年內(nèi)，字節(jié)跳動的數(shù)據(jù)量迎來了近 100 倍的增長，業(yè)務(wù)對數(shù)據(jù)的訴求也產(chǎn)生了一些變化。一開始客戶只需要幾 TB 或幾十 GB 的數(shù)據(jù)，到一年兩年后，他們就要求基礎(chǔ)架構(gòu)能應(yīng)對數(shù)十 TB 甚至數(shù)百 TB 的數(shù)據(jù)量級。如何快速滿足應(yīng)用側(cè)的數(shù)據(jù)容量需求、吞吐需求變化，是我們遇到的第二個挑戰(zhàn)。

數(shù)據(jù)存量太多，成本居高不下。隨著業(yè)務(wù)的快速發(fā)展，如何管理龐大的結(jié)構(gòu)化和非結(jié)構(gòu)化數(shù)據(jù)，并有效應(yīng)對高昂的成本，對我們而言也十分具有挑戰(zhàn)性。

字節(jié)跳動數(shù)據(jù)庫的演進(jìn)

字節(jié)跳動數(shù)據(jù)庫經(jīng)歷了以下三個階段：

2015 - 2017 年：刀耕火種的石器時代。在這一階段，字節(jié)跳動的業(yè)務(wù)量級比較小，主要的 App 是今日頭條，因此數(shù)據(jù)庫的實例大概在 1~2k 量級，產(chǎn)品主要以開源的 MySQL 和 MyRocks 為主，運(yùn)維體系主要是依靠人工和腳本。

2018 - 2021 年：標(biāo)準(zhǔn)化、系統(tǒng)化。隨著抖音的快速發(fā)展，字節(jié)的業(yè)務(wù)規(guī)模也迎來快速增長，達(dá)到數(shù)千套庫和數(shù)萬個數(shù)據(jù)庫實例，原有產(chǎn)品體系已難以解決用戶需求，因此我們引入了類似 MongoDB 等開源方案。此外，我們也從 2019 年開始研發(fā)云原生分布式數(shù)據(jù)庫產(chǎn)品 veDB 。我們還更新了運(yùn)維體系，由原來半自動化半人工的狀態(tài)逐漸走向平臺化，大大提升運(yùn)營效率。

2021 年底至今：融合智能化。當(dāng)前，字節(jié)跳動內(nèi)部已經(jīng)開始研發(fā)數(shù)據(jù)庫的第三代產(chǎn)品技術(shù)體系。在未來幾年內(nèi)，我們預(yù)計公司業(yè)務(wù)規(guī)模會上升到數(shù)萬套庫、數(shù)十萬數(shù)據(jù)庫實例，因此在原有產(chǎn)品體系基礎(chǔ)上，我們引入了 HTAP、Serverless DB、MemDB 等產(chǎn)品和技術(shù)，在運(yùn)維體系上，也引入 AI 技術(shù)，使得運(yùn)維更加智能化。

字節(jié)跳動數(shù)據(jù)庫的“過去”

第一代數(shù)據(jù)庫系統(tǒng)架構(gòu)主要分三層，示意圖如下：

整體來講，第一代數(shù)據(jù)庫系統(tǒng)架構(gòu)以開源 MySQL 為主，通過分庫分表中間件為用戶提供較好的服務(wù)，以人工為主、腳本為輔進(jìn)行運(yùn)維。它主要存在以下三個問題：

字節(jié)跳動數(shù)據(jù)庫的“現(xiàn)在”

為了解決這三個問題，數(shù)據(jù)庫團(tuán)隊開發(fā)了第二代數(shù)據(jù)庫，圍繞標(biāo)準(zhǔn)化和系統(tǒng)化構(gòu)建了龐大的產(chǎn)品矩陣和運(yùn)維平臺。

如上圖所示，當(dāng)前字節(jié)跳動數(shù)據(jù)庫體系呈現(xiàn)產(chǎn)品多樣化、產(chǎn)品智能化兩個特征，其中矩陣底層的 Inf-Brain 是數(shù)據(jù)庫管理大腦，主要承擔(dān)流量預(yù)測、熔斷預(yù)測、智能參數(shù)調(diào)優(yōu)等能力。上層各模塊則是各細(xì)分產(chǎn)品，比如智能運(yùn)維、分布式中間件、分布式緩存、KV、圖等，也有云數(shù)據(jù)庫方向的 veDB、HTAP 相關(guān)的一些技術(shù)。

veDB主體架構(gòu)

veDB 自身即一個較大的產(chǎn)品矩陣。它除了提供 MySQL、PG、MongoDB，也在字節(jié)跳動內(nèi)部研發(fā)擴(kuò)展了 Elastic Search 服務(wù)，包括自研的、用于處理 TP/AP 相關(guān)事務(wù)的產(chǎn)品 HTAP。數(shù)據(jù)庫團(tuán)隊在設(shè)計上采用了分層式架構(gòu)，由高性能網(wǎng)絡(luò)連接上層的數(shù)據(jù)庫和底層的分布式存儲引擎平臺。

整個 veDB 的架構(gòu)遵循的基本哲學(xué)是分離。

首先是計算和存儲的分離。如下圖所示，veDB 分為計算層和存儲層，其中計算層又被拆分出負(fù)責(zé)數(shù)據(jù)庫流量調(diào)度、接入、鑒權(quán)的代理層以及數(shù)據(jù)庫計算層。計算層中是數(shù)據(jù)庫的一些運(yùn)行實例，它兼容 MySQL、PG 和 MongoDB 等數(shù)據(jù)庫引擎，是無狀態(tài)的，可以動態(tài)地在數(shù)據(jù)中心里做分布和調(diào)度。最下方是存儲層，我們把數(shù)據(jù)庫日志、數(shù)據(jù)庫 Page 和對應(yīng)的處理邏輯都卸載到里面，它支持 HDD、SSD、PM。

其次是日志和數(shù)據(jù)的分離。我們把數(shù)據(jù)庫的 Wal 和 Page 放到不同介質(zhì)里，來實現(xiàn)成本和性能之間的平衡。

第三是讀寫分離。我們最大可以支持一組 15 從的配比，當(dāng)讀流量比較大時，用戶可以通過彈性擴(kuò)充應(yīng)對讀的負(fù)載，這在字節(jié)跳動內(nèi)部已經(jīng)被大規(guī)模應(yīng)用了。

基于以上設(shè)計，veDB 呈現(xiàn) 6 大特點：

業(yè)務(wù)實踐

在業(yè)務(wù)實踐層面，數(shù)據(jù)庫團(tuán)隊主要面對以下三種類型。

第一類是容量型實例，比如電商某些訂單雖然吞吐量不大，但數(shù)據(jù)量特別大，遠(yuǎn)超以往 2T-3T 的單機(jī)容量?；诘诙鷶?shù)據(jù)庫系統(tǒng)，在計算存儲分級之后，存儲層可以無限擴(kuò)容，使得用戶無需擔(dān)心數(shù)據(jù)庫，只需聚焦業(yè)務(wù)開發(fā)。

第二類是 QPS 型實例。2021 年春晚，數(shù)據(jù)庫團(tuán)隊支持了某中臺的推送業(yè)務(wù)，目標(biāo)用戶量（設(shè)備）高達(dá) 10 億級。最終我們的峰值吞吐量超過了 600 萬 QPS，整體數(shù)據(jù)量也超過了 20TB。活動結(jié)束后，因為計算節(jié)點都是無狀態(tài)的，且數(shù)據(jù)都放在共享存儲層，我們輕松完成了節(jié)點下線，幫助公司節(jié)省了大量計算資源。

第三類是小型實例。字節(jié)跳動大部分線上實例都是小型實例，QPS 比較低，數(shù)據(jù)量也在 GB 級別，這類型的實例可以通過虛擬化、混部、容器等技術(shù)降低計算成本。在數(shù)據(jù)量層面，它們也可以通過共享存儲空間降低整體存儲成本。

字節(jié)跳動數(shù)據(jù)庫的“未來”

未來數(shù)據(jù)庫的情景預(yù)測

伴隨業(yè)務(wù)的發(fā)展，我們預(yù)計在 2022 年以后，字節(jié)跳動的數(shù)據(jù)庫規(guī)模會達(dá)到數(shù)萬套庫、數(shù)十萬實例。如何更好地支持業(yè)務(wù)的發(fā)展，如何建立管理這數(shù)萬套庫的實力，成了我們下一代技術(shù)重點關(guān)注的話題——如前所述，在產(chǎn)品方面，數(shù)據(jù)庫團(tuán)隊會持續(xù)推出更多產(chǎn)品和引入新技術(shù)，使得產(chǎn)品在種類和協(xié)議上能出現(xiàn)一定的融合；在運(yùn)維方面，團(tuán)隊也會引入 AI 技術(shù)解決著力解決當(dāng)前的痛點。

在談及未來之前，首先我們可以回顧兩個問題：

對于問題一，在 2018 年，數(shù)據(jù)庫團(tuán)隊面臨的問題是業(yè)務(wù)需要多種類型的數(shù)據(jù)，但當(dāng)時的產(chǎn)品無法提供相應(yīng)支持；發(fā)展至今，現(xiàn)在字節(jié)跳動已擁有日漸豐富的數(shù)據(jù)庫產(chǎn)品矩陣，我們的新挑戰(zhàn)變成了如何幫助用戶選擇合適的數(shù)據(jù)庫。

對于問題二，早期因為數(shù)據(jù)規(guī)模不大，數(shù)據(jù)庫團(tuán)隊關(guān)注的是怎么保留一些存儲、計算資源用于構(gòu)建運(yùn)營環(huán)境的運(yùn)維體系；現(xiàn)在我們已經(jīng)擁有百萬級服務(wù)器規(guī)模，如何利用這些資源、在云環(huán)境下構(gòu)建數(shù)據(jù)庫產(chǎn)品的服務(wù)成了我們的新探索方向。

數(shù)據(jù)庫管理領(lǐng)域的發(fā)展概覽

如果我們回顧數(shù)據(jù)庫技術(shù)領(lǐng)域的整體發(fā)展情況，不難發(fā)現(xiàn)這樣的發(fā)展規(guī)律。

自 1980s DBMS 出現(xiàn)以來，IBM 等商業(yè)化公司在早期紛紛推出 OLTP 型數(shù)據(jù)庫，這一時期數(shù)據(jù)庫的典型特征是為了解決應(yīng)用程序開發(fā)過程中管理數(shù)據(jù)的復(fù)雜性問題。隨著時間的推移，1990s 企業(yè)開始出現(xiàn)大量數(shù)據(jù)分析型需求，比如銀行報表，這催生了一個新的分支 OLAP。

到 21 世紀(jì)初，互聯(lián)網(wǎng)行業(yè)迎來大規(guī)模爆發(fā)，OLTP 開始無法滿足企業(yè)對于在線數(shù)據(jù)的一些管理訴求，OLAP 也難以管理離線分析、作業(yè)處理系統(tǒng)上的數(shù)據(jù)，加之商業(yè)化數(shù)據(jù)庫和存儲帶來的巨大成本使企業(yè)難以承受，以 NoSQL 和 BigData 為代表的數(shù)據(jù)庫革命正式爆發(fā)，無論是 Google 開源的 HDFS、Bigtable，還是 HBase、MongoDB，它們都旨在解決 OLTP 型數(shù)據(jù)庫吞吐量、擴(kuò)展性不足的問題。

到 2010 年，Google 開始大量使用 NoSQL 和 BigData 數(shù)據(jù)庫系統(tǒng)，但很快它就發(fā)現(xiàn)了不少問題，比如 NoSQL 不支持事務(wù)且每個產(chǎn)品的 NoSQL 接口都不一樣，這給應(yīng)用程序遷移和學(xué)習(xí)帶來了極大的成本，為此它又開發(fā)了 NewSQL 這一新分支。

整體來看，數(shù)據(jù)庫在短短二三十年演進(jìn)過程出現(xiàn)了大量分支，技術(shù)和產(chǎn)品也越來越復(fù)雜。到今天，大家又覺得這些東西太復(fù)雜，開始著手去做簡化，比如 2015 年左右，AWS 結(jié)合 OLTP 和云原生發(fā)布了分布式數(shù)據(jù)庫 Aurora，結(jié)合 OLAP 與云原生發(fā)布 Redshift，包括 BigData 也正與數(shù)據(jù)湖概念結(jié)合，衍生出一些新形態(tài)。

除此之外，近幾年行業(yè)又開始流行 HTAP，把云、OLAP、BigData 做有機(jī)結(jié)合，使數(shù)據(jù)庫既能處理復(fù)雜的 query，又能支持在線業(yè)務(wù)訴求。那么這樣的三合一是不是未來的發(fā)展趨勢呢？我們不知道。

數(shù)據(jù)庫團(tuán)隊的兩個觀察和思考

數(shù)據(jù)庫領(lǐng)域的技術(shù)和產(chǎn)品經(jīng)歷了從簡單到復(fù)雜再到簡單的過程，但如果審視做數(shù)據(jù)管理的真實初衷，恐怕大家的目標(biāo)都是為了方便用戶——而各種復(fù)雜分支恰恰讓用戶更難做技術(shù)選型。

我們能不能不要選擇性地去解決一部分問題，而是構(gòu)建一個大而全的系統(tǒng)去解決問題？我們能否為用戶提供統(tǒng)一的數(shù)據(jù)管理服務(wù)？即使現(xiàn)在做不到，那我們能不能提供盡量少的數(shù)據(jù)管理服務(wù)，去簡化研發(fā)人員的研發(fā)成本，包括用戶的使用成本和學(xué)習(xí)成本？

基于以上思考，字節(jié)跳動數(shù)據(jù)庫團(tuán)隊產(chǎn)生了兩個重要的觀察思考：

首先是橫向融合探索，簡化業(yè)務(wù)應(yīng)用數(shù)據(jù)管理體系。舉個例子，過去構(gòu)建一個微服務(wù)，數(shù)據(jù)層既要考慮在線數(shù)據(jù)，也會考慮離線數(shù)據(jù)，不可避免會涉及多種數(shù)據(jù)庫及每種數(shù)據(jù)庫下不同的表的管理，導(dǎo)致在線應(yīng)用的復(fù)雜度較高。同時從在線數(shù)據(jù)生成到離線分析，數(shù)據(jù)的可見性通常會以天、小時、分鐘級別計數(shù)。在數(shù)據(jù) ETL 過程中，數(shù)據(jù)的 integrity 如何去保證，這也是一個非常大的挑戰(zhàn)。

字節(jié)跳動數(shù)據(jù)庫團(tuán)隊一直在嘗試通過技術(shù)上的融合簡化在線應(yīng)用的數(shù)據(jù)管理，例如 veDB 正在探索把 MySQL、ES Protocols 的協(xié)議集成到數(shù)據(jù)庫里，支持事務(wù)處理、分析查詢、搜索等融合任務(wù)，使應(yīng)用側(cè)只需關(guān)注數(shù)據(jù)本身，無需關(guān)注數(shù)據(jù)和維護(hù)多種數(shù)據(jù)庫。在事務(wù)處理層面，veDB 已經(jīng)能做到數(shù)據(jù)可見性秒級，并且強(qiáng)一致，支持 snapshot 隔離級別。通過存儲層的技術(shù)整合，veDB 也大幅優(yōu)化了數(shù)據(jù)的存儲成本，顯著降低了數(shù)據(jù)冗余系數(shù)。

其次是縱向融合探索，重塑應(yīng)用緩存和數(shù)據(jù)庫邊界。單體和微服務(wù)時代，用戶在使用數(shù)據(jù)庫時，需要在前面掛一個 Redis，因為數(shù)據(jù)庫的吞吐量通常不能夠做得很大，容易被過高的 QPS 打掛。當(dāng)企業(yè)架構(gòu)從單體時代發(fā)展到在線微服務(wù)時代，這種做法會帶來大量緩存系統(tǒng)和數(shù)據(jù)庫類型的復(fù)雜管理難題，因此我們希望通過一套系統(tǒng)重塑應(yīng)用緩存和數(shù)據(jù)庫，為用戶帶來便捷。比如我們正在 veDB 中做一些軟件和技術(shù)硬件層面的探索，盡可能減少用戶的數(shù)據(jù)管理成本和學(xué)習(xí)成本，同時消除用戶 multi-tiering 數(shù)據(jù)流動管理，讓用戶聚焦業(yè)務(wù)邏輯，也幫助他們消除了原先數(shù)據(jù)與緩存不一致性等業(yè)界難題。

第三是分離和整合：新的變量、硬件和系統(tǒng)。除了用戶層面一些應(yīng)用場景的融合，我們也在公司基礎(chǔ)架構(gòu)體系內(nèi)部看到了一些分離和整合的內(nèi)容，比如軟件、硬件和操作系統(tǒng)。下圖左側(cè)是數(shù)據(jù)庫模塊，從上到下分別是 SQL 層、事務(wù)層、緩存層和存儲層；右側(cè)則是云數(shù)據(jù)中心里應(yīng)用的運(yùn)行時環(huán)境，比如公司大部分微服務(wù)都跑在 K8s 上，硬件層面的新算力、新互聯(lián)、新存儲都在與時俱進(jìn)地發(fā)生變化。

以算力為例，從只有 CPU 到發(fā)展到 CPU+GPU+DPU+FPGA，數(shù)據(jù)庫團(tuán)隊一直在嘗試把壓縮、加密解密等復(fù)雜的、需要消耗算力的作業(yè)放到 FPGA 里去。當(dāng)公司 CPU 算力從 96c 發(fā)展到 192c 甚至超過 300c，如何重塑數(shù)據(jù)庫里的索引、事務(wù)處理也是我們要提前思考的問題。

第四是分離與整合：當(dāng)前云數(shù)據(jù)中心的 building blocks。

總的來講，數(shù)據(jù)庫也是一種軟件，當(dāng)前我們能不能利用云中心里的硬件和運(yùn)行時環(huán)境使數(shù)據(jù)庫變得更強(qiáng)大、更彈性，也是一個重要方向。

數(shù)據(jù)庫團(tuán)隊在軟件、系統(tǒng)層面做了非常多的工作，比如把數(shù)據(jù)庫 Severless 化，把數(shù)據(jù)庫里的狀態(tài)放到分布式的 Persistent Memory 構(gòu)建的高性能存儲引擎里，在存儲層實現(xiàn)自動分層分級。通過這樣，我們可以把計算層做得更加彈性。

以下圖為例，有三個租戶，其中租戶 A 需要一些 MySQL 和 PG。我們可以把這些租戶的數(shù)據(jù)庫實例運(yùn)行在容器中，動態(tài)地做計算資源調(diào)配，根據(jù)業(yè)務(wù)的高峰期和低谷期提供不同大小的數(shù)據(jù)庫實例來實現(xiàn)彈性。在這種大一統(tǒng)運(yùn)營模式之下，我們就可以擺脫以往獨立物理機(jī)數(shù)量不足的窘境，利用公司百萬級服務(wù)器實現(xiàn)算力復(fù)用。

未來，數(shù)據(jù)庫團(tuán)隊會圍繞應(yīng)用場景層面的融合、縱向的技術(shù)整合以及硬件和系統(tǒng)的整合，重新構(gòu)建云數(shù)據(jù)庫，使它能夠回歸用戶價值，幫助用戶提升開發(fā)效率、運(yùn)行效率和運(yùn)營效率，降低學(xué)習(xí)和使用等各類成本。

字節(jié)跳動基礎(chǔ)架構(gòu)數(shù)據(jù)庫&云存儲團(tuán)隊

Database & Cloud Storage Team，服務(wù)于字節(jié)跳動全系產(chǎn)品。在這里，我們有豐富的云存儲產(chǎn)品，負(fù)責(zé)治理數(shù)十 EB 級別的海量數(shù)據(jù)；有多種數(shù)據(jù)庫產(chǎn)品，提供極致時延、超大吞吐的云原生數(shù)據(jù)庫服務(wù)；有前沿的技術(shù)研究，探索新硬件與新軟件架構(gòu)的融合，打造下一代革命性的云存儲與數(shù)據(jù)庫產(chǎn)品。

以上就是【沒想到！新鮮出爐（字節(jié)跳動的未來發(fā)展戰(zhàn)略）字節(jié)跳動未來趨勢-字節(jié)跳動數(shù)據(jù)庫的過去、現(xiàn)狀與未來】的全部內(nèi)容。

微信:N915888888

(歡迎您前來咨詢)