一、背景與挑戰(zhàn)

首先來介紹一下相關(guān)背景。

傳統(tǒng)數(shù)倉存在實時和離線兩條鏈路，來滿足業(yè)務(wù)對于時效數(shù)據(jù)的時效性和數(shù)據(jù)量的不同需求。離線會維護歷史的全量視圖，實時會維護增量視圖，最后在服務(wù)層去進行數(shù)據(jù)的匯總，從而支持后續(xù)的在線的serving、 OLAP 查詢以及看板的應(yīng)用等等。 

因為處理場景的差異，在實時和離線數(shù)倉的具體實現(xiàn)上，依賴的底層存儲計算引擎基本上是完全隔離的，實時依賴的主要是以 Flink 為代表的流式計算引擎來做計算，而離線依賴主要是以 Spark 為代表的引擎，實時主要依賴 KV 或 MQ 這樣的多種存儲選型。離線則常常采用 Hive 為代表的存儲引擎，傳統(tǒng)的數(shù)倉架構(gòu)，它本質(zhì)上結(jié)合了流計算和 批計算的優(yōu)勢，通過兩套代碼來兼容實時數(shù)據(jù)和離線數(shù)據(jù)的優(yōu)勢，彌補各自的缺點。但是這兩套架構(gòu)或代碼也帶來了兩倍的資源成本，并且因為底層計算引擎的不同，對于相同算子的處理的語義不是完全一致的，它們的計算結(jié)果就會存在差異。所以對于研發(fā)同學(xué)來說，這部分差異也會給數(shù)據(jù)校驗等其它一些工作帶來額外的負擔(dān)。總結(jié)下來，傳統(tǒng)數(shù)倉的 Lambda 架構(gòu)主要存在三個問題要解決：第一個是一套計算邏輯，但需要寫離線和實時兩套代碼，帶來了兩倍的運維成本；第二是離線實時兩條鏈路帶來了資源冗余的問題，雙倍的資源的成本；第三是兩套引擎計算口徑不完全對齊，導(dǎo)致數(shù)據(jù)校準(zhǔn)方面會有比較大的困難。所以業(yè)內(nèi)提出了希望通過批流一體來解決當(dāng)前傳統(tǒng) Lambda 架構(gòu)的問題。基于上述問題，再結(jié)合內(nèi)部的實際場景，批流一體的訴求可以分為兩種，第一種是計算的批流一體，第二種是存儲的批流一體。計算的批流一體指的是希望通過底層一套系統(tǒng)，業(yè)務(wù)層的一套代碼同時滿足離線和實時的開發(fā)需求，從而解決兩套系統(tǒng)帶來的研發(fā)效率、人工成本、運維成本等資源成本相關(guān)的問題。另外我們希望一套系統(tǒng)能夠?qū)R計算指標(biāo)的口徑來解決數(shù)據(jù)一致性的問題。

存儲的流批一體包括，第一是實時和離線所在的存儲統(tǒng)一，第二是實時和離線的數(shù)據(jù)能夠復(fù)用。實時和離線存儲統(tǒng)一是指我們希望實時和離線能夠使用統(tǒng)一選型的存儲，這就要求存儲能夠滿足大規(guī)模、全量和增量數(shù)據(jù)的讀寫訴求。批流數(shù)據(jù)復(fù)用指的是批處理能夠使用流處理的結(jié)果數(shù)據(jù)，提升整個離線數(shù)倉的產(chǎn)出時間。典型的 case 就是 ODS 層的數(shù)據(jù)復(fù)用，另外流處理也能夠復(fù)用批處理的數(shù)據(jù)來解決鏈路冷啟動的時候，需要將離線的數(shù)據(jù)回灌到實時存儲中的額外成本，我們通過 LAS 去實現(xiàn)了批流一體的能力。在計算層，我們的解決思路是對外暴露統(tǒng)一的 SQL，底層根據(jù) SQL 處理的場景選擇不同的執(zhí)行引擎去執(zhí)行，對用戶屏蔽以底層執(zhí)行引擎的差異性。之所以這樣做的原因是我們認為不同引擎適用于不同場景，很難找到引擎能夠同時滿足實時和離線，不同時效性和數(shù)據(jù)規(guī)模的要求，在 SQL 層，我們對齊了底層執(zhí)行引擎的差異性來實現(xiàn)計算口徑的對齊，解決了上面說到的一致性問題。在存儲層，我們基于湖倉一體的架構(gòu)，通過數(shù)據(jù)湖實現(xiàn)了批流一體存儲的能力。除了能夠支持流式的增量和批式的全量讀寫之外，我們還支持了高效的 OLAP 查詢能力以及維表 join 的能力。

