1.2 案例分析

1.2.1 SK電信駕駛安全性評分

SK電信是韓國的移動通信運營商，T map是其手機導航App，類似于我國的百度地圖和高德地圖。這款App可對用戶的駕駛安全性（超速、加速、減速）評分，汽車保險公司根據這個評分計算保費。T map的Driving score功能，如圖1-8所示。

1.批處理架構

在行駛過程中，車輛的GPS位置（經度、緯度、海拔）信息由App實時上傳至后臺服務端。其中，GPS一分鐘定位一次，App將五分鐘內的位置信息打成一個數據包上傳。

最初，系統采用批處理架構，GPS位置信息被定期抽取到Hive數據倉庫中，計算Driving score的ETL（Extract Transform Load）批處理程序由Oozie調度執行，頻率為每天兩次，評分結果在第二天返回用戶。從傳統金融領域到電信領域，從零售領域到物聯網領域，這種數據處理系統已經成為標配架構。但是這種 T+1處理架構的缺陷也很明顯，即用戶體驗較差、決策反應速度較慢。Driving score批處理系統的架構如圖1-9所示。

因此，SK電信將上述批處理架構重構為基于消息的流式數據處理架構，提供實時Driving score服務。

2.流式數據處理架構

筆者以12分鐘一趟的駕駛為例，分析流式數據處理架構設計面臨的問題及其解決方案。

App端將每5分鐘內的300個GPS位置信息以JSON格式打包發給后臺服務端，按照定位時間先后順序，以a、b、c、d命名這4個數據包，系統在接收數據包d后立即返回Driving score。在計算機術語里，這12分鐘一趟的駕駛稱為session （一次會話）。針對這種應用場景做如下分析。

（1）亂序是常見情況：數據包 d不僅包含 GPS位置信息，還包含 session結束標志信息。即使系統能保證數據包在App端的上傳順序，也不能保證數據包到達處理節點的順序，因為后臺服務系統的分布式特性可能會導致數據包亂序，如計算Driving score的處理程序可能先收到數據包d，隔一段時間才收到數據包c。（2）窗口機制：在很多應用系統中，開始與結束標志信息并不存在，數據處理程序需要根據應用系統的領域知識推定。因此，什么時間點計算 Driving score是流式數據處理架構設計的關鍵點，這個關鍵點在流式數據處理架構理論中被稱為窗口機制。

（3）松耦合：在企業級IT架構中，數據處理系統和業務邏輯系統通常是分開的，數據部門負責數據處理系統的開發與維護，軟件開發部門負責業務邏輯系統架構的設計與程序開發。但是，由于數據處理系統的數據來自業務邏輯系統，這兩個系統不可避免地會存在一定的耦合。并且，如果數據處理系統涉及底層軟件模塊，數據部門就需要將相關開發工作委托給軟件開發部門，但復雜的數據需求實現流程、不同的技術棧帶來的需求理解偏差等因素，將導致數據從軟件開發部門到數據部門的周期過長，這是另一種耦合，因此流式數據處理架構需要松耦合設計。

基于以上分析，流式數據處理系統的前端部署分布式消息系統 Kafka，直接串接在 GPS 位置信息的傳輸通道上，Source 節點從 Kafka 訂閱 GPS位置信息，并將JSON格式解析后的信息推送到時間窗口節點（Time&Window）處理，Sink節點將處理的結果信息寫入Kafka，Kafka負責持久化或對接到下游系統。Driving score流式架構的邏輯模式如圖1-10所示。

在圖1-10中，每個處理節點只有一個實例，這是流式數據處理系統的邏輯模式。流式數據處理系統是分布式計算系統，因此在實際執行過程中每個相同功能的節點都會有多個并行實例對應于物理部署模式，如圖1-11所示。

在物理部署模式中，每個Source節點實例會和所有時間窗口節點實例相連，這樣同一個 session 的 GPS 位置信息可以被同一個時間窗口節點實例處理。數據處理“一直”在運行，而不是定時運行的（批處理采用定時觸發運行機制），從而規避了T+1處理架構的缺陷。

在物理部署模式中，我們還觀察到4個數據包的順序為a、b、d、c，而不是按事件發生的順序a、b、c、d。下面介紹解決上述數據包亂序問題的三種窗口機制。

1.設定固定時間間隔的session窗口

在時間軸上，兩趟駕駛不會出現重疊，即兩個活動session之間會有一定的時間間隔，可以通過數據分析的方法計算這個間隔的合理值（不一定是最小值，可參考1.4節和1.5節的內容），例如1小時。如果時間窗口節點實例在接收d之后的1小時內沒有再觀察到新的GPS位置信息數據包，則系統可以在這個時間點上返回Driving score。這種窗口機制很簡單，但是仍需要等待1小時才能得到結果。

