Spark Relational Cache實現亞秒級響應的交互式分析

本場視頻連接：https://developer.aliyun.com/live/1548?spm=a2c6h.12873581.0.0.71671566Xloy3Z&groupCode=apachespark

本場PPT資料：https://www.slidestalk.com/AliSpark/SparkRelationalCache2019_57927

本次分享主要分爲如下四個方面：

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

1、項目介紹

項目背景

阿里雲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。

2、技術分析

阿里雲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做爲分區列。

3、如何使用

DDL

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

數據更新

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

4、性能分析

Cube構建

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

查詢性能

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

相關文章：EMR Spark Relational Cache 利用數據預組織加速查詢

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

---

本文做者：開源大數據EMR

閱讀原文

本文爲雲棲社區原創內容，未經容許不得轉載。