Spark 3.0.0正式版發佈,開發近兩年新增了哪些特性?

原計劃在2019年年底發佈的 Apache Spark 3.0.0 今天終於趕在下週二舉辦的 Spark Summit AI 會議之前正式發佈了! 

Apache Spark 3.0.0 自2018年10月02日開發到目前已經經歷了近21個月!這個版本的發佈經歷了兩個預覽版以及三次投票:

  • 2019年11月06日第一次預覽版,參見Preview release of Spark 3.0[1]

  • 2019年12月23日第二次預覽版,參見Preview release of Spark 3.0[2]

  • 2020年03月21日 [VOTE] Apache Spark 3.0.0 RC1[3]

  • 2020年05月18日 [VOTE] Apache Spark 3.0 RC2[4]

  • 2020年06月06日 [vote] Apache Spark 3.0 RC3[5]

Apache Spark 3.0 增加了很多令人興奮的新特性,包括:

  • 動態分區修剪(Dynamic Partition Pruning)

  • 自適應查詢執行(Adaptive Query Execution)

  • 加速器感知調度(Accelerator-aware Scheduling)

  • 支持 Catalog 的數據源API(Data Source API with Catalog Supports)

  • SparkR 中的向量化(Vectorization in SparkR)

  • 支持 Hadoop 3/JDK 11/Scala 2.12 等等。

這個版本一共解決了 3400 多個 ISSUES。

這 3400 多個 issues 在 Spark 各個組件的分佈情況如下:


Apache Spark 3.0.0 中主要特性如下:

關於這些比較重要的特性我已經在 這個分類裏面進行了介紹,感興趣的同學可以去看看。下面我們來快速看看 Spark 3.0 比較重要的新特性吧。比較全面的可以到 Spark Release 3.0.0 這裏看看。

動態分區修剪(Dynamic Partition Pruning)

所謂的動態分區裁剪就是基於運行時(run time)推斷出來的信息來進一步進行分區裁剪。舉個例子,我們有如下的查詢:

SELECT * FROM dim_iteblog 
JOIN fact_iteblog 
ON (dim_iteblog.partcol = fact_iteblog.partcol) 
WHERE dim_iteblog.othercol > 10

假設 dim_iteblog 表的 dim_iteblog.othercol > 10 過濾出來的數據比較少,但是由於之前版本的 Spark 無法進行動態計算代價,所以可能會導致 fact_iteblog 表掃描出大量無效的數據。有了動態分區裁減,可以在運行的時候過濾掉 fact_iteblog 表無用的數據。經過這個優化,查詢掃描的數據大大減少,性能提升了 33 倍。

在 TPC-DS 基準測試中,102個查詢中的60個得到2到18倍的加速。

這個特性對應的 ISSUE 可以參見 SPARK-11150 和 SPARK-28888。具體請參見《Apache Spark 3.0 動態分區裁剪(Dynamic Partition Pruning)介紹》《Apache Spark 3.0 動態分區裁剪(Dynamic Partition Pruning)使用》

自適應查詢執行(Adaptive Query Execution)

自適應查詢執行(又稱 Adaptive Query Optimisation 或者 Adaptive Optimisation)是對查詢執行計劃的優化,允許 Spark Planner 在運行時執行可選的執行計劃,這些計劃將基於運行時統計數據進行優化。

早在2015年,Spark 社區就提出了自適應執行的基本想法,在 Spark 的 DAGScheduler 中增加了提交單個 map stage 的接口,並且在實現運行時調整 shuffle partition 數量上做了嘗試。但目前該實現有一定的侷限性,在某些場景下會引入更多的 shuffle,即更多的 stage,對於三表在同一個 stage 中做 join 等情況也無法很好的處理;而且使用當前框架很難靈活地在自適應執行中實現其他功能,例如更改執行計劃或在運行時處理傾斜的 join。所以該功能一直處於實驗階段,配置參數也沒有在官方文檔中提及。這個想法主要來自英特爾以及百度的大牛,具體參見 SPARK-9850,對應的文章可以參見《Apache Spark SQL自適應執行實踐》

而 Apache Spark 3.0 的 Adaptive Query Execution(AQE) 是基於 SPARK-9850 的思想而實現的,具體參見 SPARK-23128。SPARK-23128 的目標是實現一個靈活的框架以在 Spark SQL 中執行自適應執行,並支持在運行時更改 reducer 的數量。新的實現解決了前面討論的所有限制,其他功能(如更改 join 策略和處理傾斜 join)將作爲單獨的功能實現,並作爲插件在後面版本提供。

