查詢效能提升3倍！Apache Hudi 查詢優化了解下？

leesf發表於2022-03-06

Apache優化

從 Hudi 0.10.0版本開始，我們很高興推出在資料庫領域中稱為 Z-Order 和 Hilbert 空間填充曲線的高階資料佈局優化技術的支援。

1. 背景

Amazon EMR 團隊最近發表了一篇很不錯的文章展示了對資料進行聚簇是如何提高查詢效能的，為了更好地瞭解發生了什麼以及它與空間填充曲線的關係，讓我們仔細研究該文章的設定。

文章中比較了 2 個 Apache Hudi 表（均來自 Amazon Reviews 資料集）：

未聚簇的 amazon_reviews 表（即資料尚未按任何特定鍵重新排序）
amazon_reviews_clustered 聚簇表。當資料被聚簇後，資料按字典順序排列（這裡我們將這種排序稱為線性排序），排序列為star_rating、total_votes兩列（見下圖）

為了展示查詢效能的改進，對這兩個表執行以下查詢：

這裡要指出的重要考慮因素是查詢指定了排序的兩個列（star_rating 和 total_votes）。但不幸的是這是線性/詞典排序的一個關鍵限制，如果新增更多列，排序的價值會會隨之減少。

從上圖可以看到，對於按字典順序排列的 3 元組整數，只有第一列能夠對所有具有相同值的記錄具有關鍵的區域性性屬性：例如所有記錄都具有以“開頭的值” 1"、"2"、"3"（在第一列中）很好地聚簇在一起。但是如果嘗試在第三列中查詢所有值為"5"的值，會發現這些值現在分散在所有地方，根本沒有區域性性，過濾效果很差。

提高查詢效能的關鍵因素是區域性性：它使查詢能夠顯著減少搜尋空間和需要掃描、解析等的檔案數量。

但是這是否意味著如果我們按表排序的列的第一個（或更準確地說是字首）以外的任何內容進行過濾，我們的查詢就註定要進行全面掃描？不完全是，區域性性也是空間填充曲線在列舉多維空間時啟用的屬性（我們表中的記錄可以表示為 N 維空間中的點，其中 N 是我們表中的列數）

那麼它是如何工作的？我們以 Z 曲線為例：擬合二維平面的 Z 階曲線如下所示：

可以看到按照路徑，不是簡單地先按一個座標 ("x") 排序，然後再按另一個座標排序，它實際上是在對它們進行排序，就好像這些座標的位已交織成單個值一樣：

線上性排序的情況下區域性性僅使用第一列相比，該方法的區域性性使用到所有列。

以類似的方式，希爾伯特曲線允許將 N 維空間中的點（我們表中的行）對映到一維曲線上，基本上對它們進行排序，同時仍然保留區域性性的關鍵屬性，在此處閱讀有關希爾伯特曲線的更多詳細資訊，到目前為止我們的實驗表明，使用希爾伯特曲線對資料進行排序會有更好的聚簇和效能結果。

現在讓我們來看看它的實際效果！

2. 設定

我們將再次使用 Amazon Reviews 資料集，但這次我們將使用 Hudi 按 product_id、customer_id 列元組進行 Z-Order排序，而不是聚簇或線性排序。

資料集不需要特別的準備，可以直接從 S3 中以 Parquet 格式下載並將其直接用作 Spark 將其攝取到 Hudi 表。

啟動spark-shell

./bin/spark-shell --master 'local[4]' --driver-memory 8G --executor-memory 8G \
  --jars ../../packaging/hudi-spark-bundle/target/hudi-spark3-bundle_2.12-0.10.0.jar \
  --packages org.apache.spark:spark-avro_2.12:2.4.4 \
  --conf 'spark.serializer=org.apache.spark.serializer.KryoSerializer'

匯入Hudi表