既然提到了LAS，我們看一下 LAS 的整體結(jié)構(gòu)， LAS全稱是 Lakehouse Analysis Service。湖倉一體的數(shù)據(jù)分析服務(wù)，融合了湖與倉的優(yōu)勢，既能夠利用湖的優(yōu)勢將所有的數(shù)據(jù)都存儲到廉價存儲中，供積極學(xué)習(xí)、數(shù)據(jù)分析等場景使用，又能夠基于數(shù)據(jù)湖構(gòu)建數(shù)倉，讓BI、報表等業(yè)務(wù)場景去使用。 

LAS具有如下一些特性：首先是能夠支持統(tǒng)一的元數(shù)據(jù)，避免在數(shù)據(jù)湖中存在數(shù)據(jù)孤島的問題，每個數(shù)據(jù)都是可追溯的。第二個是依托數(shù)據(jù)湖提供ACID 的能力。第三點是機器支持企業(yè)級的權(quán)限管控。第四點是支持資源的極致彈性擴縮容，降低用戶的使用成本。最后是引擎的內(nèi)核的極致優(yōu)化，提供高效的讀寫性能。LAS 整體架構(gòu)，最上面一層是湖倉開發(fā)工具，為數(shù)據(jù)應(yīng)用場景提供能力支撐。下面一層是數(shù)據(jù)分析引擎，支持流批一體SQL，解決計算批流一體的問題，并且支持根據(jù) SQL 的特點去做引擎的智能選擇和加速。針對 OLAP 分析，我們會將 SQL 路由到不同的執(zhí)行引擎去執(zhí)行，比如對 Ad-hoc我們會用 Presto 去進行查詢。再往下一層是統(tǒng)一元數(shù)據(jù)層，最后一層是基于 Hudi 去實現(xiàn)的流批存儲層。本文會聚焦在流批一體存儲的細節(jié)實現(xiàn)上。

我們需要分析現(xiàn)有的離線數(shù)倉和實時數(shù)倉的具體需求，來考慮流批一體存儲的實現(xiàn)方式。離線數(shù)倉的整體結(jié)構(gòu)分層相對來說還是比較清晰的，使用的存儲也會比較單一，主要是Spark 加 Hive 的形式，提供高效的數(shù)據(jù)處理和吞吐能力，能夠支持離線數(shù)據(jù)回溯場景下的并發(fā)更新。但是實時數(shù)倉的使用存儲相對來說會復(fù)雜一些，一般會依托 Kafka 或 MQ 進行每一層數(shù)據(jù)表的構(gòu)建，為了支持高效的 join 的性能，在維表的存儲選型上，我們往往會根據(jù)數(shù)據(jù)量的差異選擇KV、Hbase 或者是 MySQL 去進行存儲。在整體的 DWS 數(shù)倉鏈路梳理完之后，到了數(shù)據(jù)應(yīng)用層會對接 ClickHouse、Doris這樣的高效的 OLAP 引擎，去對外提供計時的數(shù)據(jù)看板報表等等。數(shù)據(jù)應(yīng)用層還會有一些 serving 的功能，服務(wù)層會將數(shù)據(jù)寫到 KV 或者 MySQL 或者 ES 這些存儲里，對外提供 serving 的服務(wù)。

在構(gòu)建實時數(shù)倉新鏈路的時候，對于鏈路冷啟動，需要使用歷史分區(qū)的數(shù)據(jù)，所以我們需要將離線的數(shù)據(jù)回灌到實時鏈路的 MQ 里面，受限于 MQ 帶寬的限制，整體的回溯周期可能會非常的長，并且操作很復(fù)雜。另外當(dāng)計算指標(biāo)有問題，或者是整體的計算口徑需要調(diào)整的時候，也需要使用離線的數(shù)據(jù)去對實時數(shù)據(jù)進行回刷，同樣它也會遇到回溯周期長，操作復(fù)雜等一系列問題。通過介紹可以看出實時數(shù)據(jù)倉庫整體相對比較復(fù)雜，存儲方式和構(gòu)建標(biāo)準(zhǔn)沒有完全統(tǒng)一。為了更精細地分析實時數(shù)據(jù)倉庫對于流批一體存儲的需求，我們基于數(shù)據(jù)量延遲、數(shù)據(jù)一致性要求和計算周期等維度，將場景劃分成了三類：日志計算、長周期計算和全量計算。

