流計算概述

什麼是流數據：

數據有靜態數據和流數據。

靜態數據：

很多企業爲了支持決策分析而構建的數據倉庫系統，其中存放的大量歷史數據就是靜態數據。技術人員可以利用數據挖掘和 OLAP（On-Line Analytical Processing）分析工具從靜態數據中找到對企業有價值的信息。

靜態

圖：靜態數據的一般處理流程

流數據：

近年來，在 Web 應用、網絡監控、傳感監測等領域，興起了一種新的數據密集型應用——流數據，即數據以大量、快速、時變的流形式持續到達。

• 實例：PM2.5 檢測、電子商務網站用戶點擊流

流數據具有如下特徵：

• 數據快速持續到達，潛在大小也許是無窮無盡的。

• 數據來源衆多，格式複雜。

• 數據量大，但是不十分關注存儲，一旦經過處理，要麼被丟棄，要麼被歸檔存儲。

• 注重數據的整體價值，不過分關注個別數據。

• 數據順序顛倒，或者不完整，系統無法控制將要處理的新到達的數據元素的順序。

批量計算和實時計算：

對靜態數據和流數據的處理，對應着兩種截然不同的計算模式：批量計算和實時計算。

• 批量計算：充裕時間處理靜態數據，如 Hadoop。

• 流計算：流數據不適合採用批量計算，因爲流數據不適合用傳統的關係模型建模。流數據必須採用實時計算，響應時間爲秒級。在大數據時代，數據格式複雜、來源衆多、數據量巨大，對實時計算提出了很大的挑戰。因此，針對流數據的實時計算——流計算，應運而生。

模型

圖：數據的兩種處理模型

流計算的概念：

流計算：實時獲取來自不同數據源的海量數據，經過實時分析處理，獲得有價值的信息。

流計算示意圖

圖：流計算示意圖

流計算秉承一個基本理念，即數據的價值隨着時間的流逝而降低，如用戶點擊流。因此，當事件出現時就應該立即進行處理，而不是緩存起來進行批量處理。爲了及時處理流數據，就需要一個低延遲、可擴展、高可靠的處理引擎.

對於一個流計算系統來說，它應達到如下需求：

• 高性能

• 海量式

• 實時性

• 分佈式

• 易用性

• 可靠性

Streaming 定義：

Streaming 是基於開源 Storm，是一個分佈式、實時計算框架。

特點：

• 實時響應，低延時。

• 數據不存儲，先計算

• 連續查詢

• 事件驅動

傳統數據庫計算：數據先存儲，在查詢處理。

流計算與 Hadoop:

Hadoop 設計的初衷是面向大規模數據的批量處理。

MapReduce 是專門面向靜態數據的批量處理的，內部各種實現機制都爲批處理做了高度優化，不適合用於處理持續到達的動態數據。

可能會想到一種 “變通” 的方案來降低批處理的時間延遲——將基於 MapReduce 的批量處理轉爲小批量處理，將輸入數據切成小的片段，每隔一個週期就啓動一次 MapReduce 作業。但這種方式也無法有效處理流數據。

• 切分成小片段，可以降低延遲，但是也增加了附加開銷，還要處理片段之間依賴關係。

• 需要改造 MapReduce 以支持流式處理。

結論：魚和熊掌不可兼得，Hadoop 擅長批處理，不適合流計算。

Streaming 在 FusionInsight 中的位置：

位置

圖：Streaming 在 FusionInsight 中的位置

Streaming 是一個實時分佈式的實時計算框架，在實時業務彙總有廣泛的應用。

流計算框架：

當前業界誕生了許多專門的流數據實時計算系統來滿足各自需求。

商業級：IBM InfoSphere Streams 和 IBM StreamBase。

開源流計算框架

• Twitter Storm：免費、開源的分佈式實時計算系統，可簡單、高效、可靠地處理大量的流數據。

• Yahoo! S4（Simple Scalable Streaming System）：開源流計算平臺，是通用的、分佈式的、可擴展的、分區容錯的、可插拔的流式系統。

公司爲支持自身業務開發的流計算框架：

• Facebook Puma

• Dstream（百度）

• 銀河流數據處理平臺（淘寶）

