Flink on Yarn 詳情 - hdfs,flink,kubernetes,雲計算,hdfs,JavaScript,前端開發 mob64ca140088a9 博客

一、HDFS：分佈式存儲的“數據倉庫”

1. HDFS核心架構：三大角色分工

二、Flink：大數據處理的“計算引擎”

1. Flink核心特性

2. Flink核心架構：三層協作模型

三、Flink+K8s+HDFS：雲原生大數據的“黃金組合”

1. 彈性資源調度：降本增效的核心

2. 可靠數據存儲：保障計算不丟數據

3. 高可用與易運維：降低集羣管理成本

四、問題實戰：NN報錯與PVC狀態關聯排查

1. 背景知識

hdfs的NN的初始化是否依賴JN

HA模式下初始化的關鍵步驟

2. 問題現象

NN Pod完整報錯日誌

PVC與組件狀態詳情

3. 檢查PVC處於pending原因

五、思考-AI診斷

1.架構方案

2.工作流程

3.詳細設計

六、總結

在Flink+K8s+HDFS的雲原生大數據架構中，HDFS的NameNode（NN）是核心組件，其Pod報錯“存儲目錄異常”且關聯PVC處於Pending狀態是常見問題。要高效排查這類問題，需先理清HDFS、Flink的核心概念與架構，以及三者協同的優勢，再針對性定位存儲資源問題。

一、HDFS：分佈式存儲的“數據倉庫”

HDFS（Hadoop Distributed File System）是專為大數據場景設計的分佈式文件系統，核心作用是安全存儲海量數據並支持高併發訪問，相當於大數據架構中的“共享倉庫”。

1. HDFS核心架構：三大角色分工

HDFS採用“主從架構”，通過三個核心角色協同實現數據存儲與管理，用“圖書館”比喻更易理解：

NameNode（NN）：倉庫管理員 - 負責管理“文件元數據”（如文件名、存儲路徑、大小、修改時間），相當於圖書館的“索引目錄”，不存儲實際數據。 - 是HDFS的“大腦”，一旦故障整個存儲系統不可用，生產環境需部署主備NN（HA架構）確保高可用。 - 核心依賴：需持久化存儲元數據到本地目錄（如`/hdfs-data/pv-nn/name`），該目錄通常掛載K8s的PVC實現數據持久化——這也是NN Pod報錯與PVC強相關的原因。
DataNode（DN）：倉庫貨架 - 負責存儲實際數據塊（默認128MB/塊，可配置），相當於圖書館的“書架”，數據塊會默認存3份副本避免丟失。 - 定期向NN彙報自身存儲的塊信息，NN據此維護全局元數據。
JournalNode（JN）：管理員的“同步筆記本” - 僅在HA架構中存在，負責主備NN的元數據同步。主NN修改元數據後，會將操作記錄寫入JN集羣，備NN實時讀取同步，確保主備切換時數據一致。 - 需部署奇數個節點（至少3個），通過投票機制保證數據可靠性。

HDFS工作流：用户上傳文件→NN分配存儲塊和DN節點→文件被切分成塊存儲到多個DN→NN記錄元數據並同步到JN→用户讀取文件時，NN告知DN位置，直接從DN讀取。

二、Flink：大數據處理的“計算引擎”

Apache Flink是一款流批一體的分佈式計算框架，既能處理實時數據流（如電商實時交易、用户行為日誌），也能處理固定大小的批數據（如歷史報表統計），核心定位是“讓數據計算更實時、更可靠”。

1. Flink核心特性

流批一體：將批數據視為“有界流”，用同一引擎處理，避免傳統“流批兩套系統”的複雜度。
低延遲高吞吐：基於“流處理優先”設計，可實現毫秒級延遲，同時支持每秒數百萬條數據的吞吐。
可靠狀態管理：計算過程中的中間結果（如窗口聚合值）可持久化，任務故障後能恢復狀態，保證計算連續性。

2. Flink核心架構：三層協作模型

客户端（Client）：任務提交入口 - 將用户編寫的Flink作業（Java/Scala/Python代碼）編譯成“作業圖（JobGraph）”，提交給JobManager，不參與實際計算。
JobManager：計算指揮中心 - 集羣的“大腦”，負責作業調度與管理，包含： - ResourceManager：申請和分配計算資源（CPU/內存）； - Dispatcher：接收作業並啓動JobMaster； - JobMaster：每個作業對應一個JobMaster，將JobGraph優化為“執行圖（ExecutionGraph）”，調度任務到TaskManager執行。
TaskManager：計算執行節點 - 集羣的“幹活節點”，負責執行具體計算任務，每個TaskManager包含多個Task Slot（計算單元），可並行運行多個任務； - 與其他TaskManager交互數據，管理本地狀態存儲。

