摘要：ING集團發表了《Efficient Scheduling Of High Performance Batch Computing For Analytics Workloads With Volcano - Krzysztof Adamski & Tinco Boekestijn, ING》主題演講。
在KubeCon + CloudNativeCon North America，ING集團發表了《Efficient Scheduling Of High Performance Batch Computing For Analytics Workloads With Volcano - Krzysztof Adamski & Tinco Boekestijn, ING》主題演講，重點介紹了雲原生批量計算項目Volcano如何在數據管理平臺中爲大數據分析作業提供高性能調度工作。
詳情參見：KubeCon + CloudNativeCon North America
ING背景介紹
ING集團（荷蘭語：Internationale Nederlanden Groep），亦名荷蘭國際集團，是一個國際金融服務私營企業，成立於1991年，由荷蘭最大的保險公司Nationale-Nederlanden，與荷蘭的第三大銀行NMB PostBank Group合併而成。
ING集團的服務遍及全球40多個國家，核心業務是銀行、保險及資產管理等。ING集團的全球職員大約56,000人，顧客5320萬人，包括自然人、家庭，企業、政府及其他等，例如基金組織。
業務背景介紹
在銀行行業有許多法規和限制，如：監管要求在全球範圍內各不相同、數據孤島-全局和本地限制、數據安全、合規創新等，想要快速引入新技術不是一件容易的事情，爲此，ING佈局符合自身產業的DAP平臺（Data Analytics Platform），爲全球50%的ING員工提供安全的、自助的端到端分析能力，幫助員工在數據平臺之上構建並解決業務問題。
2013年開始我們有了數據平臺的概念，2018年通過引入雲原生技術打造新一代基礎設施平臺，從那時起，平臺需求有了穩定的增長，採用率也在持續提升，目前數據索引平臺上的項目已超過400個。我們所構建的平臺目標是在高度安全的自助服務平臺中完成所有分析需求，並且具備以下特點：
- 開源工具模型
- 強大的計算能力
- 嚴格的安全和合規措施
- 所有的分析集中在同一個平臺
- 滿足全球和本地需求
挑戰與方案
目前我們在由傳統的Hadoop平臺向Kubernetes過渡，但是對於作業管理和多框架支持方面還存在一些挑戰，如下：
1.Job的管理
a.Pod級調度，無法感知上層應用
b.缺乏細粒度的生命週期管理
c.缺乏任務依賴關係，作業依賴關係
2.調度
a.缺少基於作業的調度，如：排序、優先級、搶佔、公平調度、資源預定等
b.缺少足夠的高級調度算法，如：CPU拓撲、任務拓撲、IO-Awareness，回填等
c.缺少對作業、隊列、命名空間之間資源共享機制的支持
3.多框架支持
a.對Tensorflow、Pytorch等框架的支持不足
b.對每個框架部署（資源規劃、共享）等管理比較複雜
利用Kubernetes來管理應用服務（無狀態應用、甚至是有狀態應用）是非常方便的，但是對於批量計算任務的調度管理不如yarn友好，同樣yarn也存在一些限制，比如對新框架的支持不夠完善，比如TensorFlow、Pytorch等，爲此，我們也在尋找新的解決方案。
▍Kubernetes + Hadoop
在我們之前的集羣管理上，會把Hadoop和Kubernetes的調度分開，基本上所有的spark作業都會運行在Hadoop集羣中，其他的一些任務和算法會運行在Kubernetes集羣，我們的目標是希望所有的任務全部運行在Kubernetes集羣，這樣管理起來會更簡單。
Kubernetes和YARN共同工作時，由於Kubernetes和Hadoop資源是靜態劃分的，在正常辦公時間，Hadoop應用和Kubernetes各自使用自身分配資源，即便spark任務壓力大也無法借用更多資源。夜晚時間，集羣中僅有批處理任務，Kubernetes資源全部空閒，卻無法分配給Hadoop進行有效利用，對於調度平臺來講，這不是一種最佳的資源分配方式。
▍Kubernetes with Volcano
使用Kubernetes管理整個集羣，通過Volcano進行spark任務調度，此時不需要再對資源做靜態劃分，集羣資源可根據Pod、Batch、Interactive任務的優先級、資源壓力等進行動態調整，集羣整體資源利用率得到極大提升。比如在正常辦公時間內，常規服務應用資源空閒的情況下，Batch和Interactive應用資源需求增多時，可以暫時借用常規服務的資源；在假期和夜晚休息時，Batch業務可以使用集羣所有資源進行數據計算，集羣資源利用率得到極大提升。
比如在正常辦公時間內，常規服務應用資源空閒的情況下，Batch和Interactive應用資源需求增多時，可以暫時借用常規服務的資源；在假期和夜晚休息時，Batch業務可以使用集羣所有資源進行數據計算，集羣資源利用率得到極大提升。
Volcano是專爲Kubernetes而生的批處理調度引擎，其提供了以下能力：
- 加權優先級的作業隊列
- 如果集羣具有備用容量，可提交超過隊列資源限制的任務
- 當更多的pod被調度時，具備搶佔能力
- 豐富可配置的工作負載調度策略
- 兼容YARN的調度能力
Volcano的引入，補齊了Kubernetes平臺對批處理作業的調度管理能力，並且自Apache Spark 3.3版本以來，Volcano被作爲Spark on Kubernetes的默認batch調度器，安裝使用更方便。
業務常用特性
▍冗餘與局部親和
Volcano保留Kubernetes中pod級別的親和性反親和性策略配置，並增加了task級別的親和性和反親和性策略。
▍DRF（Dominant Resource Fairness）調度
DRF調度算法的全稱是Dominant Resource Fairness，是基於容器組Domaint Resource的調度算法。volcano-scheduler觀察每個Job請求的主導資源，並將其作爲對集羣資源使用的一種度量，根據Job的主導資源，計算Job的share值，在調度的過程中，具有較低share值的Job將具有更高的調度優先級。
比如集羣資源總量爲CPU：18C，Memory：72GB，兩個用戶分別是User1和User2，每個User分配1個隊列，在提交作業時會根據主導資源計算job的調度優先級。
- User1: CPU share值爲 6/18=0.33，Memory share值爲 24 / 72 = 0.33，最終share值爲0.33
- User2：CPU share值爲 12/18=0.67，Memory share值爲 24 / 72 = 0.33，最終share值爲0.67
DRF策略在任務調度時，優先分配share值較低的Job，即User1所申請的資源。
集羣內隊列資源可以通過配置權重值進行劃分，但是當本隊列提交任務超出隊列分配的資源，並且其他隊列存在資源空閒時，可以進行隊列間資源共享。即User2在使用完本隊列CPU資源後，可以使用User1隊列內的空閒CPU資源。當User1隊列提交新任務需要CPU資源時，將會觸發搶佔動作，回收User1被其他隊列借用的資源。
▍避免資源匱乏
在使用過程中，需要避免批量計算任務與自有服務出現資源搶佔與衝突的問題。比如：我們集羣中有兩個可用節點，集羣中需要部署一個統一的服務層對外提供服務，比如Presto，或者類似Alluxio的緩存服務。但是在批量計算調度時，集羣的資源空間有可能全部被佔用，我們將無法完成自有服務的部署或升級，爲此我們增加了空間可用係數相關配置，爲集羣預留一些備用空間，用於自有服務的部署使用。
▍DRF 儀表盤
我們根據Volcano的監控數據做了一個drf調度的儀表盤，在不同層次顯示更細粒度的調度信息。在業務集羣中，我們有一個隊列存放交互式用戶的任務，另有隊列存放平臺運行的所有重大項目的計算任務，我們可以爲重大項目隊列提供一定的資源傾斜，但是此時對交互式用戶的任務將不會太友好。
目前我們正在考慮增加集羣高峯時段展示的功能，爲用戶提供更多的集羣使用狀態和壓力等信息，在自助服務平臺用戶視角來看，用戶按照集羣的繁忙程度選擇自己任務的開始時間，這樣可以避免後臺複雜的配置就可以獲得高性能的運算體驗。
總結
Volcano對批處理任務調度做了很好的抽象，使我們在Kubernetes平臺能夠獲得更高的調度性能，後面我們也會將開發的功能逐步回合社區，比如：DRF Dashboard、在每個節點添加空閒空間、自動隊列管理、更多的Prometheus監控指標、Grafana儀表盤更新、kube-state-metrics更新和集羣角色限制等。
Volcano社區技術交流地址
Volcano官網：https://volcano.sh
GitHub : https://github.com/volcano-sh/volcano
每週例會： https://zoom.us/j/91804791393