ING國際銀行基於Volcano的巨量資料分析平臺應用實踐
摘要：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