Hadoop實戰讀書筆記（1）

編寫可擴展、分佈式的數據密集型程序的基礎知識

爲何數據量很大？

在當今社會，咱們正在被數據包圍，人們上傳視頻、用手機照相、發短信給朋友、更新Facebook、網上留言以及點擊廣告等，都產生大量的數據。重要的是，服務提供者不能不這些數據隨便的刪除，如何存儲這些數據就成爲了難題。

 

數據以指數級的增加！~也就是U的右半邊

數據的增加首先對像谷歌、雅虎、亞馬遜、微軟、Facebook、騰訊、百度、阿里等等公司提出了挑戰。如何存儲、如何分析，他咩的。

 

存儲這些數據是有必要的，可是幹嗎要進行分析呢？

你可能有這樣的需求，遍歷全部的數據發現哪些網站更受歡迎，哪些書籍有需求，哪一種廣告吸引人。若是知道了以上這些，對公司的商業發展會有很大幫助，會產生不少利潤。可是數據的量級倒是TB或者PB級別（1TB=1024GB、 1PB=1024TB），你須要在這麼大的數據上進行遍歷。

 

他們怎麼作了？

谷歌率先推出了MapReduce計算模型，針對本身公司的業務需求。

Doug Cutting看到機會，參考Google的論文，領導開發了一個開源版本的MapReduce，稱爲Hadoop

雅虎等公司紛紛響應，爲其提供支持。

如今Hadoop已經成爲許多互聯網公司的基礎計算平臺的一個核心部分，如雅虎、Facebook、LinkedIn和Twitter。

許多傳統行業、傳媒業和電信業也開始採用這個系統，如《紐約時報》、中國移動和IBM等公司

 

做爲程序員我感受鴨梨好大呀！~

Hadoop及大規模分佈式數據處理，正在迅速成爲許多程序員的一項重要技能，傳統的關係數據庫、網絡和安全也須要掌握，做爲一個高效的程序員的必修課。

斯坦福和卡內基-梅隆等一流的大學已經開始將Hadoop引入他們的計算機科學課程。

 

什麼是Hadoop？

Hadoop是一個開源框架，可編寫和運行分佈式應用處理大規模數據。

 

Hadoop不同凡響之處是？

方便：通常商用機器構成的大型集羣或者其餘雲計算服務，俗稱：一羣屌絲頂個高富帥

健壯：容錯機制，由於是通常的商用機器，因此硬件故障不能保證。Hadoop認爲一臺主機故障是常態，但不會影響集羣的運行。

可擴展：經過增長集羣的節點，能夠線性的擴展以處理更大的數據集。

簡單：Hadoop容許用戶快速、高效的編寫出並行代碼，而不須要關注具體並行的實現，只要按她的模式走便可。

亞馬遜的彈性計算雲（EC2）等雲計算服務是啥？

 

Hadoop集羣是什麼？

同一地點用網絡互聯的一組通用機器，由於有不少機器，因此也稱爲"機器雲" "雲"

另外：一般在一個Hadoop集羣中的機器都是相對同構的X86 Linux服務器，並且它們集合老是位於同一個數據中心，並一般在同一組機架裏。

 

什麼是機架？

搭載計算機的架子，一個機架裏面有不少計算機。

 

什麼是摩爾定律？

摩爾定律是由英特爾（Intel）創始人之一戈登·摩爾（Gordon Moore）提出來的。其內容爲：當價格不變時，集成電路上可容納的晶體管數目，約每隔18個月便會增長一倍，性能也將提高一倍。換言之，每一美圓所能買到的電腦性能，將每隔18個月翻一倍以上。

 

摩爾定律說明硬件性能的提高，就能夠解決大規模計算的問題嗎？

固然能夠，但不能全靠超級計算機，由於這種難度會很大，古代的中國人在使用牛拉木頭的時候，會使用多個牛來拉木頭，而不是培養出更強壯的牛。

有一種替代方案已經得到普及，即把許多低端、商用的機器組織在一塊兒，造成一個功能專注的分佈式系統。

 

