流計算成為大數據實時計算的事實代名詞

實時計算一般都是針對海量數據進行的，一般要求為秒級。實時計算主要分為兩塊：

• 數據的實時入庫

• 數據的實時計算

數據源是實時的不間斷的，要求用戶的響應時間也是實時的（比如對于大型網站的流式數據：網站的訪問 PV/UV、用戶訪問了什么內容、搜索了什么內容等，實時的數據計算和分析可以動態實時地刷新用戶訪問數據，展示網站實時流量的變化情況，分析每天各小時的流量和用戶分布情況）。

當談及大數據實時計算方面當前的挑戰時，吳惠君表示這個挑戰就如同其名字一樣：大數據的挑戰，實時計算的挑戰。其中，大數據的挑戰包括很多方面：

• 比如‘數據的獲得’上，現在移動端的數據分布廣，按照一般的思路是收集手機數據到云上，那么這個收集的系統就是第一個要解決的挑戰，一般 Kafka 比較適用，或者類似的 Pulsar 也有很多人嘗試。

• 比如‘數據的存儲’上，由于這些收集的數據要被實時計算使用，所以這個存儲系統要響應快速，并能很好的跟實時計算的系統結合，一般 Druid 可以適用在這個場景，另外它還能跟批處理的歷史數據存儲結合。除此之外，還有比如’數據的備份’等等。

在大數據挑戰基礎上的實時計算的挑戰，是個非常復雜的問題。傳統的硬實時或者軟實時系統難以應用在大數據的情況下，然后在現有大數據平臺的基礎上構建新的實時系統才是普遍采用的方法，其中流計算就處在這樣一個位置。

流計算有幾個適應的點，它可以方便的建立在大數據的平臺或者云上，并且能夠通過一些擴容方法來滿足各種大小數據量，憑借它的低延遲的特性，它可以滿足一定的實時要求它和其他大數據處理的項目和社區共享先進的理念和經驗，這些讓流計算當仁不讓的成為大數據實時計算的事實代名詞。

可見，數據的價值隨著時間的流逝而降低，所以事件出現后必須盡快地對它們進行處理，而不是積累。對于這點和傳統的 MapReduce 有差異，即傳統的分布式計算往往是首先拿到一個大的積累后的數據，再進行數據拆分和聚合。而流處理的重點是通過事件機制，類似流管道一樣，接收都消息馬上就進行處理。

流式大數據的實時處理

大數據行業核心技術面臨的挑戰仍然存在，并將在可預見的未來持續下去。隨著數據呈指數級增長，企業組織和服務于其的技術公司將繼續處在一場持續的戰斗中，使其變得易于管理。

大數據通常被分為兩類：一類是批式大數據，另一類是流式大數據。

如果把數據當成水庫的話，水庫里面存在的水就是批式大數據，進來的水是流式大數據。

其中，流式數據的實時分析，一定是有規則、模型的東西。復雜的分析計算，加上實時這兩個結合起來，如果能做的好，一定能夠加速大數據在各個行業的應用。

當前，越來越多的企業選擇流處理。流處理打破了傳統的數據分析和處理的模式，即數據最終積累和落地后再針對海量數據進行拆分處理，然后進行分析統計，傳統的模式很難真正達到實時性和速度要求。

而實時流處理模型的重點正是既有類似 Hadoop 中 MapReduce 和 PIG 一樣的數據處理和調度引擎，又解決了直接通過輸入適配接到流的入口，流實時達到實時處理，實時進行分組匯聚等增量操作。

由于流數據實時到達，實時處理，有具體的數據處理的流處理引擎，因此具備低延遲，高可靠性和容錯能力。

Twitter 是如何實現對實時系統的異常檢測？

據吳惠君介紹：Heron 項目就是 Twitter 提供的流處理或者叫做大數據實時計算的典型。

一個穩定可靠的系統離不開監控，我們不僅監控服務是否存活，還要監控系統的運行狀況。運行狀況主要是對這些組件的核心 metrics 采集、抓取、分析和報警。

吳惠君描述：

在異常檢測方面，Heron 采用的 Dahlion 框架，在 Dhalion 框架基礎上開發了 Health manager 模塊來檢測和處理系統異常。其中，Dhalion 框架是由 Microsoft 和 Twitter 聯合發明專用于實時流處理系統的異常檢測和響應框架，它主要應對三個在流處理系統中的常見場景：

• self tuning

• self stabilizing

• self healing

Dhalion 由一個 policy 調度器和若干個 detector 和 resolver 來合作完成異常檢測和響應。

policy 管理 detector 和 resolver：

• detector 檢測系統各種指標的異常；

• resolver 根據 detector 的結果進行對應的處理。

另外，還有些輔助的模塊來配合這個主過程，比如 metrics provider 喂給 detecor 檢測數據；action 等完成 resolver 和 detector 之間的協同。

在 Dhalion 基礎上的 Health manager 實現了幾個 Heron 常用的 detector 和 resolver。比如檢測 slow instance 的 detector。有些時候，某些容器云調度的容器由于各種原因會比較慢，那么根據這個容器的各種指標，比如隊列長度，響應時間，反壓 backpressure 標志等，判斷比較然后得出這個容器結點相比其他容器是不是異常。

其他一些 detector 還包括檢測是不是整體上資源不夠，是不是可以壓縮資源池等等。在 resolver 方面，從最簡單的重啟容器，到擴容 / 縮容，特殊操作等等都可以用 resolver 的形式實現應用。

