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個：
1、GFS（Google File System）。一個分佈式文件系統，隱藏下層負載均衡，冗餘複製等細節，對上層程序提供一個統一的文件系統API接口。Google根據自己的需求對它進行了特別優化，包括：超大文件的訪問，讀操作比例遠超過寫操作，PC機極易發生故障造成節點失效等。GFS把文件分成64MB的塊，分佈在集羣的機器上，使用Linux的文件系統存放。同時每塊文件至少有3份以上的冗餘。中心是一個Master節點，根據文件索引，找尋文件塊。詳見Google的工程師發佈的GFS論文。
2、MapReduce。Google發現大多數分佈式運算可以抽象爲MapReduce操作。Map是把輸入Input分解成中間的Key/Value對，Reduce把Key/Value合成最終輸出Output。這兩個函數由程序員提供給系統，下層設施把Map和Reduce操作分佈在集羣上運行，並把結果存儲在GFS上。
3、BigTable。一個大型的分佈式數據庫，這個數據庫不是關係式的數據庫。像它的名字一樣，就是一個巨大的表格，用來存儲結構化的數據。
以上三個設施Google均有論文發表。正是因爲有了以上的三項核心技術，才使得Google的分佈式框架很有創造性、擴展性，而且在系統吞吐量上有很大的競爭力。
結合上面講的一些背景，再來看一下Hadoop這個架構的核心技術吧！
主要是由HDFS、MapReduce和Hbase組成。HDFS是Google File System（GFS）的開源實現。MapReduce是Google MapReduce的開源實現。HBase是Google BigTable的開源實現。這裏就不多說了，具體的每個核心技術的原理會在後續的文章裏面一點一點的介紹，畢竟也是剛開始學，邊學邊成長吧！
Hadoop的一些特點
1、 擴容能力（Scalable）：能可靠地（reliably）存儲和處理千兆字節（PB）數據。在不保證低延時的前提下，具有相當大的吞吐量，非常適合海量數據的運算。
2、 成本低（Economical）：可以通過普通機器組成的服務器羣來分發以及處理數據。這些服務器羣總計可達數千個節點。而且每個節點都是運行在開源操作系統Linux上面的。
3、 高效率（Efficient）：通過分發數據，hadoop可以在數據所在的節點上並行地（parallel）處理它們，這使得處理非常的快速。
4、 可靠性（Reliable）：hadoop能自動地維護數據的多份複製，並且在任務失敗後能自動地重新部署（redeploy）計算任務。
Hadoop的不足之處
1、 該框架設計的初衷是針對海量數據的運算處理的問題。因此對於一些數據量很小的處理沒有任何優勢可言，甚至還不如單機串行的效果，性能也完全體現不出來。
2、 既然是海量數據的處理，優先考慮的是該系統的吞吐量等性能問題。所以也很難滿足平常的低時延的需求，這點是不可避免的，只能說想辦法儘量去權衡兩者，進而優化。
3、 集羣中存在大量的機器，所以節點故障是不可避免的。在Hadoop中有兩種類型的結點：namenode和datanode。Hadoop集羣採取的master/slave結構，分別對應namenode和datanode兩種類型。Datanode故障一般是不會影響整個系統的，這個和它的存儲策略有關。但是namenode故障是是極大的問題，如果namenode掛掉了，那問題就很嚴重。而且namenode的內存限制也是整個系統的瓶頸，這個在這裏就不多說，後面隨着慢慢的瞭解就知道了。
4、 其文件系統設計的前提是一次寫入多次讀取的情況，因此我們是無法修改某條詳細的數據，只能overwrite全部的數據，或者是在文件末尾追加數據。
5、 集羣內部是通過tcp/ip協議進行通信的，所以網絡帶寬也會成爲系統的瓶頸之一。
6、 系統內部的調度策略。在使用了Hadoop一段時間之後，感覺它的job調度策略不是很完善，沒能充分利用集羣資源展現出其全部的性能。
7、 採用Java實現。Java的IO處理雖然沒有性能瓶頸，但是對於CPU密集型的任務是一個噩耗。這點可以通過對比HBase和Hypertable兩個開源的Bigtable實現來做初步的驗證。
8、 開源項目。開源本身是一柄雙刃劍，它方便了大多數人，但是對於一個有一定規模的公司，項目發展方向的把握，技術保密和支持等都是採用Hadoop這種開源項目必須考慮的問題。另外，Hadoop作爲一個比較新的項目，性能和穩定性的提升還需要一定時間。
9、安全問題。如果對外提供服務就要對外開放端口，那就有可能成爲被攻擊的目標，所以這個問題在以後的商業應用中顯得尤爲重要。雖然並不清楚Hadoop的安全程度到底如何，但是這個是沒有止境的。道高一尺，魔高一丈。
10、任然使用的是行存儲。從相關資料上瞭解到列存儲在海量數據處理方面的優勢，覺得未來在這方面會有所改變。
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
本文原名“Don’t use Hadoop when your data isn’t that big ”，出自有着多年從業經驗的數據科學家Chris Stucchio，紐約大學柯朗研究所博士後，搞過高頻交易平臺，當過創業公司的CTO，更習慣稱自己爲統計學者。對了，他現在自己創業，提供數據分析、推薦優化諮詢服務，他的郵件是：[email protected] 。
他們又問我，“你能使用Hadoop做簡單的group by(分組)和sum(統計)嗎？”我說當然可以，但我會說需要看具體的文件格式。
- collection.flatMap( (k,v) => F(k,v) ).groupBy( _._1 ).map( _.reduce( (k,v) => G(k,v) ) )
- SELECT G(...) FROM table GROUP BY F(...)
- 目標：統計計算圖書館書籍的數量
- Map：你統計奇數書架上書的數量，我統計偶數書架上書的數量。（做統計的人越多，統計出結果越快，就是機器越多，效率越高）
- Reduce：把我們每個人單獨統計的結果數據加在一起。
在Hadoop裏，所有計算都必須按照一個map、一個group by、一個aggregate或者這種計算序列來寫。這和穿上緊身衣一樣，多憋得慌啊。許多計算用其他模型其實更適合。穿上緊身衣（使用hadoop）的唯一原因就是，可以擴展到極大的數據集。可大多數情況，你的數據集很可能根本遠遠夠不上那個數量級。
可是呢，因爲Hadoop和大數據是熱詞，世界有一半的人都想穿上緊身衣，即使他們實際不需要Hadoop。
對於Excel來說的“很大的數據”並非大數據，其實還有其它極好的工具可以使用——我喜歡的是基於Numpy庫之上Pandas。它可以將幾百MB數據以高效的向量化格式加載到內存，在我購買已3年的筆記本上，一眨眼的功夫，Numpy就能完成1億次浮點計算。Matlab和R也是極好的工具。
因此，對於幾百兆的數據量，典型的做法是寫一個簡單的Python腳本逐行讀取，處理，然後寫到了一個文件就行了
二、可我的數據是10GB呢？
我買了臺新筆記本，它有16GB的內存（花$141.98）和256GB的SSD(額外200美元)。，如果在Pandas里加載一個10GB的csv文件，實際在內存裏並沒有那麼大（內存不是佔有10G）——可以將 “17284932583” 這樣的數值串存爲4位或者8位整數，“284572452.2435723”存爲8位雙精度。
三、可我的數據是100GB、500GB或1TB呢？
四、Hadoop << SQL或Python腳本
在計算的表達能力來說，Hadoop比SQL差。Hadoop裏能寫的計算，在SQL或者簡單的Python腳本都可以更輕鬆地寫出來。
SQL是一個直觀的查詢語言，適合做業務分析，業務分析師和程序員都很常用。SQL查詢非常簡單，而且還非常快——只有數據庫使用了正確的索引，要花幾秒鐘的sql查詢都不太常見。
五、我的數據超過了5TB
只能使用Hadoop，而無需做過多的選擇。
你的命可真苦——只能苦逼地折騰Hadoop了，沒有太多其他選擇（可能還能用許多硬盤容量的高富帥機器來扛），而且其他選擇往往貴得要命（腦海中浮現出IOE等等字樣……）。
用Hadoop唯一的好處是擴展。如果你的數據是一個數TB的單表，那麼全表掃描是Hadoop的強項。此外的話（如果你沒有這樣大數據量的表），請關愛生命，儘量遠離Hadoop。它帶來的煩惱根本不值，用傳統方法既省時又省力。
六、Hadoop是一個極好的工具我並不討厭Hadoop，當我用其它工具不能很好處理數據時我會選擇Hadoop。另外，我推薦使用Scalding，不要使用Hive或Pig。Scalding支持使用Scala語言來編寫Hadoop任務鏈，隱藏了其下的MapReduce。
再分享一下我老師大神的人工智能教程吧。零基礎！通俗易懂！風趣幽默！還帶黃段子！希望你也加入到我們人工智能的隊伍中來！https://blog.csdn.net/jiangjunshow