Hadoop簡介

Hadoop簡介

Hadoop的概要介紹

Hadoop，是一個分佈式系統基礎架構，由Apache基金會開發。用戶能夠在不瞭解分佈式底層細節的狀況下，開發分佈式程序。充分利用集羣的威力高速運算和存儲。

簡單地說來，Hadoop是一個能夠更容易開發和運行處理大規模數據的軟件平臺。該平臺使用的是面向對象編程語言Java實現的，具備良好的可移植性。

 

Hadoop的發展歷史

       Hadoop是Doug Cutting（Apache Lucene創始人）開發的使用普遍的文本搜索庫。Hadoop起源於Apache Nutch，後者是一個開源的網絡搜索引擎，自己也是由Lucene項目的一部分。那麼咱們接下來就先來看一下Nutch的一些發展情況，使得咱們對Hadoop的前身有更多的瞭解。

Nutch項目開始於2002年，一個可工做的抓取工具和搜索系統很快浮出水面。但開發人員很快就意識到，他們的這個架構將沒法擴展到擁有數十億網頁的網絡。在2003年發表的一篇描述Google分佈式文件系統(Google File System，簡稱GFS)的論文爲他們提供了及時的幫助，文中稱Google正在使用此文件系統。 GFS或相似的東西，能夠解決他們在網絡抓取和索引過程當中產生的大量的文件的存儲需求。具體而言，GFS會省掉管理所花的時間，如管理存儲節點。在2004年，他們開始開發一個開放源碼的應用，即Nutch的分佈式文件系統(NDFS)，也就是後來耳熟能詳的HDFS的前身。

2004年，Google又發表了一篇論文，向全世界介紹了MapReduce這一偉大的科技成果。 2005年初，Nutch的開發者們又在Nutch上增長了一個可工做的MapReduce應用，到當年的年中，全部主要的Nutch算法被移植到使用MapReduce和NDFS來運行。

    Nutch中的NDFS和MapReduce實現的應用遠不僅是搜索領域，在2006年2月，他們從Nutch轉移出來成爲一個獨立的Lucene子項目，就是如今流行的開源雲計算平臺Hadoop。大約在同一時間，Doug Cutting加入雅虎，Yahoo提供一個專門的團隊和資源將Hadoop發展成一個可在網絡上運行的系統。在2008年2月，雅虎宣佈其搜索引擎產品部署在一個擁有1萬個內核的Hadoop集羣上。至此之後，Hadoop這個詞在業界迅速升溫，當你們提到雲計算的時候就天然而然的想起這個詞。

那麼，接下來讓我見識一下Hadoop這個分佈式計算框架的威力吧！2008年4月，Hadoop打破世界紀錄，成爲最快排序1TB數據的系統。運行在一個910節點的羣集，Hadoop在209秒內排序了1 TB的數據(還不到三分半鐘)，擊敗了前一年的297秒冠軍。同年11月，谷歌在報告中聲稱，它的MapReduce實現執行1TB數據的排序只用了68秒。 在2009年5月，有報道宣稱Yahoo的團隊使用Hadoop集羣對1 TB的數據進行排序只花了62秒時間。就這樣，奇蹟一點一滴的在被它不斷地創造出來~

 

Hadoop的關鍵技術

       能夠說，Hadoop發展到今天的地步，在很大程度上得益於Google的分佈式集羣的啓發。Google的數據中心使用廉價的Linux PC機組成集羣，在上面運行各類應用。即便是分佈式開發的新手也能夠迅速使用Google的基礎設施。核心組件有3個：

　　一、GFS（Google File System）。一個分佈式文件系統，隱藏下層負載均衡，冗餘複製等細節，對上層程序提供一個統一的文件系統API接口。Google根據本身的需求對它進行了特別優化，包括：超大文件的訪問，讀操做比例遠超過寫操做，PC機極易發生故障形成節點失效等。GFS把文件分紅64MB的塊，分佈在集羣的機器上，使用Linux的文件系統存放。同時每塊文件至少有3份以上的冗餘。中心是一個Master節點，根據文件索引，找尋文件塊。詳見Google的工程師發佈的GFS論文。

