Hadoop技術(shù)已經(jīng)無處不在。不管是好是壞，Hadoop已經(jīng)成為 大數(shù)據(jù) 的代名詞。短短幾年間，Hadoop從一種邊緣技術(shù)成為事實上的標準�？磥恚粌H現(xiàn)在Hadoop是企業(yè) 大數(shù)據(jù) 的標準，而且在未來，它的地位似乎一時難以動搖。
谷歌文件系統(tǒng)與MapReduce
我們先來探討一下Hadoop的靈魂——MapReduce。面對數(shù)據(jù)的爆炸性增長，谷歌的工程師Jeff Dean和Sanjay Ghemawat架構(gòu)并發(fā)布了兩個開創(chuàng)性的系統(tǒng)：谷歌文件系統(tǒng)（GFS）和谷歌MapReduce（GMR）。前者是一個出色而實用的解決方案-使用常規(guī)的硬件擴展并管理數(shù)據(jù)，后者同樣輝煌，造就了一個適用于大規(guī)模并行處理的計算框架。
谷歌MapReduce（GMR）為普通開發(fā)者/用戶進行大數(shù)據(jù)處理提供了簡易的方式，并使之快速、具備容錯性。谷歌文件系統(tǒng)（GFS）和谷歌MapReduce（GMR）也為谷歌搜索引擎對網(wǎng)頁進行抓取、分析提供了核心動力。
再回頭看看開源世界中的Hadoop，Apache Hadoop的分布式文件系統(tǒng)（HDFS）和Hadoop MapReduce完全是谷歌文件系統(tǒng)（GFS）和谷歌MapReduce（GMR）的開源實現(xiàn)。Hadoop項目已經(jīng)發(fā)展成為一個生態(tài)系統(tǒng)，并觸及了大數(shù)據(jù)領(lǐng)域的方方面面。但從根本上，它的核心是MapReduce。
Hadoop是否可以趕超谷歌？
一個有趣的現(xiàn)象是，MapReduce在谷歌已不再顯赫。當企業(yè)矚目MapReduce的時候，谷歌好像早已進入到了下一個時代。事實上，我們談?wù)摰倪@些技術(shù)早就不是新技術(shù)了，MapReduce也不例外。
我希望在后Hadoop時代下面這些技術(shù)能夠更具競爭性。 盡管許多Apache社區(qū)的項目和商業(yè)化Hadoop項目都非�；钴S，并以來自HBase、Hive和下一代MapReduce（YARN）的技術(shù)不斷完善著Hadoop體系，我依然認為，Hadoop核心（HDFS和Zookeeper）需要脫離MapReduce并以全新的架構(gòu)增強自己的競爭力，真正與谷歌技術(shù)一較高下。
過濾不斷增長的索引，分析不斷變化的數(shù)據(jù)集。 Hadoop的偉大之處在于，它一旦開始運行，就會飛速地分析你的數(shù)據(jù)。盡管如此，在每次分析數(shù)據(jù)之前，即添加、更改或刪除數(shù)據(jù)之后，我們都必須將整個數(shù)據(jù)集進行流式處理。這意味著，隨著數(shù)據(jù)集的膨脹，分析時間也會隨之增加，且不可預(yù)期。
那么，谷歌又是怎么做到搜索結(jié)果越來越實時呈現(xiàn)呢？ 一個名為Percolator的增量處理引擎取代了谷歌MapReduce（GMR）。通過對新建、更改和已刪除文檔的處理，并使用二級索引進行高效的分類、查詢，谷歌能夠顯著地降低實現(xiàn)其目標的時間。
Percolator的作者寫道：“將索引系統(tǒng)轉(zhuǎn)化為一個增量系統(tǒng)……文檔平均處理延遲的因子降低到了現(xiàn)在的100。”這句話的意思是，索引Web上新內(nèi)容的速度比之前MapReduce系統(tǒng)快了100倍。
谷歌Dremel即時數(shù)據(jù)分析解決方案
谷歌和Hadoop社區(qū)曾致力于構(gòu)建基于MapReduce的易用性即時數(shù)據(jù)分析工具，如谷歌的并行處理語言Sawzall，Apache Pig和Hive。但對熟知SQL的人們而言，他們忽略了一個基本事實-構(gòu)建MapReduce的目標就在于管理數(shù)據(jù)處理工作。它的核心能力在于工作流管理，而不是即時數(shù)據(jù)分析。
與之形成鮮明對比的是，很多BI或數(shù)據(jù)分析查詢基本上都要求即時、交互和低延遲。這意味著，使用Hadoop不僅需要規(guī)劃流程圖，而且需要為許多查詢分析裁減不必要的工作流。即便如此，我們也要花費數(shù)分鐘等待工作開始，然后花費數(shù)小時等待工作流完成，并且這個過程也非常不利于交互式體驗。因此，谷歌研發(fā)了Dremel予以應(yīng)對。Dremel是Google 的“交互式”數(shù)據(jù)分析系統(tǒng)，可以在幾秒鐘內(nèi)處理PB級別的數(shù)據(jù)，并能輕松應(yīng)對即時查詢。
Google Dremel的設(shè)計特點：
Dremel是一個可擴展的大型系統(tǒng)。 在一個PB級別的數(shù)據(jù)集上面，將任務(wù)縮短到秒級，無疑需要大量的并發(fā)。磁盤的順序讀速度在100MB/S上下，那么在1S內(nèi)處理1TB數(shù)據(jù)，意味著至少需要有1萬個磁盤的并發(fā)讀! Google一向是用廉價機器辦大事的好手。但是機器越多，出問題概率越大，如此大的集群規(guī)模，需要有足夠的容錯考慮，保證整個分析的速度不被集群中的個別節(jié)點影響。
Dremel是MapReduce的補充。 和MapReduce一樣，Dremel也需要GFS這樣的文件系統(tǒng)作為存儲層。在設(shè)計之初，Dremel并非是MapReduce的替代品，它只是可以執(zhí)行非�？斓姆治�，在使用的時候，常常用它來處理MapReduce的結(jié)果集或者用來建立分析原型。
Dremel的數(shù)據(jù)模型是嵌套的。 互聯(lián)網(wǎng)數(shù)據(jù)常常是非關(guān)系型的。Dremel還需要有一個靈活的數(shù)據(jù)模型，這個數(shù)據(jù)模型至關(guān)重要。Dremel支持一個嵌套的數(shù)據(jù)模型，類似于JSON。而傳統(tǒng)的關(guān)系模型，由于不可避免的有大量的JOIN操作，在處理如此大規(guī)模的數(shù)據(jù)的時候，往往是有心無力的。
Dremel中的數(shù)據(jù)是采用列式存儲的。 使用列式存儲，分析的時候，可以只掃描需要的那部分數(shù)據(jù)的時候，減少CPU和磁盤的訪問量。同時列式存儲是壓縮友好的，使用壓縮，可以綜合CPU和磁盤，發(fā)揮最大的效能。
Dremel結(jié)合了Web搜索和并行DBMS的技術(shù)。 Dremel借鑒了Web搜索中的“查詢樹”的概念，將一個相對巨大復(fù)雜的查詢，分割成較小較簡單的查詢。大事化小，小事化了，能并發(fā)的在大量節(jié)點上跑。另外，和并行DBMS類似，Dremel可以提供了一個SQL-like的接口，就像Hive和Pig那樣。
谷歌的圖數(shù)據(jù)計算框架Pregel
谷歌MapReduce是專門為抓取、分析世界上最龐大的圖形架構(gòu)-internet而設(shè)計的，但針對大規(guī)模圖算法（如圖遍歷（BFS）、PageRank，最短路徑（SSSP）等）的計算則顯得效率低下。因此，谷歌構(gòu)建了Pregel。
Hadoop,大數(shù)據(jù),谷歌
Pregel給人的印象非常深刻。Pregel不僅能高效執(zhí)行SSSP或PageRank算法，更令人驚訝的是，公布的數(shù)據(jù)顯示Pregel處理一個有著幾十億節(jié)點、上萬億條邊的圖，只需數(shù)分鐘即可完成，其執(zhí)行時間隨著圖的大小呈線性增長。
Pregel基于BSP模型，就是“計算”-“通信”-“同步”的模式：
- 輸入輸出為有向圖
- 分成超步
- 以節(jié)點為中心計算，超步內(nèi)每個節(jié)點執(zhí)行自己的任務(wù)，執(zhí)行節(jié)點的順序不確定
- 兩個超步之間是通信階段
在Pregel中，以節(jié)點為中心計算。Step 0時每節(jié)點都活動著，每個節(jié)點主動“給停止投票”進入不活動狀態(tài)。如果接收到消息，則激活。沒有活動節(jié)點和消息時，整個算法結(jié)束。容錯是通過檢查點來做的。在每個超步開始的時候，對主從節(jié)點分別備份。
總結(jié)
盡管當前大數(shù)據(jù)技術(shù)的核心依然是Hadoop，但谷歌卻已經(jīng)為我們展現(xiàn)了許多更先進的大數(shù)據(jù)技術(shù)。谷歌開發(fā)這些技術(shù)的本意并不是要立刻拋棄掉MapReduce，但毫無疑問這是未來大數(shù)據(jù)技術(shù)的趨勢。盡管已經(jīng)出現(xiàn)了上述大數(shù)據(jù)技術(shù)的開源實現(xiàn)，但我們不禁要問，Hadoop的輝煌還能延續(xù)多久？
核心關(guān)注：拓步ERP系統(tǒng)平臺是覆蓋了眾多的業(yè)務(wù)領(lǐng)域、行業(yè)應(yīng)用，蘊涵了豐富的ERP管理思想，集成了ERP軟件業(yè)務(wù)管理理念，功能涉及供應(yīng)鏈、成本、制造、CRM、HR等眾多業(yè)務(wù)領(lǐng)域的管理，全面涵蓋了企業(yè)關(guān)注ERP管理系統(tǒng)的核心領(lǐng)域，是眾多中小企業(yè)信息化建設(shè)首選的ERP管理軟件信賴品牌。
轉(zhuǎn)載請注明出處：拓步ERP資訊網(wǎng)http://www.oesoe.com/
本文標題：Hadoop的生命周期有多久？
本文網(wǎng)址：http://www.oesoe.com/html/support/11121517777.html
相關(guān)文章
