機器學習系統需要的資料格式

在線上系統中同時進行預測與學習

這種作法的資料格式需求，會非常近似於線上系統。無論是預測與學習，都可以視為是線上服務的一部分，所以一個基本門檻就是：處理單一事件時，反應時間要夠快。也因為後者的作法，需求貼近線上服務，所以資料格式的設計就很單純，程式碼在維護的成本也比較低。但是代價則是在多服務器時，讓機器學習系統同步的難度很高。

( 出處： http://f5loadbalancer.com/f5-load-balancer-wiki/ )

現代的線上系統，常常用多台機器來平行處理事件，讓系統能夠在很短的時間處理大量的事件。也因此，每一台機器會接收到的事件數量、事件內容會不太一樣。因此，如果採用「學習」與「預測」同時在線上處理的架構，就會發生每一台機器不一致的狀況。而機器學習系統除了處理單一事件時，反應時間要夠快這樣的需求之外，還有更重要的需求：預測精準（無論那一種架構的機器學習系統，都要符合這樣的需求，否則不如不要搭建機器學習系統）。而一個常識是：越多的學習資料，機器學習系統就越準。因此，直接以常見的方式平行擴充服務器，這種架構的機器學習系統的預測精準度會比較低，因為每一個模型所學習的資料只有1/n ( n 為服務器的個數 )。

這種架構的另一個問題，會在運用監督式學習時發生。監督式學習的學習資料中，需要有每一個事件的反饋資訊。舉例來說，預測點擊率的機器學習系統，學習時需要知道事件的結果（使用者有無點擊廣告）。但是這樣的結果，並不會和事件同時被觀察到，而是需要等待。如果等待的時間夠短，我們可以把事件放在Memory Buffer中，等若干分鐘後再做學習。如果等待的時間要很長，那就要花額外的工程能量來克服（建構對應的database… 等等）。

在線上做預測，線下作學習

這種作法的資料格式需求，則會比較複雜。前面我們提過，在線上系統的需求是：處理單一事件時，反應時間要快，而分析系統的需求是：處理全部事件時的整體時間要短。而分析系統的另一個挑戰是查詢指令的不確定性。

機器學習系統，在線上預測的需求，則也是類似：預測單一事件的時間要短以及預測精準。也因此，這部份的系統設計也是接近線上系統的設計。而機器學習系統在線下學習時，又分成兩種工作：模型的調校，與例行性的學習。模型的調校，比較接近一般分析系統的情境：我們很難事先知道會使用的資料欄位。而我們對每一次調校能容許的等待時間，比一般的分析系統下查詢的時間更長。也因此，前面介紹給分析系統使用的資料格式(Ex : 將資料以column-based的方式儲存於檔案系統)，其實也是滿足這樣的工作需求。而一般在工程資源有限時，我們會直接用相同的作法解決讓模型的調校與例行性的學習的需求。(在大公司，這兩種工作的確是會切開的)。

到這裡，讀者可能覺得故事很單純：那我們就在線上系統使用row based的資料格式(ex: protocol buffer或avro)做預測，線下系統使用column based的資料格式做學習就好了。但是機器學習系統，通常還需要做把資料轉換成線性代數中的向量後，才能做學習與預測。這個問題在遇到大量類別型變數時，特別嚴重，而廣告系統剛好就是其中一個例子。更成熟的機器學習系統，還會對事件做特徵抽取(feature extraction)或特徵工程(feature engineer)。前面提到，機器學習系統的基本需求是預測精準，而預測與學習的一致性是預測精準的基本需求之一。

ps. 預測與學習的一致性是指，事件在預測時，或是在學習時，轉換成線性代數的向量，要一致。

所以，如果我們在線上系統使用row based的資料格式，線下系統使用column based或是其他的資料格式，而且各自寫一個程式來將事件轉換成線性代數中的向量，那就會帶來極大的維護難題：要讓兩支輸入不同（雖然資訊相同，但是資料格式不同）的程式，輸出的結果一模一樣。在工程能量有限時，我們應該避免這樣的狀況。

因此，我認為採用這樣的架構時，在線下學習，仍然應該採用以row based儲存於檔案系統的方式，儲存與處理資料。儘量讓線下學習與線上預測使用相同的程式碼，是在工程能量有限時很重要的考量。

這樣做的代價，是在線下學習時的時間更長。但是因為我們對每一次調校能容許的等待時間，比一般的分析系統下查詢的時間更長，所以我在取捨之下，會更喜歡這種作法。