簡(jiǎn)介：?阿里云技術(shù)專家李少鋒(風(fēng)澤)在Apache Hudi 與 Apache Pulsar 聯(lián)合 Meetup 杭州站上的演講整理稿件，本議題將介紹典型 CDC 入湖場(chǎng)景，以及如何使用 Pulsar/Hudi 來構(gòu)建數(shù)據(jù)湖，同時(shí)將會(huì)分享 Hudi 內(nèi)核設(shè)計(jì)、新愿景以及社區(qū)最新動(dòng)態(tài)。

本文PPT下載鏈接：

李少鋒(風(fēng)澤) - 阿里云技術(shù)專家-《基于Apache Hudi的CDC數(shù)據(jù)入湖》.pdf

一、CDC背景介紹

首先我們介紹什么是CDC？CDC的全稱是Change data Capture，即變更數(shù)據(jù)捕獲，它是數(shù)據(jù)庫(kù)領(lǐng)域非常常見的技術(shù)，主要用于捕獲數(shù)據(jù)庫(kù)的一些變更，然后可以把變更數(shù)據(jù)發(fā)送到下游。它的應(yīng)用比較廣，可以做一些數(shù)據(jù)同步、數(shù)據(jù)分發(fā)和數(shù)據(jù)采集，還可以做ETL，今天主要分享的也是把DB數(shù)據(jù)通過CDC的方式ETL到數(shù)據(jù)湖。

對(duì)于CDC，業(yè)界主要有兩種類型：一是基于查詢的，客戶端會(huì)通過SQL方式查詢?cè)磶?kù)表變更數(shù)據(jù)，然后對(duì)外發(fā)送。二是基于日志，這也是業(yè)界廣泛使用的一種方式，一般是通過binlog方式，變更的記錄會(huì)寫入binlog，解析binlog后會(huì)寫入消息系統(tǒng)，或直接基于Flink CDC進(jìn)行處理。

它們兩者是有區(qū)別的，基于查詢比較簡(jiǎn)單，是入侵性的，而基于日志是非侵入性，對(duì)數(shù)據(jù)源沒有影響，但binlog的解析比較復(fù)雜一些。

基于查詢和基于日志，分別有四種實(shí)現(xiàn)技術(shù)，有基于時(shí)間戳、基于觸發(fā)器和快照，還有基于日志的，這是實(shí)現(xiàn)CDC的技術(shù)，下面是幾種方式的對(duì)比。

通過這個(gè)表格對(duì)比可以發(fā)現(xiàn)基于日志的綜合最優(yōu)，但解析比較復(fù)雜，但業(yè)界有很多開源的binlog的解析器，比較通用和流行的有Debezium、Canal，以及Maxwell。基于這些binlog解析器就可以構(gòu)建ETL管道。

下面來看下業(yè)界比較流行的一種CDC入倉(cāng)架構(gòu)。

整個(gè)數(shù)據(jù)入倉(cāng)是分實(shí)時(shí)流是離線流，實(shí)時(shí)流解析binlog，通過Canal解析binlog，然后寫入Kafka，然后每個(gè)小時(shí)會(huì)把Kafka數(shù)據(jù)同步到Hive中；另外就是離線流，離線流需要對(duì)同步到Hive的貼源層的表進(jìn)行拉取一次全量，如果只有前面的實(shí)時(shí)流是數(shù)據(jù)是不全的，必須通過離線流的SQL Select把全量導(dǎo)入一次數(shù)據(jù)，對(duì)每張ODS表會(huì)把存量數(shù)據(jù)和增量數(shù)據(jù)做一個(gè)Merge。這里可以看到對(duì)于ODS層的實(shí)時(shí)性不夠，存在小時(shí)、天級(jí)別的延遲。而對(duì)ODS層這個(gè)延時(shí)可以通過引入Apache Hudi做到分鐘級(jí)。

二、CDC數(shù)據(jù)入湖方法

