希望我在開始第一個機器學習項目之前就了解的那些事兒

當我們學習任何一個新的內容或遇到新的事情時，隨著時間的推移，可能回過頭來會發現，當時要是怎樣結果又會怎樣。身邊很多人包括我自己在讀完大學後，發現如果高中再努力一些或重新把大學時間利用好，人生的路途是不是能更順利些……曾經聽一位老師說過「青春就像這樣，不管你怎樣過都會過得一團糟」。事實上，大多數學生沒有利用好時間是由於沒有明確的方向。同理，對於新入職的員工而言，有一個師父在平時的工作中以他過來人的經驗引導一下，新員工的發展也會更順利些。那麼對於學習機器學習而言，這裡有一份過來人的經驗分享清單，希望這個清單能夠幫助那些正在學習機器學習的相關人員少走一些彎路，節約一些時間。

這份清單主要是包含一些關於構建機器學習工作流以及Apache Spark相關的具體內容。

預測是困難的

對於任何未知的事情，很難對其做出一個準確的時間預測，但我們會朝著目標前進。然而隨著時間的推移，在努力的過程中逐漸會出現錯誤，這是由於我們無法預測採用哪種方法就能夠得出好的結果，能夠做的只有確保項目組可以快速地迭代更新。

項目有很大的未知數，請確保團隊能夠進行快速迭代更新

在開始之前驗證數據是否完整

當開始使用機器學習管道時，我們已經收集了大約3年時間的原始數據。但沒有對原始數據做任何處理，只是將其存儲以防萬一。原始數據採用CSV文件形式，此時沒有注意到這些數據存在問題，另外編寫這些文件的代碼會隨著時間的推移而導致一些錯誤。因此在構建機器學習管道的同時，還需要修復造成錯誤的數據問題，最終在Apache Spark中編寫相關的代碼來清理歷史數據。在進行到中間時刻才發現問題，而不是在最初，這無疑增加了項目的難度。

在開展工作之前，請確保數據正確

對數據進行一次預處理，對構建模型進行一百萬次訓練

在最初訓練機器學習模型時，我們嘗試載入所有的數據。而採用的數據大小是TB級別，如果每次訓練都載入所有數據會導致訓練速度很慢。因此，每次訓練時不需要載入所有的數據，可以對其做一些預處理，創建一個新的小數據集。此外，並沒有刪掉原始數據集，將其作為備份以防後續過程中出現新的錯誤。

不要將ETL和模型訓練混淆。如果你正在訓練1000個模型且不想執行1000次預處理，可以只做一次預處理並保存，然後將其用於所有的模型訓練需求。

為不同的團隊成員提供輕易的訪問途徑

在上文說過，我們將原始數據存儲在AWS S3中備份。當開始使用機器學習開展工作時，發現為每個人提供輕鬆地訪問途徑顯得至關重要。只給予讀取許可權是不夠的，科研人員不會通過筆記本下載TB級的數據，且不會隨身攜帶筆記本電腦來處理TB級的數據，這隻會浪費每個人的時間。我們發現使用支持像Apache Spark這樣環境的Notebook可以達到這個目的，比如Jupyter、zeepelin等，讀者可以根據自己的平台選擇合適的Notebook。

為小組人員提供訪問TB級數據的途徑，此外必須提供合適的工具使其能夠從中很好的理解這些數據，比如Jupyter、zeppelin等這些基於spark集群的Notebook。

對於大數據而言，監控是必須的

當處理大數據時，傳統的軟體工程方法是不起作用的。一般的程序可能花費幾分鐘就可以運行完畢，但大數據可能需要幾小時到幾天的時間。與傳統軟體編程相比，如何在大數據情況下減少批量處理作業的完成時間這一問題更為複雜。使用雲計算可以水平降低機器要求以及縮短運行時間。但是，我們應該增加機器的數量還是完全改變機器的類型？分散式環境中的瓶頸在哪裡？等等這些問題都是減少執行時間時需要解決的問題。

對於Apache Spark而言，很難弄清楚需要的機器類型。Amazon EMR帶有Ganglia，這讓我們一眼就可以監視集群內存/CPU。但有時候也不得不去檢查底層的EC2實例監測，因為Ganglia並不完美，將二者結合起來使用是很不錯的方法。此外，與訓練機器學習模型的作業相比，ETL作業具有不同的執行配置文件。ETL佔用了大量的網路和內存，機器學習需要更多的計算，可以為這兩種類型的作業選擇不同的實例類型。

