學好hadoop不是一朝一夕的事情此文件簡略僅適用於初入門做了解使用，若想深入學習請使用《hadoop權威指南》

hadoop模組：

Hadoop Common：支援其他Hadoop模組的常用實用程式。

Hadoop分散式檔案系統（HDFS™）：一種分散式檔案系統，可提供對應用程式資料的高吞吐量訪問。

Hadoop YARN：作業排程和叢集資源管理的框架。

Hadoop MapReduce：基於YARN的系統，用於並行處理大型資料集。（一種計算框架）

Hadoop Ozone： Hadoop的物件儲存。（後來新增）

 

三種執行模式：

本地（獨立）模式

：

Hadoop配置為以非分散式模式執行，作為單個Java程序。這對除錯很有用

偽分散式模式： 

Hadoop還可以在偽分散式模式下在單節點上執行，其中每個Hadoop守護程式在單獨的Java程序中執行

在一臺機器上執行hdfs檔案系統，執行mr程式，從hdfs上獲取資料，結果存放到hdfs上

完全分散式模式：

執行在多臺機器上，同時只有一個hdfs系統

10.12

hdfs體系結構（主、/從結構）

圖參照官方文件

 

 

namenode：維護名稱空間、儲存元資料和使用者對hdfs的操作、副本數等

管理檔案系統名稱空間的主伺服器,和管理客戶端對檔案的訪問組成,塊到DataNode的對映

datanode:   存放實際資料（塊）

連線到它們執行的節點的儲存

提供來自檔案系統客戶端的讀寫請求

執行塊的建立，刪除

secondarynamenode：輔助namenode進行工作（檢查點儲存）

hdfs的設計理念

硬體故障是常態而非例外。HDFS例項可能包含數百或數千臺伺服器計算機，每臺計算機都儲存檔案系統資料的一部分。事實上，存在大量元件並且每個元件具有非平凡的故障概率意味著HDFS的某些元件始終不起作用。

因此，檢測故障並從中快速自動恢復是HDFS的核心架構目標。

 

在HDFS上執行的應用程式需要對其資料集進行流式訪問。

它們不是通常在通用檔案系統上執行的通用應用程式。HDFS設計用於批處理而不是使用者的互動式使用。

重點是資料訪問的高吞吐量而不是資料訪問的低延遲。

POSIX強加了許多針對HDFS的應用程式不需要的硬性要求。

交易幾個關鍵領域的POSIX語義以提高資料吞吐率。

 

在HDFS上執行的應用程式具有大型資料集。HDFS中的典型檔案大小為千兆位元組到太位元組。

因此，HDFS被調整為支援大檔案。它應該提供高聚合資料頻寬並擴充套件到單個叢集中的數百個節點。

它應該在單個例項中支援數千萬個檔案。

 

HDFS應用程式需要一個一次寫入多次讀取的檔案訪問模型。

除了追加和截斷之外，無需更改建立，寫入和關閉的檔案。支援將內容附加到檔案末尾，但無法在任意點更新。該假設簡化了資料一致性問題並實現了高吞吐量資料訪問。

MapReduce應用程式或Web爬蟲應用程式完全適合此模型。

 

應用程式請求的計算如果在其操作的資料附近執行則更有效。

當資料集的大小很大時尤其如此。這可以最大限度地減少網路擁塞並提高系統的整體吞吐量。

假設通常更好的是將計算遷移到更靠近資料所在的位置，而不是將資料移動到執行應用程式的位置。

HDFS為應用程式提供了介面，使其自身更靠近資料所在的位置。

資料塊

儲存在hdfs中的最小單位

預設大小128M

這麼大的原因：

為了最小化定址開銷，一般定址時間為10ms，傳輸速率為100MB/s

為了定址時間佔傳輸時間的1%，所以。。。。

10.13

元資料：

檢視fsimage

整個檔案系統名稱空間（包括塊到檔案和檔案系統屬性的對映）

hdfs oiv -i 要檢視的檔名 -o輸出的檔名 -p XML

檢視edites

檔案系統元資料發生的每個更改

hdfs oev -i 要檢視的檔名 -o輸出的檔名

 

namenode啟動過程

載入fsimage

載入edites

進行檢查點儲存

等待datanode彙報塊資訊

 

datanode啟動後

掃描本地塊的資訊

彙報給namenode

 

心跳機制

datanode每隔三秒彙報給namenode

 

檢查點（執行時主要由secondarynamenode完成）

它從磁碟讀取FsImage和EditLog，將EditLog中的所有事務應用到FsImage的記憶體中表示，並將此新版本重新整理為磁碟上的新FsImage。然後它可以截斷舊的EditLog，因為它的事務已應用於永續性FsImage

 

 

