MLSQL的前生后世

2022-04-25 08:05:13 浏览数 (1)

前言

今天看了下项目的first commit log, 发现MLSQL已经三岁多了。

代码语言：javascript复制
commit bbf08489f2e3c58afd584e03b8c9c83d25c63b3b
Author: WilliamZhu <allwefantasy@gmail.com>
Date:   Thu Apr 28 15:04:13 2016  0800
open-source version

再查看了一下自己的第一个开源项目，

代码语言：javascript复制
commit 35af7b36e909282626038206eceb9c4ea5319047
Author: WilliamZhu <allwefantasy@gmail.com>
Date:   Mon Jul 2 10:37:31 2012  0800

    初始化版本

竟然是12年就开始了，距今已然七年了。顿时感慨良多。

三年前我做MLSQL时，只是希望它能够用配置化脚本完成ETL(批和流)流程。比如一个典型的流式程序大概长这个样子：

代码语言：javascript复制
{
  "StreamJob": {
    "desc": "测试",
    "strategy": "spark",
    "algorithm": [],
    "ref": [
    ],
    "compositor": [
      {
        "name": "stream.sources",
        "params": [
          {
            "format": "socket",
            "outputTable": "test",
            "port": "9999",
            "host": "localhost",
            "path": "-"
          }
        ]
      },
      {
        "name": "stream.sql",
        "params": [
          {
            "sql": "select avg(value) avgAge from test",
            "outputTableName": "test3"
          }
        ]
      },            
      {
        "name": "stream.outputs",
        "params": [
          {
            "name": "jack",
            "format": "console",
            "path": "-",
            "inputTableName": "test3",
            "mode": "Overwrite"
          }
        ]
      }
    ],
    "configParams": {
    }
  }
}

看起来竟然有些生涩。不过经过这三年，这个项目已经完全脱胎换骨了：

  1. 从原来的一个Json配置脚本，演化成一个较为成熟的面向大数据和AI的语言。

https://www.mlsql.tech/home

  1. 解决问题的范围也从流批配置化处理，转化为流，批，机器学习，探索查询，以及常规的脚本任务（基本能解决导数据和AI遇到的大部分问题）。
  2. 面向的人群从大数据研发转向数据分析师，以及所有研发，产品，运营，和商业团队。
  3. 从一个工具发展成一个Production Stack,在努力成为大数据中台解决方案的路上。

开源之路-源起

个人开源项目最大的特点就是随着个人的成长一起成长，而个人的成长又和自己在公司的工作内容紧密绑定。如果大家看过我早期写的一篇文章:

https://cloud.tencent.com/developer/article/1195246

就可以看到，我的工作技能完全是跟着工作走的。最早做Java Web开发，后来转型了做了几个月Ruby程序员，再后面因为公司需要做搜索，又转回来做Java。早些年很多公司的大数据部其实是由搜索团队孕育过来的，所以因为我做搜索，然后自然而然在大数据兴起的时候，同时也在做大数据。

我们来看看MLSQL刚开源时（那个时候叫StreamingPro）的定位： “Declarative workflows for building Spark Streaming”，翻译过来就是通过申明式工作流构建Spark Streaming程序。因为那个时候我所在的部门核心工作其实是做流，而且数据规模特别大（数据价值并不大）。一开始是用Storm,恰逢部门需要做技术升级，把Storm升级到Spark Streaming,所以我捉摸着，如何简化Spark Streaming的开发变的很重要，所以这个时候开始思考了这件事，于是有了StreamingPro的诞生。

但是其实这个项目在公司以及部门内部并没有得到广泛使用。不过我觉得我的思考方向是对的，虽然可能当时的想法以及做法并不成熟。后面我尝试将机器学习也纳入到到Declarative workflows 里，事实证明可行的。

后来入职了现在这家公司时，StreamingPro已经比较成熟，而且扩展性也不错，所以我开始强力推动它，在使用的过程中，我发现了几个大的问题：

  1. 第一个是json并不是一个很好的表达方式。在里面写SQL很痛苦，虽然我后面开发了一个Inteliij Idea 插件，试图简化它，但证实根子上不对，再努力也力有不逮。
  2. 配置只是换了写代码的方式，程序还是要每次运行的时候提交到yarn集群。这也就意味着只有拥有跳板机的同学才能使用。这样除了部分研发以外，其他人都没办法用，而且启动慢

后面无意看到了某君写的博客里面介绍了自己的DSL，萌生重新开发一套DSL的想法。这套DSL经过发展，就是现在的MLSQL了。

开源之路-崭露头角

所以到了17年的时候，MLSQL 做了两个显著的改变：

  1. Spark应用变成服务，提供Rest接口执行MLSQL脚本。不再是按Application的方式执行。
  2. MLSQL脚本正式取代了Json配置文件。

