本文內容是我學習ML時做的一個練手專案，描述應用機器學習的一般步驟。該專案的目標是從點選流資料中找出惡意使用者的請求。點選流資料長下圖這樣子，包括請求時間、IP、平臺等特徵：

該專案從開始做到階段性完成，大致可分為兩個階段：演算法選擇和工程優化。演算法選擇階段挑選合適的ML模型，嘗試了神經網路、高斯分佈、Isolation Forest等三個模型。由於點選流資料本身的特性，導致神經網路和高斯分佈並不適用於該場景，最終選擇了Isolation Forest。工程優化階段，最初使用單機訓練模型和預測結果，但隨著資料量的增加，最初的單機系統出現了效能瓶頸；然後開始優化效能，嘗試了分佈化訓練，最終通過單機非同步化達到了效能要求。

1 演算法選擇

1.1 神經網路

剛開始沒經驗，受TensorFlow熱潮影響，先嚐試了神經網路。選用的神經網路是MLP（Multilayer Perceptron，多層感知器），一種全連線的多層網路。MLP是有監督學習，需要帶標籤的樣本，這裡“帶標籤”的意思是樣本資料標註了哪些使用者請求是惡意的、哪些是正常的。但後臺並沒有現成帶標籤的惡意使用者樣本資料。後來通過安全側的一些資料“間接”給使用者請求打上了標籤，然後選擇IP、平臺、版本號、操作碼等資料作為MLP的輸入資料。結果當然是失敗，想了下原因有兩個：

1， 樣本的標籤質量非常差，用這些樣本訓練出來的模型效能當然也很差；

2， 輸入的特徵不足以刻畫惡意使用者。

資料的質量問題目前很難解決，所以只能棄用MLP。

1.2 高斯分佈

這個演算法的思想比較簡單：與大部分樣本不一致的樣本就是異常；通過概率密度量化“不一致”。具體做法是：選擇符合高斯分佈或能轉換為高斯分佈的特徵，利用收集到的資料對高斯分佈做引數估計，把概率密度函式值小於某個閾值的點判定為異常。

所謂的引數估計是指，給定分佈資料，求分佈的引數。對高斯分佈來說，就是求μ和σ。用極大似然估計可以得到高斯分佈引數的解析解：

得到高斯分佈引數後，用下式計算概率密度：

X表示一個特徵輸入。若有多個特徵x0、x1、…、xn，一種簡單的處理方法是將其結果連乘起來即可：f(x) = f(x0)f(x1)…f(xn)。

然後選定一個閾值ε，把f(x) < ε的樣本判定為異常。ε值需根據實際情況動態調整，預設可設定ε = f(μ- 3σ)。

把這個模型初步應用於點選流異常檢測時，效果還不錯，但在進一步實施過程中碰到一個棘手問題：樣本中最重要的一個特徵是操作碼，當前操作碼在微信後臺的取值範圍是[101, 1000]，每個操作碼的請求次數是模型的基礎輸入，對900個特徵計算概率密度再相乘，非常容易導致結果下溢位，以致無法計算出精度合適的概率密度值。這個現象被稱為維度災難（Dimension Disaster）。

解決維度災難的一個常見做法是降維，降維的手段有多種，這裡不展開討論了。在點選流分析的實踐中，降維的效果並不好，主要原因有兩個：

1， 正常使用者和惡意使用者的訪問模式並不固定，導致很難分解出有效的特徵矩陣或特徵向量；

2， 降維的本質是有失真壓縮，有失真壓縮必定導致資訊丟失。但在本例中每一維的資訊都是關鍵資訊，有失真壓縮會極大破壞樣本的有效性。

高斯分佈模型的維度災難在本例中較難解決，只能再嘗試其他模型了。

1.3 Isolation Forest

Isolation Forest，可翻譯為孤異森林，該演算法的基本思想是：隨機選擇樣本的一個特徵，再隨機選擇該特徵取值範圍中的一個值，對樣本集做拆分，迭代該過程，生成一顆Isolation Tree；樹上葉子節點離根節點越近，其異常值越高。迭代生成多顆Isolation Tree，生成Isolation Forest，預測時，融合多顆樹的結果形成最終預測結果。Isolation Forest的基礎結構有點類似經典的隨機森林（Random Forest）。演算法的細節見這裡：http://cs.nju.edu.cn/zhouzh/zhouzh.files/publication/icdm08b.pdf。

