專欄目錄
(1)大資料和應用場景介紹
(2)大資料技術綜述總結
(3)HDFS原理與高可用技術原理介紹
(4)Yarn架構、資源管理原理和運維技術介紹
(5)Kafka原理和高可用介紹
1.HDFS簡介
HDFS也是由Doug Cutting基于Google公司03年10月開源的論文GFS做的開源實作。目前為止，HDFS的運用非常廣泛，基本上很多大資料平台大部分都會選用HDFS（或者類似HDFS）這樣的分布式檔案系統、來作為海量資料存儲的一個解決方案。最初在設計HDFS時的背景是 當時裝置的存儲和讀寫性能都很差，并且單一裝置運作穩定性低的情況 （現在硬體裝置優化很好了，目前HDFS已經不是最優方案了），于是 HDFS在設計之初就是為了解決大規模、海量資料的存儲以及讀寫，并且盡可能的保證裝置的穩定性。
【HDFS的優勢】 1. 高容錯性，HDFS提供了“副本備援機制”，簡單來說就是 一份資料在HDFS當中存放，包含它自身在内至少會有（預設）三個副本類似随機的存放在叢集不同的伺服器上，并且當其中一台伺服器當機、目前這台伺服器上資料丢失，但 HDFS會自動再将缺失的副本再通過copy的方式、保證資料的副本不會低于預設三個（副本預設是3個）。 2. 可建構在廉價的商業伺服器上，基于第一條高容錯性的優勢，HDFS可以搭建在低成本的廉價伺服器上，而沒有必要選擇非常昂貴的伺服器上，因為即使廉價伺服器穩定性相對較差， 但是叢集規模成百上千台當機一台、兩台對于整個HDFS叢集來說，基本上沒有任何的影響。 3. 适合海量資料存儲，分布式架構設計、HDFS可支援幾萬台伺服器的叢集規模，乘以每台伺服器磁盤容量、整個HDFS檔案系統容量非常之大，并且他所支援存放的單個資料檔案GB、TB、PB級别都沒有任何問題。 4. 适合批處理，通過 “移動計算而非移動資料”設計，簡單來說就是資料在哪個節點，你就呆在哪計算就行了。 避免了資料跨網絡、結點移動拷貝的工作，很大限度的提升計算速度。 5. 流式資料通路，一次寫入、多次讀取。檔案一旦寫入完成、不能修改， 僅僅隻支援追加。保證了資料的一緻性。 【HDFS的适用場景】
1.叢集規模大：适合大檔案存儲、海量資料存儲。
2.集穩容量大：适合批量資料通路 HDFS适用于“大檔案存儲、海量資料存儲”、“批量資料通路”這些場景
【HDFS的缺點】 但是HDFS本身設計上也存在問題： 1. 低延時資料通路 ：這裡的 “低延時”指的是例如毫秒級别要将資料寫入HDFS、或毫秒級别讀取HDFS内資料 ，無法支援。也就是說它某一時間大量讀寫不要緊，叢集容量夠穩定，但你要它毫秒級别完成那肯定不現實，至少任務排程、任務結果收集都要耗一點時間。 2. 并發寫入、随機修改 ：①HDFS當中 檔案隻能有一個寫、不支援多個線程同時寫入一個檔案 。②并且 隻支援追加寫，不支援随機寫。 3. 小檔案存儲 ：小檔案問題是大家在大資料領域需要格外注意的問題。首先撇開HDFS來說，假如10GB資料容量，10個1GB的資料集、1w個1M的資料集，占用存儲空間相同，讓你在這兩種資料集中找到其中一個資料檔案，明顯第二種場景非常耗時，也 就是說小檔案存儲之後，在尋址的時間開銷會非常之高、以至于會高于讀取時間 。此外，回到HDFS當中來考慮， HDFS當中每一個資料檔案都會對應有一份中繼資料資訊需要存放 ，大家可以把中繼資料資訊先簡單了解為就是檔案的一些基本資訊（如檔案名稱、大小、權限等），一個檔案對應一條中繼資料資訊，當你存儲的都是一些小檔案、檔案個數會急速增長，對應中繼資料也就需要更多的空間來存儲，并且中繼資料是在記憶體媒體中存儲，這樣一來會非常浪費記憶體資源、顯然是不适用的。是以，在使用HDFS過程當中一定要注意“小檔案”的這個問題。
2.HDFS架構Master/Slave
(1)基本結構關系
- NameNode是主節點，DataNode是從節點，HDFS Client是用戶端、HDFS提供了比較豐富的用戶端像cli、api、gui等等支援SecondaryNameNode相當于輔助NameNode工作的一個節點、但并不是NameNode的備份結點！。
- NameNode主節點：主要負責接受用戶端送出過來的讀寫請求、以及一些類似管理的工作。比如說，資料存到HDFS當中每個檔案都會對應一份中繼資料資訊(見後介紹)，這些中繼資料資訊都是存放在NameNode的記憶體區域内、由NameNode來進行維護。
- DataNode從節點：主要負責資料的存放。資料檔案寫入到HDFS當中會切分為小的資料塊block（圖中DataNode中紫色、橙色、紅色等小的方塊），這些資料塊會存放在DataNode節點上。在一個HDFS叢集當中DataNode結點可以有任意多台，當然要根據你檔案系統的資料量來确定，并且後期如果容量不足的情況下，也支援DataNode結點動态添加、擴容。
- 通信：DataNode運作中一直和NameNode保持通信。一方面，在DataNode啟動時，會給NameNode上報有哪些資料塊（block的位置存放資訊），NameNode接收到這些block位置資訊會維護好一份完整的中繼資料資訊，進而找到具體資料存放在哪些DataNode上；另一方面，運作過程中，DataNode會每隔3秒定時和NameNode做一次心跳，進而NameNode知道DataNode的運作狀況。
(2)Block規則
一個10G的檔案上傳到HDFS中：
- 首先，在用戶端處切分成一個個Block塊，預設情況下Block塊的大小是128M。
- 這些切分後的Block塊，會以多副本的形式均勻放置到DataNode中。
- 資料存放在DataNode後，主節點NameNode需要知道檔案切分了多少Block塊和每個Block塊具體存放的位置。這些記錄資訊就是中繼資料。
(3)NameNode和DataNode功能介紹
(4)活躍主節點和備份節點介紹(Hadoop3.X)
- ActiveNameNode是主節點。具體功能是管理整個叢集，是目前活動的管理節點。作為管理節點，管理命名空間和中繼資料資訊，管理Block副本政策。并處理用戶端讀寫請求，為DataNode配置設定任務。
- Standby Namenode是Master的熱備節點，并負責定期合并中繼資料檔案。
(5)Block和client用戶端關系
3.HDFS存儲機制
(1)Block、中繼資料、副本關系
①Block是HDFS的最小存儲單元，預設大小為128M（128M，據說是希望IO時間/(IO+網絡傳輸)=1%效果最好），可以自定義修改，但是要注意修改的一些影響，塊太大和太小都可能會影響性能。
②Block存儲到DataNode上，會以多副本的形式進行存儲，預設副本數為3，通過機架感覺和副本均勻分布的政策保證資料的高可用性。資料存儲之後，對應的中繼資料會儲存在NameNode中。
(2)Block檔案解析
(3)副本存放政策詳解
①副本之間沒有“主備”關系
②block前3個副本放置遵循規律，後N個随機
(4)元資訊存儲和持久化政策
①元資訊由于存放在NameNode記憶體中，如果小檔案過多容易造成記憶體容量不足，進而當機
②元資訊持久化包含兩種檔案：fsimage和edits。 fsimage檔案可以了解為是一個記憶體的快照，他會将記憶體當中除去block位置存放資訊之外的所有中繼資料資訊持久化寫到一個磁盤當中的檔案内； edits檔案，這種檔案可了解為Mysql的binlog日志記錄檔案。
【元資訊持久化不丢失資料】
由于每次更新fsimage檔案性能不高(一個樹結構要周遊和結構變化)，是以fsimage并不會實時去發生變化，那麼後邊這些操作則通過edits檔案做一個記錄。是以及時NameNode當機了，也能通過edits恢複fsimage最新結構。
(5)元資訊存儲檔案詳解
與DataNode Block檔案不同，在NameNode中結構為：
- fsimage_字首檔案：即fsimage檔案，之是以有多個是因為他定時要做合并，是以會保留有多份fsimage檔案
- edits_字首檔案：即edits檔案。
- VERSION：VERSION檔案是java屬性檔案，儲存了HDFS的基本資訊
- seen_txid：是存放transactionId的檔案，format之後是0，它代表的是namenode裡面的edits_*檔案的尾數，namenode重新開機的時候，會按照seen_txid的數字，循序從頭跑edits_0000001~到seen_txid的數字。
(6)edits與fsimage合并
①Hadoop1.x：
用戶端各項操作記錄會寫入到edits檔案内。
Secondary合并觸發：Secondary會主動從NameNode中通過HttpGet方式将edits和fsimage檔案拷貝并存放在本地磁盤中，開始合并。合并過程其實就是将該fsimage加載到記憶體當中，然後逐條執行edits日志中的各項操作、來更新記憶體裡的中繼資料資訊。合并完後，fsimage被持久化(快照生成)産生新的fsimage，此時記憶體中的中繼資料資訊便是觸發合并那個時間點一份完整的中繼資料資訊。
Secondary轉移：新的fsimge通過Http Post方式将這個新的fsimage檔案發送給NameNode，舊版fsimage被替換。之前合并期間，NameNode同時還生成一個空的edits檔案，Secondary在合并的過程中，所有用戶端的操作都會記錄在這個新的空edits檔案中，直到Secondary把新的fsimage檔案推給NameNode，NameNode會同時将新的fsimage、以及新的edits檔案啟用整個合并過程完成結束。
是以，在運作過程中HDFS會定期觸發整個合并流程，進而會保證fsimage檔案越來越大、但edits檔案大小穩定。
②Hadoop2.x：
引入了活躍ActiveNN(NameNode)和等待standby兩種節點。用戶端操作時，edit除了在ActiveNN寫，還會在JournalNode叢集上寫(專門管理日志叢集，見高可用)，同時StandBy定期同步。Standby與secondary最重要的不同是：Standby在Active當機時，能夠充當Active角色，而Secondary隻能充當加快fsimage和edits合并的備份節點(不保證日志能寫到Secondary)
4.讀寫過程
HDFS讀寫過程
5.HDFS安全模式
(1)安全模式本質和安全模式退出介紹
(2)安全模式觸發原因和兩種故障排查方式
6.HDFS高可用探讨
(1)HDFS本身架構讨論
①HDFS結構劣勢主要在于NameNode記憶體受限：可以用聯邦機制解決（多個節點分享元檔案，或者每個NameNode管理自己領域的DataNode，并且多個NameNode還由上一層節點進行控制做負載均衡）
②NameNode單點容易故障：可用HA解決 (見下主備節點ActiveNN和StandbyNN)
(2)高可用有哪些可以思考地方
(3)高可用技術參考
① 高可用的本質是在主節點當機之後，從熱備節點可以立馬代替當機的主節點接管叢集，保證服務是不中斷的。那對于NameNode來說，如果要立馬接管叢集并且保證服務不中斷，那就需要中繼資料保持一緻。
②下圖中QJM方案介紹：
- Journal叢集可以實作edits共享，實作Master主備節點的中繼資料同步。
- Journal叢集需要部署奇數台，每次edits檔案的寫入都需要半數以上的節點傳回成功才代表成功。保證edits中繼資料檔案的高可用。
(4)高可用整套技術架構
- JournalNode叢集：負責管理NameNode日志edits檔案的管理，也就是ActiveNameNode寫日志是直接寫入到JournalNode叢集上。
- ZKFC – ZookeeperFailoverController：每台NameNode伺服器上都會運作一個ZKFC程序，主要負責兩個任務： 監控目前NameNode運作狀況資訊、與Zookeeper叢集保持心跳并将這些資訊彙報給Zookeeper叢集；控制NameNode Active、Standby狀态的切換管理 (參考一緻性算法Paxos算法 )。
- Zookeeper叢集：實際中也是部署 2N+1台，核心也是通過Paxos算法，在HDFS叢集中主要負責接收到ZKFC彙報的NameNode健康資訊做“選舉”，“選舉”哪一台NameNode應該是Active狀态。
- DataNode叢集：負責資料的存儲，但是差別于1.x的設計、 在2.x叢集中DataNode上報block資訊會同時上報給兩台NameNode。
運作過程：
①HDFS運作過程中，如果Active的NameNode運作出現故障，此時目前NameNode上的ZKFC會将異常的健康資訊彙報給Zookeeper叢集，或者NameNode這台伺服器當機，Zookeeper叢集長時間接收不到ZKFC的資料，都會得知第一台NameNode運作出現了問題。
②主備替換：此時Zookeeper叢集會做選舉、推選第二台NameNode作為Active的NameNode來接管叢集，之後Zookeeper先通知給第二台NameNode上的ZKFC，由ZKFC将目前這台NameNode狀态從Standby切換為Active。
③元資訊恢複：fsimage檔案在第二台NameNode上有一份，運作過程中edits檔案一直寫在JournalNode叢集上、第二台NameNode可以直接拿到這些edits檔案，狀态切換之後，便可以先将fsimage加載記憶體，然後一條一條執行edits日志内容，并且叢集在運作過程中DataNode會将各自伺服器上block資訊彙報給第一台和第二台，第二台上緩存有這些block資訊再将它和記憶體當中部分原資料資訊進行拼接。當這些操作全部執行完成之後，此時第二台NameNode記憶體當中中繼資料資訊和第一台NameNode出現故障時記憶體當中中繼資料資訊完全一緻，這樣整個HA便達到了。