一、概述

Hudi（Hadoop Upserts Deletes and Incrementals），簡(jiǎn)稱Hudi，是一個(gè)流式數(shù)據(jù)湖平臺(tái)，支持對(duì)海量數(shù)據(jù)快速更新，內(nèi)置表格式，支持事務(wù)的存儲(chǔ)層、 一系列表服務(wù)、數(shù)據(jù)服務(wù)(開箱即用的攝取工具)以及完善的運(yùn)維監(jiān)控工具，它可以以極低的延遲將數(shù)據(jù)快速存儲(chǔ)到HDFS或云存儲(chǔ)（S3）的工具，最主要的特點(diǎn)支持記錄級(jí)別的插入更新（Upsert）和刪除，同時(shí)還支持增量查詢。

• Apache Hudl本身不存儲(chǔ)數(shù)據(jù)，僅僅管理數(shù)據(jù)，借助外部存儲(chǔ)引擎存儲(chǔ)數(shù)據(jù)，比如HDFS；
• 此外，Apache Hudi也不分析數(shù)據(jù)，需要使用計(jì)算分析引擎，查詢和保存數(shù)據(jù),比如Spark或Flink；
• 使用Hudi時(shí)，加載jar包，底層調(diào)用API,所以需要依據(jù)使用大數(shù)據(jù)框架版本，編譯Hudi源碼，獲取對(duì)應(yīng)依賴jar包。

GitHub地址：https://github.com/apache/hudi

官方文檔：https://hudi.apache.org/cn/docs/overview

上圖從下到上，由左向右看

• hudi 底層的數(shù)據(jù)可以存儲(chǔ)到hdfs、s3、azure、alluxio等存儲(chǔ)。
• hudi 可以使用spark/flink 計(jì)算引擎來消費(fèi) kafka、pulsar 等消息隊(duì)列的數(shù)據(jù)，而這些數(shù)據(jù)可能來源于 app 或者微服務(wù)的業(yè)務(wù)數(shù)據(jù)、日志數(shù)據(jù)，也可以是 mysql 等數(shù)據(jù)庫的 binlog 日志數(shù)據(jù)。
• spark/hudi 首先將這些數(shù)據(jù)處理為 hudi 格式的 row tables （原始表），然后這張?jiān)急砜梢员?Incremental ETL (增量處理)生成一張 hudi 格式的 derived tables 派生表。
• hudi 支持的查詢引擎有：trino、hive、impala、spark、presto 等。
• 支持 spark、flink、map-reduce 等計(jì)算引擎繼續(xù)對(duì) hudi 的數(shù)據(jù)進(jìn)行再次加工處理。

二、Hudi 架構(gòu)

• 通過DeltaStreammer、Flink、Spark等工具，將數(shù)據(jù)攝取到數(shù)據(jù)湖存儲(chǔ)，可使用HDFS作為數(shù)據(jù)湖的數(shù)據(jù)存儲(chǔ)；
• 基于HDFS可以構(gòu)建Hudi的數(shù)據(jù)湖；
• Hudi提供統(tǒng)一的訪問Spark數(shù)據(jù)源和Flink數(shù)據(jù)源；
• 外部通過不同引擎，如：Spark、Flink、Presto、Hive、Impala、Aliyun DLA、AWS Redshit訪問接口；

三、Hudi的表格式

Hudi提供兩類型表：寫時(shí)復(fù)制（Copy on Write，COW）表和讀時(shí)合并（Merge On Read，MOR）表。

• 對(duì)于 Copy-On-Write Table，用戶的 update 會(huì)重寫數(shù)據(jù)所在的文件，所以是一個(gè)寫放大很高，但是讀放大為 0，適合寫少讀多的場(chǎng)景。
• 對(duì)于 Merge-On-Read Table，整體的結(jié)構(gòu)有點(diǎn)像 LSM-Tree，用戶的寫入先寫入到 delta data 中，這部分?jǐn)?shù)據(jù)使用行存，這部分 delta data 可以手動(dòng) merge 到存量文件中，整理為 parquet 的列存結(jié)構(gòu)。

1）Copy on Write（寫時(shí)復(fù)制）

簡(jiǎn)稱COW，顧名思義，它是在數(shù)據(jù)寫入的時(shí)候，復(fù)制一份原來的拷貝，在其基礎(chǔ)上添加新數(shù)據(jù)。正在讀數(shù)據(jù)的請(qǐng)求，讀取的是最近的完整副本，這類似Mysql 的MVCC的思想。

