720
顛覆大數據分析之實時分析的應用
在這一節，我們將看到構建兩個應用的步驟：一個工業日誌分類係統和一個互聯網流量過濾應用。
工業日誌分類
隨新舊生產工程係統的自動化以及電子工程的發展，大量的機器之間（M2M）的數據正在被生成出來。機器之間的數據可以來自多個不同的源頭，包
括無線傳感器，電子消費設備，安全應用，還有智能家居設備。舉個例子，2004年的地震和隨後的海嘯造就了由海洋傳感器構成的海嘯預警係統。自2011年的日本東北地區的地震以來，日本已經沿火車軌道安裝了許多傳感器，幫助探測不尋常的地震活動以便及時關閉火車運行。GE和其它大電子/電氣公司擁有巨量的車間生產日誌和其它的M2M數據。Splunk、Sumo Logic、Logscape，還有XpoLog是一些專注於M2M數據分析的公司。
這一切是如何組合在一起的：機器對機器的故障分析
這個用例來自電子製造公司。車間裏的不同設備，接收輸入，執行測試，以非結構化文本形式發送日誌，記錄測試運行的結果。日誌基本上獲取了每次測試的參數和它們的值以及輸出的結果——這麼做的意圖就是確認測試是通過還是失敗。為便於讀者理解要處理和分析什麼，下麵給出日誌文件樣本。
識別錯誤的老辦法是把數據傳遞給一個專家創建的複雜的正則表達式。新方法是用機器學習算法代替正則表達式——由算法學習故障根源的模式。
這個係統的架構見圖4.2。為了便於理解，來自機器的輸入數據發布到Kafka集群。Kafka是一個高速分布式發布-訂閱係統（Kreps等 2011）。Kafka的主要組件是生產者、代理、消費者（譯者注：原文分別是：producer broker consumer）。它為一個集群中多代理節點，以及多生產者、消費者節點提供了靈活性。生產者向一個主題發布數據。一個名為代理的Kafka服務器儲存著這些消息，允許消費者訂閱並異步消費它們。
圖4.2 工業日誌分類係統架構
Kafka的一個有趣前提是順序磁盤訪問比重複的隨機訪問內存更快。這樣就允許他們把緩存在內存的數據/消息保存到磁盤，從而容忍故障。如果一個代理（broker）從故障中恢複後，消費者能夠繼續消費保存在磁盤上的消息。即使消費者崩潰了，它也可以發現（譯者注：原文是come up）、倒帶、重新消費數據。這是通過Kafka所使用的拉取模型得以實現的，消費者從代理拉取數據——它們可以按照自己的節奏進行。這種模型與其它消費係統有所不同，例如那些基於JMS的實現（HornerQ就是這樣一個係統）。在我們的係統中，這很有用，因為消費者是一個Storm的Kafka spout。Kafka spout隻會以Storm能夠處理的速度消費數據（在它上麵運行機器學習算法）。Kafka也通過無狀態的設計提供容錯機製——所有的組件隻用Zookeeper集群或磁盤維護狀態。這樣就允許組件從臨時故障中恢複。Kafka還提供數據在集群中的分片選項。
Kafka另一個有趣的地方是它的維護消息順序的能力——在時間敏感的上下文環境中這一點就變的很重要。這一點保證了Storm不會亂序處理消息——Storm的Kafka spout將會從生產者按順序接收消息。還可以在生產者和代理之間插入一個負載均衡器，根據負載環境將消息發送給合適的代理。
我們已經為Storm實現了一個Kafka spout，用來消費數據流。這些數據由Storm bolt接收並處理。我們為機器學習算法的訓練部分實現了一個分離bolt，以及運行時的分類部分。訓練算法是串行的，它的並行化是一個正交問題，現在我們可以忽略它。它必須理解完成了算法學習模式（完成了訓練），它就能夠用於分類。在線分類算法運行於一個Storm bolt——我們已經配置了Storm為輸入流的每個元組使用分離線程。每個元組表示一組從輸入流注入的值，這些值將按照“失敗的“或”通過的“分類。我們還配置Storm以分布式模式運行並確保能夠在集群的任意節點上高度每個線程。
機器學習(譯者注：這一節學術性質太強，術語太多，可能翻譯的不夠好)
當前的機器學習算法實現了最小二乘法(LS)SVM的二類分類——使用了一個整體上可以擴展為多類分類。訓練階段的目的是最小化下述標準：
數據點的各自類別為n1,n2，總數為n(=n1+n2)。質心向量表示為c1,c2,c；協方差矩陣為Sd*d；正規化參數記為C。閉合形式解如下：
標準向量
偏差為
標準矢量和偏差是訓練向量——那些訓練算法的輸出以及捕捉模式的訓練數據。它們以下列方式用於在線分類器：
（一類）
（其它分類）
互聯網流量過濾器
這個應用與之前的那個非常相似。因此我們隻討論它的顯著特征並給出簡要說明。架構如圖4.3。
圖4.3 互聯網流分類係統架構
該架構的突出特性歸因於獨特的自然語言處理需要。（頁麵可以是英語或其它語言，比如阿拉伯語或印度語。）因此必須有一個單獨的用作數據修改的Storm bolt。一個叫做斯坦福自然語言處理工具的開源項目（NLP），可在這裏提供幫助，隻需要對輸入數據格式做上些調整。數據必須被廣泛並行化——在實時的機器學習中，必須在精度和吞吐量之間做出權衡。權衡的產生歸因於可能為了提高精度而為算法增加的參數，而更多的參數又增加了算法運行時間。因此，為了達到高精度而又不影響係統吞吐量，數據準備時間就要被大幅縮減——又因此，數據修改bolt就要做出微調。與之相似，即使分類算法（一種SVM）也需要並行化並高效實現。
Storm的替代品
能夠運行時實現機器學習算法的分布式流式係統的選擇並不多——Hadoop不合格的原因很簡單，基於它執行分布於內存中的操作很困難。把一個批處理係統改成一個流式處理係統或者把一個單一係統改成一個流處理和批處理兼務的高效係統是一項艱巨的任務。合理的選擇隻有Akka、Yahoo的S4（Neumeyer等. 2010）和Storm。這樣一個係統的需求如下：
- 長期的輸入速率高於輸入
- 必須在內存中存儲隊列化的數據
- 必須允許並行的數據處理
Akka尚處於成為一個企業級選擇的起步和造勢階段。有趣的是，它率先提出了基於角色的模型（由Agha 1986）。然而，就現在而言，相比於Akka，Storm似乎更成熟且擁有更多的生產用例。
S4係統類似於Akka，也是基於角色的模型實現，但是更加強大而複雜。S4係統包括處理元素（PE），PE之間可以通過生產或消費事件實現互相通訊，不過不能訪問其它PE的狀態。一個S4流定義為一個鍵值對（Storm流是元組）。PE消費流，計算中間值，還可能會分發輸出流。處理節點（PN）是PE的邏輯主機。事件由它們的關鍵屬性通過哈希函數路由到PN。與Storm類似，幫助PE發送/接收事件的交互層構建於ZooKeeper之上。S4不能處理因故障丟失的消息，因為實現它的假設之一是：因故障丟失的消息是可容忍的。
來自穀歌的Dremel（Melnik等 2010）或它的開源實現Apache Drill也被稱做實時查詢係統。讀者可能疑惑我們為什麼不用它或者不把它與Storm/S4比較一番。需要理解的是，Storm/S4是可能用來實現近實時機器學習算法的流式處理引擎，然而Dremel和Drill是實時查詢係統。如果有運行類SQL實時查詢功能的係統，Dremel/Drill就相當合適。Drill由MapR支持。Cloudera也有它自己的Dremel實現，叫做Imala。
最後更新：2017-05-22 16:39:35