MLSQL：融合 Spark+Ray，让企业低成本落地 Data+AI
由 Kyligence 主办的 Data & Cloud Summit 2021 行业峰会在上海成功举办，此次峰会特设「开源有道」分论坛，邀请了来自 Apache Kylin，Apache Spark，Alluxio，Linkis，Ray 以及 MLSQL 等开源社区的技术大佬，分享了目前开源社区关于大数据、机器学习等多个热门话题的前沿技术和最佳实践。Kyligence 技术合伙人兼资深架构师祝海林分享了一站式大数据和 AI 平台——MLSQL 是如何融合 Spark + Ray，助力企业低成本 Data + AI，引起了现场观众的热烈讨论。
-- 以下为祝海林在大会演讲实录 --
大家好，我是祝海林，今天很高兴给大家介绍一站式大数据和 AI 平台——MLSQL。在座各位基本都是做大数据相关的工作，无论您所在公司是否已经在使用 AI，我们都知道，目前落地 AI 其实只是时间问题了，因为大数据和 AI 两者存在非常强的延续关系。而 MLSQL 做的事情其实非常简单——就是让大家低成本落地 Data 和 AI，今天简单介绍以下四点：
当前落地 Data+AI 所面临的痛点
MLSQL 到底是什么
如何使用 MLSQL 低成本落地 Data + AI
MLSQL 典型案例
当前落地 Data + AI 所面临的痛点
当前痛点主要分为两部分，第一是企业面临的痛点；第二是一线人员，也就是落地 AI 的人员面临的痛点。大家一起看看中小企业开发一个算法的典型流程：
第一步是进行数据提取，企业数据往往分布在各个地方。如果企业数据仓库做得比较好的，可能将数据放在 HDFS 上，并且搭了 HUE，会在 HUE 上写 SQL 进行数据的提取和预处理。但是 SQL 的功能毕竟有限，大家会发现很多复杂功能的处理 SQL 是无法实现的。
这个时候，有一些企业就会引入 PySpark，用 Python 来处理。在 PySpark 把这些数据处理完之后，大家可能还需要机器学习库，比如 TensorFlow 等，如果是分布式的话，大家可能还需要把 TensorFlow 放到专有的 Cluster 集群去跑。当然，企业也可以把它放到 PySpark 去跑，但是大家会发现通过 PySpark 把数据“喂”给机器学习库是一件很难的事。
举个例子，如果算法是单机版的，而 Pyspark 是分布式的，大家最终要把数据 Collect 到 Driver 端给 TensorFlow，或者是在某个 worker 节点去进行 Repartition 后再把数据给到 TensorFlow。在 Collect 数据到 Driver 端的过程中就很可能会挂掉，因为这里可能有几千万甚至上亿的数据，如果是 Repartition 到一个分区，你会发现进行了一次很大的 Shuffle，这个性能也可能会导致 Spark 挂掉，这就是为什么 PySpark 现在处理不好这个问题。
完成上述步骤之后，大家还需要把这个模型部署出去，大多是部署成 API 服务，一般是以下三点：
部署到批处理里去，预测一些已有数据；
部署到流处理里去，预测一些实时数据；
部署成 API 服务，供第三方去调用。
上述就是一个模型训练好之后，通常要应用的三点。
在完成数据预处理、PySpark 处理数据、使用机器学习库进行训练以及复杂的模型部署等，企业接下来还需要进行持续的迭代。大家都知道模型都会随着数据变化而变化的，如果不持续迭代的话，辛辛苦苦训练出来的模型可能一个月之后就是一堆垃圾了，数据已经发生了改变，人员使用数据的习惯也已经发生了改变，模型如果不持续更新迭代就是没有用的。
大家会发现，需要维护的组件越来越多，为了让整个任务跑起来，大家又会去使用调度任务把它调度起来。比如，你在 HUE 里面跑一个任务，因为它们都分属于不同的系统，很难做到资源的弹性分配和充分利用，你会发现问题越来越多。
对于数据科学家而言，为了去落地一个算法，需要学这么多框架，而这些框架和本职工作相关性并不高，数据科学家又不是超人，这就会导致落地一个算法的门槛就会变得非常高。
一线人员包括研发、数据科学家，还涉及到管理人员，你会发现在这个过程中，部署和维护成本都非常高。数据会在各个组件流转，这就可能带来数据安全问题。数据要多次落盘，格式、形态都不一致，还会产生大量临时文件，而这些文件很可能就在某一个没有管控的目录里，就可能会导致数据的泄露。大家往往也会“选择性忽视”这些文件，尤其是做研发的朋友们，大家在用的时候很开心，但过常常会忘记清理。
在这个过程中，当然也存在资源浪费的问题，各个组件都会占用资源，你没有办法让系统弹性协调资源。其次，存在使用门槛高的问题。举个例子，数据科学家想要落地一个算法，需要学 Python 以及上文提及的各个系统和框架。
通过上述描述，大家会发现落地一个算法在中小型企业可能是以周计的，需要投入一个算法工程师以及多个研发，最终可能需要一周、两周甚至是一个月才能落地一个算法。
企业落地 Data + AI 的痛点
企业现在是怎么利用 AI 的？理想情况是：通过一个算法提升了 1% 的效率，减少了大量成本，公司多挣了 1 个亿，但这种场景其实是很少的，一般只有在大型企业，提升 1% 的效率才能带来这么大的收益。但大部分中小企业以及互联网企业其实是由非常多的场景构成的，每个场景可能都需要一个或者多个算法，而这些算法往往体现在流程优化、用户体验改进等。
正如上文提到的，乐观来看，落地一个算法就需要一周，而现在普通中小企业，往往有几百个场景，需要落地成百上千个算法，还需要持续迭代，大家都可以想到这个成本有多高。同时，对于企业来说，这些耗费大量人力物力的算法带来的收益是很难量化的。难点在于，这些场景是人工没有办法解决的，又只能通过 AI。
我经常举的一个例子就是「在线问诊」，在线问诊过程中有一个分诊环节，当用户描述自己症状的时候，需要把他分到具体的科室里去，对于背后的企业而言，成千上万的用户同时在问，这种情况下没有办法通过人工去做，只能通过算法。如果借助机器能完成 98% 分诊，大部分用户的体验就会得到大幅提升。但对于企业而言，带来的价值仅仅是让自己产品的一个小环节获得了不错的体验而已。
痛点一：算法落地成本高于收益
对于企业，往往有两大痛点，企业会发现落地一个算法，到具体某个场景的时候，成本是远远高于收益的。正如我们刚刚提到的，这个算法可能仅仅带来了一点点体验的提升，但是企业投入了好几个算法工程师，花了几周甚至一个月才将其落地。对于企业来说，算法工程师和研发工程师资源比较珍贵，硬件成本也比较高的。
痛点二：人才资源不足，时间成本高
第二个痛点在于，有的企业特别有远见，他们不在乎资金的投入，目的就是要让产品领先于其他企业，哪怕前期亏钱也是可以的。尽管投入这样的资金，企业也不一定能成功落地 Data + AI。首先企业要招大量的研发、数据科学家等，就算投入大量资金可能也是很难的。尤其是对于一些非技术企业，比如传统制造业等，更是难上加难。即使企业招到了人，基于以前的平台体系去构建难度还是非常高，可能要花半年到一年的时间来构建和落地，时间成本是非常高的。
上述两个痛点都给大多数企业落地 Data + AI 带来了重重挑战。
02. MLSQL 到底是什么
对于想要落地 Data + AI 的广大企业而言，不妨考虑一下 MLSQL。首先大家来看一下 MLSQL 究竟是什么，之后再来了解一下为什么它能够解决上述问题。我们将 MLSQL 定义是一门语言，语言一般包含两部分，一是语言的规范和语法，第二是语言的执行。语言只有规范没有用，写出来的语言需要有引擎去执行才行。
为了更好的拥抱 AI 生态，我们其实用到了两个引擎，一个是 Spark，一个是 Ray。在座很多人应该都是做大数据相关的，大家应该对 Spark 不陌生，使用过 Spark 的话，一般都会用到 UDF。不知道大家有没有想过解决这样一个问题：我用 Python 训练了一个 Tensorflow 的模型，有没有可能把这个模型做成 UDF 直接放到 SQL 里去使用？这样就可以做批处理、流处理，甚至可以暴露成 API 对外提供服务。传统做法，我们可能得上 JNI 了，因为 Spark 是用 Java 或者 Scala 开发的，而 AI 大部分模型都是基于 Python/C++ 开发的，这个过程就会比较麻烦。
MLSQL 做了一些工作，可以把 Spark 的 UDF 跑在 Ray 上，用户本身是无感知的，正常注册自己的 UDF 就好了。这个工作我们目前已经取得了初步的成果，我们用 96 行代码，就能把任意需要的模型预测功能（基于 Python 开发的模型）封装成一个 Spark UDF 模型。这在以前是比较困难的，因为 UDF 之前是一个无状态的，而模型预测是有状态的，就需要事先加载一个模型，之后再去提供一个 UDF 预测能力。我们通过融合 Spark + Ray，很好的解决了这个问题，所以，他们两者的融合，是可以带来很大想象力的。
MLSQL 核心引擎是 Spark，Ray 是可插拔的，两者都是分布式的，衔接上也是分布式的，所以我们说 MLSQL 天然就是一个分布式引擎。对于企业而言，如果只有语言和执行引擎，没有第三方开箱即用的库，什么东西都要自己开发，其实是没有什么价值的。为了帮助企业去更好地落地 Data+AI，MLSQL 提供许多功能的支持：
对数据湖的支持，在 MLSQL 里面，大家把引擎用起来，进行一个配置，指定一个目录，就可以向数据湖里面更新数据、写数据。
对 CDC 的支持，大家比较熟悉的应该是 Flink，那 Spark 去做 CDC 呢？MLSQL 直接内置两行代码就可以实时同步到数据湖里面去，还包括各种内置的算法。
下文我会展示一个 Demo，在 Demo 中，用户完全不需要用到 Python，只通过 SQL 就能完成一个复杂的机器学习流程：从提取数据、处理数据、训练数据、调参，到最后部署成 API 服务和 UDF。
当然 MLSQL 也支持 Python，在 MLSQL 里 Python 是一段文本脚本，你可以在 Python 中分布式处理 Spark 中的数据或者进行模型训练，结果重新返回给 Spark，中间可以不落地，性能还好。因为 Python 部分也是分布式的，而且灵活，这得益于我们对 Ray 的支持。另外我们也能实现一些非常酷炫的效果，比如之前提到的使用 Ray 作为 Spark UDF 的执行引擎，完成 Python 模型转化为 UDF 的操作。
传统的 SQL 是需要默认指定一个数据源的，比如 Hive 是数据源，你写 select 的时候，系统知道到哪去取，但是实际上数据联邦查询才是未来，之前主会场的大佬也提到，未来数据一定是从 collect 到 connect，为什么？现在法律法规对数据隐私要求越来越严格了，各个地方的数据不能随意地传输，而你需要进行统一分析的话，一定要采用联邦式的，数仓未来一定只是作为数据源之一而已，未来你会有非常多的数据仓库，物理上是割裂的，上层视角可能还是一个数仓的概念。
MLSQL 就提供了非常好的便利，比如上面这个例子，MLSQL 可以 Load Hive 数据、JDBC 数据以及 HDFS 数据，Load 完之后的表，后面就可以直接使用了。MLSQL 对 SQL 做了比较好的改造，select 之后马上就可以得到一个视图名，比如下文图中的 as joined，最后我们可以得到一个 final 表，从 final 表里面取出一个 output 的结果，你会发现我们完全把 SQL 脚本化了，变得非常简单，不需要写非常复杂的嵌套 SQL，因为 SQL 的复杂度来源于两方面：
子查询会导致嵌套复杂，嵌套一定是不符合人类思维的，顺序结构才符合人类思维。
Join 查询和窗口，有时候一条 SQL 有成百上千行，原因只是大量使用了子查询，Join 了无数张表，在这里 MLSQL 完全可以把它打平，select 完之后就会得到一张表去使用，非常简单。
此外，MLSQL 还提供了分支语法的支持，模块的支持，让 SQL 越来越强，越来越便利。
上图右边是一张原理图，MLSQL 主要做了三个部分：第一是语法解析，第二是代码翻译器，第三是执行引擎。其中比较重要的是语法解析引擎，MLSQL 做了 include 处理，支持模块化等。虽然大家看到的是 SQL，但你现在已经可以直接使用 MLSQL 去开发一个模块了，最后通过 include 语法把它引入进来。
之前我们已经使用 MLSQL 开发了一个叫 lib-core 的标准库，用户可以直接 include 进来去完成一些特定的功能，还包括语法检查、执行编译时的权限检查，以及一些命令行的预处理，然后是一些内置组件相关的初始化。
解析完之后的话，MLSQL 会把它翻译成 RDD data frame 或者 Python 的代码。以前大家写 UDF 的时候比较痛苦的是你需要开发一个 jar 包，部署时还需要去重启 Hive Server。在 MLSQL 你可以使用 register 语法去动态注册 UDF，在里面写一段 Scala 的代码，就可以直接在后续的 SQL 中去使用它了。这得益于 MLSQL 有一个 Scala 和 Java 的动态编译组件，里面嵌了一段 Python 代码，它是由 Pyjava 互通组件去完成的，最终是支持在 Java 里面去执行 Python 代码，从而在 SQL 里实现 Python，并且实现数据的互通。
接下来介绍 MLSQL 的架构，它非常简单。作为一个引擎，前面会有一个 Load Balance，加 JDBC/Rest API，最后会有一个控制台界面供你去使用。MLSQL 可以跑在 Yarn/k8s/Standalone 和 Local 模式。MLSQL Engine 是一个典型的 master-slave 结构。因为我们支持 Python 脚本，这意味着我们需要在 Java 里面执行 Python 代码，于是我们重新实现了一套 Python Deamon 和 Python Worker，这个是作为 Client 的，然后在 Ray 里执行 Client 的代码，这大概等价于在 PC 机上写一段 python 代码，最终会连接到 Ray 的 Cluster 上去执行。
传统的 PySpark 会有一个很大的毛病，大家可能也遇到过，Python Worker 和 Java 的 Executor 是在一起的。这种混部的架构会有一个问题，如果你跑一个很大的查询，Python Worker 占用的内存会非常大，或是把你的 CPU 跑满了，而且你是没有办法做资源隔离的。当跑满的时候，HDFS 也跑在上面，一不小心把节点跑挂了，可能还会遇到数据安全的问题，而且 Python Worker 节点也是互不相通的。所以这种混合的架构其实是有问题的，MLSQL 其实是把它减轻了，真正的 Python 处理逻辑是自动发送到 Ray Cluster 上去执行了，多环境再也不是问题了。以前 Python worker 可能需要 TensorFlow A 版本，另外一个用户说我要 TensorFlow B 版本，在这种情况下，我们可以起多个 Ray Cluster，用户直接决定连哪个 Ray Cluster，这个事情就迎刃而解了。
综上，MLSQL 架构其实有以下三个特点：
不管是 SQL 引擎还是 Python 引擎，几乎每个步骤都是分布式引擎；
MLSQL 支持 Python，拥抱了 AI 生态，解决了数据连接问题；
支持多环境，因为真正的机器学习里面，大家会发现环境是最难搞定的问题。
MLSQL 其实面对的受众是非常广泛的，它是一个很简单的语言，可以只用 SQL；但也可以复杂，允许你写一些高阶的 Python 代码来和 SQL 协作；同时作为研发工程师，你可以开发 UDF 函数或者说是写一些插件模块来增强 MLSQL 语言和引擎。MLSQL 是一个插件化的内核，它可以应对数据科学家、大数据工程师、产品和运营等，还面向于服务，这些会在后文的案例场景中简单介绍一下。
03. 如何使用 MLSQL 低成本落地 Data + AI
MLSQL 怎么做到这一点的呢？我认为是开源、统一、简单和安全这四点让企业可以真正实现低成本落地 Data + AI。
首先 MLSQL 是开源的，云上云下皆可部署，开源社区有保障，我们未来也会有商业版的支持，大家可以选择开源，也可以选择商业版。
我们不仅仅开源了引擎，还开源了开箱即用的 MLSQL Console，是一个 Web IDE。MLSQL 还可以让单引擎支持多租户，Web IDE 支持 Script/Notebook 的开发模式。我们还提供了一个非常高阶的分析工坊，可以实现自助化分析。MLSQL 可以做到，你写出来的任意复杂度的 SQL 都可以在分析工坊用「点点点」的方式来完成。这点以前很难做到，因为你要把复杂的操作转化成一条 SQL，其实没有工程师可以做得到，但是在 MLSQL 里，用户的任何一个操作都可以转换成一个语句，最后形成几千行的 MLSQL 代码，只需要一个前端工程师就可以完成。
最后一起来看看 Console 和 Zepplin，HUE 的对比。
其次，MLSQL 做到的是统一，对于用户来说，不再需要那么多组件才能完成大量工作，语言层面和交互层统一了，引擎层就是一个引擎，你把它解压进行部署，整个工作就都完成了。
MLSQL 相对其他语言，比如标准的 SQL 或者 PySpark 等语言的优缺点，我们在下图进行了简单的对比。
统一的价值就是带来了更低的成本，无论是面向维护者，还是使用者，大家都告别了一堆的系统和组件。
MLSQL 的另一个价值是简单。
我们实测过，如果你懂 SQL 的话几天就能入门，可以做一些流批、数据分析的工作。如果标准数据科学家，可以在里面完成一整个 Pipeline，支持你去写 Python，然后最主要的是可以实现代码易于自动化生成，去做一些高阶的产品。比如我们前面提到的无代码的分析工坊，和其他技术相比，你用 MLSQL 做同一件事，会发现完全不是一个量级的工作。「简单」的价值就在于降低了用户操作的门槛，一线人员效率提升了，之前用 Python 才能实现的工作现在用 SQL 就可以了。
MLSQL 带来的还有安全价值。以前大家会通过 Ranger 或者一些其他的组件，这些组件你会发现一个最大的问题，它们都会侵入到底层的数据存储。一个典型的例子，我用 Pyspark 去访问 MySQL 数据库，如果有 1000 个人去访问的话，数据库工作人员需要给 1000 个人去配 JDBC 的权限连接，这显然是做不到的。
而 MLSQL 是自主开发的一个语言，我们在设计这个语言的时候就考虑到了数据访问安全控制的问题。所以 MLSQL 可以做到语言层面统一做权限，可以控制用户能否加载某个数据，粒度是表级别还是到行列级别。这些都可以在 MLSQL 引擎层面做，根本不侵入各个存储层。你能不能访问 Hive 不是 Hive 去授权，而是在语言交互层面就已经授权了。
相对于其他语言，MLSQL 还有一个很大的优势，它不仅可以控制数据的存取，还能在语言层面，对某一个语法去授权。比如在 Python 里面，你用哪个语法肯定是控制不了的，除非自己重新实现一遍。但在 MLSQL 里，你能否用自定义 UDF、能否使用 Python、以及能否使用某个模块等，都可以做非常精细化的权限控制。
还有刚刚提的隐私计算，数据现在是不允许搬家的。举个例子，A 公司和 B 公司进行合作，两者的数据是不能搬家的，以前为什么要搬家呢？以前没有好的途径把这个数据暴露出来，原因是什么？以前如果暴露出来的 SQL，根本不能满足用户分析的需求，但如果暴露出是 Python 这种 API，又太灵活、没有安全性可言了。
正如我们前面提到的，MLSQL 不仅可以控制数据安全，还能控制语法元素，非常灵活。这就意味着大家完全可以提供一套 MLSQL 引擎接口出去，可以在这里随意地“玩耍”，生成一个算法模型，这个模型经过 A 公司的授权就可以下载到 B 公司，不存在授权安全性的问题。
04. MLSQL 典型案例
接下来，我们看几个 MLSQL 的典型案例。
首先看一下场景一，这是一家消费金融公司，他们已经跟进 MLSQL 3 年了，累计运行了 700 多万任务，数据规模 TB 级别，全公司有 200 多个人，200 人里有 35% 注册了 MLSQL 的使用账号，也就是大概有 70 多个人注册了账号。其中日活达到了 71%，这意味着注册的 70 个人每天几乎都有 50 多个人去使用。
通过这个案例，大家可以发现，使用 MLSQL 去玩转数据的门槛非常低，人人都可以去用。更夸张的是，整个大数据平台支撑团队只用了 2 个人，不需要复杂的组件，就可以完成很多事情。这个又告诉我们什么呢？这意味着维护这套平台成本非常低。
案例二
还有一个典型场景是厦门的一家信息公司，这家公司提供面向政府部门的服务。PPT 里说的模型，举个例子，发现卡口处是不是有汽车套牌的情况，也就是数据过来之后我要计算是否在异地出现。这些模型，他们以前是用 Kettle 做的，会发现客户的一个模型 2 周都搞不定，这个时候还不能加人，因为加人也没有用。后来实在受不了了，而且随着他们的数据来源也越来越多，还没有办法做异构数据的的联合查询，于是他们就引入了 MLSQL。
引入 MLSQL 后，给他们的开发效率带来了 15 倍的提升，怎么算出来的呢？他们举了个例子，通过 MLSQL 对客户提供支持后，客户 30 个模型、500 个任务，4 个人用了 1 个月就实施掉了，客户现场只提供 1 个人就可以了，每天就只需要看看日志和异常，无论开发效率还是运维效率，都有一个非常明显的提升。而且他们以前的流程都是在本地开发好，再到客户现场去调试，有问题又要回到“大本营”里去，现在 MLSQL 本身就是一个脚本，可以在直接在客户那里调试，MLSQL 成本非常低，本身的语法是可以扩展的，还可以用插件的方式去实现更复杂的处理逻辑。
我们部署成 API 服务的时候，你会发现他进行预测的时候也是写 SQL，但是数据不再是一张表，而是你传过来的 Json 数据，我们可以把这条 SQL 应用于你传过来的数据进行计算。不用做任何开发，组合一些函数，就可以完成一个端到端的预测，而传统的预测必须提供向量才能预测出来。
我们刚才看的 register 到可以跑到服务上，就是一个标准的函数。包括前面我们的案例，和 demo 演示因为都是内置模型，就可以很容易做到这一点。现在通过结合 Ray，MLSQL 也可以把 Python 的模型变成一个 UDF 函数进行使用。
大家看到，一个算法的开发和发布变成一件非常简单的事情，从数据的加载、处理到训练模型、调参、发布成 API 服务，都在 Notebook 里就可以完成整个流程了，根本不需要研发“爸爸”，搞完就可以发给第三方去玩了。
还未添加个人签名 2021.11.08 加入
还未添加个人简介
评论