Storm 并非完全適合所有實時應用

流數據的迅速崛起帶來了一類全新的應用開發技術。為了應對不斷增長的數據（如物聯網和機器通信產生的大量數據），同時，利用實時個性化技術改進在線 用戶體驗，越來越多的應用開發引入了流數據技術。對于流數據應用的定義多種多樣，但都包含三個基本功能：實時數據采集，實時分析和自動化決策。

流處理的解決方案也可以采取多種形式。通常其體系結構包含：tuple-at-a-time流處理工具（又名復雜事件處理工具）；面向批處理的流處 理技術，是對靈活性和健壯性的折中方案；內存數據庫，強調業務的實時性。雖然這些方法可以解決許多問題，但是就開發量、維護開銷、存儲容量、性能而言，這 些方法存在很大差異。需要注意的是，了解需要用多少組件來實現你需要的功能是十分重要的。開發、測試、運營一個系統的工作量取決于需要整合在一起的組件的 數量。

舉個例子：Apache Stor m 是最流行的為開發者用于流式應用的工具之一，但是一個使用storm的流式處理方案通常不僅僅需要storm。正如我在上一篇文章中 討論到的，Storm通常使用Kafka用于數據采集，而Storm和Kafka都需要Zookeeper用于管理狀態。最后，如我下面討論到的，還需要 第四個系統用于管理狀態。最終，當所有工作完成后，一個3結點（指計算節點）的Storm集群會很輕易地掉消耗12個結點！

Apache Storm和快速數據應用

Apache Storm 是一個能近實時地在數據之上運行用戶代碼片段的流式數據處理框架。它實際上是一系列連在一起的管道。本質上開發者在運行中間部分（指Storm的管道）的代碼時，他們將輸入數據源和后端數據存儲連接起來。Storm的延時比基于Hadoop的系統更接近CEP（復雜事件處理）。它提供的通過書寫簡單代碼處理事件，將更多背景交給框架處理的特性，對于有時間修修補補的開發者來說很有吸引力。

Storm 通常用于簡單的分析任務， 諸如計算，以及清洗，使其常規化，并且準備攝入用于長期存儲的數據。然而，Storm 不能夠有狀態操作，這對于進行實時決策非常重要。狀態數據的分析正處于快速數據應用程序的中心，諸如：個性化，客戶參與，推薦引擎，報警，授權與政策執 行。無需諸如 Zookeeper與 Cassandra 之類的額外組件，Storm 不能查找維度數據，更新匯總，或者直接作用于一個事件（那就是，對實時進行決策）。

這些實例就是一個更廣泛有關“快”的數據應用程序的類的一部分。開發人員意識到認識的價值和作用于實時數據，并且快速的數據工具正充實著簡單的流媒體方式和傳統的分析賣場實現價值。考慮問題并且不涉及技術，什么是一個快速應用程序共同的主題呢？

首先，它們都要讀入數據，比如日志記錄，傳感器記錄，財務票據，點擊流，在線行為觸發等等。這些數據來得比消防龍頭噴的水還快，快速數據處理系統必須要能流暢讀入這些數據。

然后就是實時解析讀入進來的數據。在這之前，某些系統可以讀入一個流然后提交給 OLAP 系統處理，這樣的處理有可能耗時過長，起不到實時的作用。而快速數據處理系統則通過事件模型來處理讀入數據，同時拉取已有數據（比方維度表或歷史表）來進 行處理。系統可以將信息展示出來或發送一個提醒，讓相關的人員來做決定；但更合適的做法是讓系統自動來處理——比如“當X類型的用戶滿足Y條件時，執行策略Z”。

最后，快速數據處理要和大數據相集成。我們有一個基礎假設，就是數據都是有生命周期的。實時數據交給快速數據處理系統來處理，而像機器學習、回歸測試和歷 史查詢這樣的深度分析，則交給 OLAP 或基于 Hadoop/HDFS 的系統去做。這種情況下，快速數據處理系統不但將擴充后的數據提交給深度分析系統，同時也接收深度分析系統的處理結果，比如規則學習引擎生成的一條規則。

要想理解 Storm 在整個快速數據處理系統中的角色，最簡單的就是看它自身能處理哪些問題，以及它把哪些問題丟給開發者解決。Storm 框架的設計目標是以一種可以自由水平擴展并具有一定容錯性的方式，將數據從數據源提交給用戶處理。它對于輸入數據可以是“最多一次”或“最少一次”的處理 方式，如果處理失敗，它也可以再度重試。

對持久化狀態的認識明顯是不足的。由于各種各樣的原因，高速數據應用需要對狀態進行記錄。保留之前看到的元組信息，可以是未經處理的生數據，也可以是經過 聚合的數據，都能夠幫助處理引擎找到數據中蘊藏的模式。在進行任何分析之前，獲取更多維度的數據有助于豐富這些元組數據，來進行更廣泛的概括和分析。通常 來說，最終決策取決于這些持久儲存的動態規則。

