流式機器學習演算法的入門和認知

李博Garvin發表於2018-09-18

一.流式計算背景

1.概述

其實技術總在更新，做這個行業也是一直要走在學習並適應的路上，這也是人工智慧領域最吸引我的地方，其實基礎的理論是不變的，但是隨著業務的發展，計算能力的發展，上層的實現總是在迭代，今天講下我對於流計算的一些認知。
在這裡插入圖片描述

先聊下計算引擎的進化，隨手畫了上面的圖。其實第一代分散式計算引擎是Hadoop，這是一個跨時代的創造，人們使用Hadoop的MapReduce框架實現了許多的演算法，這些演算法也發揮了很大的作用。Hadoop最大的特點是，資料計算依賴於硬碟儲存，也就是說很多的計算過程中的結果都需要存在硬碟中，然後再從硬碟拉起，造成效能較低的問題。

Spark好在一點，把資料全部放到記憶體中進行計算，大大提高效率。但是無論是Spark或是Hadoop解決的都是批計算的問題，也稱batch計算。離線計算需要把資料收集起來統一的去算，對於演算法來講，可能收斂會更快，因為參與計算的資料比較多。但是也有暴露一個問題，實時性很差。這個問題就引出了下一代計算引擎-流計算這樣一個話題。

2. 流計算

弄明白流計算，首先要搞清楚概念。先來看下流計算（stream compute）以及批計算（batch compute）的計算模型：

流計算：當一條資料被處理完成後,序列化到快取中,然後立刻通過網路傳輸到下一個節點,由下一個節點繼續處理。
批處理系統：當一條資料被處理完成後,序列化到快取中,並不會立刻通過網路傳輸到下一個節點,當快取寫滿,就持久化到本地硬碟上,當所有資料都被處理完成後,才開始將處理後的資料通過網路傳輸到下一個節點。

對於流計算，是不是有一點感覺了。相較於batch compute，stream compute對於業務上一定是更靈活，因為可以跟資料更實時性的相關聯（資料的時間週期其實很重要，有機會我也會給大家分享我的看法）。

stream對於業務的優勢我舉一個例子，比如一個電商平臺，有一個推薦系統，推薦模型都是每週根據離線資料做批訓練生成的。但是突然有一天，這個電商搞了一個針對特殊人群的定向營銷活動，有大量的特殊使用者湧入，那針對這部分人群以前的老模型可能就不會起作用，這時候如果有一個實時訓練模型的能力就會對這種場景有更快速地響應，這個就有是online learning的概念，那底層依賴的是流計算引擎。

3. 真正的下一代流計算引擎

流計算引擎會是下一代的計算引擎，這裡指的不是流計算替代批計算，而是下一代流計算引擎會相容batch compute和stream compute，做到流批一體，Flink或許是一個答案。

當然流計算的挑戰會比做批計算大很多，比如failover機制，批計算所有計算結果都是有儲存的，可以回溯，流計算怎麼解決當機問題。比如exactly once機制，如何保證分散式流計算中的資料只被處理一次，而不是被多臺機器多次處理。

不過還是相信這些問題會被完美解決，未來的演算法也一定是會向流式方向遷移。

二.淺談FTRL演算法（流式邏輯迴歸演算法）

1.流失演算法概覽

先聊下對於流式演算法的一些看法，流式演算法就是要實時的去更新模型，所以從易實現的角度分析，不是所有的批計算演算法都適合做流式演算法，只有那些損失函式易於計算的演算法才比較適合做成流式。

常見的兩種損失函式的計算方法如下：
在這裡插入圖片描述

在這裡插入圖片描述

（注：這裡每個變數的具體含義我就不解釋了，如果看不懂的同學，真應該買本書好好補補基礎知識了）

流式演算法跟批演算法最大的不同就在於資料的計算量，批演算法和流演算法的計算模型如下：

批演算法：每次使用全量資料計算損失函式和梯度，然後更新模型
流演算法：每次使用1條資料計算損失函式和梯度，然後更新模型

從這個角度來看，因為每次參與訓練的資料量變小了，所以對於演算法從訓練資料稀疏度和資料維度這兩給角度來看，有更多的約束和挑戰。FTRL演算法是由Google提出，目前在online learning這個層面有非常好表現的演算法，可以理解為是流計算中的邏輯迴歸演算法，目前FTRL在廣告投放、商品推薦等實時計算場景被廣泛應用。下面就介紹下FTRL的具體計算流程。