三、Flink+K8s+HDFS：雲原生大數據的“黃金組合”

三者並非獨立存在，而是形成“計算-調度-存儲”的閉環：Flink負責“計算”，K8s負責“資源調度與集羣管理”，HDFS負責“數據存儲”，組合優勢顯著。

1. 彈性資源調度：降本增效的核心

K8s的動態調度能力與Flink結合，實現資源按需分配： - 大促等流量高峯時，K8s自動增加Flink TaskManager Pod和HDFS DataNode數量； - 低谷時自動縮減資源，避免閒置浪費； - 通過Namespace和資源配額隔離Flink、HDFS等服務，防止相互搶佔資源。

2. 可靠數據存儲：保障計算不丟數據

HDFS為Flink提供關鍵存儲支撐： - Flink的Checkpoint（定期快照）和Savepoint（手動快照）存儲到HDFS，故障後可恢復狀態； - 計算結果數據（如實時報表）持久化到HDFS，支持後續查詢和分析； - HDFS的多副本存儲確保數據不丟失，適配大數據場景的可靠性需求。

3. 高可用與易運維：降低集羣管理成本

三者協同實現端到端高可用： - Flink JobMaster主備切換、HDFS NN主備切換通過K8s和ZooKeeper保障； - 所有組件容器化部署，用K8s YAML定義配置，實現“一次編寫，到處部署”； - 統一通過Prometheus+Grafana監控計算、資源、存儲指標，運維更高效。

四、問題實戰：NN報錯與PVC狀態關聯排查

1. 背景知識

hdfs的NN的初始化是否依賴JN

在HDFS非高可用（Non-HA）模式下，NameNode的初始化不依賴JournalNode；但在高可用（HA）模式下，NameNode的初始化確實依賴JournalNode。

特性維度	🚫 非HA模式	✅ HA模式
核心依賴	初始化不依賴JN	初始化依賴JN
JournalNode角色	無JN角色	JN作為共享存儲系統，是HA的關鍵組件
NameNode關係	單個NameNode	Active與Standby NN通過JN同步元數據
初始化命令	`hdfs namenode -format`	1. 主NN: `-format` 2. 備NN: `-bootstrapStandby`

HA模式下初始化的關鍵步驟

在HA模式下，NameNode的初始化是一個嚴謹的過程，其核心依賴JournalNode作為共享存儲系統來保證元數據的一致性。具體步驟如下：

啓動JournalNode集羣：在初始化NameNode之前，必須先在所有JournalNode節點上啓動JournalNode服務。這是後續操作的基礎。
格式化並啓動主NameNode：在規劃為Active的NameNode節點上，執行格式化命令 hdfs namenode -format。這個命令會初始化本地的元數據目錄，並且會與配置好的JournalNode集羣進行交互，初始化共享編輯日誌區域。
同步元數據到備NameNode：在規劃為Standby的NameNode節點上，執行 hdfs namenode -bootstrapStandby 命令。這個命令會從JournalNode共享編輯目錄（以及可選的從主NameNode拉取最新的fsimage）同步元數據，確保備節點與主節點具有一致的起點

2. 問題現象

NN Pod完整報錯日誌

通過kubectl logs <nn-pod-name> -n ververica查看報錯，核心信息如下：

2025-11-03 01:46:19,924 ERROR org.apache.hadoop.hdfs.server.namenode.NameNode: Failed to start namenode.
org.apache.hadoop.hdfs.server.common.InconsistentFSStateException: Directory /hdfs-data/pv-nn/name is in an inconsistent state: storage directory does not exist or is not accessible.
        at org.apache.hadoop.hdfs.server.namenode.FSImage.recoverStorageDirs(FSImage.java:369)
        at org.apache.hadoop.hdfs.server.namenode.FSImage.recoverTransitionRead(FSImage.java:220)
        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFSImage(FSNamesystem.java:1044)
        at org.apache.hadoop.hdfs.server.namenode.FSNamesystem.loadFromDisk(FSNamesystem.java:707)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.loadNamesystem(NameNode.java:635)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.initialize(NameNode.java:696)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:906)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.<init>(NameNode.java:885)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.createNameNode(NameNode.java:1626)
        at org.apache.hadoop.hdfs.server.namenode.NameNode.main(NameNode.java:1694)
2025-11-03 01:46:19,926 INFO org.apache.hadoop.util.ExitUtil: Exiting with status 1

PVC與組件狀態詳情

博主環境中部署的HA模式

通過kubectl get pvc -n ververica和kubectl get pods -n ververica | grep jn查看狀態：

