一、湖倉一體技術誕生的背景和現狀

1.湖倉的演進

1）數據倉庫（90s）

需要進行數據處理的公司在湖倉演進的架構選擇上都十分相似。起初，首選方式是數倉架構，比如teradata 、greenplum或Oracle等。通常數據處理的流程是把一些業務數據庫，如Transactional Database等，通過ETL的方式加載到Data Warehouse中，再在前端接入一些報表或者BI的工具去展示。

自Bill Inmon提出數倉概念以來，從90年代的美國到國內，數倉架構一直是一個比較經典的架構，它可以高效處理結構化的數據，而且性能好、速度快。尤其是teradata，它是存算一體的架構。

但是隨著業務類型增多，我們需要擴展更多的業務場景，如數據科學或機器科學領域等。數據類型和數量也隨之增多，結構化數據在互聯網領域只占很小的一部分，還有很多半結構化、非結構化的埋點日志和音視頻數據等。

我們的數倉已經無法處理更多數據，一些新技術，尤其是開源等多個領域的大數據技術開始涌現。

2）數據湖——數倉兩層架構（10s）

我們逐漸將架構劃分為數倉和數據庫的雙層架構，把數據先加載到數據湖中，通常我們會選擇Hadoop數據庫作為自建數據湖。如果要做高效的查詢或者報表的輸出，我們會對數據再加工，放入高性能的數倉中，如ClickHouse或Doris等。

大概從2010年開始，隨著Hadoop的盛行，絕大多數互聯網公司都在用這樣的架構。大家如果使用過Hadoop，相信也能感知到它可以支持各種不同的場景，基本上能夠滿足所有業務場景。

缺點：

• 在效率方面存在較大缺陷，比如數據要來回導，以ETL或者反向ETL的方式導進導出，會出現多份；
• 一致性很難保證。

3）倉、湖、流——孤島式架構（15s）

這個架構整體偏離線處理，隨著流式框架的引入，大公司整體的數據處理架構在2015年后就變成了倉、湖、流三種架構。

根據不同的場景選擇不同的架構，比如我要做一些Ad-hoc的場景，我們會選擇在倉里面進行；如果要做一些定時的報表或業務報表，則用Spark；如果想要做一些流式數據的查詢和分析，則可以用Flink之類的工具。

這個架構存在幾個問題：

• 一致性：數據分成了三路，彼此之間天然割裂，在這種割裂的情況下，一致性是一個大問題。如果大家在公司里做一些數據處理的架構如Lambda架構等，流和批數據的對齊是一個繞不開的問題，因為數據是多份的，本質上仍是一致性問題。
• 受限的進階分析：如果我們在湖上做數據分析，我們缺乏一些更高階的分析能力，比如更新、快照、ACID等語義存在缺失。
• 數據成本：每一個通路的底層存儲不同，計算也不一樣，因為計算需要對應的存儲來決定計算的性能，所以我們需要拷貝多份數據，成本也隨之上升。

2.解決之道——湖倉一體

大概于20年左右提出了湖倉一體的架構，試圖用一個統一的湖上建倉或湖倉一體的存儲架構，解決數倉和數據庫的問題。

針對傳統意義的數據湖，若在對象存儲或者Hadoop上能夠構建出具備數倉語義的一個格式，使得我們在湖上的格式有更強的能力去做數倉，則需要具備幾個條件：

• 湖上可靠的數據管理：即需要一種開放的高性能的數據組織方式。采用傳統方式定義表時，缺乏一種高效的表的組織方式。我們通常用 Hive表，它就是一個目錄，沒有特殊的能力。我們需要一種更高效的組織能力，兼顧一些倉的特性。
• 支持機器學習和數據科學：湖倉一體的技術需要有一套開放的標準或者開放的接口。大家在用數倉的時候，會發現它是存算一體的數倉，存儲就是為了計算所定制。雖然性能很好，但不開放，也就是所有的生態都要建立在上面，但數據湖則是天然開放，Flink和Spark等其他引擎都能使用這些數據。
• 最先進的SQL性能：若湖倉一體只是湖，那么很輕易就能辦到，但是它的性能會比較差。如果要使表具備倉的性能，比如能夠匹敵類似Snowflake或者Redshift這樣的性能，則需要一個高性能的SQL引擎，這也是Databricks做了Photon引擎的原因，有了這些，我們就可以真正在湖上構建出一個高性能的數倉，也就是“湖倉一體”。

