沈MM再聊大數據

自從去年上半年做了一個涉及大數據的項目，就被認為是部門里的大數據第一人，其實萬不敢當。在此之前所在部門的確對這方面毫無涉足，我們是部門內的先行者。但要說有多么了解大數據，其實也很汗顏，認真一點說，我們是想借助這個項目去大數據的海洋里試駕遠航，可事實是我們趕在被真正的大數據的海浪打翻之前就已經回到岸邊。

也正因這個項目，令我們開拓了視野，自從轉型到技術開發，從曾經只顧得上埋頭啃傳輸協議，到終有機會抬頭看看虛擬化，搗鼓云計算，再涉足大數據，借助技術開發部各種高端項目，令我有機會湊近前沿科技。也正是因為做了這個項目，開始對外界關于大數據的各種信息開始敏感，而當時正在項目中的我們，更多關注的是當前腳下的路，而不是周圍的風景。

所以當這個項目完結相當長一段時間以后，我們依然在留心大數據方面的消息，雖然再入這個領域的機會很小，但已經變成一種習慣意識，也曾有莫名的滑稽的自豪感，就像一個孩子，會指著櫥窗里彩色的糖果對著其他流口水的小伙伴們說，看，我吃過中間這個最大的！

這兩年，“大數據”這個詞在公眾眼前出現的次數越來越多，聽起來的確氣勢恢宏，所以很多人都敬仰著不明覺厲。而隨著越來越多的使用，各類商家無論什么都冠上“大數據”三個字以期身價倍增，連個街頭乞丐都會用大數據給自己找攤位，用得多了，民眾就會有困惑，大數據到底是什么玩意？怎么什么人都能玩得轉？

那么我們就先來說說，什么是大數據。

大數據，顧名思義，首先是要大。但是，多大才算大呢？只是單純的大嗎？其實這是非常有爭議的，因為大數據，不像通訊領域的3G、4G，有嚴格的標準，有章可循。

大多數研究者認為，大數據和海量數據是有區別的，那么就有了第一個定義：大數據?=?海量數據?+?復雜類型的數據

數據庫中的數據可以分為三種類型：結構性數據，非結構性數據以及半結構性數據。如果是結構性數據，一般通過購買更多的存儲來解決，但當海量的非結構性及半結構性數據存在的時候，情況就變得復雜了。對于大數據在數據處理這方面的應用，很多人都在質疑，大數據和傳統的數據統計/數據分析有什么區別，認為現在的宣傳都是炒作，都是偷換概念，實際上沒有什么新鮮的東西。

其實還是有明顯區別的。

傳統的統計學，數據分析，都是基于樣本數據的，在進行各種分析前，首先需要采樣。那么這里就引出了大數據的第一個特征，也是很容易被人們忽視的：大數據的運算范圍，并不是樣本數據，哪怕規模宏大的樣本數據。而是，全數據。隨機抽樣，有它的弊端，數據的可靠性存在著偏差，而直接跳過采樣，采用全數據，是大數據的一個霸氣里程碑。

可能是為了淺顯易懂，就取了“BigData”，“大數據”這么樣的一個名字，如果換成“馬斯戴德”之類的名字，估計會顯得高深莫測一些，也可以和現在的數據分析處理技術有一個一目了然的區別。

提到大數據，就要提到大數據的4V特征，其實我很不想說這個，但是提到大數據你不說這個，人家就會覺得你業余（其實我本來也很業余）。4V是這4個詞的縮寫：Volume（大量）、Velocity（高速）、Variety（多樣）、Value（價值）。

其實上面已經提到了兩個V，Volume?和?Variety，這是大數據自身的兩個不能回避的特征。

可是很多人都會有疑問：對于體量大的標準如何衡定？到底多大才算大？

Hadoop是什么？這次看名字看不出來了吧？

來，讓我告訴你，Hadoop?是一個大象小玩偶的名字。

只不過是一個特殊的玩偶。因為它是?Hadoop?創始人愛女的一個鐘愛玩偶。所以，我們今天看到的?Hadoop?被命名成?Hadoop。

