摘要：在近期舉辦的全球架構(gòu)師峰會上，個推首席數(shù)據(jù)架構(gòu)師袁凱，基于他在數(shù)據(jù)平臺的建設(shè)以及數(shù)據(jù)產(chǎn)品研發(fā)的多年經(jīng)驗，分享了面向機器學(xué)習(xí)數(shù)據(jù)平臺的設(shè)計與搭建。二具體開展機器學(xué)習(xí)的過程原始數(shù)據(jù)經(jīng)過數(shù)據(jù)的處理，入庫到數(shù)據(jù)倉里。

機器學(xué)習(xí)作為近幾年的一項熱門技術(shù)，不僅憑借眾多“人工智能”產(chǎn)品而為人所熟知，更是從根本上增能了傳統(tǒng)的互聯(lián)網(wǎng)產(chǎn)品。在近期舉辦的2018 ArchSummit全球架構(gòu)師峰會上，個推首席數(shù)據(jù)架構(gòu)師袁凱，基于他在數(shù)據(jù)平臺的建設(shè)以及數(shù)據(jù)產(chǎn)品研發(fā)的多年經(jīng)驗，分享了《面向機器學(xué)習(xí)數(shù)據(jù)平臺的設(shè)計與搭建》。

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

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

2、廣告人群定向；

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

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

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

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

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

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

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

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

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

三、機器學(xué)習(xí)項目落地的常見問題
雖然上面的流程很清晰，但在具體落地的過程中也會遇到很多問題，這里我就之前的實踐經(jīng)驗談幾點。

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

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

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

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

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

5、機器學(xué)習(xí)領(lǐng)域的一大難題在于對數(shù)據(jù)的使用，它的成本非常高，因為我們把大量時間用于探索數(shù)據(jù)了。

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

四、個推針對機器學(xué)習(xí)問題的解決方案
首先說一下我們這個平臺的目標：

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

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

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

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

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

下半部分是建模平臺，也叫實驗平臺，它主要供算法工程師使用，建模平臺包含：

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

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

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

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

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

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

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

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

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

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

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

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

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

五、方案實踐具體要點
第一點，我們講講jupyter這塊：

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

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

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

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

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

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

1）標準化的ID Mapping服務(wù)API。

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

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

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

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

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

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

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

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

最后分享下我們的一些經(jīng)驗：

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

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

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

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

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

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

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

以上就是我在機器學(xué)習(xí)方面的一些心得經(jīng)驗，希望對你有幫助。也歡迎在留言區(qū)針對相關(guān)的問題與我交流！