演講嘉賓簡介：李潇，Databricks Spark研發部主管，Apache Spark committer,PMC member。
以下内容根據演講視訊以及PPT整理而成。
點選連結觀看精彩回放：
https://developer.aliyun.com/live/43188本次分享主要圍繞以下四個方面：
- Spark的起源
- Spark的今天
- Spark的最新進展
- Spark的未來
一、Spark的起源
Spark的創始人Matei于2007年開始在Berkeley讀博，他對資料中心級别的分布式計算非常感興趣。
彼時，一些網際網路公司已經開始用幾千台機器計算并存儲資料。這樣，Matei開始和Yahoo以及Facebook的團隊合作，來解決工業界中的大資料問題。在這一過程中，他意識到了這些大資料技術的巨大潛能，不僅能應用于網際網路公司，還能應用于科學資料集和工業資料集等場景。然而，這些技術還沒有在這些場景裡普及起來，所有的處理流水線都還依賴于專業的工程師實作。同時，大多數技術都僅局限于批處理，還缺少對互動式查詢的支援。最後，這些技術還都不支援機器學習。
另外，Matei在Berkeley繼續研究時發現，Berkeley的研究團體同樣需要可擴充的資料處理器，特别是機器學習研究。
于是，Matei開始抓住這個契機和Lester合作，後者參加了Netflix的一個機器學習大賽。Matei根據具體的應用場景設計了一個程式設計模型，使得像Lester這樣的應用者可以使用這個程式設計模型開發大資料應用軟體。基于此，2009年Matei着手開發Spark，并在最初就收到了許多好評，Berkeley的許多大資料研究者們都使用Spark進行大資料應用開發和研究。
2010年，Matei将Spark開源。Spark的最初版本僅僅關注Map Reduce風格的計算，其網頁如下圖。相對于傳統的Map Reduce, Spark具有更幹淨的API以及更好的性能。令人興奮的是，Spark在開源兩個月後就收到了社群的代碼，這說明确實有開源社群成員使用Spark并且利用Spark做出了一些有趣的項目。
在接下來的兩年，Matei投入了許多精力來拜訪早期Spark使用者，組織Meetup。在和一些早期使用者接觸後，Matei被這些早期案例震驚了：一些使用者在用Spark做一些他從未想過的事情。比如，一些使用者使用Spark做後端處理，以開發互動式應用。比如，一些神經科學家使用Spark實時監控動物大腦産生的信号，進行神經科學實驗。還有一些創業公司使用Spark分析使用者使用的社交媒體資料，利用Spark更新記憶體資料以進行流計算，而這發生在Spark提供流計算子產品之前。另外，來自Yahoo的資料倉庫團隊使用Spark運作SQL query，運作R實作的資料科學業務，他們還将Spark engine共享給團隊内部的許多使用者，使用者體量非常大。這些都堅定了Matei的信心，确定了Spark大有可為。
從2012年到2015年，基于Spark的不同使用場景和需求，Spark團隊開始擴充Spark以確定任何資料處理場景都可以使用Spark分擔計算工作，用Spark解決資料處理問題。他們主要做了三方面努力：
第一，添加了Python, R以及SQL等程式設計語言入口，使得使用者可以使用其熟悉的語言來使用Spark。
第二，添加了許多子產品以完成不同資料處理任務，包括圖處理、流處理。
第三，提供了更高層級的API以消除使用者手動設定API的困擾，比如大家熟知的DataFrames API。DataFrames API是
Spark SQL中最受歡迎的API，和SQL Language一樣。這是因為，DataFrames API會被SQL優化集優化，同時又與程式設計語言融合在一起，是以比SQL語言更加簡單好用。
這些曾經的努力深深地影響着現在的Apache Spark。
二、Spark的今天
在Python方面，68%的Databricks的互動式notebook指令是用Python寫的，是Scala的6倍，同時遠遠高于SQL這種廣泛使用的資料庫語言。這意味着，更多的程式員可以使用Spark進行資料處理和分析，而不僅僅局限于使用SQL的程式員。
在SQL方面，大約有90%的Spark API調用實際上跑在Spark SQL這個子產品上。無論開發人員使用Python, Scala, Java或者R調用Spark，這些開發人員都實際受益于SQL engine的優化。在Databricks上，每天由Spark SQL處理的資料量都達到了exabytes量級。是以，整個社群在Spark SQL的投入相當大，這使得Spark SQL engine成為性能最好的開源SQL engine。在TPC-DS benchmark項目上，Spark 3.0中Spark SQL engine的性能比Spark 2.0整整快了兩倍，比Presto快了1.5倍。今年年初，阿裡巴巴的E-MapReduce團隊使用Spark SQL engine打破了TPC-DS benchmark項目的最高性能記錄。總的來說，Spark SQL engine是一個非常強大且高效的SQL engine。
在流處理方面，每天使用Databricks做流處理的資料超過5兆。Structured Streaming讓流處理變得非常簡單，能夠輕松地将DataFrames和SQL計算變成流計算。近年來，使用Databricks做流計算的資料量每年翻4倍，增長非常迅速。
基于Spark的這些變化可以總結得到以下兩個經驗：
第一，易用性，即如何使使用者更簡單地使用和操作Spark以及如何幫助使用者快速定位錯誤，這對于一個好的項目非常重要；
第二，Spark API的設計需要關注這些設計能否支援使用者實作軟體開發的最佳實踐，比如通過組合不同庫函數實作不同應用，同時支援可測試和子產品化。API的設計還需要融入标準的程式設計環境，比如Python, Java, Scala, R等，以使其能夠被友善地嵌入不同應用中。確定API的設計支援軟體開發最佳實踐，才能夠使使用者更安全和友善地使用它們。
以上是Spark已經做到的，随着時間的不斷推進，Spark還将繼續在這些方面不斷完善。
三、Spark的最新進展
Spark 3.0是Spark有史以來最大的Release，共包含3400多個patch。下面這張圖顯示了這些patch所屬的子產品，幾乎一半的patch都屬于Spark SQL。Spark SQL的優化不僅服務于SQL language，還服務于機器學習、流計算和Dataframes等計算任務，這使得社群對Spark SQL的投入非常大。此外，Spark團隊還付出了大量努力使Spark 2.0的使用者友善地更新到3.0。
以下主要從SQL和Python兩個方面讨論Spark的最新進展。
SQL方面
近幾年，SQL engine方面主要的改進就是Adaptive Query Execution (AQE)。AQE能夠在運作時根據計算任務的特性更新計算計劃，也就是execution plan，比如自動調整reducer數量，自動改變join算法，自适應地處理資料傾斜問題。AQE的這種能力讓Spark變得更加簡單易用，使得Spark使用者們不需要再繁冗地進行各種資料調優。
AQE可以自動調整reducer數量。過去，Dataframes上60%的叢集都需要使用者手動更改reducer數量，這使得使用者不勝其擾，而AQE可以幫助解決這個問題。
AQE可以自動減小partition數量。在做聚合時，AQE還可以通過調整和合并小的partition，自适應地減小partition的數量，以減少資源浪費。
AQE還可以優化join操作。即使有高品質的資料統計資訊，使用者仍然很難獲悉已經進行join操作的記錄數。而AQE可以在join操作的初始階段獲悉資料的輸入特性，并基于此選擇适合的join算法進而最大地優化性能。
AQE還能夠解決資料傾斜問題，通過調整不同key的資料來避免資料傾斜，進而提高性能。比如，在TPC-DS的查詢問題上，AQE能夠調整不同key以達到8倍的性能加速。這使得使用者能夠使用Spark處理更多資料，而不需要手動收集資料統計資訊來優化性能。
AQE僅僅是Spark 3.0在性能方面的一種改進，提升Spark性能的例子還包括Dynamic partition pruning, Query compile speedups，以及Optimizer hints等。正如前文所述，Spark 3.0相比Spark 2.0的性能提速達到2倍，并且這種改進在真實場景下可能更明顯。
除了性能，Spark 3.0在SQL的相容性方面也有了很大的提升。比如，ANSI SQL方言做了标準化的SQL支援,使得其它SQL系統的負載和業務能夠很容易轉移到Spark SQL上。
Python方面
Spark 3.0在Python方面的改善包括易用性和性能。
對于易用性，Spark 3.0使使用者能夠更友善地定義Pandas UDFs。使用者可以通過Python type hints指定其期待的資料格式和函數類型。在Spark 3.0中，使用者可以僅僅指明資料的type，而不是寫許多備援的模闆式代碼，類似于Spark 2.0。
在性能方面，Spark 3.0做了大量Apache Arrow的性能更新，20%-25%的性能提升來自于Apache Arrow自身。Spark 3.0還使用Apache Arrow實作了大量Python和R之間的資料交換，而這些對Spark使用者都是透明的。此外，Spark 3.0在SparkR方面的性能提升高達40倍，Spark還将提出更多的API來合并Pandas和Spark。
Spark 3.0新功能分布在不同的子產品上，比如阿裡巴巴貢獻的可用來監控流計算的Structured Streaming UI，可檢測的流作業監控名額，全新的Spark language查詢手冊，新的Data Source API等。更多的Spark 3.0新功能可參見Xiao Li的講座。
Spark生态圈的其它項目
除了Spark項目自身的發展，整個社群還圍繞Spark做出了許多創新。去年，Databricks釋出了Koalas項目,支援直接在Spark上運作Pandas API，使得更多的Pandas使用者能夠使用Spark解決大資料問題。Delta LAKE提供了可靠的表存儲。社群還給Scikit learn, HYPEROPT, Joblib等添加了基于Spark的後端引擎，幫助它們解決大資料問題。Spark社群還和著名的基因公司一起開發了Glow項目，被大規模地應用于基因領域進行基因分析。Rapids提供了大量的資料科學和機器學習算法，使用GPU加速計算。最後，Databricks也進行了優化，改善了Spark和可視化系統的互動，使得使用者可以快速地開發以Spark作後端引擎的互動式界面。
下面以Koalas為例展開具體介紹。
Koalas是Pandas API在Spark上的實作，能夠使更多的資料科學代碼直接運作在Spark上。從去年在Spark 3.0中釋出至今，Koalas已經達到了每個月85萬的下載下傳量，大約是PySpark的1/5。未來Spark社群還将在Koalas上投入更多。
這次，Spark社群還釋出了Koalas 1.0，具有以下特性：
第一，達到了80%的Pandas API覆寫率。
第二，由于Spark 3.0的釋出，Koalas的性能也大大提升。
第三，能夠支援更多的功能，包括missing values, NA以及in-place updates等。
第四，具有分布式的索引類型。
第五，能夠非常友善地使用pip進行安裝，對Python使用者非常友好。
四、Spark的未來
在回顧了Spark的發展過程後，接下來再來展望資料科學的發展和資料驅動的AI進步。顯然，Spark在過去的十年生逢其時，多次重大的決策導緻Spark發展神速。然而，基于Spark開發大資料和AI應用仍然過于複雜，讓基于Spark的應用開發變得更加簡單仍大有可為。為此，Spark開源社群正在做更多的努力：
第一，要使資料的探索和使用變得更加簡單，也就是資料科學和資料工程。
第二，還需要讓Spark API更好地與生态圈的其它主流軟體連接配接起來。
接下來介紹Databricks在Apache Spark的接下來幾個release中做出的具體努力。
Zen
第一個項目叫Zen，中文名是禅。Zen的項目名來自Python社群的項目Python Zen，其定義了設計Python的一系列原則，正是這些原則帶來了Python社群如今的繁榮。Zen項目旨在提高Apache Spark在Python方面的可用性，Spark社群希望通過Zen項目讓Spark Python的使用和Python生态圈的其它API一樣易用。比如，提供更好的錯誤報告機制，将更易用的API加入Python的API中，進一步改善性能以使API更加Python化。
AQE
Spark社群還将繼續優化AQE的動态優化能力，同時改善使用者體驗，避免額外的資料準備工作。
ANSI SQL
Spark社群還将标準化SQL語言支援，通過ANSI SQL使更多的主流SQL engine的工作能夠遷移到Spark SQL中。
以Zen的Python Error Messages為例
在Spark 2.4中如果發生意味除零，使用者會在Python Error Messages中得到冗長的錯誤資訊，甚至還包括了大量的Java資訊，這對Python程式員非常不友好。Spark 3.0中将簡化Python Error Messages以避免備援的錯誤資訊，使使用者能夠快速查錯。
Python文檔
Spark社群還提供了對使用者更加友好的Python文檔，而之前的PySpark API文檔存在許多無用的API。
Spark社群對Spark的未來非常有信心。有理由相信，Spark 3.0将解決更多問題，讓大資料和AI資料處理變得更加簡單！