日韩无码专区无码一级三级片|91人人爱网站中日韩无码电影|厨房大战丰满熟妇|AV高清无码在线免费观看|另类AV日韩少妇熟女|中文日本大黄一级黄色片|色情在线视频免费|亚洲成人特黄a片|黄片wwwav色图欧美|欧亚乱色一区二区三区

本次分享主要是針對(duì)Apache Hudi 0.11.0新版本新特性進(jìn)行深度解讀，主要介紹4個(gè)方面的內(nèi)容：

站在用戶的角度思考問題，與客戶深入溝通，找到鹽池網(wǎng)站設(shè)計(jì)與鹽池網(wǎng)站推廣的解決方案，憑借多年的經(jīng)驗(yàn)，讓設(shè)計(jì)與互聯(lián)網(wǎng)技術(shù)結(jié)合，創(chuàng)造個(gè)性化、用戶體驗(yàn)好的作品，建站類型包括：成都網(wǎng)站設(shè)計(jì)、成都做網(wǎng)站、企業(yè)官網(wǎng)、英文網(wǎng)站、手機(jī)端網(wǎng)站、網(wǎng)站推廣、國(guó)際域名空間、虛擬空間、企業(yè)郵箱。業(yè)務(wù)覆蓋鹽池地區(qū)。

• 多級(jí)索引
• Spark SQL 新功能
• Flink 集成改進(jìn)
• 其他功能和提升

01多級(jí)索引

首先和大家分享下多級(jí)索引，接下來我們將從三個(gè)方面介紹它。第一是為什么我們引入多級(jí)索引multi model index，第二多級(jí)索引的設(shè)計(jì)以及實(shí)踐，最后將介紹如何利用多級(jí)索引，極大提升讀寫性能。

1. 為什么要引入多級(jí)索引（Multi-Modal Index）

在介紹多級(jí)索引之前，我們先看看索引是什么？索引是數(shù)據(jù)庫(kù)系統(tǒng)中常用的查詢加速技術(shù)。通過構(gòu)建索引就可以利用生成的元數(shù)據(jù)metadata快速定位查詢所需數(shù)據(jù)的位置，這樣可以減少甚至避免從文件系統(tǒng)中掃描或者讀取不必要的數(shù)據(jù)，減少IO的開銷，大大提升查詢效率。我們可以類比圖書館以及教科書中的索引，這些都是通過利用提前生成好的metadata來快速找到想要查找的信息。

其實(shí)在Apache Hudi的湖倉(cāng)一體的架構(gòu)中已經(jīng)提供了特有的索引支持，這里我們可以看一個(gè)例子。其中我們用的一種索引可以快速定位到我們所需要更新或者刪除的記錄所在的文件組。如下圖所示：

如果沒有index的情況下，對(duì)于所有的更新以及刪除的記錄，我們需要和所有的文件進(jìn)行merge，這樣開銷會(huì)非常大。如果使用了索引，讀寫開銷會(huì)極大地降低，可以提高查詢這個(gè)位置的效率。

在Hudi中我們默認(rèn)開啟了基于bloom filter的索引。這些bloom filter是存儲(chǔ)在數(shù)據(jù)文件的footer中。作為一個(gè)單獨(dú)的存在，它可以被用到索引的流程過程中。

那我們?yōu)槭裁催€要在Hudi中引用多級(jí)索引？其實(shí)索引的主要目的就是剛剛提到的提升數(shù)據(jù)查詢的速度，那么就需要存儲(chǔ)metadata。而對(duì)于TB、EB級(jí)別表中的metadata，它們的量級(jí)會(huì)很大。通常的做法是把它們存儲(chǔ)于單獨(dú)的數(shù)據(jù)塊block或者是數(shù)據(jù)文件中。而我們?cè)趯?shí)測(cè)的過程中，遇到了讀寫瓶頸。同時(shí)，在維護(hù)metadata的過程中，它需要實(shí)時(shí)的和數(shù)據(jù)表進(jìn)行同步。這樣的管理十分復(fù)雜，因?yàn)橐ＷCtransaction，如果我們要在Hudi中引用新的索引開發(fā)周期會(huì)很長(zhǎng)。

2. 多級(jí)索引的設(shè)計(jì)與實(shí)現(xiàn)

為了解決上述的問題，我們?cè)诤}(cāng)一體的存儲(chǔ)架構(gòu)中引入了多級(jí)索引，是首次在類似的架構(gòu)中引入統(tǒng)一平臺(tái)、多元化、高性能的索引。我們的目標(biāo)是支持所有計(jì)算及查詢引擎來提升讀寫性能，甚至未來如果出現(xiàn)新的引擎，也是可以進(jìn)行兼容的。

