前言

先給MLSQL做個(gè)定義：

1. MLSQL是首先是一門語言，SQL的超集。 這意味著他的門檻足夠低，無論分析師，研發(fā)，算法，運(yùn)營，產(chǎn)品經(jīng)理都可以用。
2. MLSQL 同時(shí)也是一個(gè)跨平臺(tái)的支持私有部署和云部署的分布式計(jì)算引擎。這意味著你可以充分利用MLSQL的算力，完成大部分算法和大數(shù)據(jù)相關(guān)的工作。

MLSQL踐行了用一個(gè)語言，一個(gè)平臺(tái)去完成大數(shù)據(jù)和機(jī)器學(xué)習(xí)相關(guān)的工作。

數(shù)據(jù)中臺(tái)的概念（讓我們炒個(gè)概念）

在談MLSQL解決了什么問題之前，我們先提一個(gè)“數(shù)據(jù)中臺(tái)”的概念。什么是數(shù)據(jù)中臺(tái)呢？數(shù)據(jù)中臺(tái)至少應(yīng)該具備如下三個(gè)特點(diǎn)：

1. 在不移動(dòng)數(shù)據(jù)的情況下，提供全司視角數(shù)據(jù)視圖，并且能夠?qū)⑦@種能力釋放給兄弟部門。
2. 在不干涉其他部門API定義的情況下，提供全司視角的（也包括外部API）的API服務(wù)視圖，并且能夠在中臺(tái)中組裝使用。
3. 所有的人都可以在數(shù)據(jù)中臺(tái)上以統(tǒng)一的，簡單的語言，結(jié)合第二點(diǎn)中提到的API服務(wù)能力，在中臺(tái)中對(duì)第一點(diǎn)中提到的數(shù)據(jù)進(jìn)行加工處理，這些加工處理包括批處理，流式，包括機(jī)器學(xué)習(xí)訓(xùn)練，批預(yù)測(cè)，提供API服務(wù)等。

簡而言之，數(shù)據(jù)中臺(tái)應(yīng)該是分析師，算法，研發(fā)，產(chǎn)品，運(yùn)營甚至老板日常工作的集中式的控制臺(tái)。MLSQL就可以做成這么一件事，為什么呢？

正如前言所述，MLSQL是一門語言，一個(gè)分布式引擎，并且支持各種數(shù)據(jù)源，所以他天然適合做數(shù)據(jù)中臺(tái)。

大數(shù)據(jù)研發(fā)同學(xué)看這里的痛點(diǎn)

1. 很多情況大數(shù)據(jù)平臺(tái)和算法平臺(tái)是割裂的，這就意味著人員和工作流程，還有研發(fā)方式，語言都是割裂。
2. 在大數(shù)據(jù)平臺(tái)里面，批處理，流式，API服務(wù)等等都是割裂的。我們依賴各種語言，比如Scala/Java/Go/Python等等，每個(gè)人寫出的代碼各有千秋，分析師，研發(fā)，數(shù)倉各自看不懂對(duì)方的東西。
3. 起點(diǎn)低，都快進(jìn)入了2019年了，很多同學(xué)們還在用一些比較原始的技術(shù)和理念，比如還在大量使用類似yarn調(diào)度的方式去做批任務(wù)，流式也還停留在JStorm,Spark Streaming等技術(shù)上。哪怕是沒有多少歷史包袱的公司也是。
4. 我們會(huì)有大量的項(xiàng)目需要維護(hù)，而在我看來，一個(gè)中小型大數(shù)據(jù)部門，2-3個(gè)核心項(xiàng)目倉庫是最理想的。代碼維護(hù)是昂貴的。

MLSQL首先是彌合了大數(shù)據(jù)平臺(tái)和算法平臺(tái)的割裂，這是因?yàn)镸LSQL對(duì)算法有著非常友好的支持。我們看一個(gè)比較典型的示例：

