企業(yè)大數(shù)據(jù)基礎(chǔ)平臺(tái)搭建和開發(fā)代碼

目錄

理解HadoopHDFS5

1.介紹5

2.HDFS設(shè)計(jì)原則5

2.1設(shè)計(jì)目標(biāo)5

2.2系統(tǒng)架構(gòu)和容錯(cuò)性設(shè)計(jì)6

2.3HDFS不適合的應(yīng)用類型6

2.4HDFS的存儲(chǔ)策略6

3.HDFS核心概念6

3.1Blocks6

3.2Namcnodc&Datantxic6

3.3BlockCaching7

3.4HDFSFederation7

3.5HDFSHA（HighAvailability高可用性）7

4.命令行接口8

5.Hadoop文件系統(tǒng)10

6.Java接口12

6.1讀操作12

6.2寫數(shù)據(jù)13

6.3目錄操作13

6.4刪除數(shù)據(jù)14

7.數(shù)據(jù)流（讀寫流程）14

7.1讀文件14

7.2寫文件14

7.3一致性模型16

7.4Hadoop節(jié)點(diǎn)距離16

8相關(guān)運(yùn)維工具17

8.1使用distcp并行復(fù)制17

8.2平衡HDFS集群17

9HDFS機(jī)架感知概念及配置實(shí)現(xiàn)17

一、機(jī)架感知是什么？17

二、那么怎么告訴呢？17

三、什么情況下會(huì)涉及到機(jī)架感知？18

四、機(jī)架感知需要考慮的情況（權(quán)衡可施性、可用性、帶寬消耗）18

五、通過什么方式能夠告知HadoopNameNode哪些Slaves機(jī)器屬于哪個(gè)Rack?以下是配置步驟。18

六、網(wǎng)絡(luò)拓?fù)錂C(jī)器之間的距離19

10使用HDFS管理界面20

YARN20

基本架構(gòu)21

工作機(jī)制2.

ResourceManager2.

資源管理2：

任務(wù)調(diào)度22

內(nèi)部結(jié)構(gòu)22

作業(yè)提交全過程22

資源調(diào)度器23

任務(wù)的推測執(zhí)行24

YARN的WEBUI的使用說明25

集群運(yùn)行狀態(tài)查看27

Hadoop3.0新特性28

HadoopCommon28

HadoopHDFS28

lladoopMapReduce29

HadoopYARN29

總結(jié)29

Hive內(nèi)部表和外部表的區(qū)別32

概念理解32

創(chuàng)建內(nèi)部表H32

裝載數(shù)據(jù)（11）33

創(chuàng)建一個(gè)外部表1234

裝載數(shù)據(jù)（t2）35

查看文件位置35

觀察HDFS上的文件38

重新創(chuàng)建外部表1239

官網(wǎng)解釋40

Hive數(shù)據(jù)倉庫之拉鏈表，流水表，全量表，增量表40

Hadoop3.2.0完全分布式集群搭建43

一.集群環(huán)境格建43

二.Hadoop配置修改45

修改hadoop-env.sh配置jdk路徑，定義集群操作用戶45

修改core-site,xmlhadoop核心配置45

修改hdfs-site.xmlhadoop從節(jié)點(diǎn)配置45

修改workers告知hadoophdfs上有哪些DataNode節(jié)點(diǎn)46

修改yarn-site,xml配置yarn服務(wù)46

修改mapred-site?xml文件46

將修改好的配置文件分發(fā)到從節(jié)點(diǎn)的三臺(tái)服務(wù)器上47

H.Hadoop服務(wù)啟動(dòng)47

叫運(yùn)行WorcCount49

在Linux平臺(tái)下載MySQL51

yum安裝MySQL54

Hive環(huán)境搭建58

一、安裝59

二、配置管理59

三、運(yùn)行6：

四、常用優(yōu)化方法67

1.常用MapReduce作業(yè)配置參數(shù)67

2.常見問題及參數(shù)設(shè)置68

3.其它常用參數(shù)設(shè)置68

4.HiveSQL控制map數(shù)和reduce數(shù)69

5.動(dòng)態(tài)分區(qū)無Reduce產(chǎn)生小文件處理69

6.處理countdistinct產(chǎn)生數(shù)據(jù)傾斜處理70

五、分區(qū)表和分桶表的區(qū)別7.

ApacheMahout環(huán)境搭建71

Sqoop安裝73

PySpark環(huán)境搭建77

在Linux平臺(tái)下載Python3.877

1、依賴安裝77

2、下載安裝包77

3、解壓77

4、安裝78

5、添加軟桂接78

6、測試78

Linux下升級安裝python3.8?并配置pip及yum78

Linux安裝Python3.8環(huán)境，卸載舊Python8.

安裝最新版Python2.7.13和Python3.6.2（Python2和Python3共存，修改后默認(rèn)版本為Python3.6.2）82

Linux上安裝ApacheSpark3.1.0詳細(xì)步驟84

Spark的安裝與配置8?

Spark集群的安裝與設(shè)置89

Ubuntu12.04下Hadoop2.2.0集群搭建92

Ubuntu14.04下安裝Hadoop2.4.0（單機(jī)模式）98

啟動(dòng)Spark集群105

Spark性能優(yōu)化110

1、Spark作業(yè)基本運(yùn)行原理112

2、資源參數(shù)調(diào)優(yōu)112

num-executors112

