Spark SQL：通過“order by”改善緩存內存占用

Question

我有兩個場景，其中我有23 GB分區parquet數據並讀取很少的columns並預先caching它以稍后觸發一系列后續查詢。

設置：

• 集群：12 節點 EMR
• 火花版本：1.6
• Spark 配置：默認
• 運行配置：兩種情況相同

案例一：

val paths = Array("s3://my/parquet/path", ...)
val parqFile = sqlContext.read.parquet(paths:_*)
parqFile.registerTempTable("productViewBase")
val dfMain = sqlContext.sql("select guid,email,eventKey,timestamp,pogId from productViewBase")
dfMain.cache.count

從SparkUI讀取的輸入數據為 6.2 GB，緩存對象為15.1 GB 。

案例一：

val paths = Array("s3://my/parquet/path", ...)
val parqFile = sqlContext.read.parquet(paths:_*)
parqFile.registerTempTable("productViewBase")
val dfMain = sqlContext.sql("select guid,email,eventKey,timestamp,pogId from productViewBase order by pogId")
dfMain.cache.count

從SparkUI讀取的輸入數據為 6.2 GB，緩存對象為5.5 GB 。

對此行為的任何解釋或代碼參考？

Answer 1

其實還是比較簡單的。 正如您在 SQL 指南中所讀到的：

Spark SQL 可以使用內存中的列格式緩存表... Spark SQL 將僅掃描所需的列並自動調整壓縮

排序列式存儲的好處在於它很容易壓縮典型數據。 排序時，您會得到這些相似記錄的塊，甚至可以使用非常簡單的技術（如RLE ）將它們壓縮在一起。

這是一個在具有列式存儲的數據庫中實際上經常使用的屬性，因為它不僅在存儲方面非常有效，而且在聚合方面也非常有效。

sql.execution.columnar.compression包涵蓋了 Spark 列壓縮的不同方面，如您所見， RunLengthEncoding確實是可用的壓縮方案之一。

所以這里有兩部分：

• Spark 可以根據統計信息動態調整壓縮方法：

  Spark SQL 會根據數據的統計信息自動為每一列選擇一個壓縮編解碼器。

• 排序可以將相似的記錄聚集在一起，從而使壓縮效率更高。

如果列之間存在一些相關性（如果不是這種情況？）即使是基於單個列的簡單排序也會產生相對較大的影響並提高不同壓縮方案的性能。