位元組雲資料庫未來方向的探索與實踐

語言: CN / TW / HK

動手點關注 乾貨不迷路  :point_up_2:

日前,位元組跳動技術社群 ByteTech 舉辦的第四期位元組跳動技術沙龍圓滿落幕,本期沙龍以《位元組雲資料庫架構設計與實戰》為主題。在沙龍中,位元組跳動基礎架構資料庫開發工程師劉輝聰,跟大家探討了 《位元組雲資料庫未來方向的探索與實踐》,本文根據分享整理而成。

位元組雲資料庫概覽

位元組雲資料庫架構分為四層,示意圖如下:

  • DBEngine 層: 我們對外會提供完備的資料庫,相容全面的資料庫生態,包括 Mysql、PG、ES、Mongo 等;同時我們也支援混合負載,即 HTAP。

  • DB-Cache 層: 這一層會儲存兩類資料,一類是日誌流,另一類是使用者資料的快取。我們在這一層引入一些新的硬體進行加速,為使用者提供極致的效能體驗。

  • DB-Store 層: 這一層是低成本、跨 AZ、多格式的 DB-Store 層,用於儲存使用者資料。DB-Store 層是一個分散式的儲存平臺,它支援外掛式的儲存格式,比如 veDB 中的行存格式、 ByteHTAP 的行列混合格式;它也支援 Segment 級別的 PITR 特性,提高資料的可用性;它還支援壓縮 和 Tail Segment 的特性,來極致降低儲存成本。

  • Store 層: 這一層是冷資料儲存層,用於儲存備份資料或者分層的冷資料。

  • Severless: 目前 veDB 部署在位元組內部虛擬機器上,同時我們支援在火山引擎上進行容器化部署。我們希望通過當前正在探索的 Serverless ,為使用者提供 pay by usage 的計費模式,提供自動 scale up 和 scale down 能力,來充分提高空閒資源的利用率。

  • Brian: 這是資料庫的“大腦”,負責提供 AI 能力。

位元組雲資料庫架構的特點是支援三個分離,一是儲存與計算的分離,二是日誌和資料的分離,三是快取與計算的分離。

A-Store For veDB 探索與實踐

背景

業界的很多產品證明了 veDB 雲原生資料庫架構具有著強大 優勢, 如下:

  • 極致彈性,儲存計算按需擴充套件,這是儲存和計算分離帶來的核心優勢,使得雲原生資料庫在對外提供良好的相容性同時提供良好的擴充套件性;

  • 支援儲存層多租戶共享,能夠極致提高儲存資源利用率;

  • 計算層超分超賣,提升計算利用率。

但是這種儲存與計算分離的架構也有一定的 劣勢:

  • 計算儲存間延時增加;

  • Local: 100us VS Remote: 1-5msdryme。

儲存和計算分離後,我們將儲存拉到遠端的分散式儲存系統上,會導致計算和儲存之間的延時增加。之前 MySQL 在本地訪問 nvme,訪問時間大概在微秒級別,但是經過網路延時後,訪問時間在毫秒級別。因此我們提出一個設想,是否有一個能和本地 NVME-SSD 同樣快且穩定的儲存層?新硬體的持久化記憶體和 RDMA 的出現為上述設想提供了可能。

Persistent Memory

在過去幾十年間,計算機系統已經實現瞭如下金字塔型儲存結構。

金字塔上層是易失儲存,容量小,延時低;金字塔下層是非易失儲存,容量大,延時高。對於 DRAM 及以上的易失儲存,CPU 可以通過 Load 和 Store 指令直接訪問,響應時間大致在幾十納秒到 100 納秒級別。對於 SSD 及以下的非易失儲存, CPU 就無法直接訪問,企業級 SSD 的響應時間可以達到 10 微秒到 100 微秒的級別。由此可以看出 SSD 和 DRAM 之間存在差不多 100 多倍的效能差距,在訪問時延上存在一個很大的跳變,但是持久化記憶體的出現彌補了它們之間的效能鴻溝。

