細(xì)粒度資源管理的背景

目的

Flink 目前采用粗粒度的資源管理方法，其中task被部署到預(yù)定義的、通常相同的slot中顷扩，而不需要每個包含多少資源的概念火邓。使用slot共享飞崖，可以將同一slot共享組 (SSG)中的task部署到一個slot中烂叔，而不管每個task/operator需要多少資源。在FLIP-56中固歪，我們提出了細(xì)粒度資源管理蒜鸡，它根據(jù)工作負(fù)載的資源需求，利用具有不同資源的slot來執(zhí)行task牢裳。

對于許多job來說逢防，使用粗粒度的資源管理并將所有task簡單地放在一個 SSG 中就足夠了，無論是在資源利用率還是可用性方面蒲讯。

• 對于所有task都具有相同并行度的許多流式j(luò)ob忘朝，每個slot將包含一個完整的pipeline。理想情況下判帮，所有pipeline應(yīng)該使用大致相同的資源辜伟，這可以通過調(diào)整相同slot的資源輕松滿足。
• task的資源消耗隨時間而變化脊另。當(dāng)一個task的消耗減少時，額外的資源可以被另一個消耗增加的task使用约巷。這被稱為削峰填谷效應(yīng)偎痛，減少了所需的整體資源。

但是独郎，在某些情況下踩麦，粗粒度的資源管理不能很好地工作。

• task可能有不同的并行度氓癌。有時谓谦，無法避免這種不同的并行性。例如贪婉，source/sink/lookup task的并行性可能會受到外部上游/下游系統(tǒng)的分區(qū)和 IO 負(fù)載的限制反粥。在這種情況下，具有較少task的slot將比具有整個task pipeline的slot需要更少的資源疲迂。
• 有時才顿，整個pipeline所需的資源可能太多，無法放入單個slot/task管理器中尤蒿。在這種情況下郑气，pipeline需要拆分為多個 SSG，它們可能并不總是具有相同的資源需求腰池。
• 對于批處理job尾组，并非所有task都可以同時執(zhí)行忙芒。因此，pipeline的瞬時資源需求隨時間而變化讳侨。

嘗試使用相同的slot執(zhí)行所有task可能會導(dǎo)致非最佳資源利用率呵萨。相同slot位的資源必須能夠滿足最高資源要求，這對于其他要求將是浪費的爷耀。當(dāng)涉及到 GPU 等昂貴的外部資源時甘桑，這種浪費會變得更加難以承受。
因此歹叮，需要細(xì)粒度的資源管理跑杭，利用不同資源的slot來提高這種場景下的資源利用率。

現(xiàn)狀

目前咆耿，F(xiàn)LIP-56 中提出的大部分slot分配和調(diào)度邏輯已經(jīng)實現(xiàn)德谅，除了一個仍在進(jìn)行中的slot管理器插件（FLINK-20835）。主要缺失的部分是用于指定job資源需求的用戶接口萨螺。

有一些古老的代碼用于設(shè)置轉(zhuǎn)換算子資源并聚合它們以生成slot請求窄做。但是，這些代碼從未真正使用過慰技，也沒有向用戶公開 API椭盏。最重要的是，我們不確定讓用戶指定operator級別的資源需求并在運(yùn)行時聚合它們是正確的方法吻商，這將在后續(xù)部分中討論掏颊。

范圍

image.png

此 FLIP 提出了基于slot共享組 (SSG) 的運(yùn)行時接口，用于指定細(xì)粒度的資源需求艾帐。具體來說乌叶，我們討論了如何在Transformation層指定資源需求并在之后加以利用，這涵蓋了 Table/SQL API 和 DataStream API 工作負(fù)載的公共路徑柒爸。

由于以下原因准浴，用于指定資源要求的最終用戶接口被排除在本 FLIP 的范圍之外。

