大數據之所以能夠坐擁一個“大”字，主要依靠源源不斷且態勢穩定的輸入數據流。在大容量環境之下，數據的積累速度往往十分驚人，不過其分析與存儲仍然困擾着不少用戶。
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