Heron 增加了新功能

自去年 Twitter 開源了大數據實時分析系統 Heron 以來，一年多的時間，Heron 社區開發了許多新的功能。據吳惠君介紹：特別是今年 Heron 增加了 elastic runtime scaling，effectively once，functional API，multi-language topology，self-regulating 等。

?elastic runtime scaling

根據 storm 的數據模型，topology 的并行度是 topology 的作者在編程 topology 的時候指定的。很多情況下，topology 需要應付的數據流量在不停的變化。

topology 的編程者很難預估適合的資源配置，所以動態的調整 topology 的資源配置就是運行時的必要功能需求。直觀地改變 topology 中結點的并行度就能快速的改變 topology 的資源使用量來應付數據流量的變換。Heorn 通過 update 命令來實現這種動態調整。

?effectively once

Heron 在原有 tuple 傳輸模式 at most once 和 at least once 以外，新加入了 effectively once。原有的 at most once 和 at least once 都有些不足之處，比如 at most once 會漏掉某些 tuple；而 at least once 會重復某些 tuple。所以 effectively once 的目標是使得計算結果精確可信。

?Functional API

函數式編程是近年來的熱點，Heron 適應時代潮流在原有 API 的基礎上添加了函 數式 API 。Heron 函數式 API 讓 topology 編程者更專注與 topology 的應用邏輯，而不必關心 topology/spout/bolt 的具體細節。Heron 的函數式 API 相比于原有底層 API 是一種更高層級上的 API，它背后的實現仍然是轉化為底層 API 來構建 topology。

?multi language topology

以往 topology 編程者通常使用兼容 Apache Storm 的 Java API 來編寫 topology。現在 Heron 提供 Python 和 C++ 的 API，讓熟悉 Python 和 C++ 的程序員也可以編寫 topology。

Python 和 C++ 的 API 設計與 Java API 類似，它們包含底層 API 用來構造 DAG，將來也會提供函數式 API 讓 topology 開發者更專注業務邏輯。

?self-regulating

Heron 結合 Dahlion 框架開發了新的 health manager 模塊。

• Dhalion 框架是一個讀取 metrics 然后對 topology 進行相應修復的框架。

• health manager 由 2 個步驟組成，detector/diagnose 和 resolver。

detector/diagonse 讀取 metrics 探測 topology 狀態并發現異常，resolver 根據發現的異常解決讓 topology 恢復正常。healtmgr 模塊的引入，形成了完整的反饋閉環。

倚仗開源社區 大大節約流式處理成本

流式處理是一種成本和效費比都高的計算模式。企業要如何權衡成本與人員支出的呢? 為此，吳惠君提出了自己的看法，借助云平臺和開源社區的力量，可以大大節約成本。

據吳惠君介紹，企業中使用流計算的成本分兩部分：機器和人員。

• 機器方面，很多企業都是基于容器云平臺上搭建流計算系統，對于這種情況機器池大小，部署等都可控。那么，機器的成本基本就是實打實的成本，意思是要處理這么多這么快的數據就是要這么多機器。對于具體的業務，根據實際場景測試能知道真實要多少機器，然后再看業務設計再來決策是不是值得。

• 人員方面，以 Heron 為例，Heron 開源以后形成了一定規模的社區，很多新的功能和日常項目維護很多都交給社區來做。依托社區的力量，企業實際的人員開銷并不大。

流數據處理引擎如何選？

我們可以對比一下現在流行的幾種流處理項目：Storm，Flink，Spark Streaming，Kafka Streams 和 Heron。

首先看 Storm。它是適用于需要快速響應中等流量的場景。Storm 和 Heron 在 API 上兼容，在功能上基本可以互換；Twitter 從 Storm 遷移到了 Heron，說明如果 Storm，Heron 二選一的話，沒有啥意外 情況需要考慮的話，一般都是選 Heron。

然后看 Kafka Streams。它與 Kafka 綁定，如果現有系統是基于 Kafka 構建的，可以考慮使用 Kafka Streams，減少各種開銷。

再看 Spark Streaming，一般認為 Spark Streaming 的流量是這些項目中最高的，但是它的響應延遲也是最高的。對于響應速度要求不高，但是對流通量要求高的系統，可以采用 Spark Streaming；如果把這種情況推廣到極致就可以直接使用 Spark 系統。

最后，Flink 使用了流處理的內核，同時提供了流處理和批處理的接口。如果項目中需要同時兼顧流處理和批處理的情況，Flink 比較適合。同時因為需要兼顧兩邊的取舍，在單個方面就不容易進行針對性的優化和處理。

可見，Spark Streaming，Kafka Streams，Flink 都有特定的應用場景，其他一般流處理情況下可以使用 Heron。

寫在最后

世界正在走向實時化，越來越多的應用場景需要以很低的延遲來分析實時數據。隨著實時數據的流行，流處理會是很重要處理方式。在許多快速擴展的實時用例中大多都應用了 Heron，其中包括異常和欺詐檢測、物聯網和萬物互聯應用、嵌入式系統、虛擬現實和增強現實、廣告投放、金融、安全和社會媒體等。在實時流處理過程中，如何選擇一款適合的流數據處理引擎？如何更快的采集數據并實時的處理數據？都是企業亟須突破的。

總結

以上是生活随笔為你收集整理的世界正在走向实时化，谈谈Twitter对流处理的理解与思考的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。