• 細(xì)粒度的資源管理不是端到端的捎稚。我們認(rèn)為這應(yīng)該是通過公開用戶 API 來激活該功能的最后一步乐横。
• 不同的開發(fā) API 可能會以不同的方式公開用于指定資源需求的接口。它需要與組件專家進(jìn)行更深入的討論阳藻，以決定開發(fā) API 應(yīng)如何集成此功能晰奖。以下示例只是一些初步想法，用于演示用戶接口在不同開發(fā) API 中的外觀腥泥。
  • 對于DataStream API匾南，已經(jīng)有為算子設(shè)置SSG的接口』淄猓基于此蛆楞，我們可以引入新的接口來直接指定 SSG 的資源需求溯乒。
  • 對于 Table API & SQL，由于沒有暴露operator和 SSG 的概念豹爹，因此規(guī)劃器可能應(yīng)該生成 SSG 資源需求裆悄，只向用戶暴露幾個配置旋鈕。

細(xì)粒度資源需求的粒度

在本節(jié)中臂聋，我們將討論應(yīng)該以什么粒度指定細(xì)粒度的資源需求光稼，這是設(shè)計運(yùn)行時接口需要回答的最基本問題。具體來說孩等，我們討論了三種設(shè)計方案的優(yōu)缺點：為每個算子艾君、task或slot共享組指定資源要求。

用戶故事

在深入研究設(shè)計選項之前肄方，我們想明確細(xì)粒度資源管理的用戶故事冰垄，這有助于了解每個設(shè)計選項的優(yōu)缺點如何影響我們的目標(biāo)用例。

我們認(rèn)為权她，細(xì)粒度的資源管理并不是對現(xiàn)有方法的替代虹茶，而是對控制 Flink 資源使用的用戶參與范圍的擴(kuò)展。用戶可以根據(jù)他們的專業(yè)知識和要求選擇他們想要參與的程度隅要。

• 最少涉及的選項是利用開箱即用的粗粒度資源配置蝴罪。它應(yīng)該適用于大多數(shù)簡單的用例，尤其是對于嘗試 Flink 的初學(xué)者步清。然而洲炊，資源利用通常不是最優(yōu)的。
• 在生產(chǎn)中尼啡，通常需要更多的用戶參與，指定算子的并行度询微，配置粗粒度的 slot/taskmanager 資源崖瞭，以及拆分 slot 共享組。
• 對于粗粒度資源管理效果不佳的情況（如目的部分所述）細(xì)粒度資源管理為專家用戶提供了一種進(jìn)一步優(yōu)化資源利用率的方法撑毛，方法是控制pipeline的每個特定部分應(yīng)該使用多少資源使用书聚，以更多的用戶參與為代價。

算子粒度

如果為每個算子指定了細(xì)粒度的資源需求藻雌，那么 Flink 運(yùn)行時需要聚合這些資源需求來生成slot資源需求雌续，關(guān)于算子如何鏈接以及task如何共享slot。

優(yōu)點是：

• 資源需求與算子鏈/slot共享之間的解耦胯杭。operator資源需求獨立于operator的鏈接方式以及task共享slot的方式驯杜。理想情況下，算子鏈和slot共享的更改不應(yīng)要求用戶重新指定資源需求做个。
• 針對并行性差異的潛在優(yōu)化鸽心。對于具有不同并行度的算子的 SSG滚局，有機(jī)會使用slot中算子所需的資源來滿足slot請求，這可能會以進(jìn)一步提高 Flink 運(yùn)行時的努力為代價顽频，進(jìn)一步提高資源利用率藤肢。

但是，也有一些缺點：

• 用戶參與過多糯景。復(fù)雜的工作可能包含數(shù)十甚至數(shù)百個operator嘁圈。為每個operator指定資源需求是不切實際的。
• 難以支持混合資源需求蟀淮。
  • 混合資源需求：有時用戶可能只想為工作的某些部分指定資源需求最住，而未指定其余部分的需求，并期望他們使用與粗粒度資源管理類似的資源灭贷。
  • 支持混合算子資源要求很困難温学，因為具有指定和未指定資源要求的算子可能鏈接在一起或共享同一個slot。很難通過聚合指定和未指定的operator需求來定義slot需要哪些資源甚疟。
• 累積配置錯誤仗岖。配置的資源需求和實際需要的資源之間總是存在偏差。算子越多览妖，這種偏差的累積誤差就越大轧拄，這可能會損害資源的利用率。

