日前，字節(jié)跳動(dòng)技術(shù)社區(qū) ByteTech 舉辦的第四期字節(jié)跳動(dòng)技術(shù)沙龍圓滿落幕，本期沙龍以《字節(jié)云數(shù)據(jù)庫架構(gòu)設(shè)計(jì)與實(shí)戰(zhàn)》為主題。在沙龍中，字節(jié)跳動(dòng)基礎(chǔ)架構(gòu)數(shù)據(jù)庫開發(fā)工程師劉輝聰，跟大家探討了 《字節(jié)云數(shù)據(jù)庫未來方向的探索與實(shí)踐》，本文根據(jù)分享整理而成。

字節(jié)云數(shù)據(jù)庫概覽

字節(jié)云數(shù)據(jù)庫架構(gòu)分為四層，示意圖如下：

DBEngine 層：我們對(duì)外會(huì)提供完備的數(shù)據(jù)庫，兼容全面的數(shù)據(jù)庫生態(tài)，包括 Mysql、PG、ES、Mongo 等；同時(shí)我們也支持混合負(fù)載，即 HTAP。

DB-Cache 層：這一層會(huì)存儲(chǔ)兩類數(shù)據(jù)，一類是日志流，另一類是用戶數(shù)據(jù)的緩存。我們?cè)谶@一層引入一些新的硬件進(jìn)行加速，為用戶提供極致的性能體驗(yàn)。

DB-Store 層：這一層是低成本、跨 AZ、多格式的 DB-Store 層，用于存儲(chǔ)用戶數(shù)據(jù)。DB-Store 層是一個(gè)分布式的存儲(chǔ)平臺(tái)，它支持插件式的存儲(chǔ)格式，比如 veDB 中的行存格式、 ByteHTAP 的行列混合格式；它也支持 Segment 級(jí)別的 PITR 特性，提高數(shù)據(jù)的可用性；它還支持壓縮 和 Tail Segment 的特性，來極致降低存儲(chǔ)成本。

Store 層：這一層是冷數(shù)據(jù)存儲(chǔ)層，用于存儲(chǔ)備份數(shù)據(jù)或者分層的冷數(shù)據(jù)。

Severless：目前 veDB 部署在字節(jié)內(nèi)部虛擬機(jī)上，同時(shí)我們支持在火山引擎上進(jìn)行容器化部署。我們希望通過當(dāng)前正在探索的 Serverless ，為用戶提供 pay by usage 的計(jì)費(fèi)模式，提供自動(dòng) scale up 和 scale down 能力，來充分提高空閑資源的利用率。

Brian：這是數(shù)據(jù)庫的“大腦”，負(fù)責(zé)提供 AI 能力。

字節(jié)云數(shù)據(jù)庫架構(gòu)的特點(diǎn)是支持三個(gè)分離，一是存儲(chǔ)與計(jì)算的分離，二是日志和數(shù)據(jù)的分離，三是緩存與計(jì)算的分離。

A-Store For veDB 探索與實(shí)踐背景

業(yè)界的很多產(chǎn)品證明了 veDB 云原生數(shù)據(jù)庫架構(gòu)具有著強(qiáng)大優(yōu)勢，如下：

• 極致彈性，存儲(chǔ)計(jì)算按需擴(kuò)展，這是存儲(chǔ)和計(jì)算分離帶來的核心優(yōu)勢，使得云原生數(shù)據(jù)庫在對(duì)外提供良好的兼容性同時(shí)提供良好的擴(kuò)展性；
• 支持存儲(chǔ)層多租戶共享，能夠極致提高存儲(chǔ)資源利用率；
• 計(jì)算層超分超賣，提升計(jì)算利用率。

但是這種存儲(chǔ)與計(jì)算分離的架構(gòu)也有一定的劣勢：

• 計(jì)算存儲(chǔ)間延時(shí)增加；
• Local: 100us VS Remote: 1-5msdryme。

