一、Hadoop的整體架構
Hadoop是一個專為大數據設計的架構解決方案，歷經多年開發演進，已逐漸發展成為一個龐大且復雜的系統。其內部工作機制融合了分布式理論與具體工程開發的精髓，構成了一個整體架構。
Hadoop最樸素的原理在于，它利用大量的普通計算機來處理大規模數據的存儲和分析任務，而非依賴于單一的超級計算機。這一設計理念不僅降低了硬件成本，還通過分布式處理提高了系統的可擴展性和容錯性。
Hadoop作為大數據處理領域的基石性架構，其設計理念體現了"分而治之"的分布式計算哲學。經過十余年的技術演進，Hadoop已從最初的單一計算框架發展為包含存儲、資源管理、計算引擎等完整組件的生態系統，其架構復雜度反映了分布式系統理論與工程實踐的深度融合。
Hadoop 系統的一個架構圖，現在已經有了非常多的組件，但最核心的兩部分依然是底層的文件系統 HDFS和用于計算的 MapReduce。來看下 Hadoop 系統中的一些重要組成部分。
二、HDFS（分布式文件系統）
HDFS 主要有 NameNode、DataNode、Secondary NameNode 三大組件：
-
?NameNode?
- 管理文件系統的命名空間
- 協調客戶端對文件的訪問
- 存儲文件系統的元數據
-
?Secondary NameNode?
- 定期合并NameNode的編輯日志和鏡像文件，減少NameNode啟動時間
- 提供NameNode的備份，但不用于故障切換
-
?DataNode?
- 存儲實際的數據塊
- 執行數據的讀寫操作
- 定期向NameNode報告其存儲的數據塊信息
Primary Namenode 與 Secondary Namenode
三、MapReduce（分布式計算框架）
MapReduce 核心思想：分而治之的并行計算
3.1 拆分（Split）→ 并行計算（Map）?
- 輸入數據被自動切割為 ?分片（Split）?（默認與 HDFS Block 對齊） → 分發到集群節點?。
- ?Map 階段?：每個節點對本地數據執行相同的用戶自定義函數，輸出中間鍵值對 (key, value)。
👉 實質：將大規模問題分解為獨立子問題
3.2 聚合（Shuffle）→ 歸約（Reduce）
- ?Shuffle 階段?：框架按 key 將中間結果跨節點分組、排序、傳輸（核心瓶頸）?。
- ?Reduce 階段?：相同 key 的數據發送到同一節點，執行歸約邏輯（如求和、去重）。
👉 實質：合并子問題的結果生成全局解
MapReduce Split
MapReduce Shuffle
四、Yarn(資源調度與管理框架)
老周在之前講解Flink架構的時候講過YARN集群架構，我這里直接拿我之前Yarn的架構圖。YARN集群總體上是經典的主／從(Master/Slave)架構，主要由ResourceManager、NodeManager、ApplicationMaster和Container等幾個組件構成。
4.1 ResourceManager
以后臺進程的形式運行，負責對集群資源進行統一管理和任務調度。ResourceManager的主要職責如下：
- 接收來自客戶端的請求。
- 啟動和管理各個應用程序的ApplicationMaster。
- 接收來自ApplicationMaster的資源申請，并為其分配Container。
- 管理NodeManager，接收來自NodeManager的資源和節點健康情況匯報。
4.2 NodeManager
集群中每個節點上的資源和任務管理器，以后臺進程的形式運行。它會定時向ResourceManager匯報本節點上的資源（內存、CPU）使用情況和各個Container的運行狀態，同時會接收并處理來自ApplicationMaster的Container啟動／停止等請求。NodeManager不會監視任務，它僅監視Container中的資源使用情況，例如。如果一個Container消耗的內存比最初分配的更多，就會結束該Container。
4.3 Task
應用程序具體執行的任務。一個應用程序可能有多個任務，例如一個MapReduce程序可以有多個Map任務和多個Reduce任務。
4.4 Container
YARN中資源分配的基本單位，封裝了CPU和內存資源的一個容器，相當于一個Task運行環境的抽象。從實現上看，Container是一個Java抽象類，定義了資源信息。應用程序的Task將會被發布到Container中運行，從而限定了Task使用的資源量。
一個應用程序所需的Container分為兩類：運行ApplicationMaster的Container和運行各類Task的Container。前者是由ResourceManager向內部的資源調度器申請和啟動的，后者是由ApplicationMaster向ResourceManager申請的，并由ApplicationMaster請求NodeManager進行啟動。
我們可以將Container類比成數據庫連接池中的連接，需要的時候進行申請，使用完畢后進行釋放，而不需要每次獨自創建。
4.5 ApplicationMaster
ApplicationMaster可在Container內運行任何類型的Task。例如，MapReduce ApplicationMaster請求一個容器來啟動Map Task或Reduce Task。也可以實現一個自定義的ApplicationMaster來運行特定的Task，以便任何分布式框架都可以受YARN支持，只要實現了相應的ApplicationMaster即可。
我們可以這樣認為：ResourceManager管理整個集群，NodeManager管理集群中的單個節點，ApplicationMaster管理單個應用程序（集群中可能同時有多個應用程序在運行，每個應用程序都有各自的ApplicationMaster）。
YARN集群中應用程序的執行流程如下圖所示：
- 客戶端提交應用程序（可以是MapReduce程序、Spark程序等）到ResourceManager。
- ResourceManager分配用于運行ApplicationMaster的Container，然后與NodeManager通信，要求它在該Container中啟動ApplicationMaster。ApplicationMaster啟動后，它將負責此應用程序的整個生命周期。
- ApplicationMaster向ResourceManager注冊（注冊后可以通過ResourceManager查看應用程序的運行狀態）并請求運行應用程序各個Task所需的Container（資源請求是對一些Container的請求）。如果符合條件，ResourceManager會分配給ApplicationMaster所需的Container（表達為Container ID和主機名）。
- ApplicationMaster請求NodeManager使用這些Container來運行應用程序的相應Task（即將Task發布到指定的Container中運行）。
此外，各個運行中的Task會通過RPC協議向ApplicationMaster匯報自己的狀態和進度，這樣一旦某個Task運行失敗，ApplicationMaster就可以對其重新啟動。當應用程序運行完成時，ApplicationMaster會向ResourceManager申請注銷自己。
五、Hadoop HA
問題1：兩個NameNode主節點，誰是Active，誰是Standby?
利用Zookeeper進行選舉
問題2：怎么實現的？
- 每一個NameNode都有一個ZKFC：Zookeeper Failover Contorller
- 功能
- 負責幫助NameNode向Zookeeper進行注冊選舉，并且監聽active的NameNode
- 負責監控NameNode的狀態
問題3：如果有兩個NameNode，客戶端如何知道誰是active？
- 客戶端只能請求active狀態的NameNode
- 一旦配置了HA，將兩個NameNode構建成一個整體
- 客戶端不用再請求單個NameNode，請求這個整體，這個整體負責從zookeeper中找到誰是active轉發這個請求
問題4：如果有兩個NameNode，所有的DataNode向哪個NameNode進行注冊呢？
兩個NameNode 都注冊，只有active的能管理。
問題5：一個是active，一個standby，如果active宕機，standby接替active，如何保證standby的元數據與active是一致的？
- journalnode日志節點
- active狀態的 NN，會將自己元數據的變化日志edits文件寫入journalnode集群
- standby狀態的NN，會從journalnode集群中將變化讀取出來，對自己操作，保證自己的元數據與active的元數據是一致的
六、HDFS Architecture
6.1 NameNode and DataNodes
6.2 Data Replication
)
)