注意：為operator資源要求設(shè)置默認(rèn)值可能有助于減少用戶參與讽膏。然而檩电，找出一個合適的默認(rèn)值也很困難，有時甚至是不可能的府树。不正確的默認(rèn)值也可能放大累積配置錯誤俐末。

task粒度

如果為每個task指定了細(xì)粒度的資源需求，那么 Flink 運(yùn)行時需要暴露算子如何鏈接到task中奄侠，并聚合task資源需求以生成關(guān)于task如何共享slot的slot資源需求卓箫。

task粒度方式的優(yōu)缺點與算子粒度方式類似，但有以下區(qū)別垄潮。

• task是鏈?zhǔn)給perator烹卒，因此資源需求不再與算子鏈解耦。
• task比operator少弯洗，因此用戶參與較少但仍然過多旅急，累積配置錯誤。
• 公開算子鏈牡整。雖然 DataStream API 提供了接口來提示應(yīng)該如何鏈接算子藐吮，但完整的算子鏈接策略仍然在 Flink 的運(yùn)行時內(nèi)部。暴露operator在運(yùn)行時如何被鏈接意味著對涉及鏈接策略設(shè)置重大限制，因為任何導(dǎo)致不同鏈接結(jié)果的新更改都可能破壞資源配置的向后兼容性炎码。

slot共享組粒度

通過為每個 SSG 指定細(xì)粒度的資源需求盟迟，F(xiàn)link 運(yùn)行時可以直接請求具有所需資源的slot。它克服了算子/task粒度方法的缺點潦闲。

• 靈活的用戶參與攒菠。需要多少用戶努力取決于用戶定義了多少 SSG。SSG 越多歉闰，需要指定的資源需求就越多辖众。
• 支持混合資源需求。由于需求在 SSG 上和敬，因此無需擔(dān)心具有混合需求的operator/task被鏈接在一起或共享同一個slot凹炸。FLIP-56 已經(jīng)支持從同一 TM 分配具有混合要求的slot。具有未指定要求的slot請求將由與粗粒度資源管理中的等效資源來滿足昼弟。
• 較少的累積配置錯誤啤它。同一 SSG 內(nèi)的operator之間的削峰填谷效應(yīng)應(yīng)該會減少所需的整體資源。

此外舱痘，基于 SSG 的方法還有助于簡化系統(tǒng)变骡。

• 指定的資源需求可以直接用于slot分配。不需要進(jìn)一步的處理/轉(zhuǎn)換/聚合芭逝。
• 試圖仔細(xì)決定每個算子/task應(yīng)該使用多少資源（CPU塌碌、堆內(nèi)存等）不會在運(yùn)行時執(zhí)行中生效，因為除了托管內(nèi)存之外旬盯，slot內(nèi)的算子/task之間沒有資源隔離台妆。
• 對于托管內(nèi)存，F(xiàn)LIP-53和FLIP-141已經(jīng)引入了一種基于分?jǐn)?shù)的方法胖翰，用于在slot內(nèi)共享托管內(nèi)存接剩。暴露更多用于控制operator/task內(nèi)存的旋鈕可能會破壞現(xiàn)有方法，或者至少會使系統(tǒng)復(fù)雜化萨咳。

與算子/task粒度方法相比搂漠，這種方法有以下缺點。

• 資源需求和算子鏈/slot共享之間的耦合某弦。如果 SSG 發(fā)生變化，無論是用戶明確指定的還是由于算子鏈/slot共享策略的變化而克，指定的資源需求也需要調(diào)整靶壮。
• 針對并行性差異的用戶參與。對于具有不同并行度的算子的 SSG员萍，不包含所有算子的子task的slot可能會占用比需要的資源多腾降。為了針對這個問題提高資源利用率，用戶需要將具有不同并行度的算子分成不同的 SSG碎绎。

概括

上表總結(jié)了三種設(shè)計方案的優(yōu)缺點塞绿。

通過以上利弊沟涨，我們看到了一個重要的底層事實，這也是我們選擇基于 SSG 的方式最有說服力的理由异吻，即Slot 是 Fink 運(yùn)行時資源管理的基本單元裹赴。

