前言
先給MLSQL做個定義:
- MLSQL是首先是一門語言,SQL的超集。 這意味著他的門檻足夠低,無論分析師,研發(fā),算法,運營,產(chǎn)品經(jīng)理都可以用。
- MLSQL 同時也是一個跨平臺的支持私有部署和云部署的分布式計算引擎。這意味著你可以充分利用MLSQL的算力,完成大部分算法和大數(shù)據(jù)相關的工作。
MLSQL踐行了用一個語言,一個平臺去完成大數(shù)據(jù)和機器學習相關的工作。
數(shù)據(jù)中臺的概念(讓我們炒個概念)
在談MLSQL解決了什么問題之前,我們先提一個“數(shù)據(jù)中臺”的概念。什么是數(shù)據(jù)中臺呢?數(shù)據(jù)中臺至少應該具備如下三個特點:
- 在不移動數(shù)據(jù)的情況下,提供全司視角數(shù)據(jù)視圖,并且能夠?qū)⑦@種能力釋放給兄弟部門。
- 在不干涉其他部門API定義的情況下,提供全司視角的(也包括外部API)的API服務視圖,并且能夠在中臺中組裝使用。
- 所有的人都可以在數(shù)據(jù)中臺上以統(tǒng)一的,簡單的語言,結合第二點中提到的API服務能力,在中臺中對第一點中提到的數(shù)據(jù)進行加工處理,這些加工處理包括批處理,流式,包括機器學習訓練,批預測,提供API服務等。
簡而言之,數(shù)據(jù)中臺應該是分析師,算法,研發(fā),產(chǎn)品,運營甚至老板日常工作的集中式的控制臺。MLSQL就可以做成這么一件事,為什么呢?
正如前言所述,MLSQL是一門語言,一個分布式引擎,并且支持各種數(shù)據(jù)源,所以他天然適合做數(shù)據(jù)中臺。
大數(shù)據(jù)研發(fā)同學看這里的痛點
- 很多情況大數(shù)據(jù)平臺和算法平臺是割裂的,這就意味著人員和工作流程,還有研發(fā)方式,語言都是割裂。
- 在大數(shù)據(jù)平臺里面,批處理,流式,API服務等等都是割裂的。我們依賴各種語言,比如Scala/Java/Go/Python等等,每個人寫出的代碼各有千秋,分析師,研發(fā),數(shù)倉各自看不懂對方的東西。
- 起點低,都快進入了2019年了,很多同學們還在用一些比較原始的技術和理念,比如還在大量使用類似yarn調(diào)度的方式去做批任務,流式也還停留在JStorm,Spark Streaming等技術上。哪怕是沒有多少歷史包袱的公司也是。
- 我們會有大量的項目需要維護,而在我看來,一個中小型大數(shù)據(jù)部門,2-3個核心項目倉庫是最理想的。代碼維護是昂貴的。
MLSQL首先是彌合了大數(shù)據(jù)平臺和算法平臺的割裂,這是因為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;
這段腳本完成了數(shù)據(jù)加載,處理,tfidf化,并且使用兩個算法進行訓練,注冊模型為函數(shù),最后調(diào)用函數(shù)進行預測,一氣呵成。大家可以看這個PPT,了解MLSQL如何進行批,流,算法,爬蟲相關的工作。
第二個問題,如何統(tǒng)一流批,API, 在上面的PPT里大家可以看到,所有工作都使用MLSQL語言完成,除此之外你可以整合各類API服務,用MLSQL完成諸如爬蟲,發(fā)郵件,生成下載鏈接等等功能。
第三個問題,MLSQL底層集合了譬如Spark,Tensorflow/Sklearn等各種主流技術以及大數(shù)據(jù)相關的思想,所以其實并不需要你關注太多。
算法的同學看這里的痛點
我們假設大部分算法的代碼都是基于Python的:
- 項目難以重現(xiàn),可閱讀性和環(huán)境要求導致能把另外一個同事寫的python項目運行起來不得不靠運氣
- 和大數(shù)據(jù)平臺銜接并不容易,需要讓研發(fā)重新做工程實現(xiàn),導致落地周期變長。
- 訓練時數(shù)據(jù)預處理/特征化無法在預測時復用
- 集成到流式,批處理和提供API服務都不是一件容易的事情
- 代碼/算法復用級別有限,依賴于算法自身的經(jīng)驗以及自身的工具箱,團隊難以共享。
- 其他團隊很難接入算法的工作
這些問題我們慢慢看。首先是項目難以重現(xiàn),環(huán)境問題。MLSQL 的PythonALg模塊可以集成任何Python算法項目。我們通過借鑒MLFlow的一些思想可以很好的解決Python環(huán)境依賴問題,并且比MLFlow具有更少的侵入性。用戶只要在自己的項目里添加一個包依賴文件就可以很好的解決。
第二個和大數(shù)據(jù)平臺銜接,我PPT里還有個so sad 系列:

基本算法工程師搞了個算法,很可能需要兩周才能上線,你說怎么才能迭代變快。兩周上線不可怕,可怕的是每個項目都是如此。那么MLSQL怎么去解決呢? 正如前面提到的, MLSQL 的PythonALg模塊可以集成任何Python算法項目,算法工程師只要把項目丟進MLSQL就可以轉(zhuǎn)化為一個算法模塊,然后使用MLSQL語言調(diào)用。所以天然就是銜接的。如果用戶不使用Python,那更好,MLSQL自己也集成了深度學習和傳統(tǒng)機器學習相關的庫,你可以用現(xiàn)成的。
第三個問題,”訓練時數(shù)據(jù)預處理/特征化無法在預測時復用“,我們知道,在訓練時,都是批量數(shù)據(jù),而在預測時,都是一條一條的,本身模式就都是不一樣的。所以傳統(tǒng)的模式是很難復用的,在MLSQL里,所謂數(shù)據(jù)處理無非就是 SQL+UDF Script+Estimator/Transformer, 前面兩個復用其實沒啥問題,Estimator/Transformer 在訓練時,接受的是批量的數(shù)據(jù),并且將學習到的東西保存起來,之后在預測時,會將學習到的東西轉(zhuǎn)化函數(shù),然后使用函數(shù)對單條數(shù)據(jù)進行預測。大家看這個圖就明白了。

第四個問題,”集成到流式,批處理和提供API服務都不是一件容易的事情“,因為任何算法或者處理邏輯都可以被MLSQL自動轉(zhuǎn)化為一個UDF函數(shù),所以可以無縫的銜接進流式和批處理里。那么如何提供API服務呢?MLSQL核心理念如下:

