近日，Databricks 融資四個億估值 62 億美金的新聞引爆了整個技術圈。Spark 歷經 10 年發展，已經成爲當今最炙手可熱的開源技術框架之一。熟悉我司的朋友都知道，我們的最新產品已經實現了 all On Spark，不管是構建引擎還是查詢引擎，所有的管理全都基於 Spark 運作。全棧 Spark 架構不僅給構建和查詢帶來更好的性能，提升服務的時間響應的及時性，也能爲企業客戶減少採購成本和降低運維成本。
上個月 18 日，我們非常榮幸邀請到了 Spark PMC 李瀟來到 Kyligence 交流分享，在此也特別感謝大神不辭辛勞來我司交流分享。
李瀟：Databricks Engineering Manager，Apache Spark 項目 Committer & PMC，管理兩組跨國團隊，專注於 Apache Spark 和 Databricks Runtime 的開發和建設，同時也積極推進 Spark 開源社區的建設。（Github: gatorsmile）
Apache Spark & Databricks
Apache Spark 自 2009 年誕生與加州大學伯克利分校的 AMPLab 實驗室，歷經 10 年發展，全球超過 1400 位來自 300 多家企業和組織的工程師爲其貢獻代碼，是大數據處理領域事實上的業界標杆。Databricks 作爲 Spark 背後的公司，大名鼎鼎的“磚廠”，可謂陣容豪華，包括了 UC Berkeley 計算機教授、AMPLab 聯合創始人 Ion Stoica，UC Berkeley 計算機科學教授 Scott Shenker（Scott計算機歷史上論文被引用次數最高的人，同時也是知名SDN公司Nicira的聯合創始人及前CEO），Spark 原作者、Stanford 教授 Matei Zaharia。在不斷完善 Spark 的同時，還陸續推出了 Mlflow、Delta 等重磅產品。
本次分享着重介紹了 Spark 生態圈的最新動向。Delta Lake 這個最新的Spark Data Source 是如何解決 Spark 的各種痛點；以及 Spark 3.0 預覽版的衆多特性。特別是，深入講解了 Dynamic Partition Pruning 和 Adaptive Query Execution 優化是如何讓 Spark 更加容易使用並且快速執行。
Topic 1: Delta
傳統 Lambda 架構系統侷限性太大，爲了解決如下問題：
- 同時讀寫，並且要保證數據的一致性
- 可以高吞吐從大表讀數據
- 遇到錯誤寫出可以回滾和刪改
- 在線業務不下線的同時可以重新處理歷史數據
- 處理遲到數據而無需推遲下階段的數據處理
Databricks推出了全新的Delta架構（Structured Streaming + Delta Lake）：
Delta架構的特性：
- 持續的數據流入和處理 [再無 Lambda 架構的批流分離]
- 物化中間結果來改善可靠性和方便故障排查
- 基於用戶使用場景和商業需求做費用與延遲的取捨
- 根據查詢的常用模式來優化數據的物理存儲
- 歷史數據的再處理只需要刪除結果 table 重啓流處理
- 通 過 調 整 schema management，data expectations and UPDATE/DELETE/MERGE 來一步一步地改善數據 質量，直到數據可以被用於分析
Delta架構的優勢：
- 減少端到端的 pipeline SLA，多個使用單位把 data pipeline 的 SLA 從小時減少到分鐘級別
- 減少 pipeline 的維護成本，避免了爲了達到分鐘級別的用例延遲而引入 lambda 架構
- 更容易地處理數據更新和刪除，簡化了 change data capture, GDPR, Sessionization, 數據去冗
- 通過計算和存儲的分離和可彈縮從而降低了 infrastructure 的費用，多個使用單位將 infrastructure 的費用降低了超過十倍
Topic 2: Spark 3.0
Spark 3.0 預覽版引入了包括 Dynamic Partition Pruning，Adaptive Query Execution 等衆多新特性，而這些都離不開整個社區以及 Spark 背後的大廠們的共同努力與貢獻。
Dynamic Partition Pruning：Spark 2.x 查詢引擎的 CBO 的實際效果並不理想，主要是因爲以下 3 個問題，
- Missing Statistics (一次性計算 ETL workloads)
- Out-of-date Statistics (存儲與計算分離)
- Misestimated Costs (多樣部署環境 + UDFs)
對於 Query Optimization，在 Rule 和 Cost 的基礎上，Spark 3.0 中新增了 Runtime 級別的 Dynamic Partition Pruning，以此下圖查詢爲例， left table 上的 column filter 無法作用於 right table，因此 right table 還是需要 scan 大量數據，而事實上 join 的計算過程中只用到了 right table 的少量數據。如何去避免這種情況呢？答案就是 Dynamic Partition Pruning，通過在運行時將 left table pushdown 之後的結果 reuse，爲 right table 產生一個新的 filter，由此大幅減少 table scan，帶來性能上的巨大提升。
Adaptive Query Execution：通過動態的 Statistics 來做優化，在執行過程中，產生執行的部分 RDD 時，可以把這部分的 Statistics 結果收集起來，爲後續計算重新做優化，產生新的更優的執行計劃。以下圖查詢爲例，根據 Runtime Statistics，將 Sort Merge Join 優化成了 BroadCast Hash Join，由此大大提升了性能。但是 Adaptive Query Execution 默認是關閉的，因爲對於小查詢這個優化可能會帶來額外的消耗，以致性能反而變差。
Q & A
Q: Delta Lake 中樂觀併發控制如何判斷 who win when conflicts among transactions？
A: 這些判斷會依賴文件系統自身的原子性，在不同的環境中有不同的 commit service，比如 HDFS 本身就支持文件操作的原子性，所以對應的 commit service 可以通過直接調用 HDFS 的 api 的方式來進行操作。
Q: Delta Lake 主要解決了讀多寫少的場景，我們曾針對 Kyligence Enterprise 的用戶做過一系列調研，結果顯示，存在不少需要一個寫比較密集，而讀也需要很高的性能的方案的場景，對於這種場景你們是怎麼看待的？
A: Delta Lake 的確更適合少寫多讀的場景，我們也是做了取捨，具體情況還是要針對性地去做讀或者寫的優化。比如，將來我們可以稍微犧牲部分讀性能的情況下去做寫的優化時，就可以將寫產生的 change 保存在額外的 file 中，這樣就是寫得更快，但是每次需要多讀一個 file，並定時地合併。
Q：修改歷史版本數據，Delta Lake 能否支持？更新數據的成本如何？（Kyligence Enterprise 的用戶偶爾會有這種需求：對於歷史上已經計算完成的報表數據，用戶偶然會發現歷史數據中有少量錯誤數據，這導致計算出的 cube 數據也有偏差，此時用戶修改了原始數據後，就想對 cube 數據進行更正。Kyligence Enterprise 中想要完成數據修改，需要具備2個條件：1，歷史數據存在；2，能確認錯誤數據所屬時間段，由此可以對數據進行 refresh。但是計算量取決於包含錯誤數據的 cube segment 數據量的大小）
A：Delta Lake 中支持 Update，但是影響到的數據範圍會由業務來判斷，可能影響很大，取決於影響到的 file 數和 file的大小。
Q: Spark 是如何讓業務知道自己是否適合這個平臺，或者說如何讓用戶能輕鬆地意識到這個查詢是否適合？
A: 我們 Databricks 會自動地提供 Tips（提示），目前，對於有些業務，的確存在性能達不到或者不合適的情況，但是理論上都是可以做到的，不過有些需要新實現訂製的版本來支持；在我們的平臺上，當用戶的任務運行完成之後，平臺自動能給出一些建議（Tips），比如通過開關某個 feature 或者修改部分配置來提升性能。
Q: Spark 中 CBO 效果不好，其中一個原因是 Statistics 的缺失，那很多 ETL 或者數據分析，用戶的數據都是按天增量的，這些增量數據的 Statistics 是否能從歷史數據中獲取？
A: 所有對於具體 workload 或者具體使用環境做出的優化都是能夠提升 Spark 的表現，但是 Spark 作爲一個普適的查詢引擎，很難以一個 general 的方式去解決所有的問題。反過來說，Delta 是另一個外部數據源（date source），因爲它是擁有數據的，它有大量的空間可以根據 Statistics 去做優化，對於外部數據源，Delta 需要自己的定製優化去改善查詢。是否擁有數據這裏是有本質區別的。
Q: Kyligence 目前在根據查詢 sql 的執行計劃樹和一些 Statistics 來預測 Spark job 的最佳配置，由此來降低 Kyligence Enterprise 用戶的使用和調優成本，社區是否重視這個？
A: 我們認爲這個是很重要的，但是目前很難設計一套普適的方案去解決所有的配置調優問題，根據用戶場景的不同，他們會有自己的方案，而且這些調優通常在 Spark 外部的系統（使用 Spark 的系統）去解決。目前 Spark 用戶也相對資深，Spark 提供各種接口，用戶可以插入定製的調優，像 Linkedin，Facebook, Netflix 都在做類似的事情。
Q: Spark 中 parquet 沒有 IO 級別的 index，這是爲什麼？
A: Spark 作爲一個計算引擎，是不擁有數據的，在沒有數據特徵的情況下去做 index 並沒有太大的意義，所以 Spark 不做這些。Delta 裏面是做了的，因爲 Delta 是擁有數據的。
Q: 使用 Spark 時，如果只對少量表做 Broadcast，的確能提升性能，但是如果同時對多張表進行 Broadcast 會引發 driver 的內存問題，或者 Shuffle statistics 很大很多的情況下，driver 端也會有內存問題，如何解決這種問題？
A: 我們下個 release Spark 3.0 將支持所有 join algorithm 的 Hint。用戶可以更方便地選擇最適合的算法，來提升自己的查詢。driver 端的全局內存管理是需要重構，現在做的各種優化和改善都還沒有解決本質問題。
Q: Structured Streaming 持續數據流的 limitation 解決地如何？
A: 由於超低延時的持續數據流的需求不是那麼大，目前流處理團隊在解決流處理的最痛的痛點，比如大量小文件和讀寫原子性，因此主要投入在 Delta 的研發，持續數據流暫時沒有投入過多的資源。
