JindoCube使用說明

JindoCube在E-MapReduce 3.24.0及之後版本中可用。本文主要介紹E-MapReduce JindoCube的安裝、部署和使用等。

前提條件

已建立表或者視圖。

概述

JindoCube是E-MapReduce Spark支援的進階特性，通過預計算加速資料處理，實現十倍甚至百倍的效能提升。您可以將任意View表示的資料進行持久化，持久化的資料可以儲存在HDFS或OSS等任意Spark支援的DataSource中。EMR Spark自動探索可用的已持久化資料，並最佳化執行計畫，對使用者完全透明。JindoCube主要用於查詢模式相對比較固定的業務情境，通過提前設計JindoCube，對資料進行預計算和預組織，從而加速業務查詢的速度，常見的使用情境包括MOLAP多維分析、報表產生、資料Dashboard和跨叢集資料同步等。

JindoCube的安裝與部署

JindoCube作為EMR Spark組件的進階特性，所有使用EMR Spark提交的Dataset、DataFrame API、SQL任務，均可以基於JindoCube進行加速，無須額外的組件部署與維護。

UI頁面展示。

JindoCube主要通過Spark的UI頁面進行管理，包括JindoCube的建立、刪除和更新等。通過UI建立JindoCube完成後，即可自動用於該叢集所有Spark任務的查詢加速。通過spark.sql.cache.tab.display參數可以控制是否在Spark UI頁面展示JindoCube的Tab，可以通過EMR控制台在Spark服務中配置相關參數，或者在Spark提交命令中指定參數值，該參數預設值為false。 Spark_UI

JindoCube還提供了spark.sql.cache.useDatabase參數，可以針對業務方向，按不同的業務建立database，把需要建cache的view放在這個database中。對於分區表JindoCube還提供了spark.sql.cache.cacheByPartition參數，可指定cache使用分區欄位進行儲存。

參數	說明	樣本值
spark.sql.cache.tab.display	顯示Cube Managment頁面。	true
spark.sql.cache.useDatabase	cube儲存資料庫。	db1,db2,dbn
spark.sql.cache.cacheByPartition	按照分區欄位儲存cube。	true

最佳化查詢。

spark.sql.cache.queryRewrite用於控制是否允許使用JindoCube中的Cache資料加速Spark查詢任務，使用者可以在叢集、session、SQL等層面使用該配置，預設值為true。

JindoCube的使用

建立JindoCube。

通過阿里雲帳號登入E-MapReduce控制台。
單擊集群管理頁簽。
單擊待操作叢集所在行的叢集ID。
單擊左側導覽列的访问链接与端口。
在公網訪問連結頁面，單擊YARN UI所在行的連結，進入Knox代理的YARN UI頁面。

Knox相關使用說明請參見Knox。
單擊Name為Thrift JDBC/ODBC Server，Application Type為SPARK所在行的ApplicationMaster。
單擊上方的Cube Management頁簽。

單擊New Cache。

您可以選擇某一個表或視圖，單擊action中的連結繼續建立Cache。可以選擇的Cache類型分為兩類：

Raw Cache：某一個表或者視圖的raw cache，表示將對應表或視圖代表的表資料按照指定的方式持久化。

在建立Raw Cache時，需要指定如下資訊：

參數	描述	是否必選
Cache Name	指定Cache的名字，支援字母、數字、串連號（–）和底線（_）的組合。	必選
Column Selector	選擇需要Cache哪些列的資料。	必選
Rewrite	是否允許該Cache被用作後續查詢的執行計畫最佳化。	必選
Provider	Cache資料的儲存格式，支援JSON、PARQUET、ORC等所有Spark支援的資料格式。	必選
Partition Columns	Cache資料的分區欄位。	可選
ZOrder Columns	ZOrder是一種支援多列排序的方法，Cache資料按照ZOrder欄位排序後，對於基於ZOrder欄位過濾的查詢會有更好的加速效果。	可選

Cube Cache：基於某一個表或者視圖的未經處理資料，按照使用者指定的方式構建cube，並將cube資料持久化。

在建立Cube Cache時，使用者需要指定如下資訊：