AQE 框架目前提供了三個功能:

動態合併 shuffle partitions;動態調整 join 策略;動態優化傾斜的 join(skew joins)。

基於沒有統計數據的 1TB TPC-DS 基準,Spark 3.0 可以使 q77 的速度提高8倍,使 q5 的速度提高2倍,而對另外26個查詢的速度提高1.1倍以上。可以通過設置 SQL 配置 spark.sql.adaptive=true 來啓用 AQE,這個參數默認值爲 false。

加速器感知調度(Accelerator-aware Scheduling)

如今大數據和機器學習已經有了很大的結合,在機器學習裏面,因爲計算迭代的時間可能會很長,開發人員一般會選擇使用 GPU、FPGA 或 TPU 來加速計算。在 Apache Hadoop 3.1 版本里面已經開始內置原生支持 GPU 和 FPGA 了。作爲通用計算引擎的 Spark 肯定也不甘落後,來自 Databricks、NVIDIA、Google 以及阿里巴巴的工程師們正在爲 Apache Spark 添加原生的 GPU 調度支持,該方案填補了 Spark 在 GPU 資源的任務調度方面的空白,有機地融合了大數據處理和 AI 應用,擴展了 Spark 在深度學習、信號處理和各大數據應用的應用場景。這項工作的 issue 可以在 SPARK-24615 裏面查看,相關的 SPIP(Spark Project Improvement Proposals) 文檔可以參見 SPIP: Accelerator-aware scheduling[6]

目前 Apache Spark 支持的資源管理器 YARN 和 Kubernetes 已經支持了 GPU。爲了讓 Spark 也支持 GPUs,在技術層面上需要做出兩個主要改變:

在 cluster manager 層面上,需要升級 cluster managers 來支持 GPU。並且給用戶提供相關 API,使得用戶可以控制 GPU 資源的使用和分配。在 Spark 內部,需要在 scheduler 層面做出修改,使得 scheduler 可以在用戶 task 請求中識別 GPU 的需求,然後根據 executor 上的 GPU 供給來完成分配。

因爲讓 Apache Spark 支持 GPU 是一個比較大的特性,所以項目分爲了幾個階段。在 Apache Spark 3.0 版本,將支持在 standalone、 YARN 以及 Kubernetes 資源管理器下支持 GPU,並且對現有正常的作業基本沒影響。對於 TPU 的支持、Mesos 資源管理器中 GPU 的支持、以及 Windows 平臺的 GPU 支持將不是這個版本的目標。而且對於一張 GPU 卡內的細粒度調度也不會在這個版本支持;Apache Spark 3.0 版本將把一張 GPU 卡和其內存作爲不可分割的單元。詳情請參見《Apache Spark 3.0 將內置支持 GPU 調度》文章。

Apache Spark DataSource V2

Data Source API 定義如何從存儲系統進行讀寫的相關 API 接口,比如 Hadoop 的 InputFormat/OutputFormat,Hive 的 Serde 等。這些 API 非常適合用戶在 Spark 中使用 RDD 編程的時候使用。使用這些 API 進行編程雖然能夠解決我們的問題,但是對用戶來說使用成本還是挺高的,而且 Spark 也不能對其進行優化。爲了解決這些問題,Spark 1.3 版本開始引入了 Data Source API V1,通過這個 API 我們可以很方便的讀取各種來源的數據,而且 Spark 使用 SQL 組件的一些優化引擎對數據源的讀取進行優化,比如列裁剪、過濾下推等等。

Data Source API V1 爲我們抽象了一系列的接口,使用這些接口可以實現大部分的場景。但是隨着使用的用戶增多,逐漸顯現出一些問題:

部分接口依賴 SQLContext 和 DataFrame擴展能力有限,難以下推其他算子缺乏對列式存儲讀取的支持缺乏分區和排序信息寫操作不支持事務不支持流處理

爲了解決 Data Source V1 的一些問題,從 Apache Spark 2.3.0 版本開始,社區引入了 Data Source API V2,在保留原有的功能之外,還解決了 Data Source API V1 存在的一些問題,比如不再依賴上層 API,擴展能力增強。Data Source API V2 對應的 ISSUE 可以參見 SPARK-15689。雖然這個功能在 Apache Spark 2.x 版本就出現了,但是不是很穩定,所以社區對 Spark DataSource API V2 的穩定性工作以及新功能分別開了兩個 ISSUE:SPARK-25186 以及 SPARK-22386。Spark DataSource API V2 最終穩定版以及新功能將會隨着年底和 Apache Spark 3.0.0 版本一起發佈,其也算是 Apache Spark 3.0.0 版本的一大新功能。