-- 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化，并且使用兩個(gè)算法進(jìn)行訓(xùn)練,注冊(cè)模型為函數(shù)，最后調(diào)用函數(shù)進(jìn)行預(yù)測(cè)，一氣呵成。大家可以看這個(gè)PPT,了解MLSQL如何進(jìn)行批，流，算法，爬蟲相關(guān)的工作。

第二個(gè)問題，如何統(tǒng)一流批，API, 在上面的PPT里大家可以看到，所有工作都使用MLSQL語言完成，除此之外你可以整合各類API服務(wù)，用MLSQL完成諸如爬蟲，發(fā)郵件，生成下載鏈接等等功能。

第三個(gè)問題，MLSQL底層集合了譬如Spark,Tensorflow/Sklearn等各種主流技術(shù)以及大數(shù)據(jù)相關(guān)的思想，所以其實(shí)并不需要你關(guān)注太多。

算法的同學(xué)看這里的痛點(diǎn)

我們假設(shè)大部分算法的代碼都是基于Python的：

1. 項(xiàng)目難以重現(xiàn)，可閱讀性和環(huán)境要求導(dǎo)致能把另外一個(gè)同事寫的python項(xiàng)目運(yùn)行起來不得不靠運(yùn)氣
2. 和大數(shù)據(jù)平臺(tái)銜接并不容易，需要讓研發(fā)重新做工程實(shí)現(xiàn)，導(dǎo)致落地周期變長。
3. 訓(xùn)練時(shí)數(shù)據(jù)預(yù)處理/特征化無法在預(yù)測(cè)時(shí)復(fù)用
4. 集成到流式，批處理和提供API服務(wù)都不是一件容易的事情
5. 代碼/算法復(fù)用級(jí)別有限，依賴于算法自身的經(jīng)驗(yàn)以及自身的工具箱，團(tuán)隊(duì)難以共享。
6. 其他團(tuán)隊(duì)很難接入算法的工作

這些問題我們慢慢看。首先是項(xiàng)目難以重現(xiàn)，環(huán)境問題。MLSQL 的PythonALg模塊可以集成任何Python算法項(xiàng)目。我們通過借鑒MLFlow的一些思想可以很好的解決Python環(huán)境依賴問題，并且比MLFlow具有更少的侵入性。用戶只要在自己的項(xiàng)目里添加一個(gè)包依賴文件就可以很好的解決。

第二個(gè)和大數(shù)據(jù)平臺(tái)銜接，我PPT里還有個(gè)so sad 系列：

image.png

基本算法工程師搞了個(gè)算法，很可能需要兩周才能上線，你說怎么才能迭代變快。兩周上線不可怕，可怕的是每個(gè)項(xiàng)目都是如此。那么MLSQL怎么去解決呢？ 正如前面提到的， MLSQL 的PythonALg模塊可以集成任何Python算法項(xiàng)目，算法工程師只要把項(xiàng)目丟進(jìn)MLSQL就可以轉(zhuǎn)化為一個(gè)算法模塊，然后使用MLSQL語言調(diào)用。所以天然就是銜接的。如果用戶不使用Python,那更好，MLSQL自己也集成了深度學(xué)習(xí)和傳統(tǒng)機(jī)器學(xué)習(xí)相關(guān)的庫，你可以用現(xiàn)成的。

第三個(gè)問題，”訓(xùn)練時(shí)數(shù)據(jù)預(yù)處理/特征化無法在預(yù)測(cè)時(shí)復(fù)用“，我們知道，在訓(xùn)練時(shí)，都是批量數(shù)據(jù)，而在預(yù)測(cè)時(shí)，都是一條一條的，本身模式就都是不一樣的。所以傳統(tǒng)的模式是很難復(fù)用的，在MLSQL里，所謂數(shù)據(jù)處理無非就是 SQL+UDF Script+Estimator/Transformer, 前面兩個(gè)復(fù)用其實(shí)沒啥問題，Estimator/Transformer 在訓(xùn)練時(shí)，接受的是批量的數(shù)據(jù)，并且將學(xué)習(xí)到的東西保存起來，之后在預(yù)測(cè)時(shí)，會(huì)將學(xué)習(xí)到的東西轉(zhuǎn)化函數(shù)，然后使用函數(shù)對(duì)單條數(shù)據(jù)進(jìn)行預(yù)測(cè)。大家看這個(gè)圖就明白了。