3.三種主流開源技術

前文講述了湖倉一體技術所要具備的幾個特性，如今在開源領域主要有三種技術擁有這些特性，分別是：Hudi、Iceberg和Delta Lake。

它們的功能整體上比較接近，都是一種數據的組織方式，即定義了一種表的格式，這個格式主要是定義數據的組織方式，而不是確定一種數據的存儲格式。與一些純粹的數據格式或Hive表（Hive 3.0版本前）相比，它提供了ACID事務能力，這樣就具備了倉的能力，它可以提供一些事務的特性和并發能力，還可以做行級數據的修改、表結構的修改和進化，這些都是傳統大數據格式難以完成的事項。湖倉一體技術出現后被業界迅速采用，從21年開始就進入了Gartner技術成熟度曲線的評估。

4.湖倉一體技術的優勢

• 優化數據入湖流程：相比傳統的成熟形態，比如T+1的入倉形態或者入湖的形態，它可以用T+0的高效的流式入湖形態，大大降低了數據的可見時延。
• 支持更多的分析引擎：它是開放的，所以能夠支持很多引擎。我們內部也對接了很多不同的引擎，包括Flink、Spark 、Presto和StarRocks等。
• 統一數據存儲和靈活的文件組織：采用比較靈活的文件組織方式，具備了一些額外的特性，使得流和批都可以用這種文件組織方式進行消費。
• 增量讀取處理能力

5.湖倉一體落地場景

1）加速數據入湖

下圖左側是我們一個舊的數據管道。舉個例子，要收集一些Spark的審計日志以觀察每天的情況，那么我們就可以把Spark日志都導入到消息隊列中。在騰訊內部使用的是TubeMQ，然后我們有一個服務TDSort用于歸檔，把數據按照小時或者天的時間格式分類，緊接著保存至HDFS上，再啟動一個Hive的命令，把它添加到分區內。

前面是通過流式進入，后面是批的落盤，整體設計比較復雜。為了保證exactly-once以及保證流轉批的可見性，我們在原子性上花了很多心思，因為在原先的架構上我們缺乏事務的能力，所以我們通常依賴HDFS的原子性來保證可見性。

之后我們把整體架構遷到了以數據湖格式為體系的另一套架構中，選擇用Flink來做流式的入湖，把它寫到HDFS上，這樣整體鏈路就變得更為簡單。對于Flink寫下的數據，我們主要選擇的是Iceberg，在Flink讀取把它寫到Iceberg中，下游就能直接可見。

至此，原先T+1的可見性就變成T+0，這個是最典型、最常見的一種使用方式。這也是我們內部像廣告和視頻號等業務的主要使用方式，把小時級的數據可見性降低到分鐘級的可見性。

2）構建CDC Pipeline

CDC在騰訊內部不算是非常大的場景，但原本通過拉鏈表方式去構建，會帶來一些問題：一是延遲，二是后續的處理流程非常復雜。

我們現在改成了另一種方式，使用Flink的CDC Connector，再加上Hudi。因為針對CDC而言，Hudi在這方面的能力比Iceberg更成熟，所以選用Hudi而不是Iceberg。

有兩種方案，一種方案是直連MySQL或PostgreSQL等類似的數據庫，另一種是通過消息隊列的方式，通常都是使用第一種方式，這也是比較常見的一種內部形態，與前面相比Flink CDC connector與MySQL直連獲取binlog。

3）近實時的流批一體架構

在業務側使用整套湖倉一體技術后，從原先的Lambda架構轉換成了湖倉一體的架構。在原先的架構中，流和批分離，流主要是用消息隊列來做流式的Pipeline的構建，還有一條離線鏈路做數據的回補和對賬等。但是離線存在于HDFS上，這樣就會導致兩條鏈路要做同一份數據的處理。

使用湖倉一體就相當于把它們合并，我們在ODS、DWD或者DWS層統一用Iceberg來進行流式寫入。在流式寫入后，可以在每一層中做離線或者批的分析，也可以一直做流式分析，因此同一份數據既做到了流式的讀和寫，又做到了批的讀和寫，一份數據就可以適配整個場景，不需要存多份數據或者接多條ETL Pipeline。這就是我們比較典型的一個架構，騰訊視頻也是在這個架構基礎上做演進。

