1、巡檢
YARN 為 Hadoop 叢集的上層應用，包括 MapReduce、Spark 等計算服務在內，提供了統一的資源管理和排程服務。
每日早晚巡檢YARN 服務，主要檢查資源池內主機的健康狀態，保障 YARN 服務可用性。
1.1、YARN CM 執行狀態
Yarn 叢集，目前 Cloudera Manager 顯示 6 個不良，16 個存在隱患

開啟顯示為不良的 NodeManager，這個節點有壞盤正在報修階段

檢視存在隱患的 NodeManager

檢視正在執行的 Container 與總核數的差距

檢視是否有大量失敗的 Container，目前很少

檢視 resourcemanager 高可用狀態，良好

檢視 resourcemanager 監控指標，記憶體充足，待定的 Container 持續負載不高

JVM 堆疊，沒有異常

檢視記憶體、磁碟情況，記憶體充足，磁碟延遲低

1.2、YARN WEB UI 執行狀態
檢視叢集整體情況，發現 5 個 LOST 節點，1 個不健康節點

1 個不健康節點是有壞盤情況，已經進去報修階段

5 個 Lost Nodes 是因為幾個主機總是出問題以及 IAAS 測正在檢視

檢視資源佇列資源使用情況，因為我是晚上 8 點截的圖，是低峰期，所以使用資源不多

1.3、YARN/MR 關鍵效能指標
各個 NodeManager 的 GC 時間

gc 時間基本在幾 ms，gc 正常。

NodeManager 駐留記憶體

NodeManager 駐留記憶體為 1G 左右，因此建議提升 NodeManager 記憶體。

叢集每秒完成的任務數

每秒完成 1.5 個任務。
1.3.1、存在問題
叢集資源使用率較低

叢集節點記憶體使用，節點普遍記憶體使用都只有 10G 左右。

叢集節點 CPU 平均使用率在 40%左右，不算很高。

但是從 Yarn 的頁面可以看到，Yarn 的叢集使用率已經高達 100%
1.3.2、原因分析
Yarn 顯示資源使用率達到 100%，而叢集節點記憶體，CPU 等資源卻使用不是很高。
Yarn 在配置時，通過設定每個 NodeManager 可以分配的 Container 記憶體， 以及 CPU，來設定每個節點的資源。目前每個 NodeManager 配置了 120G，CPU 配置了 32VCore。
目前叢集可能存在的問題是，每個 Container 分配的資源過高，實際任務並不需要這麼多資源，從而出現了資源被分配完，但是使用率低的情況。
1.3.3、建議方案
降低 Container 的記憶體分配，增加 Nodemanager 能夠分配的 Vcore 數。配置如下：
1.Container 虛擬 CPU 核心yarn.nodemanager.resource.cpu-vcores： 48
2.Map 任務記憶體 mapreduce.map.memory： 1.5G
3.Reduce 任務記憶體 mapreduce.reduce.memory.mb 1.5G
4.Map 任務最大堆疊 mapreduce.map.java.opts.max.heap 1.2G
5.Reduce 任務最大堆疊 mapreduce.reduce.java.opts.max.heap 1.2G 不過注意，對於某些對於記憶體需求較高的任務，需要單獨設定，保證不出現outofmemory 的情況。
2、引數調優
2.1、節點記憶體資源
yarn.nodemanager.resource.memory-mb
NodeManager 一般和 datanode 部署在一起，這些角色本身也要消耗記憶體， 並且作業系統也需要部分記憶體，建議 Container 記憶體可以適當降低，這些總的記憶體相加不能超過節點實體記憶體，我們給作業系統留 5G 以內的記憶體
2.2、節點虛擬 CPU 核心
yarn.nodemanager.resource.cpu-vcores
NodeManager 可以使用的核數，我們產線環境的核數配置的跟機器的核數是一致的
2.3、Container 最小分配記憶體
yarn.scheduler.minimum-allocation-mb
Container 最小記憶體定義了 Yarn 可以分配給 Container 最小資源，不管任務本身處理的資料量大小，都會至少分配這麼多的記憶體，我們產線環境設定的是2G，從目前的監控上看記憶體資源是夠用的，CPU 資源緊張
2.4、Container 最大分配記憶體
yarn.scheduler.maximum-allocation-mb
Container 最大可申請的記憶體，目前我們產線環境配置的是 32G，因為我們產線環境有 Spark 作業，Spark 同一個執行器可以跑多個任務，平分記憶體
2.5、資源規整化因子
yarn.scheduler.increment-allocation-mb 假如規整化因子 b=512M，上述講的引數
yarn.scheduler.minimum-allocation-mb 為 1024， yarn.scheduler.maximum-allocation-mb 為 8096，然後我打算給單個 map 任務申請記憶體資源(mapreduce.map.memory.mb):
申請的資源為 a=1000M 時，實際 Container 最小記憶體大小為 1024M(小於yarn.scheduler.minimum-allocation-mb 的話自動設定為yarn.scheduler.minimum-allocation-mb);
申請的資源為 a=1500M 時，實際得到的 Container 記憶體大小為 1536M，計算公式為:ceiling(a/b)*b，即 ceiling(a/b)=ceiling(1500/512)=3，
3*512=1536。此處假如 b=1024，則 Container 實際記憶體大小為 2048M 也就是說 Container 實際記憶體大小最小為
yarn.scheduler.minimum-allocation-mb 值，然後增加時的最小增加量為規整化因子 b，最大不超過 yarn.scheduler.maximum-allocation-mb
當使用 capacity scheduler 或者 fifo scheduler 時，規整化因子指的就是引數yarn.scheduler.minimum-allocation-mb，不能單獨配置，即yarn.scheduler.increment-allocation-mb 無作用;
當使用 fair scheduler 時，規整化因子指的是引數yarn.scheduler.increment-allocation-mb
我們產線環境設定的是 512M
2.6、Container 最小虛擬 CPU 核心數量
yarn.scheduler.minimum-allocation-vcores 產線環境配置的為 1
2.7、最大Container 虛擬 CPU 核心數量
yarn.scheduler.maximum-allocation-vcores 我們的產線環境配置的是 12
2.8、MapReduce ApplicationMaster 的記憶體
yarn.app.mapreduce.am.resource.mb
我們產線環境設定的是 2G，2G 基本夠用了，如果有特殊情況，可以酌情改大
2.9、ApplicationMaster Java 最大堆疊
通常是 yarn.app.mapreduce.am.resource.mb 的 80%，1.6G
2.10、Map 任務記憶體
mapreduce.map.memory.mb
Map 任務申請的記憶體大小，產線環境設定的是 2G，一般有作業覆蓋
2.11、Reduce 任務記憶體
mapreduce.reduce.memory.mb
Reduce 任務申請的內容大小，產線環境設定的是 2G，一般有作業覆蓋
2.12、Map 和Reduce 堆疊記憶體
mapreduce.map.java.opts、mapreduce.reduce.java.opts
以 map 任務為例，Container 其實就是在執行一個指令碼檔案，而指令碼檔案中， 會執行一個 Java 的子程序，這個子程序就是真正的 Map Task，mapreduce.map.java.opts 其實就是啟動 JVM 虛擬機器時，傳遞給虛擬機器的啟動引數，表示這個 Java 程式可以使用的最大堆記憶體數，一旦超過這個大小，JVM 就會丟擲 Out of Memory 異常，並終止程序。而mapreduce.map.memory.mb 設定的是 Container 的記憶體上限，這個引數由 NodeManager 讀取並進行控制，當 Container 的記憶體大小超過了這個引數值，NodeManager 會負責 kill 掉 Container。在後面分析yarn.nodemanager.vmem-pmem-ratio 這個引數的時候，會講解NodeManager 監控 Container 記憶體（包括虛擬記憶體和實體記憶體）及 kill 掉Container 的過程。就是說，mapreduce.map.java.opts 一定要小於mapreduce.map.memory.mbmapreduce.reduce.java.opts 同 mapreduce.map.java.opts 一樣的道理。預設是 mapreduce.map.memory.mb 和 mapreduce.reduce.memory.mb 的 80%
2.13、ResourceManager 的 Java 堆疊大小
產線環境配置的是 32G，-Xmx32768m 產線環境使用了 16G

