機(jī)器學(xué)習(xí)作為近幾年的一項(xiàng)熱門技術(shù)，不僅憑借眾多“人工智能”產(chǎn)品而為人所熟知，更是從根本上增能了傳統(tǒng)的互聯(lián)網(wǎng)產(chǎn)品。下文將基于本人所負(fù)責(zé)的個(gè)推大數(shù)據(jù)平臺(tái)搭建工作，與大家分享個(gè)推數(shù)據(jù)平臺(tái)架構(gòu)方面的經(jīng)驗(yàn)以及踩過的一些坑。

一、背景：機(jī)器學(xué)習(xí)在個(gè)推業(yè)務(wù)中的應(yīng)用場景

作為獨(dú)立的智能大數(shù)據(jù)服務(wù)商，個(gè)推主要業(yè)務(wù)包括開發(fā)者服務(wù)、精準(zhǔn)營銷服務(wù)和各垂直領(lǐng)域的大數(shù)據(jù)服務(wù)。而機(jī)器學(xué)習(xí)技術(shù)在多項(xiàng)業(yè)務(wù)及產(chǎn)品中均有涉及：

1、個(gè)推能夠提供基于精準(zhǔn)用戶畫像的智能推送。其中用戶標(biāo)簽主要是基于機(jī)器學(xué)習(xí)，通過訓(xùn)練模型后對人群做預(yù)測分類;

2、廣告人群定向;

3、商圈景區(qū)人流量預(yù)測;

4、移動(dòng)開發(fā)領(lǐng)域經(jīng)常出現(xiàn)虛假設(shè)備，機(jī)器學(xué)習(xí)能夠幫助開發(fā)者識(shí)別新增的用戶的真?zhèn)?

5、個(gè)性化內(nèi)容推薦;

6、用戶流失以及留存周期的預(yù)測。

[[237115]]

二、具體開展機(jī)器學(xué)習(xí)的過程

1、原始數(shù)據(jù)經(jīng)過數(shù)據(jù)的ETL處理，入庫到數(shù)據(jù)倉里。

2、上面藍(lán)色部分代表機(jī)器學(xué)習(xí)：首先把樣本數(shù)據(jù)與我們的自有數(shù)據(jù)進(jìn)行匹配，然后洞察這份數(shù)據(jù)并生成特征，這個(gè)過程叫特征工程。接下來基于這些特征，選擇合適的算法訓(xùn)練后得到模型，最終把模型具體應(yīng)用到全量的數(shù)據(jù)中，輸出預(yù)測的結(jié)果。

標(biāo)準(zhǔn)的機(jī)器學(xué)習(xí)工作流：針對業(yè)務(wù)上產(chǎn)生的具體問題，我們把它轉(zhuǎn)化成數(shù)據(jù)問題，或者評(píng)估它能否用數(shù)據(jù)來解決。將數(shù)據(jù)導(dǎo)入并過濾后，我們需要將數(shù)據(jù)與業(yè)務(wù)問題和目標(biāo)進(jìn)行相關(guān)性分析，并根據(jù)具體情況對數(shù)據(jù)做二次處理。

下一步我們進(jìn)行特征工程。從數(shù)據(jù)里找出跟目標(biāo)有關(guān)的特征變量，從而構(gòu)建或衍生出一些特征，同時(shí)要把無意義的特征剔除掉。我們大概需要花80%的時(shí)間在特征工程這個(gè)環(huán)節(jié)。選出特征之后，我們會(huì)用邏輯回歸和RNN等算法進(jìn)行模型的訓(xùn)練。接下來需要對模型做驗(yàn)證，判斷其是否符合目標(biāo)。不符合目標(biāo)的原因有可能是數(shù)據(jù)和目標(biāo)不相關(guān)，需要重新采集;也有可能是我們在探索的時(shí)候，工作不到位，因而需要對現(xiàn)有的數(shù)據(jù)重新探索，再進(jìn)行特征工程這些步驟。如果最終模型符合業(yè)務(wù)預(yù)期，我們會(huì)把它應(yīng)用在業(yè)務(wù)線上面。