基于CDC數(shù)據(jù)的入湖，這個(gè)架構(gòu)非常簡(jiǎn)單。上游各種各樣的數(shù)據(jù)源，比如DB的變更數(shù)據(jù)、事件流，以及各種外部數(shù)據(jù)源，都可以通過變更流的方式寫入表中，再進(jìn)行外部的查詢分析，整個(gè)架構(gòu)非常簡(jiǎn)單。

架構(gòu)雖然簡(jiǎn)單，但還是面臨很多挑戰(zhàn)。以Apache Hudi數(shù)據(jù)湖為例，數(shù)據(jù)湖是通過文件存儲(chǔ)各種各樣的數(shù)據(jù)， 對(duì)于CDC的數(shù)據(jù)處理需要對(duì)湖里某部分文件進(jìn)行可靠地、事務(wù)性變更，這樣可以保證下游查詢不會(huì)看到部分結(jié)果，另外對(duì)CDC數(shù)據(jù)需要高效的做更新、刪除操作，這就需要快速定位到更改的文件，另外是對(duì)于每小批量的數(shù)據(jù)寫入，希望能夠自動(dòng)處理小文件，避免繁雜的小文件處理，還有面向查詢的布局優(yōu)化，可以通過一些技術(shù)手段如Clustering改造文件布局，對(duì)外提供更好的查詢性能。

而Apache Hudi是怎么應(yīng)對(duì)這些挑戰(zhàn)的呢？首先支持事務(wù)性寫入，包括讀寫之間的MVCC機(jī)制保證寫不影響讀，也可以控制事務(wù)及并發(fā)保證，對(duì)于并發(fā)寫采用OCC樂觀鎖機(jī)制，對(duì)更新刪除，內(nèi)置一些索引及自定義保證更新、刪除比較高效。另外是面向查詢優(yōu)化，Hudi內(nèi)部會(huì)自動(dòng)做小文件的管理，文件會(huì)自動(dòng)長(zhǎng)到用戶指定的文件大小，如128M，這對(duì)Hudi來說也是比較核心的特性。另外Hudi提供了Clustering來優(yōu)化文件布局的功能。

下圖是典型CDC入湖的鏈路。上面的鏈路是大部分公司采取的鏈路，前面CDC的數(shù)據(jù)先通過CDC工具導(dǎo)入Kafka或者Pulsar，再通過Flink或者是Spark流式消費(fèi)寫到Hudi里。第二個(gè)架構(gòu)是通過Flink CDC直聯(lián)到MySQL上游數(shù)據(jù)源，直接寫到下游Hudi表。

其實(shí)，這兩條鏈路各有優(yōu)缺點(diǎn)。第一個(gè)鏈路統(tǒng)一數(shù)據(jù)總線，擴(kuò)展性和容錯(cuò)性都很好。對(duì)于第二條鏈路，擴(kuò)展性和容錯(cuò)性會(huì)稍微差點(diǎn)，但由于組件較少，維護(hù)成本相應(yīng)較低。

這是阿里云數(shù)據(jù)庫(kù)OLAP團(tuán)隊(duì)的CDC入湖鏈路，因?yàn)槲覀兾覀冏鯯park的團(tuán)隊(duì)，所以我們采用的Spark Streaming鏈路入湖。整個(gè)入湖鏈路也分為兩個(gè)部分：首先有一個(gè)全量同步作業(yè)，會(huì)通過Spark做一次全量數(shù)據(jù)拉取，這里如果有從庫(kù)可以直連從庫(kù)做一次全量同步，避免對(duì)主庫(kù)的影響，然后寫到Hudi。然后會(huì)啟動(dòng)一個(gè)增量作業(yè)，增量作業(yè)通過Spark消費(fèi)阿里云DTS里的binlog數(shù)據(jù)來將binlog準(zhǔn)實(shí)時(shí)同步至Hudi表。全量和增量作業(yè)的編排借助了Lakehouse的作業(yè)自動(dòng)編排能力，協(xié)調(diào)全量和增量作業(yè)，而對(duì)于全量和增量銜接時(shí)利用Hudi的Upsert語(yǔ)義保證全增量數(shù)據(jù)的最終的一致性，不會(huì)出現(xiàn)數(shù)據(jù)偏多和偏少的問題。