啊……讓我們感嘆一下偉大的父愛……

扯遠。

我們先來一段稍顯官方的生硬解說詞：

Hadoop是一個由Apache基金會所開發的分布式系統基礎架構。用戶可以在不了解分布式底層細節的情況下，開發分布式程序。充分利用集群的威力進行高速運算和存儲。Hadoop實現了一個分布式文件系統（Hadoop Distributed File System），簡稱HDFS。HDFS有高容錯性的特點，并且設計用來部署在低廉的（low-cost）硬件上；而且它提供高吞吐量（high throughput）來訪問應用程序的數據，適合那些有著超大數據集（large data set）的應用程序。HDFS放寬了（relax）POSIX的要求，可以以流的形式訪問（streaming access）文件系統中的數據。Hadoop的框架最核心的設計就是：HDFS?和?MapReduce。HDFS為海量的數據提供了存儲，而?MapReduce?為海量的數據提供了計算。

說白了，Hadoop?是一個實現了MapReduce模式的開源的分布式并行編程框架。是不是又有一堆疑問？OK，我們先來探討一下Hadoop的靈魂——MapReduce。

面對數據的爆炸性增長，谷歌的工程師?Jeff Dean?和?Sanjay Ghemawat?架構并發布了兩個開創性的系統：谷歌文件系統（GFS）和谷歌MapReduce（GMR）。前者是一個出色而實用的解決方案，使用常規的硬件擴展并管理數據，后者同樣輝煌，造就了一個適用于大規模并行處理的計算框架。谷歌MapReduce（GMR）為普通開發者/用戶進行大數據處理提供了簡易的方式，并使之快速、具備容錯性。谷歌文件系統（GFS）和谷歌MapReduce（GMR）也為谷歌搜索引擎對網頁進行抓取、分析提供了核心動力。而實際上，HDFS?就是?Google File System（GFS）的開源實現，MapReduce?是Google MapReduce?的開源實現。Hadoop項目已經發展成為一個生態系統，并觸及了大數據領域的方方面面。當初我們敏感地意識到大數據的運用離不開計算平臺，就好比美麗的花朵離不開絢麗的顏色。但在我們對Hadoop平臺進行了幾輪深入分析之后，的確是對它又愛又恨。

MapReduce是一種模式，一種什么模式呢？一種云計算的核心計算模式，一種分布式運算技術，也是簡化的分布式編程模式，它主要用于解決問題的程序開發模型，也是開發人員拆解問題的方法。MapReduce模式的主要思想是將自動分割要執行的問題（例如程序）拆解成map（映射）和reduce（化簡）的方式，如下圖所示：

在數據被分割后通過Map?函數的程序將數據映射成不同的區塊，分配給計算機機群處理達到分布式運算的效果，在通過Reduce?函數的程序將結果匯整，從而輸出開發者需要的結果。MapReduce?借鑒了函數式程序設計語言的設計思想，其軟件實現是指定一個Map?函數，把鍵值對(key/value)映射成新的鍵值對(key/value)，形成一系列中間結果形式的key/value?對，然后把它們傳給Reduce(規約)函數，把具有相同中間形式key?的value?合并在一起。Map?和Reduce?函數具有一定的關聯性。

（話說你們真的喜歡看這個么....?真的要往下看么.... o(╯□╰)o）

一個MapReduce作業（job）通常會把輸入的數據集切分為若干獨立的數據塊，由?Map任務（task）以完全并行的方式處理它們?？蚣軙ap的輸出先進行排序，然后把結果輸入給Reduce任務。通常作業的輸入和輸出都會被存儲在文件系統中。整個框架負責任務的調度和監控，以及重新執行已經失敗的任務。如下圖所示（Hadoop MapReduce處理流程圖）：

