分析：大數據漫談，唯快不破

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