2.14、NodeManager 的 Java 堆疊大小
產線環境配置的是 1G，-Xmx1024m
對於節點數較大，並且處理任務較多的叢集，NodeManager 的記憶體可以相應設定的充裕一些，比如 2G-4G

2.15、Reduce 任務前要完成的 Map 任務數量
mapreduce.job.reduce.slowstart.completedmaps
該引數決定了 Map 階段完成多少比例之後，開始進行 Reduce 階段，如果叢集空閒資源較多，該引數可以設定的比較小，如果資源緊張，建議可以設定的更大，由 0.8 改為 0.95
2.16、Hive 引數彙總
1.組合引數優化：減少 map 數
是否支援可切分的CombineInputFormat 合併輸入小檔案此引數必須加否則不生效
set hive.hadoop.supports.splittable.combineinputformat=true;
set hive.input.format=org.apache.hadoop.hive.ql.io.CombineHiveInputFor mat;
一個節點上 split 的至少的大小
set mapred.max.split.size=1073741824;
一個交換機下 split 至少的大小
set mapred.min.split.size.per.node=1073741824;
2.組合引數優化：調整 reduce 輸出大小，降低 reduce 數，降低小檔案輸出
強制指定 reduce 的任務數量，可以設定這個引數，如果不確定忽略此引數， 用下面的兩個引數
mapred.reduce.tasks=${num}
reduce 最大個數
set hive.exec.reduceRegionServer.max=300;
每個 reduce 任務處理的資料量，一般設定為 2G， 2G = 2147483648 Bytes
set hive.exec.reduceRegionServer.bytes.per.reducer=2147483648;
hive.exec.reduceRegionServer.bytes.per.reducer 67108864 預設值是64M
3.優化小檔案問題
在 Map-only 的任務結束時啟用合併小檔案set hive.merge.mapfiles=true;
在 Map-Reduce 的任務結束時啟用合併小檔案set hive.merge.mapredfiles=true;
當輸出檔案的平均大小小於該值時，啟動一個獨立的 map-reduce 任務進行檔案 merge
set hive.merge.smallfiles.avgsize=1073741824;
合併後文件的大小為 1GB 左右
set hive.merge.size.per.task=1073741824;
4.container 記憶體大小
map 記憶體
set mapreduce.map.memory.mb=2048; 叢集最小值是 2048M，與
mapreduce.map.memory.mb/mapred.max.split.size 比例是 2:1
reduce
set mapreduce.reduce.memory.mb=4096;與hive.exec.reduceRegionServer.bytes.per.reducer 引數比例 1:1~1:2
set mapred.child.java.opts=-Xmx3481m;確認叢集與 mapreduce.map.memory.mb 的關係
5.作業通用引數
job 名
set mapreduce.job.name=P_DWA_D_IA_test;
佇列名
set mapreduce.job.queuename=ia;
3、運維
3.1、運維命令
3.1.1、application
yarn application [options]
-list
#列出 RM 中的應用程式。支援使用-appTypes 來根據應用程式型別過濾應用程式，並支援使用-appStates 來根據應用程式狀態過濾應用程式。
-kill <ApplicationId>
#終止應用程式。
-status <ApplicationId>
#列印應用程式的狀態。
-appStates <States>
#與-list 一起使用，可根據輸入的逗號分隔的應用程式狀態列表來過濾應用程式。有效的應用程式狀態可以是以下之一： ALL，NEW，NEW_SAVING，SUBMITTED，ACCEPTED，RUNNING， FINISHED，FAILED，KILLED
-appTypes <Types>
#與-list 一起使用，可以根據輸入的逗號分隔的應用程式型別列表來過濾應用程式。
3.1.2、applicationattempt
yarn applicationattempt [options]
-help #幫助
-list <ApplicationId> #獲取到應用程式嘗試的列表，其返回值ApplicationAttempt-Id 等於 <Application Attempt Id>
-status <Application Attempt Id> #列印應用程式嘗試的狀態。
3.1.3、classpath
yarn classpath
#列印需要得到 Hadoop 的 jar 和所需要的 lib 包路徑
3.1.4、container
yarn container [options]
#列印 container(s)的報告
-help #幫助
-list <Application Attempt Id> #應用程式嘗試的ContaineRegionServer 列表
-status <ContainerId> #列印 Container 的狀態
3.1.5、logs
yarn logs -applicationId <application ID> [options] #轉存container 的日誌。
複製程式碼
-applicationId <application ID> #指定應用程式 ID，應用程式的 ID 可以在 yarn.resourcemanager.webapp.address 配置的路徑檢視（即：ID）
-appOwner <AppOwner> #應用的所有者（如果沒有指定就是當前使用者）應用程式的 ID 可以在 yarn.resourcemanager.webapp.address 配置的路徑檢視（即：User）
-containerId <ContainerId> #Container Id
-help #幫助
-nodeAddress <NodeAddress> # 節點地址的格式：nodename:port（埠是配置檔案中:yarn.nodemanager.webapp.address 引數指定）
3.1.6、node
yarn node [options]
#列印節點報告
-all #所有的節點，不管是什麼狀態的。
-list #列出所有 RUNNING 狀態的節點。支援-states 選項過濾指定的狀態，節點的狀態包含：NEW，RUNNING，UNHEALTHY，DECOMMISSIONED，LOST，REBOOTED。支援--all 顯示所有的節點。
-states <States> #和-list 配合使用，用逗號分隔節點狀態，只顯示這些狀態的節點資訊。
-status <NodeId> #列印指定節點的狀態。
3.1.7、queue
yarn queue [options]
#列印佇列資訊
-status #<QueueName> 列印佇列的狀態
3.1.8、rmadmin
yarn rmadmin [-refreshQueues]
[-refreshNodes]
[-refreshUserToGroupsMapping]
[-refreshSuperUserGroupsConfiguration] [-refreshAdminAcls]
[-refreshServiceAcl]
[-getGroups [username]]
<serviceId>]
<serviceId2>]
[-transitionToActive [--forceactive] [--forcemanual]
[-transitionToStandby [--forcemanual] <serviceId>] [-failover [--forcefence] [--forceactive] <serviceId1>
[-getServiceState <serviceId>] [-checkHealth <serviceId>]
[-help [cmd]]

-refreshQueues #過載佇列的 ACL，狀態和排程器特定的屬性，ResourceManager 將過載 mapred-queues 配置檔案
-refreshNodes #動態重新整理 dfs.hosts 和 dfs.hosts.exclude 配置，無需重啟 ResourceManager。
#dfs.hosts：列出了允許連入 NameNode 的 datanode 清單（IP 或者機器名）
#dfs.hosts.exclude：列出了禁止連入 NameNode 的datanode 清單（IP 或者機器名）
#重新讀取 hosts 和 exclude 檔案，更新允許連到Namenode 的或那些需要退出或入編的 datanode 的集合。
-refreshUserToGroupsMappings #重新整理使用者到組的對映。
-refreshSuperUserGroupsConfiguration #重新整理使用者組的配置
-refreshAdminAcls #重新整理 ResourceManager 的ACL 管理
-refreshServiceAcl #ResourceManager 過載服務級別的授權檔案。
-getGroups [username] #獲取指定使用者所屬的組。
-transitionToActive [–forceactive] [–forcemanual] <serviceId> #嘗試將目標服務轉為 Active 狀態。如果使用了–forceactive 選項，不需要核對非Active 節點。如果採用了自動故障轉移，這個命令不能使用。雖然你可以重寫
–forcemanual 選項，你需要謹慎。
-transitionToStandby [–forcemanual] <serviceId> # 將服務轉為 Standby 狀態. 如果採用了自動故障轉移，這個命令不能使用。雖然你可以重寫–forcemanual 選項，你需要謹慎。
-failover [–forceactive] <serviceId1> <serviceId2> # 啟 動 從 serviceId1 到 serviceId2 的故障轉移。如果使用了-forceactive 選項，即使服務沒有準備， 也會嘗試故障轉移到目標服務。如果採用了自動故障轉移，這個命令不能使用。
-getServiceState <serviceId> #返回服務的狀態。（注：ResourceManager 不是 HA 的時候，是不能執行該命令的）
-checkHealth <serviceId> #請求伺服器執行健康檢查，如果檢查失敗，RMAdmin 將用一個非零標示退出。（注：ResourceManager 不是 HA 的時候，是不能執行該命令的）
-help [cmd] #顯示指定命令的幫助，如果沒有指定，則顯示命令的幫助。
3.2、啟動、停止
3.2.1、命令列啟動
1.全部啟動 YARN 叢集
./bin/start-yarn.sh
2.全部停止 YARN 叢集
./bin/stop-yarn.sh
3單獨啟停 resourcemanager 叢集
./bin/yarn-deamon.sh start resourcemanager
./bin/yarn-deamon.sh stop resourcemanager
4單獨啟停 nodemanager 叢集
./bin/yarn-deamon.sh start nodemanager
./bin/yarn-deamon.sh stop nodemanager
3.2.2、CM啟動、停止
1.整體啟動、停止、重啟、滾動重啟

2.部分啟動、停止、重啟、滾動重啟

3.3、擴縮容
同HDFS擴縮容
3.4、資源佇列-容量排程
3.4.1、概述
Hadoop 的可插拔排程器，允許多租戶安全地共享一個大叢集，以便在分配容量的約束下及時為應用程式分配資源，被設計來以共享、多租戶的形式執行hadoop 應用程式，在友好規則下，能夠更大限度地提高叢集的吞 吐量和利用率。
Capacity Schedule 排程器以佇列為單位劃分資源。簡單通俗點來說，就是一個個佇列有獨立的資源， 佇列的結構和資源是可以進行配置的。

default 佇列佔 30%資源，analyst 和 dev 分別佔 40%和 30%資源；類似的，analyst 和 dev 各有兩個子佇列，子佇列在父佇列的基礎上再分配資源。佇列以分層方式組織資源，設計了多層級別的資源限制條件以更好的讓多使用者共享一個 Hadoop 叢集，比如佇列資源限制、使用者資源限制、使用者應用程式數目限制。佇列裡的應用以 FIFO 方式排程，每個佇列可設定一定比例的資源最低保證和使用上限，同時每個使用者也可以設定一定的資源使用上限以防止資源 濫用。而當一個佇列的資源有剩餘時，可暫時將剩餘資源共享給其他佇列。
3.4.2、特性
1.分層佇列
支援層級佇列來確保資源在子佇列間共享。
2.容量保證
所有提交到佇列的的應用程式都將能保證獲取到資源，管理員可以配置soft 和硬體資源分配到每個佇列的限制。
3.安全性
每個佇列有嚴格的 ACLs 許可權控制，允許哪些使用者提交到某個佇列，哪些使用者不能看看或者修改其他人的應用等。
4.彈性
彈性特性允許閒置資源能被任何佇列分配到。
5.多租戶
一系列全面的限制，防止單個應用程式、單使用者和佇列獨佔佇列或叢集的所有資源，以確保叢集不會不堪重負。
6.可操作性
執行時配置：執行時可以配置佇列的定義、屬性修改等操作，比如容量、acl 修改
作業保障：管理員停止佇列時，保障正在執行的應用程式執行完成，保障其他新的應用程式不能提交到 佇列或者子佇列。
3.4.3、排程器設定
要配置 ResourceManager 以使用 CapacityScheduler，請在 conf/yarn-site.xml 中 設 置 以 下 屬 性 ： yarn.resourcemanager.scheduler.class：org.apache.hadoop.yarn.server.resourcemanager.scheduler.capacity.C apacityScheduler
CM 中設定：

3.4.4、佇列引數
1.資源分配相關引數：
capacity：佇列的最小資源容量（百分比）。注意，所有佇列的容量之和應小於 100
maximum-capacity：佇列的資源使用上限
minimum-user-limit-percent：每個使用者最低資源保障（百分比）
user-limit-factor：每個使用者最多可使用的資源量（百分比）
2.限制應用程式數目的相關引數：
maximum-applications：叢集或者佇列中處於等待和執行狀態的應用程式數目上限，這是一個強限制項，一旦叢集中應用程式數目超過該上限， 後續提交的應用程式將被拒絕。預設值為 10000。Hadoop 允許從叢集和佇列兩個方面該值，其中，叢集的總體數目上限可通過引數yarn.scheduler.capacity.maximum-applications 設定，預設為 10000， 而單個佇列可通過引數yarn.scheduler.capacity.<queue-path>.maximum-applications 設定適合自己的值
maximum-am-resource-percent：叢集中用於執行應用程式ApplicationMaster 的資源比例上限，該引數通常用於限制處於活動狀態的應用程式數目。所有佇列的 ApplicationMaster 資源比例上限可通過引數 yarn.scheduler.capacity.maximum-am-resource-percent 設定，而單個佇列可通過引數yarn.scheduler.capacity.<queue-path>.maximum-am-resource-percent 設定適合自己的值
3.佇列訪問許可權控制
state：佇列狀態，可以為 STOPPED 或者 RUNNING。如果一個佇列處於 STOPPED 狀態，使用者不可以將應用程式提交到該佇列或者它的子佇列中。類似的，如果 root 佇列處於 STOPPED 狀態，則使用者不可以向叢集提交應用程式，但正在執行的應用程式可以正常執行結束，以便佇列可以優雅地退出
acl_submit_application：限定哪些使用者/使用者組可向給定佇列中提交應用程式。該屬性具有繼承性，即如果一個使用者可以向某個佇列提交應用程式，則它可以向它所有子佇列中提交應用程式
acl_administer_queue：為佇列指定一個管理員，該管理員可控制該佇列的所有應用程式，比如殺死任意一個應用程式等。同樣，該屬性具有繼承性，如果一個使用者可以向某個佇列中提交應用程式，則它可以向它的所有子佇列中提交應用程式當管理員需動態修改佇列資源配置時，可修改配置檔案conf/capacity-scheduler.xml，然後執行“yarn rmadmin -refreshQueues” 當前 Capacity Scheduler 不允許管理員動態減少佇列數目，且更新的配置引數值應是合法值，否則會導致配置檔案載入失敗
3.4.5、佇列配置
CapacityScheduler 有一個預定義佇列叫 root，系統中所有的佇列是 root 佇列的一個子佇列。
更多的佇列可以通過配置 yarn.scheduler.capacity.root.queues 該屬性來配置，多個子佇列 使用"，"來分割。
CapacityScheduler 有一個概念叫 queue path，是用來配置佇列層級的，這個 queue path 是佇列的 層級，使用 root 開始，然後用"."來進行連線。比如root.a。
佇列的子佇列可使用 yarn.scheduler.capacity.<queue-path>.queues 來配置。除非另有申明，否則子元素不能直接從父元素繼承屬性。
產線案例
<?xml veRegionServerion="1.0" encoding="utf-8"?>

<configuration>
<property>
<name>yarn.scheduler.capacity.maximum-applications</name>
<value>10000</value>
</property>
<property>
<name>yarn.scheduler.capacity.resource-calculator</name>
<value>org.apache.hadoop.yarn.util.resource.DominantResourceCalculator</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.queues</name>
<value>default,ia,ia_dzh,ia_serv</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.default.capacity</name>
<value>0</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.default.user-limit-factor</name>
<value>1</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.default.maximum-capacity</name>
<value>100</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.default.state</name>
<value>RUNNING</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.default.acl_submit_applications</name>
<value>t1</value>

</property>
<property>
<name>yarn.scheduler.capacity.root.default.acl_administer_queue</name>
<value>t1</value>
</property>

<property>
<name>yarn.scheduler.capacity.root.ia.capacity</name>
<value>50</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia.user-limit-factor</name>
<value>2</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia.maximum-capacity</name>
<value>100</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia.state</name>
<value>RUNNING</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia.acl_submit_applications</name>
<value>if_ia_pro,if_ia_serv</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia.acl_administer_queue</name>
<value>ia</value>
</property>

<property>
<name>yarn.scheduler.capacity.root.ia_dzh.capacity</name>
<value>30</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia_dzh.user-limit-factor</name>
<value>5</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia_dzh.maximum-capacity</name>
<value>100</value>
</property>
<property>

<name>yarn.scheduler.capacity.root.ia_dzh.state</name>
<value>RUNNING</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia_dzh.acl_submit_applications</name>
<value>if_ia_pro</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia_dzh.acl_administer_queue</name>
<value>if_ia_pro</value>
</property>

<property>
<name>yarn.scheduler.capacity.root.ia_serv.capacity</name>
<value>20</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia_serv.user-limit-factor</name>
<value>4</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia_serv.maximum-capacity</name>
<value>100</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia_serv.state</name>
<value>RUNNING</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia_serv.acl_submit_applications</name>
<value>lf_ia_serv</value>
</property>
<property>
<name>yarn.scheduler.capacity.root.ia_serv.acl_administer_queue</name>
<value>ia_serv</value>
</property>
</configuration>
3.5、資源佇列-公平排程設定
3.5.1、概述
公平排程是一種為應用程式分配資源的方法，它可以隨時間使得所有應用程式平均獲得相等的資源份額。 下一代的 Hadoop 能夠排程多種資源型別。預設情況下，公平排程程式僅基於記憶體來確定排程公平性決策。它可以使用Ghodsi 等人開發的DRF（作業排程演算法）的概念來配置，同時排程記憶體和 CPU。當有一個應用程式在執行時，該應用程式將使用整個叢集。當提交其他應用程式時，將會有資源被釋放來分配給新應用程式，以便最終每個應用程式獲得的資源大致相同。與組成應用程式佇列的預設 Hadoop 排程器不同，這可以讓短應用程式在合理的時間內完成，同時不會使長期存在的應用程式捱餓。它也是一種在多個使用者之間共享群集的合理方式。最後，公平共享還可以與應用優先順序一起使用 - 優先順序用權重來確定每個應用應獲得的總資源的比例。
排程程式將應用程式進一步組織為“佇列”，並在這些佇列之間公平地共享資源。預設情況下，所有使用者共享一個名為“default”的佇列。如果應用程式專門在容器資源請求中列出佇列，則將請求提交給該佇列。還可以通過配置中基於請求的使用者名稱來分配佇列。在每個佇列中，排程策略被用來在正在執行的應用程式之間共享資源。預設是根據記憶體來公平分享資源，但也可以配置具有 DRF（作業排程演算法）的 FIFO 和多資源策略。佇列可以按照階級來劃分資源，並根據權重配置來按特定比例去共享群集。
除了提供公平共享資源外，Fair Scheduler 還允許為佇列分配可保證的最小資源，這對於確保某些使用者，使用者組或生產應用始終獲得足夠的資源是很有用的。當佇列包含應用程式時，它最少能獲得一個最小資源，但是當佇列不需要完全保證共享時，超出部分將在其他正在執行的應用程式之間分配。這使得排程器可以保證佇列容量，同時在佇列裡不包含應用程式時，可以有效地利用資源。
Fair Scheduler 允許所有應用程式預設執行，但也可以通過配置檔案限制每個使用者和每個佇列執行的應用程式數量。這在當用戶必須一次提交數百個應用程式時是非常有用的，或者說，如果同時執行太多應用程式會導致建立過多的中間資料或過多的上下文切換時，可以提高效能。限制應用程式不會導致任何後續提交的應用程式失敗，只會在排程程式的佇列中等待，直到某些使用者的早期的應用程式完成為止。
3.5.2、具有可插拔策略的分層佇列
Fair Scheduler 支援層次佇列（hierarchical queues），所有佇列都從 root佇列開始，root 佇列的孩子佇列公平地共享可用的資源。孩子佇列再把可用資源公平地分配給他們的孩子佇列。apps 可能只會在葉子佇列被排程。此外， 使用者可以為每個佇列設定不同的共享資源的策略，內建的佇列策略包括 FifoPolicy， FaiRegionServerharePolicy (default)， and DominantResourceFairnessPolicy。
3.5.3、佇列配置
自定義 Fair Scheduler 通常涉及更改兩個檔案。首先，可以通過在現有配置目錄的 yarn-site.xml 檔案中新增配置屬性來設定排程程式範圍的選項。其次，在大多數情況下，使用者需要建立一個分配檔案，列出存在哪些佇列以及它們各自的權重和容量。分配檔案每 10 秒重新載入一次，允許動態更改。
可以放在 yarn-site.xml 中的屬性屬性描述
yarn.scheduler.fair.allocation.file分配檔案的路徑。除了某些策略預設值之外，分配檔案是描述佇列及其屬性的 XML 清單。此檔案必須採用下一節中描述的 XML 格式。如果給出了相對路徑，則在類路徑（通常包括 Hadoop conf 目錄）上搜索檔案。預設為 fair-scheduler.xml。
yarn.scheduler.fair.user-as-default-queue 在未指定佇列名稱的情況下，是否將與分配關聯的使用者名稱用作預設佇列名稱。如果將其設定為“false”或未設定，則所有作業都有一個共享的預設佇列，名為“default”。預設為 true， 產線環境一版會置位 false
yarn.scheduler.fair.preemption 是否使用搶佔。預設為 true。分配檔案必須是 XML 格式。格式包含五種型別的元素：
Queue elements:代表隊列。佇列元素可以採用可選屬性“型別”，當設定為“父”時，它將使其成為父佇列。當我們想要建立父佇列而不配置任何葉佇列時，這非常有用。每個佇列元素可能包含以下屬性：
minResources： 隊 列 有 權 獲 得 的 最 小 資 源
maxResources： 分 配 隊 列 的 最 大 資 源
maxRunningApps： 限 制 隊 列 中 的 應 用 程 序 數 量 一 次 運 行
maxAMShare：限制可用於執行應用程式主伺服器的佇列公平共享的分數。
weight:與其他佇列不成比例地共享群集。權重預設為 1，權重為 2 的佇列應該獲 得 的 資 源 大 約 是 具 有 默 認 權 重 的 隊 列 的 兩 倍 。
schedulingPolicy：設定任意佇列的排程策略。
aclSubmitApps：可以將應用程式提交到佇列的使用者和/或組的列表。
aclAdministerApps：可以管理佇列的使用者和/或組的列表。
3.5.4、佇列設定
1.設定 yarn.resourcemanager.scheduler.class 值為org.apache.hadoop.yarn.server.resourcemanager.scheduler.fair.FaiRegi onServercheduler

3.5.5、Web UI 監控
可以通過 ResourceManager 的 Web 介面在 http：//*ResourceManagerURL*/cluster/scheduler 中檢查當前的應用程式，佇列和公平份額（資源）。
可以在 Web 介面上的每個佇列中看到以下欄位： Used Resources - 分配給佇列中容器的資源總和。
Num Active Applications - 佇列中至少收到一個容器的應用程式數。Num Pending Applications - 佇列中尚未收到任何容器的應用程式數。Min Resources - 保證佇列的最低資源配置。
Max Resources - 允許進入佇列的最大資源配置。
Instantaneous Fair Share - 佇列的瞬時公平份額資源。這些資源僅考慮活動佇列（具有正在執行的應用程式的佇列），並用於排程決策。當其他佇列不使
用佇列時，可以為佇列分配超出其共享的資源。資源消耗等於或低於其瞬時公平份額的佇列將永遠不會搶佔其容器。
Steady Fair Share - 佇列穩定的公平份額資源。這些資源考慮所有佇列，無論它們是否處於活動狀態（已執行應用程式）。這樣，計算就不會很頻繁，而且僅在配置或容量發生變化時才會更改。它們旨在提供使用者可以預期的資源可見性，從而顯示在 Web UI 中。
3.6、資源佇列原則

3.7、資源佇列調整案例
【案例】
xx叢集上的佇列分為生產型和非生產型。在xx日凌晨0 點--早上 9 點，非生產型佇列佔用資源較多，導致叢集壓力過大，影響了當日早上 9 點的 xx 下發。生產側提出了佇列資源的優化方案，如下：
Queue Absolute Capacity Configured Max Capacity
ds 2 3
ec 5 7
db_ser 3 2
hc 80 1.23
default 2 7
zy_scp 5 4
Am1c 3 4
【備份當前佇列的配置檔案】
在 CM 首頁點選 yarn

在 yarn 的【配置】頁面，搜尋“容量排程”，調出右側的【值】

將【值】中的資料全部複製出來備份到本地。建議貼上到寫字板上，貼上到 txt 裡排版會出現混亂。
【修改當前佇列的配置資訊】
以 qc 佇列為例：

【儲存更改】

【重新整理動態資源池】
在 CM 首頁，點選叢集右邊的倒三角，再點選【重新整理動態資源池】

【核實已經修改成功】
在 Applications 頁面的 Scheduler，調出 qc 佇列的資訊

3.8、無CM 修改佇列資源
【需求】
固網叢集 xx 佇列 lf_zl 資源 38%*1.8 拆分
原佇列 lf_zl 改為 25%*2 租戶使用
其餘資源新增佇列 lf_ja 13%*1.8 預計後續部署租戶使用
【修 改 capacity-scheduler.xml】
cd/opt/beh/core/hadoop/etc/hadoop/ #進入配置檔案所在目錄cpcapacity-scheduler.xmlcapacity-scheduler.xml_20170616 #備份配置檔案
vi capacity-scheduler.xml #修改配置檔案
修改 yarn.scheduler.capacity.root.queues 的值，在 value 裡新增 lf_ja

修改原 lf_zl 的值：
把 yarn.scheduler.capacity.root.lf_zl.capacity 的值從 38 改為 25

把 yarn.scheduler.capacity.root.lf_zl.user-limit-facto 的值從 1.8 改為 2

在配置檔案中新增佇列配置檔案，如下：
<property>
<name>yarn.scheduler.capacity.root.lf_ja.capacity</name>
<value>13</value>
<description>default queue target capacity.</description>
</property>

<property>
<name>yarn.scheduler.capacity.root.lf_ja.user-limit-factor</na me>
<value>1.8</value>
<description>
default queue user limit a percentage from 0.0 to 1.0.
</description>
</property>

<property>
<name>yarn.scheduler.capacity.root.lf_ja.maximum-capacity</ name>
<value>100</value>
<description>
The maximum capacity of the default queue.
</description>

</property>

<property>
<name>yarn.scheduler.capacity.root.lf_ja.state</name>
<value>RUNNING</value>
<description>
The state of the default queue. State can be one of RUNNING or STOPPED.
</description>
</property>
<property>
<name>yarn.scheduler.capacity.root.lf_ja.acl_submit_applicatio ns</name>
<value>lf_ja_pro</value>
<description>
The ACL of who can submit jobs to the default queue.
</description>
</property>

<property>
<name>yarn.scheduler.capacity.root.lf_ja.acl_administer_queue
</name>

<value>lf_ja_pro</value>
<description>
The ACL of who can administer jobs on the default

queue.
</description>
</property>
【把更改後的配置檔案拷貝到 stanby 節點】
cp /opt/beh/core/hadoop/etc/hadoop/capacity-scheduler.xml /opt/beh/core/hadoop/etc/hadoop/capacity-scheduler.xml_20170616#登入 stanby 節點備份原配置檔案
scp /opt/beh/core/hadoop/etc/hadoop/capacity-scheduler.xml [email protected]:/opt/beh/core/hadoop/etc/hadoop/capacity-scheduler.xml #把修改後的配置檔案拷貝到備節點主機上
【登入主節點動態重新整理資源池】
yarn rmadmin -refreshQueues#重新整理動態資源池
【登入 yarn 介面檢查更改結果是否正確】
如圖：

3.9、修改使用者yarn 資源分配
hadoop修 改 用 戶yarn隊 列 分 配 倍 數
1.以管理員使用者登入所要更改的 CM，進入後點擊 yarn，如圖：

2.在 yarn 介面點選配置按鈕，並在彈出的查詢框中輸入“容量排程”，查詢如圖：

3.把出現的值貼上到文字留作備份（建議貼上到寫字板上，貼上到 txt 裡排版會出現混亂）切記一定要備份！！！
4.修改所需修改的值（一般限制使用者佇列，建議修改分配的倍數即 Configured User Limit Factor 這個值。修改 Absolute Capacity 需要對整體叢集進行計算，所以使用者加一起的達到百分百，建議不做修改）
5.列：如修改 didi 使用者的 Configured User Limit Factor 值。

（1）登入 yarn，點選 Scheduler，點選 didi 使用者的倒三角圖示：

我們可以看出 didi 使用者的 Configured User Limit Factor 值為 3， 即他可以使用超出他分配百分比的三倍。
（2）修改拷貝中的文字，查詢 didi 配置檔案那列：

(3)找到所需修改的值 Configured User Limit Factor。將倍數修改成需要調整後的值。

（3）把配置檔案拷貝回 CM-yarn-配置-容量排程的那個文字框裡，點選儲存。

（4）回到 CM 主頁，點選叢集右邊的倒三角，點選重新整理動態資源池。

（5）配置完畢，到 yarn 上檢視修改是否成功。
4、排障
4.1、資源問題
【現象】
目前 CC 叢集出現大量任務積壓，執行緩慢的情況，懷疑是叢集的資源分配出現了問題。
CC 叢集總共有 569 個 NodeManager，總共 VCore 數是 27704 ，記憶體171T，資源比較豐富。理論上，應該足夠任務的執行。
經過現場的分析，發現如下現象。
叢集總體的資源使用高，少量剩餘
如下圖所示，叢集總體的資源使用已經非常高，但是仍有少量剩餘。其中 CPU Vcore，總共 27704 個，使用了 26842 個。記憶體總共 171T，使用了153T。即叢集 CPU 使用了 95%以上，但是仍然有少量的剩餘。

佇列最小資源沒有得到滿足
從上圖可以看出，目前配置的佇列最小資源都設定的比較大，即使叢集資源使用非常高，仍然沒有滿足最小資源的需求。佇列最小資源，是叢集有資源的情況下，必須要滿足的資源。並且叢集中，絕大部分佇列都沒有達到最小資源。
出現大量 Map Pening
如下圖所示，叢集中出現大量的任務都有如下的現象。Reduce 已經啟動， 在等待 Map 階段完成，然後向前執行，但是 Map 階段還有部分任務沒有完成， 這部分任務也拿不到資源執行，running 的 map 為 0。從而出現了死鎖的情況。即 Reduce 啟動了佔用了資源，但是在等待 Map，而 Map 拿不到資源無法執行。

【分析】
根據上面的現象，可以分析得出，導致任務出現積壓的情況，直接原因是因為，出現了資源分配的死鎖。即 Reduce 階段佔用了資源，但是需要等待Map 階段執行完成，而 Map 階段在等待資源，但是資源已經被 Reduce 都佔用了，無法申請到資源，因此無法執行。大量的任務都出現了這種情況，叢集中絕大部分的資源都被 Reduce 的 Container 佔用了，而 Map 階段分到的資源很少。
Mapreduce 任務在執行任務時，分為 Map，Reduce 兩個階段，這兩個階段都需要申請 yarn 的 Container，進行執行。並且 Yarn 並不區分 Map，
Reduce 的 Container 型別，只要是申請資源，會一視同仁。Reduce 階段， 需要獲取 Map 階段的輸出，從而繼續往下執行。Yarn 通過引數
mapreduce.job.reduce.slowstart.completedmaps，設定比例，例如設定為0.8（目前叢集設定為 0.8），則 Map 階段完成 80%後，Reduce 階段就會開始申請 Container，佔用資源。提前啟動 Reduce 的好處是，可以儘早的申請到資源，然後 Reduce 首先從已經完成的 Map 任務中拷貝資料，Map 同時執行。從而，加快整體任務的執行。
然而，這個設定，在極端情況下，會出現問題：
1.叢集中存在大量任務同時執行
2.其中不少的任務都需要啟動大量的 Map 任務和 reduce 任務
3.叢集總體的資源使用率已經非常高，沒有很多的剩餘資源
在上述的情況下，就有可能出現資源死鎖的情況。由於大量的任務同時執行，並且其中不少的任務都有大量的 Map 任務和 Reduce 任務，當 Map 任務完成到一定比例之和，就開始啟動 Reduce 任務，Reduce 任務啟動之後， 佔用了資源，但是 Map 還沒有結束。叢集總體的資源使用率已經非常高，沒有很多的剩餘資源，Map 階段分配不到足夠的資源，只能非常緩慢的執行，或者甚至分不到資源，直接不運行了。
整個任務就停滯了，但是也不超時。
另外一個加劇該現象的原因是，因為目前叢集佇列的資源設定中，每個資源池的最小資源佔比設定的比較大，總和已經超過了叢集資源的總和 。
設定佇列的最小資源，是為了保證佇列能夠至少能夠拿到最小資源，不至於被餓死。並且叢集有一定的剩餘資源，可以供資源池之間競爭，作為補充。但是目前的設定，導致即使叢集所有的資源也無法滿足每個佇列的最小資源。這樣的情況，就導致了，叢集的所有資源基本會被使用完，並且關鍵的是，所有的佇列都認為是自己的最小資源。即使某個隊列出現了資源飢餓的情況，也無法從叢集或者其他佇列搶佔部分資源來補充。
【解決方案】
設定 mapreduce.job.reduce.slowstart.completedmaps 為 1
設定為 1 之後，Reduce 需要等待 Map 階段都完成之後，才會申請資源並啟動，這樣的話，就不會出現 Reduce 佔用資源而 Map 分配不到的情況了。
如下圖所示，通過 CM，設定mapreduce.job.reduce.slowstart.completedmaps 為 1。同時，原來設定預設 reduce 個數為 600， 這個值偏大，修改為 40。

重新調整資源池的設定
重新調整各資源池，最小資源，最大資源，以及併發任務數。
建議調整所有資源池的最小資源為叢集資源的 60%。最大資源為叢集資源的 100%。
【整體修改】

NodeManager 記憶體調整
如下圖所示，目前叢集 NodeManager 記憶體為 2G，對於一個比較繁忙， 並且規模很大的叢集，NodeManager 記憶體建議可以設定的稍微大一點，下圖修改成 4G。

【控制Map 數】
可以通過設定 mapreduce.input.fileinputformat.split.minsize 引數來控制任務的 Map 數，該引數控制每個 map 的最小處理資料量。
在 hive 中可以通過 set mapreduce.input.fileinputformat.split.minsize=67108864 來設定
4.2、慢作業
在 AA 叢集中存在部分任務，執行較慢的情況。這些任務都是比較長的 hiveSQL，處理的資料量並不是很大，在幾個 G 左右，但是執行時間很長，需要 40 分鐘到一個小時。
經過分析，這些任務的 map 階段其實執行的很快，幾十秒就能結束，慢主要是發生在 Reduce 階段，Reduce 需要花費幾十分鐘才能執行完成。檢視Reduce 階段日誌發現，Reduce 寫出了大量的日誌，約有 1G，並且這些日誌都像是從表中獲取的資料進行的列印。正常 Hive 是不會輸出這些日誌的，只有應用端進行了設定才會進行列印。
出現這種情況，最有可能的是使用 Java 程式碼編寫了 Hive 的 UDF 程式，在UDF 中進行了列印，並且在 hive SQL 中使用了 UDF，從而列印了這些日誌。經與生產側 xxx 溝通，確認使用了 UDF，應用正在確認相關程式碼，並進行下一步解決。
4.3、gc overhead limit exceeded 導致map 失敗
【現象】
xx日，4m1-01 叢集上的多個 job 執行失敗。

【定位失敗的 map task】

【檢視失敗的 map tasks 的日誌】

發現第 3 次 task attempt 有一條 FATAL 型的報錯： java.lang.OutOfMemoryError: GC overhead limit exceeded

【確認末端原因】
JVM 的堆疊過小，導致 job 執行失敗。
【解決辦法】
可以調整JVM的堆疊大小，但是目前沒有標準可供參考去調整JVM。而且這種報錯的頻率不高，所以只能建議業務方再多次執行 job，或改在資源較空閒的時間段執行 job。事實證明，這種辦法是可行的。
最佳方案：適當調大 mapreduce.map.memory.mb 這個引數的值
4.4、hive 執行任務中報記憶體不足的錯誤

執行 hive 前加上引數
set mapresuce.reduce.shuffle.input.buffer.percent=0.1;
set mapred.child.java.opts=-Xmx3096m; // jvm 啟動的子執行緒可以使用的最大記憶體
set mapreduce.reduce.shuffle.parallelcopies=10;// reuduce shuffle 階段並行傳輸資料的數量
export HADOOP_CLIENT_OPTS="-Xmx8192m $HADOOP_CLIENT_OPTS
4.5、Job 報錯失敗
使用者反映 JOB 執行失敗報錯，如下：

懷疑為沒有此目錄許可權
查詢該目錄下許可權正常，但並無 mapred-audit.log 檔案，其他介面機有此檔案。

新增此檔案：

4.6、NameNode RPC 負載過高
【現象】
基於小檔案問題與 XXX 和 XXX 瞭解多租戶初篩程式問題，發現初篩程式 URLFilter_Hour_Tenants 在執行之前會獲取檔案資訊，獲取檔案資訊需要 2 至 5 小時才能完成。
【問題排查】
1、目前處理 HHH 日誌的程式有如下： YX：凌晨 1 點分省處理昨天一天的資料
2、HHH 日誌初篩，按小時處理省份資料，rpc 請求為 31 萬，缺點：每小時每個省份的作業處理卻要掃描當天此省份全量檔案資訊，造成大量無用的 rpc 請求
3、Spark streaming 實時採集原始日誌，目前是增量獲取檔案資訊，對 rpc 的壓力影響較小
HHH 日誌初篩現象：
Job 輸入目錄有 31 萬的檔案，這個任務讀取整個資料夾其中的 1.4 萬的檔案。如下截圖是初篩 job 的 rpc 請求，請求次數為 310172，從日誌上看每秒鐘併發十幾次到幾十次，耗時 3 個半小時，併發度太低的原因是因為 rpc 請求佇列堆積了很多請求

昨天晚上 23 點到今天凌晨 2 點的時候，rpc 佇列累積請求長度較高

昨天晚上 23 點到今天凌晨 2 點的時候，rpc 平均請求時長偏高

【解決方案】
1、HHH 多租戶初篩程式由原來的 MR 批處理改為 spark streaming 實時採集處理，降低 rpc 負載，XXX 協助 XXX、XXX、XXX 改造程式
2、spark streaming 資料直接輸出到租戶對應目錄，省去 mv 環節
3、預計兩週上線，上線前需做程式碼、流程評審
4.7、SRC 層分鐘表hive 入庫延遲排查
【現象】
XXLL 分鐘表 load 存在異常，平臺支撐組牽頭排查 XXLLSRC 層分鐘表 hive 入庫延遲問題。
【問題排查】
Hive 錯誤日誌
異常出現次數：大概 595 次
異常資訊：
2019-04-27 01:38:41，484 ERROR ZooKeeperHiveLockManager (SessionState.java:printError(920)) - Unable to acquire IMPLICIT， EXCLUSIVE lock lf_xl_src@src_c_sa_basic_normal after 100 attempts. 2019-04-27 01:38:41，506 ERROR ql.Driver
(SessionState.java:printError(920)) - FAILED: Error in acquiring locks: Locks on the underlying objects cannot be acquired. retry after some time
org.apache.hadoop.hive.ql.lockmgr.LockException: Locks on the underlying objects cannot be acquired. retry after some time
at org.apache.hadoop.hive.ql.lockmgr.DummyTxnManager.acquireLocks( DummyTxnManager.java:164)
at org.apache.hadoop.hive.ql.Driver.acquireLocksAndOpenTxn(Driver.java: 988)
at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1224) at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1053)
at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1043) at
org.apache.hadoop.hive.cli.CliDriver.processLocalCmd(CliDriver.java:20 9)
at org.apache.hadoop.hive.cli.CliDriver.processCmd(CliDriver.java:161) at org.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:372) at org.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:307) at org.apache.hadoop.hive.cli.CliDriver.executeDriver(CliDriver.java:704) at org.apache.hadoop.hive.cli.CliDriver.run(CliDriver.java:677)
at org.apache.hadoop.hive.cli.CliDriver.main(CliDriver.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorI mpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethod AccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.hadoop.util.RunJar.run(RunJar.java:221)
at org.apache.hadoop.util.RunJar.main(RunJar.java:136)

Hive 鎖
檢視鎖：

鎖擁有者：
> show locks src_c_sa_basic_normal extended;
OK
lf_xl_src@src_c_sa_basic_normal SHARED LOCK_QUERYID:lf_xl_bp_20190427164141_acb414ff-d237-414b-a778-5 ef916724c04
LOCK_TIME:1524818467680 LOCK_MODE:IMPLICIT
LOCK_QUERYSTRING:insert overwrite table lf_xl_dwd.dwd_d_sa_basic_n ormal_hour partition(month_id='201904'，day_id='27'，hour_id='15'， prov_id='075'，sa_type)
select msisdn ， imsi ，

start_time ， end_time ， imei ，
mcc ，
mnc ， current_lac， current_ci ， roamtype ， eventtype ， rantype ， province ，
fiRegionServert_lac ， fiRegionServert_ci ， latitude ，
longitude ， area ，
hrov_id ， harea_id， rmsisdn， rimsi， srvstat ，
cdRegionServertat ，

direction ，
srvorig ，
srvtype ， poweroff_ind ， csfb_res ，
enodebid ， ci ，
destnet_type ， sourcenet_type， uenc ，
msnc ，
res_time ，
msg_id ， cause_code， district_id， hcountry， is_filled， recv_time， sa_type
from lf_xl_src.src_c_sa_basic_normal
where date_id='20190427' and hour_id='15' and prov_id='075' and no

t(imsi='' and msisdn='') and not(imsi regexp '\\D' or msisdn regexp '\\ D')
hive目前主要有兩種鎖，SHARED（共享鎖 S）和 Exclusive（排他鎖 X）。共享鎖 S 和 排他鎖 X 它們之間的相容性矩陣關係如下：

Zookeeper 日誌
Hive 獲取 lock 失敗：

日誌條數：

Znode 結構：

程序堆疊：

程序堆疊資訊：
"main" prio=10 tid=0x00007fdf7c012800 nid=0x772f waiting on condi tion [0x00007fdf85b23000]
java.lang.Thread.State: TIMED_WAITING (sleeping) at java.lang.Thread.sleep(Native Method)
at org.apache.hadoop.hive.ql.lockmgr.zookeeper.ZooKeeperHiveL ockManager.lock(ZooKeeperHiveLockManager.java:268)
at org.apache.hadoop.hive.ql.lockmgr.zookeeper.ZooKeeperHiveL ockManager.lock(ZooKeeperHiveLockManager.java:182)
at org.apache.hadoop.hive.ql.lockmgr.DummyTxnManager.acquir eLocks(DummyTxnManager.java:161)
at org.apache.hadoop.hive.ql.Driver.acquireLocksAndOpenTxn(Dri ver.java:988)
at org.apache.hadoop.hive.ql.Driver.runInternal(Driver.java:1224) at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1053)
at org.apache.hadoop.hive.ql.Driver.run(Driver.java:1043)
at org.apache.hadoop.hive.cli.CliDriver.processLocalCmd(CliDriver. java:209)
at org.apache.hadoop.hive.cli.CliDriver.processCmd(CliDriver.java:161)
at org.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:372)
at org.apache.hadoop.hive.cli.CliDriver.processLine(CliDriver.java:307)
at org.apache.hadoop.hive.cli.CliDriver.executeDriver(CliDriver.java:704)
at org.apache.hadoop.hive.cli.CliDriver.run(CliDriver.java:677) at org.apache.hadoop.hive.cli.CliDriver.main(CliDriver.java:617)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(Delegating MethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:606) at org.apache.hadoop.util.RunJar.run(RunJar.java:221)
at org.apache.hadoop.util.RunJar.main(RunJar.java:136)
【目前解決方案】
取消 load 操作，改為 cp 操作，檢測 hdfs 檔案修復 hive 分割槽。
【其他問題】
強制殺死 kafka 消費者：