需要從CPU/內存/網路/IO監控方面優化成本，此外發現不同的工作（ETL、機器學習）有不同的機器要求。

在一開始就需要對機器學習預測進行基準測試

對機器學習模型的預測有沒有延遲要求？如果有的話，在選擇任何具體框架之前，請確定該框架的訓練模型是否可以滿足你的延遲要求。對於基礎模型而言，很容易就能掌握其中包含的數學基本理論，並理所當然的認為它會運行得很快。但事實證明，還有一些其它因素可能會導致預測的速度不如理論上預期的那樣快。建立一個簡單的模型並進行基準測試。如果在建立管道後才發現問題，這可能會浪費大量的時間。當發現Spark不能滿足延遲要求時，可以使用mleap庫提升預測延遲。

如果有延遲需求，請從要使用的框架中製作出一個簡單模型，精度、準確率或其它指標都無關緊要，只需要以預測延遲為基準點。

無論AWS如何顯示，S3都不是一個文件系統

使用AWS的GUI或CLI很容易忘記S3不是一個文件系統，S3是一個對象存儲庫，存儲的對象是json、圖片等內容。這個區別很重要，因為在S3中重命名內容並不像在真正的文件系統中那樣快。如果在一個文件系統中移動一個對象，它可能會很快地移動，但這在S3中是無法實現的。為什麼這個顯得很重要呢？因為當通過Apache將數據寫入S3時，Apache Spark會產生臨時文件，然後將其移動到新的秘鑰中。基於以上原因，Apache Spark有一個設置，可以告訴它不寫入臨時文件，而是寫入最終輸出。我們使用了這種設置，在寫入AWS s3上節約了大量的時間。

Apache Spark主要是基於Scala

如果使用的是Apache Spark，你應該知道它主要是基於Scala的。Java和Python等應用介面也可以工作，但是網上的例子大多是基於Scala的。而我們使用的是Java，這是由於之前的技術棧使用的是Java。在剛開始時，對於機器學習和Scala等方面都沒有任何專業知識，我們簡單地認為機器學習對於項目而言至關重要，而Scala不是。因此，無法讓團隊像處理機器學習問題那樣處理Scala曲線。將Scala翻譯成Java並不難，但將Spark Scala翻譯為Spark Java很困難，因為這些應用介面在Java中難以使用。

如果你不了解Scala並且還想使用 Spark Mllib，那麼可能需要在選擇語言方面考慮妥協。這種解決方案不是理想的工程解決方案，而是一個實用的解決方案。

知識分享對於團隊合作而言很重要

如果將機器學習與現有系統集成在一起，那麼將不得不與其他開發人員打交道。此外，還需要與業務、操作、營銷等人員進行交流。但是這些人員中的大多數人不會對機器學習有很好的理解，因此他們需要這方面的知識，但是他們又不能坐下來學習機器學習相關課程。這個時候就應該做一些機器學習方面的知識分享，只需要解釋一些涉及外行常見的術語即可，比如訓練集/測試集/驗證集、模型等，而不必教他們相關演算法等深奧的內容。

對於專業人員來說，很容易忘記機器學習中充滿了術語，雖然你可能完全熟悉這些術語，但對於團隊中的其他人而言，這些可能會是完全陌生的詞語，因為不是所有人都參加過機器學習課程。

對資料庫構建版本控制可能是一個好的想法

可能需要對資料庫構建版本控制方案，並且可以在不重新部署整個軟體的情況下切換不同的模型訓練代碼以使用不同的數據集。我們創建了一些模型，並用一些數據對其進行了嘗試，結果發現數據量不夠，模型工作得不夠好。因此，為資料庫建立版本控制方案，以便可以在V1版本上訓練模型並繼續生成下一個版本。新版本中足夠的數據後，就可以切換模型訓練代碼以使用新數據集。此外，還製作了一個UI界面，以便控制機器學習的參數、指定用於訓練的數據量等。基本上可以通過UI可以輕鬆地配置一些參數，以確保對用於訓練的數據進行更改時不需要重新部署相關參數。

喜歡這篇文章嗎？立刻分享出去讓更多人知道吧！