什麼是實時流計算？
1、實時流計算背景
2、實時計算應用場景
3、實時計算處理流程
4、實時計算架構
所謂實時流計算，就是近幾年由于資料得到廣泛應用之後，在資料持久性模組化不滿足現狀的情況下，急需資料流的瞬時模組化或者計算處理。這種實時計算的應用執行個體有金融服務、網絡監控、電信資料管理、 Web 應用、生産制造、傳感檢測，等等。在這種資料流模型中，單獨的資料單元可能是相關的元組（Tuple），如網絡測量、呼叫記錄、網頁通路等産生的資料。但是，這些資料以大量、快速、時變（可能是不可預知）的資料流持續到達，由此産生了一些基礎性的新的研究問題——實時計算。實時計算的一個重要方向就是實時流計算。
實時流計算背景
資料的價值随着時間的流逝而降低，是以事件出現後必須盡快對它們進行處理，最好事件出現時便立刻對其進行處理，發生一個事件進行一次處理，而不是緩存起來成一批處理。例如商用搜尋引擎，像 Google、 Bing 和 Yahoo! 等，通常在使用者查詢響應中提供結構化的Web 結果，同時也插入基于流量的點選付費模式的文本廣告。為了在頁面上的最佳位置展現最相關的廣告，通過一些算法來動态估算給定上下文中一個廣告被點選的可能性。上下文可能包括使用者偏好、地理位置、曆史查詢、曆史點選等資訊。一個主搜尋引擎可能每秒鐘處理成千上萬次查詢，每個頁面都可能會包含多個廣告。為了及時處理使用者回報，需要一個低延遲、可擴充、高可靠的處理引擎。
對于這些實時性要求很高的應用，若把持續到達的資料簡單地放到傳統資料庫管理系統DBMS）中，并在其中進行操作，是不切實際的。傳統的 DBMS 并不是為快速連續地存放單的資料單元而設計的，而且也不支援“持續處理”，而“持續處理”是資料流應用的典型特征。另外，現在人們都認識到，“近似性”和“自适應性”是對資料流進行快速查詢和其處理（如資料分析和資料采集）的關鍵要素，而傳統 DBMS 的主要目标恰恰與之相反：通穩定的查詢設計，得到精确的答案。
另外一些方案是采用 MapReduce 來處理實時資料流。但是，盡管 MapReduce 做了實時性改進，也很難穩定地滿足應用需求。這是因為 Hadoop MapReduce 架構為批處理做了高度優化，典型的是通過排程批量任務來操作靜态資料，任務不是常駐服務，資料也不是實時流入；而資料流計算的典型範式之一是不确定資料速率的事件流流入系統，系統處理能力必須與事件流量比對。
實時計算應用
網際網路領域的實時流計算一般都是針對海量資料進行的，除了非實時計算的需求（如計算結果準确）以外，實時計算最重要的一個需求是能夠實時響應計算結果，一般要求為秒級。個人了解，網際網路行業的實時計算可以分為以下兩種應用場景。
1）資料源是實時的、不間斷的，要求對使用者的響應時間也是實時的。主要用于網際網路流式資料處理。所謂流式資料，是指将資料看作資料流的形式來處理。資料流則是在時間分布和數量上無限的一系列資料記錄的集合體；資料記錄是資料流的最小組成單元。例如，對于大型網站，活躍的流式資料非常常見，這些資料包括網站的通路 PV/UV、使用者通路的内容、搜尋的内容等。實時的資料計算和分析可以動态實時地重新整理使用者通路資料，展示網站實時流量的變化情況，分析每天各小時的流量和使用者分布情況，這對于大型網站來說具有重要的實際意義。
2）資料量大且無法或沒必要預算，但要求對使用者的響應時間是實時的。主要用于特定場合下的資料分析處理。當資料量很大，同時發現無法窮舉所有可能條件的查詢組合或者大量窮舉出來的條件組合無用時，實時計算就可以發揮作用，将計算過程推遲到查詢階段進行，但需要為使用者提供實時響應。
實時計算處理流程
網際網路上海量資料（一般為日志流）的實時計算過程可以劃分為 3 個階段：資料的産生與收集階段、傳輸與分析處理階段、存儲對對外提供服務階段，如圖 1-1 所示。下面分别進行簡單介紹。
圖 1 實時計算處理流程
（1）資料實時采集
需求：功能上保證可以完整地收集到所有日志資料，為實時應用提供實時資料；響應時間上要保證明時性、低延遲（在 1s 左右）；配置簡單，部署容易；系統穩定可靠等。
目前，網際網路企業的海量資料采集工具有 Facebook 開源的 Scribe、 LinkedIn 開源的Kafka、 Cloudera 開源的 Flume，淘寶開源的 TimeTunnel、 Hadoop 的 Chukwa 等，它們均可以滿足每秒數百 MB 的日志資料采集和傳輸需求。
（2）資料實時計算
傳統的資料操作，首先将資料采集并存儲在 DBMS 中，然後通過查詢和 DBMS 進行互動，得到使用者想要的答案。在整個過程中，使用者是主動的，而 DBMS 系統是被動的，過程操作如圖 1-2 所示。
圖 2 傳統的資料操作流程
但是，對于現在大量存在的實時資料，如股票交易的資料，這類資料實時性強，資料量大，沒有止境，傳統的架構并不合适。流計算就是專門針對這種資料類型準備的。在流資料不斷變化的運動過程中實時地進行分析，捕捉到可能對使用者有用的資訊，并把結果發送出去。在整個過程中，資料分析處理系統是主動的，而使用者卻處于被動接收的狀态，處理流程如圖 3 所示。
圖 3 流計算處理過程
需求：适應流式資料、不間斷查詢；系統穩定可靠、可擴充性好、可維護性好等。有關計算的一些注意點：分布式計算、并行計算（節點間的并行、節點内的并行）、熱點資料的緩存政策、服務端計算。
（3）實時查詢服務
全記憶體：直接提供資料讀取服務，定期轉存到磁盤或資料庫進行持久化。
半記憶體：使用 Redis、 Memcache、 MongoDB、 BerkeleyDB 等記憶體資料庫提供資料實時查詢服務，由這些系統進行持久化操作。
全磁盤：使用 HBase 等以分布式檔案系統（HDFS）為基礎的 NoSQL 資料庫，對于KeyValue 記憶體引擎，關鍵是設計好 Key 的分布。
實時計算架構
最近這幾年随着實時計算的流行，相繼出現了以下實時計算的架構。
1、 IBM 的 StreamBase
StreamBase 是 IBM 開發的一款商業流式計算系統，在金融行業和政府部門使用，其本身是商業應用軟體，但提供了開發版。相對于付費使用的企業版，開發版的功能更少，但這并不妨礙我們從外部使用 API 接口來對 StreamBase 本身進行分析。
StreamBase 使用 Java 開發， IDE 是基于 Eclipse 進行二次開發，功能非常強大。 StreamBase也提供了相當多的 Operator、 Functor 以及其他元件來幫助建構應用程式。使用者隻需要通過 IDE拖拉控件，然後關聯，設定好傳輸的 Schema 并且設定控件計算過程，就可以編譯出一個高效處理的流式應用程式。同時， StreamBase 還提供了類 SQL 來描述計算過程。 StreamBase 的架構如圖 1-4 所示。
StreamBase Server 是節點上啟動的管理程序，它負責管理節點上 Container 的執行個體，每個 Container 通 過 Adapter 獲 得 輸 入， 交 給 應 用 邏 輯 計 算， 然 後 通 過 Adapter 輸 出。 各 個Container 互相連接配接，形成一個計算流圖。
圖4 StreamBase 架構圖
Adapter 負責與異構輸入或輸出互動，源或目的地可能包括 CSV 檔案、 JDBC、 JMS、Simulation（ StreamBase 提供的流産生模拟器）或使用者定制。
每個 StreamBase Server 上面都會有一個 System Container，主要是産生系統監控資訊的流式資料。
HA Container 用于容錯恢複，可以看出它實際包含兩個部分： Heartbeat 和 HA Events，其中 Heartbeat 也是 Tuple 在 Container 之間傳輸。在 HA 方案下， HA Container 監控 PrimaryServer 的活動情況，然後将這些資訊轉換成為 HA Events 交給 StreamBase Monitor 來處理。
Monitor 就是從 System Container 和 HA Container 中擷取資料并進行處理。 StreamBase認為 HA 問題應該通過 CEP 方式處理，也就是說出現問題的部件肯定會反映在 SystemContainer 和 HA Container 的輸出流上面， Monitor 如果通過複雜事件處理這些 Tuples 就能夠檢測到機器故障等問題，并做出相應處理。
2、Yahoo 的 S42
Yahoo! S4（Simple Scalable Streaming System）是一個通用的、分布式的、可擴充的、分區容錯的、可插拔的流式系統 。基于 S4 架構，開發者可以容易地開發面向持續流資料處理的應用。 S4 的最新版本是 v0.6.0，是 Apache 孵化項目，其設計特點有以下幾個方面。
Actor 計算模型：為了能在普通機型構成的叢集上進行分布式處理，并且在叢集内部不使用共享記憶體， S4 架構采用了 Actor 模式，這種模式提供了封裝和位址透明語義，是以在允許應用大規模并發的同時，提供了簡單的程式設計接口。 S4 系統通過處理單元（Processing Elements， PEs）進行計算，消息在處理單元間以資料事件的形式傳送，PE 消費事件，發出一個或多個可能被其他 PE 處理的事件，或者直接釋出結果。每個PE 的狀态對于其他 PE 不可見， PE 之間唯一的互動模式就是發出事件和消費事件。
對等叢集架構： S4 采用對等架構，叢集中的所有處理節點都是等同的，沒有中心控制節點，這使得叢集的擴充性很好，處理節點的總數理論上無上限；同時， S4 沒有單點容錯的問題。
可插拔體系架構： S4 系統使用 Java 語言開發，采用了極富層次的子產品化程式設計，每個通用功能點都盡量抽象出來作為通用子產品，而且盡可能地讓各子產品實作可定制化。
支援部分容錯：基于 ZooKeeper 服務的叢集管理層會自動路由事件從失效節點到其他節點。除非顯式儲存到持久性存儲，否則節點故障時，節點上處理事件的狀态會丢失。
S4 的重要應用場景是預估點選通過率（CTR）。 CTR 是廣告點選數除以展現數得到的比率，擁有足夠曆史的展現和點選資料後， CTR是使用者點選廣告可能性的一個很好的估算，精确的來源點選對于個性化和搜尋排名來說都價值無限。據 S4 的開發者稱，線上流量上的實驗顯示基于S4系統的新CTR計算架構可以在不影響收入的前提下将 CTR 值提高 3%，這主要是通過快速檢測低品質的廣告并把它們過濾出去而獲得的收益。 S4 系統提供的低延遲處理能夠使得商務廣告部門獲益，但是潛在的風險也不能忽視，那就是事件流的速率快到一定程度後，S4可能無法處理， 會導緻事件的丢失， 如圖4所示。
圖 5 S4 在流量壓力測試下的事件丢失情況
3、Twitter 的 Storm
Twitter 的 Storm ： Storm 是一個分布式的、容錯的實時計算系統。 Storm 的用途：可用于處理消息和更新資料庫（流處理），在資料流上進行持續查詢，以流的形式傳回結果到用戶端（持續計算），并行化一個類似實時查詢的熱點查詢（分布式的 RPC）。
Storm 為分布式實時計算提供了一組通用原語，可被用于“流處理”中，實時處理消息并更新資料庫。這是管理隊列及工作者叢集的另一種方式。 Storm 也可用于“連續計算”
（ continuous computation），對資料流做連續查詢，在計算時将結果以流的形式輸出給使用者。它還用于“分布式 RPC”，以并行的方式運作昂貴的運算。
Storm 的主要特點如下：
簡單的程式設計模型。類似于 MapReduce 降低了并行批處理複雜性， Storm 降低了進行實時處理的複雜性。
可以使用各種程式設計語言。可以在 Storm 上使用各種程式設計語言。預設支援 Clojure、Java、 Ruby 和 Python。要增加對其他語言的支援，隻需實作一個簡單的 Storm 通信協定即可。
容錯性。 Storm 會管理工作程序和節點的故障。
水準擴充。計算是在多個線程、程序和伺服器之間并行進行的。
可靠的消息處理。 Storm 保證每個消息至少能得到一次完整處理。當任務失敗時，它會負責從消息源重試消息。
快速。系統的設計保證了消息能得到快速的處理，使用 ZeroMQ 作為其底層消息隊列。
本地模式。 Storm 有一個“本地模式”，可以在處理過程中完全模拟 Storm 叢集。這可以使使用者快速進行開發和單元測試。
4、Twitter 的 Rainbird
Rainbird 是一款分布式實時統計系統，可以用于實時資料的統計。
1）統計網站中每一個頁面，域名的點選次數。
2）内部系統的運作監控（統計被監控伺服器的運作狀态）。
3）記錄最大值和最小值。
Rainbird 建構在 Cassandra 上，使用 Scala 編寫，依賴于 ZooKeeper、 Scribe 和 Thrift。每秒可以寫入 10 萬個事件，而且都帶有層次結構，或者進行各種查詢，延遲小于 100ms。目前 Twitter 已經在 Promoted Tweets、微網誌中的連結、短位址、每個使用者的微網誌互動等生産環境使用了 Rainbird。其主要元件的功能如下。
ZooKeeper：是 Hadoop 子項目中的一款分布式協調系統，用于控制分布式系統中各個元件的一緻性。
Cassandra ：是 NoSQL 中一款非常出色的産品，集合了 Dynamo 和 BigTable 特性的分布式存儲系統，用于存儲需要統計的資料，并提供用戶端查詢統計資料（需要使用分布式 Counter 更新檔 CASSANDRA-1072）。
Scribe ：是 Facebook 開源的一款分布式日志收集系統，用于在系統中将各個需要統計的資料源收集到 Cassandra 中。
Thrift ：是 Facebook 開源的一款跨語言 C/S 網絡通信架構，開發人員基于該架構可以輕松地開發 C/S 應用。
5、Facebook 的 Puma
Puma 是 Facebook 的資料流處理系統，早期的處理系統如圖 1-6 所示，即二代 Puma。PTail 将資料以流的方式傳遞給 Puma 2， Puma 2 每秒需要處理百萬級的消息，處理多為Aggregation 方式的操作，遵循時間序列，涉及的複雜 Aggregation 操作諸如獨立訪次、最頻繁事件，等等。
圖 6 Puma 2 系統資料處理通路
對于每條消息， Puma 2 發送“Increment”操作到 HBase。考慮到自動負載均衡、自動容錯和寫入吞吐等因素， Puma 選擇 HBase 而不是 MySQL 作為其存儲引擎。 Puma 2的伺服器都是對等的，即同時可能有多個 Puma 2 伺服器向 HBase 中修改同一行資料。是以，Facebook 為 HBase 增加了新的功能，支援一條 Increment 操作修改同行資料的多列。
Puma 2的架構非常簡單并且易于維護，其涉及的狀态僅僅是 PTail 的 Checkpoint，即上遊資料位置周期性地存儲在 HBase中。由于是對稱結構，叢集擴容和機器故障的處理都非常友善。不過， Puma 2的缺點也很突出，首先，HBase的Increment操作是非常昂貴的，因為它涉及讀和寫，而HBase的随機讀效率比較差；另外，複雜 Aggregation 操作也不好支援，需要在 HBase上寫很多使用者代碼；再者，Puma 2在故障時會産生少量重複資料，因為 HBase的 Increment 和 PTail 的 Checkpoint 并不是一個原子操作。
但值得一提的是， Puma 并沒有開源出來，使用者可以了解和借鑒其實作原理。
6、阿裡的 JStorm
JStorm 是一個 Alibaba 開源的分布式實時計算引擎，可以認為是 Twitter Storm 的 Java版本，使用者按照指定的接口實作一個任務，然後将這個任務遞交給 JStorm 系統， JStorm 會啟動背景服務程序 7×24 小時運作，一旦某個 Worker 發生故障，排程器立即配置設定一個新的Worker 替換這個失效的 Worker。
JStorm 處理資料的方式是基于消息的流水線處理，是以特别适合無狀态計算，也就是計算單元依賴的資料全部可以在接受的消息中找到，并且最好一個資料流不依賴另外一個資料流。是以， JStorm 适用于下面的場景：
日志分析。從日志中分析出特定的資料，并将結果存入外部存儲器，如資料庫。
管道系統。将資料從一個系統傳輸到另外一個系統，如将資料庫同步到 Hadoop。
消息轉化器。将接收到的消息按照某種格式轉化，存儲到另外一個系統，如消息中間件中。
統計分析器。從日志或消息中提煉出某個字段，然後進行 COUNT 或 SUM 計算，最後将統計值存入外部存儲器。
但是， JStorm 的活躍度并不高，截至本章書寫時，整個 JStorm 項目共送出過 36 次，并且隻有 1 個 Committer，相比 Twitter Storm，不管是活躍度，還是認可度都還不是一個數量級的産品。
7、其他實時計算系統
（1） HStreaming
HStreaming 是建立在 Hadoop 上的可擴充的、可持續的資料分析系統。它可以分析、可視化并處理大量連續資料，如一個金融交易系統實時展示資料圖。 HStreaming 由 Jana Uhlig與 Volkmar Uhlig 聯合創立，該公司沒有提供相關産品的開源版本，從官網資訊來看，隻提供相關的解決方案。
HStreaming 公司嘗試為 Hadoop 環境添加一個實時的元件，當資料送出到系統，在存儲到磁盤之前會進行資料處理，類似開源的 Storm 和 Kafka。目前 HStreaming 已經建立了一個完整的系統，該系統能夠利用實時的引擎來處理視訊、伺服器、傳感器以及其他機器上生成的資料流，而且完全相容 Hadoop 作為一個歸檔和批量處理系統。
（2） Esper
Esper 是 EsperTech 公司使用 Java 開發的事件流處理（Event Stream Processing， ESP）和複雜事件處理（Complex Event Processing， CEP）引擎。 CEP 是一種實時事件處理并從大量事件資料流中挖掘複雜模式的技術。 ESP 是一種從大量事件資料流中過濾、分析有意義的事件，并能夠實時取得這些有意義的資訊的技術。該引擎可應用于網絡入侵探測、 SLA 監測、RFID 讀取、航空運輸調控、金融（風險管理、欺詐探測）等領域。 Esper 可以用在股票系統、風險監控系統等實時性要求比較高的系統中。
（3） Borealis
Borealis 是由 Brandeis University、 Brown University 和 MIT 合作開發的一個分布式流式系統，由之前的流式系統 Aurora、 Medusa 演化而來，是學術研究的一個産品， 2008 年已經停止維護。
Borealis 具有豐富的論文、完整的使用者 / 開發者文檔，系統是用 C++ 實作的，運作于x86-based Linux 平台。系統是開源的，同時使用了較多的第三方開源元件，包括用于查詢語言翻譯的 ANTLR、 C++ 的網絡程式設計架構庫 NMSTL 等。
Borealis 系統的流式模型和其他流式系統基本一緻：接受多元的資料流和輸出流，為了容錯，采用确定性計算，對于容錯性要求高的系統，會對輸入流使用算子進行定序。
8、架構對比
實時資料流計算是近年來分布式、并行計算領域研究和實踐的重點，無論是工業界，還是學術界，都誕生了多個具有代表性的資料流計算系統，用于解決實際生産問題和進行學術研究。不同的系統滿足不同應用的需求，系統并無好壞之分，關鍵在于服務的對象是誰。圖 1-7 從開發語言、高可用機制、支援精确恢複、主從架構、資源使用率、恢複時間、支援狀态持久化及支援去重等幾個方面比較了典型的 3 個資料流計算系統 Puma、 Storm 和 S4。因為 StreamBase 是廠商發行商用版本， HStreaming 隻提供解決方案，而 JStorm 和 Storm 非常相似，是以這幾種産品并沒有羅列在圖 7 中。
圖7 Puma、 Storm 和 S4 三種資料流計算系統對比
可以看到，為了高效開發，兩個系統使用 Java，另一種系統使用函數式程式設計語言Clojure ；高可用方案，有兩個系統使用 Primary Standby 方式，系統恢複時間可控，但系統複雜度增加，資源使用率也較低，因為需要一些機器來當備機；而 Storm 選擇了更簡單可行的上遊回放方式， 資源使用率高，就是恢複時間可能稍長些； Puma 和 S4 都支援狀态持久化，但 S4 目前不支援資料去重，未來可能會實作；三個系統都做不到精确恢複，即恢複後的執行結果和無故障發生時保持一緻，因為即使是 Primary Standby 方式，也隻是定期Checkpoint，并沒有跟蹤每條消息的執行。商用的 StreamBase 支援精确恢複，這主要應用于金融領域。
本文轉自大資料躺過的坑部落格園部落格，原文連結：http://www.cnblogs.com/zlslch/p/5989237.html，如需轉載請自行聯系原作者