Yarn管理放置規則
這是CDP中Yarn使用系列中的一篇,之前的文章請參考<使用YARN Web UI和CLI>、<CDP 中配置Yarn的安全性>、<CDP的Yarn資源排程與管理>、<CDP中Yarn管理佇列>、<Yarn在全域性級別配置排程程式屬性>和<Yarn配置每個佇列屬性>。
放置規則可以定義在指定應將哪個佇列用於提交的作業時考慮的邏輯。這些預定義規則使您可以在提交作業時無需指定佇列名稱即可提交作業。
有兩種佇列可以提交作業:
靜態佇列:始終存在且由使用者使用佇列管理器 UI(或配置檔案)定義的佇列。
動態佇列:當作業提交給它們時動態建立的佇列。如果 YARN 服務重新啟動,它們將被自動刪除。要了解有關動態佇列的更多資訊,請參閱管理動態佇列。
放置規則使您能夠定義提交作業時應用的邏輯,以指定應將哪個佇列用於提交的作業。這使您可以在不定義目標佇列的情況下提交作業,甚至可以覆蓋提交者在作業提交期間指定的目標佇列。
預設情況下,只有在作業提交期間未指定目標佇列或指定的目標佇列作為“預設”提供時,才會考慮放置規則。要更改此行為,請參閱啟用預設佇列對映的覆蓋。
放置規則按照它們在放置規則列表中出現的順序進行評估。當提交作業並且必須考慮放置規則時,將對規則進行評估,並使用第一個匹配規則來確定作業執行的佇列。
如果在作業提交過程中沒有放置規則且未指定目標佇列,則作業將提交到排程程式的預設佇列。
如果放置規則的目標佇列不存在或無法建立,則執行配置的回退操作。您可以為每個放置規則配置回退操作,它可以具有以下值:
跳過:忽略當前規則並繼續下一個。
PlaceDefault:將應用程式放置到預設佇列 root.default(除非它被其他東西覆蓋)。
拒絕:拒絕提交。
如果在作業提交過程中沒有指定目標佇列,並且沒有與作業匹配的放置規則,則將作業提交到排程程式的預設佇列。
預設情況下,如果在作業提交期間指定了無效佇列,則提交將被拒絕。要更改此行為,請參閱啟用預設佇列對映的覆蓋。
重要
儘管可以使用安全閥配置片段來配置放置規則,但 Cloudera 建議使用 YARN 佇列管理器 UI 進行放置規則配置和管理,即使這會導致一些限制。尤其重要的是不要使用安全閥配置片段來設定舊的放置規則策略格式。您必須使用新的基於 JSON 的放置規則格式。
放置規則策略
建立放置規則時,您必須設定其策略。您可以選擇許多預定義的策略,也可以建立自定義策略。
重要
在引用佇列時,Cloudera 建議始終提供父佇列。雖然,在容量排程程式中,您只能通過葉佇列名稱來引用佇列,但如果有更多具有相同名稱的葉佇列,則可能會導致問題。提供父佇列可確保將引用轉換為完全限定的路徑,即不會有歧義。
下表列出了策略的名稱、佇列管理器 UI 的“放置規則建立”對話方塊中顯示的選項及其詳細說明:
表 1.放置規則策略
策略 |
佇列管理器使用者介面 |
描述 |
---|---|---|
使用者 |
將應用程式放入以使用者命名的佇列中。 |
將應用程式放入與提交者使用者名稱匹配的佇列中。 |
主要組 |
將應用程式放入以使用者的主要組命名的佇列中。 |
將應用程式放入與提交者的主要組匹配的佇列中。 |
主要組使用者 |
將應用程式放入以使用者命名的佇列中,該使用者是以使用者的主要組命名的佇列的子級。 |
將應用程式放入佇列層次結構中 [parentQueue].<primaryGroup>.<userName>。parentQueue 是可選的。 |
次要組 |
將應用程式放入以使用者的次要組命名的佇列中。 |
將應用程式放入與提交者的次要組匹配的佇列中。 |
次要組使用者 |
將應用程式放入以使用者命名的佇列中,該使用者是為使用者的次要組命名的佇列的子級。 |
將應用程式放入佇列層次結構中 [parentQueue].<secondaryGroup>.<userName>。parentQueue 是可選的。 |
應用名稱 |
將應用程式放入以應用程式命名的佇列中。 |
將應用程式放入與應用程式名稱匹配的佇列中。 重要的 它區分大小寫,不會刪除空格。 |
指定 |
將應用程式放入執行時指定的佇列中。 |
將應用程式置於提交期間定義的佇列中。 |
拒絕 |
拒絕申請。 |
拒絕提交。 |
預設佇列 |
將應用程式放入預設佇列。 |
將應用程式放入預設佇列 root.default 或其覆蓋值。 |
設定預設佇列 |
將預設佇列設定為: |
從 root.default 更改預設佇列。 此策略不會永久更改預設佇列。當提交申請時開始評估時,它始終是“root.default”。 但是,調整後的預設佇列將一直有效,直到放置規則評估完成。 |
Custom |
使用以下自定義策略: |
使使用者能夠使用自定義放置字串。 |
自定義放置策略
該custom放置策略可以描述與相應的變數佔位符的其他策略。例如,primaryGroupUser 與父佇列root.groups可以表示為:root.groups.%primary_group.%user
如果您打算使用該策略,自定義策略變量表描述了哪些變數可用custom。
在內部,該工具使用適當的值填充某些變數。如果custom選擇了對映策略,則可以使用這些。放置規則評估引擎在替換它們時只進行最少的驗證。因此,您有責任提供正確的字串。
表 2.自定義策略變數
變數 |
意義 |
---|---|
%application |
提交的應用程式的名稱。 |
%default |
排程程式的預設佇列。 |
%primary_group |
提交者的主要群體。 |
%secondary_group |
提交者的次要(補充)組。 |
%specified |
包含提交者定義的佇列。 它是一個獨立變數,請勿將其與其他自定義變數或路徑結合使用。 如果指定的目標佇列是default這個變數,則不會設定。如果目標佇列是 default佇列,則應指定root.default父路徑。 |
%user |
提交申請的使用者。 |
如果將 MapReduce 應用程式提交到佇列root.users.mrjobs,則值%specified將設定為 root.users.mrjobs。
很少有策略可以實現custom。您可以使用custom該將customPlacement欄位設定為%specified,而不是使用該specified策略。
但是,您可以對其進行更多控制,因為您還可以向這些變數附加或預先新增一個額外的字串。因此可以進行以下設定:root.groups.%primary_group.admins.%user.longrunningjobs
該字串必須解析為有效的佇列路徑才能正確放置。
傳統模式和權重模式之間的差異
在某些情況下,傳統資源分配模式(絕對和相對模式)的行為與權重模式不同。
該create標誌
傳統模式:如果父級不受管理,則無效。
權重模式:適用於所有父佇列。但是,如果 yarn.scheduler.capacity.<queue-path>.auto-queue-creation-v2.enabled 設定為false,則不會建立佇列。
巢狀規則primaryGroupUser和 secondaryGroupUser
傳統模式:他們希望父佇列存在,這意味著它們不能自動建立。更具體地說,當你使用primaryGroupUser它時會導致一個類似於父佇列的佇列路徑,root.<primaryGroup>.<userName>並且root.<primaryGroup>父佇列必須存在。它可以是託管父級,以便 userName自動建立葉,但仍必須手動建立父級。
權重模式:只要父級允許建立動態佇列,就沒有限制。將建立請求的佇列。
如何閱讀放置規則表
在佇列管理器 UI 中,您可以在一頁上檢視所有放置規則。瞭解此頁面可以幫助您根據需要管理放置規則。
如果您選擇佇列管理器 UI,然後轉到放置規則選項卡,則放置規則概覽頁面將顯示在 Cloudera Manager 中 。它顯示一個包含以下列的表格:
表 1.放置規則概覽頁面
列名 |
描述 |
---|---|
Order |
從上到下評估放置規則。此列提供放置規則的順序。 |
Type |
向引擎指示當前規則應該匹配的物件:應用程式、使用者或組。 值:Application, Users, Group |
Match |
要匹配的字串,或表示“全部”的星號“*”。例如,如果型別為 User 且此字串為“hadoop”,則僅當提交者使用者為“hadoop”時才會評估規則。“*”不適用於組。 |
Policy |
定義應用程式放置位置的預定義或自定義策略。 值:User, PrimaryGroup, PrimaryGroupUser, SecondaryGroup, SecondaryGroupUser, ApplicationName, Specified, Reject, DefaultQueue, SetDefaultQueue,Custom |
Parent Queue |
在的情況下User,PrimaryGroup, PrimaryGroupUser,SecondaryGroup,和 SecondaryGroupUser策略,這告訴其中,匹配佇列應該尋找引擎。例如,如果策略是PolicyGroup,父是root.groups並且提交的組是“admin”,那麼結果佇列將是:root.group.admin |
Custom Value |
它可以有兩種型別的值:
|
建立佇列? |
它設定create標誌,它在重量和傳統模式下的工作方式不同。 如果設定為No,則放置策略確定的目標佇列如果不存在則不會建立。這意味著不會發生動態自動子建立。 但是,即使設定為Yes它仍然不能保證佇列會被建立。您還必須確保為指定的父佇列啟用了動態自動子建立功能。 以下策略不支援該create 標誌:
|
Fallback |
如果目標佇列不存在或無法建立,則定義回退操作。 值:Skip, PlaceDefault, Reject |
Actions |
單擊適用的圖示以對放置規則執行操作:
|
建立放置規則
放置規則確定應用程式和作業分配到的佇列。您可以使用 YARN 佇列管理器 UI 建立放置規則。
如果放置規則使用靜態佇列,則必須先建立目標葉佇列,然後再建立使用它的放置規則。建立放置規則時,UI 將顯示所有現有葉佇列。
如果放置規則使用動態建立的佇列,您必須在建立使用它的放置規則之前為目標父佇列啟用動態自動子建立功能。建立規則時,UI 將顯示所有現有佇列作為目標父佇列選項,但如果未為所選佇列啟用動態自動子建立功能,則會顯示警告訊息,您無法建立放置規則。有關更多資訊,請參閱管理動態佇列。
在 Cloudera Manager 中,選擇YARN Queue Manager UI。
圖形佇列層次結構顯示在概覽 選項卡中。
轉到放置規則選項卡。
單擊+ 新增。
在新增放置規則對話方塊dsiplayed使用預設設定,或與是您所建立的最後位置規則的精確副本設定。
設定您希望規則匹配的應用程式引數:
規則應匹配應用程式:設定與此規則匹配的應用程式引數。
此規則應匹配:設定與此規則匹配的值。
設定當應用程式匹配時規則應該做什麼。
匹配應用程式時,請執行以下操作:設定放置規則策略。
設定應提交作業的佇列的父級。
放置應用程式的佇列的父佇列應該是:從下拉列表中選擇一個可用的父佇列。
重要的
Cloudera 建議在父佇列是可用屬性時始終設定它,即使它只是可選的。這樣可以避免同名葉子佇列引起的問題。
如果要建立目標佇列,如果它不存在選擇如果不存在則 建立目標佇列?複選框。要啟用此功能,您必須在步驟 6 中設定一個父佇列。
注意
如果您希望建立不存在的目標佇列,則必須為您選擇的父佇列啟用動態自動子建立功能。
設定回退動作。
檢查您的放置規則設定。
注意
建立放置規則後,您將無法對其進行編輯。如果您想更改放置規則的設定,您必須刪除它,然後使用正確的值重新建立它。
單擊“確定”。
提供更改的說明,然後單擊“確定”。
該規則將新增到放置規則列表的底部,併成為要評估的最後一個規則。
示例 - 建立放置規則
您必須設定放置規則以滿足您的特定需求。在此示例中,開發人員、QA 工程師和測試開發人員共享一個叢集,您要設定九個放置邏輯。
以下是建立放置規則時要實現的放置邏輯:
如果使用者屬於devs主要組,則應將應用程式放置到root.users.devs。這是為開發人員保留的。
如果使用者屬於qa主要組,則應用程式應轉到root.users.lowpriogroups.<primaryGroup>。這些佇列的容量較低,供測試人員使用。
如果使用者屬於qa-dev主要組,則應用程式應轉到root.users.highpriogroups.<primaryGroup>。這些佇列具有更高的容量,供測試開發人員使用。
將應用程式放入與使用者名稱匹配的佇列中。
如果沒有這樣的佇列,則從應用程式提交上下文中獲取該佇列,但如果該佇列不存在且父級被管理,則不應建立該佇列。
如果以上都不匹配,則應將應用程式放入 root.default佇列中。
如果預設放置失敗,請將預設佇列更改為 root.users.default。
再次嘗試放置到預設佇列。
如果失敗,則完全拒絕提交。
使用佇列管理器 UI,可以通過以下方式實現此邏輯:
佇列層次結構
名稱旁邊帶有螺栓標誌的佇列是啟用了動態自動子建立的父項。
放置規則概述
重新排序放置規則
放置規則按照它們在放置規則列表中出現的順序進行評估。提交作業時,會評估規則,並使用第一個匹配規則來確定執行作業的佇列。
提交作業時,會從上到下評估規則,使用第一個匹配規則來確定作業執行的佇列。
如果始終滿足某個規則,則不會評估後續規則。預設情況下,放置規則按新增順序排列;首先新增的規則首先出現。您可以輕鬆地重新排序規則。
在 Cloudera Manager 中,選擇 YARN Queue Manager UI。
圖形佇列層次結構顯示在概覽 選項卡中。
轉到放置規則選項卡。
顯示放置規則列表。
單擊重新排序。
僅當您至少有兩個放置規則時,重新排序選項才可用。
單擊規則行中的上移和下移箭頭按鈕。
單擊儲存重新排序。
刪除放置規則
YARN 佇列管理器 UI 使您能夠刪除以前建立的放置規則。如果要刪除與放置規則關聯的佇列,首先必須刪除其關聯的放置規則。
在 Cloudera Manager 中,選擇 YARN Queue Manager UI。
圖形佇列層次結構顯示在概覽 選項卡中。
單擊放置規則選項卡。
顯示放置規則列表。
在操作列中,單擊要刪除的放置規則所在行中的Bin 圖示。
點選儲存。
啟用覆蓋預設佇列對映
預設情況下,僅當在作業提交期間未指定目標佇列時才考慮放置規則。您可以更改該行為以考慮放置規則是否在作業提交時指定了目標佇列。
該yarn.scheduler.capacity.queue-mappings-override.enable屬性控制何時考慮放置規則。在 YARN 佇列管理器 UI 中,此屬性稱為Override Queue Mapping。預設情況下,該屬性設定為 false,這意味著該功能被禁用並且放置規則無法覆蓋在作業提交時指定的目標佇列。
下表顯示瞭如何指定在不同場景下作業應使用哪個佇列:
表 1.目標佇列規範場景
覆蓋佇列對映 |
在作業提交時指定目標佇列? |
放置規則存在嗎? |
最終結果 |
---|---|---|---|
已禁用(設定為 false) |
是的 |
是的 |
作業被提交到提交者指定的佇列。 |
已禁用(設定為 false) |
是的 |
不 |
作業被提交到提交者指定的佇列。 |
已禁用(設定為 false) |
不 |
是的 |
放置規則指定目標佇列。 |
已禁用(設定為 false) |
不 |
不 |
作業被提交到排程程式的預設佇列 ( root.default)。 |
已啟用(設定為 true) |
是的 |
是的 |
放置規則指定目標佇列。 |
已啟用(設定為 true) |
是的 |
不 |
作業被提交到提交者指定的佇列。 |
已啟用(設定為 true) |
不 |
是的 |
放置規則指定目標佇列。 |
已啟用(設定為 true) |
不 |
不 |
作業被提交到排程程式的預設佇列 ( root.default)。 |
當放置規則覆蓋作業提交時定義的目標佇列時,如果使用specified放置規則策略,仍然可以考慮指定的佇列。有關詳細資訊,請參閱放置規則策略。
在 Cloudera Manager 中,選擇 YARN Queue Manager UI。
圖形佇列層次結構顯示在概覽 選項卡中。
轉到排程程式配置選項卡。
找到 覆蓋佇列對映屬性。預設情況下它是禁用的。
選中該框以啟用此功能。
點選儲存。
提供更改的說明,然後單擊“確定”。
即使在作業提交期間指定了目標佇列,也會考慮放置規則。
原文連結:https://docs.cloudera.com/cdp-private-cloud-base/latest/yarn-allocate-resources/topics/yarn-placement-rules.html
本文分享自微信公眾號 - 大資料雜貨鋪(bigdataGrocery)。
如有侵權,請聯絡 [email protected] 刪除。
本文參與“OSC源創計劃”,歡迎正在閱讀的你也加入,一起分享。
- Yarn管理放置規則
- Yarn在全域性級別配置排程程式屬性
- 使用YARN Web UI和CLI
- CDP中的Hive3系列之管理Hive的工作負載
- CDP中的Hive3系列之啟動Apache Hive3
- Hive on Tez 簡介
- CDP私有云基礎7.1.7發行說明
- CDP的Hive Metastore簡介
- FAQ系列之Impala
- CDP私有云基礎版7.1.6版本概要
- CDP通過支援谷歌雲擴充套件了混合雲的支援
- 教程|運營資料庫 Phoenix SQL:在CDP公有云上使用HBase、Nifi和Kafka
- 下一站–建立從邊緣到洞察的資料管道
- 配置客戶端以安全連線到Apache Kafka叢集4:TLS客戶端身份驗證
- 配置客戶端以安全連線到Kafka叢集–LDAP
- NiFi –混合雲環境中的資料移動賦能者
- 有關Apache NiFi的5大常見問題
- 使用YCSB進行HBase效能測試
- Cloudera Manager主機管理
- 使用CFM進行日誌減少技術