持久化記憶體(PMEM)位於 DRAM 和 SSD 之間,它具有以下幾個核心的特性:

  • 非易失性:持久化記憶體具備硬碟的特性,即掉電重啟,記憶體中的資料依舊存在;

  • 位元組可定址;

  • 大容量:對於單臺伺服器,持久化記憶體容量可以達到 TB 級別;

  • 低延時。

在資料庫領域,持久化記憶體目前主要有兩種使用模式,模式一:將其作為一個單機的持久化層,用來加速單個計算節點的效能;模式二:把它拉遠做一個分散式的持久化池。作為 veDB 產品的擴充套件,位元組資料庫團隊在架構上是將 PMEM 作為分散式的共享儲存池,用於加速 veDB 的效能。相對於第一種單機模式,拉遠的儲存池存在一個缺陷:它仍舊需要通過網路來訪問,效能低於單機的持久化記憶體。但是 RDMA 的出現能夠有效彌補該缺陷。

RDMA

RDMA 是一種遠端直接記憶體訪問的技術。在傳統的 TCP/IP 協議中,資料傳輸時會經過多次的資料拷貝,以及經過 CPU 的核心上下文切換。資料需要經歷從使用者態到核心態,從核心態再拷貝到網絡卡。同時,TPC/IP 協議會有一些處理開銷,包括 Buffer 管理,協議棧管理,以及傳送完之後系統中斷引起的開銷。RDMA 技術能夠幫助計算機直接存取另外一個計算機的記憶體。

RDMA 具有以下三個核心優勢:

  • 零拷貝(Zero-Copy):應用程式能夠直接執行資料傳輸,不需要經過多次資料拷貝,就能直接傳送到遠端的計算機記憶體中去;

  • 核心旁路(Kernal bypass):應用程式直接可以在使用者態執行資料傳輸,不用經過使用者態到核心態的上下文切換;

  • 不需要 CPU 干預(No CPU invovlement)。

基於以上 PMEM 和 RDMA 的新硬體加持,儲存系統能夠提供極低的延時,非常適用於對效能要求很高、容量無需很大的場景,比如儲存系統中的 Cache、WAL 日誌、記憶體資料庫等。

A-Store 架構

基於 AEP + RDMA 硬體,資料庫團隊設計了分散式、高效能儲存系統——A-Store。A-Store 對外提供的語義是 Append-only 寫介面和隨機讀,支援 RDMA 單雙邊的訊息。

從圖中可以看出,A-store 架構包含三個模組:

  • AEP-SDK 模組: SDK 會作為一個庫,連線到計算層的比如 veDB 的 DB Engine 中去,成為一個 IO 入口;

  • AEP-Server 模組:它是一個單獨的程序,部署在某個儲存節點上,就負責管理該節點上所有 AEP 的介質以及後臺任務;

  • 叢集管理模組:這個模組複用了 veDB 儲存層的叢集管理模組,對其進行了一些適配和修改,主要負責資料分佈、節點故障發現、元資料的持久化。

最後,A-store 架構具有三個核心特點:一是高效能,硬體直通設計,旁路 Server 軟體棧,IO 路徑是完全無鎖化的設計,也沒有拷貝;二是分散式,底層的 Server 層可以擴充套件;三是高可用,儲存在 AEP-Server 的資料,一般都支援多副本部署,目前我們一般部署三副本,保證資料的高可靠性。

A-Store 應用

A-Store 主要有以下兩個應用方向:

  • 緩解 veDB 儲存拉遠對效能的影響: veDB 儲存拉遠具體拉遠了哪些資料?比如在 MySQL 系統裡通常會有兩類資料:Redo 日誌和使用者資料,我們就將這兩類資料拉遠,此時我們通過 A-Store 加速這兩類資料訪問速度,因此 A-Store 的第一個應用是用於 Redo 日誌加速。第二個應用是 Extend Buffer Pool。

  • 特性增強: 我們正在開發一款基於 A-store 的高效能儲存引擎, MemTable。

A-Store For Redo Log 加速

