分佈式計算模式之Stream

前言

上文介紹了分佈式計算模式中的 MapReduce 模式。這種模式的核心思想是：將大任務拆分成多個小任務，針對這些小任務分別計算後，再合併各小任務的結果以得到大任務的計算結果。
這種模式下任務運行完成之後，整個任務進程就結束了，屬於短任務模式。但是任務進程的啓動和停止是一件很耗時的事兒，因此 MapReduce 對處理實時性的任務就不太合適了。實時性任務主要是針對流數據的處理，對處理時延要求很高，通常需要有常駐服務進程，等待數據的隨時到來隨時處理，以保證低時延。處理流數據任務的計算模式，在分佈式領域中叫作 Stream。

什麼是 Stream

近年來，由於網絡監控、傳感監測、AR/VR 等實時性應用的興起，一類需要處理流數據的業務發展了起來。比如各種直播平臺中，我們需要處理直播產生的音視頻數據流等。這種如流水般持續湧現，且需要實時處理的數據，我們稱之爲流數據。
總結來講，流數據的特徵主要包括以下 4 點：

• 數據如流水般持續、快速地到達；
• 海量數據規模，數據量可達到 TB 級甚至 PB 級；
• 對實時性要求高，隨着時間流逝，數據的價值會大幅降低；
• 數據順序無法保證，也就是說系統無法控制將要處理的數據元素的順序。

在分佈式領域中，處理流數據的計算模式，就是流計算，也叫作 Stream。流計算的職責是實時獲取來自不同數據源的海量數據，進行實時分析處理，獲得有價值的信息。流計算一般用於處理數據密集型應用。

Stream應用場景

• 百度、淘寶等大型網站中，每天都會產生大量的流數據，這些數據包括用戶的搜索內容、用戶的瀏覽記錄等。實時採集用戶數據，並通過流計算進行實時數據分析，可以瞭解每個時刻數據流的變化情況，甚至可以分析用戶的實時瀏覽軌跡，從而進行個性化內容實時推薦，提高用戶體驗。
• 愛奇藝、騰訊等音視頻平臺，對電影、電視劇等數據的處理，也是採用了流計算模式。

Stream 工作原理

上一篇文章中介紹了 MapReduce，是一種批量計算的形式。這種模式下，會先收集數據並將其緩存起來，等到緩存寫滿時纔開始處理數據。因此，批量計算的一個缺點就是，從數據採集到得到計算結果之間經歷的時間很長。
而流計算強調的是實時性，數據一旦產生就會被立即處理，當一條數據被處理完成後，會序列化存儲到緩存中，然後立刻通過網絡傳輸到下一個節點，由下一個節點繼續處理，而不是像 MapReduce 那樣，等到緩存寫滿纔開始處理、傳輸。爲了保證數據的實時性，在流計算中，不會存儲任何數據，就像水流一樣滾滾向前。所以說，流計算屬於持續性、低時延、事件驅動型的計算作業。
使用流計算進行數據處理，一般包括 3 個步驟，如下圖所示：

• 第一步，提交流式計算作業。流式計算作業是一種常駐計算服務，比如實時交通監測服務、實時天氣預報服務等。對於流式計算作業，首先必須預先定義計算邏輯，並提交到流計算系統中，使得流計算系統知道自己該如何處理數據。系統在整個運行期間，由於收集的是同一類型的數據、執行的是同一種服務，因此流式計算作業的處理邏輯不可更改。如果用戶停止當前作業運行後再次提交作業，由於流計算不提供數據存儲服務，因此之前已經計算完成的數據無法重新再次計算。
• 第二步，加載流式數據進行流計算。流式計算作業一旦啓動將一直處於等待事件觸發的狀態，一旦有小批量數據進入流式數據存儲，系統會立刻執行計算邏輯並迅速得到結果。從上圖中我們可以看出，在流計算系統中，有多個流處理節點，流處理節點會對數據進行預定義的處理操作，並在處理完後按照某種規則轉發給後續節點繼續處理。此外，流計算系統中還存在管理節點，主要負責管理處理節點以及數據的流動規則。其中，處理節點的個數以及數據轉發的規則，都在第一步作業提交時定義。
  第三步，持續輸出計算結果。流式計算作業在得到小批量數據的計算結果後，可以立刻將結果數據寫入在線 / 批量系統，無需等待整體數據的計算結果，以進一步做到實時計算結果的實時展現。

流計算不提供流式數據的存儲服務，數據是持續流動的，在計算完成後就會立刻丟棄。流計算適用於需要處理持續到達的流數據、對數據處理有較高實時性要求的場景。爲了及時處理流數據，流計算框架必須是低延遲、可擴展、高可靠的。
目前流計算相關的框架和平臺也有很多了，主流的劃分方式是將其分爲如下 3 類：