　　二、MapReduce。Google發現大多數分佈式運算能夠抽象爲MapReduce操做。Map是把輸入Input分解成中間的Key/Value對，Reduce把Key/Value合成最終輸出Output。這兩個函數由程序員提供給系統，下層設施把Map和Reduce操做分佈在集羣上運行，並把結果存儲在GFS上。

　　三、BigTable。一個大型的分佈式數據庫，這個數據庫不是關係式的數據庫。像它的名字同樣，就是一個巨大的表格，用來存儲結構化的數據。

　　以上三個設施Google均有論文發表。正是由於有了以上的三項核心技術，才使得Google的分佈式框架頗有創造性、擴展性，並且在系統吞吐量上有很大的競爭力。

       結合上面講的一些背景，再來看一下Hadoop這個架構的核心技術吧！

       主要是由HDFS、MapReduce和Hbase組成。HDFS是Google File System（GFS）的開源實現。MapReduce是Google MapReduce的開源實現。HBase是Google BigTable的開源實現。這裏就很少說了，具體的每一個核心技術的原理會在後續的文章裏面一點一點的介紹，畢竟也是剛開始學，邊學邊成長吧！

 

Hadoop的一些特色

       一、 擴容能力（Scalable）：能可靠地（reliably）存儲和處理千兆字節（PB）數據。在不保證低延時的前提下，具備至關大的吞吐量，很是適合海量數據的運算。

二、 成本低（Economical）：能夠經過普通機器組成的服務器羣來分發以及處理數據。這些服務器羣總計可達數千個節點。並且每一個節點都是運行在開源操做系統Linux上面的。

三、 高效率（Efficient）：經過分發數據，hadoop能夠在數據所在的節點上並行地（parallel）處理它們，這使得處理很是的快速。

四、 可靠性（Reliable）：hadoop能自動地維護數據的多份複製，而且在任務失敗後能自動地從新部署（redeploy）計算任務。

 

Hadoop的不足之處

       一、 該框架設計的初衷是針對海量數據的運算處理的問題。所以對於一些數據量很小的處理沒有任何優點可言，甚至還不如單機串行的效果，性能也徹底體現不出來。

       二、 既然是海量數據的處理，優先考慮的是該系統的吞吐量等性能問題。因此也很難知足日常的低時延的需求，這點是不可避免的，只能說想辦法儘可能去權衡二者，進而優化。

       三、 集羣中存在大量的機器，因此節點故障是不可避免的。在Hadoop中有兩種類型的結點：namenode和datanode。Hadoop集羣採起的master/slave結構，分別對應namenode和datanode兩種類型。Datanode故障通常是不會影響整個系統的，這個和它的存儲策略有關。可是namenode故障是是極大的問題，若是namenode掛掉了，那問題就很嚴重。並且namenode的內存限制也是整個系統的瓶頸，這個在這裏就很少說，後面隨着慢慢的瞭解就知道了。

       四、 其文件系統設計的前提是一次寫入屢次讀取的狀況，所以咱們是沒法修改某條詳細的數據，只能overwrite所有的數據，或者是在文件末尾追加數據。

       五、 集羣內部是經過tcp/ip協議進行通訊的，因此網絡帶寬也會成爲系統的瓶頸之一。

       六、 系統內部的調度策略。在使用了Hadoop一段時間以後，感受它的job調度策略不是很完善，沒能充分利用集羣資源展示出其所有的性能。

七、 採用Java實現。Java的IO處理雖然沒有性能瓶頸，可是對於CPU密集型的任務是一個噩耗。這點能夠經過對比HBase和Hypertable兩個開源的Bigtable實現來作初步的驗證。

       八、 開源項目。開源自己是一柄雙刃劍，它方便了大多數人，可是對於一個有必定規模的公司，項目發展方向的把握，技術保密和支持等都是採用Hadoop這種開源項目必須考慮的問題。另外，Hadoop做爲一個比較新的項目，性能和穩定性的提高還須要必定時間。

       九、安全問題。若是對外提供服務就要對外開放端口，那就有可能成爲被攻擊的目標，因此這個問題在之後的商業應用中顯得尤其重要。雖然並不清楚Hadoop的安全程度到底如何，可是這個是沒有止境的。道高一尺，魔高一丈。

       十、任然使用的是行存儲。從相關資料上了解到列存儲在海量數據處理方面的優點，以爲將來在這方面會有所改變。

 