cxecutor-ncmory113

executor-cores113

driver-raenory113

spark,default,parallelism113

spark,storage.mcmoryFraction113

spark,shuffle.mcmoryFraction113

3、資源參數(shù)參考示例114

4、Spark中E勺三種Join策略114

BroadcastHashJoin114

ShuffleHashJoin114

SortMergeJoin115

5、Spark3.D中AQE新特性116

6、數(shù)據(jù)倉庫中數(shù)據(jù)優(yōu)化的一股原則119

7、Spark中的寬依賴和窄依賴119

概述119

詳細(xì)運(yùn)行原理120

8、DAG的生成和劃分Stage123

DAG介紹123

DAG劃分Stage123

9、Spark算子124

10^SparkRDD155

SparkRDD及其特性155

SparkRDD的核心特性155

11、用Spark計(jì)算MySQL的數(shù)據(jù)158

AWS大數(shù)據(jù)組件158

ETL設(shè)計(jì)開發(fā)過程158

關(guān)系型數(shù)據(jù)庫大數(shù)據(jù)性能優(yōu)化解決方案之分表（當(dāng)前表歷史表）、表分區(qū)、數(shù)據(jù)清理原則160

原因和目的160

數(shù)據(jù)是否需要清理的閾值判斷160

滿負(fù)載周期判斷160

遷移周期判斷160

不同類型數(shù)據(jù)的分區(qū)方案16.

歷史表的清理方案161

注意的點(diǎn)161

數(shù)據(jù)倉庫緩慢變化維（Slowchangingdemenison）的實(shí)現(xiàn)方案16'

MySQLsTeradata和PySpark代碼互轉(zhuǎn)表和代碼163

PySpark代碼基本結(jié)構(gòu)207

PySpark從MySQL導(dǎo)出數(shù)據(jù)到parquet文件208

PySpark從Teradata導(dǎo)出數(shù)據(jù)到parquet文件208

PySpark從Parqucnt文件寫入Hive表209

PySpark讀取HiveSQL查詢數(shù)據(jù)寫入parquet文件209

PySpark獲取Dataframe的采樣數(shù)據(jù)并保存到CSV文件209

PySpark連接MySUL數(shù)據(jù)庫插入數(shù)據(jù)21。

PySpark連接Teradata數(shù)據(jù)庫插入數(shù)據(jù)210

PySpark遍歷Dataframe所有行210

PySpark移動(dòng)Parquet文件所在目錄211

PySpark復(fù)制Parquet文件所在目錄211

PySpark刪除Parquet文件所在目錄212

PySpark修改Hive指向的存儲(chǔ)路徑212

PySpark顯示HDFS路徑下的文件212

PySpark顯示普通Hive表的容量(GB)212

PySpark顯示Hive分區(qū)表的容量(GB)212

PySpark顯示HDFS目錄下每個(gè)子目錄的容量212

PySpark調(diào)用Sqcx)p從HDFS導(dǎo)入到Hive表212

HiveQL從parquet文件創(chuàng)建Hive表213

HiveQL從Hi/e表創(chuàng)建Hive視圖213

HivcQI.格式化顯示Hive查詢結(jié)果數(shù)據(jù)213

Hive導(dǎo)出Hi?e查詢結(jié)果數(shù)據(jù)為CSV文件213

HiveQL顯示Hive所有的表213

HiveQL顯示Hive所有的數(shù)據(jù)庫214

Shell帶日期參數(shù)運(yùn)行HQL腳本214

HiveQL更新視圖指向當(dāng)天的表數(shù)據(jù)214

HiveQL修改Hive表指向的存儲(chǔ)文件215

Shell清除HDFS里的數(shù)據(jù)215

Shell查看HDFS數(shù)據(jù)215

Sqoop顯示MySQL中的數(shù)據(jù)庫215

Sqoop從MySQL數(shù)據(jù)庫導(dǎo)入HDFS215

Sqoop從HDFS數(shù)據(jù)庫導(dǎo)入MySQL217

Sqoop顯示M/SQL中的數(shù)據(jù)庫217

Teradata支持的數(shù)據(jù)類型218

MySQL支持的數(shù)據(jù)類型220

Hive支持的數(shù)據(jù)類型220

Parquet文件存儲(chǔ)格式221

項(xiàng)目組成22.

數(shù)據(jù)模型222

Striping/Assembly算法223

Parquet文件格式225

性能227

項(xiàng)目發(fā)展228

總結(jié)229

理解HadoopHDFS

文本詳細(xì)介紹了HDFS中的許多概念，對于理解Hadoop分布式文件系統(tǒng)很有幫助。

1.介紹

在現(xiàn)代的企業(yè)環(huán)境中，單機(jī)容量往往無法存儲(chǔ)大量數(shù)據(jù)，需要跨機(jī)器存儲(chǔ)。統(tǒng)一管理分布在集群上的文件系統(tǒng)稱為分布式文件系統(tǒng)。而一旦在系統(tǒng)

中，引入網(wǎng)絡(luò)，就不可避免地引入了所有網(wǎng)絡(luò)編程的豆雜性，例如挑戰(zhàn)之一是如果保證在節(jié)點(diǎn)不可用的時(shí)候數(shù)據(jù)不丟失。

傳統(tǒng)的網(wǎng)絡(luò)文件系統(tǒng)（NFS）雖然也稱為分布式文件系統(tǒng)，但是其存在一些限制。由于NFS中，文件是存儲(chǔ)在單機(jī)上，因此無法提供可靠性保