10.15

機架感知：

檢查兩臺機器是否在同一機架上

NameNode通過Hadoop Rack Awareness中概述的過程確定每個DataNode所屬的機架ID 。

一個簡單但非最優的策略是將複製品放在獨特的機架上。這可以防止在整個機架發生故障時丟失資料，並允許在讀取資料時使用來自多個機架的頻寬。此策略在群集中均勻分佈副本，這樣可以輕鬆平衡元件故障的負載。但是，此策略會增加寫入成本，因為寫入需要將塊傳輸到多個機架。

 

副本存放策略：

基於機架感知

當複製因子為3時，HDFS的放置策略是在編寫器位於datanode上時將一個副本放在本地計算機上，否則放在隨機datanode上，另一個副本放在另一個（遠端）機架上的節點上，

最後一個在同一個遠端機架的不同節點上。此策略可以減少機架間寫入流量，從而提高寫入效能。

機架故障的可能性遠小於節點故障的可能性; 此策略不會影響資料可靠性和可用性保證。

但是，它確實減少了讀取資料時使用的聚合網路頻寬，因為塊只放在兩個唯一的機架而不是三個。

使用此策略時，檔案的副本不會均勻分佈在機架上。三分之一的副本位於一個節點上，

三分之一的副本位於一個機架上的其他節點，另外三分之一均勻分佈在剩餘的機架上。此策略可提高寫入效能，而不會影響資料可靠性或讀取效能。

網路頻寬 22

大型HDFS例項在通常分佈在許多機架上的計算機群集上執行。不同機架中兩個節點之間的通訊必須通過交換機。

在大多數情況下，同一機架中的計算機之間的網路頻寬大於不同機架中的計算機之間的網路頻寬。

 

資料磁碟故障：

心跳和重新複製

每個DataNode定期向NameNode傳送Heartbeat訊息。網路分割槽可能導致DataNode的子集失去與NameNode的連線。

NameNode通過缺少Heartbeat訊息來檢測此情況。NameNode將DataNodes標記為沒有最近的Heartbeats，並且不會將任何新的IO請求轉發給它們。註冊到死DataNode的任何資料都不再可用於HDFS。

DataNode死亡可能導致某些塊的複製因子低於其指定值。NameNode不斷跟蹤需要複製的塊，並在必要時啟動複製。由於許多原因可能會出現重新複製的必要性：DataNode可能變得不可用，副本可能會損壞，DataNode上的硬碟可能會失敗，標記DataNodes宕機的超時是保守的長（預設情況下超過10分鐘），以避免由DataNode狀態抖動引起的複製風暴。

 

均衡器

使忙碌的datanode上的塊複製到相對空閒的datanode上，確保每個datanode使用率接近叢集的使用率

start-balancer.sh

 

資料的完整性

從DataNode獲取的資料塊可能已損壞。由於儲存裝置中的故障，網路故障或有缺陷的軟體，可能會發生此損壞。HDFS客戶端軟體對HDFS檔案的內容進行校驗和檢查。當客戶端建立HDFS檔案時，它會計算檔案每個塊的校驗和，並將這些校驗和儲存在同一HDFS名稱空間中的單獨隱藏檔案中。

當客戶端檢索檔案內容時，它會驗證從每個DataNode接收的資料是否與儲存在關聯校驗和檔案中的校驗和相匹配。

如果不是，則客戶端可以選擇從具有該塊的副本的另一個DataNode中檢索該塊。

 

檔案刪除和取消刪除:

如果啟用了垃圾箱配置，則FS Shell刪除的檔案不會立即從HDFS中刪除。

相反，HDFS將其移動到垃圾目錄（每個使用者在/user/<username>/.Trash下都有自己的垃圾目錄）。

只要檔案保留在垃圾箱中，檔案就可以快速恢復。

 

最近刪除的檔案被移動到當前的垃圾箱目錄（/user/<username>/.Trash/Current），並且在可配置的時間間隔內，HDFS建立了檢查點（在/ user / <username> / .Trash / <date>下）

對於當前垃圾目錄中的檔案，並在過期時刪除舊檢查點。有關垃圾箱的檢查點，

請參閱FS shell的expunge命令。

 

它的生命週期在垃圾箱中到期後，NameNode將從HDFS名稱空間中刪除該檔案。

刪除檔案會導致釋放與檔案關聯的塊。

請注意，在使用者刪除檔案的時間與HDFS中相應增加的可用空間之間可能存在明顯的時間延遲。

 

減少複製因子

在副本數大於設定的副本數時進行