4）更好的Hive表

回到湖倉一體的本質，即使我們不需要上述的特性，相比傳統的Hive表，它也帶來了很多新的特性和能力。用于取代離線的場景化，也會有更好的效果。

數據治理：

• 支持表結構進化：Hive的其中一個特性就是分區，在建表的時候就需要指定分區字段，同時在查詢時也必須加上分區的過濾條件，否則它有可能去查所有的分區，造成大量數據的誤讀取。分區一旦定下來就很難變動，但Iceberg是隱式的分區，通過它的表達式來做分區的映射和轉換，就可以對分區做出調整，比如原先是按月來分區，你可以把它更改成按天分區。
• 支持行級數據的修正：原先Hive表的一個常見思路是用覆蓋寫的方式，要做數據修正時就要覆蓋一個分區，但你可能只有一行數據需要調整。湖倉一體的格式提供了行級的修正能力。提供兩種修正，一種是Copy On Write的修正，還有一種是Merge On Read的修正，降低了修正的代價，大大提高了它的實時性。

數據查詢：

• ACID能力：Hive依靠HDFS的原子性來保證它的可見性。比如你Insert到多個分區時，Insert涉及到跨多目錄復制，則無法原子性，這時你一邊 Insert一邊去查詢的時候就會讀到臟數據，Iceberg、Hudi都是通過快照機制進行查詢，快照只有被commit了以后才可見，所以這時并發地讀和寫數據，不會出現任何問題。
• 高效的data skipping能力：像這種新的表格式，它會增加一些額外的能力，比如z-ordering的data skipping的能力，使得你能更高效地做多維數據分析。即使沒有實時的需求，只想替換Hive表，那么用湖倉一體這些新的表格式也能給你帶來更好的效果。

二、湖倉一體技術現存的問題

1.湖倉一體內核的性能

隨著湖倉一體實踐的逐漸深入，尤其是當單鏈路的數據量達到分鐘級，每日達到萬億規模時，湖倉一體的性能問題就要格外重視。

1）數據治理問題

• 海量小文件：我們主要用Iceberg，它每次commit時都會生成大量文件，你要求的commit時間越短，它的小文件就會越多，幾天過去，這張表的小文件數可能達到幾百萬，甚至上千萬，這個時候再去查詢，Query Plan就會跑不動，變得非常慢。
• Query Plan時延：Iceberg保存了多副本，每一次commit都會產生一個元數據的快照，快照里面包含了很多信息，元數據的數量將越來越大。如果未做一些元數據的清理或者合并，那么只是生成執行計劃就需要大量耗時。我們內部的廣告系統在使用，它是一個復雜類型，大概有幾千列的表結構的查詢和嵌套類型的復雜字段。Iceberg未優化的時候，Query Plan甚至要十幾分鐘。

2）查詢性能問題

• 平衡讀寫性能：寫和讀的對于性能的要求不同，如何能夠平衡寫和讀是非常重要的一個問題。
• 發揮極速性能：Iceberg和Hudi很多高階的特性，比如索引之類，我們內部也進行了大量建設。

3）流批一體

批處理希望能夠有更多的數據塊聚合在一起讀取，做到更多樣、更大的吞吐，流則需要更快的響應。

2.湖倉一體技術的實時性限制

拋開內核，無論是Iceberg還是Hudi，本質上都是海量文件的組織方式，無法擺脫存儲的限制，我們通常會把它存到內部的HDFS上，云上則會存到對象存儲中。但對象存儲也有它的限制，吞吐量較大，但延遲會較高。

如果需要流讀，我們通常在構建實時鏈路的時候，會選擇消息隊列，它的存儲模型完全不同，是低延遲高響應，順序讀寫。它的存儲能力決定了計算，流式計算的訪問方式和離線計算的訪問方式不同。

這個時候就會出現兩個問題：

• 如何平衡流式的訪問和批的訪問？既能做到高性能和高效，又能做到低成本？
• 傳統的Iceberg和Hudi，實現分鐘級已經接近極限，如果繼續加速該如何優化？

三、騰訊在湖倉一體上的工作

1.內核優化

1）功能優化