• 資源需求的粒度應(yīng)該對應(yīng)于它們在運(yùn)行時的實現(xiàn)方式。根據(jù)slot分配的要求诀浪，從任何其他粒度轉(zhuǎn)換到slot資源要求將增加系統(tǒng)復(fù)雜性棋返。
• 運(yùn)行時接口應(yīng)該只需要資源管理所需的最少信息集，為開發(fā) API 留出更大的靈活性雷猪。開發(fā) API 將用戶提供的operator/task要求（如果這是向最終用戶公開的內(nèi)容）聚合到slot位要求比從用戶提供的slot位要求中組成operator/task要求更直接睛竣。

綜上所述，在這個 FLIP 中求摇，我們提出了基于 SSG 的運(yùn)行時接口射沟，用于配置細(xì)粒度的資源需求，因為它與運(yùn)行時資源的管理方式相對應(yīng)与境，從而具有可用性验夯、效率和簡單性。與收益相比摔刁，我們認(rèn)為缺點影響較谢幼：算子鏈和slot共享策略不會經(jīng)常以影響資源需求的方式變化，用戶參與與并行差異是可用性和資源利用率之間的權(quán)衡用戶來決定。

提議的變更

本 FLIP 中提出的更改非常簡單绑谣。

• 引入用于指定基于 SSG 的資源要求的運(yùn)行時接口党窜。
• 分配具有指定資源要求的slot。

運(yùn)行時接口

作為統(tǒng)一運(yùn)行時的入口點借宵，從用戶開發(fā) API 中StreamGraphGenerator獲取各種設(shè)置幌衣，并相應(yīng)地生成。TransformationsStreamGraph我們建議添加以下接口來指定 SSG 的細(xì)粒度資源需求暇务。

public class StreamGraphGenerator {
    /**
     * Specify fine-grained resource requirements for slot sharing groups.
     *
     * <p>Note that a slot sharing group hints the scheduler that the grouped operators CAN be
     * deployed into a shared slot. There's no guarantee that the scheduler always deploy the
     * grouped operator together. In cases grouped operators are deployed into separate slots,
     * the slot resources will be derived from the specified group requirement.
     */
    public StreamGraphGenerator setSlotSharingGroupResource(Map<String, ResourceProfile> slotSharingGroupResources);
}

指定的 SSG 資源需求需要一直傳遞到對應(yīng)SlotSharingGroup的ExecutionGraph泼掠。

slot分配

目前，SSG 的slot請求由SlotSharingExecutionSlotAllocator.我們建議SlotSharingExecutionSlotAllocator利用相應(yīng)的資源需求SlotSharingGroups來生成slot請求垦细。

相關(guān)問題

網(wǎng)絡(luò)內(nèi)存

網(wǎng)絡(luò)內(nèi)存包含在當(dāng)前的ResourceProfile實現(xiàn)中择镇，期望細(xì)粒度的資源管理不會將太多的task部署到需要比 TM 包含的更多網(wǎng)絡(luò)內(nèi)存的 TM 上。
但是括改，每個task需要多少網(wǎng)絡(luò)內(nèi)存很大程度上取決于 shuffle 服務(wù)的實現(xiàn)腻豌，并且在切換到另一個 shuffle 服務(wù)時可能會有所不同。因此嘱能，目前無論是用戶還是 Flink 運(yùn)行時都無法輕松指定task/slot的網(wǎng)絡(luò)內(nèi)存需求吝梅。網(wǎng)絡(luò)內(nèi)存控制的具體解決方案超出了本 FLIP 的范圍。然而惹骂，我們知道解決這個問題的一些潛在方向苏携。

• 相對于給定的內(nèi)存池大小，使 shuffle 服務(wù)自適應(yīng)地控制分配給每個task/slot的內(nèi)存量对粪。這樣右冻，就不需要依賴細(xì)粒度的資源管理來控制網(wǎng)絡(luò)內(nèi)存消耗。
• 讓 shuffle 服務(wù)公開用于計算給定 SSG 的網(wǎng)絡(luò)內(nèi)存需求的接口著拭。通過這種方式纱扭，F(xiàn)link 運(yùn)行時可以指定計算出的針對slot的網(wǎng)絡(luò)內(nèi)存需求，而無需了解不同 shuffle 服務(wù)實現(xiàn)的內(nèi)部細(xì)節(jié)儡遮。