MapReduce致力于解決大規模數據處理的問題，因此在設計之初就考慮了數據的局部性原理，利用局部性原理將整個問題分而治之。由于MapReduce集群由普通PC機構成，為無共享式架構。在處理之前，將數據集分布至各個節點。處理時，每個節點就近讀取本地存儲的數據處理（map），將處理后的數據進行合并（combine）、排序（shuffle and sort）后再分發（至reduce節點），避免了大量數據的傳輸，提高了處理效率。無共享式架構的另一個好處是配合復制（replication）策略，集群可以具有良好的容錯性，一部分節點的down機對集群的正常工作不會造成影響。而這種可靠性的提升，正離不開它底層的文件系統，HDFS。

HDFS是Hadoop Distribute File System?的簡稱，也就是Hadoop的一個分布式文件系統。HDFS設計理念之一就是讓它能運行在普通的硬件之上，即便硬件出現故障，也可以通過容錯策略來保證數據的高可用。由于HDFS存儲的數據集作為hadoop的分析對象，在數據集生成后，長時間在此數據集上進行各種分析。每次分析都將涉及該數據集的大部分數據甚至全部數據，因此讀取整個數據集的時間延遲比讀取第一條記錄的時間延遲更重要，所以HDFS具有最高效的訪問模式：一次寫入、多次讀取(流式數據訪問)。

一個HDFS集群是有由一個Namenode和一定數目的Datanode組成。Namenode是一個中心服務器，負責管理文件系統的namespace和客戶端對文件的訪問。Datanode在集群中一般是一個節點一個，負責管理節點上它們附帶的存儲。在內部，一個文件其實分成一個或多個block，這些block存儲在Datanode集合里。如下圖所示（HDFS體系結構圖）：

剛開始分析的時候，我很容易在名稱上將Datanode和Namenode弄混，后來想了個辦法，Namenode是那個有命名權的人，這種人一般位高權重，高高在上，一個就夠了；Datanode雖然看起來很有貨，但就是個干苦力的，基礎工作都是它們做，這樣一想，名字就搞清楚了。

對于block，每一個block會在多個datanode上存儲多份副本，默認是3份。Rack?是指機柜的意思，一個block的三個副本通常會保存到兩個或者兩個以上的機柜中（當然是機柜中的服務器），這樣做的目的是做防災容錯，因為發生一個機柜掉電或者一個機柜的交換機掛了的概率還是蠻高的。這樣既保證了可以使各任務就近讀取縮短處理時間，又有很好的數據備份安全，唯一有些缺憾的是，備份數量過多的話，會拉長數據balance的時間。

如果把HDFS和MapReduce結合起來看，內部工作原理就是下面這張圖，淺顯易懂：

因為我們是從平臺轉型過來的，自然對新事物中的平臺或框架更感興趣和敏感，當我們鎖定了Hadoop這種計算框架之后，花了很大的精力來分析和測試。最初接觸到的時候被很多概念所蒙蔽，但我們最終克服了它，并在測試數據的背后尋找到了真相。關于HDFS我們就簡單講這么多，我實在是不想讓這篇文章看起來像一個枯燥乏味的技術細節探討專題，Hadoop是免費的開源軟件，網上相關的資料特別多，有興趣深挖的筒子可以移步百度。

由于Hadoop技術出現的特別早，而且，其本身也有一些掣肘，所以后來又出現了一個加強版：Spark。

.

（快回來~~！我說的不是車~~

百科是這樣對它定義的：

相信這簡單幾句話也講的很清楚，Spark的廣告語號稱有百倍于Hadoop的速度，這在為海量數據計算動輒要等上十幾個小時甚至更久的人們眼睛冒光……我們當時也冒光了……于是我們咔咔把環境搭起來，然后和Hadoop測試比較了……然后我們憤怒地咆哮：廣告都他喵是騙人的！當然，情緒是要發泄的，但Calm down之后，好好想一想，是有原因的。

