HDFS相關(guān)

1. HDFS讀寫文件過程

image

這里描述的 是一個256M的文件上傳過程 ① 由客戶端 向 NameNode節(jié)點節(jié)點 發(fā)出請求②NameNode 向Client返回可以可以存數(shù)據(jù)的 DataNode 這里遵循 機架感應(yīng) 原則

③客戶端 首先 根據(jù)返回的信息 先將 文件分塊（Hadoop2.X版本 每一個block為 128M 而之前的版本為 64M）④然后通過那么Node返回的DataNode信息 直接發(fā)送給DataNode 并且是 流式寫入 同時 會復(fù)制到其他兩臺機器⑤dataNode 向 Client通信 表示已經(jīng)傳完 數(shù)據(jù)塊 同時向NameNode報告⑥依照上面（④到⑤）的原理將 所有的數(shù)據(jù)塊都上傳結(jié)束 向 NameNode 報告 表明 已經(jīng)傳完所有的數(shù)據(jù)塊

image

讀寫過程鏈接blog

2.寫HDFS時datanode處錯怎么辦

其中一個塊壞了辜纲，只要有其它塊存在城须，會自動檢測還原氛赐。

打開一個DFSOutputStream流斯辰，Client會寫數(shù)據(jù)到流內(nèi)部的一個緩沖區(qū)中板鬓，然后數(shù)據(jù)被分解成多個Packet告私，每個Packet大小為64k字節(jié)寂殉，每個Packet又由一組chunk和這組chunk對應(yīng)的checksum數(shù)據(jù)組成，默認(rèn)chunk大小為512字節(jié)香浩，每個checksum是對512字節(jié)數(shù)據(jù)計算的校驗和數(shù)據(jù)类缤。當(dāng)Client寫入的字節(jié)流數(shù)據(jù)達(dá)到一個Packet的長度，這個Packet會被構(gòu)建出來邻吭，然后會被放到隊列dataQueue中餐弱，接著DataStreamer線程會不斷地從dataQueue隊列中取出Packet，發(fā)送到復(fù)制Pipeline中的第一個DataNode上囱晴，并將該Packet從dataQueue隊列中移到ackQueue隊列中膏蚓。ResponseProcessor線程接收從Datanode發(fā)送過來的ack，如果是一個成功的ack畸写，表示復(fù)制Pipeline中的所有Datanode都已經(jīng)接收到這個Packet驮瞧，ResponseProcessor線程將packet從隊列ackQueue中刪除。在發(fā)送過程中枯芬，如果發(fā)生錯誤论笔，所有未完成的Packet都會從ackQueue隊列中移除掉，然后重新創(chuàng)建一個新的Pipeline千所，排除掉出錯的那些DataNode節(jié)點狂魔，接著DataStreamer線程繼續(xù)從dataQueue隊列中發(fā)送Packet。下面是DFSOutputStream的結(jié)構(gòu)及其原理淫痰，如圖所示：

image

我們從下面3個方面來描述內(nèi)部流程：

• 創(chuàng)建Packet

Client寫數(shù)據(jù)時最楷，會將字節(jié)流數(shù)據(jù)緩存到內(nèi)部的緩沖區(qū)中，當(dāng)長度滿足一個Chunk大写怼（512B）時籽孙，便會創(chuàng)建一個Packet對象，然后向該Packet對象中寫Chunk Checksum校驗和數(shù)據(jù)火俄，以及實際數(shù)據(jù)塊Chunk Data犯建，校驗和數(shù)據(jù)是基于實際數(shù)據(jù)塊計算得到的。每次滿足一個Chunk大小時瓜客，都會向Packet中寫上述數(shù)據(jù)內(nèi)容适瓦，直到達(dá)到一個Packet對象大泄灯簟（64K），就會將該Packet對象放入到dataQueue隊列中犹菇，等待DataStreamer線程取出并發(fā)送到DataNode節(jié)點。

• 發(fā)送Packet

DataStreamer線程從dataQueue隊列中取出Packet對象芽卿，放到ackQueue隊列中揭芍，然后向DataNode節(jié)點發(fā)送這個Packet對象所對應(yīng)的數(shù)據(jù)。

• 接收ack

發(fā)送一個Packet數(shù)據(jù)包以后卸例，會有一個用來接收ack的ResponseProcessor線程称杨，如果收到成功的ack，則表示一個Packet發(fā)送成功筷转。如果成功姑原，則ResponseProcessor線程會將ackQueue隊列中對應(yīng)的Packet刪除。

3.namenode的作用