當檔案的複製因子減少時，NameNode選擇可以刪除的多餘副本。下一個Heartbeat將此資訊傳輸到DataNode。

然後，DataNode刪除相應的塊，並在群集中顯示相應的可用空間。

再一次，setReplication API呼叫完成與叢集中可用空間的出現之間可能存在時間延遲。

 

塊快取：

預先讀取檔案的塊到記憶體，用來提升常用檔案的讀取效率

 

10.22

寫流程：

1.載入配置檔案（參照上節課）

2.獲取檔案系統（參照上節課）

3.建立寫入路徑（Path）

4.建立輸出流

 

10.23

mapreduce:填空式程式設計

MapReduce是一個分散式計算框架

分而治之-資料在哪計算在哪

兩個階段

map（對映）階段

reduce（規約或合併）階段

 

MapReduce作業的輸入和輸出型別：

 

（輸入）<k1，v1> - > map - > <k2，v2> - > combine - > <k2，v2> - > reduce - > <k3，v3>（輸出）

輸入和輸出的KV對必須由框架序列化

將結構化物件轉換為位元組流-----方便在網路傳輸和寫入磁碟

 

 

10.25

Mapper

將輸入鍵/值對對映到一組中間鍵/值對。

將   K1和V1    對映到      K2和V2

對映是將輸入記錄轉換為中間記錄的單個任務。

轉換後的中間記錄不需要與輸入記錄具有相同的型別。

給定的輸入對可能對映到零或多個輸出對。

執行一次map只對一行記錄進行處理，K1V1和K2V2不需要具有相同型別

 

Hadoop map - reduce框架為作業的InputFormat生成的每個InputSplit生成一個map任務。

Mapper實現可以通過JobContext.getConfiguration()訪問作業的配置。

InputFormat對檔案進行切分，一般情況檔案有幾個塊就會被切分成幾個InputSplit，每一個InputSplit產生一個map任務，   檔案130M ，2個塊   128M    2M  1.1   InputSplit數是1

InputSplit是邏輯切分

Block是物理的

 

mapper框架的呼叫順序

框架首先呼叫

setup(org.apache.hadoop.mapreduce.Mapper.Context)，

然後為InputSplit中的每個鍵/值對呼叫

map(Object, Object, org.apache. mapreduce. mapper . context)。

最後呼叫

cleanup(org.apache.hadoop.mapreduce.Mapper.Context)。

 

與給定輸出鍵關聯的所有中間值隨後由框架分組，並傳遞給一個Reducer，以確定最終的輸出。

使用者可以通過指定兩個關鍵的RawComparator類來控制排序和分組。

 

map輸出按每個reduce進行分割槽

使用者可以通過實現自定義分割槽器來控制哪個鍵(以及相應的記錄)到哪個Reducer。

使用者可以選擇通過Job.setCombinerClass(Class)指定一個組合器來執行中間輸出的本地聚合，這有助於減少從對映器到還原器的資料傳輸量。

如果reduce數為零，那麼mapper的輸出將直接寫入OutputFormat，而無需按鍵排序。

 

 

 

Mapper的組成

setup(Context context)

在任務一開始的時候呼叫一次

map(KEYIN key, VALUEIN value, Context context)

對於inputslipt中的每個鍵/值對呼叫一次。大多數應用程式應該重寫它，但是預設的是identity函式。

cleanup(Context context )

在任務結束的時候呼叫一次

run(Context context)

專家使用者專用，以獲取完成的控制權

 

reducer

減少一組中間值，這些中間值與一組較小的值共享一個鍵。

多個Mapper產生K2V2合併到一起具有相同的K2

 

reducer主要有三個階段

1.Shuffle（一部分）：

Reducer通過網路使用HTTP從每個mapper複製排序的輸出（K2V2）。

2.Sort：

框架合併按鍵對reducer輸入進行排序(因為不同的mapper可能輸出相同的鍵)。

shuffle和sort階段是同時發生的，也就是說，在提取輸出時，它們是合併的。

SecondarySort ：

要對值迭代器返回的值進行二級排序，應用程式應該使用二級鍵擴充套件鍵並定義一個分組比較器。

鍵將使用整個鍵進行排序，但將使用分組比較器進行分組，以決定在同一個呼叫中傳送哪些鍵和值以進行縮減。

分組比較器是通過Job.setGroupingComparatorClass(Class)指定的。

排序順序由Job.setSortComparatorClass(Class)控制。

例如，假設您希望找到重複的web頁面，並將它們都標記為“最知名”示例的url。你會這樣做:

地圖輸入鍵:url

地圖輸入值:文件

地圖輸出鍵:文件校驗和，url pagerank