優(yōu)點(diǎn)：讀取時(shí)，只讀取對(duì)應(yīng)分區(qū)的一個(gè)數(shù)據(jù)文件即可，較為高效；

缺點(diǎn)：數(shù)據(jù)寫入的時(shí)候，需要復(fù)制一個(gè)先前的副本再在其基礎(chǔ)上生成新的數(shù)據(jù)文件，這個(gè)過程比較耗時(shí)。

2）Merge On Read（讀時(shí)合并）

簡(jiǎn)稱MOR，新插入的數(shù)據(jù)存儲(chǔ)在delta log 中，定期再將delta log合并進(jìn)行parquet數(shù)據(jù)文件。讀取數(shù)據(jù)時(shí)，會(huì)將delta log跟老的數(shù)據(jù)文件做merge，得到完整的數(shù)據(jù)返回。下圖演示了MOR的兩種數(shù)據(jù)讀寫方式。

優(yōu)點(diǎn)：由于寫入數(shù)據(jù)先寫delta log，且delta log較小，所以寫入成本較低；

缺點(diǎn)：需要定期合并整理compact，否則碎片文件較多。讀取性能較差，因?yàn)樾枰獙elta log和老數(shù)據(jù)文件合并

3）COW vs MOR

COW表，用戶在 snapshot 讀取的時(shí)候會(huì)掃描所有最新的 FileSlice 下的 base file。

MOR表，在 READ OPTIMIZED 模式下，只會(huì)讀最近的經(jīng)過 compaction 的 commit。

四、元數(shù)據(jù)表（Metadata Table）

Apache Hudi元數(shù)據(jù)表可以顯著提高查詢的讀/寫性能。元數(shù)據(jù)表的主要目的是消除“列出文件”操作的要求。

讀取和寫入數(shù)據(jù)時(shí)，將執(zhí)行文件列表操作以獲取文件系統(tǒng)的當(dāng)前視圖。當(dāng)數(shù)據(jù)集很大時(shí)，列出所有文件可能是性能瓶頸，但更重要的是，對(duì)于AWS S3等云存儲(chǔ)系統(tǒng)，由于某些請(qǐng)求限制，大量的文件列出請(qǐng)求有時(shí)會(huì)導(dǎo)致節(jié)流。相反，元數(shù)據(jù)表將主動(dòng)維護(hù)文件列表，并消除遞歸文件列表操作的需要。

五、索引（Indexing）

Hudi通過索引機(jī)制將給定的hoodie鍵（記錄鍵+分區(qū)路徑）一致地映射到文件id，從而提供高效的升級(jí)。一旦將記錄的第一個(gè)版本寫入文件，記錄鍵和文件組/文件id之間的映射就不會(huì)改變。簡(jiǎn)而言之，映射的文件組包含一組記錄的所有版本。

目前，Hudi支持以下索引類型：

Bloom索引（默認(rèn)）：使用由記錄鍵構(gòu)建的Bloom過濾器，也可以使用記錄鍵范圍修剪候選文件。

簡(jiǎn)單索引：根據(jù)從存儲(chǔ)上的表中提取的鍵，對(duì)傳入的更新/刪除記錄執(zhí)行精簡(jiǎn)聯(lián)接。

HBase索引：管理外部Apache HBase表中的索引映射。

自定義索引：當(dāng)然也可以擴(kuò)展這個(gè)公共API來實(shí)現(xiàn)自定義索引。

六、查詢類型（Query Type）

Hudi支持三種不同的查詢表的方式：Snapshot Queries(快照查詢)、Incremental Queries(增量查詢)和Read Optimized Queries(讀優(yōu)化查詢)。

1）Snapshot Queries(快照查詢)

查詢查看給定提交或壓縮操作時(shí)表的最新快照。在合并讀取表的情況下，它通過動(dòng)態(tài)合并最新文件切片的基本文件和增量文件來公開接近實(shí)時(shí)的數(shù)據(jù)（幾分鐘）。

對(duì)于隨寫復(fù)制表，它提供了現(xiàn)有拼花桌的插入式替換，同時(shí)提供了upsert/delete和其他寫入端功能。

2）Incremental Queries(增量查詢)

在給定的提交/壓縮之后，查詢只會(huì)看到寫入表的新數(shù)據(jù)。這有效地提供了更改流以啟用增量數(shù)據(jù)管道。