目前乳蛾，我們在FLINK-20863中建議暫時排除網(wǎng)絡(luò)內(nèi)存ResourceProfile，以解除對網(wǎng)絡(luò)內(nèi)存控制問題的細(xì)粒度資源管理功能的阻礙鄙币。如果需要肃叶，它可以在未來添加回來，只要有一個好的方法來指定需求十嘿。

資源匹配

目前因惭，ResourceProfile::isMatching使用以下規(guī)則（以下稱為松散匹配）來決定是否可以使用slot資源來滿足給定的資源需求，在SlotManager和中SlotPool：

• 任何資源都可以滿足未指定的要求 ( )详幽。ResourceProfile::UNKNOWN
• 任何大于或等于自身的資源都可以滿足指定的需求。請注意，此規(guī)則未生效唇聘，因為沒有指定要求 atm版姑。

在動態(tài)slot分配之前設(shè)計了松散匹配規(guī)則。在slot的資源在TM啟動時就已確定且不可更改的假設(shè)下迟郎，松散匹配規(guī)則具有以下優(yōu)點剥险。

• 對于獨立部署，它允許在預(yù)啟動的 TM 的slot幾乎沒有確切所需的資源時滿足slot請求宪肖。
• 對于活動資源管理器部署表制，它增加了slot被重用的機(jī)會，從而降低了為各種資源需求啟動新 TM 的成本控乾。

隨著 FLIP-56 中引入的動態(tài)slot分配么介，松散匹配規(guī)則的好處已大大降低。由于slot可以在 TM 啟動后動態(tài)創(chuàng)建蜕衡，只要可用任何所需的資源壤短，松散匹配規(guī)則保留的唯一好處是避免在slot可以在 JM 端重用時分配新slot，這無關(guān)緊要慨仿，因為無需啟動新的 TM久脯。

另一方面，松散匹配規(guī)則也引入了一些問題镰吆。

• 重復(fù)使用較大的slot來滿足較小的要求可能會損害資源利用率帘撰。
• 在匹配一組需求和slot時，在job故障轉(zhuǎn)移或聲明性slot分配協(xié)議的情況下万皿，總是找到一個可行的匹配解決方案（假設(shè)有一個）并不簡單摧找。

image.png

上圖展示了如何在松散匹配規(guī)則下找不到可行的匹配解決方案。假設(shè)有兩個資源需求A和B相寇，并且有兩個slotX和Y慰于。每個Requirement/Slot下面的數(shù)字代表資源的數(shù)量。那么 A 可以用 X 和 Y 來滿足唤衫，而 B 只能用 Y 來滿足婆赠。左邊顯示了一個可行的匹配，這兩個條件都可以滿足佳励。但是休里，松散匹配規(guī)則也可能導(dǎo)致另一個匹配，如右側(cè)所示赃承，其中 A 由 Y 滿足妙黍，而 B 和 X 不匹配。

鑒于其好處的減少和它引入的問題瞧剖，我們在FLINK-20864中提出用以下精確匹配規(guī)則替換松散匹配規(guī)則拭嫁。

• 未指定的要求 (ResourceProfile::UNKNOWN) 只能由 TM 的默認(rèn)slot資源來滿足可免。
• 指定的要求只能由與其自身相等的資源來滿足。

資源死鎖

image.png

上圖演示了由于調(diào)度依賴性導(dǎo)致的潛在死鎖情況做粤。對于給定的拓?fù)浣浇瑁畛跽{(diào)度程序?qū)⒄埱?4 個slot，分別用于 A怕品、B妇垢、C 和 D。假設(shè)只有 2 個slot可用肉康，如果兩個slot都分配給pipeline區(qū)域 0（如左圖所示）闯估，A 和 B 將先完成執(zhí)行，然后執(zhí)行C和D吼和，最后執(zhí)行E涨薪。但是，如果一開始將 2 個 slot 分配給 A 和 C（如右圖所示）纹安，那么 A 和 C 都無法完成執(zhí)行尤辱，因為缺少 B 和 D 消耗了它們產(chǎn)生的數(shù)據(jù)。