存儲(chǔ)和計(jì)算分離后，我們將存儲(chǔ)拉到遠(yuǎn)端的分布式存儲(chǔ)系統(tǒng)上，會(huì)導(dǎo)致計(jì)算和存儲(chǔ)之間的延時(shí)增加。之前 MySQL 在本地訪問 nvme，訪問時(shí)間大概在微秒級(jí)別，但是經(jīng)過網(wǎng)絡(luò)延時(shí)后，訪問時(shí)間在毫秒級(jí)別。因此我們提出一個(gè)設(shè)想，是否有一個(gè)能和本地 NVME-SSD 同樣快且穩(wěn)定的存儲(chǔ)層？新硬件的持久化內(nèi)存和 RDMA 的出現(xiàn)為上述設(shè)想提供了可能。

Persistent Memory

在過去幾十年間，計(jì)算機(jī)系統(tǒng)已經(jīng)實(shí)現(xiàn)了如下金字塔型存儲(chǔ)結(jié)構(gòu)。

金字塔上層是易失存儲(chǔ)，容量小，延時(shí)低；金字塔下層是非易失存儲(chǔ)，容量大，延時(shí)高。對(duì)于 DRAM 及以上的易失存儲(chǔ)，CPU 可以通過 Load 和 Store 指令直接訪問，響應(yīng)時(shí)間大致在幾十納秒到 100 納秒級(jí)別。對(duì)于 SSD 及以下的非易失存儲(chǔ)， CPU 就無法直接訪問，企業(yè)級(jí) SSD 的響應(yīng)時(shí)間可以達(dá)到 10 微秒到 100 微秒的級(jí)別。由此可以看出 SSD 和 DRAM 之間存在差不多 100 多倍的性能差距，在訪問時(shí)延上存在一個(gè)很大的跳變，但是持久化內(nèi)存的出現(xiàn)彌補(bǔ)了它們之間的性能鴻溝。

持久化內(nèi)存（PMEM）位于 DRAM 和 SSD 之間，它具有以下幾個(gè)核心的特性：

• 非易失性：持久化內(nèi)存具備硬盤的特性，即掉電重啟，內(nèi)存中的數(shù)據(jù)依舊存在；
• 字節(jié)可尋址；
• 大容量：對(duì)于單臺(tái)服務(wù)器，持久化內(nèi)存容量可以達(dá)到 TB 級(jí)別；
• 低延時(shí)。

在數(shù)據(jù)庫領(lǐng)域，持久化內(nèi)存目前主要有兩種使用模式，模式一：將其作為一個(gè)單機(jī)的持久化層，用來加速單個(gè)計(jì)算節(jié)點(diǎn)的性能；模式二：把它拉遠(yuǎn)做一個(gè)分布式的持久化池。作為 veDB 產(chǎn)品的擴(kuò)展，字節(jié)數(shù)據(jù)庫團(tuán)隊(duì)在架構(gòu)上是將 PMEM 作為分布式的共享存儲(chǔ)池，用于加速 veDB 的性能。相對(duì)于第一種單機(jī)模式，拉遠(yuǎn)的存儲(chǔ)池存在一個(gè)缺陷：它仍舊需要通過網(wǎng)絡(luò)來訪問，性能低于單機(jī)的持久化內(nèi)存。但是 RDMA 的出現(xiàn)能夠有效彌補(bǔ)該缺陷。

RDMA

RDMA 是一種遠(yuǎn)程直接內(nèi)存訪問的技術(shù)。在傳統(tǒng)的 TCP/IP 協(xié)議中，數(shù)據(jù)傳輸時(shí)會(huì)經(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)卡。同時(shí)，TPC/IP 協(xié)議會(huì)有一些處理開銷，包括 Buffer 管理，協(xié)議棧管理，以及發(fā)送完之后系統(tǒng)中斷引起的開銷。RDMA 技術(shù)能夠幫助計(jì)算機(jī)直接存取另外一個(gè)計(jì)算機(jī)的內(nèi)存。

RDMA 具有以下三個(gè)核心優(yōu)勢：

