大數據江湖
世人皆知「天下功夫出少林」，其實並不完全正確。刨根問底，也可說是「少林功夫出天下」。當年元朝大軍進軍汴梁，少林寺岌岌可危。時任少林住持為人間免遭禍害，特意深入蒙古大軍拜見忽必烈，利用佛家慈悲之理化解了這場人間災難。後來被忽必烈拜為國師。元朝定都之後，遂向天下下令禁止民間習武。但少林寺可以不受禁令的限制，隨意習武。此後的幾十年里，少林寺便成了民間習武交流武藝的場所。每位江湖高人都把自己的絕學留在了少林寺，少林寺也因此達到了空前的規模。這些絕學都分門別類的藏在了「藏經閣」之中。初時藏經閣藏書較少，倒也容易管理。但隨著藏經閣藏書越來越大，管理藏經閣藏書成了少林寺僧人的一項艱巨任務，大量僧人常年累月在藏經閣整理經書，工作量巨大，僧人苦不堪言。時到公元二十世紀，拉里?佩奇出任方丈，情況才大為改觀。佩奇方丈獨創九陰真經（又叫佩奇演算法），通過此演算法將藏經閣管理的井井有條，大大解放了寺中僧人，僧人才可以有時間天天念佛抄經。
話說這佩奇也是慈悲之人，發現江湖其它幫派根本跟不上少林寺的節奏，擔心技術後繼無人，於是在江湖月刊發表了三篇心經（Gfs、Bigtable、MapReduce）。
此時武當掌門道格?卡汀正苦於無法管理武當藏書而將武當一門發揚光大，看到那三篇心經茅塞頓開，於是開始依葫蘆畫瓢，在武當做起了實驗。
存下大數據之後，就開始考慮怎麼處理數據。雖然HDFS可以為你整體管理不同機器上的數據，但是這些數據太大了。一台機器讀取成上P的數據，一台機器慢慢跑也許需要好幾天甚至好幾周。對於武當名門大派來說，單機處理是不可忍受的，比如更新琅琊榜，它必須在一天之內跑完這些處理。那麼我如果要用很多台機器處理，我就面臨了如何分配工作，如果一台機器掛了如何重新啟動相應的任務，機器之間如何互相通信交換數據以完成複雜的計算等等。這就是MapReduce/Tez/Spark的功能。MapReduce是第一代計算引擎，Tez和Spark是第二代。MapReduce的設計，採用了很簡化的計算模型，只有Map和Reduce兩個計算過程（中間用Shuffle串聯），用這個模型，已經可以處理大數據領域很大一部分問題了。
那什麼是Map什麼是Reduce？
如果啟動了一個MapReduce程序。第一個是Map階段，第二個是Reduce階段。map階段負責對輸入文件進行切分處理，然後匯總再分組給reduce進行處理，以達到高效的分散式計算效率。
Map＋Reduce的簡單模型雖然好用，但是很笨重。第二代的Tez和Spark除了內存Cache之類的新feature，本質上來說，是讓Map/Reduce模型更通用，讓Map和Reduce之間的界限更模糊。Tez和Spark好比給Map/Reduce打通了任督二脈，讓數據交換更靈活，更少的磁碟讀寫，以便更方便地描述複雜演算法，取得更高的吞吐量。
有了MapReduce，Tez和Spark之後，人們發現，MapReduce的程序寫起來真麻煩。他們希望簡化這個過程。這就好比你有了彙編語言，雖然你幾乎什麼都能幹了，但是你還是覺得繁瑣。你希望有個更高層更抽象的語言層來描述演算法和數據處理流程。於是就有了Pig和Hive。Pig是接近腳本方式去描述MapReduce，Hive則用的是SQL。它們把腳本和SQL語言翻譯成MapReduce程序，丟給計算引擎去計算，而你就從繁瑣的MapReduce程序中解脫出來，用更簡單更直觀的語言去寫程序了。
有了Hive之後，人們發現SQL對比Java有巨大的優勢。一個是它太容易寫了。用SQL一兩行就能描述的東西，MapReduce寫起來大約要幾十上百行。而更重要的是，一般的程序員，只要會寫SQL，都可以來做大數據編程。於是數據分析人員終於不再看工程師的眼色，工程師也從寫奇怪的一次性的處理程序中解脫出來。大家都開心了。Hive逐漸成長成了大數據倉庫的核心組件。甚至很多公司的流水線作業集完全是用SQL描述，因為易寫易改，一看就懂，容易維護。
自從數據分析人員開始用Hive分析數據之後，他們發現，Hive在MapReduce上跑，太慢了。流水線作業集也許沒啥關係，比如一天更新的琅琊榜，反正24小時內跑完就算了。但是數據分析，人們總是希望能跑更快一些。比如我希望看過去一個小時內多少人在太極拳的選課頁面駐足，分別停留了多久，對於一個巨型網站海量數據下，這個處理過程也許要花幾十分鐘甚至很多小時。而這是你無法忍受的。
於是Impala，Presto，Drill等非交互SQL引擎誕生了。三個系統的核心理念是，MapReduce引擎太慢，因為它太通用，太強壯，太保守，我們SQL需要更輕量，更激進地獲取資源，更專門地對SQL做優化，而且不需要那麼多容錯性保證（因為系統出錯了大不了重新啟動任務，如果整個處理時間更短的話，比如幾分鐘之內）。這些系統讓用戶更快速地處理SQL任務，犧牲了通用性穩定性等特性。如果說MapReduce是屠龍刀，砍啥都不怕，那上面三個就韋小寶的玄鐵匕首，靈巧鋒利，但是不能搞太大太硬的東西。
這些系統，一直沒有達到人們期望的流行度。這時日月神教倒是創造了兩種異類功夫。他們是Hive on Tez / Spark和SparkSQL。它們的設計理念是，MapReduce慢，但是如果我用新一代通用計算引擎Tez或者Spark來跑SQL，那我就能跑的更快。而且用戶不需要維護兩套系統。這就好比你跟東方不敗對戰，任你十八般武藝，千變萬化，我就一枚繡花針，你還沒轍，因為我比你快，天下武功，唯快不破。
上面的介紹，基本就是一個數據倉庫的構架了。底層HDFS，上面跑MapReduce/Tez /Spark，在上面跑Hive，Pig。或者HDFS上直接跑Impala、Drill、Presto。這解決了中低速數據處理的要求。
那如果我要更高速的處理呢？
如果我是琅琊閣，我希望顯示不是24小時高手排名，我想看一個不斷變化的琅琊榜，更新延遲在一分鐘之內，上面的手段都將無法勝任。於是又一種計算模型被開發出來，這就是Streaming（流）計算。Storm是最流行的流計算平台。流計算的思路是，如果要達到更實時的更新，在數據流進來的時候就處理了。流計算可以簡單、可靠的處理大量，基本無延遲，但是它的短處是，不靈活，你想要統計的東西必須預先知道，畢竟數據流過就沒了，你沒算的東西就無法補算了。因此它是個很好的東西，但是無法替代上面數據倉庫和批處理系統。
還有一個有些獨立的模塊是KV Store，比如Cassandra，HBase，MongoDB等。所以KV Store就是說，我有一堆鍵值，我能很快速的獲取與這個Key綁定的數據。比如我用身份證號，能取到你的身份數據。這個動作用MapReduce也能完成，但是很可能要掃描整個數據集。而KV Store專用來處理這個操作，所有存和取都專門為此優化了。從幾個P的數據中查找一個身份證號，也許只要零點幾秒。這讓大數據公司的一些專門操作被大大優化了。比如我網頁上有個根據訂單號查找訂單內容的頁面，而整個網站的訂單數量無法單機資料庫存儲，我就會考慮用KV Store來存。KV Store的理念是，基本無法處理複雜的計算，大多沒法JOIN，也許沒法聚合，沒有強一致性保證（不同數據分布在不同機器上，你每次讀取也許會讀到不同的結果，也無法處理類似銀行轉賬那樣的強一致性要求的操作）。但是速度極快。
每個不同的KV Store設計都有不同取捨，有些更快，有些容量更高，有些可以支持更複雜的操作。但是必有一款適合你。
除此之外，還有一些更特製的系統/組件，比如Mahout是分散式機器學習庫，Protobuf是數據交換的編碼和庫，ZooKeeper是高一致性的分布存取協同系統，等等。
有了這麼多亂七八糟的工具，都在同一個集群上運轉，大家需要互相尊重有序工作。所以另外一個重要組件是，調度系統。現在最流行的是Yarn。你可以把他看作中央管理，好比全真七子天罡北斗陣，按北斗星座的方位，馬鈺位當天樞，譚處端位當天璇，劉處玄位當天璣，丘處機位當天權；王處一位當玉衡,郝大通位當開陽,孫不二位當搖光。丘處機承當中樞衝要，指揮你來一招神仙指路，我來一招大漠孤煙……
所以你可以認為大數據生態系統其實就是一個江湖。為了滿足不同門派的需求，你需要各種不同的武功招式。江湖上誰都想開宗立派，所以江湖上的武功只會越來越多，越來越複雜。
推薦閱讀：
※大數據告訴你二胎政策開放，母嬰行業能否起飛？
※相親大數據下的愛情、婚姻安全感
※【觀點】利用大數據構建互聯網金融情緒指數
※hadoop實驗（MapReduce）——關於氣象數據集
※智慧警務指揮決策系統，助力平安城市
TAG:大數據 |