更多關於 Apache Spark DataSource V2 的詳細介紹請參見 Apache Spark DataSource V2 介紹及入門編程指南(上) 和 Apache Spark DataSource V2 介紹及入門編程指南(下) 兩篇文章的介紹。

豐富的 API 和功能

爲了滿足新的用例並簡化 Spark 應用程序的開發,Apache Spark 3.0 版本提供了新的功能並增強了現有的功能。

增強的 pandas UDF

Pandas UDF 最初是在 Spark 2.3 中引入的,用於擴展 PySpark 中 UDF 並將 pandas API 集成到 PySpark 應用程序中。但是,當添加更多 UDF 類型時,現有接口很難理解。爲了解決這個問題,Spark 3.0 引入了帶有 Python 類型提示的新 pandas UDF 接口。此版本增加了兩種新的 pandas UDF 類型:iterator of series to iterator of series 和 iterator of multiple series to iterator of series,以及三個新的 pandas 函數 API:grouped map、map 和 co-grouped map。詳細介紹可以參見 Apache Spark 3.0 新的 Pandas UDF 及 Python Type Hints:https://www.iteblog.com/archives/9814.html。

一組完整的 join hints

儘管社區不斷提高編譯器的智能性,但不能保證編譯器始終可以針對每種情況做出最佳決策。Join 算法的選擇基於統計和啓發式算法,當編譯器無法做出最佳選擇時,用戶仍然可以使用 join hints 來影響優化器選擇更好的計劃。Apache Spark 3.0 通過添加新的 hints 擴展了現有的 join hints :SHUFFLE_MERGE、SHUFFLE_HASH 和 SHUFFLE_REPLICATE_NL

新的內置函數

Scala API 中增了32個新的內置函數和高階函數。在這些內置函數中,添加了一組針對 MAP 的特定內置函數[transform_key,transform_value,map_entries,map_filter,map_zip_with],以簡化對 MAP 數據類型的處理。

增強的監控功能

Apache Spark 在監控方面也包含許多增強功能,這些功能使監控更加全面和穩定。這些增強的監控功能不會對性能產生重大影響。主要可以分爲以下三個地方。

重新設計 Structured streaming 的 UI

Structured streaming 最初是在 Spark 2.0 中引入的。Spark 3.0 爲監控這些流作業重新設計了 UI。這個新的 UI 提供了兩組統計信息:

已完成的流查詢作業的聚合信息流查詢的詳細統計信息,包括 Input Rate, Process Rate, Input Rows, Batch Duration, Operation Duration 等

增強 EXPLAIN 命令

讀取計劃(Reading plans)對理解和調優查詢非常重要。現有的解決方案看起來很混亂,每個算子的字符串表示可能非常寬,甚至可能被截斷。Spark 3.0 版本使用一種新的格式化(FORMATTED)模式對其進行了增強,並且還提供了將計劃轉儲到文件的功能。

可觀察的指標

連續監視數據質量的變化是管理數據管道非常需要的特性。Spark 3.0 版本爲批處理和流處理應用程序引入了這種功能。可觀察指標被命名爲可以在查詢上定義的任意聚合函數(dataframe)。一旦 dataframe 的執行到達一個完成點(例如,完成批查詢),就會發出一個命名事件,其中包含自上一個完成點以來處理的數據的指標。

更好的 ANSI SQL 兼容

PostgreSQL 是最先進的開源數據庫之一,其支持 SQL:2011 的大部分主要特性,完全符合 SQL:2011 要求的 179 個功能中,PostgreSQL 至少符合 160 個。Spark 社區目前專門開了一個 ISSUE SPARK-27764 來解決 Spark SQL 和 PostgreSQL 之間的差異,包括功能特性補齊、Bug 修改等。功能補齊包括了支持 ANSI SQL 的一些函數、區分 SQL 保留關鍵字以及內置函數等。這個 ISSUE 下面對應了 231 個子 ISSUE,如果這部分的 ISSUE 都解決了,那麼 Spark SQL 和 PostgreSQL 或者 ANSI SQL:2011 之間的差異更小了。

SparkR 向量化讀寫

Spark 是從 1.4 版本開始支持 R 語言的,但是那時候 Spark 和 R 進行交互的架構圖如下:

每當我們使用 R 語言和 Spark 集羣進行交互,需要經過 JVM ,這也就無法避免數據的序列化和反序列化操作,這在數據量很大的情況下性能是十分低下的!

而且 Apache Spark 已經在許多操作中進行了向量化優化(vectorization optimization),例如,內部列式格式(columnar format)、Parquet/ORC 向量化讀取、Pandas UDFs 等。向量化可以大大提高性能。SparkR 向量化允許用戶按原樣使用現有代碼,但是當他們執行 R 本地函數或將 Spark DataFrame 與 R DataFrame 互相轉換時,可以將性能提高大約數千倍。這項工作可以看下 SPARK-26759。新的架構如下:

可以看出,SparkR 向量化是利用 Apache Arrow,其使得系統之間數據的交互變得很高效,而且避免了數據的序列化和反序列化的消耗,所以採用了這個之後,SparkR 和 Spark 交互的性能得到極大提升。

Kafka Streaming: includeHeaders

Apache Kafka 0.11.0.0 版本支持在消息中配置一些 headers 信息,具體參見 KIP-82 - Add Record Headers,對應的 ISSUE 參見 KAFKA-4208。這些 Headers 在一些場景下很有用,Spark 3.0.0 爲了滿足用戶的場景所以當然需要支持這個功能了,具體參見 SPARK-23539。具體使用如下

val df = spark 
            .readStream 
            .format("kafka") 
            .option("kafka.bootstrap.servers", "host1:port1,host2:port2") 
            .option("subscribe", "topic1")
            .option("includeHeaders", "true")
            .load()


df.selectExpr("CAST(key AS STRING)", "CAST(value AS STRING)", "headers") .as[(String, String, Map)]

其他

Spark on K8S:Spark 對 Kubernetes 的支持是從2.3版本開始的,Spark 2.4 得到提升,Spark 3.0 將會加入 Kerberos 以及資源動態分配的支持。Remote Shuffle Service:當前的 Shuffle 有很多問題,比如彈性差、對 NodeManager 有很大影響,不適應雲環境。爲了解決上面問題,將會引入 Remote Shuffle Service,具體參見 SPARK-25299支持 JDK 11:參見 SPARK-24417,之所以直接選擇 JDK 11 是因爲 JDK 8 即將達到 EOL(end of life),而 JDK9 和 JDK10 已經是 EOL,所以社區就跳過 JDK9 和 JDK10 而直接支持 JDK11。不過 Spark 3.0 預覽版默認還是使用 JDK 1.8;移除對 Scala 2.11 的支持,默認支持 Scala 2.12,具體參見 SPARK-26132支持 Hadoop 3.2,具體參見 SPARK-23710,Hadoop 3.0 已經發布了2年了(Apache Hadoop 3.0.0-beta1 正式發佈,下一個版本(GA)即可在線上使用),所以支持 Hadoop 3.0 也是自然的,不過 Spark 3.0 預覽版默認還是使用 Hadoop 2.7.4。移除 Python 2.x 的支持:早在 2019年6月社區就有相關的討論關於在 Spark 3.0 移除對 Python 2 的支持,目前 Spark 3.0.0 默認支持 Python 3.x ,參見 SPARK-27884。Spark Graph 支持 Cypher:Cypher 是流行的圖查詢語言,現在我們可以直接在 Spark 3.0 使用 Cypher。Spark event logs 支持 Roll 了,參見 《Spark 3.0 終於支持 event logs 滾動了》

引用鏈接

[1] Preview release of Spark 3.0: https://spark.apache.org/news/spark-3.0.0-preview.html
[2] Preview release of Spark 3.0: https://spark.apache.org/news/spark-3.0.0-preview2.html
[3] [VOTE] Apache Spark 3.0.0 RC1: https://www.mail-archive.com/[email protected]/msg25781.html
[4] [VOTE] Apache Spark 3.0 RC2: https://www.mail-archive.com/[email protected]/msg26040.html
[5] [vote] Apache Spark 3.0 RC3: https://www.mail-archive.com/[email protected]/msg26119.html

[6] https://spark.apache.org/releases/spark-release-3-0-0.html

[7] SPIP: Accelerator-aware scheduling: https://issues.apache.org/jira/secure/attachment/12960252/SPIP_%20Accelerator-aware%20scheduling.pdf

往期推薦
▬
數據倉庫、數據湖、流批一體,終於有大神講清楚了!

Flink在快手實時多維分析場景的應用

認識 Delta Lake:讓數倉進化到數據湖

乾貨 | Kafka 內核知識梳理,附思維導圖

發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.
相關文章