每秒中週期提交 offset

4.8、大資料作業JVM 記憶體崩潰 1
【現象】
今天 XXX 反饋在介面機 XXX 上做 hdfs dfs -mv（同時執行 150 個 mv）操作的時候出現了大量的類似 hs_err_pid10147.log（10147 代表 java 程序號）這樣的檔案，這個檔案是 java 的致命錯誤日誌，程序會直接崩潰。
【問題排查】
檢視日誌
hs_err_pid10147.log 中關鍵日誌如下，或者是記憶體不足或者是 java 不能建立新的執行緒（即在系統層面限制了程序或執行緒建立的資料量）
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Cannot create GC thread. Out of system resources. # Possible reasons:
# The system is out of physical RAM or swap space # In 32 bit mode， the process size limit was hit
# Possible solutions:
# Reduce memory load on the system
# Increase physical memory or swap space # Check if swap backing store is full
# Use 64 bit Java on a 64 bit OS
# Decrease Java heap size (-Xmx/-Xms)
# Decrease number of Java threads
# Decrease Java thread stack sizes (-Xss)
# Set larger code cache with -XX:ReservedCodeCacheSize= # This output file may be truncated or incomplete.
#
# Out of Memory Error (gcTaskThread.cpp:48)， pid=14974， tid=0x00007fcbeaf75700
#
# JRE veRegionServerion: (8.0_161-b12) (build )
# Java VM: Java HotSpot(TM) 64-Bit Server VM (25.161-b12 mixed mode linux-amd64 compressed oops)
# Failed to write core dump. Core dumps have been disabled. To enable core dumping， try "ulimit -c unlimited" before starting Java again
#