可查看自給定commit/delta commit即時(shí)操作依賴新寫入的數(shù)據(jù)，有效地提供變更流來啟用增量數(shù)據(jù)管道。

3）Read Optimized Queries(讀優(yōu)化查詢)

查詢查看給定提交/壓縮操作時(shí)表的最新快照。僅顯示最新文件切片中的基/列文件，并確保與非hudi列表相比具有相同的列查詢性能。

讀優(yōu)化查詢和快照查詢相同僅訪問基本文件，提供給定文件片自上次執(zhí)行壓縮操作以來的數(shù)據(jù)。通常查詢數(shù)據(jù)的最新程度的保證取決于壓縮策略。

七、計(jì)算模型

在hudi過去的使用場(chǎng)景里，和大部分公司的架構(gòu)類似，采用批式和流式共存的Lambda架構(gòu)，后來Uber提出增量Incremental模型，相對(duì)批式來講，更加實(shí)時(shí)，相對(duì)流式而言，更加經(jīng)濟(jì)。

1）批式模型(Batch)

批式模型就是使用MapReduce、Hive、Spark等典型的批計(jì)算引擎，以小時(shí)任務(wù)或者天任務(wù)的形式來做數(shù)據(jù)計(jì)算。特性如下：

延遲：小時(shí)級(jí)延遲或者天級(jí)別延遲。這里的延遲不單單指的是定時(shí)任務(wù)的時(shí)間，在數(shù)據(jù)架構(gòu)里，這里的延遲時(shí)間通常是定時(shí)任務(wù)間隔時(shí)間+一系列依賴任務(wù)的計(jì)算時(shí)間+數(shù)據(jù)平臺(tái)最終可以展示結(jié)果的時(shí)間。數(shù)據(jù)量大、邏輯復(fù)雜的情況下，小時(shí)任務(wù)計(jì)算的數(shù)據(jù)通常真正延遲的時(shí)間是2-3小時(shí)。

數(shù)據(jù)完整度：數(shù)據(jù)較完整。以處理時(shí)間為例，小時(shí)級(jí)別的任務(wù)，通常計(jì)算的原始數(shù)據(jù)已經(jīng)包含了小時(shí)內(nèi)的所有數(shù)據(jù)，所以得到的數(shù)據(jù)相對(duì)較完整。但如果業(yè)務(wù)需求是事件時(shí)間，這里涉及到終端的一些延遲上報(bào)機(jī)制，在這里，批式計(jì)算任務(wù)就很難派上用場(chǎng)。

成本：成本很低。只有在做任務(wù)計(jì)算時(shí)，才會(huì)占用資源，如果不做任務(wù)計(jì)算，可以將這部分批式計(jì)算資源出讓給在線業(yè)務(wù)使用。從另一個(gè)角度來說成本是挺高的，如原始數(shù)據(jù)做了一些增刪改查，數(shù)據(jù)晚到的情況，那么批式任務(wù)是要全量重新計(jì)算。

2）流式模型(Stream)

流式模型，典型的就是使用Flink來進(jìn)行實(shí)時(shí)的數(shù)據(jù)計(jì)算，特性：

延遲：很短，甚至是實(shí)時(shí)。

數(shù)據(jù)完整度：較差。因?yàn)榱魇揭娌粫?huì)等到所有數(shù)據(jù)到齊之后再開始計(jì)算，所以有一個(gè)watermark的概念，當(dāng)數(shù)據(jù)的時(shí)間小于watermark時(shí)，就會(huì)被丟棄，這樣是無法對(duì)數(shù)據(jù)完整度有一個(gè)絕對(duì)的保障。在互聯(lián)網(wǎng)場(chǎng)景中，流式模型主要用于活動(dòng)時(shí)的數(shù)據(jù)大盤展示，對(duì)數(shù)據(jù)的完整度要求并不算很高。在大部分場(chǎng)景中，用戶需要開發(fā)兩個(gè)程序，一是流式數(shù)據(jù)生產(chǎn)流式結(jié)果，而是批式計(jì)算人物，用于次日修復(fù)實(shí)時(shí)結(jié)果。

成本：很高。因?yàn)榱魇饺蝿?wù)時(shí)常駐的，并且對(duì)于多流join的場(chǎng)景，通常要借助內(nèi)存或者數(shù)據(jù)庫來做state的存儲(chǔ)，不管是序列化開銷，還是和外部組件交互產(chǎn)生的額外IO，在大數(shù)據(jù)量下都是不容忽視的。