import org.apache.hadoop.fs.{FileStatus, Path}
import scala.collection.JavaConversions._
import org.apache.spark.sql.SaveMode._
import org.apache.hudi.{DataSourceReadOptions, DataSourceWriteOptions}
import org.apache.hudi.DataSourceWriteOptions._
import org.apache.hudi.common.fs.FSUtils
import org.apache.hudi.common.table.HoodieTableMetaClient
import org.apache.hudi.common.util.ClusteringUtils
import org.apache.hudi.config.HoodieClusteringConfig
import org.apache.hudi.config.HoodieWriteConfig._
import org.apache.spark.sql.DataFrame

import java.util.stream.Collectors

val layoutOptStrategy = "z-order"; // OR "hilbert"

val inputPath = s"file:///${System.getProperty("user.home")}/datasets/amazon_reviews_parquet"
val tableName = s"amazon_reviews_${layoutOptStrategy}"
val outputPath = s"file:///tmp/hudi/$tableName"


def safeTableName(s: String) = s.replace('-', '_')

val commonOpts =
  Map(
    "hoodie.compact.inline" -> "false",
    "hoodie.bulk_insert.shuffle.parallelism" -> "10"
  )


////////////////////////////////////////////////////////////////
// Writing to Hudi
////////////////////////////////////////////////////////////////

val df = spark.read.parquet(inputPath)

df.write.format("hudi")
  .option(DataSourceWriteOptions.TABLE_TYPE.key(), COW_TABLE_TYPE_OPT_VAL)
  .option("hoodie.table.name", tableName)
  .option(PRECOMBINE_FIELD.key(), "review_id")
  .option(RECORDKEY_FIELD.key(), "review_id")
  .option(DataSourceWriteOptions.PARTITIONPATH_FIELD.key(), "product_category")
  .option("hoodie.clustering.inline", "true")
  .option("hoodie.clustering.inline.max.commits", "1")
  // NOTE: Small file limit is intentionally kept _ABOVE_ target file-size max threshold for Clustering,
  // to force re-clustering
  .option("hoodie.clustering.plan.strategy.small.file.limit", String.valueOf(1024 * 1024 * 1024)) // 1Gb
  .option("hoodie.clustering.plan.strategy.target.file.max.bytes", String.valueOf(128 * 1024 * 1024)) // 128Mb
  // NOTE: We're increasing cap on number of file-groups produced as part of the Clustering run to be able to accommodate for the 
  // whole dataset (~33Gb)
  .option("hoodie.clustering.plan.strategy.max.num.groups", String.valueOf(4096))
  .option(HoodieClusteringConfig.LAYOUT_OPTIMIZE_ENABLE.key, "true")
  .option(HoodieClusteringConfig.LAYOUT_OPTIMIZE_STRATEGY.key, layoutOptStrategy)
  .option(HoodieClusteringConfig.PLAN_STRATEGY_SORT_COLUMNS.key, "product_id,customer_id")
  .option(DataSourceWriteOptions.OPERATION.key(), DataSourceWriteOptions.BULK_INSERT_OPERATION_OPT_VAL)
  .option(BULK_INSERT_SORT_MODE.key(), "NONE")
  .options(commonOpts)
  .mode(ErrorIfExists)

3. 測試

每個單獨的測試請在單獨的 spark-shell 中執行，以避免快取影響測試結果。

////////////////////////////////////////////////////////////////
// Reading
///////////////////////////////////////////////////////////////

// Temp Table w/ Data Skipping DISABLED
val readDf: DataFrame =
  spark.read.option(DataSourceReadOptions.ENABLE_DATA_SKIPPING.key(), "false").format("hudi").load(outputPath)

val rawSnapshotTableName = safeTableName(s"${tableName}_sql_snapshot")

readDf.createOrReplaceTempView(rawSnapshotTableName)


// Temp Table w/ Data Skipping ENABLED
val readDfSkip: DataFrame =
  spark.read.option(DataSourceReadOptions.ENABLE_DATA_SKIPPING.key(), "true").format("hudi").load(outputPath)

val dataSkippingSnapshotTableName = safeTableName(s"${tableName}_sql_snapshot_skipping")

readDfSkip.createOrReplaceTempView(dataSkippingSnapshotTableName)