namenode總體來說是管理和記錄恢復(fù)功能呜舒。比如管理datanode锭汛，保持心跳，如果超時則排除袭蝗。對于上傳文件都有鏡像images和edits,這些可以用來恢復(fù)唤殴。更多：深度了解namenode---其 內(nèi)部關(guān)鍵數(shù)據(jù)結(jié)構(gòu)原理簡介http://www.aboutyun.com/forum.php?mod=viewthread&tid=7388

在HDFS中，namenode的服務(wù)提供整個HDFS文件系統(tǒng)的namespace管理到腥，塊管理等所有服務(wù)朵逝，metadata所有的相關(guān)服務(wù)都是由namenode進(jìn)程在提供。其中包括 filename->blocksequence (namespace)乡范，以及block->machinelist的對應(yīng)表配名。其中前者通過fsimage寫入到本地文件系統(tǒng)中，而后者是通過每次HDFS啟動時晋辆，datanode進(jìn)行blockreport后在內(nèi)存中重構(gòu)的數(shù)據(jù)結(jié)構(gòu)渠脉。絕大部分的情況下，namenode服務(wù)進(jìn)程其實都是在被動的接收服務(wù)請求 -> 進(jìn)行相應(yīng)的操作和更新 –> 進(jìn)行適當(dāng)?shù)姆祷卣煌稀Ｋ粤幔贖DFS的程序代碼中，NameNode類其實只是一個用來接收被動接收調(diào)用服務(wù)的包裝涩哟，它實現(xiàn)了ClientProtocol接口索赏，用來接收來自DFSClient的rpc請求；它實現(xiàn)了DatanodeProtocol接口贴彼，用來接收來自Datanode的各種服務(wù)請求潜腻；同時它還實現(xiàn)了NamenodeProtocol，用來提供跟SecondaryNameNode之間的rpc請求和通信器仗。但實際上融涣，對NameNode的rpc調(diào)用后面的處理邏輯童番，以及namespace的bookkeeping，blocksmap的維護(hù)威鹿，并沒有在NameNode的程序結(jié)構(gòu)中包含剃斧。真正進(jìn)行以上數(shù)據(jù)結(jié)構(gòu)維護(hù)的，是HDFS中的FSNamesystem類忽你。對NameNode的各種請求堕伪，比如創(chuàng)建输瓜，修改忆蚀，刪除蕾域，移動，getLocations的操作糟秘，在NameNode內(nèi)部都是通過FSNamesystem提供的接口對內(nèi)部數(shù)據(jù)結(jié)構(gòu)進(jìn)行的訪問简逮。

4.NameNode的HA

NameNode的HA一個備用，一個工作尿赚，且一個失敗后散庶，另一個被激活。他們通過journal node來實現(xiàn)共享數(shù)據(jù)凌净。

https://blog.csdn.net/daydayup_668819/article/details/70815335

5 分片

https://www.cnblogs.com/qinwangchen/p/5837940.html

totalSize：是整個Map-Reduce job所有輸入的總大小督赤。

numSplits：來自job.getNumMapTasks()，即在job啟動時用org.apache.hadoop.mapred.JobConf.setNumMapTasks(int n)設(shè)置的值泻蚊，給M-R框架的Map數(shù)量的提示躲舌。

goalSize：是輸入總大小與提示Map task數(shù)量的比值，即期望每個Mapper處理多少的數(shù)據(jù)性雄，僅僅是期望没卸，具體處理的數(shù)據(jù)數(shù)由下面的computeSplitSize決定。

minSplitSize：默認(rèn)為1秒旋，可由子類復(fù)寫函數(shù)protected void setMinSplitSize(long minSplitSize) 重新設(shè)置约计。一般情況下，都為1迁筛，特殊情況除外煤蚌。

minSize：取的1和mapred.min.split.size中較大的一個。

blockSize：HDFS的塊大小细卧，默認(rèn)為64M尉桩，一般大的HDFS都設(shè)置成128M。

splitSize：就是最終每個Split的大小贪庙，那么Map的數(shù)量基本上就是totalSize/splitSize蜘犁。

接下來看看computeSplitSize的邏輯：首先在goalSize（期望每個Mapper處理的數(shù)據(jù)量）和HDFS的block size中取較小的，然后與mapred.min.split.size相比取較大的止邮。

