看数据与机器学习交互接口发展

本文章由阿里云社群直播视频整理和而来。
讲师：祝威廉，资深数据架构，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的应用们。