確實是 hdfs mv 的 java 程序崩潰
VM Arguments:
jvm_args: -Dproc_dfs -Xmx1000m
-Dhadoop.log.dir=/opt/cloudera/parcels/CDH-5.13.1-1.cdh5.13.1.p0.2/ lib/hadoop/logs -Dhadoop.log.file=hadoop.log
-Dhadoop.home.dir=/opt/cloudera/parcels/CDH-5.13.1-1.cdh5.13.1.p0.2/lib/hadoop -Dhadoop.id.str= -Dhadoop.root.logger=INFO，console
-Djava.library.path=/opt/cloudera/parcels/CDH-5.13.1-1.cdh5.13.1.p0.2/lib/hadoop/lib/native -Dhadoop.policy.file=hadoop-policy.xml
-Djava.net.preferIPv4Stack=true -Djava.net.preferIPv4Stack=true
-Dhadoop.security.logger=INFO，NullAppender java_command: org.apache.hadoop.fs.FsShell
-mv hdfs://10.244.12.214:8020/serv/smartsteps/raw/events/locationev ent/2019/05/15/011/000150_0.gz hdfs://10.244.12.214:8020/serv/smartsteps/raw/events/locationevent/2019/05/15/011/./CD051201010101ASMARTSTEPS1805151000170000151.011.gz