接下來我們介紹一些在多級(jí)索引設(shè)計(jì)中所需要的需求。

• 第一是我們需要保證可拓展的元數(shù)據(jù)（scalable metadata）。我們希望元數(shù)據(jù)是Serverless的，是不需要任何的計(jì)算或者是內(nèi)存中需要支持的，可以獨(dú)立存在于數(shù)倉(cāng)一體和數(shù)據(jù)湖中。同時(shí)希望它能獨(dú)立于計(jì)算及查詢引擎，它是可拓展的，能高性能地支持不同索引類型。
• 第二是我們希望多級(jí)索引中的元數(shù)據(jù)和數(shù)據(jù)表保持實(shí)時(shí)同步，保證每次的更新都是事務(wù)性的。
• 第三是保證查詢的速度。保證對(duì)于多級(jí)索引的查詢是低延遲的，主要的查詢類型包括point, range, and prefix lookups等。

我們分別來看一下是如何實(shí)現(xiàn)的。

首先是可拓展的元數(shù)據(jù)，我們采用了和已有數(shù)據(jù)庫(kù)類似的設(shè)計(jì)，那就是在內(nèi)部構(gòu)建一個(gè)元數(shù)據(jù)表meta table。對(duì)于Hudi table來說，我們利用的是Hudi的mor表來存儲(chǔ)這些數(shù)據(jù)。mor表的優(yōu)勢(shì)是可以很快地進(jìn)行數(shù)據(jù)的更新與刪除。同時(shí)，Hudi表也是Serverless的，它不會(huì)依賴任何計(jì)算及內(nèi)存資源。在這個(gè)表里我們針對(duì)不同的索引是建立獨(dú)立的分區(qū)的。在這樣的情況下，不同的index可以完成獨(dú)立的管理以及自動(dòng)化的管理。我們?cè)谑褂胢or表的另一個(gè)優(yōu)點(diǎn)是可以支持任意的索引大小。從mb級(jí)別到gb級(jí)別再到tb級(jí)別。針對(duì)獨(dú)立的分支，我們可以引入新的作用類型，就只需要建立新的分區(qū)。在構(gòu)建可拓展的元數(shù)據(jù)的時(shí)候，需要索引的一個(gè)初始化。我們提高了兩種方式的初始化。一種是同步，同步是在寫入表的過程中，在最后commit之前會(huì)做一個(gè)index的步驟。而第二種方式是異步。異步創(chuàng)建索引是hudi首次引入的，保證了concurrent writer 不受影響。下面是異步創(chuàng)建索引的流程圖：

• 第二點(diǎn)的設(shè)計(jì)原則是保證對(duì)metadata table的更新是事務(wù)性的，來保證metadata table結(jié)構(gòu)里面的數(shù)據(jù)要和數(shù)據(jù)表實(shí)時(shí)同步。我們?cè)O(shè)計(jì)了一套叫multi table多表的transaction。同時(shí)在這個(gè)metadata table 里，有自我管理的表服務(wù)，包括compaction, cleaning。它們會(huì)保證定時(shí)操作，以保證這個(gè)metadata table 的讀性能會(huì)很好。
• 第三點(diǎn)是對(duì)于metadata的快速查詢。我們使用了HFile作為MDT的數(shù)據(jù)格式。原因是列格式Parquet或基于行的Avro不適合 pointed lookup；HFile格式中的index使得 pointed lookup非常高效，只需要讀取相關(guān)數(shù)據(jù)塊。我們針對(duì)HFile做了一個(gè)測(cè)試，得出在千萬（10M）+條目中查詢 N 條目，HFile 相比于 Parquet、Avro 有 10-100倍的提升。如下圖：

3. 利用多級(jí)索引極大提升讀寫性能

接下來介紹多級(jí)索引所帶來的主要的讀寫性能提升。

• 首先是File Listing

在云存儲(chǔ)中我們發(fā)現(xiàn)大部分情況下，如果對(duì)于大型表的上千分區(qū)以及百萬級(jí)的數(shù)據(jù)文件做listing，會(huì)造成讀寫瓶頸。這主要是因?yàn)樵拼鎯?chǔ)的設(shè)計(jì)所導(dǎo)致的。如果我們利用metadata table中的files來做分區(qū)。這個(gè)分區(qū)里提供了這個(gè)數(shù)據(jù)表里所有的file。相比于云軟件系統(tǒng)有2-20倍的提升。如下圖：