證，當(dāng)很多客戶端同時(shí)訪問NFSServer時(shí)，很容易造成服務(wù)器壓力，造成性能瓶頸。另外如果要對NFS中的文件進(jìn)行操作，需要首先同步到本

地，這些修改在同步到服務(wù)端之前，其它客戶端是不可見的。某種程度上，NFS不是一種典型的分布式系統(tǒng)，雖然它的文件的確放在遠(yuǎn)端（單一）

的服務(wù)器上面。

Figure2.Theclient-serverarchitectureofNFS

Figure3.TheclientandserverNFSstack

從NFS的協(xié)議或可以看到，它事實(shí)上是一種VFS（操作系統(tǒng)對文件的一種抽象）實(shí)現(xiàn)。

HDFS.是HadoopDisiribuledFileSystem的簡稱，是Hadoop抽象文件系統(tǒng)的,種實(shí)現(xiàn)。Hadoop抽象文件系統(tǒng)可以與本地系統(tǒng)、AmazonS3等集

成，甚至可以通過Web協(xié)議（webhsfs）來操作。HDFS的文件分布在集群機(jī)器上，同時(shí)提供副本進(jìn)行容錯(cuò)及可靠性保證。例如客戶端寫入讀取文

件的直接操作都是分布在集群各個(gè)機(jī)器上的，沒有單點(diǎn)性能壓力。

如果你從零開始搭建一個(gè)完整的集群，參考[Hadoop集群搭建詳細(xì)步驟（2.6.0）]（hllD：//blog.csdn.nel/bingduanlbd/article/delails/51892750）

2.HDFS設(shè)計(jì)原則

HDFS設(shè)計(jì)之初就非常明確其應(yīng)用場景，適用與什么類型的應(yīng)用，不適用什么應(yīng)用，有一-個(gè)相對明確的指導(dǎo)原則。

2.1設(shè)計(jì)目標(biāo)

?HDFS是Hadoop的核心項(xiàng)目，也是現(xiàn)在大數(shù)據(jù)領(lǐng)域的事實(shí)存儲(chǔ)標(biāo)準(zhǔn)。它的高容錯(cuò)性設(shè)計(jì)，使它可以運(yùn)行在大量的廉價(jià)商業(yè)硬件之上，那么

它的設(shè)計(jì)會(huì)有這么幾個(gè)假設(shè)的前提。

?首先，它會(huì)首先假設(shè)硬件的故障是一個(gè)通常現(xiàn)象。也就是說即使每一塊磁盤故障的概率非常小，當(dāng)你的服務(wù)器集群有數(shù)千臺(tái)甚至上萬臺(tái)節(jié)點(diǎn)

的時(shí)候，那這（磁盤故障）也是非常司空見慣的事情。所以說如何快速的發(fā)現(xiàn)、定位問題，并且快速地做故障恢復(fù)。這是它最重要的設(shè)計(jì)目

林。

?第二，HDFS適合于大容量數(shù)據(jù)，流式訪問這樣的場景。比如說在大數(shù)據(jù)場景下，動(dòng)輒就是上百G,甚至上T的文件。因此，相比于低延時(shí)

而言，它會(huì)更加在意批量處理，高吞吐這樣的訴求。

?第三，它是形成一個(gè)理念，就是移動(dòng)計(jì)算的代價(jià)小于移動(dòng)數(shù)據(jù)的代價(jià)。它也是大數(shù)據(jù)領(lǐng)域的一個(gè)普遍的共識(shí)。因此Hadoop在推出HDFS存

儲(chǔ)的時(shí)候，也推出了M叩Reduce計(jì)算框架，就是出于這個(gè)目的。

?還有，存儲(chǔ)非常大的文件：這里非常大指的是幾百M(fèi)、G、或者TB級別。實(shí)際應(yīng)用中已有很多集群存儲(chǔ)的數(shù)據(jù)達(dá)到PB級別。根據(jù)Hadoop

官網(wǎng)，Yahoo!的Hadoop集群約有10萬顆CPU,運(yùn)行在4萬個(gè)機(jī)器節(jié)點(diǎn)上。更多世界上的Hadoop集群使用情況，參考Hadocp官網(wǎng).

?以及，采用流式的數(shù)據(jù)訪問方式:HDFS基于這樣的一個(gè)假設(shè)：最有效的數(shù)據(jù)處理模式是一次寫入、多次諛取數(shù)據(jù)集經(jīng)常從數(shù)據(jù)源生成或者

拷貝一次，然后在其上做很多分析工作

分析工作經(jīng)常讀取其中的大部分?jǐn)?shù)據(jù)，即使不是全出。因此讀取整個(gè)數(shù)據(jù)集所需時(shí)間比讀取第一條記錄的延時(shí)更重要。

?最后，運(yùn)行于商業(yè)硬件上:Hadoop不需要特別貴的、reliable的（可旅的）機(jī)器，可運(yùn)行于普通商用機(jī)器（可以從多家供應(yīng)商采購），商用

機(jī)器不代表低端機(jī)器。在集群中（尤其是大的集群），節(jié)點(diǎn)失敗率是比較高的HDFS的目標(biāo)是確保集群在節(jié)點(diǎn)失敗的時(shí)候不會(huì)讓用戶感覺到