日志計算的場景特點在于數(shù)據(jù)量比較大，但是可以接受少量數(shù)據(jù)丟失。大部分數(shù)據(jù)要求在分鐘內(nèi)計算，并進行分組聚合。但該場景的痛點在于希望通過批流數(shù)據(jù)復(fù)用和統(tǒng)一以提升數(shù)據(jù)時效性和降低資源成本。對于長周期計算場景，數(shù)據(jù)量相對中等。需要對指標(biāo)進行復(fù)合計算，但整體數(shù)據(jù)周期可能較長。直播類業(yè)務(wù)場景可能持續(xù)一個月，數(shù)據(jù)要求在秒級。該場景的痛點在于冷啟動和回溯過程復(fù)雜、周期長、成本高。全量計算場景數(shù)據(jù)量不大，會將全量數(shù)據(jù)存儲到Flink state中進行計算，要求強一致性，時效性要求在秒級別。但該場景遇到的最大問題在于因數(shù)據(jù)存儲到Flink state中，未進行分層結(jié)構(gòu)，回溯的中間結(jié)果可能不透出，不太利于開發(fā)人員進行調(diào)試操作。總結(jié)來看，數(shù)倉對于存儲的主要需求可以概括為以下幾點：其一，實時存儲不統(tǒng)一，運維復(fù)雜；其二，實時離線存儲不統(tǒng)一，資源成本高；其三，冷啟動或回溯過程復(fù)雜耗時；其四，無法查詢中間數(shù)據(jù)。因此，我們的批流一體存儲方案，不僅要解決上述痛點，還需要具備以下基本能力：支持離線回溯場景的分區(qū)并發(fā)更新，且數(shù)據(jù)讀寫吞吐量不低于Hive。對于流式場景的流批處理，需要滿足低延遲的要求，數(shù)據(jù)延遲約為幾秒鐘，并能夠提供高吞吐量以支持千萬級RPS。此外，我們還需要提供支持Exactly-once和At-least-once數(shù)據(jù)一致性語義的功能。為了實現(xiàn)整體的流批一體的目標(biāo)，還需要支持多引擎，例如Spark、Flink的讀寫，同時也需要支持多種OLAP引擎進行查詢。

二、設(shè)計方案

接下來看一下我們的流批一體存儲方案，結(jié)合剛剛討論的流批一體存儲目標(biāo)，我們發(fā)現(xiàn)現(xiàn)有的基于數(shù)據(jù)湖倉一體的架構(gòu)，實際上已經(jīng)可以滿足大多數(shù)要求了。當(dāng)前數(shù)據(jù)湖倉一體的架構(gòu)已經(jīng)支持所有數(shù)據(jù)入湖，并支持Spark、Flink引擎，同時也可以進行離線和實時的數(shù)據(jù)操作。在下游數(shù)據(jù)應(yīng)用方面，數(shù)據(jù)湖倉一體的架構(gòu)還支持ihook、metastore、adhoc等OLAP查詢方式。在字節(jié)內(nèi)部使用的場景中，業(yè)務(wù)會通過Flink實時將數(shù)據(jù)入湖，使用Spark批量回溯更新湖內(nèi)的數(shù)據(jù)，并且下游會使用Presto查詢服務(wù)來觸及下游的看板。因此，我們信息湖倉庫主要使用了Hudi這樣的開源方案。在功能方面，數(shù)據(jù)湖倉庫基本符合了實時和離線數(shù)倉對于流批一體存儲的需求，而這主要是因為Hudi本身提供了事務(wù)支持，我們在內(nèi)部還進行了桶索引機制的優(yōu)化以進一步提高入湖的性能，并且通過metastore的元數(shù)據(jù)服務(wù)來支持并發(fā)寫入功能。此外，Hudi原生支持多引擎，因此既可以對批流進行讀寫消費，也可以使用Presto進行交互式分析。

在內(nèi)部，湖倉一體架構(gòu)大規(guī)模地落地了離線的數(shù)倉場景和部分近實時的數(shù)倉場景。但是因為 Hudi 本身的或者數(shù)據(jù)庫本身分鐘級別的可見性，它還是沒有辦法做到實時數(shù)倉存儲的標(biāo)準(zhǔn)方案。

