《資料資產管理核心技術與應用》讀書筆記-第二章:後設資料的採集與儲存

张永清發表於2024-08-06

《資料資產管理核心技術與應用》是清華大學出版社出版的一本圖書,全書共分10章,第1章主要讓讀者認識資料資產,瞭解資料資產相關的基礎概念,以及資料資產的發展情況。第2~8章主要介紹大資料時代資料資產管理所涉及的核心技術,內容包括後設資料的採集與儲存、資料血緣、資料質量、資料監控與告警、資料服務、資料許可權與安全、資料資產管理架構等。第9~10章主要從實戰的角度介紹資料資產管理技術的應用實踐,包括如何對後設資料進行管理以發揮出資料資產的更大潛力,以及如何對資料進行建模以挖掘出資料中更大的價值。

圖書介紹:資料資產管理核心技術與應用

今天主要是給大家分享一下第二章的內容:

第二章的標題為後設資料的採集與儲存

主要是介紹瞭如何從Apache Hive、Delta lake、Apache Hudi、Apache Iceberg、Mysql 等常見的資料倉儲、資料胡以及關係型資料庫中採集獲取後設資料。、

1、Hive的後設資料採集方式:

1.1、基於Hive Meta DB的後設資料採集

由於Hive在部署時,是將資料單獨儲存在指定的資料庫中的,所以從技術實現上來說肯定是可以直接透過從Hive後設資料儲存的的資料庫中獲取到需要的後設資料資訊。Hive通常是將後設資料儲存在單獨的資料庫中,可以在部署時由使用者自己來指定儲存在哪種資料庫上,通常可以支援儲存在MySQL、SQLServer、Derby 、Postgres、Oracle等資料庫中。Hive後設資料資料庫中常見的關鍵表之間的關聯關係如下圖,根據下圖的關聯關係,我們就可以用SQL語句查詢到需要的後設資料的資料資訊。

相關表的介紹如下:

DBS:儲存著Hive中資料庫的相關基礎資訊

DATABASE_PARAMS:儲存著Hive中資料庫引數的相關資訊

TBLS:儲存著Hive中資料庫的資料表的相關基礎資訊

COLUMNS_V2:儲存著資料表的欄位資訊

TABLE_PARAMS:儲存著Hive中資料庫的資料表引數或者屬性的相關基礎資訊

TBL_PRIVS:儲存著表或者檢視的授權資訊

SERDES:儲存著資料序列化的相關配置資訊

SERDE_PARAMS:儲存著資料序列化的屬性或者引數資訊

SDS:儲存著資料表的資料檔案儲存的相關資訊

SD_PARAMS:儲存著資料表的儲存相關屬性或者引數資訊

PARTITIONS:儲存著資料表的分割槽相關資訊

PARTITION_KEYS:儲存著資料表的分割槽欄位資訊

PARTITION_PARAMS:儲存分割槽的屬性或者引數資訊

1.2、基於Hive Catalog的後設資料採集

Hive Catalog 是Hive提供的一個重要的元件,專門用於後設資料的管理,管理著所有Hive庫表的結構、儲存位置、分割槽等相關資訊,同時Hive Catalog提供了RESTful API或者Client 包供使用者來查詢或者修改後設資料資訊,其底層核心的Jar包為hive-standalone-metastore.jar。在該Jar包中的org.apache.hadoop.hive.metastore.IMetaStoreClient.java 介面中定義了對Hive後設資料的管理的抽象,詳細程式碼實現可以參考紙質書。

在Hive2.2.0版本之前Hive還提供了以Hcatalog REST API的形式對外可以訪問Hive Catalog(Hive2.2.0版本後,已經移除了Hcatalog REST API這個功能),REST API 訪問地址的格式為:http://yourserver/templeton/v1/resource,在Hive的Wiki網站:WebHCat Reference - Apache Hive - Apache Software Foundation中有詳細列出REST API 支援哪些介面訪問,如下圖

比如透過呼叫REST API 介面:http://yourserver/templeton/v1/ddl/database 便可以獲取到Catalog中所有的資料庫的資訊,如下圖