明顯的中斷。

2.2系統(tǒng)架構(gòu)和容錯(cuò)性設(shè)計(jì)

HFDS是一個(gè)典型的Master-Slave架構(gòu)，那這里NameNode用來存儲(chǔ)文件系統(tǒng)的元數(shù)據(jù)，比如說分塊的大小，文件路徑等等之類的。那數(shù)據(jù)是以

BLOCK的形式存儲(chǔ)在多個(gè)DataNode上的，那整體HDFS提供一個(gè)client對客戶提供一個(gè)文件系統(tǒng)的命名空間操作。比如說文件的打開、關(guān)閉、歪

命名、移動(dòng)等等。

那我們說到HDFS存儲(chǔ)文件，就不得不提到它的數(shù)據(jù)副本機(jī)制J。比如說這里的PART0文件，它包括了Block1和Block3這么兩個(gè)Block。同時(shí)，

它又被設(shè)置了replica,副本數(shù)等于2。因此，1和3這兩Block會(huì)被再豆制出另外一個(gè)1和另外一個(gè)3,存儲(chǔ)在另外一個(gè)DalaNode節(jié)點(diǎn)上，從而使

得這個(gè)文件被拆分為兩個(gè)Block存儲(chǔ)且擁有兩個(gè)副本。那這里面還有核心的問題就是，拆分后的數(shù)據(jù)會(huì)被存儲(chǔ)在地方（DataNode）,這樣一個(gè)調(diào)度

策略問題。那當(dāng)一個(gè)Block所有的副本都存在同一節(jié)點(diǎn)（DataBlock）上，這個(gè)節(jié)點(diǎn)掛掉的時(shí)候，數(shù)據(jù)不就丟失了嗎？HFDS是怎么解決這個(gè)問題

的呢？它引入了機(jī)架感知（RackAwareness）這樣一個(gè)概念。那這里我們引入了兩個(gè)機(jī)架RackI和Rack2,每臺(tái)機(jī)架上會(huì)有三個(gè)這樣的節(jié)點(diǎn)

（DataNode）.

2.3HDFS不適合的應(yīng)用類型

方?些場景不適合使用HDFS未存儲(chǔ)數(shù)據(jù)。下面列舉幾個(gè)：

I）低延時(shí)的數(shù)據(jù)訪問

對延時(shí)要求在瑩秒級別的應(yīng)用，不適合采用HDFS.HDFS是為高吞吐數(shù)據(jù)傳輸設(shè)計(jì)的，因此可能犧牲延時(shí)HBase更適合低延時(shí)的數(shù)據(jù)訪問。

2）大量小文件

文件的元數(shù)據(jù)（如目錄結(jié)構(gòu)，文件block的節(jié)點(diǎn)列表，block-nodemapping）保存在NameNode的內(nèi)存中，整個(gè)文件系統(tǒng)的文件數(shù)量:會(huì)受限于

NameNode的內(nèi)存大小。

我們不應(yīng)該把大量的小文件放在HDFS里邊去存儲(chǔ)，因?yàn)镹ameNode會(huì)在內(nèi)存里面維護(hù)整個(gè)的目錄樹，文件的數(shù)量越多，NameNode壓力越大，我

們應(yīng)該盡量的去減少NameNode的壓力。

經(jīng)驗(yàn)而言，一個(gè)文件/目錄/文件塊一般占有150字節(jié)的元數(shù)據(jù)內(nèi)存空間。如果有100萬個(gè)文件，每個(gè)文件占用I個(gè)文件塊，則需要大約300M的內(nèi)

存。因此十億級別的文件數(shù)量在現(xiàn)有商用機(jī)器上難以支持。

3）多方讀寫，需要任意的文件修改

HDFS采用追加（append-only）的方式寫入數(shù)據(jù)。不支持文件任意of優(yōu)et的修改。不支持多個(gè)寫入器（writer）?

2.4HDFS的存儲(chǔ)策略

HDFS針對不同類型的數(shù)據(jù)可以指定不同的策略，我們在HDFS上創(chuàng)建了一個(gè)文件夾，我們可以指定這個(gè)文件夾的存儲(chǔ)策略是hot,還是worm或

者是cold,如果說我們要求某一個(gè)文件夾下了數(shù)據(jù)能夠快速的被處理，我們也可以把這些數(shù)據(jù)造成策略指定為SSDo

3.HDFS核心概念

3.1Blocks

物理磁盤中有塊的概念，磁盤的物理Block是磁盤操作最小的單元，讀寫操作均以Block為最小單元，一般為512Byie.文件系統(tǒng)在物理Block之

上抽象了另一層概念，文件系統(tǒng)Block物理磁盤Block的整數(shù)倍。通常為幾KB。Hadoop提供的df、fsck這類運(yùn)維工具都是在文件系統(tǒng)的Block級

別上進(jìn)行操作。

HDFS的Block塊比一般單機(jī)文件系統(tǒng)大得多，默認(rèn)為128M。HDFS的文件被拆分成block-sized的chunk,chunk作為獨(dú)立單元存儲(chǔ)。比Block小

的文件不會(huì)占用整個(gè)Block,只會(huì)占據(jù)實(shí)際大小。例如，如果一個(gè)文件大小為1M,則在HDFS中只會(huì)占用1M的空間，而不是128M。

HDFS的Block為什么這么大？

