大數據（hadoop）

• 2020 年 7 月 27 日
• 筆記

大數據

一.概述

二.大數據特點

三.大數據部門組織結構

hadoop框架

一.hadoop是什麼

• Hadoop是一個由Apache基金會所開發的分散式系統基礎架構。
• 主要解決，海量數據的存儲和海量數據的分析計算問題。
• 廣義上來說，Hadoop通常是指一個更廣泛的概念——Hadoop生態圈。

二.hadoop三大發行版本

• Hadoop三大發行版本：Apache、Cloudera、Hortonworks。
• Apache版本最原始（最基礎）的版本，對於入門學習最好。
• Cloudera在大型互聯網企業中用的較多。
• Hortonworks文檔較好。

三.hadoop的優勢

• 高可靠性:Hadoop底層維護多個數據副本，所以即使Hadoop某個計算元素或存儲出現故障，也不會導致數據的丟失。
• 高擴展性:在集群間分配任務數據，可方便的擴展數以千計的節點。
• 高效性:在MapReduce的思想下，Hadoop是並行工作的，以加快任務處理
• 高容錯性:能夠自動將失敗的任務重新分配。

四.hadoop的組成

HDFS

一.HDFS概述

• HDFS是大數據開源框架hadoop的組件之一，全稱（Hadoop Distributed File System），它是一個分散式文件系統，由多台伺服器聯合起來實現文件存儲功能，通過目錄樹來定位文件，集群中的伺服器都有有各自的角色。

二.HDFS架構的組成

1.NameNode (nn):就是Master，它
是—個主管、管理者。