在Lakehouse的CDC入湖鏈路中，我們團(tuán)隊(duì)也做了一些優(yōu)化。

第一個(gè)是原庫(kù)的Schema變更處理，我們對(duì)接的客戶某些列的增加、刪除或者修改某些列的場(chǎng)景。在Spark寫Hudi之前會(huì)做Schema的檢驗(yàn)，看這個(gè)Schema是不是合法，如果合法就可以正常寫入，如果不合法的話，則會(huì)寫入失敗，而刪除字段會(huì)導(dǎo)致Schema校驗(yàn)不合法，導(dǎo)致作業(yè)失敗，這樣穩(wěn)定性是沒有保證的。因此我們會(huì)捕捉Schema Validation的異常，如果發(fā)現(xiàn)是減少了字段，我們會(huì)把之前的字段做自動(dòng)補(bǔ)全，然后做重試，保證鏈路是穩(wěn)定的。

第二個(gè)有些客戶表沒有主鍵或者主鍵不合理，比如采用更新時(shí)間字段作為主鍵，或者設(shè)置會(huì)變化的分區(qū)字段，這時(shí)候就會(huì)導(dǎo)致寫入Hudi的數(shù)據(jù)和源庫(kù)表數(shù)據(jù)對(duì)不上。因此我們做了一些產(chǎn)品層面的優(yōu)化，允許用戶合理設(shè)置主鍵和分區(qū)映射，保證同步到Hudi里和源庫(kù)是數(shù)據(jù)完全對(duì)齊的。

還有一個(gè)常見需求是用戶在上游庫(kù)中增加一個(gè)表，如果使用表級(jí)別同步的話，新增表在整個(gè)鏈路是無法感知的，也就無法同步到Hudi中，而在Lakehouse中，我們可以對(duì)整庫(kù)進(jìn)行同步，因此在庫(kù)中新增表時(shí)，會(huì)自動(dòng)感知新增表，將新增表數(shù)據(jù)自動(dòng)同步到Hudi，做到原庫(kù)增加表自動(dòng)感知的能力。

還有一個(gè)是對(duì)CDC寫入時(shí)候性能優(yōu)化，比如拉取包含Insert、Update、Delete等事件的一批數(shù)據(jù)，是否一直使用Hudi的Upsert方式寫入呢？這樣控制比較簡(jiǎn)單，并且Upsert有數(shù)據(jù)去重能力，但它帶來的問題是找索引的效率低，而對(duì)于Insert方式而言，不需要找索引，效率比較高。因此對(duì)于每一批次數(shù)據(jù)會(huì)判斷是否都是Insert事件，如果都是Insert事件就直接Insert方式寫入，避免查找文件是否更新的開銷，數(shù)據(jù)顯示大概可以提升30%~50%的性能。當(dāng)然這里也需要考慮到DTS異常，重新消費(fèi)數(shù)據(jù)時(shí)，恢復(fù)期間不能直接使用Insert方式，否則可能會(huì)存在數(shù)據(jù)重復(fù)，對(duì)于這個(gè)問題我們引入了表級(jí)別的Watermark，保證即使在DTS異常情況下也不會(huì)出現(xiàn)數(shù)據(jù)重復(fù)問題。

三、Hudi核心設(shè)計(jì)

接著介紹下Hudi 的定位，根據(jù)社區(qū)最新的愿景，Hudi的定義是流式數(shù)據(jù)湖平臺(tái)，它支持海量數(shù)據(jù)更新，內(nèi)置表格式以及支持事務(wù)的儲(chǔ)存，一系列列表服務(wù)Clean、Archive、

Compaction、Clustering等，以及開箱即用的數(shù)據(jù)服務(wù)，以及本身自帶的運(yùn)維工具和指標(biāo)監(jiān)控，提供很好的運(yùn)維能力。

