分析：大數(shù)據(jù)漫談唯快不破

分析：大數(shù)據(jù)漫談，唯快不破

話說道哥(DougLaney)當(dāng)年創(chuàng)立三V經(jīng)，背景是電子商務(wù)：Velocity衡量的是用戶“交互點(diǎn)”(Point-of-Interaction)，如網(wǎng)站響應(yīng)速度、訂單完成速度、產(chǎn)品和服務(wù)的交付速度等。假設(shè)交互點(diǎn)是一個黑盒子，一邊吸入數(shù)據(jù)，經(jīng)過黑盒子處理后，在另一邊流出價(jià)值，那Velocity指的是吸入、處理和產(chǎn)生價(jià)值的快速度。隨后“快”進(jìn)入了企業(yè)運(yùn)營、管理和決策智能化的每一個環(huán)節(jié)，于是大家看到了形形色色描述“快”的文字用在商業(yè)數(shù)據(jù)語境里，例如real-time(實(shí)時)，lightningfast(快如閃電的)，speedoflight(光速)，speedofthought(念動的瞬間)，TimetoValue(價(jià)值送達(dá)時間)，等等。本篇試圖討論“快”的四個問題：*為什么要“快”？*“快”的數(shù)據(jù)和處理模型*怎么實(shí)現(xiàn)“快”？*“快”的代價(jià)是什么？為什么要“快”?“快”，來自幾個樸素的思想：1)時間就是金錢。時間在分母上，越小，單位價(jià)值就越大。面臨同樣大的數(shù)據(jù)礦山，“挖礦”效率是競爭優(yōu)勢。Zara與H&M有相似的大數(shù)據(jù)供應(yīng)，Zara勝出的原因毫無疑問就是“快”。2)像其它商品一樣，數(shù)據(jù)的價(jià)值會折舊。過去一天的數(shù)據(jù)，比過去一個月的數(shù)據(jù)可能都更有價(jià)值。更普遍意義上，它就是時間成本的問題：等量數(shù)據(jù)在不同時間點(diǎn)上價(jià)值不等。NewSQL的先行者VoltDB發(fā)明了一個概念叫做DataContinuum：數(shù)據(jù)存在于一個連續(xù)時間軸(timecontinuum)上，每一個數(shù)據(jù)項(xiàng)都有它的年齡，不同年齡的數(shù)據(jù)有不同的價(jià)值取向，“年輕”(最近)時關(guān)注個體的價(jià)值，“年長”(久遠(yuǎn))時著重集合價(jià)值。3)數(shù)據(jù)跟新聞和金融行情一樣，具有時效性。炒股軟件免費(fèi)版給你的數(shù)據(jù)有十幾秒的延遲，這十幾秒是快速獵食者宰割散戶的機(jī)會；而華爾街大量的機(jī)構(gòu)使用高頻機(jī)器交易(70%的成交量來自高頻交易)，能發(fā)現(xiàn)微秒級交易機(jī)會的吃定毫秒級的。物聯(lián)網(wǎng)這塊，很多傳感器的數(shù)據(jù)，產(chǎn)生幾秒之后就失去意義了。美國國家海洋和大氣管理局的超級計(jì)算機(jī)能夠在日本地震后9分鐘計(jì)算出海嘯的可能性，但9分鐘的延遲對于瞬間被海浪吞噬的生命來說還是太長了。大家知道，購物籃分析是沃爾瑪橫行天下的絕技，其中最經(jīng)典的就是關(guān)聯(lián)產(chǎn)品分析：從大家耳熟能詳?shù)摹捌【萍幽虿肌保斤Z風(fēng)來臨時的“餡餅(pop-tarts)加手電筒”和“餡餅加啤酒”?？墒?，此“購物籃”并非顧客拎著找貨的那個，而是指你買完帳單上的物品集合。對于快消品等有定期消費(fèi)規(guī)律的產(chǎn)品來說，這種“購物籃”分析尚且有效，但對絕大多數(shù)商品來說，找到顧客“觸點(diǎn)(touchpoints)”的最佳時機(jī)并非在結(jié)帳以后，而是在顧客還領(lǐng)著籃子掃街逛店的正當(dāng)時。電子商務(wù)具備了這個能力，從點(diǎn)擊流(clickstream)、瀏覽歷史和行為(如放入購物車)中實(shí)時發(fā)現(xiàn)顧客的即時購買意圖和興趣。這就是“快”的價(jià)值。那傳統(tǒng)零售業(yè)是不是只能盯著購物清單和顧客遠(yuǎn)去的背影望“快”興嘆了呢？也不見得，我有空時會寫一篇小文“O4O：OnlineforOffline”專門寫傳統(tǒng)零售業(yè)怎么部署數(shù)據(jù)實(shí)時采集和分析技術(shù)突破困局?！翱臁钡臄?shù)據(jù)和處理模型設(shè)想我們站在某個時間點(diǎn)上，背后是靜靜躺著的老數(shù)據(jù)，面前是排山倒海撲面而來的新數(shù)據(jù)。前文講過，數(shù)據(jù)在爆炸性產(chǎn)生。在令人窒息的數(shù)據(jù)海嘯面前，我們的數(shù)據(jù)存儲系統(tǒng)如同一個小型水庫，而數(shù)據(jù)處理系統(tǒng)則可以看作是水處理系統(tǒng)。數(shù)據(jù)涌入這個水庫，如果不能很快處理，只能原封不動地排出。對于數(shù)據(jù)擁有者來說，除了付出了存儲設(shè)備的成本，沒有收獲任何價(jià)值。如上圖所示，按照數(shù)據(jù)的三狀態(tài)定義，水庫里一平如鏡(非活躍)的水是“靜止數(shù)據(jù)(dataatrest)”，水處理系統(tǒng)中上下翻動的水是“正使用數(shù)據(jù)(datainuse)”，洶涌而來的新水流就是“動態(tài)數(shù)據(jù)(datainmotion)”?！翱臁闭f的是兩個層面：一個是“動態(tài)數(shù)據(jù)”來得快。動態(tài)數(shù)據(jù)有不同的產(chǎn)生模式。有的是burst模式，極端的例子如歐洲核子研究中心(CERN)的大型強(qiáng)子對撞機(jī)(LargeHadronCollider，簡稱LHC)，此機(jī)不撞則已，一撞驚人，工作狀態(tài)下每秒產(chǎn)生PB級的數(shù)據(jù)。也有的動態(tài)數(shù)據(jù)是涓涓細(xì)流的模式，典型的如clickstream，日志，RFID數(shù)據(jù)，GPS位置信息，Twitter的firehose流數(shù)據(jù)等。二是對“正使用數(shù)據(jù)”處理得快。水處理系統(tǒng)可以從水庫調(diào)出水來進(jìn)行處理(“靜止數(shù)據(jù)”轉(zhuǎn)變?yōu)椤罢褂脭?shù)據(jù)”)，也可以直接對涌進(jìn)來的新水流處理(“動態(tài)數(shù)據(jù)”轉(zhuǎn)變?yōu)椤罢褂脭?shù)據(jù)”)。這對應(yīng)著兩種大相迥異的處理范式：批處理和流處理。如下圖所示，左半部是批處理：以“靜止數(shù)據(jù)”為出發(fā)點(diǎn)，數(shù)據(jù)是任爾東西南北風(fēng)、我自巋然不動，處理邏輯進(jìn)來，算完后價(jià)值出去。Hadoop就是典型的批處理范式：HDFS存放已經(jīng)沉淀下來的數(shù)據(jù)，MapReduce的作業(yè)調(diào)度系統(tǒng)把處理邏輯送到每個節(jié)點(diǎn)進(jìn)行計(jì)算。這非常合理，因?yàn)榘釀訑?shù)據(jù)比發(fā)送代碼更昂貴。右半部則是流數(shù)據(jù)處理范式。這次不動的是邏輯，“動態(tài)數(shù)據(jù)”進(jìn)來，計(jì)算完后價(jià)值留下，原始數(shù)據(jù)加入“靜止數(shù)據(jù)”，或索性丟棄。流處理品類繁多，包括傳統(tǒng)的消息隊(duì)列(絕大多數(shù)的名字以MQ結(jié)尾)，事件流處理(EventStreamProcessing)/復(fù)雜事件處理(ComplexEventProcessing或CEP)(如Tibco的BusinessEvents和IBM的InfoStreams)，分布式發(fā)布/訂閱系統(tǒng)(如Kafka)，專注于日志處理的(如Scribe和Flume)，通用流處理系統(tǒng)(如Storm和S4)等。這兩種范式與我們?nèi)粘Ｉ钪械膬煞N信息處理習(xí)慣相似：有些人習(xí)慣先把信息存下來(如書簽、ToDo列表、郵箱里的未讀郵件)，稍后一次性地處理掉(也有可能越積越多，舊的信息可能永遠(yuǎn)不會處理了)；有些人喜歡任務(wù)來一件做一件，信息來一點(diǎn)處理一點(diǎn)，有的直接過濾掉，有的存起來。沒有定規(guī)說哪種范式更好，對于burst數(shù)據(jù)，多數(shù)是先進(jìn)入存儲系統(tǒng)，然后再來處理，因此以批處理范式為主；而對于流數(shù)據(jù)，多采用流范式。傳統(tǒng)上認(rèn)為流處理的方式更快，但流范式能處理的數(shù)據(jù)常常局限于最近的一個數(shù)據(jù)窗口，只能獲得實(shí)時智能(real-timeintelligence)，不能實(shí)現(xiàn)全時智能(all-timeintelligence)。批處理擅長全時智能，但翻江倒海搗騰數(shù)據(jù)肯定慢，所以亟需把批處理加速。兩種范式常常組合使用，而且形成了一些定式：*流處理作為批處理的前端：比如前面大型強(qiáng)子對撞機(jī)的例子，每秒PB級的數(shù)據(jù)先經(jīng)過流處理范式進(jìn)行過濾，只有那些科學(xué)家感興趣的撞擊數(shù)據(jù)保留下來進(jìn)入存儲系統(tǒng)，留待批處理范式處理。這樣，歐洲核子研究中心每年的新增存儲存儲量可以減到25PB。*流處理與批處理肩并肩：流處理負(fù)責(zé)動態(tài)數(shù)據(jù)和實(shí)時智能，批處理負(fù)責(zé)靜止數(shù)據(jù)和歷史智能，實(shí)時智能和歷史智能合并成為全時智能。怎么實(shí)現(xiàn)“快”？涉及到實(shí)現(xiàn)，這是個技術(shù)話題，不喜可略。首先，“快”是個相對的概念，可以是實(shí)時，也可以秒級、分鐘級、小時級、天級甚至更長的延遲。實(shí)現(xiàn)不同級別的“快”采用的架構(gòu)和付出的代價(jià)也不一樣。所以對于每一個面臨“快”問題的決策者和架構(gòu)師來說，第一件事情就是要搞清楚究竟要多“快”?！翱臁睙o止境，找到足夠“快”的那個點(diǎn)，那就夠了。其次，考慮目前的架構(gòu)是不是有潛力改造到足夠“快”。很多企業(yè)傳統(tǒng)的關(guān)系型數(shù)據(jù)庫中數(shù)據(jù)量到達(dá)TB級別，就慢如蝸牛了。在轉(zhuǎn)向新的架構(gòu)(如NoSQL數(shù)據(jù)庫)之前，可以先考慮分庫分表(sharding)和內(nèi)存緩存服務(wù)器(如memcached)等方式延長現(xiàn)有架構(gòu)的生命。如果預(yù)測未來數(shù)據(jù)的增長必將超出現(xiàn)有架構(gòu)的上限，那就要規(guī)劃新的架構(gòu)了。這里不可避免要選擇流處理結(jié)構(gòu)，還是批處理結(jié)構(gòu)，抑或兩者兼具。Intel有一位老法師說：anybigdataplatformneedstobearchitectedforparticularproblems(任何一個大數(shù)據(jù)平臺都需要為特定的問題度身定做)。在下不能同意更多。為什么呢？比如說大方向決定了要用流處理架構(gòu)，我們前面列舉了很多品類，落實(shí)到具體產(chǎn)品少說上百種，所以要選擇最適合的流處理產(chǎn)品。再看批處理架構(gòu)，MapReduce也不能包打天下，碰到多迭代、交互式計(jì)算就無能為力了；NoSQL更是枝繁葉茂，有名有姓的NoSQL數(shù)據(jù)庫好幾十種。這時候請一個好的大數(shù)據(jù)咨詢師很重要(這也是我在這里說大數(shù)據(jù)咨詢服務(wù)有前景的原因)?？傮w上講，還是有一些通用的技術(shù)思路來實(shí)現(xiàn)“快”：1)如果數(shù)據(jù)流入量太大，在前端就地采用流處理進(jìn)行即時處理、過濾掉非重要數(shù)據(jù)。前段時間王堅(jiān)把大數(shù)據(jù)和無人機(jī)扯一塊，這無人機(jī)還真有個流處理的前端。它以每秒幾幀的速度處理視頻，實(shí)時匹配特殊形狀(如坦克)和金屬反光(武器)，同時把處理過的無用視頻幀幾乎全扔了。2)把數(shù)據(jù)預(yù)處理成適于快速分析的格式。預(yù)處理常常比較耗時，但對不常改動的惰性數(shù)據(jù)，預(yù)處理的代價(jià)在長期的使用中可以忽略不計(jì)。谷歌的Dremel，就是把只讀的嵌套數(shù)據(jù)轉(zhuǎn)成類似于列式數(shù)據(jù)庫的形式，實(shí)現(xiàn)了PB級數(shù)據(jù)的秒級查詢。3)增量計(jì)算--也即先顧眼前的新數(shù)據(jù)，再去更新老數(shù)據(jù)。對傳統(tǒng)的批處理老外叫做reboiltheocean，每次計(jì)算都要翻江倒海把所有數(shù)據(jù)都搗騰一遍，自然快不了。而增量計(jì)算把當(dāng)前重點(diǎn)放在新數(shù)據(jù)上，先滿足“快”；同時抽空把新數(shù)據(jù)(或新數(shù)據(jù)里提煉出來的信息)更新到老數(shù)據(jù)(或歷史信息庫)中，又能滿足“全”。谷歌的Web索引自2010年起從老的MapReduce批量系統(tǒng)升級成新的增量索引系統(tǒng)，能夠極大地縮短網(wǎng)頁被爬蟲爬到和被搜索到之間的延遲。我們前面說的“流處理和批處理肩并肩”也是一種增量計(jì)算。4)很多批處理系統(tǒng)慢的根源是磁盤和I/O，把原始數(shù)據(jù)和中間數(shù)據(jù)放在內(nèi)存里，一定能極大地提升速度。這就是內(nèi)存計(jì)算(In-memorycomputing)。內(nèi)存計(jì)算最簡單的形式是內(nèi)存緩存，F(xiàn)acebook超過80%的活躍數(shù)據(jù)就在memcached里。比較復(fù)雜的有內(nèi)存數(shù)據(jù)庫和數(shù)據(jù)分析平臺，如SAP的HANA，NewSQL的代表VoltDB和伯克利的開源內(nèi)存計(jì)算框架Spark(Intel也開始參與)。斯坦福的JohnOusterhout(Tcl/Tk以及集群文件系統(tǒng)Lustre的發(fā)明者)搞了個更超前的RAMCloud，號稱所有數(shù)據(jù)只生活在內(nèi)存里。未來新的非易失性內(nèi)存(斷電數(shù)據(jù)不會丟失)會是個gamechanger。Facebook在3月宣布了閃存版的Memcached，叫McDipper，比起單節(jié)點(diǎn)容量可以提升20倍，而吞吐量仍能達(dá)到每秒數(shù)萬次操作。另一種非易失性內(nèi)存，相變內(nèi)存(PhaseChangeMemory)，在幾年內(nèi)會商用，它的每比特成本可以是DRAM的1/10，性能比DRAM僅慢2-10倍，比現(xiàn)今的閃存(NAND)快500倍，壽命長100倍。除內(nèi)存計(jì)算外，還有其它的硬件手段來加速計(jì)算、存儲和數(shù)據(jù)通訊，如FPGA(IBM的Netezza和Convey的Hybrid-Core)，SSD和閃存卡(SAPHANA和FusionIO)，壓縮PCIe卡，更快和可配置的互聯(lián)(Infiniband的RDMA和SeaMicroSM15000的FreedomFabrics)等。此處不再細(xì)表。5)降低對精確性的要求。大體量、精確性和快不可兼得，頂多取其二。如果要在大體量數(shù)據(jù)上實(shí)現(xiàn)“快”，必然要適度地降低精確性。對數(shù)據(jù)進(jìn)行采樣后再計(jì)算就是一種辦法，伯克利BlinkDB通過獨(dú)特的采用優(yōu)化技術(shù)實(shí)現(xiàn)了比Hive快百倍的速度，同時能把誤差控制在2-10%?！翱臁钡拇鷥r(jià)是什么？這世界上沒有免費(fèi)的午餐，實(shí)現(xiàn)了“快”必然要付出代價(jià)。要么做加法，增加硬件投入、改變架構(gòu)設(shè)計(jì)；要么做減法，降低精確性、忍受實(shí)時但非全時的智能。其實(shí)，這個好比看報(bào)紙，時報(bào)、日報(bào)信息快，需要采編投入，但因?yàn)槎虝r間內(nèi)所能獲得信息的局限性，缺乏深度和全景式的文章；周報(bào)、月刊則反之?！翱臁焙苜F。有些行業(yè)，肯定是越快越好的，比如說金融領(lǐng)域，所以他們愿意買貴得離譜的SAPHANA或IBMNetezza。對絕大多數(shù)企業(yè)來說，需要精打細(xì)算。關(guān)鍵還是，對每一個問題，仔細(xì)調(diào)研清楚“足夠快”的定義。心里有底，做事不慌?！翱臁比菀族e。丹尼爾·卡尼曼在《思考，快與慢》中講到快思考容易上當(dāng)，在那一瞬間，“眼見為實(shí)”、厭惡損失和持樂觀偏見等習(xí)慣常常引導(dǎo)我們作出錯誤的選擇?；凇翱臁睌?shù)據(jù)的分析同樣會有這樣的問題，可能是數(shù)據(jù)集不夠大導(dǎo)致了