• 零拷貝（Zero-Copy）：應(yīng)用程序能夠直接執(zhí)行數(shù)據(jù)傳輸，不需要經(jīng)過多次數(shù)據(jù)拷貝，就能直接發(fā)送到遠(yuǎn)端的計(jì)算機(jī)內(nèi)存中去；
• 內(nèi)核旁路（Kernal bypass）：應(yīng)用程序直接可以在用戶態(tài)執(zhí)行數(shù)據(jù)傳輸，不用經(jīng)過用戶態(tài)到內(nèi)核態(tài)的上下文切換；
• 不需要 CPU 干預(yù)（No CPU invovlement）。

基于以上 PMEM 和 RDMA 的新硬件加持，存儲(chǔ)系統(tǒng)能夠提供極低的延時(shí)，非常適用于對(duì)性能要求很高、容量無需很大的場景，比如存儲(chǔ)系統(tǒng)中的 Cache、WAL 日志、內(nèi)存數(shù)據(jù)庫等。

A-Store 架構(gòu)

基于 AEP + RDMA 硬件，數(shù)據(jù)庫團(tuán)隊(duì)設(shè)計(jì)了分布式、高性能存儲(chǔ)系統(tǒng)——A-Store。A-Store 對(duì)外提供的語義是 Append-only 寫接口和隨機(jī)讀，支持 RDMA 單雙邊的消息。

從圖中可以看出，A-store 架構(gòu)包含三個(gè)模塊：

• AEP-SDK 模塊: SDK 會(huì)作為一個(gè)庫，連接到計(jì)算層的比如 veDB 的 DB Engine 中去，成為一個(gè) IO 入口；
• AEP-Server 模塊：它是一個(gè)單獨(dú)的進(jìn)程，部署在某個(gè)存儲(chǔ)節(jié)點(diǎn)上，就負(fù)責(zé)管理該節(jié)點(diǎn)上所有 AEP 的介質(zhì)以及后臺(tái)任務(wù)；
• 集群管理模塊：這個(gè)模塊復(fù)用了 veDB 存儲(chǔ)層的集群管理模塊，對(duì)其進(jìn)行了一些適配和修改，主要負(fù)責(zé)數(shù)據(jù)分布、節(jié)點(diǎn)故障發(fā)現(xiàn)、元數(shù)據(jù)的持久化。

最后，A-store 架構(gòu)具有三個(gè)核心特點(diǎn)：一是高性能，硬件直通設(shè)計(jì)，旁路 Server 軟件棧，IO 路徑是完全無鎖化的設(shè)計(jì)，也沒有拷貝；二是分布式，底層的 Server 層可以擴(kuò)展；三是高可用，存儲(chǔ)在 AEP-Server 的數(shù)據(jù)，一般都支持多副本部署，目前我們一般部署三副本，保證數(shù)據(jù)的高可靠性。

A-Store 應(yīng)用

A-Store 主要有以下兩個(gè)應(yīng)用方向：

• 緩解 veDB 存儲(chǔ)拉遠(yuǎn)對(duì)性能的影響：veDB 存儲(chǔ)拉遠(yuǎn)具體拉遠(yuǎn)了哪些數(shù)據(jù)？比如在 MySQL 系統(tǒng)里通常會(huì)有兩類數(shù)據(jù)：Redo 日志和用戶數(shù)據(jù)，我們就將這兩類數(shù)據(jù)拉遠(yuǎn)，此時(shí)我們通過 A-Store 加速這兩類數(shù)據(jù)訪問速度，因此 A-Store 的第一個(gè)應(yīng)用是用于 Redo 日志加速。第二個(gè)應(yīng)用是 Extend Buffer Pool。
• 特性增強(qiáng)：我們正在開發(fā)一款基于 A-store 的高性能存儲(chǔ)引擎， MemTable。

A-Store For Redo Log 加速

在之前的 veDB 部署中， Redo 日志是通過 Logstore 的組件，將數(shù)據(jù)寫到了遠(yuǎn)端的 Append only 的分布式系統(tǒng)。當(dāng)我們引入 A-Store 之后，我們將會(huì)替代原來的 Logstore 的組件，將 A-Store 的 SDK 集成到 DB Engine 內(nèi)部。相比之前的 Logstore 實(shí)現(xiàn)，A-Store 具有兩個(gè)優(yōu)勢：