這是Hudi官網(wǎng)的圖，可以看到Hudi在整個(gè)生態(tài)里是做湖存儲(chǔ)，底層可以對(duì)接HDFS以及各種云廠商的對(duì)象存儲(chǔ)，只要兼容Hadoop協(xié)議接。上游是入湖的變化事件流，對(duì)上可以支持各種各樣的數(shù)據(jù)引擎，比如presto、Spark以及云上產(chǎn)品；另外可以利用Hudi的增量拉取能力借助Spark、Hive、Flink構(gòu)建派生表。

整個(gè)Hudi體系結(jié)構(gòu)是非常完備的，其定位為增量的處理?xiàng)！５湫偷牧魇绞敲嫦蛐?#xff0c;對(duì)數(shù)據(jù)逐行處理，處理非常高效。

但面向行的數(shù)據(jù)里沒有辦法做大規(guī)模分析做掃描優(yōu)化，而批處理可能需要每天全量處理一次，效率相對(duì)比較低。而Hudi引入增量處理的概念，處理的數(shù)據(jù)都是某一時(shí)間點(diǎn)之后的，和流處理相似，又比批處理高效很多，并且本身是面向數(shù)據(jù)湖中的列存數(shù)據(jù)，掃描優(yōu)化非常高效。

而回顧Hudi的發(fā)展歷史。2015年社區(qū)的主席發(fā)表了一篇增量處理的文章，16年在Uber開始投入生產(chǎn)，為所有數(shù)據(jù)庫(kù)關(guān)鍵業(yè)務(wù)提供了支撐；2017年，在Uber支撐了100PB的數(shù)據(jù)湖，2018年隨著云計(jì)算普及，吸引了國(guó)內(nèi)外的使用者；19年Uber把它捐贈(zèng)到Apache進(jìn)行孵化；2020年一年左右的時(shí)間就成為了頂級(jí)項(xiàng)目，采用率增長(zhǎng)了超過10倍；2021年Uber最新資料顯示Hudi支持了500PB數(shù)據(jù)湖，同時(shí)對(duì)Hudi做了很多增強(qiáng)，像Spark SQL DML和Flink的集成。最近字節(jié)跳動(dòng)推薦部門分享的基于Hudi的數(shù)據(jù)湖實(shí)踐單表超過了400PB，總存儲(chǔ)超過了1EB，日增PB級(jí)別。

經(jīng)過幾年的發(fā)展，國(guó)內(nèi)外采用Hudi的公司非常多，比如公有云的華為云、阿里云、騰訊云以及AWS，都集成了Hudi，阿里云也基于Hudi構(gòu)建Lakehouse。字節(jié)跳動(dòng)的整個(gè)數(shù)倉(cāng)體系往湖上遷移也是基于Hudi構(gòu)建的，后面也會(huì)有相應(yīng)的文章分享他們基于Flink+Hudi的數(shù)據(jù)湖的日增PB數(shù)據(jù)量的實(shí)踐。同時(shí)像百度、快手頭部互聯(lián)網(wǎng)大廠都有在使用。同時(shí)我們了解銀行、金融行業(yè)也有工商銀行、農(nóng)業(yè)銀行、百度金融、百信銀行也有落地。游戲領(lǐng)域包括了三七互娛、米哈游、4399，可以看到Hudi在各行各業(yè)都有比較廣泛的應(yīng)用。

Hudi的定位是一套完整的數(shù)據(jù)湖平臺(tái)，最上層面向用戶可以寫各種各樣的SQL，Hudi作為平臺(tái)提供的各種能力，下面一層是基于SQL以及編程的API，再下一層是Hudi的內(nèi)核，包括索引、并發(fā)控制、表服務(wù)，后面社區(qū)要構(gòu)建的基于Lake Cache構(gòu)建緩存，文件格式是使用的開放Parquet、ORC、HFile存儲(chǔ)格式，整個(gè)數(shù)據(jù)湖可以構(gòu)建在各種云上。