當時的記憶體還很大：
------------ S Y S T E M ---------------
OS:CentOS Linux release 7.2.1511 (Core)
uname:Linux 3.10.0-327.el7.x86_64 #1 SMP Thu Nov 19 22:10:57 UTC
2015 x86_64
libc:glibc 2.17 NPTL 2.17
rlimit: STACK 8192k， CORE 0k， NPROC 4096， NOFILE 65535， AS
infinity
load average:46.84 11.88 4.02
/proc/meminfo:
MemTotal: 131464872 kB
MemFree: 107818664 kB
MemAvailable: 125719212 kB
BuffeRegionServer: 2220 kB
Cached: 17496468 kB
SwapCached: 0 kB
Active: 10411796 kB
檢視某個 java 程序堆疊資訊，因為記憶體足夠故推斷是第二種可能（黃色）
#
# There is insufficient memory for the Java Runtime Environment to continue.
# Cannot create GC thread. Out of system resources. # Possible reasons:
# The system is out of physical RAM or swap space # In 32 bit mode， the process size limit was hit

【解決方案】
使用者可以啟動的最大程序或執行緒數之前配置的是 1024，修改為 65535，在重新執行 150 個 mv 操作時正常
4.9、大資料作業JVM 記憶體崩潰 2
【現象】
今天 XXX 反饋在介面機 XXX 上做 hdfs dfs -mv（同時執行 150 個 mv）操作的時候出現了大量的類似 hs_err_pid3780.log（3780 代表 java 程序號）這樣的檔案，這個檔案是 java 的致命錯誤日誌，程序會直接崩潰。
【排查問題】
檢視日誌
jvm 某個錯誤日誌在 14:02 生成，需要使用 352321536 byte = 344064k 的記憶體

但是那時系統只剩下 342824k 記憶體，小於 344064k 的記憶體，故 jvm 崩潰，總結為：記憶體不足

【解決方案】
伺服器擴記憶體或降低任務併發
4.10、叢集作業資料傾斜任務排查
【現象】

作業監控發現作業存在資料傾斜

【問題排查】
在 YARN 監控頁面檢視作業資訊檢視 yarn 監控頁面，此 job 共有 1009 個 reduce， 絕大部分 reduce 都是空跑沒有處理資料

下面看一個執行時間很長的 reduce， 大概 18 個多小時

此 reduce 處理的資料量為：86.99 億條

下面看一個執行時間短的 reduce， 大部分都在 3 分鐘以內

處理的資料量為 0