• 無數(shù)據(jù)拷貝：在之前 Logstore 的實(shí)現(xiàn)里，除了有 TCP IP 的網(wǎng)絡(luò)拷貝，從用戶態(tài)到內(nèi)核態(tài)的拷貝之外，在軟件棧上也有多次數(shù)據(jù)拷貝。使用 A-Store 能夠完全去掉這種內(nèi)存拷貝, DB Engine 直接把 Redo 日志寫到 RDMA 注冊(cè)的內(nèi)存上去，無需任何的數(shù)據(jù)拷貝；
• 無線程切換：在之前 Logstore 的實(shí)現(xiàn)里，我們會(huì)有多次的線程切換，從 DB Engine 的 Log writer 線程，切換到 Logstore 線程里去。使用 A-Store 之后，我們可以直接在 Log writer 的線程里調(diào)用 A-Store 接口，無需任何軟件棧的處理，就能夠直接寫到遠(yuǎn)端的 AEP Server 上去。

Redo 日志的寫速度，對(duì)于寫負(fù)載是非常重要的。在我們目前的測試中，替換成 A-Store 之后，對(duì)于純寫的場景，性能能夠提高 20% -30%；線上真實(shí) Workload(write-heave)，性能提升 2 倍＋。

A-Store For Extend Buffer Pool

原生的 mysql 處理查詢都是單線程的處理模型，訪問數(shù)據(jù)時(shí)都要先去判斷數(shù)據(jù)是否在 Buffer Pool 中，如果不在，我們需要通過同步的接口把數(shù)據(jù)從遠(yuǎn)端存儲(chǔ)拉到 Buffer Pool。如果數(shù)據(jù)沒有命中 Buffer Pool，比如數(shù)據(jù)量很大，Buffer Pool 線上最多開 100 G ，對(duì)于用戶的請(qǐng)求，請(qǐng)求延時(shí)就會(huì)增加。為了緩解拉取遠(yuǎn)端存儲(chǔ)的性能下降問題，我們擴(kuò)展了原生的 Buffer Pool 設(shè)計(jì)，將 A-Store 作為一個(gè)遠(yuǎn)程分布式的二級(jí)緩存，來擴(kuò)大緩存空間的大小。它的一個(gè)主要優(yōu)勢是：延時(shí)更低，容量更大。

除此之外，A-Store 還提供 Hot 特性。主節(jié)點(diǎn)在故障宕機(jī)，進(jìn)行主備切換之后, 備機(jī)可以直接使用遠(yuǎn)端 AEP Buffer pool 的數(shù)據(jù)，縮短冷啟動(dòng)時(shí)間。我們?cè)诩冏x、純寫的場景下都進(jìn)行了測試，性能提高 30% - 70% 左右。

MemTable For veDB

第二個(gè)應(yīng)用方向是提供特性增強(qiáng)。字節(jié)未來的發(fā)展方向是提供數(shù)據(jù)庫的縱向融合探索，重塑應(yīng)用緩存和數(shù)據(jù)庫之間的邊界。基于 A-store 設(shè)計(jì)，我們正在開發(fā)一款內(nèi)存數(shù)據(jù)庫引擎 MemTable，對(duì)外兼容 SQL 協(xié)議。

MemTable 架構(gòu)

MemTable 架構(gòu)也采用計(jì)算與分離的思路，中間通過 RDMA 進(jìn)行通訊，它與當(dāng)前的 veDB 存在幾點(diǎn)不同。一是，MemTable 在計(jì)算層引入編譯執(zhí)行技術(shù)來大幅度提高 SQL 的執(zhí)行速度；二是存儲(chǔ)和事務(wù)的處理與 InnoDB 不同：在索引結(jié)構(gòu)上，我們目前采用 ART 索引結(jié)構(gòu)；另外我們采用 MVOCC 并發(fā)控制算法進(jìn)行事務(wù)控制；最后我們采用 Record 粒度的數(shù)據(jù)組織格式。

MemTable for veDB 架構(gòu)