NAME                          STATUS    VOLUME                                      CAPACITY   ACCESS MODES   STORAGECLASS   AGE
lxcfs-pvc                     Bound     pvc-d61befd8-1be9-47f8-bb09-b179e2945767    1Ki        RWX            lxcfs-sc       43h
pv-jn-vvp-hdfs-cluster-jn-0   Bound     yoda-0292255e-b49b-42fd-a560-cfd502359b4c   70Gi       RWO            fast-disks     36h
pv-jn-vvp-hdfs-cluster-jn-1   Bound     yoda-3c3ef831-61b4-4099-9cc3-a793c1baf798   70Gi       RWO            fast-disks     36h
pv-jn-vvp-hdfs-cluster-jn-2   Pending                                                                         fast-disks     36h
pv-nn-vvp-hdfs-cluster-nn-0   Bound     yoda-321b0886-c3d8-46be-9972-040c3d88c227   120Gi      RWO            fast-disks     35h
pv-nn-vvp-hdfs-cluster-nn-1   Bound     yoda-9e6052dc-8838-4fef-87aa-af1dccbe00d6   120Gi      RWO            fast-disks     35h

# JN Pod狀態
pv-jn-vvp-hdfs-cluster-jn-0   1/1     Running   0          36h
pv-jn-vvp-hdfs-cluster-jn-1   1/1     Running   0          36h
pv-jn-vvp-hdfs-cluster-jn-2   0/1     Pending   0          36h

**關鍵結論**：當前環境中，pv-jn-vvp-hdfs-cluster-jn-2（JN 2節點）PVC處於Pending狀態，導致JN集羣僅2個節點就緒，未滿足“奇數個節點（至少3個）”的Quorum機制要求，進而阻塞了NN的啓動流程。

3. 檢查PVC處於pending原因

Flink on Yarn_#hdfs

博主環境最終定位到：機器重新Clone後的節點親和性問題。其他場景不再贅述

五、思考-AI診斷

本案例中，診斷時間主要消耗在HDFS NameNode（nn）與JournalNode（jn）的部署關係配置問題，以及Persistent Volume Claim（pvc）處於pending狀態的根因分析上。這些問題涉及複雜的分佈式系統交互和存儲資源管理，導致手動排查效率低下。

採用多個Agent協作的方式，包括一個主Agent和多個子Agent（如規則診斷Agent、機器學習Agent、數據採集Agent等）。主Agent負責協調整個診斷流程，子Agent負責具體的診斷任務。

1.架構方案

Flink on Yarn_hdfs_02

主Agent：接收診斷請求，協調各個子Agent，彙總診斷結果，並返回最終診斷報告。
數據採集Agent：負責從Kubernetes集羣、存儲系統、節點等收集相關數據。
規則診斷Agent：基於預定義的規則（如存儲類不存在、資源不足、節點親和性等）進行診斷。
機器學習Agent：利用歷史數據和模型，進行異常檢測和根因分析，特別針對複雜場景（如機器重新clone導致的問題）。
報告生成Agent：生成診斷報告，包括問題原因、解決方案和可信度。

2.工作流程

a. 用户向主Agent發送診斷請求，指定待診斷的PVC。
  b. 主Agent調用數據採集Agent收集相關數據。
  c. 主Agent並行調用規則診斷Agent和機器學習Agent進行診斷。
  d. 主Agent彙總各個Agent的診斷結果，進行衝突解決和置信度融合。
  e. 主Agent調用報告生成Agent生成診斷報告。
  f. 返回診斷報告給用户。

3.詳細設計

3.1 數據採集Agent

負責從K8s集羣採集數據

- 採集的數據包括：
- PVC詳細信息（包括StorageClass、訪問模式、資源請求等）
- StorageClass列表及詳細信息
- PersistentVolume（PV）列表及詳細信息
- 節點信息（包括標籤、資源容量、存儲拓撲等）
- 資源配額信息
- 存儲提供商狀態
- 事件（Events）信息
- 集羣日誌（用於機器學習Agent）

3.2 規則診斷Agent

基於預定義的規則對收集的數據進行模式匹配，以發現已知的問題模式。

- 內置一系列診斷規則，例如：
- 檢查StorageClass是否存在
- 檢查資源配額是否足夠
- 檢查節點親和性約束（特別是機器重新clone後，節點標籤變化導致親和性規則不匹配）
- 檢查存儲提供商是否正常
- 檢查PV和PVC的訪問模式是否匹配
- 檢查集羣中是否有可用的節點滿足存儲拓撲要求

Flink on Yarn_#雲計算_03

3.3 知識圖譜Agent

知識圖譜Agent利用歷史診斷案例、Kubernetes存儲領域知識和最佳實踐，通過圖譜查詢和關係推理來輔助診斷。它主要基於已有的知識庫（存儲為圖譜形式）進行相似案例匹配和關係推理，從而提供診斷建議。

核心功能

