先给MLSQL做个定义:
MLSQL践行了用一个语言,一个平台去完成大数据和机器学习相关的工作。
在谈MLSQL解决了什么问题之前,我们先提一个“数据中台”的概念。什么是数据中台呢?数据中台至少应该具备如下三个特点:
简而言之,数据中台应该是分析师,算法,研发,产品,运营甚至老板日常工作的集中式的控制台。MLSQL就可以做成这么一件事,为什么呢?
正如前言所述,MLSQL是一门语言,一个分布式引擎,并且支持各种数据源,所以他天然适合做数据中台。
MLSQL首先是弥合了大数据平台和算法平台的割裂,这是因为MLSQL对算法有着非常友好的支持。我们看一个比较典型的示例:
-- load data
load parquet.`${rawDataPath}` as orginal_text_corpus;
-- select only columns we care
select feature,label from orginal_text_corpus as orginal_text_corpus;
-- feature enginere moduel
train zhuml_orginal_text_corpus as TfIdfInPlace.`${tfidfFeaturePath}`
where inputCol="content"
and `dic.paths`="/data/dict_word.txt"
and stopWordPath="/data/stop_words"
and nGrams="2";
-- load data
load parquet.`${tfidfFeaturePath}/data` as tfidfdata;
-- algorithm module
train zhuml_corpus_featurize_training as PythonAlg.`${modelPath}`
where pythonScriptPath="${projectPath}"
-- distribute data
and enableDataLocal="true"
and dataLocalFormat="json"
-- sklearn params
and `fitParam.0.moduleName`="sklearn.svm"
...
and `fitParam.1.moduleName`="sklearn.naive_bayes"
....
and `fitParam.1.labelSize`="2"
-- convert model to udf
register TfIdfInPlace.`${tfidfFeaturePath}` as tfidf_transform;
register PythonAlg.`${modelPath}` as classify_predict;
-- predict
select classify_predict(tfidf_transform(feature)) from orginal_text_corpus as output;
这段脚本完成了数据加载,处理,tfidf化,并且使用两个算法进行训练,注册模型为函数,最后调用函数进行预测,一气呵成。大家可以看这个PPT,了解MLSQL如何进行批,流,算法,爬虫相关的工作。
第二个问题,如何统一流批,API, 在上面的PPT里大家可以看到,所有工作都使用MLSQL语言完成,除此之外你可以整合各类API服务,用MLSQL完成诸如爬虫,发邮件,生成下载链接等等功能。
第三个问题,MLSQL底层集合了譬如Spark,Tensorflow/Sklearn等各种主流技术以及大数据相关的思想,所以其实并不需要你关注太多。
我们假设大部分算法的代码都是基于Python的:
这些问题我们慢慢看。首先是项目难以重现,环境问题。MLSQL 的PythonALg模块可以集成任何Python算法项目。我们通过借鉴MLFlow的一些思想可以很好的解决Python环境依赖问题,并且比MLFlow具有更少的侵入性。用户只要在自己的项目里添加一个包依赖文件就可以很好的解决。
第二个和大数据平台衔接,我PPT里还有个so sad 系列:
基本算法工程师搞了个算法,很可能需要两周才能上线,你说怎么才能迭代变快。两周上线不可怕,可怕的是每个项目都是如此。那么MLSQL怎么去解决呢?正如前面提到的, MLSQL 的PythonALg模块可以集成任何Python算法项目,算法工程师只要把项目丢进MLSQL就可以转化为一个算法模块,然后使用MLSQL语言调用。所以天然就是衔接的。如果用户不使用Python,那更好,MLSQL自己也集成了深度学习和传统机器学习相关的库,你可以用现成的。
第三个问题,”训练时数据预处理/特征化无法在预测时复用“,我们知道,在训练时,都是批量数据,而在预测时,都是一条一条的,本身模式就都是不一样的。所以传统的模式是很难复用的,在MLSQL里,所谓数据处理无非就是 SQL+UDF Script+Estimator/Transformer, 前面两个复用其实没啥问题,Estimator/Transformer 在训练时,接受的是批量的数据,并且将学习到的东西保存起来,之后在预测时,会将学习到的东西转化函数,然后使用函数对单条数据进行预测。大家看这个图就明白了。
第四个问题,”集成到流式,批处理和提供API服务都不是一件容易的事情“,因为任何算法或者处理逻辑都可以被MLSQL自动转化为一个UDF函数,所以可以无缝的衔接进流式和批处理里。那么如何提供API服务呢?MLSQL核心理念如下:
我们可以把训练阶段的模型,udf, python/scala code都转化为函数,然后串联函数就可以了。无需任何开发,就可以部署出一个端到端的API服务。大家可以看到,一个标准的API服务本质就是一个select语句。
5,6两个问题,因为大家都用同一个语言,也就没有难么困难的交流了。研发可以为算法提供更多的预处理Estimator/Transformer,算法也可以提供更多的算法Estimator/Transformer。
分析师大部分都是写SQL, hive script其实shell + SQL, 这无形又需要分析师懂shell了, shell是一门神奇的语言,主要是他不正规,没有标准委员会去约束。这是第一个痛点。
第二个痛点是啥呢, SQL难以复用。复用体现在几个层面,第一,同一条SQL里有多个相同的case when语句,我得手写很多次。第二个是,SQL表的复用,SQL执行完一般就是一张表,如果我想复用这张表,那我就得写hive表,写hive表很痛苦,耗时并且占用存储,成本高。我能不能构建类似视图的东西呢?比如我需要A表,A 其实就是一条SQL,我需要的时候include这种A就好了。
第三个痛点是,我啥事都得靠你研发,比如处理一个东西依赖的UDF函数,都得等你研发搞。那我能不能自己用Python写一个UDF,不需要编译,不需要上线,还能复用呢?
所有同学的痛点,其实就是协作痛点。不同同学讲的语言不一样,你用Java,我用SQL,我用Scala,我用C++。MLSQL怎么解决这个痛点呢?同一个语言,同一个平台。
如果是简单的SQL其实肯定无法满足算法和工程的要求呢,而MLSQL是SQL的超集,这意味着 MLSQL具备高度扩展能力,这包括:
前面的数据中台概念里,我们提到了全公司数据视图,得益于我们底层依赖的Spark,我们基本上可以load任何类型的数据源,所以你可以实现不挪动数据的情况,就可以把数仓里的数据,业务的数据库,甚至execel放在一起进行join.
MLSQL就是想成为前面我们描述的一个数据中台,整合大数据和机器学习还有分析的所有流程。他的终极目标也很简单,让你的工作更轻松。
MLSQL 官网地址是: http://www.mlsql.tech MLSQL的github地址:https://github.com/allwefantasy/streamingpro MLSQL博客地址:https://www.jianshu.com/c/759bc22b9e15