這個異常檢測模型有效利用了異常樣本“量少”和“與正常樣本表現不一樣”的兩個特點，不依賴概率密度因此不會導致高維輸入的下溢位問題。提取少量點選流樣本測試，它在900維輸入的情況下也表現良好，最終選擇它作為系統的模型。

2 工程優化

工程實現經歷了單機訓練、分散式訓練、單機非同步化訓練3個方案，下面內容介紹實現過程中碰到的問題和解決方法。

2.1 單機訓練

整個系統主要包括收集資料、訓練模型、預測異常、上報結果四個部分。

2.1.1 收集資料

剛開始嘗試該模型時，是通過手工方式從mmstreamstorage獲取樣本的：

1，通過logid 11357，得到手工登入成功使用者的uin和登入時間；

2，利用mmstreamstorage提供的介面，得到使用者登入後10分鐘的點選流；

但這樣做有兩個缺點：

1，上述步驟1是離線手工操作的，需要做成自動化；

2，mmstreamstorage的介面效能較差，只能提供2萬/min的查詢效能，上海IDC登入的峰值有9萬/min。

改進辦法是複用點選流上報模組mmstreamstorage，增加一個旁路資料的邏輯：

1，手工登入時在presence中記錄手工登入時間，mmstreamstorage基於該時間旁路一份資料給mmguardstore。由於mmstreamstorage每次只能提供單挑點選流資料，所以需要在mmguardstore中快取；

2，mmguardstore做完資料清洗和特徵提取，然後把樣本資料落地，最後利用crontab定期將該資料同步到Hadoop叢集中。

最終的資料收集模組結構圖如下所示：

點選流資料提供了IP、平臺、版本號、操作碼等特徵，經過多次試驗，選定使用者手工登入後一段時間內操作碼的訪問次數作為模型的輸入。

上面我們提到過點選流的操作碼有900個有效取值，所以一個顯然的處理方法是，在mmguardstore中把使用者的點選流資料轉化為一個900維的向量，key是cgi id，value是對應cgi的訪問次數。該向量刻畫了使用者的行為，可稱為行為特徵向量。

2.1.2 訓練模型

初起為了控制不確定性，只輸入1萬/分鐘的樣本給模型訓練和預測。系統的工作流程是先從Hadoop載入上一分鐘的樣本資料，然後用資料訓練Isolation Forest模型，最後用訓練好的模型做異常檢測，並將檢測結果同步到tdw。

在1萬/分鐘輸入下取得較好的檢測結果後，開始匯入全量資料，全量資料資料的峰值為20萬/分鐘左右。出現的第一個問題是，一分鐘內無法完成載入資料、訓練模型、預測結果，單載入資料就耗時10分鐘左右。這裡先解釋下為什麼有“一分鐘”的時間週期限制，主要原因有兩個：

1， 想盡快獲取檢測結果；

2， 由於點選流異常檢測場景的特殊性，模型效能有時效性，需要經常用最新資料訓練新的模型。

解決效能問題的第一步是要知道效能瓶頸在哪裡，抽樣發現主要是載入資料和訓練模型耗時較多，預測異常和上報結果的耗時並沒有隨資料量的增加而快速上漲。

載入資料的耗時主要消耗在網路通訊上：樣本檔案太大了，導致系統從Hadoop同步樣本資料時碰到網路頻寬瓶頸。但由於樣本是文字類資料，對資料先壓縮再傳輸可極大減少通訊量，這裡的耗時比較容易優化。

訓練模型的耗時增加源於輸入資料量的增加。下圖是1萬樣本/min的輸入下，系統個階段的耗時：

其中：
載入程式： 2s
載入資料： 6s
訓練模型：11s
分類異常： 2s
儲存結果： 4s
單輪總耗時：25s
需處理全量資料時，按線性關係換算，“訓練模型”耗時為：11s * 24 = 264s，約為4.4分鐘，單機下無法在1分鐘內完成計算。
最先想到的優化訓練模型耗時的辦法是分散式訓練。

2.2 分散式訓練

由於scikit-learn只提供單機版的Isolation Forest實現，所以只能自己實現它的分散式版本。瞭解了下目前最常用的分散式訓練方法是引數伺服器（Parameter Server，PS）模式，其想法比較簡單：訓練模型並行跑在多機上，訓練結果在PS合併。示意圖如下所示：

分散式訓練對演算法有一定要求，而Isolation Forest正好適用於分散式訓練。

然後嘗試在TensorFlow上實現Isolation Forest的分散式訓練版本。選擇TensorFlow的原因有主要兩個：

