一、核心組件

1、Hadoop通用組件 -? Hadoop Common

包含了其他hadoop模塊要用到的庫文件和工具

2、分布式文件系統(tǒng) - Hadoop Distributed File System （HDFS）

運行于通用硬件上的分布式文件系統(tǒng)，高吞吐，高可靠

3、資源管理組件 - Hadoop YARN

于2012年引入的組件，用于管理集群中的計算資源并在這些資源上調度用戶應用

4、分布式計算框架 - Hadoop MapReduce

用于處理超大數(shù)據(jù)集計算的MapReduce編程模型的實現(xiàn)

二、Hadoop關聯(lián)項目

1、Apache Ambari 是一種基于Web的工具，支持Apache Hadoop集群的供應、管理和監(jiān)控。Apache Ambari 支持HDFS、MapReduce、Hive、Pig、Hbase、Zookeepr、Sqoop和Hcatalog等的集中管理。也是5個頂級hadoop管理工具之一。

2、Avro：數(shù)據(jù)序列化系統(tǒng)

3、Cassandra是一套開源分布式NoSQL數(shù)據(jù)庫系統(tǒng)。他最初由Facebook開發(fā)，用于儲存收件箱等簡單格式數(shù)據(jù)，集GoogleBigTable的數(shù)據(jù)模型與Amazon Dynamo的完全分布式的架構于一身，Facebook于2008將Caddandra開源。

4、chukwa是一個開源的用于監(jiān)控大型分布式系統(tǒng)的數(shù)據(jù)收集系統(tǒng)。這是構建在hadoop的HDFS和MapReduce框架之上的，繼承了hadoop的可伸縮性和健壯性。Chukwa還包含了一個強大的靈活的工具集，可用于展示、監(jiān)控和分析已收集的數(shù)據(jù)。

5、hive 是基于Hadoop的一個數(shù)據(jù)倉庫工具，可以將結構化的數(shù)據(jù)文件映射為一張數(shù)據(jù)庫表，并提供簡單的sql查詢功能，可以將sql語句轉換為MapReduce任務進行運行。

6、Mahout提供一些可擴展的機器學習領域經典算法的實現(xiàn)，旨在幫助開發(fā)人員更加方便快捷的創(chuàng)建智能應用程序。Mahout包含許多實現(xiàn)，包括聚類、分類、推薦過濾、頻繁子項挖掘。此外，通過使用Apache Hadoop庫，Mahout可以有效的擴展到云中。

7、Apache Pig 是一個高級過程語言，適合于使用Hadoop 和 MapReduce 平臺來查詢大型半結構化數(shù)據(jù)集。通過允許對分布式數(shù)據(jù)集進行類似SQL的查詢，Pig可以簡化Hadoop的使用。

8、Apache Spark是專為大規(guī)模數(shù)據(jù)處理而設計的快速通用的計算引擎。Spark是UCBerkeley AMP lab開源的類Hadoop MapReduce的通用并行框架，擁有MapReduce具有的優(yōu)點。

9、Tez 是 Apache 最新的支持 DAG 作業(yè)的開源計算框架。它允許開發(fā)者為最終用戶構建性能更快、擴展性更好的應用程序。Hadoop傳統(tǒng)上是一個大量數(shù)據(jù)批處理平臺。但是，有很多用例需要近乎實時的查詢處理性能。還有一些工作則不太適合MapReduce，例如機器學習。Tez的目的就是幫助Hadoop處理這些用例場景。

10、ZooKeeper是一個分布式的，開放源碼的分布式應用程序協(xié)調服務，是Google的Chubby一個開源的實現(xiàn)，是Hadoop和Hbase的重要組件。它是一個為分布式應用提供一致性服務的軟件，提供的功能包括：配置維護、域名服務、分布式同步、組服務等。

11、HBase是一個分布式的、高可靠性、高性能、面向列、可伸縮的分布式存儲系統(tǒng)，該技術來源于Fay Chang所撰寫的Google論文“Bigtable：一個結構化數(shù)據(jù)的分布式存儲系統(tǒng)”。就像Bigtable利用了Google文件系統(tǒng)（File System）所提供的分布式數(shù)據(jù)存儲一樣，HBase在Hadoop之上提供了類似于Bigtable的能力。

三、HDFS架構

硬件錯誤

硬件錯誤是常態(tài)而不是異常。

HDFS可能由成百上千的服務器所構成，單機故障概率的存在意味著總有一部分服務器不工作的。

錯誤檢測和快速自動恢復是HDFS最核心架構目標。

流式數(shù)據(jù)訪問

運行在HDFS上的應用需要流式訪問它們的數(shù)據(jù)集。

HDFS的設計重點是批處理，而不是交互處理。是高吞吐量而不是低延遲。

