为什么去开发一个MLSQL

算法和工程之殇

算法和工程结合,有两个非常大的痛点:

第一个,算法的着眼点是,用最快速的方式清洗一些数据出来,然后接着建模训练,评估预测效果,之后再重复清洗数据,再试验。因为很多算法工程师都是Python系的,对他们来说,最简单的方式自然是写python程序。一旦确认清洗方式后,这种数据清洗工作,最后研发工程师还要再重新用Spark去实现一遍。那么如果让算法工程师在做数据清洗的时候,直接使用PySpark呢?这样复用程度是不是可以有所提高?实际上是有的。但是算法工程师初期用起来会比较吃力,因为PySpark的学习成本还是有的,而且不小。

第二个,模型的部署。比如我们把一个训练好的tf模型集成到了一个Java应用里,这个很简单,但是还是有难点,难点在哪呢? 因为模型其实接受的是向量,但是Java应用接受的还是raw数据,需要对raw数据做转化,本质上是把之前Spark实现的清洗流程再重头做一遍。Spark 通过pipeline 解决了这个问题,但是解决的不够好,因为他太慢,没办法用在来一条预测一条的场景里。

我上面提及的两点,是真实存在的,而且极大影响了研发效率。所以数据处理这块,基本整个流程下来,是至少要做三遍的。

  1. 算法需要反复清晰数据,直到找到合适的特征集合。
  2. 工程要用Spark做一遍工程化
  3. 应用服务要用Java/Scala之类的再写一遍针对单条的。

前面提到的是清洗的复用,算法工程师其实喜欢用比如TF,SKlearn等成熟框架,或者独立的高效的单一算法C++实现,比如CRF, LDA等。而工程师则喜欢一些大数据处理套件。 你想让算法工程师天天在Spark上跑,不是一朝一夕的能搞定的。

基因论

我一直觉得吴军以前提的基因论真的很有用。比如Spark社区, 整个社区是以工程师为主的,这个就是他的基因。Spark想做做算法,而且很努力,但是总是欠缺那么点意思。

我之前发文吐槽过很多次,包括整个MLlib的API,基本实用价值不大。里面的方法又限制的严,真正算法需要用的方法都访问不到(私有),暴露出来的又没啥用。

我们来看看我实际使用LDA时的尴尬境地:

image.png

还有为了拿里面一个有意义的变量,得这么弄:

image.png

可以看到有多艰难。

我得出的结论是,开发这些算法的人,根本没弄明白算法工程师会怎么用。真正做算法的,也瞧不上spark这套东西。Spark MLlib 应该还是以工程师使用居多。

所以你看tf 之类的一出来,就火了,没spark什么事。

尝试解决这些问题

我们现在回顾下问题,再抽象一层就是:

  1. 数据处理过程无法在训练和预测时复用
  2. 无法很好的衔接算法和工程的框架

数据处理过程无法在训练和预测时复用

我把数据处理分成两个部分构成.

  1. 聚合,join,字符处理
  2. 模型处理

怎么理解这两个部分呢?

首先你需要导出去寻找数据,这些数据散落在各个角落,你需要去各个角落关联,把数据收集起来,接着你会进行各种聚合操作,得到一些统计量,并且对立面的每个字段做些规则上的处理。这个就是对应我前面提到的第一部分 “聚合,join,字符处理”。

第二个部分是,模型处理。为啥数据处理也需要用到模型了?一个简单的示例时,我们需要把字符转化为数字,比如我现在有城市,那么我需要把城市转化为一个递增的int数字,然后把数字转化为ont-hot向量。这个过程我们需要得到一个城市和数字的映射关系,这个关系的建立,本质就是一个模型的建立过程。 泛化的讲,可以认为一切数据处理都是模型,但是如果都抽象成模型,那么模型就是去意义了。我们只对一类很有用,很常见的数据处理抽象成模型。

把数据切分成这两部分有啥好处呢?这就以为这数据处理变得有可复制的可能。但是如果我们都是用Python,用Java去做这些事情,那么还是不能复制,所以我们需要一套更形式化的语言去完成这两部分语言。 这个语言是什么好呢? 答案是SQL。 SQL天然适合第一部分的工作,第二部分,我们只要适当的扩充SQL语法就能高搞定。

这样,在训练时,工程和算法都可以复用一套脚本了。那么预测时候怎么办?我们怎么复用?在预测时候,数据是一条一条来的,所以基本没有前面那个聚合join的过程,只有数据处理的‘模型预测’部分。 比如对一个城市,我们会加载训练时产生的城市到数字的映射模型,然后用模型进行预测,这样就复用了训练时的功能了。

现在,我们解决了数据处理复用的东西,包括训练时工程和算法的复用,也包括训练和预测的复用。

无法很好的衔接算法和工程的框架

现在是,工程要用Spark SQL, 算法训练要用TF,怎么办,怎么让他们协作。那就是让他们都看不到底层到底是什么。

首先,数据处理,大家都用经过“扩展的SQL”,接着,算法可以用Tensorflow Python的API定义好网络结构,然后也可以用“扩展的SQL”来完成具体的训练。这样,就统一起来了。

MLSQL

现在我们看MLSQL是如何优雅的实现这个解决方案的。 我现在有一张表,表里有一个字段叫问题字段,我想用LDA做处理,从而得到问题字段的主题分布,接着我们把主题分布作为向量给一个tensorflow 模型。