• 商業級的流計算平臺，比如 IBM 的 InfoSphere Streams 和 TIBCO 的 StreamBase。InfoSphereStreams 支持同時分析多種數據類型並實時執行復雜計算。StreamBase是一個用於實時分析的軟件，可以快速構建分析系統，即時做出決策。StreamBase可以爲投資銀行、對沖基金、政府機構等提供實時數據分析服務。
• 開源流計算框架，典型代表是 Apache Storm（由 Twitter開源）和 S4（由 Yahoo 開源）。Storm 是一個分佈式的、容錯的實時計算系統，可以持續進行實時數據流處理，也可以用於分佈式RPC。S4是一個通用的、分區容錯的、可擴展的、可插拔的分佈式流式系統。這些開源的分佈式流計算系統由於具備開源代碼，因此比較適合開發人員將其搭建在自身業務系統中。
• 各大公司根據自身業務特點而開發的流計算框架，比如 Facebook 的 Puma、百度的Dstream（旨在處理有向無環的數據流）、淘寶的銀河流數據處理平臺（一個通用的、低延遲、高吞吐、可複用的流數據實時計算系統）。
  除了這些框架外，還有 Spark、Flink 等，其中Spark 和 Flink 與 Storm 框架的不同之處在於，Spark 和 Flink 除了支持流計算，還支持批量計算。

Storm 的工作原理

說到 Storm 的工作原理，我們先來對比下 Storm 與 MapReduce 的區別吧。Hadoop 上運行的是“MapReduce 作業”，而 Storm 上運行的是“計算拓撲（Topologies）”。 “作業”和“拓撲”的一個關鍵區別是：MapReduce 的一個作業在得到結果之後總會結束；而拓撲描述的是計算邏輯，該計算邏輯會永遠在集羣中運行（除非你殺死該進程）。
如下圖所示，Storm 集羣上有兩種節點，即主節點（Master Node）和工作節點（Worker Nodes）。

• 主節點上運行着一個名爲“Nimbus”的守護進程。 Nimbus 負責爲集羣分發代碼，爲工作節點分配任務以及進行故障監控。一個 Storm集羣在工作過程中，只有一個 Nimbus 進程工作。
• 每個工作節點上都運行着一個名爲“Supervisor”的守護進程。Supervisor 負責監聽分配給它所在的機器上的工作，負責接收 Nimbus分配的任務，並根據需要啓動和停止工作進程，其中每個工作進程都執行一個子任務。因此，一個正在運行的拓撲任務，是由分佈在許多計算機上的許多工作進程組成。
  

Nimbus 和 Supervisors 協同工作

前面我介紹了 Nimbus 是負責分發任務或代碼的，Supervisor 是負責接收任務，並啓動和停止工作進程以執行任務的。那麼 Nimbus 和 Supervisors 之間，具體是怎麼協同的呢：

• 如果所有數據和信息均存儲在 Master Node 上，Master Node 故障後，會導致整個集羣信息丟失，因此引入了 ZooKeeper 集羣來加強可靠性。爲此 Master Node 與 Worker Node 之間的交互通過 ZooKeeper 完成，由於 Nimbus 和 Supervisors 是 Master Node 和 Worker Node 之間負責交互的進程，因此 Nimbus 和 Supervisors 之間的所有協調都是通過 ZooKeeper 集羣完成的，比如 Nimbus 會將任務的分配情況或信息發送給 ZooKeeper 集羣，然後 Supervisors 向 ZooKeeper 集羣獲取任務，並啓動工作進程以執行任務。
• 當 Supervisor 接收到分配的任務後，會啓動工作節點的工作進程 (Worker) 去執行任務。一個計算任務可以分成任務數據的讀取以及任務執行兩部分。Worker 提供了兩個組件 Spout 和 Bolt，分別進行數據讀取和任務執行。

Storm 爲進行數據流轉換提供了基本組件 Spout 和 Bolt。 Spout 和 Bolt 有用戶自定義的接口，用於運行特定應用程序的邏輯。如下圖所示，Storm 上運行的計算拓撲其實是由一系列 Spout 和 Bolt 組成的有向無環圖，這個有向無環圖代表了計算邏輯。

Spout 和 Bolt 的含義：

• Spout 用於接收源數據。通常情況下，Spout 會從一個外部的數據源讀取數據元組，然後將它們發送到拓撲中。例如，Spout 從Twitter API 讀取推文並將其發佈到拓撲中。
• Bolt 負責處理輸入的數據流，比如數據過濾（filtering）、函數處理（functions）、聚合（aggregations）、聯結（joins）、數據庫交互等。數據處理後可能輸出新的流作爲下一個Bolt 的輸入。每個 Bolt 往往只具備單一的計算邏輯。當我們執行簡單的數據流轉換時，比如僅進行數據過濾，則通常一個 Bolt可以實現；而複雜的數據流轉換通常需要使用多個 Bolt並通過多個步驟完成，比如在神經網絡中，對原始數據進行特徵轉換，需要經過數據過濾、清洗、聚類、正則化等操作。

流計算和批量計算的區別是什麼

總結