image.png

第四個(gè)問題，”集成到流式，批處理和提供API服務(wù)都不是一件容易的事情“，因?yàn)槿魏嗡惴ɑ蛘咛幚磉壿嫸伎梢员籑LSQL自動(dòng)轉(zhuǎn)化為一個(gè)UDF函數(shù)，所以可以無縫的銜接進(jìn)流式和批處理里。那么如何提供API服務(wù)呢？MLSQL核心理念如下：

image.png

我們可以把訓(xùn)練階段的模型，udf, python/scala code都轉(zhuǎn)化為函數(shù)，然后串聯(lián)函數(shù)就可以了。無需任何開發(fā)，就可以部署出一個(gè)端到端的API服務(wù)。大家可以看到，一個(gè)標(biāo)準(zhǔn)的API服務(wù)本質(zhì)就是一個(gè)select語句。

5，6兩個(gè)問題，因?yàn)榇蠹叶加猛粋€(gè)語言，也就沒有難么困難的交流了。研發(fā)可以為算法提供更多的預(yù)處理Estimator/Transformer,算法也可以提供更多的算法Estimator/Transformer。

分析師同學(xué)的痛點(diǎn)看這里

分析師大部分都是寫SQL, hive script其實(shí)shell + SQL, 這無形又需要分析師懂shell了， shell是一門神奇的語言，主要是他不正規(guī)，沒有標(biāo)準(zhǔn)委員會(huì)去約束。這是第一個(gè)痛點(diǎn)。

第二個(gè)痛點(diǎn)是啥呢， SQL難以復(fù)用。 復(fù)用體現(xiàn)在幾個(gè)層面，第一，同一條SQL里有多個(gè)相同的case when語句，我得手寫很多次。第二個(gè)是，SQL表的復(fù)用，SQL執(zhí)行完一般就是一張表，如果我想復(fù)用這張表，那我就得寫hive表，寫hive表很痛苦，耗時(shí)并且占用存儲(chǔ)，成本高。我能不能構(gòu)建類似視圖的東西呢？比如我需要A表，A 其實(shí)就是一條SQL，我需要的時(shí)候include這種A就好了。

第三個(gè)痛點(diǎn)是，我啥事都得靠你研發(fā)，比如處理一個(gè)東西依賴的UDF函數(shù)，都得等你研發(fā)搞。那我能不能自己用Python寫一個(gè)UDF,不需要編譯，不需要上線，還能復(fù)用呢？

這些問題如何解決呢？MLSQL的解決方式在這篇文章里 如何按程序員思維寫分析師腳本

所有同學(xué)的痛點(diǎn)

所有同學(xué)的痛點(diǎn)，其實(shí)就是協(xié)作痛點(diǎn)。不同同學(xué)講的語言不一樣，你用Java,我用SQL,我用Scala,我用C++。 MLSQL怎么解決這個(gè)痛點(diǎn)呢？同一個(gè)語言，同一個(gè)平臺(tái)。

MLSQL會(huì)不會(huì)不夠靈活，限制我們的能力？

如果是簡單的SQL其實(shí)肯定無法滿足算法和工程的要求呢，而MLSQL是SQL的超集,這意味著 MLSQL具備高度擴(kuò)展能力，這包括：