為了解決時效性的問題，提供低延遲的能力，我們內(nèi)部自研了基于內(nèi)存的服務(wù)，它構(gòu)建于數(shù)據(jù)湖之上，形成了一套整體的高吞吐、高并發(fā)、低延遲的實時數(shù)據(jù)服務(wù)方案。底層方案的整體架構(gòu)如圖所示。底層是持久化數(shù)據(jù)層，會復(fù)用Hudi當(dāng)前的能力持久化數(shù)據(jù)，文件分布跟 Hudi一致，通過 log 的行存文件和 base 的列存文件進行數(shù)據(jù)存儲，會通過 file slice 這種基于時間戳的方式去維護數(shù)據(jù)的版本信息，通過 file group 這樣的方式去對文件進行分組，相同組件的數(shù)據(jù)會存儲在同文件組內(nèi)。這種文件變分組的方式，再結(jié)合索引的能力，能夠有效地提升數(shù)據(jù)入湖的性能和查詢的性能。

上層服務(wù)層主要分為兩個組件， BTS 和 Table Service Management。BTS 是基于內(nèi)存構(gòu)建的服務(wù)層，它主要是來解決實時場景下數(shù)據(jù)讀寫的時效性的問題，通過內(nèi)存去對數(shù)據(jù)讀寫進行加速，TSM (Table Service Management)，是表優(yōu)化的服務(wù)，它會異步地去執(zhí)行一些表優(yōu)化的操作，從而實現(xiàn)對查詢的加速。

這里的表優(yōu)化操作指的包括社區(qū)原生的壓縮聚合 clustering，以及一些索引異步構(gòu)建，視圖異步構(gòu)建的一些操作。壓縮聚合指的是對日志文件和基礎(chǔ)文件進一步合并以生成新的列式存儲文件，這樣對整體查詢效率而言更優(yōu)。而 clustering 則是合并小文件以減少文件開銷。當(dāng)前 TSM 只支持這兩種能力以及清理能力，我們計劃結(jié)合社區(qū)現(xiàn)有的 MDT 能力來異步構(gòu)建多級索引，以提升交互式查詢的性能。

表優(yōu)化操作是一個完全異步的過程。這部分是我們自主開發(fā)的服務(wù)，因為一些社區(qū)原生實現(xiàn)并沒有做到完全異步。為什么要異步呢？因為 compaction 和 clustering 的執(zhí)行時間比較長，同步操作會影響數(shù)據(jù)湖的寫入速度，特別是在實時場景下不可接受。而社區(qū)的異步操作僅指寫入時不阻塞，但是 compaction 會共享寫入資源在同一個應(yīng)用程序內(nèi)執(zhí)行。這可能會影響寫入作業(yè)的穩(wěn)定性，因此我們在內(nèi)部落地過程中發(fā)現(xiàn)了這個問題，最后實現(xiàn)了一個完全異步的調(diào)度執(zhí)行，同時不共享寫入資源的服務(wù)。在具體的執(zhí)行層面上，我們還利用混部的資源以降低成本。

1、數(shù)據(jù)組織形式

基于這樣的新的流批存儲架構(gòu)，我們新增了中間的服務(wù)層，特別是BTS這樣的實時元數(shù)據(jù)加速層，整體的數(shù)據(jù)組織形式如下圖所示。數(shù)據(jù)組織形式在邏輯層分為表分區(qū)、文件組和文件大小等概念。數(shù)據(jù)寫入時，先寫入對應(yīng)分區(qū)，再根據(jù)主鍵寫入對應(yīng)文件組。文件組的底層文件存儲分為內(nèi)存數(shù)據(jù)和分布式文件系統(tǒng)數(shù)據(jù)兩種類型。在內(nèi)存中，數(shù)據(jù)由塊構(gòu)成，而在分布式文件系統(tǒng)中，數(shù)據(jù)的組織形式與Hudi相似，采用基礎(chǔ)文件和日志文件的模式。值得注意的是，我們引入了日志存儲層來存儲WAL文件，以確保數(shù)據(jù)在寫入過程中的有效性，并解決內(nèi)存數(shù)據(jù)丟失的問題。因此，在寫入內(nèi)存數(shù)據(jù)之前，我們會先寫入WAL文件，確保這部分數(shù)據(jù)已被持久化存儲，實際操作才被認為是成功的。對于內(nèi)存文件塊與持久化存儲文件之間的映射關(guān)系，每個塊對應(yīng)一個WAL文件以保證數(shù)據(jù)的容錯性。每個內(nèi)存中的塊都不會永久存儲在內(nèi)存中，而是定期地刷到持久化存儲文件中。在實際操作中，多個塊通常對應(yīng)一個日志文件。