• 大寬表支持：主要針對廣告，因為廣告需要不斷加入新的特征，隨著添加的特征越來越多，表就會變得越來越寬。同時，它原來使用PB的格式，所以它有很多嵌套，現在把它轉成Iceberg，就變成了一個極大的寬表，無論對于寫入還是查詢，都極具挑戰。
• 跨源查詢支持：因為內部有舊表、新表以及不同的系統，所以需要實現跨源以及高性能的查詢。
• 流轉批：我們絕大多數的鏈路仍是批，為使在流式寫入時下游能夠具有批的可見性，我們增加了Watermark機制來進行流轉批。
• 流式寫入支持去重、增量讀取、流量控制：我們不斷改進流式寫入能力，尤其是對于在Iceberg上做CDC的寫入，部分列的更新等，做了很多改進。

2）性能優化

• 元數據讀取加速， 引入Alluxio：引入Alluxio，把元數據緩存在Alluxio上，加速它的訪問，對并行的元數據的Query Plan、壓縮格式等也做了一些調整，實現加速；
• 復雜類型列剪支優化， 基于列信息任務切分優化；
• V2表layout改進與合并加速；
• 向量化，Async-IO，CBO等查詢加速。

總體來看，設計出這些特性后，測試數據顯示，我們內部的TDW與Spark相比，性能大大提升。

2.二級索引

Snowflake或者Redshift之所以那么快，很重要的一點是因為它有索引，但我們傳統的Hive表幾乎沒有索引。Iceberg具備了構建索引的能力，也具有ACID能力，而且它的表結構也更復雜，所以我們能夠構建索引。

具體成果：1）引入一個索引框架；2）構建了不同類型的索引。

我們做的是全局索引，針對每個Data File生成對應的Index File。Index file與datafile綁定，內部有一套系統會異步更新或者生成Index。我們選擇Puffin作為存儲的格式，它是Iceberg定義的一種Index的存儲格式。我們也改造了一定的語法，使得它能夠支持索引的生成。

整體完成后，我們有一個點查的場景，bloom filter就比較適合點查的場景，速度與原來相比有一個數量級的提升。

3.流批一體的實時湖倉架構

我們在使用湖倉一體技術的時候，流式的性能已無法實現突破，因為受制于底層的存儲，使用HDFS或者對賬存儲則缺乏更低的延時，所以我們也在參考社區的方案。

Flink社區提供了一個Flink Table Store的方案，把流存儲和批存儲融合為一體，現在改了名字，叫做Paimon，我們參考其做了類似的方案。在這個方案中，流和批選擇了不同的存儲，流選擇使用消息隊列，批則是底層使用數據湖的格式，封裝在一起就成為了流批表。有了流批表，則能夠對外提供統一的流和批的讀寫接口。

我們主要是對接Flink的場景，寫的時候我們會雙寫到LogStore和Filestore這兩個系統中，根據不同的場景讀不同的系統。如果是流式則讀LogStore，批則讀Filestore。

優點：

• 引擎和表的流批一體，降低業務架構復雜度：存儲在形態上可以看成近似的統一體，未來也希望能實現真正的統一。
• 屏蔽流批差異，統一SQL操作：我們把Flink和流批對接后，就可以在Flink上提供流和批的處理能力，只需要使用同一套引擎。
• 提升時效性，兼顧流式和湖倉：因為流寫到了消息隊列中，所以流的性能提高，速度加快，能實現秒級的時效性。

4.自動數據治理

我們引入了自動數據治理的概念，它與傳統的數據治理方式的區別在于它基于事件驅動，而不是基于時間定時完成。其具備以下能力：

• 做文件的聚合，包括排序聚合和zordering聚合；
• 可以做行級或者列級的生命周期的管理；
• 自動的索引、緩存和排序等。

具體的運作步驟：它會在Iceberg的存儲中收集一些事件，根據事件分析當前要進行的操作，然后根據規則來生成這些操作。

1）小文件合并

在做小文件合并時，如何生成這些規則？

傳統意義上的小文件合并，通常來會設定一個時間點，比如每隔一小時或者每隔一天做一次，但這樣會產生很多無效的作業。若你的寫入很快，那么可能會有大量的堆積，若你寫入很慢，那么就可能有很多無效的合并操作。

