面向機器學習數據平臺的設計與搭建

       機器學習做爲近幾年的一項熱門技術，不只憑藉衆多「人工智能」產品而爲人所熟知，更是從根本上增能了傳統的互聯網產品。在近期舉辦的2018 ArchSummit全球架構師峯會上，個推首席數據架構師袁凱，基於他在數據平臺的建設以及數據產品研發的多年經驗，分享了《面向機器學習數據平臺的設計與搭建》。

 

1、背景：機器學習在個推業務中的應用場景

       做爲獨立的智能大數據服務商，個推主要業務包括開發者服務、精準營銷服務和各垂直領域的大數據服務。而機器學習技術在多項業務及產品中均有涉及：

一、個推可以提供基於精準用戶畫像的智能推送。其中用戶標籤主要是基於機器學習，經過訓練模型後對人羣作預測分類；

二、廣告人羣定向；

三、商圈景區人流量預測；

四、移動開發領域常常出現虛假設備，機器學習可以幫助開發者識別新增的用戶的真僞；

五、個性化內容推薦；

六、用戶流失以及留存週期的預測。

 

2、具體開展機器學習的過程

一、原始數據通過數據的ETL處理，入庫到數據倉裏。 

 

二、上面藍色部分表明機器學習：首先把樣本數據與咱們的自有數據進行匹配，而後洞察這份數據並生成特徵，這個過程叫特徵工程。接下來基於這些特徵，選擇合適的算法訓練後獲得模型，最終把模型具體應用到全量的數據中，輸出預測的結果。

 

標準的機器學習工做流：針對業務上產生的具體問題，咱們把它轉化成數據問題，或者評估它可否用數據來解決。將數據導入並過濾後，咱們須要將數據與業務問題和目標進行相關性分析，並根據具體狀況對數據作二次處理。

 

下一步咱們進行特徵工程。從數據裏找出跟目標有關的特徵變量，從而構建或衍生出一些特徵，同時要把無心義的特徵剔除掉。咱們大概須要花80%的時間在特徵工程這個環節。選出特徵以後，咱們會用邏輯迴歸和RNN等算法進行模型的訓練。接下來須要對模型作驗證，判斷其是否符合目標。不符合目標的緣由有多是數據和目標不相關，須要從新採集；也有多是咱們在探索的時候，工做不到位，於是須要對現有的數據從新探索，再進行特徵工程這些步驟。若是最終模型符合業務預期，咱們會把它應用在業務線上面。

• 機器學習項目落地的常見問題

雖然上面的流程很清晰，但在具體落地的過程當中也會遇到不少問題，這裏我就以前的實踐經驗談幾點。

一、如今大部分公司都已經進入大數據的時代，相比於以往的小數據級的階段，在機器學習或者數據挖掘等工做方面，對咱們的建模人員、算法專家的技能要求變高，工做難度也大大地提高了。

 

以往你們本身在單機上就能夠完成機器學習的數據預處理、數據分析以及最終機器學習的分析和上線。但在海量數據狀況下，可能須要接觸到Hadoop生態圈。

 

二、作監督學習時，常常須要匹配樣本。數據倉庫裏面的數據多是萬億級別，提取數據週期很是長，大把的時間要用於等待機器把這些數據抽取出來。

三、大多數狀況下，不少業務由一兩個算法工程師負責挖掘，於是常常會出現不一樣小組的建模工具不太統一或實現流程不規範的狀況。不統一會形成不少代碼重複率高，建模過程並無在團隊裏很好地沉澱下來。

 

四、不少機器學習算法工程師的背景存在專業的侷限性，他們可能在代碼工程化意識和經驗上相對會薄弱一些。常見的作法是：算法工程師會在實驗階段把特徵生成代碼和訓練代碼寫好，交給作工程開發的同窗，但這些代碼沒法在全量數據上運行起來。以後工程開發同窗會把代碼從新實現一遍，保證它的高可用和高效。但即使如此，也經常出現翻譯不到位的狀況，致使溝通成本高，上線應用週期長

 

5.機器學習領域的一大難題在於對數據的使用，它的成本很是高，由於咱們把大量時間用於探索數據了。

 

六、個推有多項業務在使用機器學習，但並不統一，會形成重複開發，缺乏平臺來沉澱和共享。這就致使已經衍生出來的一些比較好用的特徵，沒有獲得普遍的應用。

 

4、個推針對機器學習問題的解決方案

首先說一下咱們這個平臺的目標：

第一點，咱們但願內部的建模流程規範化。

第二點，咱們但願提供一個端到端的解決方案，覆蓋從模型的開發到上線應用整個流程。

第三點，咱們但願平臺的數據，特別是開發出的特徵數據能夠運營起來並在公司內不一樣團隊間共享使用。