2、數(shù)據(jù)讀寫方式

再來看一下整個數(shù)據(jù)讀寫的交互方式。首先，做了流批復(fù)雜的分離，因為流場景和批場景對于數(shù)據(jù)的可見性和時效性的要求是不完全一致的。對于批量回溯的場景，用戶并不是希望能夠馬上可見，只是希望把這部分數(shù)據(jù)做好更新和校準(zhǔn)而已。

在批量數(shù)據(jù)更新的場景中，數(shù)據(jù)會直接寫入持久性存儲中，也就是會寫入到HDFS上，而不是通過內(nèi)存。這種方法可以極大地提高我們的讀寫吞吐量。對于流式讀寫的情況，會首先訪問BTS之類的內(nèi)存服務(wù)進行讀寫。這里的主要實施細節(jié)是，在寫入數(shù)據(jù)時，我們會優(yōu)先寫入內(nèi)存中，會首先寫WAL文件以保障容錯。在讀取數(shù)據(jù)時，由于內(nèi)存中的數(shù)據(jù)不會一直存在，因為cache會定期清理，所以讀取時會優(yōu)先訪問內(nèi)存中的數(shù)據(jù)。如果發(fā)現(xiàn)內(nèi)存中沒有數(shù)據(jù)，我們會先加載WAL文件并對其進行預(yù)加載，以盡可能地將數(shù)據(jù)優(yōu)先加載到內(nèi)存中，以保證流式讀取的時效性。如果發(fā)現(xiàn)WAL文件也不存在，或者被清理了，那么我們就會轉(zhuǎn)而去讀取持久性存儲中的日志。在大多數(shù)情況下，這是流式讀寫，整個周期相對較短。因此，在內(nèi)存中，WAL文件的存儲能夠做到一周之內(nèi)的時效性。一周之內(nèi)的用戶都可以正常從內(nèi)存中消費這部分數(shù)據(jù)。如果用戶希望存儲長周期的數(shù)據(jù)，那么他可能需要承擔(dān)更多的存儲成本。我們需要盡可能避免從HDFS上加載日志文件，這是整體的數(shù)據(jù)讀寫方式。

3、BTS架構(gòu)

剛剛提到的流讀的場景，我們也做了讀寫的負載分離，會有單獨的讀集群去承接整體的讀流量，來避免它影響寫入節(jié)點的性能。我們來看一下整體的BTS架構(gòu)，BTS首先是Master-Slave架構(gòu)。Master主要負責(zé)一些元數(shù)據(jù)信息的管理，它的結(jié)構(gòu)與HDFS相似。Table Server以Slave的形式存在，負責(zé)數(shù)據(jù)的讀寫，并在其上存儲由若干個block組織而成的文件。對于Master，它管理的元數(shù)據(jù)包括Table Server的信息以及block的元數(shù)據(jù)管理。由于元數(shù)據(jù)管理的需要，它必然會引入一定的負載均衡機制。因此，我們目前實現(xiàn)了比較簡單的負載均衡機制，旨在避免某一Table Server內(nèi)存被打爆的情況。

Table Server主要提供數(shù)據(jù)讀寫能力，維護本地的塊并定期進行塊清理。它異步將某些塊刷新到HDFS上，整個數(shù)據(jù)讀寫流程是客戶端請求master，獲取需要寫入的塊，然后找到對應(yīng)的Table Server進行數(shù)據(jù)寫入。在寫入時，它優(yōu)先寫WAL文件，再寫內(nèi)存文件。當(dāng)數(shù)據(jù)全部寫入并ACK返回后，表示這批數(shù)據(jù)已經(jīng)成功寫入，不會再丟失。此時涉及到數(shù)據(jù)提交問題。這部分統(tǒng)一由主節(jié)點master去管理事務(wù)，其整體的事務(wù)機制與Hudi目前的實現(xiàn)相似，即依托于引擎進行提交。對于Flink來說，每次checkpoint都會觸發(fā)主節(jié)點進行提交。因此，當(dāng)下游消費這批數(shù)據(jù)時，如果我們需要達到秒級數(shù)據(jù)，則不太可能進行秒級信息源數(shù)據(jù)的提交。因此，在這部分下游可能會讀取一些基于read on committed的數(shù)據(jù)，所以需要進行去重操作，以確保At least once的語義。以上就是整體的BTS結(jié)構(gòu)的介紹。接下來介紹落地場景。