MemTable 出現(xiàn)之后，veDB 的整體架構(gòu)如上圖所示，MemTable 將作為 MySQL 的插件式存儲(chǔ)引擎。同時(shí)，它會(huì)與 InnoDB 形成互補(bǔ)，InnoDB 可以滿足業(yè)務(wù)容量型需求，MemTable 則可以滿足業(yè)務(wù)高吞吐低延時(shí)需求，預(yù)計(jì)性能可以達(dá)到 InnoDB 的 10 倍 +。

ByteHTAP 探索與實(shí)踐

背景

HTAP 概念早在 2014 年由 Gartner 提出。HTAP 強(qiáng)調(diào)以下兩個(gè)核心理念：

• 打破 AP(Analytical Processing) 和 TP(Transaction Processing)系統(tǒng)中間的墻：在數(shù)據(jù)庫發(fā)展最初階段，其實(shí)存在只有一個(gè)系統(tǒng)，不用區(qū)分 TP 和 AP 。伴隨著數(shù)據(jù)量的增長，單個(gè)系統(tǒng)內(nèi)部沒法既支持 TP 又支持 AP， 因此發(fā)展出兩個(gè)方向 OLTP 和 OLAP 。HTAP 的出現(xiàn)能夠打破 TP 到 AP 之間的墻，在一個(gè)系統(tǒng)中同時(shí)去支持這兩類負(fù)載。
• 實(shí)時(shí)性：伴隨著互聯(lián)網(wǎng)的發(fā)展，互聯(lián)網(wǎng)企業(yè)的數(shù)據(jù)呈現(xiàn)爆發(fā)式增長。TP 和 AP 的用戶 pattern 是完全不同的——TP 的 pattern 一般是命中二級(jí)索引的簡單類查詢，再加上一個(gè)增、刪、改的高頻更新操作，但是 AP 系統(tǒng)處理的都是一些復(fù)雜的查詢。這兩種 Workload 本身是非常不同的，所以如果在一個(gè)系統(tǒng)里，數(shù)據(jù)量比較大的前提下去支持這兩類負(fù)載，基本不太現(xiàn)實(shí)。目前許多公司都有兩套系統(tǒng)， TP 和 AP 系統(tǒng)，而這樣的架構(gòu)會(huì)帶來三個(gè)問題：一是，實(shí)時(shí)性要求。數(shù)據(jù)產(chǎn)生在 OLTP 系統(tǒng)里，然后經(jīng)過 ETL 的清洗流入到數(shù)據(jù)倉庫之后，數(shù)據(jù)通常會(huì)存在分鐘級(jí)甚至小時(shí)級(jí)、天級(jí)的延時(shí)。二是，數(shù)據(jù)一致性的要求。當(dāng)前許多用戶的使用場景都是把數(shù)據(jù)從 TP 的系統(tǒng)導(dǎo)入到 AP 的系統(tǒng)，在多個(gè)系統(tǒng)之間維護(hù)一致性非常困難；三是，成本，包括人力/硬件成本。

以上是業(yè)界提出 HTAP 的背景，在字節(jié)跳動(dòng)，我們希望進(jìn)行橫向融合探索，通過對(duì)外提供 everything is SQL 的接口；在內(nèi)部，不管是 TP 還是 AP，PG 還是 MySQL，通過設(shè)置統(tǒng)一的處理層來簡化業(yè)務(wù)應(yīng)用數(shù)據(jù)管理體系。

架構(gòu)

ByteHTAP 架構(gòu)主要基于以下三個(gè)核心目標(biāo)進(jìn)行設(shè)計(jì)：

• 實(shí)時(shí)查詢（時(shí)延 < 1 sec）：用戶希望在 AP 側(cè)實(shí)時(shí)看到 TP 側(cè)引入的數(shù)據(jù)修改，延時(shí)小于 1 秒鐘，該目標(biāo)對(duì)于用戶十分重要。比如字節(jié)跳動(dòng)的用戶增長部門就需要在數(shù)據(jù)不斷變化的同時(shí)，對(duì)其進(jìn)行復(fù)雜的查詢；廣告、商業(yè)分析的用戶也希望能夠在秒級(jí)的范圍內(nèi)對(duì)修改的數(shù)據(jù)進(jìn)行應(yīng)用。
• 強(qiáng)一致性（SI 隔離級(jí)別）：實(shí)時(shí)分析的數(shù)據(jù)集支持強(qiáng)一致性，為用戶提供 snapshot 隔離級(jí)別，大大簡化用戶對(duì)一致性的處理成本。
• 高性能（更新/復(fù)雜查詢）。