• 管理HDFS的名稱空間;
• 配置副本策略;
• 管理數據塊(B1ock）映射資訊;
• 處理客戶端讀寫請求。

2.DataNode:就是Slave。NameNode
下達命令，DataNode執行實際的操作。

• 存儲實際的數據塊;
• 執行數據塊的讀/寫操作。

3.Client:就是客戶端。

• 文件切分。文件上傳HDFS的時候，Clien將文件切分成一個一個的Block，然後進行上傳;
• 與NameNode交互，獲取文件的位置資訊;
• 與DataNode交互，讀取或者寫入數據;
• Clier提供一些命令來管理HDFS，比如NameNode格式化;
• Client可以通過一些命令來訪問HDFS，比如對HDFS增刪查改操作;

4.Secondary NameNode:並非NameNode的熱備。當NameNode掛掉的時候，它並不
能馬上替換NameNode並提供服務。

• 輔助NameNode，分擔其工作量，比如定期合併Fsimage和Edits，並推送給NameNode ;
• 在緊急情況下，可輔助恢復NameNode。

三.HDFS優缺點

優點：

1.高容錯性

• 數據自動保存多個副本。它通過增加副本的形式，提高容錯性。
• 某一個副本丟失以後，它可以自動恢復。

2.適合處理大數據

• 數據規模:能夠處理數據規模達到GB、TB、甚至PB級別的數據;
• 文件規模:能夠處理百萬規模以上的文件數量，數量相當之大。

3.可構建在廉價機器上，通過多副本機制，提高可靠性。

缺點：

1.不適合低延時數據訪問，比如毫秒級的存儲數據，是做不到的。
2.無法高效的對大量小文件進行存儲。

• 存儲大量小文件的話，它會佔用NameNode大量的記憶體來存儲文件目錄和塊資訊。這樣是不可取的，因為NameNode的記憶體總是有限的;
• 小文件存儲的定址時間會超過讀取時間，它違反了HDFS的設計目標

3.不支援並發寫入、文件隨機修改。

• 同一時間一個文件只能有一個用戶執行寫操作，不允許多個線同時寫;
• 僅支援數據append(追加)，不支援文件的隨機修改。

四.HDFS中namenode和DataNode的作用

1.namenode：

• 負責接受客戶端讀寫數據請求
• 負責數據塊副本的存儲策略
• 負責管理快數據的映射關係
• 儲存元數據資訊

2.datanode：

• 存儲實際的數據塊
• 真實處理數據塊的讀/寫操作

五.namenode、secondarynamenode和DataNode工作機制

1.NameNode啟動和工作內容:

• 第一次啟動NameNode格式化後，創建Fsimage和Edits文件。如果不是第一次啟動，會載入編輯日誌和鏡像文件到記憶體。
• 客戶端對元數據進行增刪改的請求。
• NameNode記錄操作日誌，更新滾動日誌。
• NameNode在記憶體中對元數據進行增刪改。

2.Secondary NameNode工作內容:

• 2NN詢問NN是否需要CheckPoint（合併鏡像和編輯日誌），並帶回NameNode是否執行結果。
• 2NN請求執行CheckPoint
• NN滾動正在寫的Edits編輯日誌。
• 將滾動前的編輯日誌和鏡像文件拷貝到2NN。
• 2NN載入編輯日誌和鏡像文件到記憶體，並執行合併，生成新的鏡像文件fsimage.chkpoint。
• 2NN拷貝fsimage.chkpoint到NN。
• NN將fsimage.chkpoint重新命名成fsimage，替換之間舊的fsimage

3.DataNode:

• 一個數據塊在DataNode上以文件形式存儲在磁碟上，包括兩個文件，一個是數據本身，一個是元數據包括數據塊的長度，塊數據的校驗和，以及時間戳。
• DataNode啟動後向NameNode註冊，通過後，周期性（1小時）的向NameNode上報所有的塊資訊。
• 心跳是每3秒一次，心跳返回結果帶有NameNode給該DataNode的命令如複製塊數據到另一台機器，或刪除某個數據塊。如果超過10分鐘沒有收到某個DataNode的心跳，則認為該節點不可用。
• 集群運行中可以安全加入和退出一些機器。

六.HDFS文件塊大小

HDFS中的文件在物理上是分塊存儲(B1ock)，塊的大小可以通過配置參數
( dfs.blocksize)來規定，默認大小在Hadoop2.x版本中是128M，老版本中是64M。

• 集群中的block
• 如果定址時間約為10ms,即查找到目標block的時間為1Oms。
• 3定址時間為傳輸時間的1%時，則為最佳狀態。   因此，傳輸時間=10ms/0.01=100Oms=1s
• 而目前磁碟的傳輸速率普遍為100MB/s。
• block大小   =1s*100MB/s=10OMB

思考:為什麼塊的大小不能設置太小，也不能設置太大?

• HDFS的塊設置太小，會增加定址時間，程式一直在找塊的開始位置;
• 如果塊設置的太大，從磁碟傳輸數據的時間會明顯大於定位這個塊開始位置所需的時間。導致程式在處理這塊數據時，會非常慢。

總結:HDFS塊的大小設置主要取決於磁碟傳輸速率。

MapReduce

一.MapReduce概述

• MapReduce是一個分散式運算程式的編程框架，是用戶開發「基於Hadoop的數據分析應用」的核心框架。
• MapReduce核心功能是將用戶編寫的業務邏輯程式碼和自帶默認組件整合成一個完整的分散式運算程式，並發運行在一個Hadoop集群上。

二.MapReduce優缺點

優點：

1.MapReduce易於編程

• 它簡單的實現一些介面，就可以完成一個分散式程式，這個分散式程式可以分布到大量廉價的PC機器上運行。也就是說你寫一個分散式程式，跟寫一個簡單的串列程式是一模一樣的。就是因為這個特點使得MapReduce編程變得非常流行。

2．良好的擴展性

• 當你的計算資源不能得到滿足的時候，你可以通過簡單的增加機器來擴展它的計算能力。

3．高容錯性

• MapReduce設計的初衷就是使程式能夠部署在廉價的PC機器上，這就要求它具有很高的容錯性。比如其中一台機器掛了，它可以把上面的計算任務轉移到另外一個節點上運行，不至於這個任務運行失敗，而且這個過程不需要人工參與，而完全是由Hadoop內部完成的。

4．適合PB級以上海量數據的離線處理

• 可以實現上千台伺服器集群並發工作，提供數據處理能力。

缺點：

1.不擅長實時計算

• MapReduce無法像MySQL—樣，在毫秒或者秒級內返回結果。

2.不擅長流式計算

• 流式計算的輸入數據是動態的，而MapReduce的輸入數據集是靜態的，不能動態變化。這是因為MapReduce自身的設計特點決定了數據源必須是靜態的。

3.不擅長DAG(有向圖)計算

• 多個應用程式存在依賴關係，後一個應用程式的輸入為前一個的輸出。在這種情況下，MapReduce並不是不能做，r而是使用後，每個MapReduce作業的輸出結果都會寫入到磁碟，會造成大量的磁碟IO，導致性能非常的低下。

三.MapReduce核心思想

• 分散式的運算程式往往需要分成至少2個階段。
• 第一個階段的MapTask並發實例，完全並行運行，互不相干。
• 第二個階段的ReduceTask並發實例互不相干，但是他們的數據依賴於上一個階段的所有MapTask並發實例的輸出。
• MapReduce編程模型只能包含一個Map階段和一個Reduce階段，如果用戶的業務邏輯非常複雜，那就只能多個MapReduce程式，串列運行。
• 總結：分析WordCount數據流走向深入理解MapReduce核心思想。

四.MapReduce進程

• 分散式的運算程式往往需要分成至少2個階段。
• 第一個階段的MapTask並發實例，完全並行運行，互不相干。
• 第二個階段的ReduceTask並發實例互不相干，但是他們的數據依賴於上一個階段的所有MapTask並發實例的輸出。
• MapReduce編程模型只能包含一個Map階段和一個Reduce階段，如果用戶的業務邏輯非常複雜，那就只能多個MapReduce程式，串列運行。
• 總結：分析WordCount數據流走向深入理解MapReduce核心思想。

五.MapReduce工作流程

1.流程詳解

上面的流程是整個MapReduce最全工作流程，但是Shuffle過程只是從第7步開始到第16步結束，具體Shuffle過程詳解，如下：

• MapTask收集我們的map()方法輸出的kv對，放到記憶體緩衝區中
• 從記憶體緩衝區不斷溢出本地磁碟文件，可能會溢出多個文件
• 多個溢出文件會被合併成大的溢出文件
• 在溢出過程及合併的過程中，都要調用Partitioner進行分區和針對key進行排序
• ReduceTask根據自己的分區號，去各個MapTask機器上取相應的結果分區數據
• ReduceTask會取到同一個分區的來自不同MapTask的結果文件，ReduceTask會將這些文件再進行合併（歸併排序）
• 合併成大文件後，Shuffle的過程也就結束了，後面進入ReduceTask的邏輯運算過程（從文件中取出一個一個的鍵值對Group，調用用戶自定義的reduce()方法）

注意

• Shuffle中的緩衝區大小會影響到MapReduce程式的執行效率，原則上說，緩衝區越大，磁碟io的次數越少，執行速度就越快。
• 緩衝區的大小可以通過參數調整，參數：io.sort.mb默認100M。

六.MapReduce作業提交

yarn

一.yarn概述

Yarn是一個資源調度平台，負責為運算程式提供伺服器運算資源，相當於一個分散式的作業系統平台，而MapReduce等運算程式則相當於運行於作業系統之上的應用程式。

二.yarn架構組成　　　

YARN主要由ResourceManager、NodeManager、ApplicationMaster和Container等組件構成.

ResourceManager:

• RM是一個全局的資源管理器，負責整個系統的資源管理和分配。它主要由兩個組件構成：調度器（Scheduler）和應用程式管理器（Applications Manager，ASM）。
• 調度器 調度器根據容量、隊列等限制條件（如每個隊列分配一定的資源，最多執行一定數量的作業等），將系統中的資源分配給各個正在運行的應用程式。需要注意的是，該調度器是一個「純調度器」，它不再從事任何與具體應用程式相關的工作，比如不負責監控或者跟蹤應用的執行狀態等，也不負責重新啟動因應用執行失敗或者硬體故障而產生的失敗任務，這些均交由應用程式相關的ApplicationMaster完成。調度器僅根據各個應用程式的資源需求進行資源分配，而資源分配單位用一個抽象概念「資源容器」（Resource Container，簡稱Container）表示，Container是一個動態資源分配單位，它將記憶體、CPU、磁碟、網路等資源封裝在一起，從而限定每個任務使用的資源量。此外，該調度器是一個可插拔的組件，用戶可根據自己的需要設計新的調度器，YARN提供了多種直接可用的調度器，比如Fair Scheduler和Capacity Scheduler等。
• 應用程式管理器應用程式管理器負責管理整個系統中所有應用程式，包括應用程式提交、與調度器協商資源以啟動ApplicationMaster、監控ApplicationMaster運行狀態並在失敗時重新啟動它等。

NodeManager:

• NM是每個節點上的資源和任務管理器，一方面，它會定時地向RM彙報本節點上的資源使用情況和各個Container的運行狀態；另一方面，它接收並處理來自AM的Container啟動/停止等各種請求。

ApplicationMaster:

用戶提交的每個應用程式均包含一個AM，主要功能包括：

• 與RM調度器協商以獲取資源（用Container表示）；
• 將得到的任務進一步分配給內部的任務(資源的二次分配)；
• 與NM通訊以啟動/停止任務；
• 監控所有任務運行狀態，並在任務運行失敗時重新為任務申請資源以重啟任務。

當前YARN自帶了兩個AM實現，一個是用於演示AM編寫方法的實常式序distributedshell，它可以申請一定數目的Container以並行運行一個Shell命令或者Shell腳本；另一個是運行MapReduce應用程式的AM—MRAppMaster。

註：RM只負責監控AM，在AM運行失敗時候啟動它，RM並不負責AM內部任務的容錯，這由AM來完成。

Container:

三.yarn 運行機制

2．工作機制詳解

• MR程式提交到客戶端所在的節點。
• YarnRunner向ResourceManager申請一個Application。
• RM將該應用程式的資源路徑返回給YarnRunner。
• 該程式將運行所需資源提交到HDFS上。
• 程式資源提交完畢後，申請運行mrAppMaster。
• RM將用戶的請求初始化成一個Task。
• 其中一個NodeManager領取到Task任務。
• 該NodeManager創建容器Container，併產生MRAppmaster。
• Container從HDFS上拷貝資源到本地。
• MRAppmaster向RM 申請運行MapTask資源。
• RM將運行MapTask任務分配給另外兩個NodeManager，另兩個NodeManager分別領取任務並創建容器。
• MR向兩個接收到任務的NodeManager發送程式啟動腳本，這兩個NodeManager分別啟動MapTask，MapTask對數據分區排序。
• MrAppMaster等待所有MapTask運行完畢後，向RM申請容器，運行ReduceTask。
• ReduceTask向MapTask獲取相應分區的數據。
• 程式運行完畢後，MR會向RM申請註銷自己。

四.yarn作業提交

• 第1步：Client調用job.waitForCompletion方法，向整個集群提交MapReduce作業。
• 第2步：Client向RM申請一個作業id。
• 第3步：RM給Client返回該job資源的提交路徑和作業id。
• 第4步：Client提交jar包、切片資訊和配置文件到指定的資源提交路徑。
• 第5步：Client提交完資源後，向RM申請運行MrAppMaster。

2.作業初始化

• 第6步：當RM收到Client的請求後，將該job添加到容量調度器中。
• 第7步：某一個空閑的NM領取到該Job。
• 第8步：該NM創建Container，併產生MRAppmaster。
• 第9步：下載Client提交的資源到本地。

3.任務分配

• 第10步：MrAppMaster向RM申請運行多個MapTask任務資源。
• 第11步：RM將運行MapTask任務分配給另外兩個NodeManager，另兩個NodeManager分別領取任務並創建容器。

4.任務運行

• 第12步：MR向兩個接收到任務的NodeManager發送程式啟動腳本，這兩個NodeManager分別啟動MapTask，MapTask對數據分區排序。
• 第13步：MrAppMaster等待所有MapTask運行完畢後，向RM申請容器，運行ReduceTask。
• 第14步：ReduceTask向MapTask獲取相應分區的數據。
• 第15步：程式運行完畢後，MR會向RM申請註銷自己。

5.進度和狀態更新

• YARN中的任務將其進度和狀態(包括counter)返回給應用管理器, 客戶端每秒(通過mapreduce.client.progressmonitor.pollinterval設置)嚮應用管理器請求進度更新, 展示給用戶。

6.作業完成

• 除了嚮應用管理器請求作業進度外, 客戶端每5秒都會通過調用waitForCompletion()來檢查作業是否完成。時間間隔可以通過mapreduce.client.completion.pollinterval來設置。作業完成之後, 應用管理器和Container會清理工作狀態。作業的資訊會被作業歷史伺服器存儲以備之後用戶核查。

HDFS HA高可用

一.HDFS-HA概述

1.所謂HA（High Available），即高可用（7*24小時不中斷服務）。

2.實現高可用最關鍵的策略是消除單點故障。HA嚴格來說應該分成各個組件的HA機制：HDFS的HA和YARN的HA。

3.Hadoop2.0之前，在HDFS集群中NameNode存在單點故障（SPOF）。

4.NameNode主要在以下兩個方面影響HDFS集群

• NameNode機器發生意外，如宕機，集群將無法使用，直到管理員重啟
• NameNode機器需要升級，包括軟體、硬體升級，此時集群也將無法使用

HDFS HA功能通過配置Active/Standby兩個NameNodes實現在集群中對NameNode的熱備來解決上述問題。如果出現故障，如機器崩潰或機器需要升級維護，這時可通過此種方式將NameNode很快的切換到另外一台機器。

二.HDFS-HA工作機制

• 通過雙NameNode消除單點故障

三.HDFS-HA工作要點

1. 元數據管理方式需要改變

• 記憶體中各自保存一份元數據；
• Edits日誌只有Active狀態的NameNode節點可以做寫操作；
• 兩個NameNode都可以讀取Edits；
• 共享的Edits放在一個共享存儲中管理（qjournal和NFS兩個主流實現）；

2. 需要一個狀態管理功能模組

• 實現了一個zkfailover，常駐在每一個namenode所在的節點，每一個zkfailover負責監控自己所在NameNode節點，利用zk進行狀態標識，當需要進行狀態切換時，由zkfailover來負責切換，切換時需要防止brain split現象的發生。

3. 必須保證兩個NameNode之間能夠ssh無密碼登錄

4. 隔離（Fence），即同一時刻僅僅有一個NameNode對外提供服務

四.HDFS-HA自動故障轉移工作機制

1.故障檢測：

• 集群中的每個NameNode在ZooKeeper中維護了一個持久會話，如果機器崩潰，ZooKeeper中的會話將終止，ZooKeeper通知另一個NameNode需要觸發故障轉移。

2.現役NameNode選擇：

• ZooKeeper提供了一個簡單的機制用於唯一的選擇一個節點為active狀態。如果目前現役NameNode崩潰，另一個節點可能從ZooKeeper獲得特殊的排外鎖以表明它應該成為現役NameNode。
• ZKFC是自動故障轉移中的另一個新組件，是ZooKeeper的客戶端，也監視和管理NameNode的狀態。每個運行NameNode的主機也運行了一個ZKFC進程；

ZKFC負責：

1.健康監測：

• ZKFC使用一個健康檢查命令定期地ping與之在相同主機的NameNode，只要該NameNode及時地回復健康狀態，ZKFC認為該節點是健康的。如果該節點崩潰，凍結或進入不健康狀態，健康監測器標識該節點為非健康的。

2.ZooKeeper會話管理：

• 當本地NameNode是健康的，ZKFC保持一個在ZooKeeper中打開的會話。如果本地NameNode處於active狀態，ZKFC也保持一個特殊的znode鎖，該鎖使用了ZooKeeper對短暫節點的支援，如果會話終止，鎖節點將自動刪除。

3.基於ZooKeeper的選擇：

• 如果本地NameNode是健康的，且ZKFC發現沒有其它的節點當前持有znode鎖，它將為自己獲取該鎖。如果成功，則它已經贏得了選擇，並負責運行故障轉移進程以使它的本地NameNode為Active。故障轉移進程與前面描述的手動故障轉移相似，首先如果必要保護之前的現役NameNode，然後本地NameNode轉換為Active狀態。