三、落地場景

我們的主要落地場景是流式數(shù)據(jù)計算，它類似于離線數(shù)倉，需要進行一些ETL清理和簡單的聚合計算。左側(cè)是整體架構(gòu)方案，我們使用了基于Hudi加BTS的數(shù)據(jù)湖方案來替換MQ，從而實現(xiàn)每一層數(shù)據(jù)表的存儲。在維表上，我們目前仍使用KV存儲。我們當(dāng)前的目標(biāo)是替換MQ場景。

原先離線需要將實時表從 MQ dump 成 Hive，去進行后續(xù)的離線數(shù)倉的相關(guān)工作。切換成這套方案后，dump 操作就可以省掉，能夠做到流批的數(shù)據(jù)復(fù)用的能力來減少整體的中間存儲的成本。

第二個場景是多維分析場景，其特點是實時數(shù)據(jù)清洗后直接支持看板等實時的OLAP查詢。基于批流一體方案結(jié)合 Presto 查詢來滿足業(yè)務(wù)側(cè)分鐘級時延訴求，和秒級查詢響應(yīng)訴求。我們團隊針對Presto進行了許多優(yōu)化，包括native engine等相關(guān)技術(shù)，以實現(xiàn)高性能查詢。目前，該場景也在現(xiàn)場落地，并取得了不錯的收益。另外，因為整體的流批是數(shù)據(jù)表，存儲是統(tǒng)一的，所以不需要額外將其轉(zhuǎn)儲為Hive表，也不需要維護離線存儲的快照。

第三個場景就是批流復(fù)用的日志場景，一般大家直覺上會從 ODS 層切換做批流復(fù)用，字節(jié)內(nèi)部，在實時場景會先對接埋點數(shù)據(jù)， Flink 端去做清洗，落到實時的存儲里面，然后對接看板等下游。在離線數(shù)倉上，也會將所有埋點信息存儲下來，根據(jù)具體的業(yè)務(wù)場景落成不同的 ODS 表，再去構(gòu)建離線數(shù)倉的任務(wù)。

當(dāng)我們整體把存儲換成 LAS 這套方案之后，只需要維護 ODS 層的數(shù)據(jù)，就能支持離線和實時兩個的場景去進行分析。

最后是飛書數(shù)倉的場景落地，整體鏈路比較清晰，分為實時和離線兩個鏈路，這里離線實時鏈路主要是去做一些人事信息變更之類的業(yè)務(wù)。離線鏈路主要是對一些長周期的問題去做一些數(shù)據(jù)的修正，把這部分修正的數(shù)據(jù)回補到我們的實時鏈路里面，讓下游的看板數(shù)據(jù)變得更準(zhǔn)確。

在實時數(shù)據(jù)傳輸和離線數(shù)據(jù)處理兩個環(huán)節(jié)中，我們都采用了LAS之類的存儲來替換底層存儲。離線數(shù)據(jù)處理要求數(shù)據(jù)的處理時間在10-15分鐘內(nèi)完成，因此用戶更慣用Spark處理離線數(shù)據(jù)處理環(huán)節(jié)。針對此，我們提供了基于Spark Thrift Server的解決方案，以減少離線數(shù)據(jù)處理中每個環(huán)節(jié)的資源申請開銷，維持常駐資源，讓用戶運行SQL來構(gòu)建離線數(shù)據(jù)處理模塊。

在實時數(shù)據(jù)傳輸環(huán)節(jié)中，用戶原本采用Kafka構(gòu)建基礎(chǔ)表并使用Hbase進行維表構(gòu)建。因為Hbase對聯(lián)合主鍵的支持并不友好，用戶每次在讀寫時都需要去序列化和反序列化主鍵列，并將復(fù)合主鍵拼裝成單一主鍵，最后將其寫入Hbase中，然后再從Hbase中讀取。這樣的流程很復(fù)雜，且時間耗時較長。

