本文章由阿裡雲社群直播視訊整理和而來。
講師：祝威廉，資深資料架構，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。
為什麼會有這樣的方向？
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的應用們。