Hadoop的發展前景

       我本人之前其實歷來沒接觸過度布式計算這一塊，偶然的一個機會來到淘寶的數據平臺實習，才知道有這麼個強大的東西存在。雖然它只是一個開源的項目，並非很成熟。可是有這麼多的強人在不斷地作貢獻，另外還有不少互聯網巨頭投入了巨大的人力物力來開發。 

       我我的仍是很看好這個分佈式計算平臺將來的前景。並且不少大公司也在使用Hadoop，像國內的淘寶、百度、騰訊，國外的雅虎、亞馬遜、Facebook等。事實證實這個分佈式平臺頗有潛力的，雖然目前仍是存在各類各樣的不足和缺陷，可是有那麼多人在爲之付出，老是可以不斷改進的。玉不琢不成器嘛~呵呵

 

我的隨想

       如今回想當年高考完了填志願，好像當時對計算機一竅不通啊~可是那時候以爲計算機很強大，也許會改變將來人們的生活方式。因此最後就這麼小不當心成了一個搞it的小菜鳥。不過既然選擇了這行，就堅持下去吧！也不能說對技術特別癡迷，可是仍是但願本身成爲一個技術牛人嘛~

       之前其實不多作筆記，做總結，再加上日常學到的東西也不多用，最後時間久了什麼都忘了。因此此次淘寶的實習轉正面試的悲劇是個教訓。積累是成長的必須過程。之後有空就多就常常去學習，思考，總結。

萬事開頭難啊~不過今天算是邁出了第一步，寫了一篇關於Hadoop的博文。千里之行始於足下~

 

 

 

注：本文是在我參考了網上不少相關資料以後，按我本身的思路整理而成的。具體的轉載地址也沒專門記錄，敬請諒解~

內容來自：（http://blog.csdn.net/husthcb/article/details/5864769）

 

 

數據分析≠Hadoop+NoSQL，不妨先看完善現有技術的10條捷徑

       讓業務搭乘大數據技術確實是件很是有吸引力的事情，而Apache Hadoop讓這個誘惑來的更加的猛烈。Hadoop是個大規模可擴展數據存儲平臺，構成了大多數大數據項目基礎。Hadoop是強大的，然而卻須要公司投入大量的學習精力及其它的資源。

若是獲得正確的應用，Hadoop確實能從根本上提高你公司的業務，然而這條Hadoop的應用之路卻充滿了荊棘。另外一個方面，許多企業（固然不是Google、Facebook或者Twitter）的數據體積並無大到須要巨型Hadoop集羣去作分析，他們純粹是被「大數據」這個熱門的詞語給吸引的。

就像Dabid Wheeler所說「計算機科學的全部問題都有另外一個層次間接的解決方案」，而Hadoop正是相似間接解決方案；當你的上司被一些流行詞彙所吸引時，作正確的軟件架構決策將變的很是艱難。

下文將給出一些對Hadoop進行投資前須要嘗試的替代方案：

瞭解你的數據

數據的整體積

Hadoop是爲大型數據集所創建的有效解決方案。

 

• GB級以上的文件系統HDFS。所以若是你的文件只是MB級的，你最好對數個文件進行整合（zip或者tar），讓其達到數百兆或者是幾GB。
• HDFS會將文件分割，並以64MB、128M或者更大的塊進行存儲。

 

若是你的數據集很是的小，那麼使用這個巨型生態系統將不會很適合。這須要對本身的數據有足夠的瞭解，而且分析須要什麼類型的查詢以及你的數據是否真的夠大。

