想必每個人都有這樣的經歷：當你在學習新事物時，萬事開頭難，你總會遇到許多未知的因素，并花大量時間去學習、適應新的領域。而隨著時間的推移，你在這個領域越來越熟練，也積累了一大堆技巧，想送給當初那個四處碰壁的自己。近日，medium博主Aseem Bansal撰文講述了自己在構建機器學習管道和使用Apache Spark時的一些經驗，希望能幫助入門者節約時間。

謹慎制定預期

和其他任務量巨大、未知的事物一樣，我們很難對機器學習項目進展作出時間預估。我們知道自己需要做哪些事來達成目標，但隨著工作進行，一些想法會逐漸暴露出缺陷。這時，我們必須接受這個現實，并馬上靈活更換方法保證工作計劃快速迭代。

項目中會有大量未知數，你需要確保團隊能夠快速迭代。

在開始前檢驗數據是否整齊

在我們第一次構建機器學習管道時，團隊已經花了大約3年的時間收集原始數據。為了防止中途因為某些意外需要重建數據的分析存儲，我們沒有對數據做任何調整，只是以.csv的格式把它們放在那里。一開始我們并沒有發現這有什么不妥，但隨著時間的推移，編寫這些文件的代碼發生了變化，也出現了不少錯誤。所以我們不得不一邊構建管道，一遍修修補補。直到最后，我們還是在Apache Spark中寫代碼，清除了所有歷史數據。如果我們事先檢查了數據整齊與否，不是直到項目進行才發現問題，也許這個過程就不會那么復雜。

在項目開始前，請確保自己的數據是正確的。

對數據進行預處理，對模型進行預訓練

為了訓練我們的機器學習模型，我們一開始試著加載了所有數據。由于文件大小是TB級的，每次加載完，模型的訓練速度就會變得非常慢，這也影響了它的迭代。后來，我們逐漸意識到似乎不用每次都加載所有數據，于是就對數據做了一些預處理并創建了一個更小的數據集，它允許模型調用我們需要的列來進行訓練。同時，我們也沒有刪除原來的數據源，而是把它作為檢測的備份資源。

不要混淆ETL和模型訓練。如果你需要訓練1000個模型，你并不需要做1000次預處理。你只要做一次，然后把數據保存到一個地方，然后把它用來訓練模型。

選擇權限共享的工具

如前所述，我們把原始數據放在AWS S3中備份，這看起來好像沒什么問題，但從數據科學角度來看，這并沒有做到真正的共享，因為當需要從S3中提取數據時，只有少數人有訪問權。

給一個只讀權是遠遠不夠的。人們能不能在筆記本電腦上下載TB級別的數據？強行來說，這是可以的，但在下完數據后筆記本電腦能用它們干什么？不是每個人都會隨身攜帶32核電腦的。要他們未雨綢繆，隨時為處理TB級的數據做好準備，這簡直是浪費時間。

這時候，我們發現一些支持Apache Spark環境的notebook可以滿足基礎需求，比如jupyter和zeppelin。如果是一些長期的集群的任務，jupyter的優勢更大一些，但由于AWS EMR內置集成，zeppelin可以憑借Amazon EMR群集進行機器學習、流處理和圖形分析，所以對于一般用戶，zeppelin更甚一籌。

只給人們開放TB級數據的只讀權限，并期望他們能做出點什么的想法是荒誕的。你必須先提供正確的工具，別人才能更上一層樓。 對于這個問題，jupyter、zeppelin等筆記本都是我們的明智之選。

大數據必須進行監控

當你處理大數據時，你會發現傳統的軟件工程方法有時不頂用。普通程序跑一跑也許只要幾分鐘，但大數據可能要幾小時甚至是幾天，具體取決于你在做什么以及你是怎么做的。幸運的是，現在不是十年前，我們不再需要等任務全部結束再來思考怎么提高效率。

和傳統的軟件編程相比，如何減少大數據背景下的批量作業是一個更復雜的問題。通過云，現在我們可以等量減少使用機器的數量，或是縮短訓練的總時長，但是面對這些選擇，哪一個才是真正的首選？我們可以增加機器數量，可以改變使用的機型，可以采用CPU bound、RAM bound，也可以是network bound、disk bound……在這個分布式環境里，我們的瓶頸在哪里？這些都是我們必須要回答的問題，它們影響項目用時的長短。