// Query 1: Total votes by product_category, for 6 months
def runQuery1(tableName: String) = {
  // Query 1: Total votes by product_category, for 6 months
  spark.sql(s"SELECT sum(total_votes), product_category FROM $tableName WHERE review_date > '2013-12-15' AND review_date < '2014-06-01' GROUP BY product_category").show()
}

// Query 2: Average star rating by product_id, for some product
def runQuery2(tableName: String) = {
  spark.sql(s"SELECT avg(star_rating), product_id FROM $tableName WHERE product_id in ('B0184XC75U') GROUP BY product_id").show()
}

// Query 3: Count number of reviews by customer_id for some 5 customers
def runQuery3(tableName: String) = {
  spark.sql(s"SELECT count(*) as num_reviews, customer_id FROM $tableName WHERE customer_id in ('53096570','10046284','53096576','10000196','21700145') GROUP BY customer_id").show()
}

//
// Query 1: Is a "wide" query and hence it's expected to touch a lot of files
//
scala> runQuery1(rawSnapshotTableName)
+----------------+--------------------+
|sum(total_votes)|    product_category|
+----------------+--------------------+
|         1050944|                  PC|
|          867794|             Kitchen|
|         1167489|                Home|
|          927531|            Wireless|
|            6861|               Video|
|           39602| Digital_Video_Games|
|          954924|Digital_Video_Dow...|
|           81876|             Luggage|
|          320536|         Video_Games|
|          817679|              Sports|
|           11451|  Mobile_Electronics|
|          228739|  Home_Entertainment|
|         3769269|Digital_Ebook_Pur...|
|          252273|                Baby|
|          735042|             Apparel|
|           49101|    Major_Appliances|
|          484732|             Grocery|
|          285682|               Tools|
|          459980|         Electronics|
|          454258|            Outdoors|
+----------------+--------------------+
only showing top 20 rows

scala> runQuery1(dataSkippingSnapshotTableName)
+----------------+--------------------+
|sum(total_votes)|    product_category|
+----------------+--------------------+
|         1050944|                  PC|
|          867794|             Kitchen|
|         1167489|                Home|
|          927531|            Wireless|
|            6861|               Video|
|           39602| Digital_Video_Games|
|          954924|Digital_Video_Dow...|
|           81876|             Luggage|
|          320536|         Video_Games|
|          817679|              Sports|
|           11451|  Mobile_Electronics|
|          228739|  Home_Entertainment|
|         3769269|Digital_Ebook_Pur...|
|          252273|                Baby|
|          735042|             Apparel|
|           49101|    Major_Appliances|
|          484732|             Grocery|
|          285682|               Tools|
|          459980|         Electronics|
|          454258|            Outdoors|
+----------------+--------------------+
only showing top 20 rows

//
// Query 2: Is a "pointwise" query and hence it's expected that data-skipping should substantially reduce number 
// of files scanned (as compared to Baseline)
//
// NOTE: That Linear Ordering (as compared to Space-curve based on) will have similar effect on performance reducing
// total # of Parquet files scanned, since we're querying on the prefix of the ordering key
//
scala> runQuery2(rawSnapshotTableName)
+----------------+----------+
|avg(star_rating)|product_id|
+----------------+----------+
|             1.0|B0184XC75U|
+----------------+----------+


scala> runQuery2(dataSkippingSnapshotTableName)
+----------------+----------+
|avg(star_rating)|product_id|
+----------------+----------+
|             1.0|B0184XC75U|
+----------------+----------+

//
// Query 3: Similar to Q2, is a "pointwise" query, but querying other part of the ordering-key (product_id, customer_id)
// and hence it's expected that data-skipping should substantially reduce number of files scanned (as compared to Baseline, Linear Ordering).
//
// NOTE: That Linear Ordering (as compared to Space-curve based on) will _NOT_ have similar effect on performance reducing
// total # of Parquet files scanned, since we're NOT querying on the prefix of the ordering key
//
scala> runQuery3(rawSnapshotTableName)
+-----------+-----------+
|num_reviews|customer_id|
+-----------+-----------+
|         50|   53096570|
|          3|   53096576|
|         25|   10046284|
|          1|   10000196|
|         14|   21700145|
+-----------+-----------+