整體架構(gòu)

基于以上核心目標(biāo)，數(shù)據(jù)庫團(tuán)隊(duì)設(shè)計(jì)了如下的 ByteHTAP 整體架構(gòu)。

目前業(yè)界存在很多 HTAP 產(chǎn)品，比如 Memory SQL 系統(tǒng) 、HANA 系統(tǒng)、還有在 TP 系統(tǒng)中擴(kuò)展 AP 能力、或者在 AP 系統(tǒng)中擴(kuò)展 TP 能力。2017 年 ACM 發(fā)表的一篇關(guān)于調(diào)研 HTAP 的論文將 HTAP 大致分為了兩類，第一類是 Single Engine 系統(tǒng)，這類系統(tǒng)有一個(gè)統(tǒng)一的查詢處理引擎，比如 Memory SQL 系統(tǒng)。第二類 Separate Engine 系統(tǒng)，這類系統(tǒng)使用分開的查詢處理引擎進(jìn)行 TP 和 AP 的處理。對(duì)于 ByteHTAP 而言，它具有以下三個(gè)核心特性：

• 一是：TP/AP 引擎分離。ByteHTAP 系統(tǒng)使用的是分開的查詢處理引擎來處理 TP 和 AP，這么做帶來的好處是我們可以在字節(jié)內(nèi)部或者是在開源的成熟產(chǎn)品里面選擇兩個(gè)不同的 TP 和 AP 系統(tǒng)來分別支持 Query Processing 的處理。這種處理對(duì)于用戶來說是透明的，我們對(duì)外會(huì)有一個(gè)智能代理層，它會(huì)自動(dòng)將用戶的請(qǐng)求路由到 TP 系統(tǒng)或者 AP 系統(tǒng)。
• 二是：計(jì)算存儲(chǔ)分離。ByteHTAP 基于 veDB 擴(kuò)展，使用 veDB 系統(tǒng)作為 OLTP 的引擎，它的一個(gè)核心組件是分布式日志框架，用來負(fù)責(zé)將日志復(fù)制和分發(fā)到底層的數(shù)據(jù)存儲(chǔ)頁面 PageStore 上。同時(shí)，在 ByteHTAP 系統(tǒng)中，數(shù)據(jù)庫團(tuán)隊(duì)擴(kuò)展了分布式日志框架，日志不僅能夠被分發(fā)到 PageStore，還能夠被分發(fā)到 HTAPStore。上層架構(gòu)了 Query Processing，目前 Query Processing 采用的 Apache Flink 實(shí)現(xiàn)。
• 三是：共享行列存儲(chǔ)平臺(tái)。ByteHTAP 的另一個(gè)核心組件是 Meta Data Service，用來存儲(chǔ) AP 系統(tǒng)的元信息，包括元信息的定義，統(tǒng)計(jì)信息，以此輔助用戶查詢。

關(guān)鍵技術(shù)點(diǎn)

數(shù)據(jù)庫團(tuán)隊(duì)分別根據(jù)三個(gè)核心目標(biāo)研發(fā)了對(duì)應(yīng)的核心技術(shù)。針對(duì)實(shí)時(shí)查詢，我們提供了以下三個(gè)核心技術(shù)，達(dá)到時(shí)延 < 1sec 的目標(biāo)：