Spark為什么敢說它快？是因為它有RDD。如果說MapReduce是Hadoop類框架的靈魂，那么RDD就是Spark的九丈矛。RDD（彈性分布式數據集）作為原始數據的抽象，可以cache到內存中，那么每次對RDD數據集的操作之后的結果，都可以存放到內存中，下一個操作可以直接從內存中輸入，省去了MapReduce大量的磁盤IO操作。這對于迭代運算比較常見的機器學習算法來說，效率提升比較大。在這些它所擅長的方面，它的高速高效是無疑的，但如果沒有特別適合它的計算模型，那么它就是輛跑在石頭地里的寶馬，比拖拉機快不到哪里去。所以Spark更適合于迭代運算比較多的ML和DM運算，而不適用那種異步細粒度更新狀態的應用，例如web服務的存儲或者是增量的web爬蟲和索引。就是對于那種增量修改的應用模型，當然不適合把大量數據拿到內存中了。增量改動完了，也就不用了，不需要迭代了。

關于Hadoop和Spark平臺的一些性能數據，可以參考我之前的博文《大數據實測之三英戰呂布》。

RDD的技術細節此處也不做過多贅述，請百度其相關資料。

我們再回到大數據的4V，正是因為大數據的Volume（大量）和?Variety（多樣）才對Velocity（高速）有了更高的要求，從而催生出各種新的計算框架，并且這種革新一直在持續。Hadoop被提出來已經十幾年了，從那時以來，已經有太多的東西發生了變化：多核心處理器、大內存地址空間、10G網絡帶寬、SSD，而至今，這已經產生足夠的成本效益。這些極大改變了在構建可容錯分布式商用系統規模方面的取舍。此外，我們對于可處理數據的規模的觀念也發生了變化。在繼Hadoop和Spark之后，又有很多新技術和新平臺出現，滿地繁花?？萍季褪沁@樣，不斷地在進步，你剛剛搞清楚一樣東西，卻發現它已經過時了。

最后我們再說大數據的第四個V，Value，價值。

在商業上，不少公司開始借助大數據為他們創造更多的機會，成功的公司諸如亞馬遜、eBay、谷歌，它們依然想要據此更上一層樓，也促使隨后的商業領袖重新思考：大數據可以用來做什么？

我曾經寫過的一篇博文，《沈MM也來聊聊大數據》，可能很多人會覺得里面提出的“通過大數據就能透析未來”這種言論有些大言聳聽，嗯，老實說，我承認對它有進行文學藝術加工，所以略顯夸張。但我依然不否認我對這種趨勢的看法，大數據，其最大的價值就是預測。

但這種預測又和我們通常意義上所講的預測不同。

寫到這里的時候，我旁邊負責寫算法系列的同事探頭問我，你說算命算不算大數據？

滾~~~

一般人們對預測的評價準則和關心重點，都是“準不準”，比如，章魚保羅，馬航事件里的巫術師，或者，天氣預報。

前兩種都是不科學的，我們笑而棄之。

天氣預報是大家最熟悉的預測類信息了，但你也一定遇到過抱怨，明明說今天天晴啊，怎么下雨了？！

因為大家都熟悉，我們就從天氣預報這個深入民心的基于大數據預測分析的典型代表為切入點，看看大數據在預測上的一些普適特征，特別是互聯網方面：

1、大數據預測的時效性

天氣預報粒度從天縮短到小時，有嚴苛的時效要求，基于海量數據通過傳統方式進行計算，得出結論時明天早已到來，預測并無價值。其他領域的大數據預測應用特征對“時效性”有更高要求，譬如股市、實時定價，所以不要忘記大數據的另一個V，Velocity（高速）。好在如今云計算、分布式計算和超級計算機的發展則提供了這樣的高速計算能力。

2、大數據預測的數據源

天氣預報需要收集海量氣象數據，氣象衛星、氣象站臺負責收集，但整套系統的部署和運維耗資巨大。傳統行業在互聯網高速發展之前鮮有領域具備這樣的數據收集能力。WEB1.0為中心化信息產生、WEB2.0為社會化創造、移動互聯網則是隨時隨地、社會化和多設備的數據上傳，每一次演化數據收集的成本都大幅降低，范圍和規模則大幅擴大。大數據被引爆的同時，借助于互聯網，大數據預測所需數據源不再是問題。

3、大數據預測的動態性

