2020年6月18日，開發了近兩年（自2018年10月份至今）的Apache Spark 3.0.0 正式釋出！
Apache Spark 3.0.0版本包含3400多個更新檔，是開源社群做出巨大貢獻的結晶，在Python和SQL功能方面帶來了重大進展并且将重點聚焦在了開發和生産的易用性上。同時，今年也是Spark開源10周年，這些舉措反映了Spark自開源以來，是如何不斷的滿足更廣泛的閱聽人需求以及更多的應用場景。
首先來看一下Apache Spark 3.0.0主要的新特性：
- 在TPC-DS基準測試中，通過啟用自适應查詢執行、動态分區裁剪等其他優化措施，相比于Spark 2.4，性能提升了2倍
- 相容ANSI SQL
- 對pandas API的重大改進，包括python類型hints及其他的pandas UDFs
- 簡化了Pyspark異常，更好的處理Python error
- structured streaming的新UI
- 在調用R語言的UDF方面，速度提升了40倍
- 超過3400個Jira問題被解決，這些問題在Spark各個核心元件中分布情況如下圖：
此外，采用Spark3.0版本，主要代碼并沒有發生改變。
改進的Spark SQL引擎
Spark SQL是支援大多數Spark應用的引擎。例如，在Databricks，超過 90％的Spark API調用使用了DataFrame、Dataset和SQL API及通過SQL優化器優化的其他lib包。這意味着即使是Python和Scala開發人員也通過Spark SQL引擎處理他們的大部分工作。
如下圖所示，Spark3.0在整個runtime，性能表現大概是Spark2.4的2倍：
接下來，我們将介紹Spark SQL引擎的新特性。
即使由于缺乏或者不準确的資料統計資訊和對成本的錯誤估算導緻生成的初始計劃不理想，但是自适應查詢執行（Adaptive Query Execution）通過在運作時對查詢執行計劃進行優化，允許Spark Planner在運作時執行可選的執行計劃，這些計劃将基于運作時統計資料進行優化，進而提升性能。
由于Spark資料存儲和計算是分離的，是以無法預測資料的到達。基于這些原因，對于Spark來說，在運作時自适應顯得尤為重要。AQE目前提供了三個主要的自适應優化：
- 動态合并shuffle partitions
可以簡化甚至避免調整shuffle分區的數量。使用者可以在開始時設定相對較多的shuffle分區數，AQE會在運作時将相鄰的小分區合并為較大的分區。
- 動态調整join政策
在一定程度上避免由于缺少統計資訊或着錯誤估計大小（當然也可能兩種情況同時存在），而導緻執行次優計劃的情況。這種自适應優化可以在運作時sort merge join轉換成broadcast hash join，進而進一步提升性能
- 動态優化傾斜的join（skew joins）
skew joins可能導緻負載的極端不平衡，并嚴重降低性能。在AQE從shuffle檔案統計資訊中檢測到任何傾斜後，它可以将傾斜的分區分割成更小的分區，并将它們與另一側的相應分區連接配接起來。這種優化可以并行化傾斜處理，獲得更好的整體性能。
基于3TB的TPC-DS基準測試中，與不使用AQE相比，使用AQE的Spark将兩個查詢的性能提升了1.5倍以上，對于另外37個查詢的性能提升超過了1.1倍。
動态分區裁剪
當優化器在編譯時無法識别可跳過的分區時，可以使用"動态分區裁剪"，即基于運作時推斷的資訊來進一步進行分區裁剪。這在星型模型中很常見，星型模型是由一個或多個并且引用了任意數量的次元表的事實表組成。在這種連接配接操作中，我們可以通過識别次元表過濾之後的分區來裁剪從事實表中讀取的分區。在一個TPC-DS基準測試中，102個查詢中有60個查詢獲得2到18倍的速度提升。
更多動态分區裁剪介紹可參考：https://databricks.com/session_eu19/dynamic-partition-pruning-in-apache-spark#:~:text=Dynamic%20partition%20pruning%20occurs%20when,any%20number%20of%20dimension%20tables
ANSI SQL相容性
對于将工作負載從其他SQL引擎遷移到Spark SQL來說至關重要。為了提升相容性，該版本采用Proleptic Gregorian月曆，使用者可以禁止使用ANSI SQL的保留關鍵字作為辨別符。此外，在數字類型的操作中，引入運作時溢出檢查，并在将資料插入具有預定義schema的表時引入了編譯時類型強制檢查，這些新的校驗機制提高了資料的品質。更多ASNI相容性介紹，可參考：https://spark.apache.org/docs/3.0.0/sql-ref-ansi-compliance.html
Join hints
盡管社群一直在改進編譯器，但仍然不能保證編譯器可以在任何場景下做出最優決策——join算法的選擇是基于統計和啟發式算法。當編譯器無法做出最佳選擇時，使用者可以使用join hints來影響優化器以便讓它選擇更好的計劃。
Apache Spark 3.0對已存在的join hints進行擴充，主要是通過添加新的hints方式來進行的，包括：
SHUFFLE_MERGE、SHUFFLE_HASH和SHUFFLE_REPLICATE_NL。
增強的Python API：PySpark和Koalas
Python現在是Spark中使用較為廣泛的程式設計語言，是以也是Spark 3.0的重點關注領域。Databricks有68％的notebook指令是用Python寫的。PySpark在 Python Package Index上的月下載下傳量超過 500 萬。
很多Python開發人員在資料結構和資料分析方面使用pandas API，但僅限于單節點處理。Databricks會持續開發Koalas——基于Apache Spark的pandas API實作，讓資料科學家能夠在分布式環境中更高效地處理大資料。
通過使用Koalas，在PySpark中，資料科學家們就不需要建構很多函數（例如，繪圖支援），進而在整個叢集中獲得更高性能。
經過一年多的開發，Koalas實作對pandas API将近80%的覆寫率。Koalas每月PyPI下載下傳量已迅速增長到85萬，并以每兩周一次的釋出節奏快速演進。雖然Koalas可能是從單節點pandas代碼遷移的最簡單方法，但很多人仍在使用PySpark API，也意味着PySpark API也越來越受歡迎。
Spark 3.0為PySpark API做了多個增強功能：
-
帶有類型提示的新pandas API
pandas UDF最初是在Spark 2.3中引入的，用于擴充PySpark中的使用者定義函數，并将pandas API內建到PySpark應用中。但是，随着UDF類型的增多，現有接口就變得難以了解。該版本引入了一個新的pandas UDF接口，利用Python的類型提示來解決pandas UDF類型激增的問題。新接口變得更具Python風格化和自我描述性。
-
新的pandas UDF類型和pandas函數API
該版本增加了兩種新的pandas UDF類型，即系列疊代器到系列疊代器和多個系列疊代器到系列疊代器。這對于資料預取和昂貴的初始化操作來說非常有用。此外，該版本還添加了兩個新的pandas函數API，map和co-grouped map。更多詳細資訊請參考：https://databricks.com/blog/2020/05/20/new-pandas-udfs-and-python-type-hints-in-the-upcoming-release-of-apache-spark-3-0.html。
-
更好的錯誤處理
對于Python使用者來說，PySpark的錯誤處理并不友好。該版本簡化了PySpark異常，隐藏了不必要的JVM堆棧跟蹤資訊，并更具Python風格化。
改進Spark中的Python支援和可用性仍然是我們最優先考慮的問題之一。
Hydrogen、流和可擴充性
Spark 3.0完成了Hydrogen項目的關鍵元件，并引入了新功能來改善流和可擴充性。
-
加速器感覺排程
Hydrogen項目旨在更好地統一基于Spark的深度學習和資料處理。GPU和其他加速器已經被廣泛用于加速深度學習工作負載。為了使Spark能夠利用目标平台上的硬體加速器，該版本增強了已有的排程程式，使叢集管理器可以感覺到加速器。使用者可以通過配置來指定加速器（詳細配置介紹可參考：https://spark.apache.org/docs/3.0.0/configuration.html#custom-resource-scheduling-and-configuration-overview）。然後，使用者可以調用新的RDD API來利用這些加速器。
-
結構化流的新UI
結構化流最初是在Spark 2.0中引入的。在Databricks，使用量同比增長4倍後，每天使用結構化流處理的記錄超過了5萬億條。
Apache Spark添加了一個專門的新Spark UI用于檢視流jobs。新UI提供了兩組統計資訊：
- 流查詢作業已完成的聚合資訊
- 流查詢的詳細統計資訊，包括Input Rate, Process Rate, Input Rows, Batch Duration, Operation Duration等
- 可觀察的名額
持續監控資料品質變化是管理資料管道的一種重要功能。Spark 3.0引入了對批處理和流應用程式的功能監控。可觀察的名額是可以在查詢上定義的聚合函數（DataFrame）。一旦DataFrame執行達到一個完成點（如，完成批查詢）後會發出一個事件，該事件包含了自上一個完成點以來處理的資料的名額資訊。
- 新的目錄插件API
現有的資料源API缺乏通路和操作外部資料源中繼資料的能力。新版本增強了資料源V2 API，并引入了新的目錄插件API。對于同時實作了目錄插件API和資料源V2 API的外部資料源，使用者可以通過辨別符直接操作外部表的資料和中繼資料（在相應的外部目錄注冊了之後）。
Spark 3.0的其他更新
Spark 3.0是社群的一個重要版本，解決了超過3400個Jira問題，這是440多個contributors共同努力的結果，這些contributors包括個人以及來自Databricks、谷歌、微軟、英特爾、IBM、阿裡巴巴、Facebook、英偉達、Netflix、Adobe等公司的員工。
在這篇博文中，我們重點介紹了Spark在SQL、Python和流技術方面的關鍵改進。
除此之外，作為裡程碑的Spark 3.0版本還有很多其他改進功能在這裡沒有介紹。詳情可以查閱版本發行說明：https://spark.apache.org/releases/spark-release-3-0-0.html。發行文檔中提供了更多詳盡的本次版本的改進資訊，包括資料源、生态系統、監控等。
最後，熱烈祝賀Spark開源發展10周年！
Spark誕生于UC Berkeley’s AMPlab，該實驗室緻力于資料密集型計算的研究。AMPLab研究人員與大型網際網路公司合作，緻力于解決資料和AI問題。但是他們發現，對于那些那些擁有海量資料并且資料不斷增長的公司同樣面臨類似的問題需要解決。于是，該團隊研發了一個新引擎來處理這些新興的工作負載，同時使處理資料的APIs，對于開發人員更友善使用。
社群很快将Spark擴充到不同領域，在流、Python和SQL方面提供了新功能，并且這些模式現在已經構成了Spark的一些主要用例。作為資料處理、資料科學、機器學習和資料分析工作負載事實上的引擎，持續不斷的投入成就了Spark的今天。Apache Spark 3.0通過對SQL和Python（如今使用Spark的兩種最廣泛的語言）支援的顯著改進，以及對性能、可操作性等方面的優化，延續了這種趨勢。
本文主要參考自Databricks部落格和Apache Spark官網，包括不局限于以下文章：
1.https://databricks.com/blog/2020/06/18/introducing-apache-spark-3-0-now-available-in-databricks-runtime-7-0.html
2.https://spark.apache.org/releases/spark-release-3-0-0.html
關于Apache SparkTM 3.0.0重要特性更詳盡的介紹，除了文中内容，也可參考來自Databricks的其他技術部落格：
- Adaptive Query Execution blog
https://databricks.com/blog/2020/05/29/adaptive-query-execution-speeding-up-spark-sql-at-runtime.html
- Pandas UDFs and Python Type Hints blog
https://databricks.com/blog/2020/05/20/new-pandas-udfs-and-python-type-hints-in-the-upcoming-release-of-apache-spark-3-0.html