目前厢岂，通過粗粒度的資源管理光督，調(diào)度程序保證在開始滿足另一個pipeline區(qū)域的要求之前總是完成滿足一個pipeline區(qū)域的要求。這意味著上圖右側(cè)所示的死鎖情況永遠(yuǎn)不會發(fā)生塔粒。

但是结借，細(xì)粒度的資源管理沒有這樣的保證。由于 SSG 的資源要求可能不同卒茬，因此當(dāng)沒有足夠的資源來滿足所有要求時船老，無法控制首先滿足哪些要求。因此圃酵，并不總是可以先完成一個pipeline區(qū)域柳畔。

為了解決這個問題，F(xiàn)LINK-20865建議讓調(diào)度程序在當(dāng)前 SSG 的要求得到滿足之前推遲其他 SSG 的請求slot郭赐，以進(jìn)行細(xì)粒度的資源管理薪韩，但代價是更多的調(diào)度時間。

反應(yīng)式調(diào)度

我們知道細(xì)粒度的資源管理可能不容易與反應(yīng)式調(diào)度一起使用捌锭，這是一個仍在規(guī)劃中的未來功能俘陷，它根據(jù)可用資源決定執(zhí)行的并行度（如FLIP-138中所述）。
為了使細(xì)粒度的資源管理與反應(yīng)式調(diào)度一起工作观谦，一個重要的懸而未決的問題是拉盾，當(dāng)沒有足夠的資源來滿足所有資源需求時，應(yīng)該首先滿足哪些資源需求豁状。

image.png

上圖左側(cè)顯示了一個目標(biāo)執(zhí)行計劃捉偏，A 和 B 各需要 4 個slot倒得。右側(cè)有 3 種可能的情況，無法滿足所有資源需求夭禽。

• 在情況 1 中屎暇，我們獲得了大約一半的目標(biāo)處理能力。
• 在情況 2 中驻粟，我們可能只能得到目標(biāo)處理能力的 1/4 左右，受到 B 的限制凶异。
• 在情況 3 中蜀撑，job根本無法執(zhí)行。

正如我們所見剩彬，在資源不足的情況下如何滿足資源需求會顯著影響 Flink 的性能酷麦，甚至可用性。當(dāng)涉及更復(fù)雜的目標(biāo)執(zhí)行計劃時喉恋，它可能會變得更加復(fù)雜沃饶，具有異構(gòu)的目標(biāo)并行性和調(diào)度依賴性。

作為第一步轻黑，我們不支持細(xì)粒度資源管理的反應(yīng)式調(diào)度糊肤。

將來，該問題可能會通過以下方向得到解決氓鄙。

• 調(diào)度器可以為每個slot資源聲明一對最小/目標(biāo)所需的slot數(shù)馆揉。這樣，我們應(yīng)該始終嘗試為執(zhí)行job分配最少的資源集抖拦。這應(yīng)該有助于在可能的情況下避免最壞的情況（上例中的情況 3）升酣。
• 我們也可能依賴調(diào)度器來檢測非最優(yōu)情況（上例中的情況 2 和 3），并調(diào)整聲明的資源需求并返回不必要的資源态罪。

要記錄的已知限制和約束

當(dāng)向用戶提供細(xì)粒度資源管理功能時噩茄，應(yīng)詳細(xì)記錄以下限制和約束，以及潛在的影響和建議复颈。

• 將可鏈接算子設(shè)置為不同的 SSG 可能會破壞算子鏈绩聘，從而改變性能。
• 在 SSG 中更改數(shù)據(jù)交換模式（流水線與阻塞）可能會影響組的資源需求券膀。
• 同一 SSG 中的算子之間的并行度差異可能會降低資源利用率君纫。

歡迎關(guān)注gzh HEYDATA 一起交流更多。