一個片為一個splits这橙，即一個map奏窑，只要搞清楚片的大小，就能計算出運行時的map數(shù)屈扎。而一個split的大小是由goalSize, minSize, blockSize這三個值決定的埃唯。computeSplitSize的邏輯是，先從goalSize和blockSize兩個值中選出最小的那個（比如一般不設(shè)置map數(shù)鹰晨，這時blockSize為當(dāng)前文件的塊size筑凫，而goalSize是文件大小除以用戶設(shè)置的map數(shù)得到的，如果沒設(shè)置的話并村，默認(rèn)是1），在默認(rèn)的大多數(shù)情況下滓技，blockSize比較小哩牍。然后再取blockSize和minSize中最大的那個。而minSize如果不通過”mapred.min.split.size”設(shè)置的話（”mapred.min.split.size”默認(rèn)為0）令漂，minSize為1膝昆，這樣得出的一個splits的size就是blockSize，即一個塊一個map叠必，有多少塊就有多少map荚孵。

5 shuffle

http://www.aboutyun.com/thread-10335-1-1.html

YARN

1.架構(gòu)

image

Yarn依然是Master/Slave的結(jié)構(gòu)：

在資源架構(gòu)層面，ResourceManager是Master纬朝，NodeManager是Slave

在應(yīng)用運行期間收叶，ApplicationMaster是Master，各個Container是Slave

ResourceManager(RM)共苛，RM是全局的資源管理器判没，負(fù)責(zé)整個系統(tǒng)的資源管理和分配。由以下兩部分組成：

調(diào)度器：根據(jù)容量隅茎、隊列限制條件將系統(tǒng)資源分配給各個應(yīng)用

資源分配的單位是container澄峰，container是一個動態(tài)資源單位，它將內(nèi)存辟犀、CPU俏竞、磁盤、網(wǎng)絡(luò)等資源封裝在一起堂竟，從而限定了資源使用量魂毁。

調(diào)度器是一個可插拔的組件，用戶可以自己定制出嘹，也可以選擇Fair或Capacity調(diào)度器

應(yīng)用程序管理器：負(fù)責(zé)管理所有應(yīng)用程序的以下內(nèi)容：

應(yīng)用提交

與調(diào)度器協(xié)商資源以啟動AM

監(jiān)控AM運行狀態(tài)并在失敗時重啟它

ApplicationMaster(AM)漱牵，用戶提交的每個應(yīng)用程序都需要包含一個AM，它的主要功能包括：

與RM調(diào)度器協(xié)商以獲取資源(以container為資源單位)

將得到的任務(wù)進(jìn)一步分配給內(nèi)部的任務(wù)

與NM通信以啟動/停止任務(wù)

監(jiān)控所有任務(wù)運行狀態(tài)疚漆，并在失敗時重新為任務(wù)申請資源以重啟任務(wù)

Tips: 當(dāng)前Yarn已經(jīng)實現(xiàn)了兩個AM：

• DistributedShell：分布式的運行shell命令 -MRAppMaster:MapReduce應(yīng)用的AMNodeManager(NM)酣胀，是每個節(jié)點上的資源和任務(wù)管理器

定時向RM匯報本節(jié)點上的資源使用情況和各個container運行狀態(tài)

接收并處理來自AM的container啟動/停止等請求

Container刁赦，是Yarn中的資源抽象

它封裝了節(jié)點上多個維度的資源(目前Yarn只支持CPU和內(nèi)存兩種資源)

它與slot的不同之處在于，slot是靜態(tài)的(每個slot的資源相同)闻镶，container是動態(tài)的(每個container的資源可以不同)甚脉。

2.提交作業(yè)

image

當(dāng)用戶向YARN中提交一個應(yīng)用程序之后，Yarn分兩大階段運行該應(yīng)用：

第一個階段是啟動AM

第二個階段是由AM創(chuàng)建應(yīng)用程序铆农，為它申請資源牺氨，并監(jiān)控運行過程，直到運行結(jié)束

步驟1：用戶向YARN提交應(yīng)用墩剖，其中包括AM猴凹、啟動AM的命令、用戶程序等

步驟2：RM為該應(yīng)用分配第一個Container岭皂，并與對應(yīng)的NM通信郊霎，要求它在這個Container中啟動應(yīng)用的AM

步驟3：AM向RM注冊，這樣用戶可以通過RM查看應(yīng)用的狀態(tài)爷绘。然后AM為各個任務(wù)申請資源书劝，并監(jiān)控它的運行狀態(tài)，直到運行結(jié)束土至，即重復(fù)以下步驟4～7

步驟4：AM采用輪詢的方式通過RPC協(xié)議向RM申請和領(lǐng)取資源

步驟5：一旦AM獲得資源购对，便與對應(yīng)的NM通信，要求它啟動任務(wù)

步驟6：NM為任務(wù)設(shè)置好運行環(huán)境(包括環(huán)境變量陶因、JAR包骡苞、二進(jìn)制程序等)后，將任務(wù)啟動命令寫到一個腳本中楷扬，并通過該腳本啟動任務(wù)