1， TensorFlow已經實現了一個分散式訓練框架；

2， TensorFlow的tf.contrib.learn包已經實現的Random Forest可作參考（Isolation Forest在結構上與Random Forest類似），只需對Isolation Forest定製一個Operation即可（Op的細節看這裡：https://www.tensorflow.org/how_tos/adding_an_op/）。

寫完程式碼測試時，發現了個巨坑的問題：TenforFlow內部的序列化操作非常頻繁、效能十分差。構造了110個測試樣本，scikit-learn耗時只有0.340秒，29萬次函式呼叫；而TensorFlow耗時達207.831秒，有2.48億次函式呼叫。

TensorFlow效能抽樣：

Scikit-learn效能抽樣：

從TensorFlow的效能抽樣資料可以看到，耗時排前排的函式都不是實現Isolation Forest演算法的函式，其原因應該與TensorFlow基於Graph、Session的實現方式有關。感覺這裡坑比較深，遂放棄填坑。

也瞭解了下基於Spark的spark-sklearn，該專案暫時還未支援Isolation Forest，也因為坑太深，一時半會搞不定而放棄了。

2.3 單機非同步化訓練

沒搞定分散式訓練，只能回到單機場景再想辦法。單機優化有兩個著力點：優化演算法實現和優化系統結構。

首先看了下scikit-learn中Isoaltion Forest的實現，底層專門用Cython優化了，再加上Joblib庫的多CPU並行，演算法實現上的優化空間已經很小了，只能從系統結構上想辦法。

系統結構上的優化有兩個利器：並行化和非同步化。之前的單機模型，載入資料、訓練模型、預測異常、上報結果在單程序中序列執行，由此想到的辦法是啟動4個工作程序分別處理相應的四個任務：非同步訓練模型、預測異常和上報結果，並行載入資料。工作程序之間用佇列通訊，佇列的一個優勢是容易實現流量控制。

寫完程式碼測試，卻發現YARD環境中的Python HDFS庫在多程序併發下直接拋異常。嘗試多個方法發現這個問題較難解決，暫時只能想辦法規避。經測試發現，直接從Hadoop同步所有壓縮過的樣本資料只需2秒左右，由此想到規避方法是：先單程序同步所有樣本資料，再多程序併發解壓、載入和預測。

按上述想法修改程式碼測試，效果較好，處理所有樣本只需20秒左右，達到了1分鐘處理完所有樣本的要求。然後提交YARD作業線上跑，處理所有樣本耗時卻達到200～400秒：

諮詢YARD側同學，得知YARD對提交的離線作業有CPU配額的硬限制，分時段配額如下表：

00:00~09:00 80%
09:00~19:00 50%
19:00~23:00 15%
23:00~24:00 50%

晚高峰時段的配額只有15%。

與YARD側同學溝通，他們答應後續會支援scikit-learn庫的線上服務。目前通過手工方式在一臺有scikit-learn的mmguardstore機器上執行線上服務，晚高峰時段處理全量資料耗時為20秒左右。

最終的系統結構圖如下圖所示：

模型訓練程序定期訓練最新的模型，並把模型通過佇列傳給預測程序。預測程序每分鐘執行一次，檢查模型佇列上是否有新模型可使用，然後載入資料、檢測異常，將檢測結果通過上報佇列傳給上報程序。上報程序block在上報佇列上，一旦發現有新資料，就根據資料型別執行上報監控、上報tdw等操作。

2.4 評估效能

安全側將異常使用者分為以下幾類：盜號、LBS/加好友、養號、欺詐、外掛/多開等。由於這些分類的異常打擊是由不同同學負責，不便於對Isolation Forest的分類結果做評估，因此需要在Isolation Forest的基礎上，再加一個分類器，標記“異常樣本”的小類。利用操作碼實現了該分類器。

接入全量資料後，每天準實時分析1億量級的樣本，檢測出500萬左右的異常，精確分類出15萬左右的惡意請求。惡意請求的uin、型別、發生時間通過tdw中轉給安全側。安全側通過線下人工分析和線上打擊，從結果看檢測效果較好。

2.5 持續優化

再回過頭觀察點選流資料，我們使用的Isolation Forest模型只利用了操作碼的統計資料。可以明顯看到，點選流是一個具備時間序列資訊的時序資料。而自然語言處理（Natural Language Processing，NLP）領域已經積累了非常多的處理時序資料的理論和實戰經驗，如LSTM、word2vec等模型。後續期望能引入NLP的相關工具挖掘出更多惡意使用者。