这个时候，公司团队慢慢体会到这确实能够大大的提升开发效率，开始慢慢接受了MLSQL。研发团队基于MLSQL开发了一整套周边系统，这包括动态DAG调度（类似Airflow等），脚本管理系统，前端Web，元数据系统等等。 所以一个东西好不好，核心就在于，他能不能真的提高人效。另外一个结论就是，你的东西就算真的好，也要不断的进化，并且很努力的进行推广，才能有机真正得到价值的体现。

当然，这个过程我们依然只是把MLSQL定位在ETL环节。

开源之路 - 进化

17年上半年重心在团队建设上，还有就是内部一些核心系统的开发上，到下半年，我们开始有了算法团队了。因为算法团队工程能力并不是非常好，而且光算法还有场景落地就已经够他们折腾的了。所以我一直在探索，如何能让工程团队更好的去支持他们，因为MLSQL底层基于Spark,所以以PySpark为出发点，先后研究了探索了 Spark Deep Learning， TFoS等项目，这些研究历程显示在了我博客里：

当时我研究 Spark Deep Learning算是比较早的，发现该项目没有NLP相关的支持，并且存在不少问题，所以自己Fork了该项目，添加了NLP以及数据交互相关的Patch,最后还写了一个万字长文的Chat,写关于如何使用Spark Deep Learning做NLP。

当时这个探索是非常有价值的，有了上面的积累后，我首先在MLSQL添加了Spark MLlib库的支持，参看SQL脚本实现算法模型的训练，预测，train/predict 等语法也是这个时候引入的。train/predict语法的引入以及后续扩展语义run语法是我认为MLSQL对SQL最成功的扩展之一。

到18年1月，我正式对MLSQL提出了新的定位：MLSQL Unify Big Data and Mchine Learning。 并且在文章为什么去开发一个MLSQL 提出了算法和大数据工程结合难点，以及给出了相应的解决方案，而MLSQL就是这个解决方案的实现者。可以不夸张的说，文中描述的痛点，现在很多公司依然得不到解决。

开源之路 - 扩大版图

当我发现MLSQL不仅仅能解决大数据处理的大部分问题，还能解决机器学习问题，更重要的是还能把他们用一个语言，一个框架完成的时候，这极大的激励了我。到18年四月，这个时候我其实还在台湾旅行，但是按捺不住，完成了爬虫的设计。 也就是通过MLSQL语法，我们可以做简单的爬虫工作。事实上在现阶段，一些简单的爬虫抓取，已经可以用MLSQL完成了。

到4月底，我扩展了MLSQL对机器学习的支持范畴，原先最早只是完成了对Spark Mllib以及自己开发的一些机器学习库（主要是Java）的支持,这阶段完成了对Python的支持，并且提供了端到端的预测服务。大家可以参考这篇文章MLSQL如何支持部署SKLearn,Tensorflow,MLLib模型提供API预测服务以及算法训练和模型部署如何避免多次重写数据预处理代码。 那么端到端到底是什么含义呢？

  1. 训练和预测一整条Pipeline，预测又包含批预测，流预测，API服务预测三部分，他们各自有不同的应用场景。
  2. 覆盖范围以及透明化。无论底层是Python,Java 写的机器学习库，MLSQL都能无缝衔接。
  3. 预测时，是raw data in , tensor out。 我们知道比如TF serving,其实是tensor in ,tensor out,这就意味着所有数据预处理工作要再另外一个系统完成，而MLSQL完美（其实也没那么完美）的解决了这个问题。

其实这期间在算法团队推广了这些实践，效果并不好。直到18年下半年才真正推广起来。原因是此时这些功能刚起步，其次这改变了算法团队原先的工作模式，任何一个新的东西，无论好坏，都需要接受它的团队反复消化，才能最后产生营养。

19年，我们又基于MLSQL Engine开发了任务调度系统，补齐了调度方面的短板。在MLSQL Console了添加了Notebook模式，重写了Java Python交互引擎等工作。

到笔者写这篇文章截止，在最新的1.5.0-SNAPSHOT里，MLSQL的周边项目也已经非常多：

https://github.com/allwefantasy/spark-binlog

https://github.com/allwefantasy/mlsqlscheduler

https://github.com/allwefantasy/pyjava

https://github.com/allwefantasy/delta-plus

https://github.com/allwefantasy/simple-schema

https://github.com/allwefantasy/spark-adhoc-kafka

还有更多，大家可以参看这个页面：

https://github.com/allwefantasy?utf8=✓&tab=repositories&q=&type=source&language=

开源之路 - 大众化

到18年下半年，准确的说，应该是8月份，研发和算法团队，已经完全接受了MLSQL。加上研发团队已经基于MLSQL开发了完善的周边，让MLSQL也输出到了其他研发团队，公司有商业团队的报表就是基于MLSQL来完成的。

这个时候我在思考，能否让更多人受益？比如分析师，产品，还有运营，还有一切非研发序列的同学们。这次我对MLSQL做了一个新的语法扩充，添加了include语法。具体的思路参考这篇内容：如何按程序员思维写分析师脚本，并且思考如何实现一个自解释的语法如何实现语法的自解释（MLSQL易用性设计有感）， 这个设计也为后续的MLSQL Console带来了极大的好处。