那么除了替換之外，就像之前提到的一樣，我們會替換掉MQ或Kafka這樣的組件，并且我們還用其他存儲替代了Hbase。我們的主要目標(biāo)是實現(xiàn)基于Flink的lookup join功能，并將小表直接加載到內(nèi)存中，以提高lookup join的性能。因此，在實時鏈路這一塊，我們已經(jīng)替換了所有的存儲組件。

四、未來規(guī)劃

最后分享一下未來規(guī)劃。首先，我們會探索更多業(yè)務(wù)場景，大規(guī)模落地更多模式。其次，在技術(shù)迭代方面，我們會對負載均衡和分離做出優(yōu)化。負載分離在BTS內(nèi)部（即內(nèi)存服務(wù)內(nèi)部）會針對一些小組件進行優(yōu)化，比如將WAL文件刷入持久化存儲（如HDFS），這部分資源占用比較高，需要分離處理。另一方面，我們會更加細致化地對讀寫負載分離和內(nèi)存服務(wù)負載均衡進行優(yōu)化。此外，我們還會實現(xiàn)更精細的流批負載分離。第三點是查詢優(yōu)化，我們會結(jié)合索引的能力，在內(nèi)存層和整體存儲方案中通過構(gòu)建索引優(yōu)化塊的數(shù)據(jù)結(jié)構(gòu)來加速查詢性能，包括點查和聯(lián)合查詢等。最后一點是與native engine的集成，以提升整體的讀寫速度。在這方面，我們需要對底層的log、block和parquet文件進行向量化處理。

五、Q&A環(huán)節(jié)

Q：Hudi支持流式的寫入與更新，那Kafka 是否可以被取代了？

A：我不確定是指社區(qū)的Hudi還是我分享的Hudi。所以我談一下我分享的整套方案，但我認為我們目前在某些方面還有欠缺。比較困難的是如何實現(xiàn)Kafka的exactly once語義。

Q：LAS支持的組件索引和二級索引是什么樣的索引結(jié)構(gòu)？

A：實際上，這部分主要是社區(qū)原生實現(xiàn)，包括我們內(nèi)部的實現(xiàn)也大部分已經(jīng)貢獻到社區(qū)了。就組件而言，社區(qū)實現(xiàn)是基于哈希去進行分桶，并同時記錄一些布隆過濾器（Bloom filter）。關(guān)于二級索引，社區(qū)目前正在進行迭代，但并沒有完全合入。

Q：使用 BTS 可以加速 Flink 寫入 Hudi 的性能嗎？

A：會。時效性提升很多。因為第一個是我們寫內(nèi)存，第二個是整個數(shù)據(jù)結(jié)構(gòu)會相對 Hudi 來說會比較輕量一些。

Q：BTS 與 Hudi分別適用的應(yīng)用場景。BTS 與Hudi的具體關(guān)系。

A：首先對于我們來說，我們整體的這套方案叫LAS， LAS 底層是基于 Hudi 去做的實現(xiàn)，為了支持流批一體存儲，我們在Hudi上加了一層內(nèi)存緩存層BTS，結(jié)合查詢引擎，一整套方案稱之為 LAS。因為 BTS 是基于 Hudi 上架了一層，所以 BTS 整體的邏輯會跟 Hudi 強相關(guān)，它我兩者之間的交互主要就是內(nèi)存文件到持久化存儲中間的一些交互，其他的大部分的設(shè)計會沿用Hudi的部分的邏輯，比方說我們會通過TSM, Table Service Management.去做一些比較優(yōu)化的服務(wù)，比方說 Hudi 的compaction， BTS 的 WAL 的clean，就這些操作。

Q：LAS怎么保證查詢數(shù)據(jù)的準(zhǔn)確性？

A：我們當(dāng)前支持的語義是 At least once，就是說首先用戶能夠在數(shù)據(jù)里面加業(yè)務(wù)字段來判斷哪條數(shù)據(jù)是最新的At least once，但是這條數(shù)據(jù)有可能會被寫入多次，所以用戶下游需要做一些去重的操作。BTS 數(shù)據(jù)怎么保證一定是寫進來的？首先我們會寫 WAL 文件，就是 WAL 文件是持久化存儲上的文件，當(dāng)文件寫完之后我們才會，我們會一邊寫 WAL文件一邊寫內(nèi)存的數(shù)據(jù)，只有寫到 WAL 文件才會寫內(nèi)存的數(shù)據(jù)，那整體都完成了之后才會返回給 client ACK，否則， client 會認為這次提交失敗了，會重新去往里寫，所以整體上一致性是不會有太大的問題的。