為了提高數(shù)據(jù)的吞吐量，在關鍵方面修改POSIX的語義。

大規(guī)模數(shù)據(jù)集

HDFS上的一個典型文件大小一般都在G字節(jié)至T字節(jié)。

HDFS支持大文件存儲。

單一HDFS實例能支撐數(shù)以千萬計的文件。

簡單的一致性模型

HDFS應用遵循“一次寫入多次讀取”的文件訪問模型。

簡化了數(shù)據(jù)一致性問題，并且使高吞吐量的數(shù)據(jù)訪問成為可能。

Map/Reduce應用或者網絡爬蟲應用都非常適合這個模型。

移動計算比移動數(shù)據(jù)更劃算

降低網絡阻塞的影響，提高系統(tǒng)數(shù)據(jù)的吞吐量。

將計算程序發(fā)送到數(shù)據(jù)所在的主機，比GB級別TB級別的數(shù)據(jù)移動更便捷。

異構軟硬件平臺間的可移植性

HDFS在設計的時候就考慮到平臺的可移植性。

這種特性方便了HDFS作為大規(guī)模數(shù)據(jù)應用平臺的推廣。

四、NameNode

NameNode管理文件系統(tǒng)的命名空間

文件和目錄的元數(shù)據(jù)：(運行時，元數(shù)據(jù)放內存)

??? 文件的block副本個數(shù)

??? 修改和訪問的時間

??? 訪問權限

??? block大小以及組成文件的block列表信息

以兩種方式在NameNode本地進行持久化：

??? 命名空間鏡像文件（fsimage）和編輯日志（edits log）。

fsimage文件不記錄每個block所在的DataNode信息，這些信息在每次系統(tǒng)啟動的時候從DataNode重建。之后DataNode會周期性地通過心跳包向NameNode報告block信息。DataNode向NameNode注冊的時候NameNode請求DataNode發(fā)送block列表信息。

1、文件名稱和路徑 2、文件的大小 3、文件的所屬關系 4、文件的block塊大小 ?128MB? 5、文件的副本個數(shù) ?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如下的目錄結構，該目錄結構在第一次格式化的時候創(chuàng)建

?

如果屬性dfs.namenode.name.dir指定了多個路徑，則每個路徑中的內容是一樣的，尤其是當其中一個是掛載的NFS的時候，這種機制為管理提供了一些彈性。備份數(shù)據(jù)

in_use.lock文件用于NameNode鎖定存儲目錄。這樣就防止其他同時運行的NameNode實例使用相同的存儲目錄。

edits表示edits log日志文件

fsimage表示文件系統(tǒng)元數(shù)據(jù)鏡像文件

NameNode在checkpoint之前首先要切換新的edits log文件，在切換時更新seen_txid的值。上次合并fsimage和editslog之后的第一個操作編號

VERSION文件是一個Java的屬性文件

?

layoutVersion是一個負數(shù)，定義了HDFS持久化數(shù)據(jù)結構的版本。這個版本數(shù)字跟hadoop發(fā)行的版本無關。當layout改變的時候，該數(shù)字減1（比如從-57到-58）。當對HDFDS進行了升級，就會發(fā)生layoutVersion的改變。

namespaceID是該文件系統(tǒng)的唯一標志符，當NameNode第一次格式化的時候生成。

clusterID是HDFS集群使用的一個唯一標志符，在HDFS聯(lián)邦的情況下，就看出它的作用了，因為聯(lián)邦情況下，集群有多個命名空間，不同的命名空間由不同的NameNode管理。

blockpoolID是block池的唯一標志符，一個NameNode管理一個命名空間，該命名空間中的所有文件存儲的block都在block池中。

cTime標記著當前NameNode創(chuàng)建的時間。對于剛格式化的存儲，該值永遠是0，但是當文件系統(tǒng)更新的時候，這個值就會更新為一個時間戳。

storageType表示當前目錄存儲NameNode內容的數(shù)據(jù)結構。

?

當文件系統(tǒng)客戶端進行了寫操作（例如創(chuàng)建或移動了文件），這個事務首先在edits log中記錄下來。NameNode在內存中有文件系統(tǒng)的元數(shù)據(jù)，當edits log記錄結束后，就更新內存中的元數(shù)據(jù)。內存中的元數(shù)據(jù)用于響應客戶端的讀請求。

edits log在磁盤上表現(xiàn)為一定數(shù)量的文件。每個文件稱為片段（Segment），前綴“edits”，后綴是其中包含的事務ID（transaction IDs）。每個寫操作事務都僅僅打開一個文件（比如：edits_inprogress_00000000000010），寫完后沖刷緩沖區(qū)并同步到磁盤，然后返回客戶端success狀態(tài)碼。如果NameNode的元數(shù)據(jù)需要寫到多個目錄中，則對于每個寫事務需要所有的寫操作都完成，并沖刷緩沖區(qū)同步到磁盤才返回success狀態(tài)碼。這樣就可以保證在發(fā)生宕機的時候沒有事務數(shù)據(jù)丟失。

