欧美成人brazzers,av在线观看网站,国产成人精品亚洲午夜

Hudi系列:Hudi核心概念(版本1.0)

?Hudi架構

?一. 時間軸(TimeLine)s

?1.1 時間軸(TimeLine)概念

?1.2 Hudi的時間線由組成

?1.3 時間線上的Instant action操作類型

?1.4 時間線上State狀態(tài)類型

?1.5 時間線官網(wǎng)實例

?二. 文件布局

?三. 索引

3.1 簡介

3.2 對比其它(Hive)沒有索引的區(qū)別

3.2 多態(tài)索引

布隆過濾器

記錄索引

表達索引

二級索引

3.3寫入端的索引類型

3.4 全局索引與非全局索引

四. 表類型

4.1 COW：(Copy on Write)寫時復制表

4.1.1 概念

4.1.2 COW工作原理

4.1.3 COW表對表的管理方式改進點

4.2 MOR：(Merge on Read)讀時復制表

4.2.1 概念

4.2.2 MOR表工作原理

4.3 總結了兩種表類型之間的權衡

五. 查詢類型

5.1 Snapshot Queries

5.2 Incremental Queries

5.3 Read Optimized Query

簡介

Hudi 中最基礎的索引機制會一致地跟蹤從給定鍵（記錄鍵 + 可選分區(qū)路徑）到文件 ID 的映射。其他類型的索引（如二級索引）都以此為基礎構建。一旦將記錄的第一個版本寫入文件組，記錄鍵和文件組/文件 ID 之間的映射就很少會發(fā)生變化。只有以刪除 + 插入形式實現(xiàn)的集群或跨分區(qū)更新才會將記錄鍵重新映射到不同的文件組。即便如此，給定的記錄鍵在時間線上的任何完成時刻都只與一個文件組相關聯(lián)。

對比其它(Hive)沒有索引的區(qū)別

對于 Copy-On-Write表，索引可實現(xiàn)快速的插入/刪除操作，因為無需與整個數(shù)據(jù)集連接來確定要重寫哪些文件。對于Merge-On-Read 表，索引允許 Hudi 限制需要合并任何給定基礎文件的更改記錄數(shù)量。具體而言，給定基礎文件僅需與屬于該基礎文件的記錄的更新合并。相反，沒有索引組件的Hive ACID需要將所有的基本文件與所有傳入的更新/刪除記錄合并。

多態(tài)索引

Hudi 通過增強元數(shù)據(jù)表以合并新類型索引的能力來支持多模式索引，并輔以索引構建的異步機制。此增強功能支持元數(shù)據(jù)表中的一系列索引，從而顯著提高了寫入和讀取表的效率。

布隆過濾器Bloom Filters

Bloom filter 索引作為元數(shù)據(jù)表中的 bloom_filter 分區(qū)。此索引采用基于范圍的修剪來修剪記錄鍵的最小值和最大值，并采用基于 bloom 過濾器的查找來標記傳入的記錄。對于大型表，這涉及讀取所有匹配數(shù)據(jù)文件的頁腳以查找 bloom 過濾器，這在整個數(shù)據(jù)集隨機更新的情況下成本可能很高。此索引集中存儲所有數(shù)據(jù)文件的 bloom 過濾器，以避免直接從所有數(shù)據(jù)文件掃描頁腳。

記錄索引Record Indexes

記錄索引作為元數(shù)據(jù)表中的 record_index 分區(qū)。包含記錄鍵到位置的映射。記錄索引是一個全局索引，在表的所有分區(qū)中強制鍵唯一性。此索引有助于比其他現(xiàn)有索引更快地定位記錄，并且可以在索引查找主導寫入延遲的大型部署中提供更快的加速。為了適應非常高的規(guī)模，它利用基于哈希的鍵空間分片。此外，在讀取數(shù)據(jù)時，索引允許點查找，從而顯著加快索引映射檢索過程。

表達式索引Expression Index

Expression Index是列函數(shù)的索引。如果查詢對列函數(shù)有謂詞，則可以使用表達式索引來加速查詢。表達式索引存儲在元數(shù)據(jù)表下的 expr_index_ 前綴分區(qū)中（每個表達式索引一個）?？梢允褂?SQL 語法創(chuàng)建表達式索引。請在此處查看 SQL DDL 文檔以了解更多詳細信息。