我們可以把訓練階段的模型,udf, python/scala code都轉(zhuǎn)化為函數(shù),然后串聯(lián)函數(shù)就可以了。無需任何開發(fā),就可以部署出一個端到端的API服務。大家可以看到,一個標準的API服務本質(zhì)就是一個select語句。
5,6兩個問題,因為大家都用同一個語言,也就沒有難么困難的交流了。研發(fā)可以為算法提供更多的預處理Estimator/Transformer,算法也可以提供更多的算法Estimator/Transformer。
分析師同學的痛點看這里
分析師大部分都是寫SQL, hive script其實shell + SQL, 這無形又需要分析師懂shell了, shell是一門神奇的語言,主要是他不正規(guī),沒有標準委員會去約束。這是第一個痛點。
第二個痛點是啥呢, SQL難以復用。 復用體現(xiàn)在幾個層面,第一,同一條SQL里有多個相同的case when語句,我得手寫很多次。第二個是,SQL表的復用,SQL執(zhí)行完一般就是一張表,如果我想復用這張表,那我就得寫hive表,寫hive表很痛苦,耗時并且占用存儲,成本高。我能不能構建類似視圖的東西呢?比如我需要A表,A 其實就是一條SQL,我需要的時候include這種A就好了。
第三個痛點是,我啥事都得靠你研發(fā),比如處理一個東西依賴的UDF函數(shù),都得等你研發(fā)搞。那我能不能自己用Python寫一個UDF,不需要編譯,不需要上線,還能復用呢?
這些問題如何解決呢?MLSQL的解決方式在這篇文章里 如何按程序員思維寫分析師腳本
所有同學的痛點
所有同學的痛點,其實就是協(xié)作痛點。不同同學講的語言不一樣,你用Java,我用SQL,我用Scala,我用C++。 MLSQL怎么解決這個痛點呢?同一個語言,同一個平臺。
MLSQL會不會不夠靈活,限制我們的能力?
如果是簡單的SQL其實肯定無法滿足算法和工程的要求呢,而MLSQL是SQL的超集,這意味著 MLSQL具備高度擴展能力,這包括:
- Estimator/Transformer ,前面我們看到train語法里的TfIdfInPlace,PythonAlg,這些模塊你可以用現(xiàn)成的,研發(fā)也可以擴展,然后--jars帶入后就可以使用。
- MLSQL提供了在腳本中寫python/scala UDF/UDAF的功能,這就意味著你可以通過代碼無需編譯和部署就能擴展MLSQL的功能。
- MLSQL 的PythonALg模塊可以集成任何Python算法項目。我們通過借鑒MLFlow的一些思想可以很好的解決Python環(huán)境依賴問題,并且比MLFlow具有更少的侵入性。
MLSQL 到底想干嘛
前面的數(shù)據(jù)中臺概念里,我們提到了全公司數(shù)據(jù)視圖,得益于我們底層依賴的Spark,我們基本上可以load任何類型的數(shù)據(jù)源,所以你可以實現(xiàn)不挪動數(shù)據(jù)的情況,就可以把數(shù)倉里的數(shù)據(jù),業(yè)務的數(shù)據(jù)庫,甚至execel放在一起進行join.
MLSQL就是想成為前面我們描述的一個數(shù)據(jù)中臺,整合大數(shù)據(jù)和機器學習還有分析的所有流程。他的終極目標也很簡單,讓你的工作更輕松。
MLSQL 官網(wǎng)地址是: http://www.mlsql.tech
MLSQL的github地址: https://github.com/allwefantasy/streamingpro
MLSQL博客地址:http://www.itdecent.cn/c/759bc22b9e15
客戶有話說
剛開始推的時候,我被噴的不行,好多SQL跑不出來,寫的各種復雜,然后跟我說數(shù)據(jù)庫都能跑出來,為啥大數(shù)據(jù)平臺跑不出來。。。然后我給他們調(diào)優(yōu),都跑出來了,最后覺得MLSQL挺好用的。但是現(xiàn)在要用的人太多,簡直奔潰。
點評:產(chǎn)品在推廣之初,總是會受到各種質(zhì)疑。能頂住壓力推廣,真的很重要,后面獲益也會很多。
MLSQL是一個可玩性很高的平臺。
確實,感覺做的很好,自由度很高。
點評: MLSQL畢竟是一個語言,而且可以很容易做成坨坨拽拽的產(chǎn)品,自動生成MLSQL腳本。
從MLSQL中可以看到世界級影響力產(chǎn)品的潛質(zhì)
點評: 客戶這么夸真的扛不住。。。。。
Q/A:
Q1: 大中臺還要能支持上層業(yè)務快速的靈活定制,上線,MLSQL能做到么?
A: MLSQL 是一個腳本語言,無需編譯和部署,調(diào)試完畢即可上線,所以天生適合上層業(yè)務的靈活性。我們舉個如何用MLSQL實現(xiàn)爬蟲功能的例子來說明如何快速的滿足業(yè)務需求。假設我們需要一個快速構建一個爬蟲服務,但是MLSQL自帶的瀏覽器渲染功能滿足不了訴求,這個時候我們可以開發(fā)一個瀏覽器渲染的服務,其API輸入是URL,輸出是經(jīng)過渲染后的html。其他所有功能全部用MLSQL來完成。實現(xiàn)上會是這個樣子的:
set chrome_render_api="http:....."
load crawller.`http://www.csdn.net/blog/ai` where xpath=..... as url_table;
select http("${chrome_render_api}",map(......)) as html,url from url_table as htmls;
.......更多處理
---存儲進數(shù)據(jù)庫
save result as jdbc.`db.table`....
開發(fā)完畢后,如果有業(yè)務需求變更,我直接更改腳本,然后發(fā)布,重新設置定時任務,基本上是0成本的,而且大家都看得懂。