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 相關文章： 2019杭州雲栖大會回顧之Spark Relational Cache實作亞秒級響應的互動式分析 本次分享主要分為以下四個方面：

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後始終保持在亞秒級響應。

相關技術文章：

EMR Spark Relational Cache 利用資料預組織加速查詢

阿裡巴巴開源大資料技術團隊成立Apache Spark中國技術社群，定期推送精彩案例，技術專家直播，問答區數個Spark技術同學每日線上答疑，隻為營造純粹的Spark氛圍，歡迎釘釘掃碼加入！