大數(shù)據(jù)發(fā)展的下一個(gè)起點(diǎn)是快數(shù)據(jù)_數(shù)據(jù)分析師

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

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

　　-- Paul Venezia

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　尋找一套通過本地?zé)o共享集群化機(jī)制實(shí)現(xiàn)冗余與可擴(kuò)展性優(yōu)勢(shì)的系統(tǒng)方案。

　　尋找一套依靠?jī)?nèi)存內(nèi)存儲(chǔ)與處理機(jī)制以實(shí)現(xiàn)各節(jié)點(diǎn)高數(shù)據(jù)吞吐能力的系統(tǒng)方案。

　　尋找一套能夠在數(shù)據(jù)抵達(dá)的同時(shí)進(jìn)行處理的系統(tǒng)。這套系統(tǒng)能否執(zhí)行狀態(tài)邏輯？它又能否查詢GB甚至更高級(jí)別的現(xiàn)有狀態(tài)，從而為決策提供信息支持？

　　尋求一套能夠?qū)⒉煌僮鞲綦x開來，并為操作提供有力保障的系統(tǒng)方案。這樣一來，用戶就能夠編寫更為簡(jiǎn)單的代碼并將注意力集中在業(yè)務(wù)難題上——而非忙于處理并發(fā)問題或者數(shù)據(jù)分歧。需要注意，某些系統(tǒng)確實(shí)能夠提供強(qiáng)大的一致性效果，但卻會(huì)給性能造成嚴(yán)重影響。

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

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

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