本文章由阿里雲社群直播視頻整理和而來。
講師：祝威廉，資深數據架構，11年研發經驗，同時維護和開發多個開源項目。
Stage1:分佈式編程發展歷程
1.MapReduce時代
大數據最開始的樣子：MR（MR指：mapreduce，後文簡稱MR）在大數據領域的地位舉足輕重，就不再贅述了。下面是一段使用MR編寫的WordCount代碼：
直觀上看，這段代碼粗糙，暴力且麻煩。在MR的初期，想要提交像如此簡單的功能的代碼，所需要的Jar包就有11個之多而且還有這麼多的代碼量，可想而知如果要搞一些複雜的需求與騷操作，簡直是要累吐我這樣的數據搬運工了。
當然我們MR的一個較大的弊端是用Java編寫代碼，又因為Java的表達能力相對較弱，這應該算是一個較大的短板。
MR時代我們會橫向拓展機器，這是一個在當時比較新穎的理念，我們在橫向拓展是並不要求機器的性能，項目初期，可以用盡量低的成本，用低性能且多數量的機器來支撐起我們的業務，也是很值得鼓吹的。當我們已現如今的知識儲備與經驗會看當時的想法，就會覺得它好low。就如同一個哲人曾經說過，今天的你如果沒有覺得昨天的你很沙雕，那麼你就沒有進步。
2.Spark
技術是不斷的進步的，上文我們說到MR是落後的，那麼替代MR的就是我們接下來說到的Spark。用spark中的RDD（Resilient Distributed Dataset）來實現wordcount代碼如下：
用了兩行代碼就替代了MR上面冗長的代碼，簡單且接近單機編程，spark都會有一個sc的入口，來進行對應的api調用。另一個優點就是不必如MR一般必須要在集群環境上進行調試沒有很好地額交互性，spark是基於scala編寫的，這裡我們叫（spark-shell）也就可以邊編寫代碼邊調試查看效果，類似於python的notebook，給予了我們開發很大的幫助，且有了很多新的理念。spark還支持多語言編程，除了原生的scala，還支持python，Java等。
3.Ray
Ray是一個新的大數據平臺:
看下上面的代碼，首先init()方法會連接一個已有的集群，如果沒有的話會自己啟動一個集群。然後我們創建一個方法或者一個class，我們加上一個annotation標註這個方法為可以遠程調用的。之後在調用的時候，其實是通過調用裡面的remote方法。然後通過ray.get(futures)拉起一個多線程來跑程序。
Ray已經是非常非常接近單機編程，支持所見即所得，簡單易用，原生支持python，可以很好的與AI整合，Ray為我們提供了更小的侵入性，更簡單的代碼實現。
螞蟻金服提供了Java支持，可以通過Java來編寫上面的代碼
4.分佈式發展歷史總結
感性總結
1.MR/Spark 都是原生支持Java/Scala系的，Ray開始原生支持Python。
2.限制越來越少，MR要求你實現接口，Spark要求你從sparSession算子開始，Ray則只需要你定義函數/class的時候打個遠程標記（另外還可以配置資源）。
3.啟動延遲越來越低，可直接interpreter執行。
問題：平臺變遷到底是什麼東西在變化？
如下圖：
基於以上圖片我們可以看到一個趨勢就是：Java與scala是MR與RDD的主力語言，python是AI的主力語言，大數據領域是Java與scala，AI則是python。Java與scala相對來說是面向平臺，python則是面向用戶。sql將會成為數據的主力。
問題：Ray是否會取代Spark嗎？
首先分別瞭解一下這兩個平臺的架構：
通過對兩個平臺的對比分析，我們可以看出，他們兩個是並列存在，目前並不存在誰取代誰的趨勢。
核心總結：
1）Ray的python/java支持是並列的,互不影響。Spark的Python AP1是需要通過Java API的。
2）兩者都分成了框架/應用,分佈式編程系統分兩個層（RDD==Ray Core）
3）Ray上的Python API自前主要面向機器學習,Java API還是面向傳統的流，批等。
4）你可以基於Ray Java API實現類似現在的Flink APl,SQL執行引擎等,並且複用已有的大數據生態。
小結論：
1）兩者體系結構類似。
2）Ray Core/RDD 都可以實現複雜的框架或者應用。
3）Ray可以實現Spark的所有功能,甚至實現一模一樣的上層API(比如DataFrame等,甚至能複用更上一層的庫比如MLL1b)。
4）Ray Core之上可以並行運行兩套生態體系(Al,大數據)
那麼到底能不能取代呢？理論上是可以的，但是還要看實際生態發展趨勢。Ray可以做到All in one，會不會替代就要看Ray的發展了。
Stage2:Spark API交互發展歷程
交互實際就是API，由下圖來看一下Spark api演化
演化總結：
1）數據處理本質是集合操作。
2）SQL是集合操作語言的典範。
3）DataFrame/DataSet 是SQL通用語言服本。
4）DF/SQL是數據處理的事實標準。
5）Python可以寫DF/DS,調用SQL,同時還可以支持機器學習學習各種庫,所以Python語言成為王道。
整個API發戰方向：
1）DataFrame/DataSet on python。
2）SQL。
為什麼會有這樣的方向？
1）數據處理本質是集合操作。
2）SQL/DF 易於無感知性能優化，可擴展性也還好。
3）Python作為C/C++的wrapper，同時是所有語音裡學習成本最低的，非常適合做交互。
Stage3:從Application到Service突破一些常見模式
分佈式編程的趨勢：
1.越來越簡單，越來越靠近單機編程。
2.執行延遲越來越低。
spark的兩種運行模式：
1.提交spark程序到Yarn/k8s上，運行完成後結束就退出 Application模式。
2.Spark作為常駐程序，通過Thrift/Rest等接口提交任務 Service模式。
Ray只有一個模式：
service模式。
service模式的好處：
1）任務提交快（無進程申請，初始化等開銷）。
2）執行速度快（AdHoc即席查詢查詢）。
3）負載均衡，集群的集群什麼的都可以一起上。
4）滿足數據分析如報表需求。
Service模式是一種進步。
Stage4:MLSQL是如何集大成，成為最好的分佈式編程平臺
MLSQL架構圖：
MLSQL將會結合Spark以及Ray。
MLSQL代碼示例：
MLSQL語言組成：
1.SQL 拓展版sql。
2.命令行 語法糖，本質也是sql。
3.python 內嵌於sql。
為什麼要一個新語言？
1）算法-》80%的代碼時SQL，20%的代碼時Python。
2）研發，產品運營，分析師-》100%SQL（部分拓展使用Java/Scala)。
因為要讓SQL成為頭等公民，那麼也就導致MLSQL應運而生。
一段典型的MLSQL腳本：
Java/Scala可以寫SQL函數：
MLSQL特點：
1）簡單-》SQL/命令行是一等公民，兼顧靈活可內嵌Python/Java/Scala。
2）內置權限=》 語言級別支持權限授權，一切資源都會抽象成表，精確到字段控制。
3）生態-》 可支持Spark/Ray之上的所有生態。
最後的建議：
1）請用Service模式。
2）分佈式編程平臺,Ray是趨勢,但Spark生態夠它繼續輝煌。
3）Ray成為機器學習的Spark。
4）數據API標準是SQL(DataFrame/DataSet),Al是Python。
5）MLSQL作為一門新的面向算法和機器學習的語言,解釋執行,內嵌權限,極度簡化了大數據和A的應用們。