地圖輸出值:url

瓜分者:通過校驗和

OutputKeyComparator:通過校驗和然後減少pagerank

OutputValueGroupingComparator:通過校驗和

3、Reduce 

在這個階段中，對於排序輸入中的每個<key(值的集合)>

呼叫reduce(物件、Iterable、org.apache.hadoop.mapreduce. reduce. context)方法。

reduce任務的輸出通常通過上下文寫入記錄寫入器。寫(物件,物件)。

 

總結：

reducer個數由job.setNumReduceTasks(tasks)控制。

程式有多少個輸出結果reducer個數，如果沒有reducer那麼由mapper個數

mapper個數由inputsplit控制，inputsplit數由塊數控制

注意： 如果一個檔案大小 小於塊大小*1.1   大於塊大小  有2個塊 有1個inputsplit

 

 

 

10.26

InputFormat:

InputFormat描述了Map-Reduce作業的輸入規範。

Map-Reduce框架依賴於作業的InputFormat:

1.驗證job的輸入規範。

2.將輸入檔案分解為邏輯inputsplit，每個inputsplit都被分配給一個單獨的mapper。

3.提供RecordReader實現，用於從邏輯InputSplit中收集輸入記錄，以便mapper進行處理。

基於檔案的inputformat(通常是FileInputFormat的子類)的預設行為是根據輸入檔案的總大小(以位元組為單位)

將輸入拆分為邏輯inputsplit。但是，輸入檔案的檔案系統塊大小被視為輸入分割的上限。

可以通過mapreduce.input.fileinputformat.split.minsize設定分割大小的下界。

 

FileInputFormat:

isSplitable(FileSystem fs, Path filename)

是否切分

getSplits(JobConf job, int numSplits)

獲取邏輯切分

TextInputFormat：

FileInputFormat預設使用這個

isSplitable是否可切分

判斷是否壓縮，如果沒有壓縮返回true

判斷是否屬於可以切分的壓縮模式，若屬於返回true

壓縮

檔案壓縮的兩大好處：減少儲存檔案所需要的磁碟空間，並加速資料網路和磁碟上的傳輸

詳見權威指南99頁

 

壓縮格式對於Hadoop平臺和MR計算時是透明的，Hadoop能夠自動將壓縮檔案進行解壓，不需要我們關心。Hadoop會根據副檔名自動選擇解碼器進行解壓，也可以人為的指定輸入格式。

壓縮演算法比較：

壓縮格式	split	native	壓縮率	速度	是否hadoop自帶	linux命令	換成壓縮格式後，原來的應用程式是否要修改
gzip	否	是	很高	比較快	是，直接使用	有	和文字處理一樣，不需要修改
lzo	是	是	比較高	很快	否，需要安裝	有	需要建索引，還需要指定輸入格式
snappy	否	是	比較高	很快	否，需要安裝	沒有	和文字處理一樣，不需要修改
bzip2	是	否	最高	慢	是，直接使用	有	和文字處理一樣，不需要修改

 

壓縮格式	codec類	演算法	副檔名	多檔案	splitable	native	工具	hadoop自帶
gzip	GzipCodec	deflate	.gz	否	否	是	gzip	是
bzip2	Bzip2Codec	bzip2	.bz2	是	是	否	bzip2	是
lzo	LzopCodec	lzo	.lzo	否	是	是	lzop	否
snappy	SnappyCodec	snappy	.snappy	否	否	是	無	否
LZ4		LZ4	.lz4	否			無

 

效能對比

壓縮格式	壓縮比	壓縮速率	解壓速率
gzip	13.4%	21 MB/s	118 MB/s
lzo	20.5%	135 MB/s	410 MB/s
snappy	22.2%	172 MB/s	409 MB/s
bzip2	13.2%	2.4MB/s	9.5MB/s

 

LineRecordReader：

將鍵視為檔案中的偏移量，將值視為行。

next（）

給下一個KV賦值

 

對aa.txt檔案可能被分成兩個塊進行分析分別求奇數偶數行和

如何判斷奇偶行？？？

重寫TextInputFormat

isSplitable

getRecordReader

重寫LineRecordReader

構造方法

next

編寫mapper

編寫reducer

編寫驅動

注意版本選擇老版本的

 

10.29

RecordReader：

記錄閱讀器將資料分解為鍵/值對，以供對映器輸入。

 

Partitioner：

分割槽鍵空間。

<p><code>Partitioner</code>控制中間對映輸出鍵的分割槽。鍵(或鍵的子集)用於派生

分割槽，通常通過雜湊函式。分割槽的總數與任務的reduce任務的總數相同。因此,控制