對Apache Spark來說，它很難弄清楚需要的機器類型。Amazon EMR帶有神經節，讓我們一眼就可以監控集群內存/ CPU。但有時我們也不得不去檢查底層的EC2實例監測，因為神經節并不完美。只有結合兩者，我們才能對比著發現問題。我們發現，執行ETL和訓練機器學習模型的任務有不同的配置文件。ETL需要占用大量的網絡和內存，而機器學習訓練對算力要求更高，所以我們為兩者選擇了不同類型的方案。

可以通過監控CPU /內存/網絡/ IO監控來優化成本。我們找到了EHL和ML對硬件的不同需求。

一開始就對機器學習模型預測實行基準測試

想一想，你對機器學習模型的預測響應時間有沒有特殊要求。如果有要求，那你在選擇框架前應該先確定該框架能滿足你的預期。要知道，基礎模型的數學理論是很容易把握的，但如果你向當然地認為模型能按著數學方程迅速給你一個預測結果，那你就錯了。

有時候影響預測速度的除了數學模型，還有其他一些奇奇怪怪的因素。而這些坑都需要你先做基準測試進行排查。如果你是在構建完機器學習管道后再做基準測試，你可能會浪費大量時間。

如果你對響應時間有要求，請先利用選擇的框架制作一個簡單模型，它可以在精度等方面表現不佳，但你可以基于它測試延遲情況。

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

當你在使用AWS的GUI或CLI時，你很容易忘記S3不是個文件系統，它只是一個對象存儲。如果你不知道什么是對象存儲，可以聯系Key-value存儲類比一下，把里面的value替換成對象，而這個對象可以是json和圖像等。

區分這一點很重要，因為在S3中重命名內容并不像在文件系統中那么快。如果你在文件系統中移動了一個對象，它可能很快就好了，這主要取決于你正在調用的內容。但如果是在S3里，你最好不要抱有同樣的幻想。

用map、reduce處理數據時，傳統的hadoop會產生臨時文件，而Apache Spark在把數據寫入S3時，會先寫入一個臨時文件，再把它們移至對象存儲，簡而言之，就是速度很慢。所以你可以選擇存本地，也可以用Apache Spark把臨時數據塞內存處理完后直接輸出最終結果。

Apache Spark主要是基于Scala的

如果你要用Apache Spark，首先你該知道它主要是基于Scala的。雖然它支持Java和Python API，但它的大多數示例還是圍繞scala展開的。

在還沒接觸過機器學習和scala前，我們用的一直是Java，并且覺得機器學習對我們的項目可能有很大的用處，但是學習scala是不必要的。事實上，我們中也沒人想處理scala的學習曲線。這樣的考慮主要是為了防止項目出錯。但有一次，我們遇到了一個Apache Spark問題，找到解決方案不麻煩，把scala翻譯成Java也不麻煩，麻煩的是我們得把Spark Scala翻譯成Spark Java，因為Java的API不太好用。

如果你完全不懂scala但又想用Spark Mllib，你可能得向scala妥協。這不是理想的解決方案，但卻是實際的解決方案。讓它運作，然后把它變得更好。相比找到一種不變的、看似完美的解決方案，學會新的東西并讓它發揮作用才更令人開心。

如果這是團隊作業，分享知識就十分重要

如果你要把機器學習和現有的其他系統集成在一起，你就不得不需要和其他開發人員打交道。你要聯系的對象除了開發者，還有業務人員、操作人員、市場營銷人員等。除非你正在從事人工智能方向的產品研發，否則這些人中的大部分不會對AI有太多太深的了解。而因為機器學習是整個解決方案中的一部分，他們也沒有時間去進行系統學習，所以知識分享就變得尤為重要了。

你不必教給他們算法和其他專業的東西，但你確實需要向他們解釋一些常用的術語，如訓練、測試、模型、算法等。

機器學習領域充滿大量術語，你可能會忽略這個現實，但對于團隊中的其他人來說，這些陌生的詞匯會讓他們感到困惑。并不是每個人都上過ML課程。

為數據構建版本是個好主意

你可能需要為您的數據構建不同版本的控制方案，讓它能在不重新部署整個軟件的情況下，切換不同的數據集供模型進行訓練。我們之前創建過一個模型，把它放在數據集上訓練后，可能是數據不夠，它的性能不盡如人意。

為此，我們為數據構建了幾個版本的控制方案，當在v1上訓練模型時，它會自動生成下一版數據。當有足夠數據后，我們就能直接靠切換代碼來進行訓練。我們還制作了一個UI，能利用它控制機器學習算法的參數，并對某些特定參數進行基本過濾，指定我們想要用于訓練的數據量。