2.設定session的事件推進標志

流式數據處理架構使用水印來推進事件時間，即Source節點或業務邏輯系統在 GPS 位置信息流中定期插入時間推進控制信息，用于表明某個時間點之前的GPS 位置信息數據包均已接收完畢，這樣時間窗口節點能夠實時計算 Driving score。從這層意義上看，水印是流式數據處理系統中事件流轉的同步信號。雖然這種窗口機制的用戶體驗好，但是需要深刻理解應用領域知識，生成水印的代價較高，特別是，當企業級業務系統有多個關聯子系統時，設計水印異常復雜。

3.觸發器實時生成近似結果

對數據部門而言，深刻理解應用領域知識，特別是深刻理解應用系統架構知識的代價較高。為此，流式數據處理系統提供觸發器機制以實時生成近似結果，即數據處理系統行先計算出正常的session結束時間點，并在這個時間點上實時計算出Driving score，如果之后觀察到屬于這個session的遲到的GPS位置信息數據包，那么時間窗口節點會撤回之前的結果并生成新的 Driving score。這種窗口機制廣泛應用在一些對實時性要求比較高的數據處理場景中。

1.2.2 流式機器學習應用

1.線下訓練模型、線上實時抽取特征

在機器學習中，求得一個與訓練數據集相吻合的函數的過程被稱為數據擬合，也被稱為曲線擬合。下面是用Python語言編寫的多項式擬合程序：

這種機器學習算法根據訓練數據集（train_x，train_y）的八次多項式特征（Feature）訓練線性回歸模型（Model）。在模型應用于線上預測時，流式處理系統從實時數據（x）中抽取特征（quadratic_featurizer.transform（x）），模型根據抽取的特征輸出預測值（y）。

這種以 Feature 和 Model 為核心組件，線下訓練模型、線上實時抽取特征的機器學習方法在傳統金融安全等領域有著廣泛的應用。其中，反欺詐是金融機構IT 團隊面臨的主要挑戰之一。欺詐的形式從 App 簽名漏洞、ATM 盜刷分離器、網絡仿冒到惡意商業間諜 APT（Advanced Persistent Threat，如“銀行大盜”Carbanak木馬可命令受感染的ATM直接吐錢），欺詐的規模從個體犯罪逐步演變成有組織的犯罪。為了應對不斷升級的欺詐手段，金融機構的應對措施也從最開始的手動檢測、規則檢測，發展到基于監督學習的模型檢測、基于非監督學習的異常檢測。

考慮到安全形勢的嚴峻性、金融業務的復雜性及分支機構的跨地域性，反欺詐系統可以采用線下訓練模型、線上實時抽取特征的機器學習方法。為了便于共享與分發，通常采用PMML的方式定義線上機器學習模型的需求，如圖1-12所示。PMML（Predictive Model Markup Language，預測模型標記語言）利用XML描述和存儲數據挖掘模型，是一種在不同應用程序之間快速共享模型的可選方案，已經被W3C所接受。PMML中定義了數據挖掘不同階段的相關信息：頭信息（Header）、數據字典（Data Dictionary）、挖掘模式（Mining Schema）、數據轉換（Transformation）、模型定義（Model Definition）和評分結果（Score Result）。

2.實時機器學習

隨著電子商務的高速發展，互聯網電商平臺的數據呈爆炸式增長，其存量數據可達EB（Exabyte，艾字節，1EB=1024PB）級，每天增量數據可達PB（Petabyte，1PB=1024TB）級，這會帶來巨大的模型訓練計算量。

反向傳播算法（詳細分析參見第 4章）是深度學習模型訓練的通用算法，如果進行全量樣本訓練，則每次訓練需要計算所有樣本的損失和，再進行梯度運算，計算開銷太大，很難進行在線學習；如果進行單樣本訓練，那么每次訓練只計算每個樣本的損失與梯度，但是整個模型訓練的收斂速度和泛化效果都不理想。

我們先將樣本數據分成多個微批（microBatch）數據集，然后在每個微批數據集上進行梯度運算。下面的代碼片段是使用TensorFlow實現Word2Vec的例子：

此外，電商數據的特征并不平穩，如“雙11”時商品的價格、活動的規則與平時完全不同，通過歷史樣本數據訓練出的模型往往不能擬合出讓人滿意的結果，圖1-13概括了這種非實時機器學習方式的特征。

實時機器學習是電商應用的合理選擇：線上實時特征抽取，采用微批方式實時訓練模型。圖1-14展示了阿里巴巴實時機器學習模型的架構。

圖1-14中的上半部分為實時抽取數據特征的過程，下半部分為實時訓練的過程，這樣整個系統可以根據實時特征更新模型參數，并將更新后的模型部署到線上。