1. Estimator/Transformer ,前面我們看到train語法里的TfIdfInPlace，PythonAlg，這些模塊你可以用現(xiàn)成的，研發(fā)也可以擴(kuò)展，然后--jars帶入后就可以使用。
2. MLSQL提供了在腳本中寫python/scala UDF/UDAF的功能，這就意味著你可以通過代碼無需編譯和部署就能擴(kuò)展MLSQL的功能。
3. MLSQL 的PythonALg模塊可以集成任何Python算法項(xiàng)目。我們通過借鑒MLFlow的一些思想可以很好的解決Python環(huán)境依賴問題，并且比MLFlow具有更少的侵入性。

MLSQL 到底想干嘛

前面的數(shù)據(jù)中臺(tái)概念里，我們提到了全公司數(shù)據(jù)視圖，得益于我們底層依賴的Spark,我們基本上可以load任何類型的數(shù)據(jù)源，所以你可以實(shí)現(xiàn)不挪動(dòng)數(shù)據(jù)的情況，就可以把數(shù)倉里的數(shù)據(jù)，業(yè)務(wù)的數(shù)據(jù)庫，甚至execel放在一起進(jìn)行join.

MLSQL就是想成為前面我們描述的一個(gè)數(shù)據(jù)中臺(tái)，整合大數(shù)據(jù)和機(jī)器學(xué)習(xí)還有分析的所有流程。他的終極目標(biāo)也很簡單，讓你的工作更輕松。

MLSQL 官網(wǎng)地址是: http://www.mlsql.tech
MLSQL的github地址： https://github.com/allwefantasy/streamingpro
MLSQL博客地址：http://www.lxweimin.com/c/759bc22b9e15

客戶有話說

剛開始推的時(shí)候，我被噴的不行，好多SQL跑不出來，寫的各種復(fù)雜，然后跟我說數(shù)據(jù)庫都能跑出來，為啥大數(shù)據(jù)平臺(tái)跑不出來。。。然后我給他們調(diào)優(yōu)，都跑出來了，最后覺得MLSQL挺好用的。但是現(xiàn)在要用的人太多，簡直奔潰。

點(diǎn)評(píng)：產(chǎn)品在推廣之初，總是會(huì)受到各種質(zhì)疑。能頂住壓力推廣，真的很重要，后面獲益也會(huì)很多。

MLSQL是一個(gè)可玩性很高的平臺(tái)。
確實(shí)，感覺做的很好，自由度很高。

點(diǎn)評(píng)： MLSQL畢竟是一個(gè)語言，而且可以很容易做成坨坨拽拽的產(chǎn)品，自動(dòng)生成MLSQL腳本。

從MLSQL中可以看到世界級(jí)影響力產(chǎn)品的潛質(zhì)

點(diǎn)評(píng)： 客戶這么夸真的扛不住。。。。。

Q/A:

Q1: 大中臺(tái)還要能支持上層業(yè)務(wù)快速的靈活定制，上線，MLSQL能做到么？

A: MLSQL 是一個(gè)腳本語言，無需編譯和部署，調(diào)試完畢即可上線，所以天生適合上層業(yè)務(wù)的靈活性。我們舉個(gè)如何用MLSQL實(shí)現(xiàn)爬蟲功能的例子來說明如何快速的滿足業(yè)務(wù)需求。假設(shè)我們需要一個(gè)快速構(gòu)建一個(gè)爬蟲服務(wù)，但是MLSQL自帶的瀏覽器渲染功能滿足不了訴求，這個(gè)時(shí)候我們可以開發(fā)一個(gè)瀏覽器渲染的服務(wù)，其API輸入是URL,輸出是經(jīng)過渲染后的html。其他所有功能全部用MLSQL來完成。實(shí)現(xiàn)上會(huì)是這個(gè)樣子的：

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;
.......更多處理
---存儲(chǔ)進(jìn)數(shù)據(jù)庫
save result as jdbc.`db.table`....

開發(fā)完畢后，如果有業(yè)務(wù)需求變更，我直接更改腳本，然后發(fā)布，重新設(shè)置定時(shí)任務(wù)，基本上是0成本的，而且大家都看得懂。