在之前的 veDB 部署中, Redo 日誌是通過 Logstore 的元件,將資料寫到了遠端的 Append only 的分散式系統。當我們引入 A-Store 之後,我們將會替代原來的 Logstore 的元件,將 A-Store 的 SDK 整合到 DB Engine 內部。相比之前的 Logstore 實現,A-Store 具有兩個優勢:

  • 無資料拷貝: 在之前 Logstore 的實現裡,除了有 TCP IP 的網路拷貝,從使用者態到核心態的拷貝之外,在軟體棧上也有多次資料拷貝。使用 A-Store 能夠完全去掉這種記憶體拷貝, DB Engine 直接把 Redo 日誌寫到 RDMA 註冊的記憶體上去,無需任何的資料拷貝;

  • 無執行緒切換: 在之前 Logstore 的實現裡,我們會有多次的執行緒切換,從 DB Engine 的 Log writer 執行緒,切換到 Logstore 執行緒裡去。使用 A-Store 之後,我們可以直接在 Log writer 的執行緒裡呼叫 A-Store 介面,無需任何軟體棧的處理,就能夠直接寫到遠端的 AEP Server 上去。

Redo 日誌的寫速度,對於寫負載是非常重要的。在我們目前的測試中,替換成 A-Store 之後,對於純寫的場景,效能能夠提高 20% -30%;線上真實 Workload(write-heave),效能提升 2 倍+。

A-Store For Extend Buffer Pool

原生的 mysql 處理查詢都是單執行緒的處理模型,訪問資料時都要先去判斷資料是否在 Buffer Pool 中,如果不在,我們需要通過同步的介面把資料從遠端儲存拉到 Buffer Pool。如果資料沒有命中 Buffer Pool,比如資料量很大,Buffer Pool 線上最多開 100 G ,對於使用者的請求,請求延時就會增加。為了緩解拉取遠端儲存的效能下降問題,我們擴充套件了原生的 Buffer Pool 設計,將 A-Store 作為一個遠端分散式的二級快取,來擴大快取空間的大小。它的一個主要優勢是:延時更低,容量更大。

除此之外,A-Store 還提供 Hot 特性。主節點在故障宕機,進行主備切換之後, 備機可以直接使用遠端 AEP Buffer pool 的資料,縮短冷啟動時間。我們在純讀、純寫的場景下都進行了測試,效能提高 30% - 70% 左右。

MemTable For veDB

第二個應用方向是提供特性增強。位元組未來的發展方向是提供資料庫的縱向融合探索,重塑應用快取和資料庫之間的邊界。基於 A-store 設計,我們正在開發一款記憶體資料庫引擎 MemTable,對外相容 SQL 協議。

MemTable 架構

MemTable 架構也採用計算與分離的思路,中間通過 RDMA 進行通訊,它與當前的 veDB 存在幾點不同。一是,MemTable 在計算層引入編譯執行技術來大幅度提高 SQL 的執行速度;二是儲存和事務的處理與 InnoDB 不同:在索引結構上,我們目前採用 ART 索引結構;另外我們採用 MVOCC 併發控制演算法進行事務控制;最後我們採用 Record 粒度的資料組織格式。

MemTable for veDB 架構

MemTable 出現之後,veDB 的整體架構如上圖所示,MemTable 將作為 MySQL 的外掛式儲存引擎。同時,它會與 InnoDB 形成互補,InnoDB 可以滿足業務容量型需求,MemTable 則可以滿足業務高吞吐低延時需求,預計效能可以達到 InnoDB 的 10 倍 +。

ByteHTAP 探索與實踐

背景