• 另一個(gè)比較重要的特性是Data Skipping

Data Skipping 技術(shù)是利用列統(tǒng)計(jì)數(shù)據(jù)來對(duì)所需要的這個(gè)數(shù)據(jù)文件做file pruning （文件裁剪），列統(tǒng)計(jì)數(shù)據(jù)常見的列統(tǒng)計(jì)數(shù)據(jù)包括取最大值、最小值、數(shù)量、大小等。Data Skipping 的作用就是通過這些統(tǒng)計(jì)數(shù)據(jù)來排除掉不需要讀的文件，這樣可以極大的提高查詢速度。我們?cè)谶@個(gè)multi model index 的metadata 中構(gòu)建了column_stats分區(qū)，這個(gè)分區(qū)里的每條記錄包含了這個(gè)Hudi表里所對(duì)應(yīng)文件的列統(tǒng)計(jì)數(shù)據(jù)。每個(gè)Record key是由列名稱、分區(qū)名稱和文件名稱組成。通過這種排列格式，可以快速定位所需的column stats。查詢復(fù)雜度是基于查詢列所需要的列的數(shù)量，通常這個(gè)數(shù)量是5到10個(gè)。對(duì)于大寬表來說，這樣可以極大地提升這個(gè)效果。在實(shí)際測(cè)試中，云上Hudi大寬表的“定向”查詢速度有10x-30x的提升。大幅減少了對(duì)無關(guān)數(shù)據(jù)文件的掃描和讀取，提高了I/O效率。如下圖：

• 我們還對(duì)Upsert 性能做了測(cè)試。我們?cè)趍etadata table中引入了一個(gè)bloom_filter 分區(qū)，取代了footer 中的 bloom filter，在大表中可以大幅減少文件讀取的時(shí)間。每條記錄包含單個(gè)數(shù)據(jù)文件（partition + file name）的 bloom filter，支持 prefix lookup。據(jù)實(shí)測(cè)，在有 100k 文件的 Hudi 表中，相比于讀取 footer，從 MDT 讀取 bloom filter的速度有3倍的提升。t6.c
• 基于多級(jí)索引，未來還有很多工作可以做，目前一個(gè)工作是針對(duì)record level index 的開發(fā)以及Luncene index的開發(fā)。
  

02 Spark SQL新功能

接下來再講Hudi在Spark SQL方面的改進(jìn)。

1. 用戶可以使用非主鍵字段更新或刪除 Hudi 表中的記錄

Spark SQL改進(jìn)Delete Operation。

在t1時(shí)刻分別往mor表cow表中分別插入a,b,c三條數(shù)據(jù)。這樣會(huì)在mor表中生成base file 文件和log file文件（下圖中簡(jiǎn)化了示意圖）。在cow表中只會(huì)生產(chǎn)base file 文件。t2時(shí)刻同時(shí)刪除mor表和cow表中 b的數(shù)據(jù)。mor表操作是刪除log file b的block是t2時(shí)刻的數(shù)據(jù)。而cow表中的操作是復(fù)制一份base file b保存到內(nèi)存中，刪除b數(shù)據(jù)之后會(huì)形成一個(gè)新版本的綠色的方框中的數(shù)據(jù)文件。如下圖：

2. SQL支持時(shí)間旅行查詢

我們?yōu)槭裁匆獙?shí)現(xiàn)Time travel？從api層面，如果我們要寫一個(gè)查詢，需要設(shè)置不同的df，構(gòu)造不同的operation，然后來查詢這個(gè)動(dòng)作。但是引用time travel的這個(gè)語句以后，一是可以在spark sql中直接使用，二是sql語句更容易去解釋這樣的一個(gè)行為和動(dòng)作。現(xiàn)在可以通過timestamp as of語法支持時(shí)間旅行查詢，但僅限Spark 3.2+。語法如下：select * from hudi_tbl timestamp as of '20210728141108100' 

①SQL Travel-場(chǎng)景1：查詢多版本數(shù)據(jù)

如下圖，我們?cè)?0:10分提交了insert和update語句，我們想要查10:05分版本的數(shù)據(jù)，通過下面的sql是可以實(shí)現(xiàn)的。

select * from test_hudi timestamp as of 20220512100510000 （10:05）

select * from test_hudi timestamp as of 20220512101030000 （10:10）

②Travel-場(chǎng)景2： 數(shù)據(jù)還原修復(fù)

• 創(chuàng)建hudi表：create table test_hudi ...
• 插入數(shù)據(jù)：insert into test_hudi ... （每插入一條數(shù)據(jù)會(huì)產(chǎn)生一個(gè)版本）