是為了最小化查找（seek）時(shí)間，控制定位文件與傳輸文件所用的時(shí)間比例。假設(shè)定位到Block所需的時(shí)間為10ms,磁盤傳輸速度為100M/s。如

果要將定位到Block所用時(shí)間占傳輸時(shí)間的比例控制1%,則Block大小需要約lOOMo

但是如果Block設(shè)置過大，在MapReduce任務(wù)中，Map或者Reduce任務(wù)的個(gè)數(shù)如果小于集群機(jī)器數(shù)量，會(huì)使得作業(yè)運(yùn)行效率很低。

Block抽象的好處

block的拆分使得單個(gè)文件大小可以大于整個(gè)磁盤的容量，構(gòu)成文件的Block可以分布在整個(gè)集群，理論上，單個(gè)文件可以占據(jù)集群中所有機(jī)器的

磁盤。

Block的抽象也簡化了存儲(chǔ)系統(tǒng)，對于Block,無需關(guān)注其權(quán)限，所有者等內(nèi)容（這些內(nèi)容都在文件級別上進(jìn)行控制）。

Block作為容錯(cuò)和高可用機(jī)制中的副本單元，即以Block為單位進(jìn)行復(fù)制。

3.2Namenode&Datanode

整個(gè)HDFS集群由Namenode和Daianode構(gòu)成masler-worker（主從）模式,：.Namenode負(fù)責(zé)構(gòu)建命名空間，管理文件的元數(shù)據(jù)等，而Daianode負(fù)

賁實(shí)際存儲(chǔ)數(shù)據(jù)，負(fù)責(zé)讀寫工作。

Namenode

Namenode存放文件系統(tǒng)樹及所有文件、目錄的元數(shù)據(jù)。元數(shù)據(jù)持久化為2種形式:

?namcspcaeimage

?editlog

但是持久化數(shù)據(jù)中不包括Block所在的節(jié)點(diǎn)列表，及文件的Block分布在集群中的哪些節(jié)點(diǎn)上，這些信息是在系統(tǒng)重啟的時(shí)候重新構(gòu)建（通過

Datanode匯報(bào)的Block,信息）。

在HDFS中，Nanwnodc可能成為集群的單點(diǎn)故障，Namenode不可用時(shí)，整個(gè)文件系統(tǒng)是不可用的。HDFS針對單點(diǎn)故障提供了2種解決機(jī)制：

1）備份持久化元數(shù)據(jù)

將文件系統(tǒng)的元數(shù)據(jù)同時(shí)寫到多個(gè)文件系統(tǒng)，例如同時(shí)將元數(shù)據(jù)寫到本地文件系統(tǒng)及NFS。這些備份來作都是同步的、原子的。

2）SecondaryNamenode

Secondary節(jié)點(diǎn)定期合并主Namenode的namespaceimage和editlog,避免editlog過大，通過創(chuàng)建檢查點(diǎn)checkpoint來合并。它會(huì)維護(hù)一個(gè)合并后

的namespaceimage副本，可用于在Namenode完全崩潰時(shí)恢更數(shù)據(jù)。下圖為SecondaryNamenode的管理界面：

.CH0martwSOOWiteJitml?U9

HadoopOwri”

Overview

i2&oi

CbwilMl201?-H-13m：10ZbyjwAiiMGktwhedfroa

2￡“：刈廠|

StatW3D1O/T/14下午T:8:JB

U?tdgijKIWv?r

aeoo

d?dkp?iatTraanctiom1000000

CheckpointImageURI

CheckpointEditlogURI

I?fil?!IKi1?：/Im*aAdf?t/naMxteacdaty

2014.

SecondaryNamenode通常運(yùn)行在另一臺(tái)機(jī)器，因?yàn)楹喜⒉僮餍枰馁M(fèi)大量的CPU和內(nèi)存。其數(shù)據(jù)落后「Namenode,因此當(dāng)Namenode完全崩潰

時(shí)，會(huì)出現(xiàn)數(shù)據(jù)丟失。通常做法是拷貝NFS中的備份元數(shù)據(jù)到Second,將其作為新的主Namenode。

在HA（HighAvAihbilify高可用忤）中可以運(yùn)行一個(gè)HeiSandhy.作為熱名?份.在ActiveNamennde抵障之后.替代原有Namenode成為Arrive

Namenodeo

Datanode

數(shù)據(jù)節(jié)點(diǎn)負(fù)責(zé)存儲(chǔ)和提取Block,讀寫請求可能來自namenode,也可能直接來自客戶端。數(shù)據(jù)節(jié)點(diǎn)周期性向Namenode匯報(bào)自己節(jié)點(diǎn)上所存儲(chǔ)的

Block相關(guān)信息。

3.3BlockCaching

DataNode通常直接從磁盤讀取數(shù)據(jù)，但是頻繁使用的Block可以在內(nèi)存中緩存。默認(rèn)情況下，一個(gè)Bkck只有一個(gè)數(shù)據(jù)節(jié)點(diǎn)會(huì)緩存。但是可以針對

每個(gè)文件可以個(gè)性化配置。

作業(yè)調(diào)度器可以利用緩存提升性能，例如MapReduce可以把任務(wù)運(yùn)行在有Block緩存的節(jié)點(diǎn)上。

用戶或者應(yīng)用可以向NameNode發(fā)送緩存指令（緩存哪個(gè)文件，緩存多久），緩存池的概念用于管理一組緩存的權(quán)限和資源。

