本次分享主要分為以下四個方面：

1. 項目介紹
2. 技術分析
3. 如何使用
4. 性能分析

一、項目介紹

項目背景

阿里雲EMR是一個開源大數據解決方案，目前EMR上面已經集成了很多開源組件，並且組件數量也在不斷的增加中。EMR下層可以訪問各種各樣的存儲，比如對象存儲OSS、集群內部自建的HDFS以及流式數據等。用戶可以利用EMR處理海量數據和進行快速分析，也能夠支持用戶在上面做機器學習以及數據清洗等工作。EMR希望能夠支撐非常大的業務數據量，同時也希望能夠在數據量不斷增長的時候，能夠通過集群擴容實現快速數據分析。

雲上Adhoc數據分析痛點

在雲上做Adhoc數據分析的時候，很難實現隨著數據量的增長使得查詢的延遲不會大幅度增加。雖然目前各種引擎不斷出現，並且某些引擎在一些場景下運行很快，但是數據量變大之後，查詢響應速度難免有所下降，因此希望在比較統一的平臺之上獲得較好的性能。與此同時，阿里雲也希望能夠提供雲原生的解決方案。Spark是目前工業界使用較多的計算引擎，應用非常廣泛，但是在處理Adhoc上還是存在很多不足之處，因此阿里雲在Spark上做了大量優化，幫助用戶滿足Adhoc查詢的需求。因此就會涉及到緩存方案，雖然Spark中很早就有了緩存機制，但想要滿足雲上Adhoc場景卻存在很多不足之處，因此阿里雲會在Spark上做大量優化，幫助用戶優化Adhoc查詢速度。但是如果把數據放到內存中，將所有數據全部用作緩存可能也不足夠，因此就催生出了Spark Relational Cache。

Spark Relational Cache

用戶的SQL請求過來之後，到了Spark上面，會需要比較長的時間在數據來源上進行處理，這裡下層的存儲包括集群的HDFS以及遠端的JindoFS和阿里雲OSS等。當有了Spark Relational Cache之後，查詢過來之後會查詢是否能夠用到存儲在Relational Cache中緩存的數據，如果不能用到則會轉發到原生路徑上，如果能用到則會用非常快的速度從緩存裡面將數據讀取出來並將結果返回給用戶。因為Relational Cache構建在高效存儲之上，通過用戶的DDL將數據變成Relational Cache。

Spark Relational Cache特點

Spark Relational Cache希望能夠達到秒級響應或者亞秒級響應，能夠在提交SQL之後很快地看到結果。並且也支持很大的數據量，將其存儲在持久化的存儲上面，同時通過一些匹配手段，增加了匹配的場景。此外，下層存儲也使用了高效的存儲格式，比如離線分析都會使用的列式存儲，並且對於列式存儲進行了大量優化。此外，Relational Cache也是用戶透明的特性，用戶上來進行查詢不需要知道幾個表之間的關係，這些都是已經有過緩存的，不需要根據已有的緩存重寫Query，可以直接判斷是否有可以使用的Relational Cache，對於一個廠商而言只需要幾個管理員進行維護即可。Spark Relational Cache支持自動更新，用戶不需要擔心因為插入了新的數據就使得Cache過時導致查詢到錯誤的數據，這裡面為用戶提供了一些設置的規則，幫助用戶去進行更新。此外，Spark Relational Cache還在研發方面，比如智能推薦方面進行了大量探索，比如根據用戶SQL的歷史可以推薦用戶基於怎樣的關係去建立Relational Cache。

二、技術分析

阿里雲EMR具有很多核心技術，如數據預計算、查詢自動匹配以及數據預組織。

數據預計算

數據在很多情況下都有一個模型，雪花模型是傳統數據庫中非常常見的模型，阿里雲EMR添加了Primary Key/Foreign Key的支持，允許用戶通過Primary Key/Foreign Key明確表之間的關係，提高匹配成功率。在數據預計算方面，充分利用EMR Spark加強的計算能力。此外，還通過Data Cube數據立方來支持多維數據分析。

執行計劃重寫

這部分首先通過數據預計算生成預計算的結果，並將結果存儲在外部存儲上，比如OSS、HDFS以及其他第三方存儲中，對於Spark DataSource等數據格式都支持，對於DataLake等熱門的存儲格式後續也會添加支持。在傳統數據庫中有類似的優化方案，比如物化視圖方式，而在Spark中使用這樣的方式就不合適了，將邏輯匹配放在了Catalyst邏輯優化器內部來重寫邏輯執行計劃，判斷Query能否通過Relational Cache實現查詢，並基於Relational Cache實現進一步的Join或者組合。將簡化後的邏輯計劃轉化成為物理計劃在物理引擎上執行。依託EMR Spark其他的優化方向可以實現非常快速的執行結果，並且通過開關控制執行計劃的重寫。

自動查詢匹配

這裡有一個簡單的例子，將三個表簡單地Join在一起，經過過濾條件獲得最終的結果。當Query過來之後先判斷Spark Relational Cache是否能夠符合需求，進而實現對於預先計算好的結果進行過濾，進而得到最終想要的結果。

數據預組織

如果將數十T的數據存在存儲裡面，那麼從這個關係中獲取最終的結果還需要不少的時間，因為需要啟動不少的Task節點，而這些Task的調度也需要不少的開銷，通過文件索引的方式將時間開銷壓縮到秒級水平，可以在執行時過濾所需要讀取的文件總量，這樣大大減少了任務的數量，這樣執行的速度就會快很多。因為需要讓全局索引變得更加有效，因此最好讓數據是排過序的，如果對於結構化數據進行排序就會知道只是對於排列在第一位的Key有一個非常好的優化效果，對於排列在後面的Key比較困難，因此引入了ZOrder排序，使得列舉出來的每個列都具有同等的效果。同時將數據存儲在分區表裡，使用GroupID作為分區列。

三、如何使用

DDL

對於簡單的Query，可以指定自動更新的開關，並起一個名字方便後續管理。還可以規定數據Layout的形式，並最終通過SQL語句來描述關係，後續提供給用戶WebUI一樣的東西，方便用戶管理Relational Cache。

數據更新

Relational Cache的數據更新主要有兩種策略，一種是On Commit，比如當依賴的數據發生更新的時候，可以將所有需要添加的數據都追加寫進去。還有一種默認的On Demand形式，用戶通過Refresh命令手動觸發更新，可以在創建的時候指定，也可以在創建之後手工調整。Relational Cache增量的更新是基於分區實現的，後續會考慮集成一些更加智能的存儲格式，來支持行級別的更新。

四、性能分析

Cube構建

阿里巴巴的EMR Spark對於1T數據的構建時間只需要1小時。

查詢性能

在查詢性能方面，SSB平均查詢耗時，無Cache時查詢 時間按Scale成比例增加，Cache Cube後始終保持在亞秒級響應。

阿里雲雙11領億元補貼，拼手氣抽iPhone 11 Pro、衛衣等好禮，點此參與：http://t.cn/Ai1hLLJT