1.2、基於Spark Catalog的後設資料採集

Spark 是一個基於分散式的大資料計算框架。Spark 和Hadoop的最大的不同是,Spark的資料主要是基於記憶體計算,所以Spark的計算效能遠遠高於Hadoop,深受大資料開發者的喜歡,Spark提供了 Java、Scala、Python 和 R 等多種開發語言的 API。

Spark Catalog是Spark提供的一個後設資料管理元件,專門用於Spark對後設資料的讀取和儲存管理,管理著Spark 支援的所有資料來源的後設資料,Spark Catalog支援的資料來源包括HDFS、Hive、JDBC等,Spark Catalog將外部資料來源中的資料表對映為Spark中的表,所以透過Spark Catalog 也可以採集到我們需要的後設資料資訊。

自Spark3.0版本起,引入了Catalog Plugin,雖然org.apache.spark.sql.catalog.Catalog 提供了一些常見的後設資料的查詢和操作,但是並不夠全面、強大以及靈活,比如無法支援多個Catalog等,所以 Catalog Plugin是Spark為了解決這些問題而應運而生的。

詳細程式碼實現可以參考紙質書。

2、Delta Lake 中的後設資料採集

提到Delta Lake 就不得提資料湖這個概念了,Delta Lake 是資料湖的一種。資料湖是相對於資料倉儲提出來的一個集中式儲存概念,和資料倉儲中主要儲存結構化的資料不同的是,資料湖中可以儲存結構化資料(一般指以行和列來呈現的資料)、半結構化資料(如 日誌、XML、JSON等)、非結構化資料(如 Word文件、PDF 等)和 二進位制資料(如影片、音訊、圖片等)。通常來說資料湖中以儲存原始資料為主,而資料倉儲中以儲存原始資料處理後的結構化資料為主。

Delta Lake是一個基於資料湖的開源專案,能夠在資料湖之上構建湖倉一體的資料架構,提供支援ACID資料事務、可擴充套件的後設資料處理以及底層支援Spark上的流批資料計算處理。

Delta Lake的主要特徵如下:

基於Spark之上的ACID資料事務,可序列化的事務隔離級別確保了資料讀寫的一致性。
利用Spark的分散式可擴充套件的處理能力,可以做到PB級以上的資料處理和儲存。
資料支援版本管控,包括支援資料回滾以及完整的歷史版本審計跟蹤。
支援高效能的資料行級的Merge、Insert、Update、Delete 操作,這點是Hive 所不能具備的。
以Parquet檔案作為資料儲存格式,同時會有 Transaction Log檔案記錄了資料的變更過程,日誌格式為JSON,如下圖

2.1 基於Delta Lake自身設計來採集後設資料

