先看看做算法有哪些痛點（我們假設大部分算法的代碼都是基于Python的）：
- 項目難以重現(xiàn)，可閱讀性和環(huán)境要求導致能把另外一個同事寫的python項目運行起來不得不靠運氣
- 和大數(shù)據(jù)平臺銜接并不容易，需要讓研發(fā)重新做工程實現(xiàn)，導致落地周期變長。
- 訓練時數(shù)據(jù)預處理/特征化無法在預測時復用
- 集成到流式，批處理和提供API服務都不是一件容易的事情
- 代碼/算法復用級別有限，依賴于算法自身的經(jīng)驗以及自身的工具箱，團隊難以共享。
- 其他團隊很難接入算法的工作
MLSQL如何解決這些問題呢？
統(tǒng)一交互語言
MLSQL提供了一套SQL的超集的DSL語法MLSQL，數(shù)據(jù)處理，模型訓練，模型預測部署等都是以MLSQL語言交互，該語言簡單易懂，無論算法，分析師，甚至運營都能看懂，極大的減少了團隊的溝通成本，同時也使得更多的人可以做算法方面的工作。
數(shù)據(jù)預處理 / 算法模塊化
所有較為復雜的數(shù)據(jù)預處理和算法都是模塊化的，通過函數(shù)以及純SQL來進行銜接。比如：
-- 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="${sklearnTrainPath}"
-- kafka params for log
and `kafkaParam.bootstrap.servers`="${kafkaDomain}"
and `kafkaParam.topic`="test"
and `kafkaParam.group_id`="g_test-2"
and `kafkaParam.userName`="pi-algo"
-- distribute data
and enableDataLocal="true"
and dataLocalFormat="json"
-- sklearn params
and `fitParam.0.moduleName`="sklearn.svm"
and `fitParam.0.className`="SVC"
and `fitParam.0.featureCol`="features"
and `fitParam.0.labelCol`="label"
and `fitParam.0.class_weight`="balanced"
and `fitParam.0.verbose`="true"
and `fitParam.1.moduleName`="sklearn.naive_bayes"
and `fitParam.1.className`="GaussianNB"
and `fitParam.1.featureCol`="features"
and `fitParam.1.labelCol`="label"
and `fitParam.1.class_weight`="balanced"
and `fitParam.1.labelSize`="2"
-- python env
and `systemParam.pythonPath`="python"
and `systemParam.pythonParam`="-u"
and `systemParam.pythonVer`="2.7";
這段小腳本腳本完成了數(shù)據(jù)加載，特征工程，最后的訓練。所有以train開頭的，都是模塊，以select 開頭的都是標準sql,
以load開頭的則是各種數(shù)據(jù)源的加載。
在MLSQL中，任何一個模塊都有兩個產(chǎn)出：模型和函數(shù)。訓練時該模塊會產(chǎn)生一個對應的模型，預測時該模型會提供一個函數(shù)，從而實現(xiàn)
- 對訓練階段的數(shù)據(jù)處理邏輯，在預測時能進行復用。
- 算法訓練的模型可以直接部署成一個預測函數(shù)。
標準遵循
所有數(shù)據(jù)處理模塊，算法模塊，都有標準的暴露參數(shù)的方式，也就是前面例子類似下面的句子：
and `fitParam.0.labelCol`="label"
and `fitParam.0.class_weight`="balanced"
and `fitParam.0.verbose`="true"
比如該算法暴露了class_weight,labelCol,verbose等參數(shù)。所有人開發(fā)的算法模塊和數(shù)據(jù)處理模塊都可以很好的進行復用。
分布式和單機多種部署形態(tài)
MLSQL是基于Spark改造而成，這就直接繼承了Spark的多個優(yōu)點：
- 你可以在MLSQL里獲取基本上大部分存儲的支持，比如ES,MySQL,Parquet,ORC,JSON,CSV等等
- 你可以部署在多種環(huán)境里，比如Yarn,Mesos,Local等模式
數(shù)據(jù)處理模塊/算法模型易于部署
同行啟動一個local模式的MLSQL Server,然后注冊我們訓練的時候使用到的數(shù)據(jù)處理模塊和算法模塊，每個模塊都會產(chǎn)生一個函數(shù)，接著就能通過http接口傳遞一個函數(shù)嵌套的方式完成一個pipeline的使用了。對于函數(shù)我們確保其響應速度，一般都是在毫秒級。
注冊就是一個簡單的register語句：
-- transform model into udf
register PythonAlg.`${modelPath}` as topic_spam_predict options
pythonScriptPath="${sklearnPredictPath}"
;
支持所有提供了Python語言接口的算法框架的集成
只要實現(xiàn)MLSQL的標準規(guī)范，你就能夠輕而易舉的將各種框架集成到MLSQL中。目前已經(jīng)支持SKlearn,同時有Keras圖片處理等相關例子。算法可以專注于算法模塊的研發(fā)，研發(fā)可以專注于數(shù)據(jù)處理模塊的開發(fā)，所有的人都可以通過MLSQL復用這些模塊，完成算法業(yè)務的開發(fā)。
