㈠ 大數據之HDFS
在現代的企業環境中，單機容量往往無法存儲大量數據，需要跨機器存儲。統一管理分布在集群上的文件系統稱為 分布式文件系統 。
HDFS （Hadoop Distributed File System）是 Hadoop 的核心組件之一， 非常適於存儲大型數據 (比如 TB 和 PB)， HDFS 使用多台計算機存儲文件，並且提供統一的訪問介面，像是訪問一個普通文件系統一樣使用分布式文件系統。
HDFS是分布式計算中數據存儲管理的基礎，是基於流數據模式訪問和處理超大文件的需求而開發的，可以運行於廉價的商用伺服器上。它所具有的 高容錯、高可靠性、高可擴展性、高獲得性、高吞吐率 等特徵為海量數據提供了不怕故障的存儲，為超大數據集的應用處理帶來了很多便利。
HDFS 具有以下 優點 ：
當然 HDFS 也有它的 劣勢 ，並不適合以下場合：
HDFS 採用Master/Slave的架構來存儲數據，這種架構主要由四個部分組成，分別為HDFS Client、NameNode、DataNode和Secondary NameNode。
Namenode是整個文件系統的管理節點，負責接收用戶的操作請求。它維護著整個文件系統的目錄樹，文件的元數據信息以及文件到塊的對應關系和塊到節點的對應關系。
Namenode保存了兩個核心的數據結構：
在NameNode啟動的時候，先將fsimage中的文件系統元數據信息載入到內存，然後根據edits中的記錄將內存中的元數據同步到最新狀態；所以，這兩個文件一旦損壞或丟失，將導致整個HDFS文件系統不可用。
為了避免edits文件過大， SecondaryNameNode會按照時間閾值或者大小閾值，周期性的將fsimage和edits合並 ，然後將最新的fsimage推送給NameNode。
並非 NameNode 的熱備。當NameNode 掛掉的時候，它並不能馬上替換 NameNode 並提供服務。其主要任務是輔助 NameNode，定期合並 fsimage和fsedits。
Datanode是實際存儲數據塊的地方，負責執行數據塊的讀/寫操作。
一個數據塊在DataNode以文件存儲在磁碟上，包括兩個文件，一個是數據本身，一個是元數據，包括數據塊的長度，塊數據的校驗和，以及時間戳。
文件劃分成塊，默認大小128M，以快為單位，每個塊有多個副本（默認3個）存儲不同的機器上。
Hadoop2.X默認128M， 小於一個塊的文件，並不會占據整個塊的空間 。Block數據塊大小設置較大的原因：
文件上傳 HDFS 的時候，Client 將文件切分成 一個一個的Block，然後進行存儲。
Client 還提供一些命令來管理 HDFS，比如啟動或者關閉HDFS。
Namenode始終在內存中保存metedata，用於處理「讀請求」，到有「寫請求」到來時，namenode會首 先寫editlog到磁碟，即向edits文件中寫日誌，成功返回後，才會修改內存 ，並且向客戶端返回，Hadoop會維護一個fsimage文件，也就是namenode中metedata的鏡像，但是fsimage不會隨時與namenode內存中的metedata保持一致，而是每隔一段時間通過合並edits文件來更新內容。
HDFS HA（High Availability）是為了解決單點故障問題。
HA集群設置兩個名稱節點，「活躍（ Active ）」和「待命（ Standby ）」，兩種名稱節點的狀態同步，可以藉助於一個共享存儲系統來實現，一旦活躍名稱節點出現故障，就可以立即切換到待命名稱節點。
為了保證讀寫數據一致性，HDFS集群設計為只能有一個狀態為Active的NameNode，但這種設計存在單點故障問題，官方提供了兩種解決方案：
通過增加一個Secondary NameNode節點，處於Standby的狀態，與Active的NameNode同時運行。當Active的節點出現故障時，切換到Secondary節點。
為了保證Secondary節點能夠隨時頂替上去，Standby節點需要定時同步Active節點的事務日誌來更新本地的文件系統目錄樹信息，同時DataNode需要配置所有NameNode的位置，並向所有狀態的NameNode發送塊列表信息和心跳。
同步事務日誌來更新目錄樹由JournalNode的守護進程來完成，簡稱為QJM，一個NameNode對應一個QJM進程，當Active節點執行任何命名空間文件目錄樹修改時，它會將修改記錄持久化到大多數QJM中，Standby節點從QJM中監聽並讀取編輯事務日誌內容，並將編輯日誌應用到自己的命名空間。發生故障轉移時，Standby節點將確保在將自身提升為Active狀態之前，從QJM讀取所有編輯內容。
注意，QJM只是實現了數據的備份，當Active節點發送故障時，需要手工提升Standby節點為Active節點。如果要實現NameNode故障自動轉移，則需要配套ZKFC組件來實現，ZKFC也是獨立運行的一個守護進程，基於zookeeper來實現選舉和自動故障轉移。
雖然HDFS HA解決了「單點故障」問題，但是在系統擴展性、整體性能和隔離性方面仍然存在問題：
HDFS HA本質上還是單名稱節點。HDFS聯邦可以解決以上三個方面問題。
在HDFS聯邦中，設計了多個相互獨立的NN，使得HDFS的命名服務能夠水平擴展，這些NN分別進行各自命名空間和塊的管理，不需要彼此協調。每個DN要向集群中所有的NN注冊，並周期性的發送心跳信息和塊信息，報告自己的狀態。
HDFS聯邦擁有多個獨立的命名空間，其中，每一個命名空間管理屬於自己的一組塊，這些屬於同一個命名空間的塊組成一個「塊池」。每個DN會為多個塊池提供塊的存儲，塊池中的各個塊實際上是存儲在不同DN中的。
㈡ hadoop集群中的幾個重要概念
（1）journalnode：使兩個namenode之間的數據實現共享（hadoop層面的）。系統層面的是NFS。
（2）zookeeper：實現namenode的切換，確保集群只有一個active
（3)格式化zkfc,讓在zookeeper中生成ha節點
(4)格式化nn:就是格式化hdfs.
與普通文件系統一樣，HDFS文件系統必須要先格式化，創建元數據數據結構以後才能使用。
(5)conf下的一些配置文件的作用
hadoop-env.sh:用於定義hadoop運行環境相關的配置信息，比如配置JAVA_HOME環境變數、為hadoop的JVM指定特定的選項、指定日誌文件所在的目錄路徑以及master和slave文件的位置等；
core-site.xml: 用於定義系統級別的參數，它作用於全部進程及客戶端，如HDFS URL、Hadoop的臨時目錄以及用於rack-aware集群中的配置文件的配置等，此中的參數定義會覆蓋core-default.xml文件中的默認配置；
hdfs-site.xml: HDFS的相關設定，如文件副本的個數、塊大小及是否使用強制許可權等，此中的參數定義會覆蓋hdfs-default.xml文件中的默認配置；
mapred-site.xml：maprece的相關設定，如rece任務的默認個數、任務所能夠使用內存的默認上下限等，此中的參數定義會覆蓋mapred-default.xml文件中的默認配置；
masters: hadoop的secondary-masters主機列表，當啟動Hadoop時，其會在當前主機上啟動NameNode和JobTracker，然後通過SSH連接此文件中的主機以作為備用NameNode;
slaves：Hadoop集群的slave(datanode)和tasktracker的主機列表，master啟動時會通過SSH連接至此列表中的所有主機並為其啟動DataNode和taskTracker進程；
Hadoop-metrics2.properties:控制metrics在hadoop上如何發布屬性
Log4j.properties：系統日誌文件、namenode審計日誌、tarsktracker子進程的任務日誌屬性
（6）hadoop.tmp.dir屬性用於定義Hadoop的臨時目錄，其默認為/tmp/hadoop-${username}。HDFS進程的許多目錄默認都在此目錄中，/hadoop/tmp目錄，需要注意的是，要保證運行Hadoop進程的用戶對其具有全部訪問許可權。
fs.default.name屬性用於定義HDFS的名稱節點和其默認的文件系統，其值是一個URI，即NameNode的RPC伺服器監聽的地址(可以是主機名)和埠(默認為8020)。其默認值為file:///，即本地文件系統。
dfs.name.dir屬性定義的HDFS元數據持久存儲路徑,默認為${hadoop.tmp.dir}/dfs/name
dfs.replication屬性定義保存副本的數量，默認是保存3份,由於這里只有兩台slave。所以設置2。
（7）可以通過修改下面幾個參數對集群讀寫性能進行優化
dfs.datanode.handler.count（加大）DN的服務線程數。這些線程僅用於接收請求，處理業務命令
dfs.namenode.handler.count（加大） NN的服務線程數。用於處理RPC請求
dfs.namenode.avoid.read.stale.datanode（true）決定是否避開從臟DN上讀數據。臟DN指在一個指定的時間間隔內沒有收到心跳信息。臟DN將被移到可以讀取(寫入)節點列表的尾端。嘗試開啟
dfs.namenode.avoid.write.stale.datanode（true） 和上面相似，是為了避免向臟DN寫數據