分佈式系統（俗稱向外擴展）與大型單機服務器（俗稱向上擴展）之間的對比？

一臺擁有4個I/O通道的高端機，即便每一個通道的吞吐量各位100MB/s，讀取4TB數據也須要3個小時。

利用Hadoop，一樣的數據集會被劃分爲較小的塊 （一般64MB），經過Hadoop分佈式文件系統(HDFS)分佈在集羣內多臺機器上。集羣能夠並行讀取數據，進而提供很高的吞吐量。

而這樣一組通用機器比一臺高端服務器更加便宜。

 

SETI@home 是什麼？

SETI@home 是一項利用全球聯網的計算機共同搜索外星生命的科學實踐計劃。

在世界各地計算機屏保的時候協助尋找外星生命，這樣不會影響用戶的使用。

在SETI@home ，一臺中央服務器存儲來自太空的無線電信號，並在上網發佈給世界各地的客戶端臺式機去尋找異常的跡象。通過客戶端的計算後，再將返回的數據結果存儲起來。

 

什麼是CPU bound（計算密集型）？

CPU bound與I/O密集型相反

 

什麼是I/O bound（I/O密集型）？

I/O bound指的是系統的CPU效能相對硬盤/內存的效能要好不少，此時，大部分的情況是CPU在等待I/O的讀寫

 

Hadoop與其餘分佈式系統架構進行比較？

SETI@home 須要客戶端和服務器之間重複傳輸數據，但因爲數據規模太大，數據遷移變得十分困難。

Hadoop是代碼向數據遷移的理念，Hadoop集羣內部既包含數據又包含計算環境，客戶端僅須要發送待執行的MapReduce程序，而這些程序通常很小。而且，數據被拆分後再集羣中分佈，而且儘量讓一段數據的計算髮生在同一臺機器上。

 

代碼向數據遷移的優點？

讓數據不動（數據很大），讓代碼移動到數據所在的機器上。

 

傳統SQL數據庫與Hadoop比較一下？

關於設計理念

SQL(結構化查詢語言)是針對結構化數據設計的。

Hadoop是針對文本這種非結構化數據設計的。

這樣看來Hadoop提供了一種更爲通用的模式。

更加詳細的比較：

1、用向外擴張代替向上擴展

擴展商用關係型數據庫的代價很是昂貴，性能4倍於標準的PC的機器，成本將大大超過一樣的4臺PC放在一個集羣中。一個Hadoop集羣的標配是十至數百臺計算機。

2、用鍵/值對代替關係表

關係型數據庫的一個基本原則是按某種模式存放具備關係型數據結構的表中，可是不能很好的適合文本、圖片、和XML文件等數據類型。

大型數據集每每是非結構化或半結構化的，在Hadoop中數據的來源能夠是任何形式，但最終會轉化爲鍵/值對。

3、用函數式編程（MapReduce）代替聲明式查詢（SQL）

SQL使用查詢語句，聲明想要查詢的結果，讓數據庫引擎斷定如何獲取數據。

MapReduce使用腳本和代碼，比SQL查詢更爲通常化的數據處理方式，例如，你能夠創建複雜的數據統計模型，或者改變圖像數據的格式。而SQL就不能很好的適應這些任務。

4、用離線批量處理代替在線處理

Hadoop是專爲離線處理和大規模數據分析而設計的，它並不適合那種對幾個記錄隨機讀寫的在線事務處理模式。

Hadoop最適合一次寫入，屢次讀取的數據存儲需求，在這方面它就像SQL的數據倉庫。

 

什麼是管道數據處理模型，什麼是消息隊列數據處理模型？

 

什麼是MapReduce數據處理模型？

這種模型最大的優勢是容易擴展到多個計算節點上處理數據。在MapReduce模型中，數據的處理原語被稱爲mapper和reducer

 

練習，統計一組文檔中的每一個單詞出現的次數？

