本文由 「AI前線」原創(chuàng)，原文鏈接：Spark 2.3重磅發(fā)布：欲與Flink爭(zhēng)高下，引入持續(xù)流處理
策劃編輯｜Natalie
作者｜Sameer Agarwal，Xiao Li，Reynold Xin ，Jules Damji
譯者｜薛命燈
AI 前線導(dǎo)讀：”2018 年 2 月 28 日，Databricks 在官方工程博客上正式發(fā)布 Apache Spark 2.3.0，作為 Databricks Runtime 4.0 beta 的一部分。新版本引入了持續(xù)流式處理模型，可將流處理延遲降低至毫秒級(jí)別，據(jù)說(shuō)會(huì)成為 PK Flink 的大殺器。還有哪些重要更新，是不是該給 Spark 升個(gè)級(jí)，看完就有數(shù)了！”
Spark 2.3 繼續(xù)向更快、更易用、更智能的目標(biāo)邁進(jìn)，引入了低延遲的持續(xù)處理能力和流到流的連接，讓 Structured Streaming 達(dá)到了一個(gè)里程碑式的高度；使用 Pandas UDF 提升 PySpark 的性能；為 Spark 應(yīng)用程序提供 Kubernetes 原生支持。
除了繼續(xù)引入 SparkR、Python、MLlib 和 GraphX 方面的新功能，這一版本主要在可用性和穩(wěn)定性方面下了功夫，解決了 1400 多個(gè) ticket。其他主要特性如下：
DataSource V2 API
向量化的 ORC Reader
包含鍵值存儲(chǔ)的 Spark History Server V2
基于 Structured Streaming 的機(jī)器學(xué)習(xí)管道 API
MLlib 增強(qiáng)
Spark SQL 增強(qiáng)
下面將簡(jiǎn)單概括一些主要的特性和改進(jìn)，更多信息可參看 Spark 2.3 發(fā)布通告（https://spark.apache.org/releases/spark-release-2-3-0.html）。
毫秒級(jí)別的持續(xù)流式處理
出于某些原因的考慮，Spark 2.0 引入的 Structured Streaming 將微批次處理從高級(jí) API 中解耦出去。首先，它簡(jiǎn)化了 API 的使用，API 不再負(fù)責(zé)進(jìn)行微批次處理。其次，開(kāi)發(fā)者可以將流看成是一個(gè)沒(méi)有邊界的表，并基于這些“表”運(yùn)行查詢。
不過(guò)，為了給開(kāi)發(fā)者提供更多的流式處理體驗(yàn)，Spark 2.3 引入了毫秒級(jí)延遲的持續(xù)流式處理模式。
從內(nèi)部來(lái)看，Structured Streaming 引擎基于微批次增量執(zhí)行查詢，時(shí)間間隔視具體情況而定，不過(guò)這樣的延遲對(duì)于真實(shí)世界的流式應(yīng)用來(lái)說(shuō)都是可接受的。
在持續(xù)模式下，流處理器持續(xù)不斷地從數(shù)據(jù)源拉取和處理數(shù)據(jù)，而不是每隔一段時(shí)間讀取一個(gè)批次的數(shù)據(jù)，這樣就可以及時(shí)地處理剛到達(dá)的數(shù)據(jù)。如下圖所示，延遲被降低到毫秒級(jí)別，完全滿足了低延遲的要求。
持續(xù)模式目前支持的 Dataset 操作包括 Projection、Selection 以及除 current_timestamp()、current_date()、聚合函數(shù)之外的 SQL 操作。它還支持將 Kafka 作為數(shù)據(jù)源和數(shù)據(jù)池（Sink），也支持將控制臺(tái)和內(nèi)存作為數(shù)據(jù)池。
開(kāi)發(fā)者可以根據(jù)實(shí)際的延遲需求來(lái)選擇使用持續(xù)模式還是微批次模式，總之，Structured Streaming 為開(kāi)發(fā)者提供了容錯(cuò)和可靠性方面的保證。
簡(jiǎn)單地說(shuō)，Spark 2.3 的持續(xù)模式所能做到的是：
端到端的毫秒級(jí)延遲
至少一次處理保證
支持 Dataset 的映射操作
流到流的連接
Spark 2.0 的 Structured Streaming 已經(jīng)可以支持 DataFrame/Dataset 的連接操作，但只是流到靜態(tài)數(shù)據(jù)集的連接，而 Spark 2.3 帶來(lái)了期待已久的流到流的連接，支持內(nèi)連接和外連接，可用在大量的實(shí)時(shí)場(chǎng)景中。
廣告變現(xiàn)是流到流連接的一個(gè)典型應(yīng)用場(chǎng)景。例如，廣告 impression 流和用戶點(diǎn)擊流包含相同的鍵（如 adld）和相關(guān)數(shù)據(jù)，而你需要基于這些數(shù)據(jù)進(jìn)行流式分析，找出哪些用戶的點(diǎn)擊與 adld 相關(guān)。
雖然看起來(lái)很簡(jiǎn)單，但實(shí)際上流到流的連接解決了一些技術(shù)性難題：
將遲到的數(shù)據(jù)緩沖起來(lái)，直到在另一個(gè)流中找到與之匹配的數(shù)據(jù)。
通過(guò)設(shè)置水位（Watermark）防止緩沖區(qū)過(guò)度膨脹。
用戶可以在資源消耗和延遲之間作出權(quán)衡。
靜態(tài)連接和流連接之間的 SQL 語(yǔ)法是一致的。
Spark 和 Kubernetes
Spark 和 Kubernetes 這兩個(gè)開(kāi)源項(xiàng)目之間的功能組合也在意料之內(nèi)，用于提供大規(guī)模分布式的數(shù)據(jù)處理和編配。在 Spark 2.3 中，用戶可在 Kubernetes 集群上原生地運(yùn)行 Spark，從而更合理地使用資源，不同的工作負(fù)載可共享 Kubernetes 集群。
Spark 可以使用 Kubernetes 的所有管理特性，如資源配額、可插拔的授權(quán)和日志。另外，要在已有的 Kubernetes 集群上啟動(dòng) Spark 工作負(fù)載就像創(chuàng)建一個(gè) Docker 鏡像那么簡(jiǎn)單。
用于 SySpark 的 Pandas UDF
Pandas UDF，也被稱為向量化的 UDF，為 PySpark 帶來(lái)重大的性能提升。Pandas UDF 以 Apache Arrow 為基礎(chǔ)，完全使用 Python 開(kāi)發(fā)，可用于定義低開(kāi)銷、高性能的 UDF。
Spark 2.3 提供了兩種類型的 Pandas UDF：標(biāo)量和組合 map。來(lái)自 Two Sigma 的 Li Jin 在之前的一篇博客（https://databricks.com/blog/2017/10/30/introducing-vectorized-udfs-for-pyspark.html） 中通過(guò)四個(gè)例子介紹了如何使用 Pandas UDF。
一些基準(zhǔn)測(cè)試表明，Pandas UDF 在性能方面比基于行的 UDF 要高出一個(gè)數(shù)量級(jí)。
包括 Li Jin 在內(nèi)的一些貢獻(xiàn)者計(jì)劃在 Pandas UDF 中引入聚合和窗口功能。
MLlib 方面的改進(jìn)
Spark 2.3 帶來(lái)了很多 MLlib 方面的改進(jìn)，包括算法、特性、性能、伸縮性和可用性。
首先，可通過(guò) Structured Streaming 作業(yè)將 MLlib 的模型和管道部署到生產(chǎn)環(huán)境，不過(guò)一些已有的管道可能需要作出修改。
其次，為了滿足深度學(xué)習(xí)圖像分析方面的需求，Spark 2.3 引入了 ImageSchema，將圖像表示成 Spark DataFrame，還提供工具用于加載常用的圖像格式。
最后，Spark 2.3 帶來(lái)了改進(jìn)過(guò)的 Python API，用于開(kāi)發(fā)自定義算法，包括 UnaryTransformer 以及用于保存和加載算法的自動(dòng)化工具。
原文鏈接：
Introducing Apache Spark 2.3 - The Databricks Blog
更多干貨內(nèi)容，可關(guān)注AI前線，ID：ai-front，后臺(tái)回復(fù)「AI」、「TF」、「大數(shù)據(jù)」可獲得《AI前線》系列PDF迷你書和技能圖譜。
