字節(jié)云數(shù)據(jù)庫概覽
字節(jié)云數(shù)據(jù)庫架構(gòu)分為四層，示意圖如下：
DBEngine 層：我們對外會提供完備的數(shù)據(jù)庫，兼容全面的數(shù)據(jù)庫生態(tài)，包括 Mysql、PG、ES、Mongo 等；同時我們也支持混合負載，即 HTAP。
DB-Cache 層：這一層會存儲兩類數(shù)據(jù)，一類是日志流，另一類是用戶數(shù)據(jù)的緩存。我們在這一層引入一些新的硬件進行加速，為用戶提供極致的性能體驗。
DB-Store 層：這一層是低成本、跨 AZ、多格式的 DB-Store 層，用于存儲用戶數(shù)據(jù)。DB-Store 層是一個分布式的存儲平臺，它支持插件式的存儲格式，比如 veDB 中的行存格式、 ByteHTAP 的行列混合格式；它也支持 Segment 級別的 PITR 特性，提高數(shù)據(jù)的可用性；它還支持壓縮 和 Tail Segment 的特性，來極致降低存儲成本。
Store 層：這一層是冷數(shù)據(jù)存儲層，用于存儲備份數(shù)據(jù)或者分層的冷數(shù)據(jù)。
Severless：目前 veDB 部署在字節(jié)內(nèi)部虛擬機上，同時我們支持在火山引擎上進行容器化部署。我們希望通過當前正在探索的 Serverless ，為用戶提供 pay by usage 的計費模式，提供自動 scale up 和 scale down 能力，來充分提高空閑資源的利用率。
Brian：這是數(shù)據(jù)庫的“大腦”，負責提供 AI 能力。
字節(jié)云數(shù)據(jù)庫架構(gòu)的特點是支持三個分離，一是存儲與計算的分離，二是日志和數(shù)據(jù)的分離，三是緩存與計算的分離。
A-Store For veDB 探索與實踐背景
業(yè)界的很多產(chǎn)品證明了 veDB 云原生數(shù)據(jù)庫架構(gòu)具有著強大優(yōu)勢，如下：
- 極致彈性，存儲計算按需擴展，這是存儲和計算分離帶來的核心優(yōu)勢，使得云原生數(shù)據(jù)庫在對外提供良好的兼容性同時提供良好的擴展性；
- 支持存儲層多租戶共享，能夠極致提高存儲資源利用率；
- 計算層超分超賣，提升計算利用率。
但是這種存儲與計算分離的架構(gòu)也有一定的劣勢：
- 計算存儲間延時增加；
- Local: 100us VS Remote: 1-5msdryme。
存儲和計算分離后，我們將存儲拉到遠端的分布式存儲系統(tǒng)上，會導致計算和存儲之間的延時增加。之前 MySQL 在本地訪問 nvme，訪問時間大概在微秒級別，但是經(jīng)過網(wǎng)絡延時后，訪問時間在毫秒級別。因此我們提出一個設想，是否有一個能和本地 NVME-SSD 同樣快且穩(wěn)定的存儲層？新硬件的持久化內(nèi)存和 RDMA 的出現(xiàn)為上述設想提供了可能。
Persistent Memory
在過去幾十年間，計算機系統(tǒng)已經(jīng)實現(xiàn)了如下金字塔型存儲結(jié)構(gòu)。
金字塔上層是易失存儲，容量小，延時低；金字塔下層是非易失存儲，容量大，延時高。對于 DRAM 及以上的易失存儲，CPU 可以通過 Load 和 Store 指令直接訪問，響應時間大致在幾十納秒到 100 納秒級別。對于 SSD 及以下的非易失存儲， CPU 就無法直接訪問，企業(yè)級 SSD 的響應時間可以達到 10 微秒到 100 微秒的級別。由此可以看出 SSD 和 DRAM 之間存在差不多 100 多倍的性能差距，在訪問時延上存在一個很大的跳變，但是持久化內(nèi)存的出現(xiàn)彌補了它們之間的性能鴻溝。
持久化內(nèi)存（PMEM）位于 DRAM 和 SSD 之間，它具有以下幾個核心的特性：
- 非易失性：持久化內(nèi)存具備硬盤的特性，即掉電重啟，內(nèi)存中的數(shù)據(jù)依舊存在；
- 字節(jié)可尋址；
- 大容量：對于單臺服務器，持久化內(nèi)存容量可以達到 TB 級別；
- 低延時。
在數(shù)據(jù)庫領(lǐng)域，持久化內(nèi)存目前主要有兩種使用模式，模式一：將其作為一個單機的持久化層，用來加速單個計算節(jié)點的性能；模式二：把它拉遠做一個分布式的持久化池。作為 veDB 產(chǎn)品的擴展，字節(jié)數(shù)據(jù)庫團隊在架構(gòu)上是將 PMEM 作為分布式的共享存儲池，用于加速 veDB 的性能。相對于第一種單機模式，拉遠的存儲池存在一個缺陷：它仍舊需要通過網(wǎng)絡來訪問，性能低于單機的持久化內(nèi)存。但是 RDMA 的出現(xiàn)能夠有效彌補該缺陷。
RDMA
RDMA 是一種遠程直接內(nèi)存訪問的技術(shù)。在傳統(tǒng)的 TCP/IP 協(xié)議中，數(shù)據(jù)傳輸時會經(jīng)過多次的數(shù)據(jù)拷貝，以及經(jīng)過 CPU 的內(nèi)核上下文切換。數(shù)據(jù)需要經(jīng)歷從用戶態(tài)到內(nèi)核態(tài)，從內(nèi)核態(tài)再拷貝到網(wǎng)卡。同時，TPC/IP 協(xié)議會有一些處理開銷，包括 Buffer 管理，協(xié)議棧管理，以及發(fā)送完之后系統(tǒng)中斷引起的開銷。RDMA 技術(shù)能夠幫助計算機直接存取另外一個計算機的內(nèi)存。
RDMA 具有以下三個核心優(yōu)勢：
- 零拷貝（Zero-Copy）：應用程序能夠直接執(zhí)行數(shù)據(jù)傳輸，不需要經(jīng)過多次數(shù)據(jù)拷貝，就能直接發(fā)送到遠端的計算機內(nèi)存中去；
- 內(nèi)核旁路（Kernal bypass）：應用程序直接可以在用戶態(tài)執(zhí)行數(shù)據(jù)傳輸，不用經(jīng)過用戶態(tài)到內(nèi)核態(tài)的上下文切換；
- 不需要 CPU 干預（No CPU invovlement）。
基于以上 PMEM 和 RDMA 的新硬件加持，存儲系統(tǒng)能夠提供極低的延時，非常適用于對性能要求很高、容量無需很大的場景，比如存儲系統(tǒng)中的 Cache、WAL 日志、內(nèi)存數(shù)據(jù)庫等。
A-Store 架構(gòu)
基于 AEP + RDMA 硬件，數(shù)據(jù)庫團隊設計了分布式、高性能存儲系統(tǒng)——A-Store。A-Store 對外提供的語義是 Append-only 寫接口和隨機讀，支持 RDMA 單雙邊的消息。
從圖中可以看出，A-store 架構(gòu)包含三個模塊：
- AEP-SDK 模塊: SDK 會作為一個庫，連接到計算層的比如 veDB 的 DB Engine 中去，成為一個 IO 入口；
- AEP-Server 模塊：它是一個單獨的進程，部署在某個存儲節(jié)點上，就負責管理該節(jié)點上所有 AEP 的介質(zhì)以及后臺任務；
- 集群管理模塊：這個模塊復用了 veDB 存儲層的集群管理模塊，對其進行了一些適配和修改，主要負責數(shù)據(jù)分布、節(jié)點故障發(fā)現(xiàn)、元數(shù)據(jù)的持久化。
最后，A-store 架構(gòu)具有三個核心特點：一是高性能，硬件直通設計，旁路 Server 軟件棧，IO 路徑是完全無鎖化的設計，也沒有拷貝；二是分布式，底層的 Server 層可以擴展；三是高可用，存儲在 AEP-Server 的數(shù)據(jù)，一般都支持多副本部署，目前我們一般部署三副本，保證數(shù)據(jù)的高可靠性。
A-Store 應用
A-Store 主要有以下兩個應用方向：
- 緩解 veDB 存儲拉遠對性能的影響：veDB 存儲拉遠具體拉遠了哪些數(shù)據(jù)？比如在 MySQL 系統(tǒng)里通常會有兩類數(shù)據(jù)：Redo 日志和用戶數(shù)據(jù)，我們就將這兩類數(shù)據(jù)拉遠，此時我們通過 A-Store 加速這兩類數(shù)據(jù)訪問速度，因此 A-Store 的第一個應用是用于 Redo 日志加速。第二個應用是 Extend Buffer Pool。
- 特性增強：我們正在開發(fā)一款基于 A-store 的高性能存儲引擎， MemTable。
A-Store For Redo Log 加速
在之前的 veDB 部署中， Redo 日志是通過 Logstore 的組件，將數(shù)據(jù)寫到了遠端的 Append only 的分布式系統(tǒng)。當我們引入 A-Store 之后，我們將會替代原來的 Logstore 的組件，將 A-Store 的 SDK 集成到 DB Engine 內(nèi)部。相比之前的 Logstore 實現(xiàn)，A-Store 具有兩個優(yōu)勢：
- 無數(shù)據(jù)拷貝：在之前 Logstore 的實現(xiàn)里，除了有 TCP IP 的網(wǎng)絡拷貝，從用戶態(tài)到內(nèi)核態(tài)的拷貝之外，在軟件棧上也有多次數(shù)據(jù)拷貝。使用 A-Store 能夠完全去掉這種內(nèi)存拷貝, DB Engine 直接把 Redo 日志寫到 RDMA 注冊的內(nèi)存上去，無需任何的數(shù)據(jù)拷貝；
- 無線程切換：在之前 Logstore 的實現(xiàn)里，我們會有多次的線程切換，從 DB Engine 的 Log writer 線程，切換到 Logstore 線程里去。使用 A-Store 之后，我們可以直接在 Log writer 的線程里調(diào)用 A-Store 接口，無需任何軟件棧的處理，就能夠直接寫到遠端的 AEP Server 上去。
Redo 日志的寫速度，對于寫負載是非常重要的。在我們目前的測試中，替換成 A-Store 之后，對于純寫的場景，性能能夠提高 20% -30%；線上真實 Workload(write-heave)，性能提升 2 倍＋。
A-Store For Extend Buffer Pool
原生的 mysql 處理查詢都是單線程的處理模型，訪問數(shù)據(jù)時都要先去判斷數(shù)據(jù)是否在 Buffer Pool 中，如果不在，我們需要通過同步的接口把數(shù)據(jù)從遠端存儲拉到 Buffer Pool。如果數(shù)據(jù)沒有命中 Buffer Pool，比如數(shù)據(jù)量很大，Buffer Pool 線上最多開 100 G ，對于用戶的請求，請求延時就會增加。為了緩解拉取遠端存儲的性能下降問題，我們擴展了原生的 Buffer Pool 設計，將 A-Store 作為一個遠程分布式的二級緩存，來擴大緩存空間的大小。它的一個主要優(yōu)勢是：延時更低，容量更大。
除此之外，A-Store 還提供 Hot 特性。主節(jié)點在故障宕機，進行主備切換之后, 備機可以直接使用遠端 AEP Buffer pool 的數(shù)據(jù)，縮短冷啟動時間。我們在純讀、純寫的場景下都進行了測試，性能提高 30% - 70% 左右。
MemTable For veDB
第二個應用方向是提供特性增強。字節(jié)未來的發(fā)展方向是提供數(shù)據(jù)庫的縱向融合探索，重塑應用緩存和數(shù)據(jù)庫之間的邊界。基于 A-store 設計，我們正在開發(fā)一款內(nèi)存數(shù)據(jù)庫引擎 MemTable，對外兼容 SQL 協(xié)議。
MemTable 架構(gòu)
MemTable 架構(gòu)也采用計算與分離的思路，中間通過 RDMA 進行通訊，它與當前的 veDB 存在幾點不同。一是，MemTable 在計算層引入編譯執(zhí)行技術(shù)來大幅度提高 SQL 的執(zhí)行速度；二是存儲和事務的處理與 InnoDB 不同：在索引結(jié)構(gòu)上，我們目前采用 ART 索引結(jié)構(gòu)；另外我們采用 MVOCC 并發(fā)控制算法進行事務控制；最后我們采用 Record 粒度的數(shù)據(jù)組織格式。
MemTable for veDB 架構(gòu)
MemTable 出現(xiàn)之后，veDB 的整體架構(gòu)如上圖所示，MemTable 將作為 MySQL 的插件式存儲引擎。同時，它會與 InnoDB 形成互補，InnoDB 可以滿足業(yè)務容量型需求，MemTable 則可以滿足業(yè)務高吞吐低延時需求，預計性能可以達到 InnoDB 的 10 倍 +。
ByteHTAP 探索與實踐
背景
HTAP 概念早在 2014 年由 Gartner 提出。HTAP 強調(diào)以下兩個核心理念：
- 打破 AP(Analytical Processing) 和 TP(Transaction Processing)系統(tǒng)中間的墻：在數(shù)據(jù)庫發(fā)展最初階段，其實存在只有一個系統(tǒng)，不用區(qū)分 TP 和 AP 。伴隨著數(shù)據(jù)量的增長，單個系統(tǒng)內(nèi)部沒法既支持 TP 又支持 AP， 因此發(fā)展出兩個方向 OLTP 和 OLAP 。HTAP 的出現(xiàn)能夠打破 TP 到 AP 之間的墻，在一個系統(tǒng)中同時去支持這兩類負載。
- 實時性：伴隨著互聯(lián)網(wǎng)的發(fā)展，互聯(lián)網(wǎng)企業(yè)的數(shù)據(jù)呈現(xiàn)爆發(fā)式增長。TP 和 AP 的用戶 pattern 是完全不同的——TP 的 pattern 一般是命中二級索引的簡單類查詢，再加上一個增、刪、改的高頻更新操作，但是 AP 系統(tǒng)處理的都是一些復雜的查詢。這兩種 Workload 本身是非常不同的，所以如果在一個系統(tǒng)里，數(shù)據(jù)量比較大的前提下去支持這兩類負載，基本不太現(xiàn)實。目前許多公司都有兩套系統(tǒng)， TP 和 AP 系統(tǒng)，而這樣的架構(gòu)會帶來三個問題：一是，實時性要求。數(shù)據(jù)產(chǎn)生在 OLTP 系統(tǒng)里，然后經(jīng)過 ETL 的清洗流入到數(shù)據(jù)倉庫之后，數(shù)據(jù)通常會存在分鐘級甚至小時級、天級的延時。二是，數(shù)據(jù)一致性的要求。當前許多用戶的使用場景都是把數(shù)據(jù)從 TP 的系統(tǒng)導入到 AP 的系統(tǒng)，在多個系統(tǒng)之間維護一致性非常困難；三是，成本，包括人力/硬件成本。
以上是業(yè)界提出 HTAP 的背景，在字節(jié)跳動，我們希望進行橫向融合探索，通過對外提供 everything is SQL 的接口；在內(nèi)部，不管是 TP 還是 AP，PG 還是 MySQL，通過設置統(tǒng)一的處理層來簡化業(yè)務應用數(shù)據(jù)管理體系。
架構(gòu)
ByteHTAP 架構(gòu)主要基于以下三個核心目標進行設計：
- 實時查詢（時延 < 1 sec）：用戶希望在 AP 側(cè)實時看到 TP 側(cè)引入的數(shù)據(jù)修改，延時小于 1 秒鐘，該目標對于用戶十分重要。比如字節(jié)跳動的用戶增長部門就需要在數(shù)據(jù)不斷變化的同時，對其進行復雜的查詢；廣告、商業(yè)分析的用戶也希望能夠在秒級的范圍內(nèi)對修改的數(shù)據(jù)進行應用。
- 強一致性（SI 隔離級別）：實時分析的數(shù)據(jù)集支持強一致性，為用戶提供 snapshot 隔離級別，大大簡化用戶對一致性的處理成本。
- 高性能（更新/復雜查詢）。
整體架構(gòu)
基于以上核心目標，數(shù)據(jù)庫團隊設計了如下的 ByteHTAP 整體架構(gòu)。
目前業(yè)界存在很多 HTAP 產(chǎn)品，比如 Memory SQL 系統(tǒng) 、HANA 系統(tǒng)、還有在 TP 系統(tǒng)中擴展 AP 能力、或者在 AP 系統(tǒng)中擴展 TP 能力。2017 年 ACM 發(fā)表的一篇關(guān)于調(diào)研 HTAP 的論文將 HTAP 大致分為了兩類，第一類是 Single Engine 系統(tǒng)，這類系統(tǒng)有一個統(tǒng)一的查詢處理引擎，比如 Memory SQL 系統(tǒng)。第二類 Separate Engine 系統(tǒng)，這類系統(tǒng)使用分開的查詢處理引擎進行 TP 和 AP 的處理。對于 ByteHTAP 而言，它具有以下三個核心特性：
- 一是：TP/AP 引擎分離。ByteHTAP 系統(tǒng)使用的是分開的查詢處理引擎來處理 TP 和 AP，這么做帶來的好處是我們可以在字節(jié)內(nèi)部或者是在開源的成熟產(chǎn)品里面選擇兩個不同的 TP 和 AP 系統(tǒng)來分別支持 Query Processing 的處理。這種處理對于用戶來說是透明的，我們對外會有一個智能代理層，它會自動將用戶的請求路由到 TP 系統(tǒng)或者 AP 系統(tǒng)。
- 二是：計算存儲分離。ByteHTAP 基于 veDB 擴展，使用 veDB 系統(tǒng)作為 OLTP 的引擎，它的一個核心組件是分布式日志框架，用來負責將日志復制和分發(fā)到底層的數(shù)據(jù)存儲頁面 PageStore 上。同時，在 ByteHTAP 系統(tǒng)中，數(shù)據(jù)庫團隊擴展了分布式日志框架，日志不僅能夠被分發(fā)到 PageStore，還能夠被分發(fā)到 HTAPStore。上層架構(gòu)了 Query Processing，目前 Query Processing 采用的 Apache Flink 實現(xiàn)。
- 三是：共享行列存儲平臺。ByteHTAP 的另一個核心組件是 Meta Data Service，用來存儲 AP 系統(tǒng)的元信息，包括元信息的定義，統(tǒng)計信息，以此輔助用戶查詢。
關(guān)鍵技術(shù)點
數(shù)據(jù)庫團隊分別根據(jù)三個核心目標研發(fā)了對應的核心技術(shù)。針對實時查詢，我們提供了以下三個核心技術(shù)，達到時延 < 1sec 的目標：
- 引入輕量級的 Log Parser 設計。在 HTAP 系統(tǒng)里，我們復用了 veDB 中高效的日志復制框架，基于 column 協(xié)議對日志進行分發(fā)，避免寫入的一個長尾時延；其次如果日志有空洞，可以采用 gossip 協(xié)議進行補洞；我們設計了一個輕量級的 Log Parser 機制，按需解析字段并進行分發(fā)。
- 分布式并行 Apply。用戶在創(chuàng)建表時可以根據(jù)需求定制自己指定的分片策略。隨后，日志復制框架會將日記分發(fā)到存儲系統(tǒng)上，各個分片可以進行分布式并行 Apply 。
- In-memory Delta Store + Persistent Base Cloumn Store。該技術(shù)是針對存儲的，我們在存儲層采用一個 In-memory Delta Store，它是一種行存格式，以及 Persistent Base Cloumn Store，它是行列混合的存儲格式，用來加速 Apply 、Flash、 Compaction 流程。
針對強一致性，涉及以下三個核心技術(shù)點，實現(xiàn) SI 隔離級別：
- 事務原子性更新可見點。我們實現(xiàn)了基于 lsn 的多本管理機制，我們在 AP 系統(tǒng)使用的日志是在 TP 系統(tǒng)里事務提交時產(chǎn)生的邏輯日志，所以事務原子性得到天然保障。我們?yōu)槿罩举x予了一個全局版本號，會原子地去更新版本號。
- 數(shù)據(jù)多版本。DataStore 支持多版本，每個用戶在查詢時都會攜帶一個全局一致的版本號，然后發(fā)送到 HTAPStore 上去，HTAPStore 會基于他的版本號給對應的數(shù)據(jù)。
- 元信息多版本。Meta Data Service 的元信息支持多版本存儲。HTAPStore 在進行日志回放時，會從邏輯日志里解析 DDL ，Meta Data Service 會拿到 DDL 的變更。
最后針對高性能，涉及以下三個核心技術(shù)點，實現(xiàn)更新/復雜查詢：
- 使用分布式計算引擎，提高執(zhí)行效率。
- 支持算子下推，比如 Filter 算子、聚合算子都可以下推到 HTAPStore 上。
- 高效的數(shù)據(jù)導入。目前我們開發(fā)了一個快速導入的工具，該工具可以幫助我們從 veDB 的 TP 系統(tǒng)拿到一個一致性的點，直接進行數(shù)據(jù)頁面的解析和寫入，將解析出來的數(shù)據(jù)以批量的方式直接寫入到 BaseStore，大大提高數(shù)據(jù)遷移的速度。
應用
ByteHTAP 可以被應用到以下兩個典型應用場景：
- 用戶需求是實時性：投放分析師需要實時調(diào)整投放計劃，在使用 ByteHTAP 之前，實時性基本上是小時級，當系統(tǒng)切換到 ByteHTAP 之后，實時性可以達到秒級。
- 用戶需求是高性能查詢：之前數(shù)據(jù)主要存儲在 MySQL 上，人力科技做數(shù)據(jù)匯總查詢比較復雜。在使用 ByteHTAP 之后，用戶將系統(tǒng)遷到 veDB 上， TP 側(cè)用來作為用戶的寫入，ByteHTAP 一側(cè)用來作為用戶的查詢，性能提升從 10 分鐘級降到秒級。
