大數(shù)據(jù)之所以能夠坐擁一個“大”字，主要依靠源源不斷且態(tài)勢穩(wěn)定的輸入數(shù)據(jù)流。在大容量環(huán)境之下，數(shù)據(jù)的積累速度往往十分驚人，不過其分析與存儲仍然困擾著不少用戶。

VoltDB公司軟件架構師John Hugg認為，相對于傳統(tǒng)為后續(xù)分析提供數(shù)據(jù)的簡單存儲機制，也許現(xiàn)在我們已經(jīng)步入了歷史的新階段——在這里，系統(tǒng)完全有能力利用Apache Kafka等工具在繼續(xù)保持高速數(shù)據(jù)輸入的同時實現(xiàn)分析。

– Paul Venezia

就在大約十年之前，我們還幾乎無法想象利用商用硬件對PB級別的歷史數(shù)據(jù)加以分析。然而時至今日，由成千上萬節(jié)點構成的Hadoop集群完成這項任務已經(jīng)不是什么難事。Hadoop等開源技術的出現(xiàn)幫助我們拓展了思路，得以有效處理PB乃至更高級別數(shù)據(jù)在商用及虛擬化硬件上的處理工作，并讓這種能力以低廉的成本服務世界各地的開發(fā)人員?？傮w來講，大數(shù)據(jù)業(yè)界已經(jīng)正式成型。

如今所謂快數(shù)據(jù)概念則引發(fā)了類似的一輪革新浪潮。首先，我們先為快數(shù)據(jù)下一個定義。大數(shù)據(jù)通常是由生產(chǎn)速度極高的數(shù)據(jù)所創(chuàng)建，其中包括點擊流數(shù)據(jù)、金融交易數(shù)據(jù)、日志聚合數(shù)據(jù)或者傳感器數(shù)據(jù)等。這些事件每一秒鐘往往會發(fā)生數(shù)千甚至數(shù)萬次。無怪乎人們會將這種數(shù)據(jù)類型稱為“消防水龍”。

當我們在大數(shù)據(jù)領域討論消防水龍這個話題時，計量單位并非傳統(tǒng)的GB、TB以及PB等為數(shù)據(jù)倉庫機制所熟悉的概念。我們更傾向于利用時間單位來進行計量：每秒MB數(shù)量、每小時GB數(shù)量或者每天TB數(shù)量。在討論中采取的這種速率與容量之間的差異，正好代表著大數(shù)據(jù)與數(shù)據(jù)倉庫之間的核心區(qū)別所在。大數(shù)據(jù)并不僅僅是“大”，它同時也要“快”。

一旦消防水龍中新鮮且傳輸速度極高的數(shù)據(jù)被傾倒進HDFS、分析RDBMS甚至是平面文件當中，大數(shù)據(jù)的優(yōu)勢就將消失殆盡——這是因為其“在事件發(fā)生的同時立即”執(zhí)行或者警示的能力已經(jīng)不復存在。消防水龍中噴涌而出的是活動數(shù)據(jù)、即時狀態(tài)或者正在進行當中的數(shù)據(jù)。與之相反，數(shù)據(jù)倉庫則是一種審視歷史數(shù)據(jù)以理解過去狀況從而預測未來的手段。

在數(shù)據(jù)輸入的同時進行處理一直被視為不可能完成的任務——或者至少需要極高的實施成本且有些不切實際，特別是在商用硬件之上。正如大數(shù)據(jù)中蘊藏的價值一樣，快數(shù)據(jù)的價值已經(jīng)隨著消息查詢與流系統(tǒng)的實現(xiàn)得以解鎖，而在這方面***代表性的解決方案無疑是Kafka與Storm。除此之外，開源NoSQL與NewSQL產(chǎn)品也為這類訴求提供了堅實的數(shù)據(jù)庫方案基礎。

在快數(shù)據(jù)中捕捉價值

捕捉輸入數(shù)據(jù)價值的***方式就是在信息抵達時立即作出反應及操作。如果大家以批量方式處理輸入數(shù)據(jù)，那就意味著各位已經(jīng)失去了其時效性、進而丟掉了快數(shù)據(jù)的核心價值。

為了處理每秒涌現(xiàn)的數(shù)萬乃至數(shù)百萬事件的相關數(shù)據(jù)，我們需要兩類技術作為前提：首先，一套能夠在事件抵達的同時立即進行交付的流系統(tǒng);第二，一套能夠在所有條目抵達的同時立即進行處理的數(shù)據(jù)存儲方案。

快數(shù)據(jù)的交付

在過去幾年當中，有兩套流系統(tǒng)方案獲得了市場的廣泛認同：Apache Storm與Apache Kafka。作為最初由Twitter工程技術團隊開發(fā)出的項目，Storm能夠非?？煽康靥幚砻棵胂⒘扛哌_***別的數(shù)據(jù)流。而作為由LinkedIn工程技術團隊開發(fā)出的項目，Kafka則是一套具備極高數(shù)據(jù)吞吐能力的分布式消息查詢系統(tǒng)。這兩大流系統(tǒng)方案解決了快數(shù)據(jù)處理任務的前提性難題。不過相比之下，Kafka的作用顯得更為獨特。

