Hadoop核心组件及组件介绍
一、核心組件
1、Hadoop通用組件 -? Hadoop Common
包含了其他hadoop模塊要用到的庫文件和工具
2、分布式文件系統 - Hadoop Distributed File System （HDFS）
運行于通用硬件上的分布式文件系統，高吞吐，高可靠
3、資源管理組件 - Hadoop YARN
于2012年引入的組件，用于管理集群中的計算資源并在這些資源上調度用戶應用
4、分布式計算框架 - Hadoop MapReduce
用于處理超大數據集計算的MapReduce編程模型的實現
二、Hadoop關聯項目
1、Apache Ambari 是一種基于Web的工具，支持Apache Hadoop集群的供應、管理和監控。Apache Ambari 支持HDFS、MapReduce、Hive、Pig、Hbase、Zookeepr、Sqoop和Hcatalog等的集中管理。也是5個頂級hadoop管理工具之一。
2、Avro：數據序列化系統
3、Cassandra是一套開源分布式NoSQL數據庫系統。他最初由Facebook開發，用于儲存收件箱等簡單格式數據，集GoogleBigTable的數據模型與Amazon Dynamo的完全分布式的架構于一身，Facebook于2008將Caddandra開源。
4、chukwa是一個開源的用于監控大型分布式系統的數據收集系統。這是構建在hadoop的HDFS和MapReduce框架之上的，繼承了hadoop的可伸縮性和健壯性。Chukwa還包含了一個強大的靈活的工具集，可用于展示、監控和分析已收集的數據。
5、hive 是基于Hadoop的一個數據倉庫工具，可以將結構化的數據文件映射為一張數據庫表，并提供簡單的sql查詢功能，可以將sql語句轉換為MapReduce任務進行運行。
6、Mahout提供一些可擴展的機器學習領域經典算法的實現，旨在幫助開發人員更加方便快捷的創建智能應用程序。Mahout包含許多實現，包括聚類、分類、推薦過濾、頻繁子項挖掘。此外，通過使用Apache Hadoop庫，Mahout可以有效的擴展到云中。
7、Apache Pig 是一個高級過程語言，適合于使用Hadoop 和 MapReduce 平臺來查詢大型半結構化數據集。通過允許對分布式數據集進行類似SQL的查詢，Pig可以簡化Hadoop的使用。
8、Apache Spark是專為大規模數據處理而設計的快速通用的計算引擎。Spark是UCBerkeley AMP lab開源的類Hadoop MapReduce的通用并行框架，擁有MapReduce具有的優點。
9、Tez 是 Apache 最新的支持 DAG 作業的開源計算框架。它允許開發者為最終用戶構建性能更快、擴展性更好的應用程序。Hadoop傳統上是一個大量數據批處理平臺。但是，有很多用例需要近乎實時的查詢處理性能。還有一些工作則不太適合MapReduce，例如機器學習。Tez的目的就是幫助Hadoop處理這些用例場景。
10、ZooKeeper是一個分布式的，開放源碼的分布式應用程序協調服務，是Google的Chubby一個開源的實現，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分布式同步、組服務等。
11、HBase是一個分布式的、高可靠性、高性能、面向列、可伸縮的分布式存儲系統，該技術來源于Fay Chang所撰寫的Google論文“Bigtable：一個結構化數據的分布式存儲系統”。就像Bigtable利用了Google文件系統（File System）所提供的分布式數據存儲一樣，HBase在Hadoop之上提供了類似于Bigtable的能力。
三、HDFS架構
四、NameNode
NameNode管理文件系統的命名空間
??? 文件的block副本個數
??? 修改和訪問的時間
??? 訪問權限
??? block大小以及組成文件的block列表信息
??? 命名空間鏡像文件（fsimage）和編輯日志（edits log）。
| 1、文件名稱和路徑 2、文件的大小 3、文件的所屬關系 4、文件的block塊大小 ?128MB? 5、文件的副本個數 ?3?? MR? 10個副本 6、文件的修改時間 7、文件的訪問時間 8、文件的權限 9、文件的block列表 ??? blk1:0,134217728,node1,node13,node26：blockID ??? blk2:134217728,134217728,node7,node89,node1002 ??? blk2:134217728*2,134217728,node7,node89,node1002 ??? blk2:134217728*3,134217728,node7,node89,node1002 ??? blk2:134217728*4,134217728,node7,node89,node1002 ??? blk2:134217728*5,134217728,node7,node89,node1002 ??? blk2:134217728,134217728,node7,node89,node1002 ??? blk2:134217728,134217728,node7,node89,node1002 ??? ... |
存儲結構
一個運行的NameNode如下的目錄結構，該目錄結構在第一次格式化的時候創建
?
如果屬性dfs.namenode.name.dir指定了多個路徑，則每個路徑中的內容是一樣的，尤其是當其中一個是掛載的NFS的時候，這種機制為管理提供了一些彈性。備份數據
in_use.lock文件用于NameNode鎖定存儲目錄。這樣就防止其他同時運行的NameNode實例使用相同的存儲目錄。
edits表示edits log日志文件
fsimage表示文件系統元數據鏡像文件
NameNode在checkpoint之前首先要切換新的edits log文件，在切換時更新seen_txid的值。上次合并fsimage和editslog之后的第一個操作編號
VERSION文件是一個Java的屬性文件
?
layoutVersion是一個負數，定義了HDFS持久化數據結構的版本。這個版本數字跟hadoop發行的版本無關。當layout改變的時候，該數字減1（比如從-57到-58）。當對HDFDS進行了升級，就會發生layoutVersion的改變。
namespaceID是該文件系統的唯一標志符，當NameNode第一次格式化的時候生成。
clusterID是HDFS集群使用的一個唯一標志符，在HDFS聯邦的情況下，就看出它的作用了，因為聯邦情況下，集群有多個命名空間，不同的命名空間由不同的NameNode管理。
blockpoolID是block池的唯一標志符，一個NameNode管理一個命名空間，該命名空間中的所有文件存儲的block都在block池中。
cTime標記著當前NameNode創建的時間。對于剛格式化的存儲，該值永遠是0，但是當文件系統更新的時候，這個值就會更新為一個時間戳。
storageType表示當前目錄存儲NameNode內容的數據結構。
?
當文件系統客戶端進行了寫操作（例如創建或移動了文件），這個事務首先在edits log中記錄下來。NameNode在內存中有文件系統的元數據，當edits log記錄結束后，就更新內存中的元數據。內存中的元數據用于響應客戶端的讀請求。
edits log在磁盤上表現為一定數量的文件。每個文件稱為片段（Segment），前綴“edits”，后綴是其中包含的事務ID（transaction IDs）。每個寫操作事務都僅僅打開一個文件（比如：edits_inprogress_00000000000010），寫完后沖刷緩沖區并同步到磁盤，然后返回客戶端success狀態碼。如果NameNode的元數據需要寫到多個目錄中，則對于每個寫事務需要所有的寫操作都完成，并沖刷緩沖區同步到磁盤才返回success狀態碼。這樣就可以保證在發生宕機的時候沒有事務數據丟失。
用戶的操作是一個事務，每個操作NN都要先將操作記錄到edits log中，如果給NN指定了多個目錄，則在多個目錄中都存在edits log文件，用戶的操作要在多個目錄中都寫完成，才讓NN同步數據到內存中。當NN在內存中也同步了數據，就返回客戶端success。
每個fsimage文件都是系統元數據的一個完整的持久化檢查點（checkpoint）（后綴表示鏡像中的最后一個事務）。寫操作不更新這個數據，因為鏡像文件通常為GB數量級，寫到磁盤很慢。如果NameNode宕機，可以將最新fsimage加載到內存，同時執行edits log對應于該faimage之后的操作，就可以重建元數據的狀態。而這正是每次啟動NameNode的時候NameNode要做的工作。
tb_user
update tb_user set username='張三' where id=7000;
my.log : update tb_user set username='張三' where id=7000;
SecondaryNameNode
存在的意義
edits log會隨著對文件系統的操作而無限制地增長，這對正在運行的NameNode而言沒有任何影響，如果NameNode重啟，則需要很長的時間執行edits log的記錄以更新fsimage（元數據鏡像文件）。在此期間，整個系統不可用。
在系統啟動期間，NameNode合并fsimage+edits log
fsimage=0
edist log=很大
內存
fsimage=GB
edits log=很大 TB
內存->執行edits log條目
解決方案就是運行SecondaryNameNode，它的作用就是為NameNode內存中的文件系統元數據生成檢查點（checkpoint）。fsimage
工作流程
edits_inprogress_00000000018_0000000028? seen_txid=29
1、secondarynamenode請求namenode生成新的edits log文件并向其中寫日志。NameNode會在所有的存儲目錄中更新seen_txid文件
2、SecondaryNameNode通過HTTP GET的方式從NameNode下載fsimage和edits文件到本地。
3、SecondaryNameNode將fsimage加載到自己的內存，并根據edits log更新內存中的fsimage信息，然后將更新完畢之后的fsimage寫到磁盤上。
4、SecondaryNameNode通過HTTP PUT將新的fsimage文件發送到NameNode，NameNode將該文件保存為.ckpt的臨時文件備用。
5、NameNode重命名該臨時文件并準備使用。此時NameNode擁有一個新的fsimage文件和一個新的很小的edits log文件（可能不是空的，因為在SecondaryNameNode合并期間可能對元數據進行了讀寫操作）。管理員也可以將NameNode置于safemode，通過hdfs dfsadmin -saveNamespace命令來進行edits log和fsimage的合并。
SecondaryNameNode要和NameNode擁有相同的內存。對大的集群，SecondaryNameNode運行于一臺專用的物理主機。
?
檢查點創建時機
對于創建檢查點（checkpoint）的過程，有三個參數進行配置：
1、默認情況下，SecondaryNameNode每個小時進行一次checkpoint合并
??? 由dfs.namenode.checkpoint.period設置，單位秒
2、在不足一小時的情況下，如果edits log存儲的事務達到了1000000個也進行一次checkpoint合并
??? 由dfs.namenode.checkpoint.txns設置事務數量
3、事務數量檢查默認每分鐘進行一次
??? 由dfs.namenode.checkpoint.check.period設置，單位秒。
總結：
| namenode 管理文件元數據 ??? 文件名稱、大小、所屬關系、權限、副本大小、副本個數 ??? 文件塊的列表信息：(塊的ID，偏移量，塊的大小，塊所在的主機名稱列表) 持久化文件 ??? fsimage(內存快照)，edits log ??? fsimage很大，GB級別；edits log只追加的文件 ??? 用戶操作首先記錄到edits log中，然后更新內存 fsimage不保存數據塊位置信息 ??? 在系統啟動的時候，datanode向namenode發送文件塊列表信息（bid） ??? datanode通過心跳向namenode匯報列表信息。 namenode元數據正常工作時，元數據放內存，高并發。 secondarynamenode 在系統啟動的時候，namenode首先加載fsimage，然后逐條執行edits log中的日志操作，如果edits log很大，則需要很長時間才能加載完畢，向磁盤寫新的fsimage，之后才可以對外提供服務。 周期性地從namenode拷貝fsimage+edits log，在SNN中合并為新的fsimage，推送給namenode。 條件：1、每小時一次，2、不足一小時，則只要edits log中記錄的事務數達到了1000000，則合并。 datanode ??? ？ |
存儲結構
?
1、SecondaryNameNode中checkpoint目錄布局（dfs.namenode.checkpoint.dir）和NameNode中的一樣。
2、如果NameNode完全壞掉（沒有備用機，也沒有NFS），可以快速地從SecondaryNameNode恢復。有可能丟數據
3、如果SecondaryNameNode直接接手NameNode的工作，需要在啟動NameNode進程的時候添加-importCheckpoint選項。該選項會讓NameNode從由dfs.namenode.checkpoint.dir屬性定義的路徑中加載最新的checkpoint數據，但是為了防止元數據的覆蓋，要求dfs.namenode.name.dir定義的目錄中沒有內容。
DataNode
存儲結構
DataNode不需要顯式地格式化;關鍵文件和目錄結構如下：
?
1、HDFS塊數據存儲于blk_前綴的文件中，包含了被存儲文件原始字節數據的一部分。
2、每個block文件都有一個.meta后綴的元數據文件關聯。該文件包含了一個版本和類型信息的頭部，后接該block中每個部分的校驗和。
3、每個block屬于一個block池，每個block池有自己的存儲目錄，該目錄名稱就是該池子的ID（跟NameNode的VERSION文件中記錄的block池ID一樣）。
當一個目錄中的block達到64個（通過dfs.datanode.numblocks配置）的時候，DataNode會創建一個新的子目錄來存放新的block和它們的元數據。這樣即使當系統中有大量的block的時候，目錄樹也不會太深。同時也保證了在每個目錄中文件的數量是可管理的，避免了多數操作系統都會碰到的單個目錄中的文件個數限制（幾十幾百上千個）。
如果dfs.datanode.data.dir指定了位于在不同的硬盤驅動器上的多個不同的目錄，則會通過輪詢的方式向目錄中寫block數據。需要注意的是block的副本不會在同一個DataNode上復制，而是在不同的DataNode節點之間復制。
存儲數據模型(重點)
1、文件線性切割成塊（Block）（按字節切割）
2、Block分散存儲在集群節點中
3、單一文件Block大小一致，文件與文件可以不一致
??? hdfs? dfs? -D? dfs.blocksize=1048576? -D dfs.replication=3? -put hello.txt? /
4、Block可以設置副本數，副本分散在不同節點中
??? a) 副本數不要超過節點數量
??? b) 承擔計算
??? c) 容錯
5、文件上傳可以設置Block大小和副本數
6、已上傳的文件Block副本數可以調整，大小不變
7、只支持一次寫入多次讀取，同一時刻只有一個寫入者
??? 對同一個文件，一個時刻只有一個寫入者
8、可以append追加數據
優勢（了解）
?
?
數據塊副本放置策略
Block的副本放置策略
第一個副本：放置在上傳文件的DN；如果是集群外提交，則隨機挑選一臺磁盤不太滿，CPU不太忙的節點。
第二個副本：放置在于第一個副本不同的 機架的節點上。
第三個副本：與第二個副本相同機架的節點。
更多副本：隨機節點
源代碼：
?
HDFS的權限（了解）
1、每個文件和目錄都和一個擁有者和組相關聯。
2、文件或者目錄對與擁有者、同組用戶和其他用戶擁有獨立的權限。
3、對于一個文件，r表示讀取的權限，w表示寫或者追加的權限。對于目錄而言，r表示列出目錄內容的權限，w表示創建或者刪除文件和目錄的權限，x表示訪問該目錄子項目的權限。
4、默認情況下hadoop運行時安全措施處于停用模式。一個客戶端可以在遠程系統上通過創建和任意一個合法用戶同名的賬號來進行訪問。 hadoop? root
5、安全措施可以防止用戶或自動工具及程序意外修改或刪除文件系統的重要部分。（dfs.permissions.enabled屬性）。防止好人做錯事。
6、超級用戶是namenode進程的標識。對于超級用戶，系統不會執行任何權限檢查。
總結
以上是生活随笔為你收集整理的Hadoop核心组件及组件介绍的全部內容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： java环境变量的设置方法_Java环境
- 下一篇： 绩效评估模板问题