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