流計算成為大數(shù)據(jù)實時計算的事實代名詞

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

• 數(shù)據(jù)的實時入庫

• 數(shù)據(jù)的實時計算

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

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

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

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

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

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

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

流式大數(shù)據(jù)的實時處理

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

大數(shù)據(jù)通常被分為兩類：一類是批式大數(shù)據(jù)，另一類是流式大數(shù)據(jù)。

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

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

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

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

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

Twitter 是如何實現(xiàn)對實時系統(tǒng)的異常檢測？

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

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

吳惠君描述：

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

• self tuning

• self stabilizing

• self healing

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

policy 管理 detector 和 resolver：

• detector 檢測系統(tǒng)各種指標的異常；

• resolver 根據(jù) detector 的結(jié)果進行對應的處理。

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

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

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

Heron 增加了新功能

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

?elastic runtime scaling

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

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

?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 的目標是使得計算結(jié)果精確可信。

?Functional API

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

?multi language topology

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

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

?self-regulating

Heron 結(jié)合 Dahlion 框架開發(fā)了新的 health manager 模塊。

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

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

detector/diagonse 讀取 metrics 探測 topology 狀態(tài)并發(fā)現(xiàn)異常，resolver 根據(jù)發(fā)現(xiàn)的異常解決讓 topology 恢復正常。healtmgr 模塊的引入，形成了完整的反饋閉環(huán)。

倚仗開源社區(qū) 大大節(jié)約流式處理成本

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

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

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

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

流數(shù)據(jù)處理引擎如何選？

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

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

然后看 Kafka Streams。它與 Kafka 綁定，如果現(xiàn)有系統(tǒng)是基于 Kafka 構(gòu)建的，可以考慮使用 Kafka Streams，減少各種開銷。

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

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

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

寫在最后

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

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。