• 查詢數(shù)據(jù)：select * from test_hudi

• 誤刪數(shù)據(jù)：delete from test_hudi where id=2
• 查詢數(shù)據(jù)：select * from test_hudi （刪除id=2的數(shù)據(jù)后只剩下了兩個(gè)版本）

• 還原數(shù)據(jù)：insert into test_hudi_table select * from test_hudi timestamp as of 20220511165343733（數(shù)據(jù)如果存在的話update，如果數(shù)據(jù)不存在就insert）
• 查詢數(shù)據(jù)：select * from test_hudi （id=2的數(shù)據(jù)已經(jīng)還原回來了）

注意：如果這個(gè)表用了 truncate清空的話，這種時(shí)間戳方式查詢恢復(fù)就不行了。 

3. 添加CALL命令以支持在 Hudi 表上調(diào)用更多操作

Call Command產(chǎn)生的一個(gè)背景是spark sql除了ddl、dql和dml之外的操作，我們想解決這三種操作之外的一些新功能的操作。那么在引入Call Command之前是沒辦法操作的。我們對(duì)比了一下傳統(tǒng)數(shù)據(jù)庫(kù)里面的存儲(chǔ)過程，類似地在spark這一塊實(shí)現(xiàn)了一個(gè)command動(dòng)作，然后對(duì)應(yīng)實(shí)現(xiàn)了一個(gè)procedure的功能。

首先是在hudi一側(cè)為call command生成了一個(gè)通用的語法，不依賴于spark的版本，可以對(duì)所有spark版本適用。然后生成了一個(gè)HoodieProcedure的類，使用CallProcedureHoodieCommand類調(diào)用動(dòng)作。

Call Command命令在設(shè)計(jì)時(shí)主要有四個(gè)方面的功能。一是支持歸檔、提交、回滾和創(chuàng)建還原點(diǎn)的快照動(dòng)作。二是可以進(jìn)行原數(shù)據(jù)管理。三是對(duì)運(yùn)維表進(jìn)行數(shù)據(jù)導(dǎo)入導(dǎo)出、Boostrap、修復(fù)表、升級(jí)/降級(jí)等操作。四是優(yōu)化表動(dòng)作，如Compaction、Clustering、Clean等。

Call Command的參數(shù)有三類。一是可以使用不定式的參數(shù)（鍵值對(duì)）作為它的入?yún)?shù)。二是可以按照參數(shù)的位置進(jìn)行入?yún)?。三是混合參?shù)。以下是傳參的具體語法：

• 接下來是CALL Command功能方面的一些介紹。

①CALL Command-快照管理的相應(yīng)的命令

• 查詢快照 ：call show_commits_metadata(table => 'test_hudi_table', limit => 10)
• 回滾快照：