用戶的操作是一個事務，每個操作NN都要先將操作記錄到edits log中，如果給NN指定了多個目錄，則在多個目錄中都存在edits log文件，用戶的操作要在多個目錄中都寫完成，才讓NN同步數(shù)據(jù)到內存中。當NN在內存中也同步了數(shù)據(jù)，就返回客戶端success。

每個fsimage文件都是系統(tǒng)元數(shù)據(jù)的一個完整的持久化檢查點（checkpoint）（后綴表示鏡像中的最后一個事務）。寫操作不更新這個數(shù)據(jù)，因為鏡像文件通常為GB數(shù)量級，寫到磁盤很慢。如果NameNode宕機，可以將最新fsimage加載到內存，同時執(zhí)行edits log對應于該faimage之后的操作，就可以重建元數(shù)據(jù)的狀態(tài)。而這正是每次啟動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會隨著對文件系統(tǒng)的操作而無限制地增長，這對正在運行的NameNode而言沒有任何影響，如果NameNode重啟，則需要很長的時間執(zhí)行edits log的記錄以更新fsimage（元數(shù)據(jù)鏡像文件）。在此期間，整個系統(tǒng)不可用。

在系統(tǒng)啟動期間，NameNode合并fsimage+edits log

fsimage=0

edist log=很大

內存

fsimage=GB

edits log=很大 TB

內存->執(zhí)行edits log條目

解決方案就是運行SecondaryNameNode，它的作用就是為NameNode內存中的文件系統(tǒng)元數(shù)據(jù)生成檢查點（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加載到自己的內存，并根據(jù)edits log更新內存中的fsimage信息，然后將更新完畢之后的fsimage寫到磁盤上。

4、SecondaryNameNode通過HTTP PUT將新的fsimage文件發(fā)送到NameNode，NameNode將該文件保存為.ckpt的臨時文件備用。

5、NameNode重命名該臨時文件并準備使用。此時NameNode擁有一個新的fsimage文件和一個新的很小的edits log文件（可能不是空的，因為在SecondaryNameNode合并期間可能對元數(shù)據(jù)進行了讀寫操作）。管理員也可以將NameNode置于safemode，通過hdfs dfsadmin -saveNamespace命令來進行edits log和fsimage的合并。

SecondaryNameNode要和NameNode擁有相同的內存。對大的集群，SecondaryNameNode運行于一臺專用的物理主機。

?

檢查點創(chuàng)建時機

對于創(chuàng)建檢查點（checkpoint）的過程，有三個參數(shù)進行配置：

1、默認情況下，SecondaryNameNode每個小時進行一次checkpoint合并

??? 由dfs.namenode.checkpoint.period設置，單位秒

2、在不足一小時的情況下，如果edits log存儲的事務達到了1000000個也進行一次checkpoint合并

??? 由dfs.namenode.checkpoint.txns設置事務數(shù)量

3、事務數(shù)量檢查默認每分鐘進行一次

??? 由dfs.namenode.checkpoint.check.period設置，單位秒。

總結：

namenode 管理文件元數(shù)據(jù) ??? 文件名稱、大小、所屬關系、權限、副本大小、副本個數(shù) ??? 文件塊的列表信息：(塊的ID，偏移量，塊的大小，塊所在的主機名稱列表) 持久化文件 ??? fsimage(內存快照)，edits log ??? fsimage很大，GB級別；edits log只追加的文件 ??? 用戶操作首先記錄到edits log中，然后更新內存 fsimage不保存數(shù)據(jù)塊位置信息 ??? 在系統(tǒng)啟動的時候，datanode向namenode發(fā)送文件塊列表信息（bid） ??? datanode通過心跳向namenode匯報列表信息。 namenode元數(shù)據(jù)正常工作時，元數(shù)據(jù)放內存，高并發(fā)。 secondarynamenode 在系統(tǒng)啟動的時候，namenode首先加載fsimage，然后逐條執(zhí)行edits log中的日志操作，如果edits log很大，則需要很長時間才能加載完畢，向磁盤寫新的fsimage，之后才可以對外提供服務。 周期性地從namenode拷貝fsimage+edits log，在SNN中合并為新的fsimage，推送給namenode。 條件：1、每小時一次，2、不足一小時，則只要edits log中記錄的事務數(shù)達到了1000000，則合并。 datanode ??? ？

存儲結構

?

1、SecondaryNameNode中checkpoint目錄布局（dfs.namenode.checkpoint.dir）和NameNode中的一樣。