• 引入輕量級(jí)的 Log Parser 設(shè)計(jì)。在 HTAP 系統(tǒng)里，我們復(fù)用了 veDB 中高效的日志復(fù)制框架，基于 column 協(xié)議對(duì)日志進(jìn)行分發(fā)，避免寫入的一個(gè)長尾時(shí)延；其次如果日志有空洞，可以采用 gossip 協(xié)議進(jìn)行補(bǔ)洞；我們?cè)O(shè)計(jì)了一個(gè)輕量級(jí)的 Log Parser 機(jī)制，按需解析字段并進(jìn)行分發(fā)。
• 分布式并行 Apply。用戶在創(chuàng)建表時(shí)可以根據(jù)需求定制自己指定的分片策略。隨后，日志復(fù)制框架會(huì)將日記分發(fā)到存儲(chǔ)系統(tǒng)上，各個(gè)分片可以進(jìn)行分布式并行 Apply 。
• In-memory Delta Store + Persistent Base Cloumn Store。該技術(shù)是針對(duì)存儲(chǔ)的，我們?cè)诖鎯?chǔ)層采用一個(gè) In-memory Delta Store，它是一種行存格式，以及 Persistent Base Cloumn Store，它是行列混合的存儲(chǔ)格式，用來加速 Apply 、Flash、 Compaction 流程。

針對(duì)強(qiáng)一致性，涉及以下三個(gè)核心技術(shù)點(diǎn)，實(shí)現(xiàn) SI 隔離級(jí)別：

• 事務(wù)原子性更新可見點(diǎn)。我們實(shí)現(xiàn)了基于 lsn 的多本管理機(jī)制，我們?cè)?AP 系統(tǒng)使用的日志是在 TP 系統(tǒng)里事務(wù)提交時(shí)產(chǎn)生的邏輯日志，所以事務(wù)原子性得到天然保障。我們?yōu)槿罩举x予了一個(gè)全局版本號(hào)，會(huì)原子地去更新版本號(hào)。
• 數(shù)據(jù)多版本。DataStore 支持多版本，每個(gè)用戶在查詢時(shí)都會(huì)攜帶一個(gè)全局一致的版本號(hào)，然后發(fā)送到 HTAPStore 上去，HTAPStore 會(huì)基于他的版本號(hào)給對(duì)應(yīng)的數(shù)據(jù)。
• 元信息多版本。Meta Data Service 的元信息支持多版本存儲(chǔ)。HTAPStore 在進(jìn)行日志回放時(shí)，會(huì)從邏輯日志里解析 DDL ，Meta Data Service 會(huì)拿到 DDL 的變更。

最后針對(duì)高性能，涉及以下三個(gè)核心技術(shù)點(diǎn)，實(shí)現(xiàn)更新/復(fù)雜查詢：

• 使用分布式計(jì)算引擎，提高執(zhí)行效率。
• 支持算子下推，比如 Filter 算子、聚合算子都可以下推到 HTAPStore 上。
• 高效的數(shù)據(jù)導(dǎo)入。目前我們開發(fā)了一個(gè)快速導(dǎo)入的工具，該工具可以幫助我們從 veDB 的 TP 系統(tǒng)拿到一個(gè)一致性的點(diǎn)，直接進(jìn)行數(shù)據(jù)頁面的解析和寫入，將解析出來的數(shù)據(jù)以批量的方式直接寫入到 BaseStore，大大提高數(shù)據(jù)遷移的速度。

應(yīng)用

ByteHTAP 可以被應(yīng)用到以下兩個(gè)典型應(yīng)用場景：

• 用戶需求是實(shí)時(shí)性：投放分析師需要實(shí)時(shí)調(diào)整投放計(jì)劃，在使用 ByteHTAP 之前，實(shí)時(shí)性基本上是小時(shí)級(jí)，當(dāng)系統(tǒng)切換到 ByteHTAP 之后，實(shí)時(shí)性可以達(dá)到秒級(jí)。
• 用戶需求是高性能查詢：之前數(shù)據(jù)主要存儲(chǔ)在 MySQL 上，人力科技做數(shù)據(jù)匯總查詢比較復(fù)雜。在使用 ByteHTAP 之后，用戶將系統(tǒng)遷到 veDB 上， TP 側(cè)用來作為用戶的寫入，ByteHTAP 一側(cè)用來作為用戶的查詢，性能提升從 10 分鐘級(jí)降到秒級(jí)。