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这种融合多个生态的项目会越来越多，这是因为，移动数据而非移动计算，也变得愈加可能。