HTAP 概念早在 2014 年由 Gartner 提出。HTAP 強調以下兩個核心理念:

  • 打破 AP (Analytical Processing) 和 TP (Transaction Processing) 系統中間的牆: 在資料庫發展最初階段,其實存在只有一個系統,不用區分 TP 和 AP 。伴隨著資料量的增長,單個系統內部沒法既支援 TP 又支援 AP, 因此發展出兩個方向 OLTP 和 OLAP 。HTAP 的出現能夠打破 TP 到 AP 之間的牆,在一個系統中同時去支援這兩類負載。

  • 實時性: 伴隨著網際網路的發展,網際網路企業的資料呈現爆發式增長。TP 和 AP 的使用者 pattern 是完全不同的——TP 的 pattern 一般是命中二級索引的簡單類查詢,再加上一個增、刪、改的高頻更新操作,但是 AP 系統處理的都是一些複雜的查詢。這兩種 Workload 本身是非常不同的,所以如果在一個系統裡,資料量比較大的前提下去支援這兩類負載,基本不太現實。目前許多公司都有兩套系統, TP 和 AP 系統,而這樣的架構會帶來三個問題:一是,實時性要求。資料產生在 OLTP 系統裡,然後經過 ETL 的清洗流入到資料倉庫之後,資料通常會存在分鐘級甚至小時級、天級的延時。二是,資料一致性的要求。當前許多使用者的使用場景都是把資料從 TP 的系統匯入到 AP 的系統,在多個系統之間維護一致性非常困難;三是,成本,包括人力/硬體成本。

以上是業界提出 HTAP 的背景,在位元組跳動,我們希望進行橫向融合探索,通過對外提供 everything is SQL 的介面;在內部,不管是 TP 還是 AP,PG 還是 MySQL,通過設定統一的處理層來簡化業務應用資料管理體系。

架構

ByteHTAP 架構主要基於以下三個核心目標進行設計:

  • 實時查詢 (時延 < 1 sec):使用者希望在 AP 側實時看到 TP 側引入的資料修改,延時小於 1 秒鐘,該目標對於使用者十分重要。比如位元組跳動的使用者增長部門就需要在資料不斷變化的同時,對其進行復雜的查詢;廣告、商業分析的使用者也希望能夠在秒級的範圍內對修改的資料進行應用。

  • 強一致性 (SI 隔離級別):實時分析的資料集支援強一致性,為使用者提供 snapshot 隔離級別,大大簡化使用者對一致性的處理成本。

  • 高效能 (更新/複雜查詢)。

整體架構

基於以上核心目標,資料庫團隊設計瞭如下的 ByteHTAP 整體架構。

目前業界存在很多 HTAP 產品,比如 Memory SQL 系統 、HANA 系統、還有在 TP 系統中擴充套件 AP 能力、或者在 AP 系統中擴充套件 TP 能力。2017 年 ACM 發表的一篇關於調研 HTAP 的論文將 HTAP 大致分為了兩類,第一類是 Single Engine 系統,這類系統有一個統一的查詢處理引擎,比如 Memory SQL 系統。第二類 Separate Engine 系統,這類系統使用分開的查詢處理引擎進行 TP 和 AP 的處理。對於 ByteHTAP 而言,它具有以下三個核心特性:

  • 一是:TP/AP 引擎分離。 ByteHTAP 系統使用的是分開的查詢處理引擎來處理 TP 和 AP,這麼做帶來的好處是我們可以在位元組內部或者是在開源的成熟產品裡面選擇兩個不同的 TP 和 AP 系統來分別支援 Query Processing 的處理。這種處理對於使用者來說是透明的,我們對外會有一個智慧代理層,它會自動將使用者的請求路由到 TP 系統或者 AP 系統。

  • 二是:計算儲存分離。 ByteHTAP 基於 veDB 擴充套件,使用 veDB 系統作為 OLTP 的引擎,它的一個核心元件是分散式日誌框架,用來負責將日誌複製和分發到底層的資料儲存頁面 PageStore 上。同時,在 ByteHTAP 系統中,資料庫團隊擴充套件了分散式日誌框架,日誌不僅能夠被分發到 PageStore,還能夠被分發到 HTAPStore。上層架構了 Query Processing,目前 Query Processing 採用的 Apache Flink 實現。

  • 三是:共享行列儲存平臺。 ByteHTAP 的另一個核心元件是 Meta Data Service,用來儲存 AP 系統的元資訊,包括元資訊的定義,統計資訊,以此輔助使用者查詢。