-- 加载一份数据文件,如果是表,则无需load语句
load csv.`/tmp/tfidf.csv`  options header="True" as zhuhl_new_ct;

-- 对text资源进行分词,这里为了简单,我直接用split了
select *,split(question,";") as words from zhuhl_new_ct 
as zhuhl_new_ct;

-- 得到词表
select explode(words) as word_x1 from zhuhl_new_ct) 
as word_table;

-- 训练一个模型,把每个词用一个数字表示
train word_table as StringIndex.`/tmp/zhuhl_si_model` where 
inputCol="word" and handleInvalid="skip";

-- 注册成SQL UDF函数。
register StringIndex.`/tmp/zhuhl_si_model` as zhuhl_si_predict;

-- 把词汇转化为数字,这样问题就被表示成一个数字序列了
select zhuhl_si_predict_array(words) as int_word_seq,label from zhuhl_new_ct
as int_word_seq_table;

-- 训练一个tfidf模型
train int_word_seq_table as TfIdf.`/tmp/zhuhl_tfidf_model` where 
inputCol="int_word_seq"
and numFeatures="4" 
and binary="true";

--注册tfidf模型
register TfIdf.`/tmp/zhuhl_tfidf_model` as zhuhl_tfidf_predict;

--将文本转化为tf/idf向量
select zhuhl_tfidf_predict(int_word_seq) as features,int_word_seq,label from int_word_seq_table
as lda_data;

-- 训练lda模型
train lda_data as LDA.`/tmp/zhuhl_lda_model` where 
 inputCol="features"
 and k="100" 
 and maxIter="10";

--注册lda预测函数
register LDA.`/tmp/zhuhl_lda_model` as zhuhl_lda_predict;

-- 把文本用主题分布表示
select *,zhuhl_lda_predict_doc(features) as features from lda_data
as zhuhl_doclist;

-- 把结果给tensorflow模型
train zhuhl_doclist as TensorFlow.`/tmp/zhuhl_rm_model` 
where pythonDefScript="/tmp/classi" 
and inputCol="features" 
and labelCol="label";

register TensorFlow.`/tmp/zhuhl_rm_model` as zhuhl_rm_predict;

这个过程基本不需要研发参与,算法就已经很好的完成了整个流程。我们现在看看如何集成到预测里面去,比如我们希望把最后这些功能都放到一个Java应用里去。

嘴阀很简单,每个数据处理环节以及最后的tf都有一个模型存储地址,Java应用只要加载这些模型就可以,并且,每个模型都有一个SQL开头的实现,比如SQLLDA,里面的话已经提供相应的predict函数(都是针对一条记录的),预测速度会非常快。 写预测程序的人只要把几个模型串联起来就可以了。

如果是异步预测,比如使用SparkStreaming等,则更简单,直接像上面一样注册UDF函数就可以了。

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏ATYUN订阅号

MIT开发新型加密方法,使基于云的机器学习更具安全性

麻省理工学院研究人员设计的一种新型加密方法可以保护在线神经网络中使用的数据,而不会减慢其运行时间。这种方法有望在基于云的神经网络进行医学图像分析和其他使用敏感数...

1803
来自专栏PaddlePaddle

AI不思议|说说那些偶尔混淆的概念

但是产品和运营两队小伙伴一不小心就遇到概念混淆的场景,有些时候是自己记模糊了、有些时候自己没记错、却被别人“拐到沟里“了…

1051
来自专栏机器之心

前沿 | MIT开发神经网络专用芯片:能耗降低95%,适合移动端设备

2137
来自专栏AI科技评论

动态 | 谷歌发布机器学习规则 关于机器学习工程的最佳实践(下)

文章介绍了一种机器学习样式,类似于 Google C++ 样式指南和其他常用的实用编程指南。

742
来自专栏数据派THU

带你用4行代码训练RNN生成文本(附资源)

本文共1400字,建议阅读6分钟。 本文介绍仅需几行代码就能训练出任意大小和复杂度的文本的神经网络文本发生器。

1182
来自专栏AI研习社

比 TensorFlow 云快 46 倍!IBM 用 Snap ML 和 Tesla V100 秀肌肉

AI 研习社按:TensorFlow 的机器学习库可以说大家都已经很熟悉了,但 IBM 的研究人员们表示这都是小意思。

792
来自专栏张俊红

数学之美(二)

总第75篇 本篇为数学之美连载篇二,你还可以看:数学之美(一) 11|矩阵运算与文本处理: 无论是词汇的聚类还是文本的分类,都可以通过线性代数中的奇异值分解来进...

3335
来自专栏用户画像

Facebook 推荐算法

版权声明:本文为博主-姜兴琪原创文章,未经博主允许不得转载。 https://blog.csdn.net/jxq0816/article/details/816...

1923
来自专栏机器之心

初学者怎么选择神经网络环境?对比MATLAB、Torch和TensorFlow

选自arXiv 机器之心编译 参与:吴攀、蒋思源、李亚洲 初学者在学习神经网络的时候往往会有不知道从何处入手的困难,甚至可能不知道选择什么工具入手才合适。近日...

44810
来自专栏追不上乌龟的兔子

Neo4j中的图形算法:15种不同的图形算法及其功能

只有你拥有使用图形分析的技巧,并且图形分析能快速提供你需要的见解时,它才具有价值。因而最好的图形算法易于使用,快速执行,并且产生有权威的结果。

3K3

扫码关注云+社区

领取腾讯云代金券