2、如果NameNode完全壞掉（沒有備用機，也沒有NFS），可以快速地從SecondaryNameNode恢復。有可能丟數(shù)據(jù)

3、如果SecondaryNameNode直接接手NameNode的工作，需要在啟動NameNode進程的時候添加-importCheckpoint選項。該選項會讓NameNode從由dfs.namenode.checkpoint.dir屬性定義的路徑中加載最新的checkpoint數(shù)據(jù)，但是為了防止元數(shù)據(jù)的覆蓋，要求dfs.namenode.name.dir定義的目錄中沒有內容。

DataNode

存儲結構

DataNode不需要顯式地格式化;關鍵文件和目錄結構如下：

?

1、HDFS塊數(shù)據(jù)存儲于blk_前綴的文件中，包含了被存儲文件原始字節(jié)數(shù)據(jù)的一部分。

2、每個block文件都有一個.meta后綴的元數(shù)據(jù)文件關聯(lián)。該文件包含了一個版本和類型信息的頭部，后接該block中每個部分的校驗和。

3、每個block屬于一個block池，每個block池有自己的存儲目錄，該目錄名稱就是該池子的ID（跟NameNode的VERSION文件中記錄的block池ID一樣）。

當一個目錄中的block達到64個（通過dfs.datanode.numblocks配置）的時候，DataNode會創(chuàng)建一個新的子目錄來存放新的block和它們的元數(shù)據(jù)。這樣即使當系統(tǒng)中有大量的block的時候，目錄樹也不會太深。同時也保證了在每個目錄中文件的數(shù)量是可管理的，避免了多數(shù)操作系統(tǒng)都會碰到的單個目錄中的文件個數(shù)限制（幾十幾百上千個）。

如果dfs.datanode.data.dir指定了位于在不同的硬盤驅動器上的多個不同的目錄，則會通過輪詢的方式向目錄中寫block數(shù)據(jù)。需要注意的是block的副本不會在同一個DataNode上復制，而是在不同的DataNode節(jié)點之間復制。

存儲數(shù)據(jù)模型(重點)

1、文件線性切割成塊（Block）（按字節(jié)切割）

2、Block分散存儲在集群節(jié)點中

3、單一文件Block大小一致，文件與文件可以不一致

??? hdfs? dfs? -D? dfs.blocksize=1048576? -D dfs.replication=3? -put hello.txt? /

4、Block可以設置副本數(shù)，副本分散在不同節(jié)點中

??? a) 副本數(shù)不要超過節(jié)點數(shù)量

??? b) 承擔計算

??? c) 容錯

5、文件上傳可以設置Block大小和副本數(shù)

6、已上傳的文件Block副本數(shù)可以調整，大小不變

7、只支持一次寫入多次讀取，同一時刻只有一個寫入者

??? 對同一個文件，一個時刻只有一個寫入者

8、可以append追加數(shù)據(jù)

優(yōu)勢（了解）

一個文件的大小可以大于網絡中任意一個磁盤的容量

使用抽象塊而非整個文件作為存儲單元，大大簡化存儲子系統(tǒng)的設計

塊非常適合用于數(shù)據(jù)備份進而提供數(shù)據(jù)容錯能力和提高可用性

?

?

數(shù)據(jù)塊副本放置策略

Block的副本放置策略

第一個副本：放置在上傳文件的DN；如果是集群外提交，則隨機挑選一臺磁盤不太滿，CPU不太忙的節(jié)點。

第二個副本：放置在于第一個副本不同的 機架的節(jié)點上。

第三個副本：與第二個副本相同機架的節(jié)點。

更多副本：隨機節(jié)點

源代碼：

?

HDFS的權限（了解）

1、每個文件和目錄都和一個擁有者和組相關聯(lián)。

2、文件或者目錄對與擁有者、同組用戶和其他用戶擁有獨立的權限。

3、對于一個文件，r表示讀取的權限，w表示寫或者追加的權限。對于目錄而言，r表示列出目錄內容的權限，w表示創(chuàng)建或者刪除文件和目錄的權限，x表示訪問該目錄子項目的權限。

4、默認情況下hadoop運行時安全措施處于停用模式。一個客戶端可以在遠程系統(tǒng)上通過創(chuàng)建和任意一個合法用戶同名的賬號來進行訪問。 hadoop? root

5、安全措施可以防止用戶或自動工具及程序意外修改或刪除文件系統(tǒng)的重要部分。（dfs.permissions.enabled屬性）。防止好人做錯事。

6、超級用戶是namenode進程的標識。對于超級用戶，系統(tǒng)不會執(zhí)行任何權限檢查。

總結

以上是生活随笔為你收集整理的Hadoop核心组件及组件介绍的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。