步驟7：各個任務(wù)通過某個RPC協(xié)議向AM匯報自己的狀態(tài)和進(jìn)度烙如，以讓AM隨時掌握狀態(tài)，從而可以在任務(wù)失敗時重啟任務(wù)

步驟8：應(yīng)用程序運行完成后毅否，AM向RM申請注銷并關(guān)閉自己亚铁。

3. yarn 組件介紹

client

image

• Client 通過RPC函數(shù)獲取唯一的ApplicationID

• Client通過RPC函數(shù)將ApplicationMaster提交到RM上

YARN ApplicationMaster

image

AM-RM

• 注冊

• 申請資源

• 告訴執(zhí)行完畢

AM通過RPC函數(shù)registerApplicationMaster向ResourceManager注冊。

注冊信息封裝成RegisterApplicationMasterRequest對象螟加。返回值為RegisterApplicationMasterResponse對象徘溢。包含屬性：

• maximumCapability 最大可申請的單個container占用的資源量

• client_t_am_token_master_key

• Application_ACLs

AM通過RPC函數(shù)allocate申請資源。發(fā)送參數(shù)為AllocateRequest捆探。主要包含以下屬性

• ask請求的資源列表然爆。每一個資源用Resourcerequest隊形表示。

• release釋放的container列表

• response_id 本次通信的應(yīng)答id

• progress應(yīng)用程序執(zhí)行進(jìn)度

• blacklist_request

返回值為AllocateResponse黍图。

• a_m_command am需要執(zhí)行的命令曾雕。

• response_id 本次通信的應(yīng)答id

• allcated_containers 分配的container列表

• Completed_container_statuses 運行完成container狀態(tài)列表

• limit集群可用資源總量

• Updated_nodes 當(dāng)前集群所有節(jié)點運行狀態(tài)列表

AM通過RPC函數(shù)finishApplicationMaster告訴執(zhí)行完畢。參數(shù)FinishApplicationMasterRequest助被。返回值FinishApplicationMasterResponse剖张。

image

AM-NM

• 啟動container

• 查詢狀態(tài)

• 釋放container

ApplicationMaster將申請到的資源二次分配給內(nèi)部的任務(wù)切诀，通過RPC函數(shù)startContainer與NM通信啟動container。

• 參數(shù)startContainersRequest搔弄。

  • container_launch_context 封裝了container執(zhí)行環(huán)境

  • container_token 啟動時候的安全令牌

• 返回值startContainersResponse

  • succeeded_requests 成功運行的container列表

  • failed_requests 運行失敗的container列表

為了實時掌握container運行狀態(tài)幅虑。AM通過RPC函數(shù)getcontainerstatus向NM詢問container運行狀態(tài)。一個container運行萬顾犹，可以通過stopcontainer釋放container倒庵。

resource manager

image

• 與客戶端交流，處理請求

• 啟動管理AM炫刷，并在其運行失敗時重啟AM

• 管理NM擎宝，接受匯報信息，及下達(dá)管理命令

• 資源管理與調(diào)度

• 交互模塊：RM對普通用戶浑玛、管理員绍申、Web提供了三種對外服務(wù)：

  • ClientRMService:為普通用戶提供服務(wù)，它處理來自客戶端的各種RPC锄奢，比如

    • 應(yīng)用提交

    • 終止應(yīng)用

    • 獲取應(yīng)用狀態(tài)等

  • AdminService:為管理員提供的獨立接口，主要目的是為了防止大量普通用戶請求阻塞管理員通道剧腻，提供如下功能：

    • 動態(tài)更新節(jié)點列表

    • 更新ACL列表

    • 更新隊列信息等

  • WebApp:提供一個Web界面來讓用戶更友好的獲知集群和應(yīng)用的狀態(tài)

• NM管理模塊：用來管理NM的模塊拘央，主要包含以下三個組件：

  • ResourceTrackerService:處理來自NodeManager的請求，主要包括：

    • 注冊：注冊是NM啟動時發(fā)生的行為书在，NM提供的信息包括：節(jié)點ID灰伟、可用資源上限信息等

    • 心跳：心跳是周期行為。NM提供的信息包括：各個Container運行狀態(tài)儒旬、運行的Application列表栏账、節(jié)點健康狀態(tài)等。RM返回的信息包括：等待釋放的Container列表栈源、Application列表等

  • NMLivelinessMonitor:監(jiān)控NM是否活著挡爵，如果NM在一定時間(默認(rèn)10m)內(nèi)未上報心跳，則認(rèn)為它死掉甚垦，需要移除

  • NodesListManager:維護(hù)正常節(jié)點和異常節(jié)點列表茶鹃，管理exclude(類似黑名單)和include(類似白名單)節(jié)點列表，這兩個列表均是在配置文件中設(shè)置的艰亮，可以動態(tài)加載闭翩。