另外一方面，鑑於你的計算指令可能很大，只經過數據庫去測量數據的體積可能會存在偏差。有時候數學計算或者分析小型數據集的排列可能會讓得出的結果遠大於實際數據體積，因此關鍵在於你對數據有切實的瞭解。

數據增加的速度

你可能在數據倉庫或者其它的數據源中存有數TB數據，然而在創建Hadoop集羣前有一個必須考慮的因素就是數據的增加速度。

對你的分析師提出幾個簡單的問題，好比：

 

• 數據增速究竟有多快？這些數據是否以很是快的速度增加？
• 幾月或者幾年後數據的體積究竟會有多大？

 

許多公司的數據增加都是按年算的。這種狀況下，你的數據增加速度其實並不快；因此這裏建議考慮歸檔和清除選項，而不是直接的奔往Hadoop。

如何減小需處理的數據

若是你確實有很是大致積的數據，你能夠考慮經過如下的途徑將數據縮減到很是適合管理的體積，如下的幾個選項已通過產業幾十年考驗。

考慮歸檔

數據存檔是對過時的數據進行分開存儲，固然存儲的時間根據實際需求制定。這須要對數據以及應用程序對數據的使用狀況，有很是充分的瞭解。好比電子商務公司的大數據處理只將3個月內的數據存入活躍數據庫，而舊訂單則被存入單獨的存儲。

這個途徑一樣能夠運用於你的數據倉庫。固然你能夠存儲更多的近期數據用於報告和查詢，使用頻度少的數據能夠被存入單獨的存儲設備。

考慮清除數據

有時候咱們一直忙於收集數據而不清楚究竟須要保存多少數據，若是你存儲了很是多用不到的數據，那麼這將毫無疑問的下降你有效數據的處理速度。弄清你的業務需求而且審查數據是否能夠被刪除，從中分析出你須要儲存數據的類型，這不只會節省你的存儲空間，一樣會提高有效數據的分析速度。

一個常常用到的最佳實踐就是給數據倉庫創建附加列，好比created_date、created_by、update_date及updated_by。經過這些附加列能夠對數據進行階段性的訪問統計，這樣就能夠清楚數據的有效週期。這裏須要着重對待的是數據清除的邏輯，切記先思考再實現。若是你使用了一個歸檔工具，那麼數據的清除將會變得很是容易。

不是全部的數據都很重要

你可能受不了儲存全部業務相關數據的誘惑，你可能有不少的數據來源，好比：日誌文件、營銷活動數據、ETL做業等。你須要明白不是全部數據都對業務起關鍵做用，並且在數據倉庫中保存全部的數據並非有益的。在數據源過濾掉不須要的數據，甚至是在儲存到數據倉庫以前。不要對全部的數據進行存儲，只分析你所需的數據。

注意哪些數據是你想要收集的

拿在線視頻編輯業務來講，你會須要保存你用戶作出的全部操做嗎？這樣的話可能會產生很是大的數據體積，若是你發現你的數據倉庫不足以應對這些數據，你可能會考慮只存儲元數據。雖然視頻編輯是個很是極端的例子，然而並不妨礙咱們在其它用例中考慮這些信息。

總而言之，根據業務的需求只收集所須要的數據。

智能分析

聘請了解業務的分析師

到目前爲止，你應該已經清楚理解數據的重要性；因此在你作了上面全部步驟後並決定使用Hadoop時，聘請1個瞭解業務的分析師將會對你業務產生巨大幫助。

若是數據分析師不懂如何從中獲取價值，那麼Hadoop將不會產生任何做用，不要吝嗇對業務有深入認識的僱員投資。鼓勵他們多作實驗，而且使用新的方式去分析同一個數據，找出使用現有基礎設施獲利的途徑。

爲決策制定使用統計抽樣

統計抽樣能夠說是很是古老的技術，研究者及數學家運用它在大致積數據上推斷合理的結論。經過這個步驟，咱們能夠大幅度的縮減數據體積。取代追蹤數十億或者數百萬的數據點，只須要跟蹤其中數千或者數百的數據點就能夠了。這個手段雖然不會給咱們提供精準的結果，可是卻能夠對大型的數據集有一個高等級的理解。