哪個<code>m</code> reduce任務的中間鍵(因此記錄)被髮送到reduce任務。</p>

 

getPartition獲取分割槽的數量一定要小於等於reduce任務數

 

shuffle：

將map輸出作為輸入傳遞給reduce的過程：詳情見權威指南7.3-------》詳詳情見原始碼

將map方法的結果寫入到緩衝區

進行分割槽排序溢寫到磁碟

合併到磁碟

reduce端請求資料（分割槽好的資料）

reduce端進行合併

傳遞給reduce方法

 

10.30

combiner：

稱為map端reduce

減少磁碟IO和網路頻寬的使用

如果實現combiner，繼承reducer類，一般情況下和自定義的reducer為同一個類

 

10.31

WritableComparable:

 writablecom可以相互比較，任何型別想要被當成hadoop

 map-reduce框架的key需要實現此介面

 

11.01

yarn:

是hadoop的叢集資源管理系統，hadoop2之後引進，入了支援mapreduce還支援其他的計算框架

執行機制：

參照權威指南79

與jobtracker和tasktracker相比

可擴充套件性：

mapreduce 1節點數4000，任務數4000達到瓶頸，yarn節點數10000，任務數100000

可用性：

守護程序失敗，可以快速恢復工作

利用率：

mapreduce 1裡面是固定分配資源的，yarn動態分配資源

 

 

 

 

三種排程策略（排程器）

FIFO：先進先出排隊執行

容器排程器：

公平排程器：

mapreduce作業執行機制：權威指南185

執行job

向資源管理器請求一個新的應用id

將作業所需的資源上傳到共享檔案系統

提交作業

排程器分配一個容器，資源管理器在節點管理器幫助下啟動一個app master

初始化作業

在共享檔案系統獲取輸入分片

請求資源管理器分配資源

啟動其他節點的容器為了map任務和reduce任務

獲取共享檔案系統裡面的資源（作業的配置、jar檔案等）

執行map任務和reduce任務

 

11.02

hadoop HA(高可用)

Quorum Journal Manager:

以共享活動和備用NameNode之間的編輯日誌

影響了HDFS叢集（導致namenode發生故障）

對於計劃外事件（例如計算機崩潰），在操作員重新啟動NameNode之前，群集將不可用。

計劃維護事件（如NameNode計算機上的軟體或硬體升級）將導致群集停機時間視窗。

注意：必須至少有3個JournalNode守護程序，因為編輯日誌修改必須寫入大多數JN。

這將允許系統容忍單個機器的故障。您也可以執行3個以上的JournalNodes，但為了實際增加系統可以容忍的失敗次數，您應該執行奇數個JN（即3,5,7等）。

請注意，當使用N個JournalNodes執行時，系統最多可以容忍（N-1）/ 2個故障並繼續正常執行。

ZooKeeper

致力於開發和維護開源伺服器，實現高度可靠的分散式協調

故障檢測

活躍的NameNode選舉

 

ZKFailoverController (ZKFC)是一個新的元件，它是一個動物管理員客戶端，還監控和管理NameNode的狀態。

每個執行NameNode的機器也執行ZKFC, ZKFC負責:

 

Health monitoring

zookeeper會話管理

ZooKeeper-based選舉

 

11.05

zookeeper:

是hadoop的分散式協調服務

特點：

是簡單的      核心是精簡的檔案系統

富有表現力的  用於實現多種協調資料結構協議，包括：分散式佇列、分散式鎖、一組   節點的領導者選舉

高可用性

鬆耦合互動方式

資源庫

高效能

zookeeper服務有兩種不同執行模式：

一種是獨立模式即只有一個zookeeper伺服器。比較適合測試環境，但是不能保證高可用性和可恢復性。

一種是在生產環境中的zookeeper通常以複製模式執行在一個計算機叢集上，這個計算機叢集通常被稱為集合體。通常使用複製來實現高可用性，只要集合體重半數以上的機器處於可用狀態，就能提供服務。

在zookeeper設計中，以下幾點考慮保證了資料一致性：

1. 順序一致性  來自任意特定客戶端的更新都會按其傳送順序被提交
2. 原子性      每個更新要麼成功要麼失敗，如果一個更新失敗則不會有客戶端看到這個更新結果。
3. 單一系統映象  一個客戶端無論連線到哪一臺伺服器，它看到的都是同樣的系統檢視。
4. 永續性一個更新一旦成功，其結果就會持久存在且不會被撤銷，表明更新不會受到伺服器故障的影響。
5. 及時性    任何客戶端所看到的滯後系統檢視都是有限的，不會超過幾十秒。