流計算的應用：

流計算是針對流數據的實時計算，可以應用在多種場景中。如百度、淘寶等大型網站中，每天都會產生大量流數據，包括用戶的搜索內容、用戶的瀏覽記錄等數據。採用流計算進行實時數據分析，可以瞭解每個時刻的流量變化情況，甚至可以分析用戶的實時瀏覽軌跡，從而進行實時個性化內容推薦。但是，並不是每個應用場景都需要用到流計算的。流計算適合於需要處理持續到達的流數據、對數據處理有較高實時性要求的場景。

主要應用於以下幾種場景：

1. 實時分析：如實時日誌處理、交通流量分析等。

2. 實時統計：如網站的實時訪問統計、排序等。

3. 實時推薦：如實時的廣告定位、時間營銷等。

流計算處理流程

概述：

傳統的數據處理流程，需要先採集數據並存儲在關係數據庫等數據管理系統中，之後由用戶通過查詢操作和數據管理系統進行交互。

傳統的數據處理流程隱含了兩個前提：

• 存儲的數據是舊的。存儲的靜態數據是過去某一時刻的快照，這些數據在查詢時可能已不具備時效性了。

• 需要用戶主動發出查詢來獲取結果。

流計算的處理流程一般包含三個階段：數據實時採集、數據實時計算、實時查詢服務。

流計算處理流程

圖：流計算處理流程示意圖

數據實時採集：

數據實時採集階段通常採集多個數據源的海量數據，需要保證實時性、低延遲與穩定可靠。

以日誌數據爲例，由於分佈式集羣的廣泛應用，數據分散存儲在不同的機器上，因此需要實時彙總來自不同機器上的日誌數據。

目前有許多互聯網公司發佈的開源分佈式日誌採集系統均可滿足每秒數百 MB 的數據採集和傳輸需求，如：

• Facebook 的 Scribe

• LinkedIn 的 Kafka

• 淘寶的 Time Tunnel

• 基於 Hadoop 的 Chukwa 和 Flume

數據採集系統的基本架構一般有以下三個部分：

數據採集

圖：數據採集系統基本框架

1. Agent：主動採集數據，並把數據推送到 Collector 部分。

2. Collector：接收多個 Agent 的數據，並實現有序、可靠、高性能的轉發。

3. Store：存儲 Collector 轉發過來的數據（對於流計算不存儲數據）。

數據實時計算：

數據實時計算階段對採集的數據進行實時的分析和計算，並反饋實時結果。

經流處理系統處理後的數據，可視情況進行存儲，以便之後再進行分析計算。在時效性要求較高的場景中，處理之後的數據也可以直接丟棄。

實時計算

圖：數據實時計算流程

實時查詢服務：

實時查詢服務：經由流計算框架得出的結果可供用戶進行實時查詢、展示或儲存。

傳統的數據處理流程，用戶需要主動發出查詢才能獲得想要的結果。而在流處理流程中，實時查詢服務可以不斷更新結果，並將用戶所需的結果實時推送給用戶。

雖然通過對傳統的數據處理系統進行定時查詢，也可以實現不斷地更新結果和結果推送，但通過這樣的方式獲取的結果，仍然是根據過去某一時刻的數據得到的結果，與實時結果有着本質的區別。

可見，流處理系統與傳統的數據處理系統有如下不同：

1. 流處理系統處理的是實時的數據，而傳統的數據處理系統處理的是預先存儲好的靜態數據。

2. 用戶通過流處理系統獲取的是實時結果，而通過傳統的數據處理系統，獲取的是過去某一時刻的結果。

3. 流處理系統無需用戶主動發出查詢，實時查詢服務可以主動將實時結果推送給用戶。

開源流計算框架 Storm

Storm 簡介：

Twitter Storm 是一個免費、開源的分佈式實時計算系統，Storm 對於實時計算的意義類似於 Hadoop 對於批處理的意義，Storm 可以簡單、高效、可靠地處理流數據，並支持多種編程語言。

Storm 框架可以方便地與數據庫系統進行整合，從而開發出強大的實時計算系統。

Twitter 是全球訪問量最大的社交網站之一，Twitter 開發 Storm 流處理框架也是爲了應對其不斷增長的流數據實時處理需求。