三、機(jī)器學(xué)習(xí)項(xiàng)目落地的常見問題

雖然上面的流程很清晰，但在具體落地的過程中也會(huì)遇到很多問題，這里我就之前的實(shí)踐經(jīng)驗(yàn)談幾點(diǎn)。

1、現(xiàn)在大部分公司都已經(jīng)進(jìn)入大數(shù)據(jù)的時(shí)代，相比于以往的小數(shù)據(jù)級(jí)的階段，在機(jī)器學(xué)習(xí)或者數(shù)據(jù)挖掘等工作方面，對我們的建模人員、算法專家的技能要求變高，工作難度也大大地提升了。

以往大家自己在單機(jī)上就可以完成機(jī)器學(xué)習(xí)的數(shù)據(jù)預(yù)處理、數(shù)據(jù)分析以及最終機(jī)器學(xué)習(xí)的分析和上線。但在海量數(shù)據(jù)情況下，可能需要接觸到Hadoop生態(tài)圈。

2、做監(jiān)督學(xué)習(xí)時(shí)，經(jīng)常需要匹配樣本。數(shù)據(jù)倉庫里面的數(shù)據(jù)可能是萬億級(jí)別，提取數(shù)據(jù)周期非常長，大把的時(shí)間要用于等待機(jī)器把這些數(shù)據(jù)抽取出來。

3、大多數(shù)情況下，很多業(yè)務(wù)由一兩個(gè)算法工程師負(fù)責(zé)挖掘，因而經(jīng)常會(huì)出現(xiàn)不同小組的建模工具不太統(tǒng)一或?qū)崿F(xiàn)流程不規(guī)范的情況。不統(tǒng)一會(huì)造成很多代碼重復(fù)率高，建模過程并沒有在團(tuán)隊(duì)里很好地沉淀下來。

4、很多機(jī)器學(xué)習(xí)算法工程師的背景存在專業(yè)的局限性，他們可能在代碼工程化意識(shí)和經(jīng)驗(yàn)上相對會(huì)薄弱一些。常見的做法是：算法工程師會(huì)在實(shí)驗(yàn)階段把特征生成代碼和訓(xùn)練代碼寫好，交給做工程開發(fā)的同學(xué)，但這些代碼無法在全量數(shù)據(jù)上運(yùn)行起來。之后工程開發(fā)同學(xué)會(huì)把代碼重新實(shí)現(xiàn)一遍，保證它的高可用和高效。但即便如此，也常常出現(xiàn)翻譯不到位的情況，導(dǎo)致溝通成本高，上線應(yīng)用周期長。

5、機(jī)器學(xué)習(xí)領(lǐng)域的一大難題在于對數(shù)據(jù)的使用，它的成本非常高，因?yàn)槲覀儼汛罅繒r(shí)間用于探索數(shù)據(jù)了。

6、個(gè)推有多項(xiàng)業(yè)務(wù)在使用機(jī)器學(xué)習(xí)，但并不統(tǒng)一，會(huì)造成重復(fù)開發(fā)，缺少平臺(tái)來沉淀和共享。這就導(dǎo)致已經(jīng)衍生出來的一些比較好用的特征，沒有得到廣泛的應(yīng)用。

四、個(gè)推針對機(jī)器學(xué)習(xí)問題的解決方案

首先說一下我們這個(gè)平臺(tái)的目標(biāo)：

***點(diǎn)，我們希望內(nèi)部的建模流程規(guī)范化。

第二點(diǎn)，我們希望提供一個(gè)端到端的解決方案，覆蓋從模型的開發(fā)到上線應(yīng)用整個(gè)流程。