Kafka的設計目的在于實現(xiàn)消息查詢并打破現(xiàn)有技術在此類任務中的局限。這類似于一種立足于查詢之上而又擁有無限可擴展性的分布式部署方案，支持多租戶且持久性極強。企業(yè)用戶可以通過部署Kafka集群來滿足自身的全部消息查詢需求。不過作為項目核心，Kafka只能交付消息——也就是說，它不支持任何形式的處理或者查詢操作。

快數(shù)據(jù)的處理

消息只是解決方案的組成部分之一。傳統(tǒng)關系型數(shù)據(jù)庫往往在性能方面存在局限。其中一些能夠以極高速率實現(xiàn)數(shù)據(jù)存儲，但在接收到數(shù)據(jù)后的驗證、填充以及執(zhí)行方面卻總會栽跟頭。NoSQL系統(tǒng)已經(jīng)擁有集群化能力與出色的性能表現(xiàn)，但卻需要對傳統(tǒng)SQL系統(tǒng)所能提供的處理能力及安全性作出犧牲。對于基本的消防水龍?zhí)幚砣蝿?，NoSQL方案可能已經(jīng)足以滿足大家的業(yè)務需求。然而如果大家在事件中執(zhí)行的是復雜的查詢以及業(yè)務邏輯操作，那么只有內存內NewSQL解決方案能夠切實解決性能表現(xiàn)與事務復雜性這兩大難題。

以Kafka為代表，不少NewSQL系統(tǒng)都圍繞著無共享集群進行建立。相關負載被分布在各個集群節(jié)點當中，從而帶來理想的性能表現(xiàn)。數(shù)據(jù)會在各個集群節(jié)點之間進行復制，旨在保障其安全性與可用性。為了處理持續(xù)增長的負載量，我們能夠以透明化方式將節(jié)點添加到集群當中。各個節(jié)點可被移除(或者出現(xiàn)故障)，集群中的其它部分仍能繼續(xù)正常實現(xiàn)功能。數(shù)據(jù)庫與消息查詢機制在設計上都成功避免了單點故障的問題。這些功能也正是規(guī)?；到y(tǒng)設計方案中的典型特色。

除此之外，Kafka與一部分NewSQL系統(tǒng)有能力利用集群化與動態(tài)拓樸機制實現(xiàn)規(guī)模化，同時又不必犧牲強大的數(shù)據(jù)保障效果。Kafka提供消息序列保障，同時一部分內存內處理引擎還能夠實現(xiàn)序列化一致性與ACID語義。這些系統(tǒng)都利用集群識別客戶端來交付更多功能或者簡化配置。***，二者也都通過來自不同設備的磁盤——而非RAID或者其它邏輯存儲方案——帶來冗余耐久特性。

大數(shù)據(jù)處理工具箱

在系統(tǒng)中進行大數(shù)據(jù)消防水龍?zhí)幚頃r，我們需要尋求哪些必要的支持機制？

• 尋找一套通過本地無共享集群化機制實現(xiàn)冗余與可擴展性優(yōu)勢的系統(tǒng)方案。
• 尋找一套依靠內存內存儲與處理機制以實現(xiàn)各節(jié)點高數(shù)據(jù)吞吐能力的系統(tǒng)方案。
• 尋找一套能夠在數(shù)據(jù)抵達的同時進行處理的系統(tǒng)。這套系統(tǒng)能否執(zhí)行狀態(tài)邏輯？它又能否查詢GB甚至更高級別的現(xiàn)有狀態(tài)，從而為決策提供信息支持？
• 尋求一套能夠將不同操作隔離開來，并為操作提供有力保障的系統(tǒng)方案。這樣一來，用戶就能夠編寫更為簡單的代碼并將注意力集中在業(yè)務難題上——而非忙于處理并發(fā)問題或者數(shù)據(jù)分歧。需要注意，某些系統(tǒng)確實能夠提供強大的一致性效果，但卻會給性能造成嚴重影響。

具備這些特性的系統(tǒng)正在NewSQL、NoSQL以及Hadoop業(yè)界當中不斷涌現(xiàn)，但不同的系統(tǒng)方案也擁有各自的權衡考量——這往往與開發(fā)者的初始假設關系密切。對于那些希望以實時方式處理快數(shù)據(jù)的企業(yè)來說，這些工具能夠有效解決快速理解數(shù)據(jù)內容時面臨的復雜性難題。

Kafka帶來了一種安全及具備高可用性的處理方式，能夠有效實現(xiàn)數(shù)據(jù)在無數(shù)生產(chǎn)者與消費者之間的移動，同時也為管理者提供卓越的性能與穩(wěn)健性。內存內數(shù)據(jù)庫則可以提供一套完整的關系型引擎，其具備強大的事務型邏輯、計數(shù)與聚合能力，并擁有足以滿足任何負載的出色可擴展性。與關系型數(shù)據(jù)庫不同，這類系統(tǒng)應當被作為與Kafka通訊基礎設施相配套的處理引擎。

無論企業(yè)用戶的實際需求如何，這些工具都表現(xiàn)出了幫助我們以更快速度了解更多數(shù)據(jù)信息的能力，而且往往能夠全面替代更為孱弱或者其它類型的系統(tǒng)方案。