開始你人生第一個機器學習項目時，避開這些坑。

來自專欄景略集智

本文是一篇機器學習過來人的經驗分享，主要談及了構建機器學習流程和 Apache Spark 中應該避免踩到哪些坑，希望文章能幫助即將開始機器學習項目的人少走一些彎路，省去一些麻煩。

在我們探索新事物的過程中，總會遇到未知的知識。在經過一番努力解決問題後，我們常感嘆如果當時能怎麼怎麼做該多好。在我（作者 Aseem Bansal——譯者注）和我的團隊們做完我們的第一個機器學習項目後同樣如此，我多想穿越回去告訴那時的自己別犯一些無謂的錯誤，當然時間無法倒流，我們犯過的錯誤只能為我們以後的工作提供借鑒，重要的是，幫助後來人避免犯同樣的錯誤。

今天我就對搭建機器學習工作流和 Apache Spark 分享一些建議。

很難預測

對於任何事情，我們其實很難做出準確的時間預測。對於我們需要做什麼去實現目標，心中或許會有一些想法，但這些想法在實現過程中總會出現錯誤，甚至被逐一推翻。我們必須接受這一點，最重要的是，要及時迅速地更正自己的想法。

在完成機器學習項目的道路上，總會出現很多未知問題，一定確保你和團隊能夠快速更新。

在開始項目前驗證數據是否整潔有序

在我們團隊開始創建第一個機器學習項目工作流之前，我們已經收集了 3 年的數據。但沒有對原始數據做任何處理，也沒做任何用途，只是將其存儲在雲端以防萬一。原始數據都以 CSV 文件保存，當時沒有注意到數據有什麼問題。而隨著時間推移，問題開始暴露，因為編寫這些文件的代碼久而久之不斷變化，因此一些被我們忽視的 bug 開始出現。所以在搭建機器學習工作流時，需要修復造成數據出現問題的代碼，最終在 Apache Spark 中編寫代碼清理歷史數據。如果進行到項目中間才發現問題，而不是一開始就將問題解決掉，顯然會大幅增加項目的難度。

在開始項目前確保數據沒有問題。

對數據進行一次預處理，然後用數據儘可能多的訓練模型

為了能訓練我們的機器學習模型，剛開始我們嘗試載入所有的數據，所用數據大小達到 TB 級。我們發現如果每次訓練都載入完所有的數據，訓練速度會非常慢，也讓模型迭代或優化的速度變得很慢。因此，我們意識到每次訓練時並不需要載入完全部數據。可以對數據集做一些預處理，創建一些較小的數據集。另外，也不要刪掉原始數據集，將其作為備份，以防後期出現錯誤。

不要將 ETL 和機器學習搞混，如果你在訓練 1000 個模型，不想預處理 1000 次，可以只進行一次預處理並保存，然後就能用於所有的模型訓練需求。

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

前面說了，我們將原始數據存放在了 AWS S3 上備份。剛開始並沒有重視數據是否易於訪問，但當我們展開機器學習工作時，發現為團隊各個成員提供便捷的訪問途徑至關重要。

只給予讀取許可權是不夠的，人們不會用個人筆記本下載 TB 級的數據，也不會在隨身攜帶筆記本處理 TB 級的數據，因為這隻會浪費時間。

我們發現使用 Apache Spark 支持的 notebook 環境可以達到這個目的，比如 Jupyter 和 Zeppelin。我們當時使用的是 Jupyter，效果不錯。讀者可根據自己的項目情況選擇合適的 notebook。

為團隊人員提供訪問 TB 級數據的途徑，還必須為他們提供合適的工具來理解數據，比如 Jupyter，Zeppelin 這樣的由 Spark 集群支持的 notebook。

對大數據而言，監控必不可少

在處理大數據時，傳統的軟體工程方法是沒有效果的。一般的項目可能花費幾分鐘，但大數據項目可能會耗費幾小時甚至幾天。和傳統編程相比，如何在大數據情況下縮短批量工作的完成時間更為複雜。使用雲計算可以水平地縮放機器要求以及縮短運行時間。但是我們應該增加機器的數量或改變機器類型嗎？我們是 CPU 受限、RAM 受限、網路受限還是硬碟受限？分散式環境中的瓶頸在哪裡？這都是我們在減少執行時間時需要回答的問題。

對於 Apache Spark 來說，很難弄清楚所需的機器類型。Amazon EMR 自帶的監控軟體能讓我們一眼就能監視集群內存或 CPU。但有時也需要查看底層的 EC2 實例檢測，因為監控軟體並不是很完美。這兩種結合起來會更好。

