注：以下圖片均引用自2019年阿里雲棲大會
Spark發展史
1 動態分區(Dynamic Partition Pruning)
在3.0以前，spark是不支持動態分區的，所謂動態分區就是針對分區表中多個表進行join的時候，在on後面的條件語句滿足一定的要求後就會進行自動動態分區裁減優化，比如：
1SELECT t1.id,t2.pKey
2FROM t1
3JOIN t2
4ON t1.pKey = t2.pKey
5AND t2.id < 2;
上面這條SQL語句在沒有使用動態分區的情況下執行過程如下圖所示：
在使用了動態分區以後執行過程變成了下圖：
可以看到之前進行join的時候對t1表中滿足on條件的所有數據進行掃描，然後再把兩張表進行join，在加入動態分區之後，我們過濾掉了t1表中的無用數據，大大減少了join時的內存計算開銷，在實際環境中同樣的代碼，性能提升了有33倍！
2
自適應查詢執行(Adaptive Query Execution)
自適應查詢是指對執行計劃按照實際數據分佈和組織情況，評估其執行所消耗的時間和資源，從而選擇代價最小的計劃去執行。一般數據庫的優化器有兩種，一種是基於規則的優化器(RBO)，一種是基於代價的優化器(CBO),自適應查詢指的就是對CBO的優化，SparkSQL的運行流程主要有：
1.將SQL語句通過詞法和語法解析生成未綁定的邏輯執行計劃；
2.分析器配合元數據使用分析規則，完善未綁定的邏輯計劃屬性轉換成綁定的邏輯計劃；
3.優化器使用優化規則將綁定的邏輯計劃進行合併、裁減、下推生成優化的邏輯計劃；
4.規劃器使用規劃策略把優化的邏輯計劃轉換成可執行的物理計劃；
5.進行preparations規則處理，構建RDD的DAG圖執行查詢計劃。
Spark以前的調度規則是執行計劃一旦確定，已經爲大家精心準備了大數據的系統學習資料，從Linux-Hadoop-spark-......，需要的小夥伴可以點擊即使發現後續執行計劃可以優化，也不可更改，而自適應查詢功能則是在執行查詢計劃的同時，基於表和列的統計信息，對各個算子產生的中間結果集大小進行估算，根據估算結果來動態地選擇最優執行計劃，如下圖：
具體可參見此篇文章
3
支持GPU調度(Support GPU Scheduling)
Spark在誕生之初就定位於統一的大數據處理引擎，目前大數據和機器學習已經密不可分，在這種情況下由於數據量比較大還有機器學習的算法迭代時間可能會很長，所以現在好多計算引擎都使用GPU、FPGA或TPU來加速計算，因此從市場需求來看，Spark支持GPU也已經勢在必行。
目前大數據組件的資源管理組件YARN和Kubernetes已經支持GPU，並有提供對應的API以供用戶使用，在Spark3.0中將支持standalone、YARN以及Kubernetes資源管理下的GPU計算，並且使用對現有正常作業基本無影響，從實現的角度來說是在scheduler層面進行調整，使得scheduler可以在task請求中識別出GPU需求，然後再按照executor上的GPU資源來分配。
4
更好的API擴展(Better API Extensions)
這個功能應該說是完善而不是新添加的功能，因爲從Apache Spark2.3.0這個版本開始已經開始引入Data Source API V2，這是因爲隨着Spark的使用用戶數量的增加，舊的Data Source API V1
逐漸出現了一些不足：
01
部分接口還是太過於依賴SQLContext和DataFrame
02
缺乏對列式數據庫存儲的讀取支持
03
寫操作不支持事務
04
不支持流式處理，不能進行增量迭代
05
缺乏分區和排序信息
06
擴展能力有限，難以下推其它算子
鑑於以上缺點，Spark從2.3開始在兼容Data Source API V1 的情況下引入並不斷改進DataSource API V2，最終的穩定版以及新功能將會解決上述所有問題，在年底和Spark3.0.0一起發佈，讓我們拭目以待吧！
5
更好的與ANSI SQL兼容
因爲Spark原來的SQL語法和函數跟ANSI標準還是存在一些差異，因此這次版本更新將縮小和ANSI標準之間的差異，包括增加一些ANSI SQL的函數、已經爲大家精心準備了大數據的系統學習資料，從Linux-Hadoop-spark-......，需要的小夥伴可以點擊區分SQL保留關鍵字以及內置函數等，如果這部分ISSUE解決，那麼Spark一定會得到更廣泛的應用。
最後我們來看一下Spark的生態，spark主要面向兩個羣體：數據工程師和數據科學家,它們之間的關係應該是相輔相成的，如下圖所示：
數據科學
在數據科學方面Spark採用和當前比較主流的數據分析語言python進行銜接來完成，在python中使用pandas可以進行數據分析，但是適用範圍只能在數據量比較小的時候，爲了解決這個問題，Spark開源了koalas，其和pandas無縫兼容，爲廣大的數據科學家帶來在大數據場景下能輕鬆的進行數據分析的福音。
下面是單獨使用koalas 和 pandas的案例:
可以看到二者在使用語法方面完全沒有差異，極大的方便了數據科學家的使用和操作。
數據工程
在數據工程方面，databricks開源了Delta Lake,這個是在實踐應用中基於成千上萬的用戶痛點而總結出來的，Delta Lake的主要特性有以下幾點：
能同時連續處理來自歷史和實時流的數據；
能確保表乾淨整潔，不受數據列污染；
允許向表中添加新列，且不會導致破壞性更改；
可進行數據版本的控制，以便在發生失誤操作時及時回滾；
與MLflow集成，可自動跟蹤和再現實驗。
以下是Delta Lake三個使用場景：