3.4HDFSFederation

我們知道NameNode的內(nèi)存會(huì)制約文件數(shù)量，HDFSFederation提供了一種橫向擴(kuò)展NameNode的方式＜在Federation模式中，每個(gè)NameNode管

理命名空間的一部分，例如一個(gè)NameNode管理/user目錄卜.的文件，另一個(gè)NameNode管理/share目錄下的文件。

每個(gè)NameNode管理一個(gè)namespacevolumn,所有volumn構(gòu)成文件系統(tǒng)的元數(shù)據(jù)。每個(gè)NameNode同時(shí)維護(hù)一個(gè)BlockPool,保存Block的節(jié)點(diǎn)

映射等信息。各NameNode之間是獨(dú)立的，一個(gè)節(jié)點(diǎn)的失敗不會(huì)導(dǎo)致其它節(jié)點(diǎn)管理的文件不可用。

客戶端使用mounttable將文件路徑映射到NameNode。mounttable是在Namenode群組之上封裝了一層，這一層也是一個(gè)Hadoop文件系統(tǒng)的實(shí)

現(xiàn)，通過view長:協(xié)議訪問。

3.5HDFSHA（HighAvailability高可用性）

在HDFS集群中，NameNode依然是單點(diǎn)故障（SPOF:SinglePointOfFailure）0元數(shù)據(jù)同時(shí)寫到多個(gè)文件系統(tǒng)以及SecondNameNode定期

checkpoint有利于保護(hù)數(shù)據(jù)丟失，但是并不能提高可用性。

這是因?yàn)镹ameNode是唯一一個(gè)對文件元數(shù)據(jù)和file-block映射負(fù)責(zé)的地方，當(dāng)它掛了之后，包括MapReduce在內(nèi)的作業(yè)都無法進(jìn)行讀寫。

當(dāng)NameNode故障時(shí)，常規(guī)的做法是使用元數(shù)據(jù)備份重新啟動(dòng)一個(gè)NameNode。元數(shù)據(jù)備份可能來源于：

?多文件系統(tǒng)寫入中的備份

?SecondNameNode的檢查點(diǎn)文件

啟動(dòng)新的Namenode之后，需要重新配置客戶端和DaiaNode的NameNode信息。另外重啟耗時(shí)一般比較久，稍具規(guī)模的集群重啟經(jīng)常需要幾十分

鐘甚至數(shù)小時(shí)，造成重啟耗時(shí)的原因大致有：

1）元數(shù)據(jù)鏡像文件載入到內(nèi)存耗時(shí)較長。

2）需要重放ediilog

3）需要收到來白DataNode的狀態(tài)報(bào)告并且滿足條件后才能離開安全模式提供寫服務(wù)。

Hadoop的HA方案

采用HA的HDFS集群配置兩個(gè)NameNode.分別處于Active和Standby狀態(tài)。當(dāng)ActiveNameNode故障之后，Standby接過責(zé)任繼續(xù)提供服務(wù)，

用戶沒有明顯的中斷感覺。一般耗時(shí)在幾十秒到數(shù)分鐘。

HA涉及到的主要實(shí)現(xiàn)邏輯有

I）主備需共享editlog存儲(chǔ)。

主NameNode和待命的NameNode共享一份editlog,當(dāng)主備切換時(shí)，Standby通過回放editlog同步數(shù)據(jù)。

共享存儲(chǔ)通常有2種選擇

?NFS：傳統(tǒng)的網(wǎng)絡(luò)文件系統(tǒng)

?QJM：quorumjournalmanager

QJM是專門為HDFS的HA實(shí)現(xiàn)而設(shè)計(jì)的，用來提供高可用的editlog。QJM運(yùn)行一組journalnode,editlog必須寫到大部分的journalnodes。通常

使用3個(gè)節(jié)點(diǎn)，因此允許一個(gè)節(jié)點(diǎn)失敗，類似ZooKeeper。注意QJM沒有使用ZK,雖然HDFSHA的確使用了ZK來選舉主Namenode。一般推薦

使用QJM,

2）DataNode需要同時(shí)往主備發(fā)送BlockReport

因?yàn)锽lock映射數(shù)據(jù)存儲(chǔ)在內(nèi)存中（不是在磁盤上），為了在AclivcNameNode掛掉之后，新的NameNode能夠快速啟動(dòng)，不需要等待來自

Datanodc的BlockReport.DataNtxlc需要同時(shí)向主備兩個(gè)NameNode發(fā)送BlockReport。

3）客戶端需要配置failover模式（失效備援模式，對用戶透明）

Namcnodc的切換對客戶端來說是無感知的，通過客戶端庫來實(shí)現(xiàn)?？蛻舳嗽谂渲梦募惺褂玫腍DFSURI是邏輯路徑，映射到一對Namcnodc地

址?？蛻舳藭?huì)不斷嘗試每一個(gè)Namcmxlc地址直到成功。

4）Standby替代SecondaryNameNode

如果沒有啟用HA,HDFS獨(dú)立運(yùn)行一個(gè)守護(hù)進(jìn)程作為SecondaryNamcnodc。定期checkpoint,合并鏡像文件和cdilH志。

如果當(dāng)主Namcnodc失敗時(shí)，備份Namcnodc正在關(guān)機(jī)（停止Standby）,運(yùn)維人員依然可以從頭啟動(dòng)備份Namcnodc,這樣比沒有HA的時(shí)候更省