不同時點的計算因子動態變化，任何變量都會引發整個系統變化，甚至產生蝴蝶效應。如果某個變量對結果起決定性作用且難以捕捉，預測難上加難，譬如人為因素。大數據預測的應用場景大都是極不穩定的領域但有固定規律，譬如天氣、股市、疾病。這需要預測系統對每一個變量數據的精準捕捉，并接近實時地調整預測。在信息急速爆炸的今天，大數據的實時預測對傳感器網絡和大數據計算能力提出了更高的要求。

4、大數據預測的規律性

大數據預測與傳統的基于抽樣的預測不同之處在于，其基于海量歷史數據和實時動態數據，發現數據與結果之間的規律，并假設此規律會延續，捕捉到變量之后進行預測。一個領域本身便有相對穩定的規律，大數據預測才有機會得到應用。古人夜觀天象就說明天氣是由規律可循的，因此氣象預報最早得到應用。反面案例則是規律難以捉摸，數據源收集困難的地震預測，還有雙色球彩票。

其實傳統的數據分析挖掘一直在做相似的事情，只不過效率會低一些或者說挖掘的深度、廣度和精度不夠。大數據預測則是基于大數據和預測模型去預測未來某件事情的概率。就像天氣預報，它只是說明天天晴的概率比較大，但不能肯定明天絕不會下雨。

大數據預測讓分析從“面向已經發生的過去”轉向“面向即將發生的未來”是大數據與傳統數據分析的最大不同。

大數據預測的邏輯基礎是，每一種非常規的變化事前一定有征兆，每一件事情都有跡可循，如果找到了征兆與變化之間的規律，就可以進行預測。大數據預測無法確定某件事情必然會發生，它更多是給出一個概率?！洞髷祿r代》中明確地指出，大數據預測“不是精確性，而是混雜性”“不是因果關系，而是相關關系”。

如果說，預測是大數據的核心，那么預測的核心是什么呢？

我們當時埋頭在大數據運算里好幾個月，突然有一天潘然醒悟，速度再快，計算量再多，結果不夠可靠，一切都是白搭，而能指引我們在茫茫數據海洋里找到彼岸的，唯有算法這盞明燈。

在我的上一篇關于大數據的博文里，我對算法很是崇拜了一通，老實說，在這個項目之前我對算法完全不懂，聽上去就很厲害的樣子。但是大數據，決然少不了算法，一套好的算法，就像是精妙的劍譜，招招制勝。

我不懂算法沒關系，我們立馬抽調一個懂算法的博士Dr.P進項目，于是接下來的一段時間，Dr.P先生整天給我們講各種算法原理，畫各種曲線圖，隨手就在玻璃墻上寫出來好多天書一樣的公式，也不管你看得懂看不懂……我的數學在離開高數課堂近十年之后又被從小黑屋里撿起來打磨，磨完了高數又磨了線性代數，但依然有些公式令我力不從心（領導，我開玩笑的）……

接下來，搭環境，攻克R語言，搞定R-Python，我們總算邁出了顫顫巍巍的第一小步。我們的一小步，是部門的一大步。

這個時候我才開始覺得，我們手里的數據，開始變得有意義。

我們當時手里有一套比較原始的算法，采用的是線性擬合，由于數據實在太復雜，最后出來的結果非常不令人滿意。于是Dr.P帶領我們給它換了一個在我看來很高級的算法——神經網絡算法。換了算法之后果然不一樣，當然其中過程之艱辛也就不多說了，我們的新算法將精度提升15%+。

算法的具體實現上也有優化空間，經過我們的努力，預測準確度提高近10%。

這里要解釋一下如何評估預測結果，比如我要預測一年后會發生某事，或某指標的升降，不可能要等一年以后才來驗證，檢驗標準的關鍵在于這個預測模型是否正確。業界一般的做法是，在原有數據集的整個區間內，拿出前一段的數據做訓練學習，用后一段的數據做驗證比較。打個比方，100天的天氣數據，我用1-80天來做訓練，然后預測后20天的數據，用這預測出來的20天結果和真實的最后20天數據做比較，有多少誤差，很容易辨別。