參數	描述	是否必選
Cache Name	指定Cache的名字，支援字母、數字、串連號（–）和底線（_）的組合。	必選
Dimension Selector	選擇構建Cube時的維度欄位。	必選
Measure Selector	選擇構建Cube時的measure欄位和measure預計算函數。	必選
Rewrite	是否允許該Cache被用作後續查詢的執行計畫最佳化。	必選
Provider	Cache資料的儲存格式，支援JSON、PARQUET、ORC等所有Spark支援的資料格式。	必選
Partition Columns	Cache資料的分區欄位。	可選
ZOrder Columns	ZOrder是一種支援多列排序的方法，Cache資料按照ZOrder欄位排序後，對於基於ZOrder欄位過濾的查詢會有更好的加速效果。	可選

cube_cache

JindoCube通過使用者指定的Dimension和Measure資訊來構建Cube，對於上圖的樣本，建立的Cube Cache可以用SQL表示為：

SELECT c_city, c_nation, c_region, MAX(lo_quantity), SUM(lo_tax)
FROM lineorder_flatten
GROUP BY c_city, c_nation, c_region;

JindoCube計算Cube的最細粒度維度組合，在最佳化使用更粗粒度的維度組合的查詢時，基於Spark強大的現場計算能力，通過重彙總實現。在定義Cube Cache時，必須使用JindoCube支援的預計算函數。JindoCube支援的預計算函數和其對應的彙總函式類型如下：

彙總函式類型	預計算函數
COUNT	COUNT
SUM	SUM
MAX	MAX
MIN	MIN
AVG	COUNT，SUM
COUNT（DISTINCT ）	PRE_COUNT_DISTINCT
APPROX_COUNT_DISTINCT	PRE_APPROX_COUNT_DISTINCT

在Cube Management頁面，展示所有的Cache列表。單擊Detail進入Cache的詳細頁面，在Cache詳細頁會展示Cache的詳細資料、包括基本資料、Cache資料分區資訊、構建Cache資訊以及構建歷史資訊等。

構建JindoCube。

建立JindoCube Cache只是進行中繼資料操作，Cache表示的資料並未持久化，需要繼續構建Cache，從而持久化Cache資料到HDFS或OSS等儲存中。此外Cache對應的源表資料可能會新增或者更新，需要更新Cache中的資料從而保持一致。JindoCube支援兩類構建操作：

Build Cache。

通過Build Cache連結，使用者可以主動觸發一次構建操作，構建頁面相關資訊如下： build_Cache

在構建JindoCube的Cache時，相關使用者選項如下：

參數

描述

Save Mode

支援Overwrite和Append兩種模式。

Overwrite：會覆蓋之前曾經構建的Cache資料。
Append：會新增資料到Cache中。

Optional Filter

使用者可以選擇額外的過濾條件，在構建時，將該Cache表示的資料過濾後再持久化。

Column：過濾欄位。
Filter Type：過濾類型，支援固定值和範圍值兩種。
- Fixed Values：指定過濾值，可以多個，以“,”分隔。
- Range Values：指定範圍值的最小和最大值，最大值可以為空白，過濾條件包含最小值，不包含最大值。

上圖中構建任務想要構建lineorder_flatten視圖的Raw Cache資料，要寫入Cache中的資料可以使用如下SQL表示：

SELECT * FROM lineorder_flatten
WHERE s_region == 'ASIA' OR s_region == 'AMERICA';

單擊Submit，提交構建任務，返回到Cache詳細頁面，對應的構建任務會提交到Spark叢集中執行，在Build Information中可以看到當前是否正在構建Cache的資訊。在Cache構建完成後，可以在Build History中看到相關的資訊。

說明

Cache資料由Spark任務寫到一個指定目錄中，和普通的Spark寫表或者寫目錄一樣，對於Parquet、Json、ORC等資料格式，並發構建同一個Cache可能導致Cache資料不準確，不可用，應避免這種情況。如果無法避免並發構建、更新Cache，可以考慮使用delta等支援並發寫的資料格式。

Trigger Period Build。

定期更新功能可以方便使用者佈建自動更新Cache的策略，保持Cache資料和源表資料的一致。相關頁面如下： Trigger_Period_build

定期更新的相關使用者選項如下：