Delta Lake 的後設資料由自己管理,通常不依賴於類似Hive Metastore 這樣的第三方外部後設資料元件。在Delta Lake中後設資料是和資料一起存放在自己的檔案系統的目錄下,並且所有的後設資料操作都被抽象成了相應的 Action 操作,表的後設資料是由 Action 子類實現的。如下是Delta Lake中原始碼的結構(原始碼Github地址:https://github.com/delta-io/delta),如下圖

在Metadata.java這個實現類中提供了後設資料的方法呼叫,詳細程式碼實現可以參考紙質書。

2.2 基於Spark Catalog來採集後設資料

由於Delta Lake 是支援使用spark 來讀取和寫入資料,所以在Delta Lake的原始碼中,也實現了Spark提供的CatalogPlugin介面,由於Delta Lake 也實現了Spark提供的CatalogPlugin介面,所以基於Spark Catalog的方式,也可以直接獲取到delta lake的後設資料資訊,詳細程式碼實現可以參考紙質書。

3、MySQL 中的後設資料採集

MySQL是被廣泛使用的一款關係型資料庫,在MySQL資料庫系統中自帶了information_schema 這個庫來提供MySQL後設資料的訪問,INFORMATION_SCHEMA是每個MySQL例項中的一個自有資料庫,儲存著MySQL伺服器維護的所有其他資料庫的相關資訊,INFORMATION_SCHEMA中的表其實都是隻讀的檢視,而不是真正的基表,不能執行INSERT、UPDATE、DELETE操作,因此沒有與INFORMATION_SCHEMA相關聯的資料檔案,也沒有具有該名稱的資料庫目錄,並且不能設定觸發器。

information_schema 中與後設資料相關的重點表如下:

Tables表:提供了資料庫中表、檢視等資訊
Columns表:提供了資料庫中表欄位的相關資訊
Views表:提供了資料庫中檢視的相關資訊
Partitions表:提供了資料庫中資料表的分割槽資訊
Files表:提供了有關儲存MySQL表空間資料的檔案的資訊
4、Apache Hudi中的後設資料採集

Hudi 和Delta Lake 一樣,也是一款基於資料湖的開源專案,同樣也能夠在資料湖之上構建湖倉一體的資料架構,透過訪問網址:Apache Hudi | An Open Source Data Lake Platform即可計入到Hudi的官方首頁。

Hudi的主要特徵如下:

支援表、事務、快速的Insert、Update、Delete 等操作
支援索引、資料儲存壓縮比高,並且支援常見的開原始檔儲存格式
支援基於Spark、Flink的分散式流式資料處理
支援Apache Spark、Flink、Presto、Trino、Hive等SQL查詢引擎
4.1 基於Spark Catalog來採集後設資料

由於Hudi是支援使用Spark 來讀取和寫入資料,所以在Hudi的原始碼中,也實現了Spark提供的CatalogPlugin介面,由於Hudi 和Delta Lake一樣, 也實現了spark提供的CatalogPlugin介面,所以採用基於Spark Catalog的方式,也可以直接獲取到Hudi的後設資料資訊,詳細程式碼實現可以參考紙質書。

4.2 Hudi Timeline Meta Server

通常情況下資料湖是透過追蹤資料湖中資料檔案的方式來管理後設資料的,不管是Delta Lake還是Hudi ,底層都是透過跟蹤檔案操作的方式來提取後設資料的。在Hudi中,對後設資料的操作和Delta Lake的實現很類似,底層也都是抽象成了相應的Action 操作,只是Action操作的型別略微有些不同。

資料湖之所以不能直接用Hive Meta Store 來管理後設資料,是因為Hive Meta Store 的後設資料管理是沒有辦法實現資料湖特有的資料跟蹤能力的。因為資料湖管理檔案的粒度非常細,需要記錄和跟蹤哪些檔案是新增操作,哪些檔案是失效操作,哪些資料的新增的,哪些資料是更新的,而且還需要具備原子的事務性,支援回滾等操作。Hudi為了管理好後設資料,記錄資料的變更過程,設計了Timeline Meta Server,Timeline 記錄了在不同時刻對錶執行的所有操作的日誌,有助於提供表的即時檢視。

在Hudi中抽象出了一個Marker的概念,翻譯過來就是標記的意思,資料的寫入操作可能在完成之前出現寫入失敗的情況,從而在儲存中留下部分或損壞的資料檔案,而標記則用於跟蹤和清除失敗的寫入操作,寫入操作開始時,會建立一個標記,表示正在進行檔案寫入。寫入提交成功後,標記將被刪除。如果寫入操作中途失敗,則會留下一個標記,表示這個寫入的檔案不完整。使用標記主要有如下兩個目的。

正在刪除重複/部分資料檔案:標記有助於有效地識別寫入的部分資料檔案,與稍後成功寫入的資料檔案對比,這些檔案包含重複的資料,並且在提交完成時會清除這些重複的資料檔案。
回滾失敗的提交:如果寫入操作失敗,則下一個寫入請求將會在繼續進行新的寫入之前會先回滾該失敗的提交。回滾是在標記的幫助下完成的,標記用於識別整體失敗但已經提交的一部分寫入的資料檔案。
加入沒用標記來跟蹤每次提交的資料檔案,那麼Hudi將不得不列出檔案系統中的所有檔案,將其與Timeline中看到的檔案關聯起來做對比,然後刪除屬於部分寫入失敗的檔案,這在一個像Hudi 這樣龐大的分散式系統中,效能的開銷將會是非常昂貴的。

4.3 基於Hive Meta DB來採集後設資料

雖然Hudi 後設資料儲存是透過Timeline來管理的,但是Hudi 在設計時,就考慮了支援將自身後設資料同步到Hive Meta Store中,其實就是將Hudi的Timeline中的後設資料非同步更新到Hive Meta Store中儲存。

在Hudi的原始碼中,定義了org.apache.hudi.sync.common.HoodieMetaSyncOperations.java這個介面抽象來作為後設資料同步給類似Hive Meta DB這樣的第三方的外部後設資料儲存庫,詳細程式碼實現可以參考紙質書。

5、Apache Iceberg中的後設資料採集

Apache Iceberg同樣也是一款開源的資料湖專案,Iceberg的出現進一步推動了資料湖和湖倉一體架構的發展,並且讓資料湖技術變得更加豐富,透過訪問網址:Apache Iceberg - Apache Iceberg 即可進入其官方首頁。

Iceberg的主要特點如下:

同樣也支援Apache Spark、Flink、Presto、Trino、Hive、Impala等眾多的SQL查詢引擎。
支援更加靈活的SQL語句來Merge、Update、Delete資料湖中的資料。
可以很好的支援對資料Schema的變更,比如新增新的列、重新命名列等。
支援快速的資料查詢,資料查詢時可以快速跳過不必要的分割槽和檔案以快速查詢到符合指定條件的資料,在Iceberg中,單個表可以支援PB級別資料的快速查詢。
資料儲存支援按照時間序列的版本控制以及回滾,可以按照時間序列或者版本來查詢資料的快照。
資料在儲存時,壓縮支援開箱即用,可以有效的節省資料儲存的成本。
5.1 Iceberg的後設資料設計

由於Hive資料倉儲的表的狀態是直接透過列出底層的資料檔案來檢視的,所以表的資料修改無法做到原子性,所以無法支援事務以及回滾,一旦寫入出錯可能就會產生不準確的結果。所以Iceberg在底層透過架構設計時增加了後設資料層這一設計來規避Hive資料倉儲的不足,如下圖所示,從圖中可以看到Iceberg使用了兩層設計來持久化資料,一層是後設資料層,一層是資料層,在資料層中儲存是Apache Parquet、Avro或ORC等格式的實際資料,在後設資料層中可以有效地跟蹤資料操作時刪除了哪些檔案和資料夾,然後掃描資料檔案統計資料時,就可以確定特定查詢時是否需要讀取該檔案以便提高查詢的速度。後設資料層通常包容如下內容:

後設資料檔案:後設資料檔案通常儲存表的Schema、分割槽資訊和錶快照的詳細資訊等資料資訊。
清單列表檔案:將所有清單檔案資訊儲存為快照中的清單檔案的索引,並且通常會包含一些其他詳細資訊,如新增、刪除了多少資料檔案以及分割槽的邊界情況等。
清單檔案:儲存資料檔案列表(比如以Parquet/ORC/AVRO格式儲存的資料),以及用於檔案被修改後的列級度量和統計資料。


5.2 透過Spark Catalog來採集後設資料

同Hudi 和Delta Lake一樣,由於Iceberg也是支援使用Spark 來讀取和寫入資料,所以在Iceberg的底層設計時,也實現了Spark提供的CatalogPlugin介面,所以透過Spark Catalog的方式,也是可以直接獲取到Iceberg的後設資料資訊,詳細程式碼實現可以參考紙質書。

5.3 透過Iceberg Java API來獲取後設資料

在Iceberg中提供了Java API 來獲取表的後設資料,透過訪問官方網址:Java API - Apache Iceberg 即可獲取到Java API的詳細介紹,如下圖

從圖中可以看到,透過Java API 可以獲取到Iceberg資料表的Schema、屬性、儲存路徑、快照等眾多後設資料資訊。

相關文章