大數(shù)據(jù) 迅速_數(shù)據(jù)分析師
天下武功，唯快不破。這句話濫觴于《拳經(jīng)》，經(jīng)過雷軍等人的演繹，幾乎成了互聯(lián)網(wǎng)時代商業(yè)致勝的不二法則。那么，大數(shù)據(jù)的快又從何說起呢？
話說道哥（Doug Laney）當年創(chuàng)立三V經(jīng)，背景是電子商務：Velocity衡量的是用戶“交互點”（Point-of-Interaction），如網(wǎng)站響應速度、訂單完成速度、產(chǎn)品和服務的交付速度等。假設交互點是一個黑盒子，一邊吸入數(shù)據(jù)，經(jīng)過黑盒子處理后，在另一邊流出價值，那Velocity指的是吸入、處理和產(chǎn)生價值的快速度。隨后“快”進入了企業(yè)運營、管理和決策智能化的每一個環(huán)節(jié)，于是大家看到了形形色色描述“快”的文字用在商業(yè)數(shù)據(jù)語境里，例如real-time（實時），lightning fast（快如閃電的），speed of light（光速），speed of thought(念動的瞬間),Time to Value（價值送達時間），等等。
本篇試圖討論“快”的四個問題：
* 為什么要“快”？
* “快”的數(shù)據(jù)和處理模型
* 怎么實現(xiàn)“快”？
* “快”的代價是什么？
為什么要“快”?
“快”，來自幾個樸素的思想：
1）時間就是金錢。時間在分母上，越小，單位價值就越大。面臨同樣大的數(shù)據(jù)礦山，“挖礦”效率是競爭優(yōu)勢。Zara與H&M有相似的大數(shù)據(jù)供應，Zara勝出的原因毫無疑問就是“快”。
2）像其它商品一樣，數(shù)據(jù)的價值會折舊。過去一天的數(shù)據(jù)，比過去一個月的數(shù)據(jù)可能都更有價值。更普遍意義上，它就是時間成本的問題：等量數(shù)據(jù)在不同時間點上價值不等。NewSQL的先行者VoltDB發(fā)明了一個概念叫做Data Continuum：數(shù)據(jù)存在于一個連續(xù)時間軸（time continuum）上，每一個數(shù)據(jù)項都有它的年齡，不同年齡的數(shù)據(jù)有不同的價值取向，“年輕”（最近）時關注個體的價值，“年長”（久遠）時著重集合價值。
3）數(shù)據(jù)跟新聞和金融行情一樣，具有時效性。炒股軟件免費版給你的數(shù)據(jù)有十幾秒的延遲，這十幾秒是快速獵食者宰割散戶的機會；而華爾街大量的機構使用高頻機器交易（70%的成交量來自高頻交易），能發(fā)現(xiàn)微秒級交易機會的吃定毫秒級的。物聯(lián)網(wǎng)這塊，很多傳感器的數(shù)據(jù)，產(chǎn)生幾秒之后就失去意義了。美國國家海洋和大氣管理局的超級計算機能夠在日本地震后9分鐘計算出海嘯的可能性，但9分鐘的延遲對于瞬間被海浪吞噬的生命來說還是太長了。
大家知道，購物籃分析是沃爾瑪橫行天下的絕技，其中最經(jīng)典的就是關聯(lián)產(chǎn)品分析：從大家耳熟能詳?shù)摹捌【萍幽虿肌?，到颶風來臨時的“餡餅（pop-tarts）加手電筒”和“餡餅加啤酒”?？墒?，此“購物籃”并非顧客拎著找貨的那個，而是指你買完帳單上的物品集合。對于快消品等有定期消費規(guī)律的產(chǎn)品來說，這種“購物籃”分析尚且有效，但對絕大多數(shù)商品來說，找到顧客“觸點（touch points）”的最佳時機并非在結帳以后，而是在顧客還領著籃子掃街逛店的正當時。電子商務具備了這個能力，從點擊流（clickstream）、瀏覽歷史和行為（如放入購物車）中實時發(fā)現(xiàn)顧客的即時購買意圖和興趣。這就是“快”的價值。那傳統(tǒng)零售業(yè)是不是只能盯著購物清單和顧客遠去的背影望“快”興嘆了呢？也不見得，我有空時會寫一篇小文“O4O：Online for Offline”專門寫傳統(tǒng)零售業(yè)怎么部署數(shù)據(jù)實時采集和分析技術突破困局。
“快”的數(shù)據(jù)和處理模型
設想我們站在某個時間點上，背后是靜靜躺著的老數(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ù)據(jù)的三狀態(tài)定義，水庫里一平如鏡（非活躍）的水是“靜止數(shù)據(jù)（data at rest）”，水處理系統(tǒng)中上下翻動的水是“正使用數(shù)據(jù)（data inuse）”，洶涌而來的新水流就是“動態(tài)數(shù)據(jù)（data in motion）”。
“快”說的是兩個層面：
一個是“動態(tài)數(shù)據(jù)”來得快。動態(tài)數(shù)據(jù)有不同的產(chǎn)生模式。有的是burst模式，極端的例子如歐洲核子研究中心（CERN）的大型強子對撞機(Large Hadron Collider，簡稱LHC)，此機不撞則已，一撞驚人，工作狀態(tài)下每秒產(chǎn)生PB級的數(shù)據(jù)。也有的動態(tài)數(shù)據(jù)是涓涓細流的模式，典型的如clickstream，日志，RFID數(shù)據(jù)，GPS位置信息，Twitter的firehose流數(shù)據(jù)等。
二是對“正使用數(shù)據(jù)”處理得快。水處理系統(tǒng)可以從水庫調出水來進行處理（“靜止數(shù)據(jù)”轉變?yōu)椤罢褂脭?shù)據(jù)”），也可以直接對涌進來的新水流處理（“動態(tài)數(shù)據(jù)”轉變?yōu)椤罢褂脭?shù)據(jù)”）。這對應著兩種大相迥異的處理范式：批處理和流處理。
如下圖所示，左半部是批處理：以“靜止數(shù)據(jù)”為出發(fā)點，數(shù)據(jù)是任爾東西南北風、我自巋然不動，處理邏輯進來，算完后價值出去。Hadoop就是典型的批處理范式：HDFS存放已經(jīng)沉淀下來的數(shù)據(jù)，MapReduce的作業(yè)調度系統(tǒng)把處理邏輯送到每個節(jié)點進行計算。這非常合理，因為搬動數(shù)據(jù)比發(fā)送代碼更昂貴。
右半部則是流數(shù)據(jù)處理范式。這次不動的是邏輯，“動態(tài)數(shù)據(jù)”進來，計算完后價值留下，原始數(shù)據(jù)加入“靜止數(shù)據(jù)”，或索性丟棄。流處理品類繁多，包括傳統(tǒng)的消息隊列（絕大多數(shù)的名字以MQ結尾），事件流處理（Event Stream Processing）/復雜事件處理（Complex Event Processing或CEP）（如Tibco的BusinessEvents和IBM的InfoStreams），分布式發(fā)布/訂閱系統(tǒng)（如Kafka），專注于日志處理的（如Scribe和Flume），通用流處理系統(tǒng)（如Storm和S4）等。
這兩種范式與我們日常生活中的兩種信息處理習慣相似：有些人習慣先把信息存下來（如書簽、To Do列表、郵箱里的未讀郵件），稍后一次性地處理掉（也有可能越積越多，舊的信息可能永遠不會處理了）；有些人喜歡任務來一件做一件，信息來一點處理一點，有的直接過濾掉，有的存起來。
沒有定規(guī)說哪種范式更好，對于burst數(shù)據(jù)，多數(shù)是先進入存儲系統(tǒng)，然后再來處理，因此以批處理范式為主；而對于流數(shù)據(jù)，多采用流范式。傳統(tǒng)上認為流處理的方式更快，但流范式能處理的數(shù)據(jù)常常局限于最近的一個數(shù)據(jù)窗口，只能獲得實時智能（real-time intelligence），不能實現(xiàn)全時智能（all-timeintelligence）。批處理擅長全時智能，但翻江倒海搗騰數(shù)據(jù)肯定慢，所以亟需把批處理加速。
兩種范式常常組合使用，而且形成了一些定式：
* 流處理作為批處理的前端：比如前面大型強子對撞機的例子，每秒PB級的數(shù)據(jù)先經(jīng)過流處理范式進行過濾，只有那些科學家感興趣的撞擊數(shù)據(jù)保留下來進入存儲系統(tǒng)，留待批處理范式處理。這樣，歐洲核子研究中心每年的新增存儲存儲量可以減到25PB。
* 流處理與批處理肩并肩：流處理負責動態(tài)數(shù)據(jù)和實時智能，批處理負責靜止數(shù)據(jù)和歷史智能，實時智能和歷史智能合并成為全時智能。
怎么實現(xiàn)“快”？
涉及到實現(xiàn)，這是個技術話題，不喜可略。
首先，“快”是個相對的概念，可以是實時，也可以秒級、分鐘級、小時級、天級甚至更長的延遲。實現(xiàn)不同級別的“快”采用的架構和付出的代價也不一樣。所以對于每一個面臨“快”問題的決策者和架構師來說，第一件事情就是要搞清楚究竟要多“快”?！翱臁睙o止境，找到足夠“快”的那個點，那就夠了。
其次，考慮目前的架構是不是有潛力改造到足夠“快”。很多企業(yè)傳統(tǒng)的關系型數(shù)據(jù)庫中數(shù)據(jù)量到達TB級別，就慢如蝸牛了。在轉向新的架構（如NoSQL數(shù)據(jù)庫）之前，可以先考慮分庫分表（sharding）和內存緩存服務器（如memcached）等方式延長現(xiàn)有架構的生命。
如果預測未來數(shù)據(jù)的增長必將超出現(xiàn)有架構的上限，那就要規(guī)劃新的架構了。這里不可避免要選擇流處理結構，還是批處理結構，抑或兩者兼具。Intel有一位老法師說：any big data platform needs tobe architected for particular problems（任何一個大數(shù)據(jù)平臺都需要為特定的問題度身定做）。在下不能同意更多。為什么呢？比如說大方向決定了要用流處理架構，我們前面列舉了很多品類，落實到具體產(chǎn)品少說上百種，所以要選擇最適合的流處理產(chǎn)品。再看批處理架構，MapReduce也不能包打天下,碰到多迭代、交互式計算就無能為力了；NoSQL更是枝繁葉茂，有名有姓的NoSQL數(shù)據(jù)庫好幾十種。這時候請一個好的大數(shù)據(jù)咨詢師很重要（這也是我在這里說大數(shù)據(jù)咨詢服務有前景的原因）。
總體上講，還是有一些通用的技術思路來實現(xiàn)“快”：
1）如果數(shù)據(jù)流入量太大，在前端就地采用流處理進行即時處理、過濾掉非重要數(shù)據(jù)。前段時間王堅把大數(shù)據(jù)和無人機扯一塊，這無人機還真有個流處理的前端。它以每秒幾幀的速度處理視頻，實時匹配特殊形狀（如坦克）和金屬反光（武器），同時把處理過的無用視頻幀幾乎全扔了。
2) 把數(shù)據(jù)預處理成適于快速分析的格式。預處理常常比較耗時，但對不常改動的惰性數(shù)據(jù)，預處理的代價在長期的使用中可以忽略不計。谷歌的Dremel，就是把只讀的嵌套數(shù)據(jù)轉成類似于列式數(shù)據(jù)庫的形式，實現(xiàn)了PB級數(shù)據(jù)的秒級查詢。
3）增量計算--也即先顧眼前的新數(shù)據(jù)，再去更新老數(shù)據(jù)。對傳統(tǒng)的批處理老外叫做reboil the ocean，每次計算都要翻江倒海把所有數(shù)據(jù)都搗騰一遍，自然快不了。而增量計算把當前重點放在新數(shù)據(jù)上，先滿足“快”；同時抽空把新數(shù)據(jù)（或新數(shù)據(jù)里提煉出來的信息）更新到老數(shù)據(jù)（或歷史信息庫）中，又能滿足“全”。谷歌的Web索引自2010年起從老的MapReduce批量系統(tǒng)升級成新的增量索引系統(tǒng)，能夠極大地縮短網(wǎng)頁被爬蟲爬到和被搜索到之間的延遲。我們前面說的“流處理和批處理肩并肩”也是一種增量計算。
4）很多批處理系統(tǒng)慢的根源是磁盤和I/O，把原始數(shù)據(jù)和中間數(shù)據(jù)放在內存里，一定能極大地提升速度。這就是內存計算（In-memory computing）。內存計算最簡單的形式是內存緩存，F(xiàn)acebook超過80%的活躍數(shù)據(jù)就在memcached里。比較復雜的有內存數(shù)據(jù)庫和數(shù)據(jù)分析平臺，如SAP的HANA，NewSQL的代表VoltDB和伯克利的開源內存計算框架Spark（Intel也開始參與）。斯坦福的John Ousterhout（Tcl/Tk以及集群文件系統(tǒng)Lustre的發(fā)明者）搞了個更超前的RAMCloud，號稱所有數(shù)據(jù)只生活在內存里。未來新的非易失性內存（斷電數(shù)據(jù)不會丟失）會是個game changer。Facebook在3月宣布了閃存版的Memcached，叫McDipper，比起單節(jié)點容量可以提升20倍，而吞吐量仍能達到每秒數(shù)萬次操作。另一種非易失性內存，相變內存（Phase Change Memory），在幾年內會商用，它的每比特成本可以是DRAM的1/10，性能比DRAM僅慢2-10倍，比現(xiàn)今的閃存（NAND）快500倍，壽命長100倍。
除內存計算外，還有其它的硬件手段來加速計算、存儲和數(shù)據(jù)通訊，如FPGA（IBM的Netezza和Convey的Hybrid-Core），SSD和閃存卡（SAP HANA和Fusion IO），壓縮PCIe卡，更快和可配置的互聯(lián)（Infiniband的RDMA和SeaMicro SM15000的Freedom Fabrics）等。此處不再細表。
5）降低對精確性的要求。大體量、精確性和快不可兼得，頂多取其二。如果要在大體量數(shù)據(jù)上實現(xiàn)“快”，必然要適度地降低精確性。對數(shù)據(jù)進行采樣后再計算就是一種辦法，伯克利BlinkDB通過獨特的采用優(yōu)化技術實現(xiàn)了比Hive快百倍的速度，同時能把誤差控制在2-10%。
“快”的代價是什么？
這世界上沒有免費的午餐，實現(xiàn)了“快”必然要付出代價。要么做加法，增加硬件投入、改變架構設計；要么做減法，降低精確性、忍受實時但非全時的智能。其實，這個好比看報紙，時報、日報信息快，需要采編投入，但因為短時間內所能獲得信息的局限性，缺乏深度和全景式的文章；周報、月刊則反之。
“快”很貴。有些行業(yè)，肯定是越快越好的，比如說金融領域，所以他們愿意買貴得離譜的SAP HANA或IBM Netezza。對絕大多數(shù)企業(yè)來說，需要精打細算。關鍵還是，對每一個問題，仔細調研清楚“足夠快”的定義。心里有底，做事不慌。
“快”容易錯。丹尼爾·卡尼曼在《思考，快與慢》中講到快思考容易上當，在那一瞬間，“眼見為實”、厭惡損失和持樂觀偏見等習慣常常引導我們作出錯誤的選擇?；凇翱臁睌?shù)據(jù)的分析同樣會有這樣的問題，可能是數(shù)據(jù)集不夠大導致了統(tǒng)計偏差，或是因為“快”而犧牲了精確性。
再進一步，“快”出錯了常?！案菜y收”。Wolters Kluwer的一個高級分析師Marcia Richards Suelzer說：“我們現(xiàn)在可以在幾納秒內作出災難性的錯誤計算，隨即將其廣播到世界的各個角落。我們不再具有計算延遲帶來的緩沖性”。技術帶來了分析的快速性和全球的連接性，同時也把我們創(chuàng)造破壞的能力放大了。美國新聞向來是求“快”，彭博社誤報“中國經(jīng)濟刺激計劃”導致全球股市大漲，至少結果還不錯，CNN在2008年誤報喬布斯有心臟病導致蘋果股價大跌就不那么美好了（彭博社還在同年誤報喬布斯的死訊）。
簡單地總結，Variety和Velocity是Volume的左右護法，它們修正和充實了“大”的內涵。Velocity帶來了諸般好處，也需要付出代價。下一篇講Veracity 魚龍混雜、真假難辨。
CDA數(shù)據(jù)分析師考試相關入口一覽（建議收藏）：
? 想報名CDA認證考試，點擊>>>
“CDA報名”
了解CDA考試詳情；
? 想學習CDA考試教材，點擊>>> “CDA教材” 了解CDA考試詳情；
? 想加入CDA考試題庫，點擊>>> “CDA題庫” 了解CDA考試詳情；
? 想了解CDA考試含金量，點擊>>> “CDA含金量” 了解CDA考試詳情；
京公網(wǎng)安備 11010802034615號
經(jīng)營許可證編號：京B2-20210330