事，算是一種改進(jìn)，因?yàn)橹貑⒄麄€(gè)過程已經(jīng)標(biāo)準(zhǔn)化到Hadoop內(nèi)部，無需運(yùn)維進(jìn)行竟雜的切換操作。

NameNode的切換通過代failovercontroller來實(shí)現(xiàn)。failovercontroller有多種實(shí)現(xiàn)，默認(rèn)實(shí)現(xiàn)使用ZooKeeper來保證只有一個(gè)Namenode處廣active

狀態(tài)。

每個(gè)Namenode運(yùn)行一個(gè)輕量級的failovercontroller進(jìn)程，該進(jìn)程使用簡單的心跳機(jī)制來監(jiān)控Namenock的存活狀態(tài)并在Namenode失敗時(shí)觸發(fā)

failover,Faikner可以由運(yùn)維手動(dòng)觸發(fā)，例如在口常維護(hù)中需要切換主Namenode,這種情況graceful（優(yōu)雅的）failover,非手動(dòng)觸發(fā)的failover稱為

ungracefulfailover?

在ungracefulfailover的情況下，沒有辦法確定失?。ū慌凶銥槭。┑墓?jié)點(diǎn)是否停止運(yùn)行，也就是說觸發(fā)failover后，之前的主Namenode可能還

在運(yùn)行。QJM?次只允許?個(gè)Namenode寫editlog,但是之前的主Namenode仍然可以接受讀請求。Hadoop使用fencing來殺掉之前的

NamenodeoFencing通過收回之前Namenode對共享的editlog的訪問權(quán)限、關(guān)閉其網(wǎng)絡(luò)端口使得原有廿JNamenode不能再繼續(xù)接受服務(wù)請求。使用

STONITH技術(shù)也可以將之前的主Namenode關(guān)機(jī)。

最后，HA方案中Namenode的切換對客戶端來說是不可見的，前面已經(jīng)介紹過，主要通過客戶端庫來完成。

4.命令行接口

HDFS提供了各種交互方式，例如通過JavaAPI、HTTP,shell命令行的。命令行的交互主要通過hadoopfs來操作。例如：

1.hadoopfs-copyFromLocal//從本地U；二之件洌HDFS

2.hadoopfsmkdir//創(chuàng)建目錄

3.hadoopfs-Is"列出文件列表

Hadoop中，文件和目錄的權(quán)限類似于POSIX模型，包括讀、寫、執(zhí)行3種權(quán)限：

?讀權(quán)限（r）：用于讀取文件或者列出目錄中的內(nèi)容

?寫權(quán)限（w）：對于文件，就是文件的寫權(quán)限。目錄的寫權(quán)限指在該目象下創(chuàng)建或者刪除文件（目錄）的權(quán)限。

?執(zhí)行權(quán)限（x）：文件沒有所謂的執(zhí)行權(quán)限，被忽略。對于目錄，執(zhí)行權(quán)限用于訪問器目錄下的內(nèi)容。

每個(gè)文件或目錄都有'owner,group,mode三個(gè)屬性，owner指文件的所有者，gro叩為權(quán)限組。mode由所有者權(quán)限、文件所屬的組中組員的權(quán)

限、非所有者業(yè)組員的權(quán)限組成。下圖表示其所有者roo"用有讀寫權(quán)限，supergroup組的組員有讀權(quán)限，其它人有讀權(quán)限。

drw*r-wr-￥-ronrcup^rnrrMin0?nifi-n7-1??nrnoGcTMnnrMar】J146RC4R1IU

bzUib-u/-lz^0:biQuas'i^(xM^<iilldj4bi5Jj4902；

-rw-r--r--2rootsupergroup14102016-07-1421:09hdfs-site.xal.

