圖中資源相關參數含義及簡單分析思路：

1. 基礎資源搶占參數

• Total Resource Preempted: <memory:62112, vCores:6>
  含義：應用總共被搶占的資源量， memory:62112 表示累計被收回的內存（單位通常是MB ，結合Hadoop生態常見配置推測 ）， vCores:6 是被收回的虛擬CPU核心數。
  分析：若頻繁、大量出現資源搶占，可能集群資源緊張，或該應用資源申請/使用策略不合理，擠占其他任務資源。
• Total Number of Non - AM Containers Preempted: 6
  含義：非應用管理器（AM，Application Master ，負責應用資源協調等）容器被搶占的總數，這里是6個。容器是YARN等資源調度框架中資源分配的基本單位。
  Total Number of AM Containers Preempted: 0
  含義：應用管理器容器未被搶占，說明負責應用整體管控的核心進程資源相對穩定。
  分析：非AM容器被搶占多，可能是業務計算容器資源超量或集群整體資源不足，優先保障了AM穩定。
• Resource Preempted from Current Attempt: <memory:62112, vCores:6>
  含義：當前應用嘗試（一次提交執行可理解為一次Attempt ）中被搶占的資源量，和總搶占資源一致，說明本次執行就發生了這些資源回收。
  Number of Non - AM Containers Preempted from Current Attempt: 6
  含義：當前嘗試里被搶占的非AM容器數量，與總數量一致，即本次執行這6個業務容器資源被收走。
  分析：本次執行資源搶占集中，需看是否應用資源申請過高，或集群在該時段有更高優先級任務。

2. 資源分配聚合參數

• Aggregate Resource Allocation: 2612397662 MB - seconds, 27483 core - seconds
  含義：
• MB - seconds ：內存資源使用的“時間積分”，可理解為 內存量（MB）× 使用時長（秒） 總和，反映內存資源的累計消耗規模 ；
• core - seconds ：CPU核心使用的“時間積分”，即 CPU核心數 × 使用時長（秒） 總和，體現CPU資源的累計消耗規模。
  分析：數值大說明應用整體資源消耗多。對比同類型、同邏輯任務，若該數值異常高，可能任務數據量突增、計算邏輯低效（如冗余計算導致CPU/內存長時間占用）。
• Aggregate Preempted Resource Allocation: 24922718 MB - seconds, 244 core - seconds
  含義：因搶占回收的資源對應的“資源 - 時間”積分，即被收回資源若正常執行下去會產生的資源消耗。
  分析：結合前面搶占的容器數、資源量，可算搶占資源占總分配資源的比例（如這里內存搶占占比約 24922718/2612397662≈0.95% ，CPU同理 ），占比高說明資源浪費/不合理使用嚴重，占比低可能是集群臨時資源調劑。

整體分析思路

1. 資源搶占影響：若資源搶占后應用仍 SUCCEEDED （成功），說明雖被回收資源，但剩余資源或重試機制（若有）保障了執行；若頻繁因搶占失敗（ FAILED ），得調整資源申請、優化任務邏輯，或和集群管理員溝通資源配額。
2. 集群層面：多任務出現類似高搶占，需檢查集群資源規劃（如隊列資源分配、節點容量），是否有資源傾斜（某隊列/用戶占用過多 ）；若僅個別任務，聚焦任務自身資源配置、數據量、計算邏輯優化。
3. 結合業務：若這是周期性ETL（如每天跑的零售客戶標簽計算 exp_ctp_retail_cust_dms_labe_df ），對比歷史執行的資源參數，看是否數據量增長導致資源需求變化，或調度時段和其他大任務沖突擠資源 。

簡單說，這些參數反映應用在集群中資源“用了多少、被收走多少、怎么被收”，用于排查資源沖突、優化任務資源配置和保障集群穩定運行 。

資源搶占（Resource Preemption）主要會從任務執行、集群穩定性、資源利用率等維度產生影響，具體如下：

1. 對任務執行的直接影響

• 執行時間延長：
  若容器被搶占，任務可能需要重新申請資源、啟動容器，增加額外的調度和初始化開銷（如YARN重新分配容器、TEZ/MapReduce任務重啟），導致整體耗時變長。
  例：前一張圖中任務因資源搶占耗時25分鐘，而無搶占的任務耗時僅16分鐘左右。
• 任務失敗風險：
  若搶占后剩余資源不足（如內存/CPU被過度回收），任務可能因“資源不足”（如OOM、容器被強制Kill）失敗；即使重試，頻繁搶占也會耗盡重試次數（若配置有限）。

2. 對集群穩定性的影響

• 集群抖動（Thrashing）：
  大量任務同時被搶占、重啟會導致集群資源“潮汐式”波動，引發YARN調度隊列過載、節點負載突增，甚至影響其他無關任務的正常執行。
• 低優先級任務“餓死”：
  若高優先級任務持續搶占資源，低優先級任務可能長期無法獲得足夠容器，導致業務延遲（如非核心ETL任務被核心報表任務搶占）。

3. 對資源利用率的雙向影響