圖譜查詢：查詢知識圖譜中與當前PVC Pending問題相關的實體和關係。
案例匹配：查找歷史上相似的成功診斷案例。
關係推理：利用圖譜中的關係（如因果關係、依賴關係）推斷可能的根因。

設計思路

知識圖譜Agent將存儲以下類型的信息：

歷史診斷案例（包括問題特徵、根因、解決方案）
Kubernetes存儲領域概念（如StorageClass、PV、PVC、Node等）及其關係
常見錯誤模式及其修復方法

當新的PVC Pending問題出現時，知識圖譜Agent會：

從當前問題中提取關鍵特徵（如錯誤信息、資源配置、節點狀態等）。
在圖譜中查找具有相似特徵的歷史案例。
返回匹配的案例及其解決方案，供診斷決策引擎參考。

Flink on Yarn_#flink_04

3.4 機器學習Agent

- 使用歷史數據進行訓練，能夠識別規則無法覆蓋的複雜模式。
- 特徵工程：從採集的數據中提取特徵，包括：
- PVC配置特徵（如存儲大小、訪問模式、StorageClass等）
- 集羣狀態特徵（如節點數量、存儲容量、資源使用率等）
- 時序特徵（如最近存儲事件、節點變化事件等）
- 拓撲特徵（如節點標籤、區域分佈等）
- 模型：可以使用分類模型（如隨機森林、梯度提升樹、神經網絡）進行根因分類，或者使用異常檢測模型（如隔離森林、自動編碼器）發現異常。
- 特別針對機器重新clone場景：檢測節點標識變化、存儲拓撲變化等。

3.5 主Agent的協調與決策

- 並行調用規則診斷Agent和機器學習Agent，並收集結果。
- 結果融合：根據各個Agent的置信度進行加權投票，或者使用規則引擎優先（因為規則通常更可解釋）並結合機器學習的結果。
- 衝突解決：如果規則診斷和機器學習診斷結果衝突，優先考慮規則診斷的結果，除非機器學習的結果有非常高的置信度且規則診斷的置信度較低。

六、總結

這類問題的本質是雲原生環境中“容器與存儲”的協同細節問題，需兼顧K8s資源配置與HDFS運行依賴，才能高效解決並避免復發。

回到原始問題“NN Pod報錯存儲目錄異常且PVC Pending”，結合上述架構可知： - NN的元數據目錄（如`/hdfs-data/pv-nn/name`）依賴K8s PVC掛載實現持久化，若PVC處於Pending狀態，意味着NN Pod無法獲取存儲資源，目錄自然“不存在或不可訪問”，導致NN啓動失敗。

基於多Agent協作的智能診斷方案，通過規則引擎、機器學習、知識圖譜結合的方式，可快速定位此類存儲資源問題。

本文章為轉載內容，我們尊重原作者對文章享有的著作權。如有內容錯誤或侵權問題，歡迎原作者聯繫我們進行內容更正或刪除文章。

mob64ca140088a9 博客

mob64ca140088a9 博客

博客 / 詳情

Flink on Yarn

一、HDFS：分佈式存儲的“數據倉庫”

1. HDFS核心架構：三大角色分工

二、Flink：大數據處理的“計算引擎”

1. Flink核心特性

2. Flink核心架構：三層協作模型

三、Flink+K8s+HDFS：雲原生大數據的“黃金組合”

1. 彈性資源調度：降本增效的核心

2. 可靠數據存儲：保障計算不丟數據

3. 高可用與易運維：降低集羣管理成本

四、問題實戰：NN報錯與PVC狀態關聯排查

1. 背景知識

hdfs的NN的初始化是否依賴JN

HA模式下初始化的關鍵步驟

2. 問題現象

NN Pod完整報錯日誌

PVC與組件狀態詳情

3. 檢查PVC處於pending原因

五、思考-AI診斷

1.架構方案

2.工作流程

3.詳細設計

六、總結

發佈評論

Product

Company

Support

Company

博客 / 詳情

Flink on Yarn

一、HDFS：分佈式存儲的“數據倉庫”

1. HDFS核心架構：三大角色分工

二、Flink：大數據處理的“計算引擎”

1. Flink核心特性

2. Flink核心架構：三層協作模型

三、Flink+K8s+HDFS：雲原生大數據的“黃金組合”

1. 彈性資源調度：降本增效的核心

2. 可靠數據存儲：保障計算不丟數據

3. 高可用與易運維：降低集羣管理成本

四、問題實戰：NN報錯與PVC狀態關聯排查

1. 背景知識

hdfs的NN的初始化是否依賴JN

HA模式下初始化的關鍵步驟

2. 問題現象

NN Pod完整報錯日誌

PVC與組件狀態詳情

3. 檢查PVC處於pending原因

五、思考-AI診斷

1.架構方案

2.工作流程

3.詳細設計

六、總結

發佈 評論

發佈評論