關鍵技術點

資料庫團隊分別根據三個核心目標研發了對應的核心技術。針對實時查詢,我們提供了以下三個核心技術,達到時延 < 1sec 的目標:

  • 引入輕量級的 Log Parser 設計。 在 HTAP 系統裡,我們複用了 veDB 中高效的日誌複製框架,基於 column 協議對日誌進行分發,避免寫入的一個長尾時延;其次如果日誌有空洞,可以採用 gossip 協議進行補洞;我們設計了一個輕量級的 Log Parser 機制,按需解析欄位並進行分發。

  • 分散式並行 Apply。 使用者在建立表時可以根據需求定製自己指定的分片策略。隨後,日誌複製框架會將日記分發到儲存系統上,各個分片可以進行分散式並行 Apply 。

  • In-memory Delta Store + Persistent Base Cloumn Store。 該技術是針對儲存的,我們在儲存層採用一個 In-memory Delta Store,它是一種行存格式,以及 Persistent Base Cloumn Store,它是行列混合的儲存格式,用來加速 Apply 、Flash、 Compaction 流程。

針對強一致性,涉及以下三個核心技術點,實現 SI 隔離級別:

  • 事務原子性更新可見點。 我們實現了基於 lsn 的多本管理機制,我們在 AP 系統使用的日誌是在 TP 系統裡事務提交時產生的邏輯日誌,所以事務原子性得到天然保障。我們為日誌賦予了一個全域性版本號,會原子地去更新版本號。

  • 資料多版本。 DataStore 支援多版本,每個使用者在查詢時都會攜帶一個全域性一致的版本號,然後傳送到 HTAPStore 上去,HTAPStore 會基於他的版本號給對應的資料。

  • 元資訊多版本。 Meta Data Service 的元資訊支援多版本儲存。HTAPStore 在進行日誌回放時,會從邏輯日誌裡解析 DDL ,Meta Data Service 會拿到 DDL 的變更。

最後針對高效能,涉及以下三個核心技術點,實現更新/複雜查詢:

  • 使用分散式計算引擎, 提高執行效率。

  • 支援運算元下推, 比如 Filter 運算元、聚合運算元都可以下推到 HTAPStore 上。

  • 高效的資料匯入。 目前我們開發了一個快速匯入的工具,該工具可以幫助我們從 veDB 的 TP 系統拿到一個一致性的點,直接進行資料頁面的解析和寫入,將解析出來的資料以批量的方式直接寫入到 BaseStore,大大提高資料遷移的速度。

應用

ByteHTAP 可以被應用到以下兩個典型應用場景:

  • 使用者需求是實時性: 投放分析師需要實時調整投放計劃,在使用 ByteHTAP 之前,實時性基本上是小時級,當系統切換到 ByteHTAP 之後,實時性可以達到秒級。

  • 使用者需求是高效能查詢: 之前資料主要儲存在 MySQL 上,人力科技做資料彙總查詢比較複雜。在使用 ByteHTAP 之後,使用者將系統遷到 veDB 上, TP 側用來作為使用者的寫入,ByteHTAP 一側用來作為使用者的查詢,效能提升從 10 分鐘級降到秒級。

位元組跳動基礎架構資料庫&雲端儲存團隊

Database & Cloud Storage Team,服務於位元組跳動全系產品。在這裡,我們有豐富的雲端儲存產品,負責治理數十 EB 級別的海量資料;有多種資料庫產品,提供極致時延、超大吞吐的雲原生資料庫服務;有前沿的技術研究,探索新硬體與新軟體架構的融合,打造下一代革命性的雲端儲存與資料庫產品。

以上內容整理自第四期位元組跳動技術沙龍《位元組雲資料庫架構設計與實戰》,獲取講師 PPT 和回放影片,請在公眾號“位元組跳動技術團隊”後臺回覆關鍵詞“0416”。

推薦閱讀

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

從單機到分散式資料庫儲存系統的演進

火山引擎雲資料庫 veDB 在位元組內部的業務實踐