我們通過收集每一次commit后寫入的增量，求均方差，判斷當前是否達到閾值。若未到閾值，我們會逐步更新它的均方差。如果達到閾值，就會觸發一個小文件的合并操作，根據事件來驅動。這樣的形式會比先前的方式更能節省資源，效率也更高。

2）自動重分布優化

現在社區也有，但我們更早開始，它主要是能夠做到加速多維查詢，把相關的record歸類放在一起。我們會通過事件收集相關性極高常被查詢的列，自動給用戶推薦可以重排列的數據，并詢問是否需要重排列。當用戶決定重排列，數據就會進行增量，做后續的重排列，這樣就能提高數據整體的有效過濾率。

3）自動索引

我們對Iceberg引入了一個索引框架，支持bloom filter 和 bitmap的構建，但是用戶并不知道如何使用索引。所以我們提供了自動索引的構建能力，會根據查詢的信息分析出哪些列的用戶查詢頻度較高，接下來我們會優先在這些列上構建索引。同時，我們選擇了根據分區的增量來加theta sketch的方式來做增量的索引，而不是每次都做全表索引的重構。構建索引后，Iceberg的常用性能會出現一個大的躍升。

四、后續規劃

我們希望湖倉建設從原先的準實時湖倉向實時湖倉的架構邁進，也希望湖倉一體架構在經過元數據、緩存和索引的優化后，能夠解決交互式查詢和流的所有場景問題，用一套存儲應對所有的場景。這是我們現在在做的事情，也是未來的目標。

Q&A

Q1：前面提及CDC的構建，是按照整庫入倉還是按表的方式來進行？

A1：我們騰訊這邊的量不算大，我們內部主要還是以append方式入湖，CDC則仍是按表的方式來，沒有做太多的優化，也沒有涉及整庫的方式。

Q2：您提到小文件合并，具體的優化是指要另起一個旁路作業，還是指將這部分的功能并入到寫入的流程里？

A2：我們采取離線和異步的方式，因為如果并入到寫入的流程，會對整體寫入造成拖垮或者堆積效應，所以根據我們內部的實踐以及單鏈路1000多億的日均寫入的經驗，同步寫入和合并的這種方案并不可行，所以我們做的是異步方案。

Q3：有些場景會選擇Hudi，另外一些場景選擇Iceberg，請問Iceberg和Hudi的選型依據是什么？

A3：我們八成以上的場景都選擇了Iceberg，因為我們投身及使用Iceberg社區的時間較早，所以對Iceberg的的整體把控會更好。只有涉及CDC的場景，我們才會用Hudi，因為Iceberg當前的CDC能力不夠成熟，但我們也在探索和建設Iceberg的CDC能力，包括全局索引的能力、部分列的更新能力等，也是為了全鏈路CDC所做的優化。如果未來Iceberg具備這樣的能力，我們應該會統一使用Iceberg，因為維護多套系統會增加維護的成本。其實這兩個技術沒有太大差別，只需選擇一種即可，實際上社區的演進最終都會趨同。

Q4：Iceberg上有Spark和Flink等多個引擎，假如我建了一個Iceberg表，可以用Spark和Flink兩種引擎同時訪問底層的表嗎？

A4：可以。因為它有所謂的事務的語義。這也取決于你的鎖如何實現，默認使用比如HiveLock等可以做隔離，所以能夠多引擎地去寫，但會有一定的沖突概率。但針對讀而言，因為Iceberg生成的每一個副本都是只讀的，所以多引擎去讀沒有任何問題。

Q5：數據湖在應用側的使用場景有哪些？

A5：數據湖從20年初引入到現在，在騰訊內部每年至少有10倍以上的規模增長，所以現在幾乎所有的業務線都在使用。最大的業務線一般是視頻號或者廣告之類，也有其他的業務，基本上所有的業務都在用數據湖，無論是用于加速數據的可見性、構建CDC還是用Iceberg替代Hive表的低效查詢，都會帶來一定的性能提升，這些場景前文有所提及。

作者介紹

邵賽賽，前騰訊實時湖倉團隊負責人，現Co-Founder & CTO of Datastrato。Apache基金會成員，Apache Spark Inlong Livy PMC成員，曾就職于Hortonworks、Intel，10年的大數據從業經驗，專注于分布式流批計算引擎的研發和優化。