參數	描述
Save Mode	支援Overwrite和Append兩種模式。 Overwrite：會覆蓋之前曾經構建的Cache資料。 Append：會新增資料到Cache中。
Trigger Strategy	觸發策略，設定觸發構建任務的開始時間和間隔時間。 Start At：通過時間控制項選擇或者手工輸入第一次觸發構建任務的時間點，日期格式為yyyy-MM-dd hh:mm:ss。 Period：設定觸發構建任務的間隔時間。
Optional Step	設定每次觸發構建任務的資料篩選條件，通過指定時間類型的欄位，配合觸發策略中的間隔時間，可以實現按照時間間隔增量的更新Cache。如果不選擇，每次全量更新Cache。 Step By：選擇累加式更新欄位類型，只支援時間類型欄位，包括Long類型的timestamp欄位，以及指定dateformat資訊的String類型欄位。 Column Name：累加式更新欄位名稱。

在Cache詳細頁面中，可以看到當前設定的定期更新策略，使用者可以隨時通過Cancel Period Build取消定期更新。所有觸發的構建任務資訊在完成後也可以在Build History列表中看到。

說明

定期更新任務是Spark叢集層級的，相關設定儲存在SparkContext中，並由Spark Driver定期觸發，當Spark叢集關閉後，定期更新任務也隨之關閉。
當前Spark叢集所有的構建任務完成後，都會展示在Build History列表中，包含開始/結束時間、SaveMode、構建條件，任務最終狀態等。Build History也是Spark叢集層級的資訊，當Spark叢集關閉後，相關資訊也隨之釋放。

管理JindoCube。

建立和構建JindoCube的Cache資料後，通過Cube Management的UI頁面，可以對JindoCube的Cache資料進行進一步的管理。
- 刪除cache。
  
  在JindoCube Cache列表頁面，可以通過action列的Drop刪除對應Cache，刪除成功後，Cache的相關中繼資料和儲存資料都會被清理。
- 開啟或關閉Cache最佳化。
  
  JindoCube支援在Cache層級，設定是否允許用於Spark查詢的最佳化，在Cache的詳細頁面，您可以通過基本資料中的Enabled或Disabled，啟用或者停用該Cache，控制是否允許該Cache用於查詢加速。
- 刪除分區資料。
  
  如果Cache的資料是按照分區儲存的，當確認某些分區資料不再需要時，刪除這些分區資料可以節省大量儲存空間。在Cache的詳細頁面，分區Cache的相關分區會通過列表展示，使用者可以通過Delete刪除特定分區的資料。
  
  說明
  在刪除Cache分區資料之前，請謹慎確認，確保該分區資料不會被使用。如果使用者的查詢經過最佳化需要用到該Cache被刪除的分區資料，會導致錯誤的查詢結果。
查詢最佳化。

目前JindoCube支援基於View的查詢最佳化，當使用者使用某個視圖建立了Raw Cache或者Cube Cache後，後續的查詢使用到了該視圖，EMR Spark會在滿足邏輯語義的前提下，嘗試使用Cache重寫查詢的執行計畫，新的執行計畫直接存取Cache資料，從而加速查詢速度。以如下情境為例，lineorder_flatten視圖是將lineorder和其他維度資料表關聯之後的大寬表視圖，其相關定義如下：

基於lineorder_flatten視圖簡單查詢的執行計畫如下：

在為line order_flatten視圖建立Raw Cache並構建完成後，執行相同查詢，EMR Spark會自動使用Cache資料最佳化執行計畫，最佳化後的執行計畫如下：

可以看到，最佳化後的執行計畫省去了lineorder_flatten視圖的所有計算邏輯，直接存取HDFS中Cache的資料。

注意事項

JindoCube並不保證Cache資料和源表資料的一致性，而是需要使用者通過手工觸發或者設定定期策略觸發更新任務同步Cache中的資料，使用者需要根據查詢對於資料一致性的需求，觸發Cache的更新任務。
在對查詢的執行計畫進行最佳化的時候，JindoCube根據視圖的中繼資料判斷是否可以使用Cache最佳化查詢的執行計畫。最佳化後，如果Cache的資料不完整，可能會影響查詢結果的完整性或正確性。可能導致Cache資料不完整的情況包括：使用者在Cache詳情頁主動刪除查詢需要的Cache Partition資料，構建、更新Cache時指定的過濾條件過濾掉了查詢需要的資料，查詢需要的資料還未及時更新到Cache等。