• 正面：倒逼資源合理分配
  搶占機制迫使低優先級/超額申請的任務釋放資源，讓高優先級/資源緊缺的任務獲得保障，提升集群整體資源利用率（避免“大任務占坑不干活”）。
• 負面：過度搶占導致資源浪費
  若搶占策略激進（如YARN的 yarn.scheduler.fair.preemption.timeout 設置過短），任務可能頻繁被中斷，資源在“搶占 - 重啟”循環中內耗，反而降低實際有效利用率。

4. 對業務邏輯的潛在影響

• 有狀態任務的數據一致性風險
  若任務是有狀態計算（如流處理、迭代計算），容器被搶占可能導致中間狀態丟失，需依賴Checkpoint機制恢復，增加數據一致性保障的復雜度。
  總結
  資源搶占是一把“雙刃劍”：合理配置（如基于優先級、資源使用閾值觸發搶占）可優化集群資源公平性與利用率；配置不當或集群過載則會導致任務延遲、失敗，甚至引發集群級不穩定。實際中需結合業務優先級、任務類型（如批處理/流處理）和集群規模，精細調整搶占策略（如YARN的公平調度/容量調度參數）。

要優化該Tez任務的參數配置，需結合資源搶占、聚合資源消耗與Tez任務的內存/CPU參數邏輯，分以下步驟調整：

一、核心參數調整：減少資源搶占，匹配實際需求

從圖中看，任務被搶占的總內存為 62112 MB （約60GB）、涉及6個非AM容器，反推原單個容器內存請求約 10GB （ 62112 ÷ 6 ≈ 10352 MB ）。但聚合資源分配的內存時間積分（ 2612397662 MB-seconds ）遠大于被搶占的資源積分（ 24922718 MB-seconds ），說明容器內存申請過高，實際使用不足，需降低容器內存請求。

1. 調整容器與AM內存

• hive.tez.container.size ：設置單個容器的總內存（需與YARN的 yarn.scheduler.minimum-allocation-mb 匹配，建議設為 4096 MB 或 6144 MB ，即4G/6G，降低被搶占概率）。
• tez.am.resource.memory.mb ：Application Master（AM）的內存，需與 yarn.scheduler.minimum-allocation-mb 一致（如設為 4096 MB ），保證AM不被搶占。
• hive.tez.container.max.java.heap.size ：容器內Java堆內存，建議為 container.size 的80%（如 container.size=4096 MB 時，設為 3276 MB ）。

2. 優化IO與內存緩沖（減少內存浪費）

Tez的IO緩沖內存若設置過大，會導致容器內存“虛高”被YARN誤判搶占。需按容器內存比例配置：

• tez.runtime.io.sort.mb ：排序內存，設為 container.size 的40%（如 container.size=4096 MB 時，設為 1638 MB ，不超過2GB）。
• tez.runtime.unordered.output.buffer.size-mb ：非排序輸出緩沖，設為 container.size 的10%（如 409 MB ）。
• hive.auto.convert.join.noconditionaltask.size ：Map Join內存，設為 container.size 的1/3（如 1365 MB ），避免大Join時內存溢出。

二、輔助優化：提升資源利用率

1. 開啟容器重用（減少資源申請次數）

設置 tez.am.container.reuse.enabled=true ，允許AM容器復用，減少YARN調度 overhead，尤其適合短任務場景。

2. 控制并行度（避免資源過載）

若任務數據量未達TB級，可降低并行度減少容器數：

• tez.grouping.split-count ：輸入分片數（即并行任務數），根據實際數據量調整（如從100+降到50左右），減少總資源申請量。

3. 匹配YARN集群配置

需確保任務參數與YARN全局配置一致：

• 若YARN的 yarn.scheduler.minimum-allocation-mb=4096 ，則 tez.am.resource.memory.mb 和 hive.tez.container.size 必須≥4096。
• 若 yarn.nodemanager.vmem-pmem-ratio=2.1 （默認），則容器虛擬內存上限為 物理內存×2.1 ，需避免Java堆外內存（如NIO緩沖）觸發虛擬內存超限。

三、驗證與監控

1. 測試調整后效果：重新運行任務，觀察 Resource Preempted 是否減少、 Elapsed （耗時）是否穩定。
2. 長期監控：通過YARN UI或日志跟蹤容器內存實際使用量（如 /proc//stat 解析），逐步微調 container.size 和堆內存參數，直到“實際使用≈申請內存”且無搶占。

示例參數配置（供參考）

set hive.tez.container.size=4096; – 每個容器4G內存
set tez.am.resource.memory.mb=4096; – AM內存與容器一致
set hive.tez.container.max.java.heap.size=3276; – 堆內存為container的80%
set tez.runtime.io.sort.mb=1638; – 排序內存40% of container
set tez.runtime.unordered.output.buffer.size-mb=409; – 非排序緩沖10% of container
set hive.auto.convert.join.noconditionaltask.size=1365; – Map Join內存1/3 of container
set tez.am.container.reuse.enabled=true; – 開啟容器重用
set tez.grouping.split-count=50; – 調整并行度

通過“降低容器內存請求+按比例分配子內存+匹配YARN配置”，可減少資源搶占，同時保證任務穩定運行。