0x00 前言
在進入本文的主題之前，先講兩件事。
第一件事，是Spark 3.0 開始重構shuffle部分，用以支持remote shuffle。這意味着我們終於可以爲shuffle專門準備一個存儲集羣了，比如一個單獨的HDFS之類的。這是Spark架構前進的一小步，也是業界開始朝計算和存儲分離走了堅實的一步。計算和存儲分離的好處我們就不多講，而計算和存儲的分離的前提是內網速度要足夠快，所以也意味着內網速度已經基本達到要求了。通過這個我是想告訴大家，內網已經足夠快。就像5G足夠快，會帶來什麼，很快就會有結果。
第二件事，對於大規模數據分析，我們知道存儲基本上必須是列式的，因爲達到一定規模後，行式存儲很難充分利用內存和CPU的加速。現在可以高興的告訴大家，數據交換格式也支持列式了，大部分語言都已經有相關的的SDK，這個格式就是Arrow. 作爲傳輸格式，本質上他也可以做爲存儲格式，這個我們不談，今天我們重點是把他當做一個傳輸格式。Arrow還有一個很大的優勢是，可以很好的避免序列化和反序列帶來的開銷，而這使得跨語言帶來的性能損耗不再是問題。通過這個，我是想告訴大家，大規模數據跨進程/跨語言傳輸已經可行了。
0x01 事情背後的事情
現在我們把兩件事合在一起看，【大數據傳輸也不再是問題】，不會有嚴重的序列化，反序列損耗，而且【內網】足夠快，這意味着：
我們可以爲所欲爲的將數據從一個集羣流轉到另外一個集羣，集羣可以是不同生態構成的。
說直白點，就是，我們可以以很小的代價，將數據從大數據生態流轉到AI生態，然後再從AI生態流轉回大數據生態。
大數據生態的典型計算框架是Spark， AI以前是各個獨立的計算框架，現在也有了一個可以統一支撐各種AI生態的分佈式計算框架Ray。如果能打通二者之間，那麼融合大數據和AI也就是水到渠成的事情。
我們很高興看到，已經有這麼去做的項目了。MLSQL以Arrow爲傳輸格式，可以讓數據在Spark 和Ray之間流轉，因爲Spark更懂數據處理，所以我們可以在Spark獲取數據，處理數據，又因爲Ray更懂AI，所以我們將數據傳輸給Ray,Ray訓練得到模型後再講數據返回給Spark，Spark將其存儲到一個合理的地方，譬如數據湖，亦或是模型倉庫，或者進一步在我們需要的地方使用這個模型。
而且，難能可貴的是，MLSQL還提供了一套語法規範，用戶可以在一個SQL腳本里完成這些事，而不用輾轉於兩個平臺才能完成這些事。下面是一段示例代碼，可以看到數據在Spark/Ray之間的流轉非常自然。
數據流轉是通過表來銜接的，20newsgroups經過Spark的兩條SQL進行處理，會被自動發送給Ray,在Python代碼裏我們可以通過RayContext獲取到這個表裏的數據，然後進行計算，計算完成後將模型（或者模型地址）通過表的形態發還給Spark，Spark會將數據保存在數據湖的ai_model數據庫下。
以前這種數據移動，而非計算移動，會非常耗時，原因是因爲在不同語言之間，必然涉及到序列化反序列化的巨大開銷，同時數據跨機器進行傳輸，也會極大的影響效率，而現在Arrow解決了前者，隨着硬件（網絡的）的發展，存儲和分離已經愈發是趨勢，也解決了跨集羣的數據存儲帶來的性能損耗。
0x02 結語
我們相信，未來數據的處理，類似MLSQL這種融合多個生態的項目會越來越多，這是因爲，移動數據而非移動計算，也變得愈加可能。