scala> runQuery3(dataSkippingSnapshotTableName)
+-----------+-----------+
|num_reviews|customer_id|
+-----------+-----------+
|         50|   53096570|
|          3|   53096576|
|         25|   10046284|
|          1|   10000196|
|         14|   21700145|
+-----------+-----------+

4. 結果

我們總結了以下的測試結果

可以看到多列線性排序對於按列（Q2、Q3）以外的列進行過濾的查詢不是很有效，這與空間填充曲線（Z-order 和 Hilbert）形成了非常明顯的對比，後者將查詢時間加快多達 3倍。值得注意的是效能提升在很大程度上取決於基礎資料和查詢，在我們內部資料的基準測試中，能夠實現超過 11倍 的查詢效能改進！

5. 總結

Apache Hudi v0.10 為開源帶來了新的佈局優化功能 Z-order 和 Hilbert。使用這些行業領先的佈局優化技術可以為使用者查詢帶來顯著的效能提升和成本節約！

提升50%！Presto如何提升Hudi表查詢效能？
2021-05-16
REST
EntityFramework優化：查詢效能
2018-05-19
Framework優化
使用Django annotation，提升django查詢效能
2019-02-05
Django
效能優化之分頁查詢
2018-11-19
優化
ClickHouse的查詢效能優勢
2023-02-22
百萬商品查詢，效能提升了10倍
2024-10-28
MySQL: 使用explain 優化查詢效能
2021-10-29
MySqlAI優化
mysql查詢效能優化總結
2020-12-23
MySql優化
pgsql查詢優化之模糊查詢
2019-07-20
SQL優化
查詢優化
2020-10-09
優化
MySQL-效能優化-索引和查詢優化
2018-06-03
MySql優化索引
MySQL——優化巢狀查詢和分頁查詢
2018-11-01
MySql優化巢狀
HBase查詢優化
2018-08-05
優化
Oracle in 查詢優化
2021-06-07
Oracle優化
join 查詢優化
2021-01-28
優化
MySQL查詢優化
2021-03-04
MySql優化
mysql查詢優化檢查 explain
2018-05-04
MySql優化AI
SQL查詢的：子查詢和多表查詢
2020-11-18
SQL
mysql-分組查詢-子查詢-連線查詢-組合查詢
2020-12-22
MySql
PostgreSQL 原始碼解讀（29）- 查詢語句#14（查詢優化-上拉子查詢）
2018-08-29
SQL原始碼優化
MySQL優化COUNT()查詢
2019-01-14
MySql優化
EntityFramework優化：查詢WITH(NOLOCK)
2018-05-17
Framework優化
MySQL 的查詢優化
2020-01-07
MySql優化
優化sql查詢速度
2020-10-25
優化SQL
分頁查詢優化
2020-04-05
優化
MySQL 慢查詢優化
2019-06-23
MySql優化
KunlunDB 查詢優化（一）
2022-01-17
優化
複雜查詢—子查詢
2020-11-16
查詢——二分查詢
2020-09-18
資料庫全表查詢之-分頁查詢優化
2020-12-31
資料庫優化
資料的儲存和查詢分離不利查詢效能 - thenewstack
2022-05-07
MYSQL學習筆記25: 多表查詢(子查詢)[標量子查詢,列子查詢]
2024-03-10
MySql筆記
TiDB 查詢優化及調優系列（二）TiDB 查詢計劃簡介
2022-04-27
TiDB優化
MySQL 查詢效能分析之 Explain
2020-01-06
MySqlAI
MySQL查詢效能最佳化
2024-07-25
MySql
剖析Elasticsearch的IndexSorting:一種查詢效能優化利器
2018-11-10
ElasticsearchIndex優化
mysql查詢太慢，我們如何進行效能優化？
2021-02-07
MySql優化
MySQL調優之查詢優化
2021-11-09
MySql優化