以下是控制在寫入器上啟用表達式索引構建和維護的配置，后續(xù)會詳細講解，這個是1.0的新增的特性

二級索引Secondary Index

Secondary Index允許用戶在 Hudi 表中不屬于記錄鍵列的列上創(chuàng)建索引（對于記錄鍵字段，Hudi 支持記錄級索引）。二級索引可用于加速對記錄鍵列以外的列使用謂詞的查詢。

以下是控制在寫入器上啟用二級索引構建和維護的配置，后續(xù)會詳細講解，這個是1.0的新增的特性

附加寫入端索引 writer-side indexes

上面討論的所有索引都可通過與元數(shù)據(jù)表集成供讀取器/寫入器使用。存儲引擎還實現(xiàn)了索引機制，通過高效讀取/連接/處理傳入的輸入記錄，以對照存儲在基礎/日志文件本身中的信息（例如，存儲在 parquet 文件頁腳中的布隆過濾器）或智能數(shù)據(jù)布局（例如，存儲桶索引）。

目前，Hudi 支持以下索引類型。Spark 引擎上的默認索引類型為 SIMPLE，F(xiàn)link 和 Java 引擎上的默認索引類型為 INMEMORY。寫入器可以使用 hoodie.index.type 配置選項選擇其中一個選項。

index類型	描述
SIMPLE（Spark 引擎的默認索引類型）	這是 Spark 引擎的標準索引類型。它執(zhí)行傳入記錄與從存儲在磁盤上的表中檢索到的鍵的有效連接。它要求鍵在分區(qū)級別上是唯一的，這樣它才能正常運行。
RECORD_INDEX	使用上一節(jié)中的記錄索引作為寫入端索引。
BLOOM	用由記錄鍵生成的布隆過濾器，并可選擇根據(jù)記錄鍵的范圍進一步縮小候選文件的范圍。它要求鍵在分區(qū)級別上是唯一的，這樣它才能正常工作。
GLOBAL_BLOOM	用由記錄鍵創(chuàng)建的布隆過濾器，還可以通過使用記錄鍵的范圍來優(yōu)化候選文件的選擇。它要求鍵在表/全局級別上是唯一的，這樣它才能正常工作。
GLOBAL_SIMPLE	對傳入記錄與從存儲表中提取的鍵執(zhí)行精益連接。它要求鍵在表/全局級別上是唯一的，這樣它才能正常工作。
HBASE	通過 Apache HBase 中的外部表管理索引映射。
INMEMORY（Flink 和 Java 的默認設置）	使用 Spark 和 Java 引擎中的內(nèi)存哈希圖以及 Flink 中的 Flink 內(nèi)存狀態(tài)進行索引。
BUCKET	利用 bucket hashing 來識別存放記錄的文件組，這在大規(guī)模情況下尤其有利。要選擇 bucket 引擎的類型（即創(chuàng)建 bucket 的方法），請使用 hoodie.index.bucket.engine 配置選項。
SIMPLE（默認）	此索引為每個分區(qū)內(nèi)的文件組使用固定數(shù)量的 bucket，這些 bucket 無法減小或增大大小。它適用于 COW 和 MOR 表。由于 bucket 數(shù)量不可改變，并且設計原則是將每個 bucket 映射到單個文件組，因此這種索引方法可能不適用于數(shù)據(jù)偏差較大的分區(qū)。
CONSISTENT_HASHING	此索引可容納動態(tài)數(shù)量的 bucket，并具有調(diào)整 bucket 大小的功能，以確保每個 bucket 的大小合適。通過允許動態(tài)調(diào)整這些分區(qū)的大小，這解決了數(shù)據(jù)量大的分區(qū)中的數(shù)據(jù)偏差問題。因此，分區(qū)可以有多個大小合理的存儲桶，這與 SIMPLE 存儲桶引擎類型中每個分區(qū)的存儲桶數(shù)量固定不同。此功能僅與 MOR 表兼容。
自帶實現(xiàn)	您可以擴展此公共 API 并使用 hoodie.index.class 提供 SparkHoodieIndex 的子類（用于 Apache Spark 編寫器）來實現(xiàn)自定義索引。