Storm 的特點：

Storm 可用於許多領域中，如實時分析、在線機器學習、持續計算、遠程 RPC、數據提取加載轉換等。

Storm 具有以下主要特點：

• 整合性

• 簡易的 API

• 可擴展性

• 可靠的消息處理

• 支持各種編程語言

• 快速部署

• 免費、開源

系統架構：

系統價格

圖：流計算系統架構圖

基本概念：

Storm 主要術語包括 Streams、Spouts、Bolts、Topology 和 Stream Groupings.

• Topology：Streaming 中運行的一個實時應用程序。

• Nimbus：負責資源分配和任務調度。

• Supervisor：負責接收 Nimbus 分配的任務，啓動和停止屬於自己管理的 worker 進程。

• Worker：Topology 運行時的物理進程。每個 Worker 是一個 JVM 進程。

• Spout：Storm 認爲每個 Stream 都有一個源頭，並把這個源頭抽象爲 Spout。

  在一個 Topology 中產生源數據流的組件。

  通常 Spout 會從外部數據源（隊列、數據庫等）讀取數據，然後封裝成 Tuple 形式，發送到 Stream 中。Spout 是一個主動的角色，在接口內部有個 nextTuple 函數，Storm 框架會不停的調用該函數。

• Bolt：在一個 Topology 中接收數據後然後執行處理的組件。

• Task：Worker 中每一個 Spout/Bolt 的線程稱爲一個 Task。

• Tuple：Streaming 的核心數據結構，是消息傳遞的基本單元，不可變 Key-Value 對，這些 Tuple 會以一種分佈式的方式進程創建和處理。

• Stream：Storm 將流數據 Stream 描述成一個無限的 Tuple 序列，這些 Tuple 序列會以分佈式的方式並行地創建和處理。即無界的 Tuple 序列。

• Zookeeper：爲 Streaming 服務中各自進程提供分佈式的協作服務、主備 Nimbus、Supervisor、Worker 將自己的信息註冊到 Zookeeper 中，Nimbus 據此感知各個角色的監控狀態。

Topology 介紹：

Topology 示意圖

圖：Topology 示意圖

Storm 將 Spouts 和 Bolts 組成的網絡抽象成 Topology，它可以被提 交到 Storm 集羣執行。Topology 可視爲流轉換圖，圖中節點是一個 Spout 或 Bolt，邊則表示 Bolt 訂閱了哪個 Stream。當 Spout 或者 Bolt 發送元組時，它會把元組發送到每個訂閱了該 Stream 的 Bolt 上進行處理。

Topology 裏面的每個處理組件（Spout 或 Bolt）都包含處理邏輯， 而組件之間的連接則表示數據流動的方向。

Topology 裏面的每一個組件都是並行運行的：

• 在 Topology 裏面可以指定每個組件的並行度，Storm 會在集羣裏面分配那麼多的線程來同時計算。

• 在 Topology 的具體實現上，Storm 中的 Topology 定義僅僅是一些 Thrift 結構體（二進制高性能的通信中間件），支持各種編程語言進行定義。

一個 Topology 是由一組 Spout 組件 (數據源) 和 Bolt 組件（邏輯處理）通過 Stream Groupings 進行連接的有向無環圖（DAG）。

業務處理邏輯被封裝進 Streaming 中的 Topology 中。

Worker 介紹：

Worker

圖：Worker Process 示意圖

Worker：一個 Worker 是一個 JVM 進程，所有的 Topology 都是在一個或者多個 Worker 中運行的。Worker 啓動後是長期運行的，除非人工停止。Worker 進程的個數取決於 Topology 的設置，且無設置上限，具體可獲得並調度啓動的 Worker 個數則取決於 Supervisor 配置的 slot 個數。

Executor：在一個單獨的 Worker 進程中會運行一個或多個 Executor 線程。每個 Executor 只能運 Spout 或者 Bolt 中的一個或多個 Task 實例。

Task：是最終完成數據處理的實體單元。

Task 介紹：

Task

圖：Task 示意圖