后面接著介紹Hudi的關(guān)鍵設(shè)計(jì)，這對(duì)我們了解Hudi非常有幫助。首先是文件格式，它最底層是基于Fileslice的設(shè)計(jì)，翻譯過來就是文件片，文件片包含基本文件和增量日志文件。基本文件就是一個(gè)Parquet或者是ORC文件，增量文件是log文件，對(duì)于log文件的寫入Hudi里編碼了一些block，一批Update可以編碼成一個(gè)數(shù)據(jù)塊，寫到文件里。而基礎(chǔ)文件是可插拔，可以基于Parquet，最新的9.0版本已經(jīng)支持了ORC。還有基于HFile，HFile可用作元數(shù)據(jù)表。

Log文件里保存了一系列各種各樣的數(shù)據(jù)塊，它是有點(diǎn)類似于數(shù)據(jù)庫(kù)的重做日志，每個(gè)數(shù)據(jù)版本都可以通過重做日志找到。對(duì)于基礎(chǔ)文件和Log文件通過壓縮做合并形成新的基礎(chǔ)文件。Hudi提供了同步和異步的兩種方式，這為用戶提供了很靈活的選擇，比如做可以選擇同步Compaction，如果對(duì)延遲不敏感，而不需要額外異步起一個(gè)作業(yè)做Compaction，或者有些用戶希望保證寫入鏈路的延遲，可以異步做Compaction而不影響主鏈路。

Hudi基于File Slice上有個(gè)File Group的概念，File Group會(huì)包含有不同的File Slice，也File Slice構(gòu)成了不同的版本，Hudi提供了機(jī)制來保留元數(shù)據(jù)個(gè)數(shù)，保證元數(shù)據(jù)大小可控。

對(duì)于數(shù)據(jù)更新寫入，盡量使用append，比如之前寫了一個(gè)Log文件，在更新時(shí)，會(huì)繼續(xù)嘗試往Log文件寫入，對(duì)于HDFS這種支持append語(yǔ)義的存儲(chǔ)非常友好，而很多云上對(duì)象存儲(chǔ)不支持append語(yǔ)義，即數(shù)據(jù)寫進(jìn)去之后不可更改，只能新寫Log文件。對(duì)于每個(gè)文件組也就是不同F(xiàn)ileGroup之間是互相隔離的，可以針對(duì)不同的文件組做不同的邏輯，用戶可以自定義算法實(shí)現(xiàn)，非常靈活。

基于Hudi FileGroup的設(shè)計(jì)可以帶來不少收益。比如基礎(chǔ)文件是100M，后面對(duì)基礎(chǔ)文件進(jìn)行了更新50M數(shù)據(jù)，就是4個(gè)FileGroup，做Compaction合并開銷是600M，50M只需要和100M合，4個(gè)150M開銷就是600M，這是有FileGroup設(shè)計(jì)。還是有4個(gè)100M的文件，也是做了更新，每一次合，比如25M要和400M合并，開銷是1200M，可以看到采用FileGroup的設(shè)計(jì)，合并開銷減少一半。

還有表格式。表格式的內(nèi)容是文件在Hudi內(nèi)是怎么存的。首先定義了表的根路徑，然后寫一些分區(qū)，和Hive的文件分區(qū)組織是一樣的。還有對(duì)表的Schema定義，表的Schema變更，有一種方式是元數(shù)據(jù)記錄在文件里，也有的是借助外部KV存儲(chǔ)元數(shù)據(jù)，兩者各有優(yōu)缺點(diǎn)。

Hudi基于Avro格式表示Schema，因此對(duì)Schema的Evolution能力完全等同于Avro Schema的Evolution能力，即可以增加字段以及向上兼容的變更，如int變成long是兼容的，但long變成int是不兼容的。

當(dāng)前現(xiàn)在社區(qū)已經(jīng)有方案支持Full Schema Evolution，即可以增加一個(gè)字段，刪去一個(gè)字段，重命名，也就是變更一個(gè)字段。