考慮這樣一種場景：一個文件，文件裏只有一句話 Do as I say， not as do. ，統計單詞出現的次數。

define wordCount as Multiset;

for each document in documentSet {

       T = tokenize (document);

       for each token in T {

              wordCount[token]++;

       }

}

display(wordCount);

單詞	計數
as	2
Do	2
i	1
not	1
say	1

改程序循環遍歷全部文檔。對於每一個文檔，使用分詞過程逐個地提取單詞。對於每一個單詞，在多重集合wordCount中的相應項上加1.最後display()函數打印出wordCount中的全部條目。

這個程序只適合少許的文檔，使用單臺計算機反覆遍歷全部文檔將會很是費時。

 

那麼，如何解決該問題？

可讓工做分佈到多臺機器上，每臺機器處理這些文檔的不一樣部分，當全部的機器都完成時，將合併這些結果。

第一階段分佈到多臺機器：

// 僞代碼

define wordCount as Multiset;

for each document in documentSet {

       T = tokenize (document);

       for each token in T {

              wordCount[token]++;

       }

}

sendToSecondPhase(wordCount);

第二階段合併這些結果

// 僞代碼

for each wordCount received from firstPhase {

       multisetAdd (totalWordCount, wordCount);

}

 

上邊的代碼不是很難對麼？可是忽略了一些細節。

缺陷1：咱們忽略了文檔讀取的性能要求，若是文件存在一箇中央存儲服務器上，那麼瓶頸就是該服務器的帶寬。所以，你須要將文檔分開存放，使每臺機器能夠僅處理本身所存儲的文檔。（這也呼應了數據密集型分佈式應用中存儲和處理不得不緊密地綁定在一塊兒）

缺陷2：忽略了wordCount被存儲在內存中，當處理大型文檔集時，一個特定單詞的數量就會超過一臺機器的內存。因此咱們不得不改寫程序，以便在磁盤上存儲該散列表。這意味着咱們將實現一個基於磁盤的散列表，其中設計大量的編碼。

缺陷3: 第二階段只有一臺計算機，它將處理來自全部計算機在第一個階段計算的wordCount的結果。wordCount的處理任務本來就至關繁重，第二階段的單臺計算機將成爲瓶頸。

 

那麼，針對以上缺陷將如何應對？

解決缺陷3，咱們可否按分佈模式重寫第二階段，以便它能夠經過增長更多的計算機來實現擴展？

須要在第一階段以後將wordCount分區，使得第二階段的每臺計算機僅需處理一個分區。

舉個例子，假設咱們在第二階段有26臺計算機。咱們讓每臺計算機上的wordCount只處理以特定字母開頭的單詞。例如，計算機A在第二階段統計以字母a開頭的單詞。爲了在第二階段中實現這種劃分，咱們須要對第一階段稍微修改。再也不採用基於磁盤的散列表實現wordCount，而是劃分出26個表：wordCount-a、wordCount-b等。每一個表統計以特定字母開頭的單詞。通過第一階段，來自該階段全部計算機的wordCount-a結果將被髮送到第二階段的計算機A上，全部wordCount-b的結果將被髮送到計算機B上，依次類推。第一階段中的每臺計算機都會將結果洗牌到第二階段計算機上。

 

如今單詞統計程序正變得複雜，爲了使它工做在一個分佈式計算機集羣上，咱們發現須要添加如下功能：

存儲文件到許多臺計算機上 (第一階段)

編寫一個基於磁盤的散列表，使得處理不受內存容量限制

劃分來自第一階段的中間數據 (即wordCount)

洗牌這些分區到第二階段中合適的計算機上

 

爲何使用Hadoop？

即便對於單詞統計這樣簡單的程序，這都是繁重的工做，而咱們甚至尚未涉及容錯的問題。

（若是在任務執行過程當中一個計算機失效該怎麼辦？）這就是咱們須要一個像Hadoop同樣的框架。當你用MapReduce模型來寫應用程序，Hadoop將替你管理全部與可擴展性相關的底層問題。