提高技術

你真的已經達到關係型數據庫處理的極限了嗎？

在探索其它領域以前，你更應該審視關係數據庫是否能夠繼續處理問題。傳統的關係型數據庫已經被使用了很長一段時間，而不少機構已經可使用它管理TB級的數據倉庫。因此在遷往Hadoop以前，不妨考慮如下的方法。

分割數據

數據切分是從邏輯上或物理上將數據分割成數個更好維護或訪問的部分，同時不少流行的開源關係型數據庫都支持分片（好比MySQL Partitioning及Postgres Partitionging）。

在傳統數據庫上考慮數據庫分片

數據庫分片是提高傳統關係型數據庫性能極限的最後一招，適用於數據能夠邏輯分片在不一樣節點上而且不多作跨節點join分享的狀況。在網絡應用程序中，基於用戶分片，並將用戶相關信息儲存在同一個節點上是提高性能的常見途徑。

分片有不少限制條件，因此並非適合全部場景，一樣在用例中存在太多的跨節點jion，分片將發揮不了任何做用。

總結

Hadoop的部署將耗費公司巨量的人力和物力，若是能經過提高現有基礎設施來達到目標也不失爲一良策。

原文：http://www.csdn.net/article/2013-07-19/2816277-hadoop-when-to-use

 

你的數據根本不夠大，別老扯什麼Hadoop了

 

本文原名「Don’t use Hadoop when your data isn’t that big 」，出自有着多年從業經驗的數據科學家Chris Stucchio，紐約大學柯朗研究所博士後，搞太高頻交易平臺，當過創業公司的CTO，更習慣稱本身爲統計學者。對了，他如今本身創業，提供數據分析、推薦優化諮詢服務，他的郵件是：stucchio@gmail.com 。

      有人問我，「你在大數據和Hadoop方面有多少經驗？」我告訴他們，我一直在使用Hadoop，可是不多處理幾TB以上數據的任務 。我基本上只是一個大數據新手——知道概念，寫過代碼，可是沒有大規模經驗。

      他們又問我，「你能使用Hadoop作簡單的group by(分組)和sum(統計)嗎？」我說固然能夠，但我會說須要看具體的文件格式。

他們給我一個U盤，裏面存儲600MB數據（他們全部的數據，而不是樣本數據）。不知道爲何，我用 pandas.read_csv（ Pandas是一種Python數據分析庫）解決方案，而不是Hadoop完成了這個任務後，他們顯得很不滿意。

      Hadoop其實是有不少侷限性的。Hadoop能夠運行一個通用的計算，下面我用僞碼進行說明：

Scala風格的僞碼：

collection.flatMap( (k,v) => F(k,v) ).groupBy( _._1 ).map( _.reduce( (k,v) => G(k,v) ) )

使用SQL風格的僞碼錶示：

SELECT G(...) FROM table GROUP BY F(...)

      或者想我多年解釋同樣：

目標：統計計算圖書館書籍的數量
Map：你統計奇數書架上書的數量，我統計偶數書架上書的數量。（作統計的人越多，統計出結果越快，就是機器越多，效率越高）
Reduce：把咱們每一個人單獨統計的結果數據加在一塊兒。

        咱們所作的只有兩個：F(k,v)和G(k,v)，除非要在中間步驟中作性能優化，其餘一切都是固定的。

    在Hadoop裏，全部計算都必須按照一個map、一個group by、一個aggregate或者這種計算序列來寫。這和穿上緊身衣同樣，多憋得慌啊。許多計算用其餘模型其實更適合。穿上緊身衣（使用hadoop）的惟一緣由就是，能夠擴展到極大的數據集。可大多數狀況，你的數據集極可能根本遠遠夠不上那個數量級。

    但是呢，由於Hadoop和大數據是熱詞，世界有一半的人都想穿上緊身衣，即便他們實際不須要Hadoop。