3）增量模型(Incremental)

針對(duì)批式和流式的優(yōu)缺點(diǎn)，Uber提出了增量模型(Incremental Mode)，相對(duì)批式來講，更加實(shí)時(shí)；相對(duì)流式而言，更加經(jīng)濟(jì)。 增量模型，簡(jiǎn)單來講，就是一mini batch的形式來跑準(zhǔn)實(shí)時(shí)任務(wù)。hudi在增量模型中支持了兩個(gè)最重要的特性：

Upsert：這個(gè)主要是解決批式模型中，數(shù)據(jù)不能插入、更新的問題，有了這個(gè)特性，可以往Hive中寫入增量數(shù)據(jù)，而不是每次進(jìn)行完全的覆蓋。（hudi自身維護(hù)了key-file的映射，所以當(dāng)upsert時(shí)很容易找到key對(duì)應(yīng)的文件）

Incremental Query：增量查詢，減少計(jì)算的原始數(shù)據(jù)量。以u(píng)ber中司機(jī)和乘客的數(shù)據(jù)流join為例，每次抓取兩條數(shù)據(jù)流中的增量數(shù)據(jù)進(jìn)行批式的join即可，相比流式數(shù)據(jù)而言，成本要降低幾個(gè)數(shù)量級(jí)。

八、數(shù)據(jù)倉庫 VS 數(shù)據(jù)湖

1）數(shù)據(jù)類型

結(jié)構(gòu)化數(shù)據(jù)——來自關(guān)系型數(shù)據(jù)庫中的行和列。

半結(jié)構(gòu)化數(shù)據(jù)——如CSV、日志、XML、JSON等。

非結(jié)構(gòu)化數(shù)據(jù)——如email、文檔、PDF等。

二進(jìn)制數(shù)據(jù)——如圖像、音頻、視頻等。

2）數(shù)據(jù)倉庫與數(shù)據(jù)湖的區(qū)別

數(shù)據(jù)倉庫可以理解為是一個(gè)優(yōu)化的數(shù)據(jù)庫，用戶分析來自事物系統(tǒng)和業(yè)務(wù)線應(yīng)用程序的關(guān)系型數(shù)據(jù)（結(jié)構(gòu)化數(shù)據(jù)和半結(jié)構(gòu)化數(shù)據(jù)）。

數(shù)據(jù)湖可以理解存儲(chǔ)來自業(yè)務(wù)應(yīng)用程序的關(guān)系型數(shù)據(jù)（結(jié)構(gòu)化數(shù)據(jù)），以及來自移動(dòng)應(yīng)用程序、IOT設(shè)備和社交媒體的非關(guān)系型數(shù)據(jù)（非結(jié)構(gòu)化數(shù)據(jù)）等所有類型數(shù)據(jù)。

3）湖倉一體化

Data Lakehouse （湖倉一體）是新出現(xiàn)的一種數(shù)據(jù)架構(gòu),它同時(shí)吸收了數(shù)據(jù)倉庫和數(shù)據(jù)湖的優(yōu)勢(shì)，數(shù)據(jù)分析師和數(shù)據(jù)科學(xué)家可以在同一個(gè)數(shù)據(jù)存儲(chǔ)中對(duì)數(shù)據(jù)進(jìn)行操作，同時(shí)它也能為公司進(jìn)行數(shù)據(jù)治理帶來更多的便利性。

LakeHouse使用新的系統(tǒng)設(shè)計(jì)：直接在用于數(shù)據(jù)湖的低成本存儲(chǔ)上實(shí)現(xiàn)與數(shù)據(jù)倉庫中類似的數(shù)據(jù)結(jié)構(gòu)和數(shù)據(jù)管理功能。

九、源碼編譯

wget https://dlcdn.apache.org/hudi/0.12.0/hudi-0.12.0.src.tgz
tar -xf hudi-0.12.0.src.tgz ; cd cd hudi-0.12.0
# mvn clean package -DskipTests
mvn clean package -DskipTests -DskipITs -Dspark3.2 -Dscala-2.12

編譯好的Hudi 包下載地址：

鏈接：https://pan.baidu.com/s/15qKm1kW1RRtbyFT53RoeGA?pwd=ihhb

提取碼：ihhb