字節跳動數據庫的過去、現狀與未來

動手點關註 幹貨不迷路 

日前,字節跳動技術社區 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://www.codegarden.cn/article/30286/
返回顶部