call rollback_to_instant('test_hudi_table',20220511224632307')

• 創(chuàng)建保存點(diǎn) ：create_savepoints
• 恢復(fù)保存點(diǎn) ：rollback_savepoints
• 刪除保存點(diǎn) ：delete_savepoints

②CALL Command-Clustering

可以設(shè)置Clustering的類型：

set hoodie.layout.optimize.strategy=linear /z-order/hilbert

常用命令：

call run_clustering(table => 'test_hudi_table',order => 'ts') 

call show_clustering(table=>'test_hudi_table')

通過這些clustering的動(dòng)作，在查詢的時(shí)候性能能達(dá)到10-20倍的提升。

③CALL Command-Compact（小文件合并）（目前只支持mor表）

Data file和Delta log file 合并會(huì)重新生成一個(gè)新的文件。

命令：call run_compaction(table=>'test_hudi_table',op=> instant

03 Flink集成改進(jìn)

最后，介紹Flink集成改進(jìn)方面的內(nèi)容。主要有以下幾點(diǎn)：

1. 在 0.11.0 中，同時(shí)支持 Flink 1.13.x 和 1.14.x。

2. 支持復(fù)雜的數(shù)據(jù)類型。

3. 基于 DFS 的 Flink HoodieCatalog。

綠色是目前已經(jīng)實(shí)現(xiàn)的操作，紅色是待實(shí)現(xiàn)的操作。可以通過ApI實(shí)現(xiàn)或者是Flink Sql實(shí)現(xiàn)。

FlinkHoodieCatalog在三個(gè)方面有比較好的作用：

• 第一個(gè)方面是對(duì)元數(shù)據(jù)的管理，通過FlinkHoodieCatalog這個(gè)框架可以更好地管理HoodieCatalog；
• 第二個(gè)方面是可以基于這個(gè)框架可以去和外面的其他的平臺(tái)去對(duì)接，更方便對(duì)接使用；
• 第三個(gè)方面是元數(shù)據(jù)方面，可以在數(shù)據(jù)血緣方面構(gòu)造一些功能。

4. Bucket Index 

為什么要集成改進(jìn)Bucket Index？這個(gè)是字節(jié)的同學(xué)貢獻(xiàn)的一個(gè)功能。他們?cè)谒麄兊纳a(chǎn)場(chǎng)景里面，在34tb的數(shù)據(jù)量在5000億的記錄寫入的情況下，Bloom Filter Index 通過Record key去找File ID 的這樣的一個(gè)動(dòng)作的性能會(huì)下降得很快。為了解決Bloom Filter Index的假陽性，他們引入了Bucket Index。

通過key的哈希值定位到File Group，提升了實(shí)時(shí)導(dǎo)入的性能。如下圖所示：

從Flink輸入了5條數(shù)據(jù)，然后通過一定的哈希策略將混合的Bucket Index進(jìn)行關(guān)聯(lián)，通過拿到FileGroupId寫入文件。

• 利用Bucket分布做優(yōu)化

Bucket分布優(yōu)化主要有：Bucket Pruning、Bucket Aggregate、Bucket Join等。如下圖所示：

• Bucket限制。目前 Bucket Index 的桶數(shù)量 ，需要根據(jù)預(yù)估的數(shù)據(jù)量提前在建表時(shí)進(jìn)行確定，且建表后不可更改。
• Bucket使用

參數(shù)：hoodie.index.type 值：BUCKET

參數(shù)：hoodie.bucket.index.num.buckets 值：48（256MB）

建議單個(gè)桶的大小控制在3GB左右。

• Bucket后續(xù)改進(jìn)。Hashmap的擴(kuò)容過程，將分桶數(shù)按倍數(shù)做到輕量級(jí)動(dòng)態(tài)擴(kuò)容。

04其他功能和提升

最后，我們來講其他功能和提升。

1. Spark DataSource 查詢優(yōu)化

我們?cè)谑褂胢or表做快照查詢的時(shí)候，log文件會(huì)被讀取，然后和base文件進(jìn)行合并。在之前的版本中，當(dāng)你做快照查詢的時(shí)候，整條log文件記錄會(huì)被讀出來。這個(gè)版本我們做了優(yōu)化，使用了內(nèi)置的標(biāo)準(zhǔn)Payload來讀取。例如：OverwriteWithLatestAvroPayload。我們會(huì)針對(duì)這個(gè)做了優(yōu)化，只把必要的列讀出來，這樣就會(huì)極大的減少內(nèi)存和壓縮解碼帶來的CPU的消耗。其實(shí)是對(duì)于非常寬的上千列的表來說，效果會(huì)非常明細(xì)。

2. Schema 演進(jìn) 

在這個(gè)版本中，我們針對(duì)Spark 3.1、Spark 3.2版本增加了schema功能的演進(jìn)。如果啟用 set hoodie.schema.on.read.enable=true以后，我們可以對(duì)表列和對(duì)表進(jìn)行一系列的操作。列的變更（增加、刪除、重命名、修改位置、修改屬性），表的變更（重命名、修改屬性） 等。

3. 保存點(diǎn)和恢復(fù) 

保存點(diǎn)和恢復(fù)可以用call command做這些操作。新版本引進(jìn)了mor表，用Hudi CLI設(shè)定保存點(diǎn)和執(zhí)行恢復(fù)或者call command來手動(dòng)設(shè)置保存點(diǎn)。保存點(diǎn)之后的數(shù)據(jù)將會(huì)被刪除。

4. Pulsar 寫提交回調(diào) 

• Hudi寫入commit支持Pulsar下游作業(yè)* 
• 主要配置 HoodieWriteCommitPulsarCallback 

hoodie.write.commit.callback.pulsar.topic

hoodie.write.commit.callback.pulsar.broker.service.url

• 可擴(kuò)展的接口HoodieWriteCommitCallback 

5. 多元化的Catalog同步

• Google BigQuery 支持查詢COW表* 
• DataHub 支持同步Schema 
• 通過AWS SDK原生同步Glue Data Catalog 

新聞標(biāo)題：ApacheHudi新版本新特性超強(qiáng)解讀
網(wǎng)站網(wǎng)址：http://www.5511xx.com/article/cdhciis.html