1、若是個人數據量是幾百兆，Excel可能無法加載它
        對於Excel來講的「很大的數據」並不是大數據，其實還有其它極好的工具可使用——我喜歡的是基於Numpy庫之上Pandas。它能夠將幾百MB數據以高效的向量化格式加載到內存，在我購買已3年的筆記本上，一眨眼的功夫，Numpy就能完成1億次浮點計算。Matlab和R也是極好的工具。

      Pandas構建於Numpy庫之上，能夠以矢量格式的方式有效地把數百兆的數據載入到內存中。在我購買已3年的筆記本上，它能夠用Numpy在一眨眼的功夫把1億的浮點數乘在一塊兒。Matlab和R也是極好的工具。
       所以，對於幾百兆的數據量，典型的作法是寫一個簡單的Python腳本逐行讀取，處理，而後寫到了一個文件就好了

2、可個人數據是10GB呢？
       我買了臺新筆記本，它有16GB的內存（花$141.98）和256GB的SSD(額外200美圓)。，若是在Pandas里加載一個10GB的csv文件，實際在內存裏並無那麼大（內存不是佔有10G）——能夠將 「17284932583」 這樣的數值串存爲4位或者8位整數，「284572452.2435723」存爲8位雙精度。

    最壞的狀況下你還能夠不一樣時將全部數據都一次加載到內存裏。

3、可個人數據是100GB、500GB或1TB呢？

     一個2T的硬盤才94.99美圓，4T是169.99。買一塊，加到桌面PC或者服務器上，而後裝上PostgreSQL來解決它

4、Hadoop << SQL或Python腳本

       在計算的表達能力來講，Hadoop比SQL差。Hadoop裏能寫的計算，在SQL或者簡單的Python腳本均可以更輕鬆地寫出來。
       SQL是一個直觀的查詢語言，適合作業務分析，業務分析師和程序員都很經常使用。SQL查詢很是簡單，並且還很是快——只有數據庫使用了正確的索引，要花幾秒鐘的sql查詢都不太常見。

     Hadoop沒有索引的概念，Hadoop只有全表掃描，並且Hadoop抽象層次太多了——我以前的項目盡在應付Java內存錯誤（  java memory errors）、內存碎片和集羣競用了，而這些時間遠多於實際的數據分析工做。

      若是你的數據並非像SQL表那樣的結構化數據（好比純文本、JSON對象、二進制對象），一般是直接寫一個小的Python腳本或者Ruby腳本逐行處理更直接。保存到多個文件，而後逐個處理便可，SQL不適用的狀況下，從編程來講Hadoop也沒那麼糟糕，但相比Python腳本仍然沒有什麼優點。

    除了難以編程，Hadoop還通常老是比其餘技術方案要慢。只要索引用得好，SQL查詢很是快。好比要計算join，PostgreSQL只需查看索引（若是有），而後查詢所需的每一個鍵。而Hadoop呢，必須作全表掃描，而後重排整個表。排序經過多臺機器之間分片能夠加速，但也帶來了跨多機數據流處理的開銷。若是要處理二進制文件，Hadoop必須反覆訪問namenode。而簡單的Python腳本只要反覆訪問文件系統便可。

5、個人數據超過了5TB

     只能使用Hadoop，而無需作過多的選擇。

    你的命可真苦——只能苦逼地折騰Hadoop了，沒有太多其餘選擇（可能還能用許多硬盤容量的高富帥機器來扛），並且其餘選擇每每貴得要命（腦海中浮現出IOE等等字樣……）。

    用Hadoop惟一的好處是擴展。若是你的數據是一個數TB的單表，那麼全表掃描是Hadoop的強項。此外的話（若是你沒有這樣大數據量的表），請關愛生命，儘可能遠離Hadoop。它帶來的煩惱根本不值，用傳統方法既省時又省力。

6、Hadoop是一個極好的工具          我並不討厭Hadoop，當我用其它工具不能很好處理數據時我會選擇Hadoop。另外，我推薦使用Scalding，不要使用Hive或Pig。Scalding支持使用Scala語言來編寫Hadoop任務鏈，隱藏了其下的MapReduce。