如何更好的支持分析师，是大众之路思考的开始，我明白，如果要让更多的人能够使用起来，我们有这么几件事情要做：

  1. 有一个预期合理的版本规划
  2. 有一个产品栈，能让用户开箱即用，而不是一个简单分布式计算引擎
  3. 要有完善的账号权限体系设计
  4. 要有更好的文档
  5. 要有方便各个群体的功能特性

首先是有一个预期合理的版本规划，公司内部有基于开源版本的内部版本。那么如何保持内部版本和开源版本同步是一件非常需要经验的事情。所以我也开始规范了MLSQL版本发布。从最早的1.1.3 版本到1.1.7,再到最近的1.2.0版本，MLSQL完成了自动化发版相关的工作，版本的定义也更加清晰。

其次是有一个产品栈，我基本上划分了三个系统：

  1. MLSQL Console
  2. MLSQL Cluster
  3. MLSQL Engine

三个产品统称为MLSQL Stack。前两个是Web系统，Engine则是我们原来说的MLSQL,但是现在只是MLSQL Stack里一个产品而已。这个Stack要易于体验和部署，我们提供了非常时尚的用一条Curl指令完成所有系统安装的功能：

代码语言：javascript复制
bash <(curl http://download.mlsql.tech/scripts/run-all.sh)

具体参看这篇文章MLSQL Stack体验 以及经过众多用户实测的手动安装文档 手动安装和启动MLSQL三套件。

不要小看这两件事，有多少人为了安装好一个系统费了九牛二胡之力，最后还是失败的？在此之前，用户能不能快速的安装体验MLSQL一直以来都是我的心病。

第三个就是要有完善的权限体系设计。我们知道大数据领域主要是基于Hadoop生态，一般计算引擎下面的数据形态五花八门，如何对底层的数据做统一的权限控制其实是一件非常复杂的事情，每个系统都有自己的权限控制体系。MLSQL创新性的引入了编译时权限控制,以极低的成本完成了对类似Kafka,MySQL,ES,HDFS,HIve, Reids,API,Web等的统一权限控制。对于传统的表还能控制到列级别。

第四个就是要有一个好的文档，社区的朋友和我一起写了个官网和文档。MLSQL Official Site 和Documentation。

第五个就是要多思考下，产品，运营，商业团队的同学到底需要什么样的功能，下面是我的尝试：

  • 用MLSQL完成简书图片备份
  • 新番：MLSQL如何帮助分析师更高效
  • 新番：产品和运营如何利用MLSQL完成excel处理

现在越来越多的人开始试用MLSQL Stack,也包括一些大公司。虽然MLSQL目前还缺一些大公司的标杆生产试用，但是不少中小公司已经开始在生产环境里面使用，而且我所在的公司也已经深度使用了两年。这足以让我具有持续维护的勇气。

维护一个开源项目，尤其是一个比较庞大的开源项目，所消耗的时间和精力是大家难以想象的。用007来形容毫不夸张。所幸的是，这些付出，于自己，于工作，于大家，都能带来价值。当然，没有家人还有领导的支持，这也是不可能的，感谢他们。

开源之路-社区

社区文化有一种迷人东西在里面。比如我最近在试图用Rust开发一个高性能的机器学习预测服务，当我进入这个语言的社区的时候，我又发现了一个崭新的世界，我因为学习Rust,又重新去学习C/C ,然后又去重新学习计算机基础结构，让自己对计算机，对语言，对系统，对业务又有了新的认知。

社区也是一个开源项目能够持续发展的核心。前期可能需要基于个人努力，去形成一个社区，而后期开源项目想要持续的发展，则必然需要有一个社区。MLSQL直到今年才开始有了自己的社区，一些使用了MLSQL的人一起探讨，一起设计，一起贡献。我们也开始维护了自己的官方群。

我们希望这个社区不仅仅在国内，我们也希望推广到国外去。所以现在一个很重要的任务就是撰写英文文档。

开源之路-新纪元

18年我们将MLSQL定义为Unify BigData and Machine Learning. 19年9月，我们将其重新定义 转成了 "The Programming Language Designed For Big Data and AI"。 至于为什么这么做，可参看这篇文章：https://cloud.tencent.com/developer/article/1971712

开源之路 - 期待

在19年，我们还提供了宏命令（将一段脚本包装成一个新的命令），以及具备雏形的脚本商店（得益于include语法支持），插件商店（动态加载数据源等），MLSQL也在一路前行。

其实我对MLSQL的期待很简单，就是能有更多的人使用，更多的人参与，然后形成一个更大的社区，这也是自己价值能体现的地方。

我对自己的期待则是，我在我的程序员生涯中能做出一些对很多人都有用的东西，这就够了。

代码语言：javascript复制
双脚留下的脚印总是能成为新道路的开始，追寻的人多了，总是有机会成为大道的。
sql html https 网络安全 spark

0 人点赞