還有一個(gè)是Hudi的索引設(shè)計(jì)。每一條數(shù)據(jù)寫入Hudi時(shí)，都會(huì)維護(hù)數(shù)據(jù)主鍵到一個(gè)文件組ID的映射，這樣在做更新、刪除時(shí)可以更快的定位到變更的文件。

右邊的圖里有個(gè)訂單表，可以根據(jù)日期寫到不同的分區(qū)里。下面就是用戶表，就不需要做分區(qū)，因?yàn)樗臄?shù)據(jù)量沒有那么大，變更沒那么頻繁，可以使用非分區(qū)的表。

對(duì)于分區(qū)表及變更頻繁的表，在使用Flink寫入時(shí)，利用Flink State構(gòu)建的全局索引效率比較高。整個(gè)索引是可插拔的，包括Bloomfilter、 HBase高性能索引。在字節(jié)場(chǎng)景中， Bloomfilter過濾器完全不能滿足日增PB的索引查找，因此他們使用HBase高性能索引，因此用戶可根據(jù)自己的業(yè)務(wù)形態(tài)靈活選擇不同索引的實(shí)現(xiàn)。在有不同類型索引情況下可以以較低代價(jià)支持遲到的更新、隨機(jī)更新的場(chǎng)景。

另外一個(gè)設(shè)計(jì)是并發(fā)控制。并發(fā)控制是在0.8之后才引入的。Hudi提供樂觀鎖機(jī)制來處理并發(fā)寫問題，在提交的時(shí)候檢查兩個(gè)變更是否沖突，如果沖突就會(huì)寫入失敗。對(duì)于表服務(wù)如Compaction或者是Clustering內(nèi)部沒有鎖，Hudi內(nèi)部有一套協(xié)調(diào)機(jī)制來避免鎖競(jìng)爭(zhēng)問題。比如做Compaction，可以先在timeline上先打一個(gè)點(diǎn)，后面完全可以和寫入鏈路解耦，異步做Compaction。

例如左邊是數(shù)據(jù)攝取鏈路，數(shù)據(jù)每半個(gè)小時(shí)攝取一次，右邊是異步刪除作業(yè)，也會(huì)變更表，并且很有可能和寫入修改沖突，會(huì)導(dǎo)致這個(gè)鏈路一直失敗，平臺(tái)無故的消耗CPU資源，現(xiàn)在社區(qū)針對(duì)這種情況也有改進(jìn)方案，希望盡早檢測(cè)并發(fā)寫入的沖突，提前終止，減少資源浪費(fèi)。

另外一個(gè)設(shè)計(jì)是元數(shù)據(jù)表。因?yàn)镠udi最開始是基于HDFS構(gòu)建和設(shè)計(jì)，沒有太多考慮云上存儲(chǔ)場(chǎng)景，導(dǎo)致在云上FileList非常慢。因此在0.8版本，社區(qū)引入了Metadata Table，Metadata Table本身也是一張Hudi表，它構(gòu)建成一張Hudi，可以復(fù)用Hudi表等各種表服務(wù)。Metadata Table表文件里會(huì)存分區(qū)下有的所有文件名以及文件大小，每一列的統(tǒng)計(jì)信息做查詢優(yōu)化，以及現(xiàn)在社區(qū)正在做的，基于Meta Table表構(gòu)建全局索引，每條記錄對(duì)應(yīng)每個(gè)文件ID都記錄在Meta table，減少處理Upsert時(shí)查詢待更新文件的開銷，也是上云必備。

四、Hudi未來規(guī)劃

未來的規(guī)劃，如基于Pulsar、Hudi構(gòu)建Lakehouse，這是StreamNative CEO提出的Proposal，想基于Hudi去構(gòu)建Pulsar分層的存儲(chǔ)。在Hudi社區(qū)，我們也做了一些工作，想把Hudi內(nèi)置的工具包DeltaStreamar內(nèi)置Pulsar Source，現(xiàn)在已經(jīng)有PR了，希望兩個(gè)社區(qū)聯(lián)系可以更緊密。Pular分層存儲(chǔ)內(nèi)核部分StreamNative有同學(xué)正在做。