[rnrrAzqrrrhzkd。fq-[q-al

-Is:Illegaloption-al

usage:hadoopfs[genericoptions]-Is[-d][-h][-R][<path>.??]

[root*?aster-]#

文件權(quán)限是否開啟通過dfs.permissions.enabled屬性來控制，這個(gè)屬性默認(rèn)為false,沒有打開安全限制，因此不會(huì)對客戶端做授權(quán)校驗(yàn)，如果開啟

安全限制，會(huì)對操作文件的用戶做權(quán)限校驗(yàn)。特殊用戶superuser是Namenode進(jìn)程的標(biāo)識(shí)，不會(huì)針對該用戶做權(quán)限校驗(yàn)。

最后看一下1s命令的執(zhí)行結(jié)果：

Lroot<^master~」*nadoopts-is

L6/07/1421:13:11WARNutil.NariveCodeLoader:unabletoloadnative-hadooplibraryforyourplatform...usingbuiltin-javaclasseswhe>

:ound14items

jrwxr-xr-x-rootsupergroup02016-07-1200:08QuasiMonteCarlo_1468253291947.1774747403

irwxr-xr-x-rootsupergroup02016-07-1200:09QuasiMonteCarlo14682533937982076042830

irwxr-xr-x-rootsupergroup02016-07-1200:16QuasiMonte<arlo_1468253772079_173690396

irwxr-xr-x-rootsupergroup02016-07-1200:26QuasiMonteCarlo_1468254388939.1988916204

irwxr-xr-x-rootsupergroup02016-07-1200:27QuasiMonteCarlo_1468254452399_605843891

irwxr-xr-x-rootsupergroup02016-07-1200:36QuasiMonte<ar1o_1468254979790_l573576092

jrwxr-xr-x-rootsupergroup02016-07-1200:45QuasiMonteCarlo_1468255539466_528333101

irwxr-xr-x?rootsupergroup02016-07-1200:51QuasiMonteCarlo_1468255886364_1062496601

jrwxr-xr-x-rootsupergroup02016-07-1200:53QuasiMonteCarlo_14682S6000554_529214867

irwxr-xr-x-rootsupergroup02016-07-1200:57Quas1MonteCar10.1468256255348.2107379102

drwxr-xr-x-rootsupergroup02016-07-1201:03QuasiMonteCarlo_1468256625983_€24708085

irwxr-xr-x-rootsupergroup02016-07-1220:00QuasiMonteCarlo_1468324818620_1876846710

jrwxr-xr-x-rootsupergroup02016-07-1220:01QuasiMonteCarlo_1468324902776_31120853

-rw-r—r—2rootsupergroup14102016-07-K21:09hdfs-s1te.xml

[root?master|

這個(gè)返回結(jié)果類似于Unix系統(tǒng)下的Is命令，第一欄為文件的mode,d表示目錄，緊接著3種權(quán)限9位。第二欄是指文件的副本數(shù)，這個(gè)數(shù)量通

過dfs.replication配置，目錄則使用-表示沒有副本一說。其它諸如所有者、組、更新時(shí)間、文件大小跟Unix系統(tǒng)中的1s命令一致。

如果需要杳看集群狀態(tài)或者瀏覽文件目錄,可以訪問Namenode暴露的HttpServer杳看集群信息.一般在namenode所在機(jī)器的50070端口.

□master:50070/dfshealth.html#tab-overview

HadoopC?vexvit?StupshotStftxtvq>UtilitiM

Overviewmaster:9000'(active)

Started：FriJul1522:28:29CST2016

Vezsion:2.6.0.re3496<99?cb8d23Mb^9dc5e(i4c99c8f9e33bbl

Coapiled：2014-11-19T21:1QZbyjtnkintfxoa《&tacb?dfro*?349649)

Clur??rH>!Cgl播c<M--44c02?bU)23g49?45

BlockPoolU)：BP-：51334281T-5O-14CB2514279W

Summary

Securityisoff.

SafeisON.Thereportedblocks143b&sreachedthethxeriiold0.9990oftot>lblocks143.Thenumberoflivedatanodes2re^cbedtbenunb?r0.In

safe>o4eextenflicn.S?fe?&devillb?turnedoffauto&aticftllyin3iec?n<k.

306fil*sanddix?ctoxiesv143block，■349totalfilesy2teBobject(f).

HelpIt?oryused78.65IBof154.56匹H—l??ary.laxHeapB?aoxyis888.94IB.

NonHeapleworyg?d29.08IBof30.31IBCoaidtedBonHeapKeaory.IAXNonHeapl?BOxyit18國.

CcnficuxedCcecity：809.46<?

DFSUsed:13.92?

■anDFSUJNNI:59.433

DFSR?Bainint：750.01GB

DFSQsedS:M

VPSKeaainingt:92.

BlockPoolUsed：13.92IB

DatanodeInformation

Inoperation

的的LastcontactStatety9seJNonDPSUsedKewainincBIT，Bl*ckpoolmedFailed”“isVersion

sl?v?l(102.1681.132:50010)2InStrrice404.7386.96J031.04GB373.68CB1蒙6.96XB(0?)02.6.0

(192168113460010)2laStrvic*4047386%Jtt2839GB376.33814：6%MB((M)026.0

Decomissioning

U*4errUeck*BlodcvvitKnolivert^licavInfile%wU?rcaastmctiea

Hadoop>2014.

Hadoop州erviewDatanodesSnapshotStartupProgressUtilities

BrowseDirectory

/user/rootGol

Pex*issionOmexGroupSizeReplicationBlockSizeHane

drwxx-xx-xrootsupergxoup0B00BQuasi?onteCarl5_14efi253291947_1774747403

drwxx-xr-xrootsuperproup0B00BQuasiMonteCarl^l468253393798_2076042830

drwxr-xx-xrootsuperproup0B00BQuasiMonteCarb_1468253772079_173690396

drwxx-xx-xrootsupergroup0B00BQuMiKonteCarl3_1468254388939_1988916204

drwxx-xr-xrootsupergroup0B00BQuwiMonteCaxb_146e254452399_605843891

drwxr-xx-xrootsupergroup0B00BQuasiIontcCarbJ468254979790_1573576092

drwxx-xx-xrootsupergroup0B008QuasiNonteCarh_528333101

drwxr-xr-xrootsupergroup0B00BQuasilIonteCarb_H68255886364_1062496?)l

drwxr-xr-xrootsupergroup0B00BQuasiIonteCarb_146e250000554_529214867

drrxr-xr-xrootsupergroup0B00BQuasiMonteCaxb_146e256255348_2107379102

drwxr-xx-xrootsupergroup0B00BQuasiMonteCarb_14e6256625983_62470eC65

drwxr-xi-xrootsup"，工oup0B00BQuasiMonteCaxb_1466324818620_1876846710

drwxx-xr-xrootsupergroup0B00BQuasiMonteCarl3_1468324902776.31120e53

drwxr-xar-xrootsuperproup