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之间的流转非常自然。
![](https://i-blog.csdnimg.cn/blog_migrate/a15335b52399336be343e7a6a9121c1d.png)
数据流转是通过表来衔接的,20newsgroups经过Spark的两条SQL进行处理,会被自动发送给Ray,在Python代码里我们可以通过RayContext获取到这个表里的数据,然后进行计算,计算完成后将模型(或者模型地址)通过表的形态发还给Spark,Spark会将数据保存在数据湖的ai_model数据库下。
以前这种数据移动,而非计算移动,会非常耗时,原因是因为在不同语言之间,必然涉及到序列化反序列化的巨大开销,同时数据跨机器进行传输,也会极大的影响效率,而现在Arrow解决了前者,随着硬件(网络的)的发展,存储和分离已经愈发是趋势,也解决了跨集群的数据存储带来的性能损耗。
0x02 结语
我们相信,未来数据的处理,类似MLSQL这种融合多个生态的项目会越来越多,这是因为,移动数据而非移动计算,也变得愈加可能。