以上，只是我們在算法上做的一個小小的嘗試，這部分依然有很大的優化空間，算法的種類也紛繁多樣，變化無窮。

得益于我們博士資源比較多，你砸個蛋糕過來一定會波及到一個博士，所以算法這么精髓的東西交給博士們打理就可以了，我們探路者已經功成身退。

對于算法我還是個門外漢，就不做過多饒舌，但這絕對是大數據預測的關鍵。關于更多算法的相關總結文章，可以參考前面那個算命博士寫的總結，【跳轉門在此】（此博非Dr.P，不過他的文章難產了，寫好以后我會加進來）

關于大數據的未來，我個人的看法是挑戰依然很大。

大數據無處不在，人們每天創造出越來越多的應用來收獲其中的價值，無論是在我們的個人生活還是專業領域，從很多方面來說，大數據是數據產生速度的一種反映，實際上有分析家預計到2020年，數據產生的速度，將會是如今數據產生速度的50倍。

一方面，科學數據的增長等，加速了這種數據的猛增，舉例來說：歐洲研究組織進行的核試驗每秒鐘能產生40TB的數據。另一方面，一些非常積極的社會和經濟變化，也加劇了數據的泛濫，想想這些例子，迅速普及的移動設備，有GPS功能和富媒體，還有社交網絡讓全世界數十億人進行數碼聯系……

這些新興科技，令如今每天產生的新數據按從前定義就是大數據，那么所有這些數據持續增長，是一種什么樣的局面？數據不斷地在變大，但是價值密度卻在在變低。如何高效地去除垃圾數據，提取有效信息的難度也在不斷上升。

這里有兩頁我以前寫的膠片，便是我所看見的大數據未來：

我在《大數據時代》里發現了一段話，權且作為本文的結束語：

“大數據并不是一個充斥著算法和機械的冰冷世界，人類的作用依然無法被完全替代。大數據為我們提供的不是最終答案，只是參-，幫助是暫時的，而更好的方法和答案還在不久的將來?！?/p>

-----------------------------------------------------------------The End.

后記：

12年的夏天，我曾寫過一篇很長很長的項目總結：《硬盤那些事》，吐槽在OMUd項目中遇到的各種奇葩狗血困難以及整個項目過程中的心路歷程，每次回頭看看，都別有一番感觸。

這一回又接到任務，要對14年做的一個大數據相關的項目進行總結，并順帶給部門全員進行一下大數據的掃盲科普?？雌饋碛幸螅鋵嵱譀]要求，這樣的文章最難寫，于是我反反復復寫了好幾稿，自己都不能滿意。本來我想像前一篇總結一樣，關注項目的過程本身的思考，但又覺得既然困難都已克服，就無須拿出來碎碎念，最終，你們見到的這一稿是V5.0，我也是蠻拼的……

其實這個項目本身，并沒有對大數據進行更深入的研究，所以我不能夠說是大數據方面的專家，連資深人士都不敢妄稱，接到這個任務也的確是有些誠惶誠恐，生怕自己的見解不到位惹來內行人士的笑話。大數據所涉及的面非常廣泛，寫著寫著可能就寫忘了一些東西，寫的并不算全面，但我想我把我理解中的主要的點都寫出來了，算是對這項目一個交代。

在這個項目的過程中，得到了很多相關部門的人的大力支持，大多數都是我不認識的，但他們都很耐心地與我交流、探討，甚至慷慨相助，對此我一直心懷感激。

借此，我誠摯地奉上我的謝意，希望那些曾經幫助過我的各位能夠在自己的領域里，獨創一片天地。

Hadoop 大數據

版權聲明：本文內容由網絡用戶投稿，版權歸原作者所有，本站不擁有其著作權，亦不承擔相應法律責任。如果您發現本站中有涉嫌抄襲或描述失實的內容，請聯系我們jiasou666@gmail.com 處理，核實后本網站將在24小時內刪除侵權內容。