第三點(diǎn)，我們希望平臺(tái)的數(shù)據(jù)，特別是開發(fā)出的特征數(shù)據(jù)可以運(yùn)營起來并在公司內(nèi)不同團(tuán)隊(duì)間共享使用。

第四點(diǎn)，這個(gè)平臺(tái)不是面向機(jī)器學(xué)習(xí)零基礎(chǔ)的開發(fā)人員，更多的是面向?qū)＜液桶雽＜业乃惴üこ處煟屗麄兲岣呓５男?。同時(shí)這個(gè)平臺(tái)要支持多租戶，確保保障數(shù)據(jù)安全。

以下是我們自己的整體方案，主要分成兩大塊：

下半部分是建模平臺(tái)，也叫實(shí)驗(yàn)平臺(tái)，它主要供算法工程師使用，建模平臺(tái)包含：

1、對應(yīng)IDE。在這個(gè)平臺(tái)上進(jìn)行數(shù)據(jù)探索、做數(shù)據(jù)的實(shí)驗(yàn)，并且它能支持項(xiàng)目的管理和共享。

2、我們希望把已經(jīng)開發(fā)好的特征數(shù)據(jù)管理起來，方便所有平臺(tái)用戶看到數(shù)據(jù)資產(chǎn)的情況。

3、樣本匹配時(shí)候，樣本ID可能與內(nèi)部ID不統(tǒng)一，這個(gè)時(shí)候需要做統(tǒng)一的ID匹配服務(wù)。

4、幫助算法工程師從萬億級(jí)數(shù)據(jù)里快速地抽取所需數(shù)據(jù)，這也是非常重要的一點(diǎn)。

5、做機(jī)器學(xué)習(xí)的過程中，除了基本的算法，實(shí)際上還有很多代碼是重復(fù)或者相似的，我們需要把這些常用代碼進(jìn)行函數(shù)化封裝。

6、支持對模型服務(wù)進(jìn)行打包部署。

7、模型還要支持版本管理。

8、在實(shí)際業(yè)務(wù)中應(yīng)用模型，需要實(shí)時(shí)監(jiān)控起來，跟進(jìn)模型的可用性、準(zhǔn)確性等。

上半部分是生產(chǎn)環(huán)境，運(yùn)行著數(shù)據(jù)處理pipeline，同時(shí)與數(shù)據(jù)建模平臺(tái)對接著。

在生產(chǎn)環(huán)境中，模型對應(yīng)的特征數(shù)據(jù)分兩類：

一類是實(shí)時(shí)特征數(shù)據(jù)，比如數(shù)據(jù)實(shí)時(shí)采集，生成一些實(shí)時(shí)的特征，根據(jù)不同的業(yè)務(wù)需求存儲(chǔ)在不同的集群里。

另一類是離線特征數(shù)據(jù)，離線數(shù)據(jù)加工后存到Hive，供模型應(yīng)用側(cè)進(jìn)行使用。

在生產(chǎn)環(huán)境中，我們可以提供在線的預(yù)測API或 離線預(yù)測好的數(shù)據(jù) 供業(yè)務(wù)線使用。

五、方案實(shí)踐具體要點(diǎn)

***點(diǎn)，我們講講jupyter這塊：

選擇Jupyter作為主要建模IDE而不是自研可視化拖拽建模工具，這樣的好處是可以做交互式的分析，建模效率也很高，擴(kuò)展方便，研發(fā)成本低。當(dāng)然類似微軟Azure這樣的可視化拖拽建模平臺(tái)，可以非常清晰地看到整個(gè)流程，適合入門級(jí)同學(xué)快速上手。但我們的目標(biāo)用戶是專家和半專家群體，所以我們選擇了最合適的Jupyter。

使用Jupyter時(shí)候，為了支持多租戶，我們采用Jupyterhub。底層機(jī)器學(xué)習(xí)框架我們用了Tensorflow、Pyspark、Sklearn等。數(shù)據(jù)處理探索時(shí)候，結(jié)合sparkmagic，可以非常方便地將寫在Jupyter上的Spark代碼運(yùn)行到Spark集群上。

