


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