作者 ｜ 張雷

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

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

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

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

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

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

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

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

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

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

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

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

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

字節(jié)跳動(dòng)數(shù)據(jù)庫(kù)的“過(guò)去”第一代數(shù)據(jù)庫(kù)系統(tǒng)架構(gòu)主要分三層，示意圖如下：

Application 層：前文提到的 1000 萬(wàn)個(gè)容器及其構(gòu)成的 10 萬(wàn)個(gè)微服務(wù)都部署在應(yīng)用層;

Proxy 層：代理層主要負(fù)責(zé)數(shù)據(jù)庫(kù)的一些接入工作，比如鑒權(quán)、流量染色、流量分發(fā)等;

Database 層：這一層部署著數(shù)據(jù)庫(kù)的一些實(shí)例，通過(guò)數(shù)據(jù)庫(kù)的 Binlog 實(shí)現(xiàn)數(shù)據(jù)的同步、高可用。

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

系統(tǒng)彈性較差。首先是容量難以得到靈活擴(kuò)展，抖音這類 App 通常都由數(shù)萬(wàn)個(gè)微服務(wù)構(gòu)成，當(dāng)微服務(wù)的數(shù)據(jù)量從早期的數(shù)十 GB 發(fā)展到之后的數(shù)十 TB，我們不得不需要花費(fèi)大量時(shí)間拆解原先的庫(kù);其次，吞吐量彈性不如人意，互聯(lián)網(wǎng)行業(yè)經(jīng)常會(huì)有春晚、電商促銷等活動(dòng)，我們需要提前進(jìn)行擴(kuò)容以應(yīng)對(duì)流量洪峰，活動(dòng)過(guò)后，數(shù)據(jù)庫(kù)難以立即收縮，也需要團(tuán)隊(duì)花費(fèi)時(shí)間搬遷大量數(shù)據(jù);

研發(fā)效率問(wèn)題。在用戶側(cè)，從申請(qǐng)數(shù)據(jù)庫(kù)到數(shù)據(jù)庫(kù)上線，期間會(huì)經(jīng)過(guò)漫長(zhǎng)的討論談判，因此如何提高數(shù)據(jù)庫(kù)的研發(fā)效率也是我們著重考慮的問(wèn)題。此外，運(yùn)維效率也有待提升——大量的拆庫(kù)和合并工作會(huì)為研發(fā)帶來(lái)不小的負(fù)擔(dān);

綜合成本偏高。第一代數(shù)據(jù)庫(kù)系統(tǒng)架構(gòu)為了 reserve CPU 和存儲(chǔ)資源以應(yīng)對(duì)流量洪峰和業(yè)務(wù)增長(zhǎng)，早期 CPU 使用率十分低下，比如 MySQL 數(shù)據(jù)庫(kù)的 CPU 使用率通常只有 10%，有些節(jié)點(diǎn)甚至長(zhǎng)期在 5% 以下;存儲(chǔ)空間也非常浪費(fèi)，整個(gè)空間的利用率只有 20%-30%。

字節(jié)跳動(dòng)數(shù)據(jù)庫(kù)的“現(xiàn)在”為了解決這三個(gè)問(wèn)題，數(shù)據(jù)庫(kù)團(tuán)隊(duì)開(kāi)發(fā)了第二代數(shù)據(jù)庫(kù)，圍繞標(biāo)準(zhǔn)化和系統(tǒng)化構(gòu)建了龐大的產(chǎn)品矩陣和運(yùn)維平臺(tái)。

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

veDB主體架構(gòu)

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

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

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

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

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

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

靈活性強(qiáng)：veDB 基于 shared-storage 架構(gòu)，實(shí)現(xiàn)了計(jì)算存儲(chǔ)分離，業(yè)務(wù)方可以按需彈性使用存儲(chǔ)容量，解決了存儲(chǔ)成本比較高的問(wèn)題;

兼容性好：目前 veDB 基本上已做到 100% 兼容 MySQL 8.0 和 PostgreSQL 12，現(xiàn)已兼容 MongoDB 4.0;

高可用性：存儲(chǔ)層多副本，支持單 AZ/跨 3 AZ 強(qiáng)一致部署，既保持了靈活性，又解決了傳統(tǒng)通過(guò) Binlog 跨多數(shù)據(jù)中心異步復(fù)制帶來(lái)的 RPO
無(wú)法等于 0 的問(wèn)題;

高性能：數(shù)據(jù)庫(kù)團(tuán)隊(duì)做了大量?jī)?yōu)化工作，使 veDB 在高并發(fā)集群模式下的吞吐量 QPS 遠(yuǎn)超傳統(tǒng)單機(jī)數(shù)據(jù)庫(kù);

成本低：按需獨(dú)立擴(kuò)縮計(jì)算/存儲(chǔ)，存儲(chǔ)層高壓縮比，把存儲(chǔ)空間利用率從第一代系統(tǒng)的 20%-30% 提升到了現(xiàn)在的 70%;

超大容量：單表 64 TB，并支持 PB-level 解決方案。

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

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

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

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

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

字節(jié)跳動(dòng)數(shù)據(jù)庫(kù)的“未來(lái)”

未來(lái)數(shù)據(jù)庫(kù)的情景預(yù)測(cè)

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

在談及未來(lái)之前，首先我們可以回顧兩個(gè)問(wèn)題：

• 數(shù)據(jù)庫(kù)服務(wù)產(chǎn)品解決的問(wèn)題是什么?
• 數(shù)據(jù)庫(kù)服務(wù)產(chǎn)品面臨的新環(huán)境是什么?

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

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

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

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

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

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

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

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

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

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

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

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

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

• 應(yīng)用場(chǎng)景方面的融合：提升用戶效率，降低用戶的接入和使用成本;
• 基礎(chǔ)設(shè)施層面的分離和整合：提升系統(tǒng)層面的效率，降低系統(tǒng)層面的成本，可以為用戶讓利。

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

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

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

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

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

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

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

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

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

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