對于Jupyter沒有現(xiàn)成的版本管理控制和項(xiàng)目管理， 我們結(jié)合git來解決。

另外為了提高建模人員在Jupyter上的效率，我們引入了比較多的插件，例如：把一些典型挖掘pipeline做成Jupyter模板，這樣需要再做一個(gè)類似業(yè)務(wù)的時(shí)候只需要基于模板再擴(kuò)展開發(fā)，比較好地解決了不規(guī)范的問題，避免了很多重復(fù)代碼，也為實(shí)驗(yàn)代碼轉(zhuǎn)化為生產(chǎn)代碼做好了基礎(chǔ)。

第二點(diǎn)，說下工具函數(shù)：

我們內(nèi)部提供了主要機(jī)器學(xué)習(xí)相關(guān)的函數(shù)庫和工具：

1)標(biāo)準(zhǔn)化的ID Mapping服務(wù)API。

2)創(chuàng)建數(shù)據(jù)抽取的API，無論是哪種存儲(chǔ)，分析人員只要統(tǒng)一調(diào)這個(gè)API就可。3)可視化做了標(biāo)準(zhǔn)化的函數(shù)庫和工具類。

4)Jupyter2AzkabanFlow: 可以把原本在Jupyter上寫好的代碼或者腳本自動(dòng)轉(zhuǎn)化成AzkabanFlow，解決了特征工程階段的代碼復(fù)用問題。

第三點(diǎn)，關(guān)于使用Tensorflow：

使用Tensorflow時(shí)，我們的選型是TensorflowOnSpark，原生的Tensorflow的分布式支持不夠好，需要去指定一些節(jié)點(diǎn)信息，使用難度較大。

TensorflowOnSpark能夠解決原生Tensorflow Cluster分布式問題，代碼也很容易遷移到TensorflowOnSpark上，基本不用改。

同時(shí)利用yarn可以支持GPU和CPU混部集群，資源易復(fù)用。

第四點(diǎn)，關(guān)于模型交付應(yīng)用：

在模型交付的問題上，我們把整個(gè)預(yù)測代碼框架化了，提供了多種標(biāo)準(zhǔn)的框架供分析人員直接選用。對輸出的模型文件有格式進(jìn)行要求，例如：只能選擇 pmml格式或者tensorflow pb格式。標(biāo)準(zhǔn)化之后，只要使用標(biāo)準(zhǔn)的預(yù)測函數(shù)庫，就可以把建模人員的工作和系統(tǒng)開發(fā)人員的工作解藕出來。

***分享下我們的一些經(jīng)驗(yàn)：

***，TensorflowOnSpark上的PS數(shù)量有限制，而且Worker和PS節(jié)點(diǎn)資源分配不是很靈活，都是等大。

第二，Jupyter在使用的時(shí)候，需要自己做一些改造，一些開源庫版本兼容性有問題。

第三，使用PMML有性能瓶頸，一些是java對象反復(fù)重建，還有一些是格式轉(zhuǎn)化損耗，具體大家可以抓取下jvm信息分析優(yōu)化。

第四，在落地過程使用Spark、Hive的問題上，需要提供易于使用的診斷工具，建模人員并不是Spark、Hive的專家，不一定熟悉如何診斷優(yōu)化。

第五，要把模型和特征庫當(dāng)成一個(gè)資產(chǎn)來看待，對它的價(jià)值定期做評(píng)估，要管理好它的生命周期。

第六，一些更偏底層的問題，比如: 硬件的選型可能要注意帶寬、內(nèi)存、GPU平衡。

***，需要平衡技術(shù)棧增加和維護(hù)代價(jià)，避免引入太多新工具新技術(shù)，導(dǎo)致運(yùn)維困難。