大資料之所以能夠坐擁一個“大”字，主要依靠源源不斷且態勢穩定的輸入資料流。在大容量環境之下，資料的積累速度往往十分驚人，不過其分析與儲存仍然困擾著不少使用者。
VoltDB公司軟體架構師John Hugg認為，相對於傳統為後續分析提供資料的簡單儲存機制，也許現在我們已經步入了歷史的新階段——在這裡，系統完全有能力利用Apache Kafka等工具在繼續保持高速資料輸入的同時實現分析。 -- Paul Venezia
就在大約十年之前，我們還幾乎無法想象利用商用硬體對PB級別的歷史資料加以分析。然而時至今日，由成千上萬節點構成的Hadoop叢集完成這項任務已經不是什麼難事。Hadoop等開源技術的出現幫助我們擴充了思路，得以有效處理PB乃至更高階別資料在商用及虛擬化硬體上的處理工作，並讓這種能力以低廉的成本服務世界各地的開發人員。總體來講，大資料業界已經正式成型。
如今所謂快資料概念則引發了類似的一輪革新浪潮。首先，我們先為快資料下一個定義。大資料通常是由生產速度極高的資料所建立，其中包括點選流資料、金融交易資料、日誌聚合資料或者感測器資料等。這些事件每一秒鐘往往會發生數千甚至數萬次。無怪乎人們會將這種資料型別稱為“消防水龍”。
當我們在大資料領域討論消防水龍這個話題時，計量單位並非傳統的GB、TB以及PB等為資料倉儲機制所熟悉的概念。我們更傾向於利用時間單位來進行計量：每秒MB數量、每小時GB數量或者每天TB數量。在討論中採取的這種速率與容量之間的差異，正好代表著大資料與資料倉儲之間的核心區別所在。大資料並不僅僅是“大”：它同時也要“快”。
一旦消防水龍中新鮮且傳輸速度極高的資料被傾倒進HDFS、分析RDBMS甚至是平面檔案當中，大資料的優勢就將消失殆盡——這是因為其“在事件發生的同時立即”執行或者警示的能力已經不復存在。消防水龍中噴湧而出的是活動資料、即時狀態或者正在進行當中的資料。與之相反，資料倉儲則是一種審視歷史資料以理解過去狀況從而預測未來的手段。
在資料輸入的同時進行處理一直被視為不可能完成的任務——或者至少需要極高的實施成本且有些不切實際，特別是在商用硬體之上。正如大資料中蘊藏的價值一樣，快資料的價值已經隨著訊息查詢與流系統的實現得以解鎖，而在這方面最具代表性的解決方案無疑是Kafka與Storm。除此之外，開源NoSQL與NewSQL產品也為這類訴求提供了堅實的資料庫方案基礎。
在快資料中捕捉價值
捕捉輸入資料價值的最佳方式就是在資訊抵達時立即作出反應及操作。如果大家以批量方式處理輸入資料，那就意味著各位已經失去了其時效性、進而丟掉了快資料的核心價值。
為了處理每秒湧現的數萬乃至數百萬事件的相關資料，我們需要兩類技術作為前提：首先，一套能夠在事件抵達的同時立即進行交付的流系統;第二，一套能夠在所有條目抵達的同時立即進行處理的資料儲存方案。
快資料的交付
在過去幾年當中，有兩套流系統方案獲得了市場的廣泛認同：Apache Storm與Apache Kafka。作為最初由Twitter工程技術團隊開發出的專案，Storm能夠非常可靠地處理每秒訊息量高達百萬級別的資料流。而作為由LinkedIn工程技術團隊開發出的專案，Kafka則是一套具備極高資料吞吐能力的分散式訊息查詢系統。這兩大流系統方案解決了快資料處理任務的前提性難題。不過相比之下，Kafka的作用顯得更為獨特。
Kafka的設計目的在於實現訊息查詢並打破現有技術在此類任務中的侷限。這類似於一種立足於查詢之上而又擁有無限可擴充套件性的分散式部署方案，支援多租戶且永續性極強。企業使用者可以通過部署Kafka叢集來滿足自身的全部訊息查詢需求。不過作為專案核心，Kafka只能交付訊息——也就是說，它不支援任何形式的處理或者查詢操作。
快資料的處理
訊息只是解決方案的組成部分之一。傳統關係型資料庫往往在效能方面存在侷限。其中一些能夠以極高速率實現資料儲存，但在接收到資料後的驗證、填充以及執行方面卻總會栽跟頭。NoSQL系統已經擁有叢集化能力與出色的效能表現，但卻需要對傳統SQL系統所能提供的處理能力及安全性作出犧牲。對於基本的消防水龍處理任務，NoSQL方案可能已經足以滿足大家的業務需求。然而如果大家在事件中執行的是複雜的查詢以及業務邏輯操作，那麼只有記憶體內NewSQL解決方案能夠切實解決效能表現與事務複雜性這兩大難題。
以Kafka為代表，不少NewSQL系統都圍繞著無共享叢集進行建立。相關負載被分佈在各個叢集節點當中，從而帶來理想的效能表現。資料會在各個叢集節點之間進行復制，旨在保障其安全性與可用性。為了處理持續增長的負載量，我們能夠以透明化方式將節點新增到叢集當中。各個節點可被移除（或者出現故障），叢集中的其它部分仍能繼續正常實現功能。資料庫與訊息查詢機制在設計上都成功避免了單點故障的問題。這些功能也正是規模化系統設計方案中的典型特色。
除此之外，Kafka與一部分NewSQL系統有能力利用叢集化與動態拓樸機制實現規模化，同時又不必犧牲強大的資料保障效果。Kafka提供訊息序列保障，同時一部分記憶體內處理引擎還能夠實現序列化一致性與ACID語義。這些系統都利用叢集識別客戶端來交付更多功能或者簡化配置。最後，二者也都通過來自不同裝置的磁碟——而非RAID或者其它邏輯儲存方案——帶來冗餘耐久特性。
大資料處理工具箱
在系統中進行大資料消防水龍處理時，我們需要尋求哪些必要的支援機制？
- 尋找一套通過本地無共享叢集化機制實現冗餘與可擴充套件性優勢的系統方案。
- 尋找一套依靠記憶體記憶體儲與處理機制以實現各節點高資料吞吐能力的系統方案。
- 尋找一套能夠在資料抵達的同時進行處理的系統。這套系統能否執行狀態邏輯？它又能否查詢GB甚至更高階別的現有狀態，從而為決策提供資訊支援？
- 尋求一套能夠將不同操作隔離開來，併為操作提供有力保障的系統方案。這樣一來，使用者就能夠編寫更為簡單的程式碼並將注意力集中在業務難題上——而非忙於處理併發問題或者資料分歧。需要注意，某些系統確實能夠提供強大的一致性效果，但卻會給效能造成嚴重影響。
具備這些特性的系統正在NewSQL、NoSQL以及Hadoop業界當中不斷湧現，但不同的系統方案也擁有各自的權衡考量——這往往與開發者的初始假設關係密切。對於那些希望以實時方式處理快資料的企業來說，這些工具能夠有效解決快速理解資料內容時面臨的複雜性難題。
Kafka帶來了一種安全及具備高可用性的處理方式，能夠有效實現資料在無數生產者與消費者之間的移動，同時也為管理者提供卓越的效能與穩健性。記憶體內資料庫則可以提供一套完整的關係型引擎，其具備強大的事務型邏輯、計數與聚合能力，並擁有足以滿足任何負載的出色可擴充套件性。與關係型資料庫不同，這類系統應當被作為與Kafka通訊基礎設施相配套的處理引擎。
無論企業使用者的實際需求如何，這些工具都表現出了幫助我們以更快速度瞭解更多資料資訊的能力，而且往往能夠全面替代更為孱弱或者其它型別的系統方案。
英文：http://www.infoworld.com/t/big-data/fast-data-the-next-step-after-big-data-244102