最近幾天已經(jīng)發(fā)布了0.9.0重要的優(yōu)化和改進(jìn)。首先集成了Spark SQL，極大降低了數(shù)據(jù)分析人員使用Hudi的門檻。

Flink集成Hudi的方案早在Hudi的0.7.0版本就有了，經(jīng)過幾個(gè)版本的迭代，Flink集成Hudi已經(jīng)非常成熟了，在字節(jié)跳動(dòng)等大公司已經(jīng)在生產(chǎn)使用。Blink團(tuán)隊(duì)做的一個(gè)CDC的Format集成，直接把Update、Deltete事件直接存到Hudi。還有就是做存量數(shù)據(jù)的一次性遷移，增量了批量導(dǎo)入能力，減少了序列化和反序列化的開銷。

另外現(xiàn)在有一些用戶會(huì)覺得Hudi存一些元數(shù)據(jù)字段，比如_hoodie_commit_time等元信息，這些信息都是從數(shù)據(jù)信息里提取的，有部分存儲(chǔ)開銷，現(xiàn)在支持虛擬鍵，元數(shù)據(jù)字段不會(huì)再存數(shù)據(jù)了，它帶來的限制就是不能使用增量ETL，無法獲取Hudi某一個(gè)時(shí)間點(diǎn)之后的變更數(shù)據(jù)。

另外很多小伙伴也在希望Hudi支持ORC格式，Hudi最新版本支持了ORC格式，同時(shí)這部分格式的是可插拔的，后續(xù)可以很靈活接入更多的格式。還做了Metadata Table的寫入和查詢優(yōu)化，通過Spark SQL查詢的時(shí)候，避免Filelist，直接通過Metadata Table獲取整個(gè)文件列表信息。

從更遠(yuǎn)來看社區(qū)未來的規(guī)劃包括對(duì)于Spark集成升級(jí)到Data SourceV2，現(xiàn)在Hudi基于V1，無法用到V2的性能優(yōu)化。還有Catalog集成，可以通過Catalog管理表，可以創(chuàng)建、刪除、更新，表格元數(shù)據(jù)的管理通過Spark Catalog集成。

Flink模塊Blink團(tuán)隊(duì)有專職同學(xué)負(fù)責(zé)，后續(xù)會(huì)把流式數(shù)據(jù)里的Watremark推到Hudi表里。

另外是與Kafka Connect Sink的集成，后續(xù)直接通過Java客戶把Kafka的數(shù)據(jù)寫到Hudi。

在內(nèi)核側(cè)的優(yōu)化，包括了基于Metadata Table全局記錄級(jí)別索引。還有字節(jié)跳動(dòng)小伙伴做的寫入支持Bucket，這樣的好處就是做數(shù)據(jù)更新的時(shí)候，可以通過主鍵找到對(duì)應(yīng)Bucket，只要把對(duì)應(yīng)Bucket的parquet文件的Bloomfilter讀取出來就可以了，減少了查找更新時(shí)候的開銷。

還有更智能地Clustering策略，在我們內(nèi)部也做了這部分工作，更智能的Clustering可以基于之前的負(fù)載情況，動(dòng)態(tài)的開啟Clustering優(yōu)化，另外還包括基于Metadata Table構(gòu)建二級(jí)索引，以及Full Schema Evolution和跨表事務(wù)。

現(xiàn)在Hudi社區(qū)發(fā)展得比較快，代碼重構(gòu)量非常大，但都是為了更好的社區(qū)發(fā)展，從0.7.0到0.9.0版本Flink集成Hudi模塊基本上完全重構(gòu)了，如果有興趣的同學(xué)可以參與到社區(qū)，共同建設(shè)更好的數(shù)據(jù)湖平臺(tái)。

原文鏈接
本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。?

總結(jié)

以上是生活随笔為你收集整理的技术干货｜基于Apache Hudi 的CDC数据入湖「内附干货PPT下载渠道」的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。