第四點，這個平臺不是面向機器學習零基礎的開發人員，更多的是面向專家和半專家的算法工程師，讓他們提升建模的效率。同時這個平臺要支持多租戶，確保保障數據安全。

    

如下是咱們本身的總體方案，主要分紅兩大塊：

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

一、對應IDE。在這個平臺上進行數據探索、作數據的實驗，而且它能支持項目的管理和共享。

 

二、咱們但願把已經開發好的特徵數據管理起來，方便全部平臺用戶看到數據資產的狀況。

 

三、樣本匹配時候，樣本ID可能與內部ID不統一，這個時候須要作統一的ID匹配服務。

 

四、幫助算法工程師從萬億級數據裏快速地抽取所需數據，這也是很是重要的一點。   

 

五、作機器學習的過程當中，除了基本的算法，實際上還有不少代碼是重複或者類似的，咱們須要把這些經常使用代碼進行函數化封裝。

  

六、支持對模型服務進行打包部署。

 

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

 

八、在實際業務中應用模型，須要實時監控起來，跟進模型的可用性、準確性等。

 

上半部分是生產環境，運行着數據處理pipeline，同時與數據建模平臺對接着。

 

在生產環境中，模型對應的特徵數據分兩類：

 

一類是實時特徵數據，好比數據實時採集，生成一些實時的特徵，根據不一樣的業務需求存儲在不一樣的集羣裏。

 

另外一類是離線特徵數據，離線數據加工後存到Hive，供模型應用側進行使用。

 

在生產環境中，咱們能夠提供在線的預測API或 離線預測好的數據 供業務線使用。

 

5、方案實踐具體要點

 

第一點，咱們講講jupyter這塊：

 

選擇Jupyter做爲主要建模IDE而不是自研可視化拖拽建模工具，這樣的好處是能夠作交互式的分析，建模效率也很高，擴展方便，研發成本低。固然相似微軟Azure這樣的可視化拖拽建模平臺，能夠很是清晰地看到整個流程，適合入門級同窗快速上手。但咱們的目標用戶是專家和半專家羣體，因此咱們選擇了最合適的Jupyter。

 

使用Jupyter時候，爲了支持多租戶，咱們採用Jupyterhub。底層機器學習框架咱們用了Tensorflow、Pyspark、Sklearn等。數據處理探索時候，結合sparkmagic，能夠很是方便地將寫在Jupyter上的Spark代碼運行到Spark集羣上。

 

對於Jupyter沒有現成的版本管理控制和項目管理， 咱們結合git來解決。

 

另外爲了提升建模人員在Jupyter上的效率，咱們引入了比較多的插件，例如：把一些典型挖掘pipeline作成Jupyter模板，這樣須要再作一個相似業務的時候只須要基於模板再擴展開發，比較好地解決了不規範的問題，避免了不少重複代碼，也爲實驗代碼轉化爲生產代碼作好了基礎。

 

    

第二點，說下工具函數：

 

咱們內部提供了主要機器學習相關的函數庫和工具：

1）標準化的ID Mapping服務API。

2）建立數據抽取的API，不管是哪一種存儲，分析人員只要統一調這個API就可。3）可視化作了標準化的函數庫和工具類。

4）Jupyter2AzkabanFlow: 能夠把本來在Jupyter上寫好的代碼或者腳本自動轉化成AzkabanFlow，解決了特徵工程階段的代碼複用問題。

 

第三點，關於使用Tensorflow：

 

使用Tensorflow時，咱們的選型是TensorflowOnSpark，原生的Tensorflow的分佈式支持不夠好，須要去指定一些節點信息，使用難度較大。

 

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

 

同時利用yarn能夠支持GPU和CPU混部集羣，資源易複用。

 

   

第四點，關於模型交付應用：

 

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

     

最後分享下咱們的一些經驗：

 

第一，TensorflowOnSpark上的PS數量有限制，並且Worker和PS節點資源分配不是很靈活，都是等大。

第二，Jupyter在使用的時候，須要本身作一些改造，一些開源庫版本兼容性有問題。

第三，使用PMML有性能瓶頸，一些是java對象反覆重建，還有一些是格式轉化損耗，具體你們能夠抓取下jvm信息分析優化。

第四，在落地過程使用Spark、Hive的問題上，須要提供易於使用的診斷工具，建模人員並非Spark、Hive的專家，不必定熟悉如何診斷優化。

第五，要把模型和特徵庫當成一個資產來看待，對它的價值按期作評估，要管理好它的生命週期。

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

最後，須要平衡技術棧增長和維護代價，避免引入太多新工具新技術，致使運維困難。

 

以上就是我在機器學習方面的一些心得經驗，但願對你有幫助。也歡迎在留言區針對相關的問題與我交流！