• AM管理模塊：主要是用來管理所有AM，主要包括：

  • ApplicationMasterService(AMS):處理來自AM的請求迄埃，包括：

    • 注冊：是AM啟動時發(fā)生的行為疗韵，信息包括：

    • AM的啟動節(jié)點、對外RPC端口侄非、trackingURL等

    • 心跳：是周期行為蕉汪。AM提供的信息包括：所需資源的描述流译、待釋放Container列表、黑名單列表等肤无。AMS返回的信息包括：新分配的Container先蒋、失敗的Container、待搶占的Container列表等

  • AMLivelinessMonitor:監(jiān)控AM是否活著宛渐，如果AM在一定時間(默認(rèn)10m)內(nèi)未上報心路竞漾，則認(rèn)為它死掉，它上面正在運行的Container將會被置為失敗狀態(tài)窥翩，而AM本身會被分配到另一個節(jié)點上(用戶可以指定重試次數(shù)业岁，默認(rèn)5)

  • ApplicationMasterLauncher：與某個NM通信，要求它為某個應(yīng)用程序啟動AM

• 應(yīng)用管理模塊：主要是各個應(yīng)用外圍的管理寇蚊，并不涉及到應(yīng)用內(nèi)部

  • ApplicationACLsManager:管理應(yīng)用程序訪問權(quán)限笔时，包含兩部分：

    • 查看權(quán)限：主要用于查看應(yīng)用程序基本信息

    • 修改權(quán)限：主要用于修改應(yīng)用程序優(yōu)先級、殺死應(yīng)用程序等

  • RMAppManager:管理應(yīng)用程序的啟動和關(guān)閉

  • ContainerAllocationExpirer:當(dāng)AM收到RM新分配的Container后仗岸，必須在一定時間(默認(rèn)10m)內(nèi)在對應(yīng)的NM上啟動該Container允耿，否則RM將強制回收該Container，而一個已經(jīng)分配的Container是否該被回收則是由ContainerAllocationExpirer決定和執(zhí)行的

• 狀態(tài)機管理模塊：RM使用有限狀態(tài)機維護(hù)有狀態(tài)對象的生命周期扒怖，狀態(tài)機的引入使得Yarn的架構(gòu)設(shè)計清晰较锡，RM內(nèi)部的狀態(tài)機有：

  • RMApp:維護(hù)一個應(yīng)用程序的整個運行周期，包括從啟動到運行結(jié)束的整個過程由于一個APP的生命周期可能會啟動多個運行實例(Attempt)盗痒，RMApp維護(hù)的是所有的這些Attempt

  • RMAppAttempt:一次應(yīng)用程序的運行實例的整個生命周期蚂蕴，可以理解為APP的一次嘗試運行

  • RMContainer:一個Container的運行周期，包括從創(chuàng)建到運行結(jié)束的整個過程俯邓。

  • RM將資源封裝成Container發(fā)送給應(yīng)用程序的AM骡楼，AM在Container描述的運行環(huán)境中啟動任務(wù)。Yarn不支持Container重用稽鞭，一個Container用完后會立刻釋放

  • RMNode:維護(hù)了一個NM的生命周期鸟整，包括從啟動到運行結(jié)束的整個過程

• 安全模塊：RM自帶了非常全面的權(quán)限管理機制，主要包括：

  • ClientToAMSecretManager

  • ContainerTokenSecretManager

  • ApplicationTokenSecretManager等朦蕴，由于這塊非常復(fù)雜吃嘿，可以找個專題討論，這里先不展開

• 調(diào)度模塊：主要包含一個組件ResourceScheduler梦重。是資源調(diào)度器兑燥，它按照一定的約束條件(比如隊列容量限制等)將集群中的資源分配給各個應(yīng)用程序，目前主要考慮內(nèi)存和CPUResourceScheduler是一個可插拔式的模塊琴拧，自帶三個調(diào)度器降瞳，用戶可以自己定制。

  • FIFO：先進(jìn)先出，單用戶

  • FairScheduler:公平調(diào)度器(FairScheduler基本上具備其它兩種的所有功能)

  • CapacityScheduler:容量調(diào)度器

node manager

image

HBASE

http://www.aboutyun.com/thread-10886-1-1.html