另外，和訓練機器學習模型的作業相比，ETL 作業具有不同的執行配置文件。ETL 佔用大量的網路和內存，機器學習需要更多的計算，應該為這兩種類型的作業選擇不同的實例類型。

需要從 CPU/內存/網路/IO 監控方面優化成本，另外注意一點，不同的作業（ETL、機器學習）有不同的機器要求。

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

你對於你的機器學習模型的預測有延遲需求嗎？如果有，在確定框架前，記得確認用該框架訓練的模型是否能滿足你的延遲需求。理解模型背後涉及的數學理論知識相對比較容易，因此你可能會以為模型會很快預測出結果，但事實證明還會有其它因素可能導致預測速度不如理論上預測的那麼快。因此，可以搭建一個模型，並進行基準測試。如果創建好機器學習流水線後再發現問題，會浪費你大量時間。如果發現 Spark 無法滿足延遲要求時，可以使用 mleap 庫優化預測延遲。

如果你有延遲需求，可以用你想使用的框架搭建一個簡單的模型。精度、準確率或其它指標都無關緊要，只需要以預測延遲對模型進行基準測試。

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

使用 AWS 的 GUI 或 CLI 很容易讓人忘記 S3 不是一個文件系統。S3 是一個對象存儲庫，存儲的值為對象，可以是 json，圖像等等。

這點區別非常重要，因為在 S3 內重命名東西不像在真正的文件系統中那麼快。如果在一個文件系統中移動一個對象，可能移動的速度會很快，但這在 S3 中是無法實現的。

為什麼說這點很重要？因為當我們通過 Apache Spark 向 S3 寫入數據時，Apache Spark 會產生臨時文件，然後將其移動到新的秘鑰中。由於以上原因，如果你是在使用文件系統，前面這麼做沒有問題，但如果是用 S3 就不行了。在 Apache Spark 中有一個設置，可以令它不寫臨時文件，而是最終輸出。使用這種設置，可以讓你在寫入 S3 時節省大量時間。

Apache Spark 基於 Scala

如果你想使用 Apache Spark，你應該知道它主要基於 Scale。Java 和 Python API 也能用，但是網上的使用案例多是基於 Scala的。我們在剛開始機器學習項目時，就沒有重視這個問題，以為掌握 Scala 知識不那麼重要。結果後麵糰隊很難處理 Scala 曲線。將 Scala 翻譯成 Java 不是很難，但是將 Spark Scala 翻譯成 Spark Java 會非常難，因為這些 API 很難使用Java。

如果你不是很懂 Scala，還想使用 Spark Millb，那麼你可能需要考慮一下在選擇編程語言方面做些妥協。雖然不是一個理想的解決方法，但卻很很實用。記住，軟體工程是在不斷迭代中進行的。先讓軟體跑起來，然後再想法讓軟體變得更好。

如果是團隊協作，知識共享很重要

如果你是迭代現有的機器學習系統，那麼就需要和其它開發者打交道。而且，還需要和業務、運營和市場人員交流溝通，但他們對機器學習通常並沒有那麼深的理解，除非你們的產品就是個很直接的 AI 產品。如果機器學習只是你們整體業務解決方案的一部分，而非整個內容，那麼業務、市場等這些崗位的成員需要了解機器學習，卻又不可能坐下來學習機器學習這方面的課程。那麼這時候，可以做一些機器學習方面的知識分享。不必教他們很深奧的演算法，解釋一些他們常用但又不理解的術語即可，比如訓練集、驗證集、測試集等等。

對於技術人員來說，這些數據很常見，可能爛熟於心，但對於團隊中的非技術人員來說，理解這些技術術語就很困難了。為了避免不必要的團隊摩擦，提高團隊協作效率，有必要向團隊成員普及日常工作中所需的機器學習基礎知識。

控制數據版本可能是個好主意

你可能希望能夠為數據創建一個版本控制計劃，從而能轉換不同的模型訓練代碼，在無需重新部署整個軟體系統的情況下使用不同的數據集。我們搭建了一些模型，並用一些數據試了試它們，發現數據不充足。模型可以運行，但還不夠好。

因此我們為數據創建了一個版本控制計劃，這樣就可以在 V1 版本上訓練模型，並不斷迭代。待新版本獲取足夠數據後，我們就能切換模型訓練代碼，使用新數據。

另外，還可以製作一個 UI界面，以便控制機器學習的參數、指定用於訓練的數據量等。基本上可以通過UI我們可以輕鬆地配置一些參數，從而確保更改用於訓練的數據時不需要重新部署相關參數。

（End）

可能你還感興趣：