Storm在這個問題上失誤了，它讓開發者自己管理對持久狀態的訪問。在Storm中有兩種訪問持久狀態的方法。第一種是，在Storm中每個工作過程都 能夠通過增加本地第三方存儲來存儲自己的狀態。Memcached和Redis是如今非常流行的本地存儲解決方案。增加本地存儲使得每個狀態的數據元組能 夠顧忌之前的數據元組，這樣，整個工作過程就變得一目了然了。但是這種“自我構建”的方法有它的負面效果：它無法集成到Storm的容錯代碼機制當中。 Storm必須通過在一個正在運行的機器上重啟工作過程并將數據元組從之前的作業遷移到新的工作過程中，來處理運行失敗的工作過程或出錯的硬件問題。這種 遷移不包含任何本地狀態，無論它是駐留在這個過程中，還是在像Memcached這樣的系統中。新的工作過程將失去失敗作業中所有的上下文信息。

并且，也很難甚至不可能直接查詢那些分散在所有工作進程中的分布式狀態。如果每個進程想要一直聚集統計，這些統計數據必須推到另一個系統，使用強大 查詢工具進行查詢。使用Storm的分布式RPC（遠程過程調用）功能來對一些數據進行直接抓取也許是可行的。但是，與如今的SQL和NoSQL數據存儲 技術的查詢功能相比，這些數據獲取的功能被嚴格限制了。
第二種訪問狀態的方法是將Storm的工作進程連接到一個集中式的或者分布式的持久化存儲 當中，例如Cassandra或HBase。采用這種方法，Storm的處理代碼能夠訪問GB或者TB級別的狀態信息，并且能夠簡單地、獨立地從 Storm系統中查詢持久化存儲的數據。這解決了本地化存儲的如上問題：狀態不能在喚醒失敗進程后重建，并且存儲可能以后將要支持更強大的查詢。雖然該方 法解決了這些問題，但它大大增加了復雜性，并帶來了可靠性的問題。

值得注意的是，Storm 與分離存儲結合可能會削弱性能。在內存中處理元組是很容易達到以驚人的速度。為了方便查詢冗余狀態而使用索引來維護其存儲，同時盡可能提供一致性保證，要 付出更多的代價。Storm 系統將被分布式存儲的性能所制約。如果處理每個元組時使用外部存儲來查詢，會造成大量的網絡延遲。隱藏這種延遲需要更多的并行性，更多的管理，意味著更多 的復雜性。而現在你可能會有兩個系統可能失敗。

當分布式存儲不可用時，Storm 的工作進程需要處理，這無疑增加來了復雜性。如果這是可能的，即使沒有復雜的用戶代碼，當在 Storm 中使用至少一次語義的時候，開發著也需要在分布式存儲中使用至少一次語義。

SQL拓展和快速數據處理

在當今的存儲中，兼容ACID，SQL關系型數據庫能夠比Sorm和其它可代替產品更簡單和容易地運行以前不能運行的應用。伴有ACID事務關系型數據庫簡化數據獲取在至多一次或至少一次語義的的時候是有要求的。因為操作是簡單的,要么完全完成或回滾。

大 多數關系型數據庫允許數據庫托管，事務邏輯：一些甚至允許使用java代碼，像Storm。因此，Storm在使用關系型的系統中提供更多的邏輯與靈活 性。但是不像在Storm中，在一個有著直接并且精心安排的路徑狀態數據的關系型數據庫中，消除出現在混合Storm和一個分布或分區的持久性存儲中問 題。

既然已經有了像PostgreSQL這種數據庫存儲系統，Nathan Marz為什么要創造Storm呢？因為PostgreSQL及其分支既不是橫向可擴展的，也沒有像Storm那樣處理元組數據的吞吐量。但是最近五年一些新的項目進入事務性存儲領域，致力于橫向擴展、容錯和原始吞吐量。這些系統方案有著和Storm一樣的擴展性和容錯性，并在處理時結合直接的狀態操作提供了強大的處理事務語義的功能。

總之，這些新平臺提供了Storm的處理流程和邏輯，Cassandra的狀態能力，Kafka的攝入語義等。更重要的是，一個分布式的，事務性的（ACID），SQL關系型數據庫能夠每秒處理成千上萬個輸入的事務或應用請求。

對于數據快速增長的應用，開發者們仍在尋求一個比 Storm 和其他流處理方案更完整的流處理平臺。Storm 需要一個伙伴數據庫去處理它所產出的任何分析內容。相比之下，對比已經有一定規模的SQL數據庫，開發者可以從數據庫中直接進行計算、存儲并做實時的查詢 分析。

Storm 的數據提取管道中的過濾器，enrich 以及組輸入事件流都需要訪問查找數據以及額外的輸入事件源。Storm 需要伙伴數據庫來進行數據的存儲和查找。不符合開發者們數據快速增長應用的需求。一個分布式、內存型的關系數據庫提供了一套更適用于數據快速增長場景下的 更簡單、強大、互動性的解決案例。

John Hugg，VoltDB 的高級架構師，工作生涯主要致力于數據庫和信息管理。做為VoltDB產品化的第一個工程師，他聯絡著麻省理工學院的學者、耶魯大學的團隊、H- Store 以及 VoltDB 的研究原型。John 還幫助 VoltDB 建立了世界一流的工程團隊繼續開發開源和商業產品。