Topology 裏面的每一個 Component(組件)（Spout/Blot）節點都是並行運行的。在 Topology 裏面，可以指定每個節點的併發度，Streaming 則會在集羣裏分配響應的 Task 來同時計算，以增強系統的處理能力。

消息分發策略（Stream Groupings）：

Groupings：Storm 中的 Stream Groupings 用於告知 Topology 如何在兩個組件間（如 Spout 和 Bolt 之間，或者不同的 Bolt 之間）進行 Tuple 的傳送。每一個 Spout 和 Bolt 都可以有多個分佈式任務，一個任務在什麼時候、以什麼方式發送 Tuple 就是由 Stream Groupings 來決定的。

目前，Storm 中的 Stream Groupings 有如下幾種方式：

1. ShuffleGrouping：隨機分組，隨機分發 Stream 中的 Tuple，保證每個 Bolt 的 Task 接收 Tuple 數量大致一致。

2. FieldsGrouping：按照字段分組，保證相同字段的 Tuple 分配到同一個 Task 中。

3. AllGrouping：廣播發送，每一個 Task 都會收到所有的 Tuple。

4. GlobalGrouping：全局分組，所有的 Tuple 都發送到同一個 Task 中。

5. NonGrouping：不分組，和 ShuffleGrouping 類似，當前 Task 的執行會和它的被訂閱者在同一個線程中執行。

6. DirectGrouping：直接分組，直接指定由某個 Task 來執行 Tuple 的處理。

分鐘

Storm 框架設計：

Storm 集羣採用 “Master—Worker” 的節點方式：

• Master 節點運行名爲 “Nimbus” 的後臺程序（類似 Hadoop 中的“JobTracker”），負責在集羣範圍內分發代碼、爲 Worker 分配任務和監測故障。

• Worker 節點運行名爲 “Supervisor” 的後臺程序，負責監聽分配給它所在機器的工作，即根據 Nimbus 分配的任務來決定啓動或停止 Worker 進程，一個 Worker 節點上同時運行若干個 Worker 進程。

• Storm 使用 Zookeeper 來作爲分佈式協調組件，負責 Nimbus 和多個 Supervisor 之間的所有協調工作。藉助於 Zookeeper，若 Nimbus 進程或 Supervisor 進程意外終止，重啓時也能讀取、恢復之前的狀態並繼續工作，使得 Storm 極其穩定。

架構

圖：Storm 集羣架構示意圖

Nimbus 並不直接和 Supervisor 交換，而是通過 Zookeeper 進行消息的傳遞。

Storm 和 Hadoop 架構組件功能對應關係：

Storm 運行任務的方式與 Hadoop 類似：Hadoop 運行的是 MapReduce 作業，而 Storm 運行的是 “Topology”。

但兩者的任務大不相同，主要的不同是：MapReduce 作業最終會完成計算並結束運行，而 Topology 將持續處理消息（直到人爲終止）。

對比

圖：Storm 和 Hadoop 架構組件功能對應關係

Storm 工作流程：

工作流程

圖：Storm 工作流程示意圖

Storm 工作流程爲：

1. 提交 Topology

2. 將任務存儲在 Zookeeper 中

3. 獲取分配的任務，並啓動 Worker

4. Worker 進程執行具體的任務

所有 Topology 任務的提交必須在 Storm 客戶端節點上進行，提交後，由 Nimbus 節點分配給其他 Supervisor 節點進行處理。

Nimbus 節點首先將提交的 Topology 進行分片，分成一個個 Task，分配給相應的 Supervisor，並將 Task 和 Supervisor 相關 的信息提交到 Zookeeper 集羣上。

Supervisor 會去 Zookeeper 集羣上認領自己的 Task，通知自己的 Worker 進程進行 Task 的處理。

Streaming 提供的接口：

REST 接口：（Representational State Transfer）表述性狀態轉移接口。

Thrift 接口：由 Nimbus 提供。Thrift 是一個基於靜態代碼生成的跨語言的 RPC 協議棧實現，它可以生成包括 C++,Java,Python, Ruby ， PHP 等主流語言的代碼實現，這些代碼實現了 RPC 的協議層和傳輸層功能，從而讓用戶可以集中精力與服務的調用和實現。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/sShdX6Jpl9TbhfMnSTYksw