開篇

近年來大家都逐漸意識到數(shù)據(jù)驅(qū)動的洞察力的重要性，因為這種方式可以增強(qiáng)戰(zhàn)略決策并提高投資回報率，為了安全存檔大數(shù)據(jù)同時也將焦點落在構(gòu)建數(shù)據(jù)湖和數(shù)據(jù)倉庫上。順勢，大數(shù)據(jù)可用于支持各種數(shù)據(jù)工程、數(shù)據(jù)科學(xué)、業(yè)務(wù)分析和運(yùn)營分析計劃，并通過提高運(yùn)營效率、降低運(yùn)營成本、制定業(yè)務(wù)戰(zhàn)略來幫助企業(yè)受益。然而，人類日常消費和生成的數(shù)據(jù)呈指數(shù)級增長，因此就需要在大數(shù)據(jù)平臺中采用結(jié)構(gòu)良好的容量治理方法。

介紹

容量治理和可擴(kuò)展性工程是相互關(guān)聯(lián)的學(xué)科，因為它需要全面了解計算、存儲容量需求、基礎(chǔ)設(shè)施供應(yīng)及其相互關(guān)系，從而制定出大數(shù)據(jù)平臺可擴(kuò)展性策略。除此之外，技術(shù)風(fēng)險的解決和安全合規(guī)性也是容量治理需要考慮的重要方面。

與其他應(yīng)用程序類似，大數(shù)據(jù)應(yīng)用程序會對客戶個人身份信息 (PII) 數(shù)據(jù)進(jìn)行操作，并影響公司的關(guān)鍵業(yè)務(wù)和戰(zhàn)略決策。同樣，大數(shù)據(jù)應(yīng)用程序必須始終遵循最新的數(shù)據(jù)安全和服務(wù)可靠性標(biāo)準(zhǔn)。所有 IT 硬件和軟件組件都必須定期更新并使用最新的安全補(bǔ)丁，并對錯誤進(jìn)行及時修復(fù)。無論部署哪種基礎(chǔ)設(shè)施，都必須不斷掃描大數(shù)據(jù)平臺的每個組件，從而保證組件能夠被快速識別，同時解決組件潛在的技術(shù)問題或安全風(fēng)險。

編輯搜圖

上圖是大數(shù)據(jù)平臺容量治理框架的功能架構(gòu)。圖中最右邊的部分代表技術(shù)用戶的基礎(chǔ)設(shè)施或供應(yīng)流。圖表的最左側(cè)部分代表需求為主以及按照通常的商業(yè)模式為主的流派，這個流派的代表是業(yè)務(wù)用戶，他們的關(guān)注點是解決業(yè)務(wù)問題而不會深入了解解決方案的技術(shù)細(xì)節(jié)。圖中時間點部分代表大數(shù)據(jù)框架，這部分會使用工具和技術(shù)根據(jù)需求（左邊的部分）管理供應(yīng)（右邊的部分）。

為了保持文章簡短，我們將把技術(shù)架構(gòu)排除在討論范圍之外，因為已經(jīng)有存在成熟的微服務(wù)等工具能夠解決特定的領(lǐng)域問題。在開始之前，需要提出一個顯而易見的問題——圍繞這個問題構(gòu)建解決方案是否值得？市場上是否有相應(yīng)的工具能夠解決容量和合規(guī)性的問題。隨著時間的推移，在使用大量監(jiān)控、APM 和分析工具之后，我們發(fā)現(xiàn)如果需要構(gòu)建治理平臺就需要整合多種工具，因為每種工具都對應(yīng)解決不同特定領(lǐng)域的問題。以上結(jié)論的前提是不重新造輪子，而使用成熟的工具。

例如，在 YARN 上運(yùn)行的 Spark 應(yīng)用程序監(jiān)控、日志分析和性能管理的工具與用于部署在 Kubernetes 容器中實現(xiàn)相同功能的工具是完全不同的。雖然它們實現(xiàn)了相同的功能但是運(yùn)行的平臺不同。同樣，將適用于在本地 VMware 中監(jiān)控、APM 和自動擴(kuò)展的工具應(yīng)用于共有云中的虛擬機(jī)中卻毫無違和感，因為公共云也需要本地監(jiān)控工具和自動縮放 API。能夠移植的原因是功能相同，環(huán)境也相同，公有云是由無數(shù)個VMware組合而成。

數(shù)據(jù)科學(xué)或 AI 產(chǎn)業(yè)化項目不一定是指 MapReduce/spark/大數(shù)據(jù)，還有一部分項目包括：系統(tǒng)接口、常規(guī)軟件或微服務(wù)應(yīng)用。只需要對DevOps 工具和底層部署平臺進(jìn)行選擇就好。

對于金融機(jī)構(gòu)而言，確保大數(shù)據(jù)平臺的持續(xù)合規(guī)性和高可用性極為重要。需要全面了解計算存儲資源（供應(yīng)）、4 V（容量、速度、品種、準(zhǔn)確性）、工作負(fù)載的性質(zhì)（處理過程）、SLA 和數(shù)據(jù)敏感性要求（需求/BAU）。只有考慮上述因素之后才能構(gòu)建一個適合特定業(yè)務(wù)場景的可擴(kuò)展解決方案，同時確保大數(shù)據(jù)平臺的高可用性和容量冗余。

交付方式：

遵循成熟度矩陣，從數(shù)據(jù)收集和探索，到識別趨勢和執(zhí)行分析，通過分析來支持智能運(yùn)營。這里將分為 7 個階段實現(xiàn)這一目標(biāo)：

1、全面盤點

建立全面的跨平臺清單，其中虛擬機(jī)基礎(chǔ)架構(gòu)級別的清單可以從本地監(jiān)控工具中輕松獲得。需要注意的是，容器化平臺和不同公有云中的 API以及監(jiān)控模式是存在差異的。除此之外，僅 VM 級別的清單是不夠的。由于平臺使用了多個內(nèi)部的、供應(yīng)商支持的和開源的中間件，而這些中間件由不同組件組成，所以需要對這些中間件創(chuàng)建清單。我們必須實現(xiàn)發(fā)布者、觀察者和訂閱者來為這些中間件執(zhí)行角色標(biāo)記，然后再將這些中間件部署到虛擬機(jī)、容器化（Kubernetes/Openshift）或公有云平臺中。

2. 基礎(chǔ)設(shè)施利用率、消費趨勢以及分析

當(dāng)了解跨混合云基礎(chǔ)架構(gòu)部署的角色之后，就需要使用基礎(chǔ)架構(gòu)利用率并將數(shù)據(jù)分類為更細(xì)的顆粒度，并且對其定義指標(biāo)。

此外，監(jiān)控數(shù)據(jù)必須解決這兩個問題：

時間點事件管理需要快速識別、通知和解決 CPU、RAM 和網(wǎng)絡(luò)容量問題。事件管理儀表板的采樣頻率需要接近實時。

時間序列數(shù)據(jù)是容量矩陣的聚合，其中聚合數(shù)據(jù)的標(biāo)記從 5 分鐘的采樣匯總到每小時、每天、每周和每月的采樣匯總。通過這樣的組件采樣頻率，提升長期容量利用率和服務(wù)運(yùn)行狀況分析的能力。

上面說的數(shù)據(jù)是技術(shù)/基礎(chǔ)設(shè)施利用率數(shù)據(jù)，然后將多租戶占用率數(shù)據(jù)疊加到這些數(shù)據(jù)之上，得出每個數(shù)據(jù)集、工作、項目/計劃和業(yè)務(wù)單位的租戶占用率的累積信息。

3. 需求分析與預(yù)測

如果從基礎(chǔ)設(shè)施利用率中獲得租戶的入住率數(shù)據(jù)，就能夠確定存儲、計算和項目規(guī)模級別的增長趨勢?；趩蝹€數(shù)據(jù)集/租戶的相對增長，就可以確定最高占用者、增長最快的數(shù)據(jù)集/租戶、頂級（計算）浪費和非關(guān)鍵噪聲鄰居。

4、性能優(yōu)化

確定最浪費的資源，在確保適當(dāng)冗余并提高服務(wù)可靠性的前提下，與業(yè)務(wù)部門合作對資源進(jìn)行優(yōu)化減少浪費。在每個時間點，都有由作業(yè)程序調(diào)度到集群上的數(shù)千個作業(yè)，每個隊列包含數(shù)百個提交的作業(yè)，這些作業(yè)服務(wù)于每日、每周、每月或臨時計劃。在這些作業(yè)的執(zhí)行過程中需要識別和調(diào)整最大的 CPU 和 RAM 浪費，并將非關(guān)鍵作業(yè)安排到非關(guān)鍵或非高峰時間段運(yùn)行。

5. 高可用性、容量冗余和可擴(kuò)展性

識別關(guān)鍵業(yè)務(wù)工作負(fù)載并為其運(yùn)行提供冗余容量，并將非關(guān)鍵的負(fù)載調(diào)整到非高峰時間，這種負(fù)載調(diào)整的行為被認(rèn)為是站點可靠性團(tuán)隊的關(guān)鍵性能指標(biāo)之一。除了確保中間件的高可用性之外，識別站點可靠性問題，并確保平臺組件的單獨和集體擴(kuò)展性，從而應(yīng)對高峰時段的流量激增，要做到以上描述必須監(jiān)控和觀察一段時間內(nèi)的運(yùn)營數(shù)據(jù)才能實現(xiàn)。

對于每個中間件組件，worker 和 master 級別的高可用性是一項基本要求，尤其是對于業(yè)務(wù)關(guān)鍵型為 1 類的應(yīng)用更是這樣。對于內(nèi)部應(yīng)用，需要對每個組件級別收集徹底、一致的代碼分析、單元集成性能測試結(jié)果、依賴許可以及漏洞掃描數(shù)據(jù)等相關(guān)信息。對于托管服務(wù)，在公有云中需要與各自的云基礎(chǔ)設(shè)施提供商建立服務(wù)水平協(xié)議。外部軟件提供商需要確保相同的軟件支持、修補(bǔ)和事件管理支持 SLA。

6. 自動擴(kuò)展、自我修復(fù)、成本優(yōu)化

在成熟的最后階段，容量治理框架將變得更具侵入性，我們的決策引擎不僅可以為 SRE 團(tuán)隊生成時間表、每周每月的計劃，還可以在無需人工干預(yù)的情況下自動修復(fù)或清理一些服務(wù)（取決于環(huán)境的關(guān)鍵性、服務(wù)水平協(xié)議和變化的影響范圍）。最后，必須對上面捕獲的數(shù)據(jù)和分析進(jìn)行管理，以確定適合每個中間件組件的性能最高、成本最優(yōu)的基礎(chǔ)架構(gòu)。

這些數(shù)據(jù)還可以用于創(chuàng)建自動擴(kuò)展策略、自我修復(fù)（特別是針對非 HA 組件）、性能和成本優(yōu)化報告以及推薦模型。

7. 技術(shù)風(fēng)險和持續(xù)合規(guī)

事實證明，采購和設(shè)置一個高性能的安全兼容的系統(tǒng)是不夠的，有必要確保每個組件無論部署在什么樣的平臺上都保持兼容性，組件不會受到持續(xù)的威脅和漏洞的影響。

技術(shù)風(fēng)險和合規(guī)性是金融行業(yè)服務(wù)交付的極其重要的方面之一，因為服務(wù)中斷可能導(dǎo)致金錢損失和監(jiān)管處罰， Cat1 這類型的應(yīng)用就是個典型的例子。一旦將項目交付到生產(chǎn)環(huán)境，成本就不會止步于此，所以要三思而后行。

• 更換報廢硬件。支持軟件類需要持續(xù)更新。終止支持許可證應(yīng)及時更新。

• 部署到不同平臺的各種組件公開了各種 TCP 和其他端口，必須統(tǒng)一掃描這些端口以獲取必要的網(wǎng)絡(luò)區(qū)域隔離、傳輸 (SSL) 和靜態(tài)（加密）標(biāo)準(zhǔn)。

• 每個中間件子組件/微服務(wù)必須準(zhǔn)時掃描關(guān)鍵漏洞（例如最近的 log4j 漏洞）。服務(wù)器需要及時打上最新的操作系統(tǒng)和安全補(bǔ)丁。

• 服務(wù)器需要定期重啟以確認(rèn)中間件層的災(zāi)難恢復(fù)、高可用性、檢測和消除單點故障以及應(yīng)用需要重啟的補(bǔ)丁。

• 對于云 EC2 實例，需要關(guān)注刷新 AMI、憑證和加密密鑰以及 SSL 證書需要更換。

• 需要掃描并確保容量冗余，以應(yīng)對月度租戶增長和動態(tài)需求高峰時期的每小時利用率。

1.需求/BAU 流

將業(yè)務(wù)需求從各個維度進(jìn)行分析，最終形成技術(shù)架構(gòu)，該架構(gòu)結(jié)合了大數(shù)據(jù)工具集和部署基礎(chǔ)設(shè)施以及針對用例的解決方案。

制定用戶案例需要的工具類型和數(shù)據(jù)容量根據(jù)系統(tǒng)的數(shù)據(jù)性質(zhì)以及數(shù)據(jù)抽取、計算和報告要求來確定。例如，流式作業(yè)需要處理連續(xù)的占用內(nèi)存較小的流數(shù)據(jù)（以及適當(dāng)?shù)挠嬎愫途W(wǎng)絡(luò)帶寬來處理流式工作負(fù)載）。另一方面，對歷史數(shù)據(jù)的 Batch/ETL 抽取需要考慮大量的內(nèi)存應(yīng)用和網(wǎng)絡(luò)流量激增的情況。除此之外，數(shù)據(jù)分析和報告生成的工作對負(fù)載的要求需要考慮CPU 和 內(nèi)存瞬間爆發(fā)力，具體取決于數(shù)據(jù)集的大小和查詢的復(fù)雜性。

編輯搜圖

需求規(guī)模模塊：

需求規(guī)模模塊將數(shù)據(jù)容量的工作負(fù)載需求（可預(yù)測和不可預(yù)測）進(jìn)行簡化，化簡之后只需要考慮基礎(chǔ)設(shè)施數(shù)據(jù)容量的供應(yīng)和可用性問題。該模塊形成了反饋閉環(huán)，該閉環(huán)將容量增長和管理需求的利益相關(guān)者涵蓋其中。

業(yè)務(wù)需求、技術(shù)需求與運(yùn)營可擴(kuò)展性：

對于業(yè)務(wù)用戶而言，功能需求是將數(shù)據(jù)集傳輸或批量抽取到數(shù)據(jù)湖中，并應(yīng)用于數(shù)據(jù)工程。又或者利用這些數(shù)據(jù)生成戰(zhàn)略報告，再或者在數(shù)據(jù)集上訓(xùn)練推薦模型倉庫。

在更廣泛的意義上，我們將需求分為兩類——1.結(jié)構(gòu)化容量需求，2.動態(tài)容量需求。讓我們看看這些。

1a  結(jié)構(gòu)化容量需求：

結(jié)構(gòu)化容量需求是預(yù)測容量大小和作業(yè)計劃的需求，以便提供必要的最低保證容量或保持適當(dāng)?shù)娜哂嗟墓ぷ髫?fù)載，從而應(yīng)對高峰時段的流量激增。這些工作負(fù)載包括流式作業(yè)，它可以預(yù)測來自源系統(tǒng)的流式負(fù)載。同樣，一旦最終部署模型 API，也可以預(yù)先為模型 API 預(yù)先設(shè)置容量。

1b 動態(tài)容量需求：

動態(tài)容量請求由探索階段的作業(yè)組成，因為容量大小無法預(yù)先預(yù)測，以及作業(yè)的執(zhí)行沒有固定的時間表。這包括數(shù)據(jù)工程師構(gòu)建其攝取或計算作業(yè)的非生產(chǎn)開發(fā)環(huán)境，以及數(shù)據(jù)科學(xué)家在將模型發(fā)布用于生產(chǎn)之前直接訓(xùn)練其模型的實驗環(huán)境。這些工作負(fù)載在辦公時間處于活動狀態(tài)，因此需要在使用高峰時段進(jìn)行容量冗余從而面對激增的流量，同時在非高峰時段回收容量，達(dá)到節(jié)約成本的目的。

度量單位與比例單位：

在考慮整個平臺的可擴(kuò)展性時，我們需要考慮三個重要因素：

伸縮單位：例如，在 Openshift 中，可以定義容器的可伸縮性，在 VPC 中它將是 VMWare，在 Aws 中它將是EKS 集群、ec2 實例、 s3 存儲桶。

度量單位：在伸縮單位最接近度量單位的情況下可以使用度量單位。例如，在 EMR 中，伸縮單位是 ec2 實例，但由于這是一個多租戶集群，因此度量單位仍然是 spark 作業(yè)使用的 CPU 小時數(shù)或內(nèi)存小時數(shù)，

銷售/購買單位：是可以放置價格標(biāo)簽的實體。由于大數(shù)據(jù)平臺本身就是一個資源管理器，也是一個資源的混合體。如果為團(tuán)隊構(gòu)建單獨的集群，雖然可以對整個集群進(jìn)行擴(kuò)展，但仍然需要回答每個作業(yè)所消耗的資源，這里就可以通過銷售/購買單位來衡量。

需求分析循環(huán)（正向容量計劃）：

在構(gòu)建數(shù)據(jù)科學(xué)/數(shù)據(jù)工程項目時，必須理解用例、選擇工具和考慮容量規(guī)劃。 盡管對源系統(tǒng)的四個 V 有很好的理解，但只能估計目標(biāo)數(shù)據(jù)集的實際足跡。除此之外，隨著按計劃或在集群上臨時運(yùn)行的連續(xù)抽取和計算作業(yè)——需要根據(jù)增長的綜合趨勢來預(yù)測容量，包括不斷增長的 T1、T2 和 T3 數(shù)據(jù)集將來所需的容量，以及每個類別所需要抽取和計算的數(shù)據(jù)集容量。

2. 處理/中間件流

位于圖表的中心的是各種大數(shù)據(jù)中間件，這個流最接近大數(shù)據(jù)主題專家和 SRE 領(lǐng)袖們。該圖根據(jù)功能對組件進(jìn)行了分類。

最大的部分是分布式計算層，包括Hadoop/spark 框架（如 Cloudera CDH/CDP、Databricks、Kubernetes 上的 Spark 等）、查詢引擎（如 Presto/Impala）和流引擎（Kafka） 。下面來逐一介紹這些組件：

2a 2b 2c 基本服務(wù)（監(jiān)控和日志聚合、數(shù)據(jù)治理、數(shù)據(jù)安全）：

有一些工具可以為平臺中的工作負(fù)載提供跨環(huán)境、跨集群的基本服務(wù)。這包括日志聚合、數(shù)據(jù)發(fā)現(xiàn)/數(shù)據(jù)治理和數(shù)據(jù)安全等功能。工具可以跨環(huán)境工作，以確保大數(shù)據(jù)平臺的可持續(xù)、安全和可靠的運(yùn)行。

2e 分析/數(shù)據(jù)科學(xué)工作負(fù)載：

它的使用模式和容量要求與運(yùn)營集群的數(shù)據(jù)抽取或計算作業(yè)有所不同。數(shù)據(jù)科學(xué)家可能需要將一組特定的大型數(shù)據(jù)集導(dǎo)入到分布式處理引擎中進(jìn)行模型訓(xùn)練。這一過程會一直持續(xù)到模型被訓(xùn)練出來，當(dāng)然需要花費比較長的時間。模型的訓(xùn)練不需要遵循任何時間表，盡管集群上的負(fù)載在正常辦公時間很高，但是在非高峰時間是處于空閑的狀態(tài)，完全可以用來進(jìn)行模型的訓(xùn)練。

此外，分析/數(shù)據(jù)科學(xué)的工作負(fù)載對集群的數(shù)據(jù)安全性和訪問控制要求比較高，因為模型訓(xùn)練的過程有可能會直接訪問客戶的生產(chǎn)數(shù)據(jù)。因此必須建立嚴(yán)格的標(biāo)記化、數(shù)據(jù)存儲、檢索和數(shù)據(jù)泄漏預(yù)防機(jī)制，以避免任何數(shù)據(jù)泄露或個人身份信息 (PII) 數(shù)據(jù)被盜。

2f 開發(fā)人員/非產(chǎn)品工作負(fù)載：

對于操作環(huán)境的數(shù)據(jù)抽取和計算作業(yè)而言，數(shù)據(jù)要么是合成數(shù)據(jù)，要么是經(jīng)過查殺的。通常，開發(fā)人員環(huán)境是共享租賃的，容量相比生產(chǎn)環(huán)境會更小一些，支持 SLA 的強(qiáng)度也較低。本質(zhì)上，大數(shù)據(jù)解決方案依賴于實際生產(chǎn)數(shù)據(jù)的四個 V，因此作業(yè)的實際足跡和性能只能在生產(chǎn)區(qū)進(jìn)行驗證。通常會為生產(chǎn)環(huán)境的作業(yè)性能調(diào)整提供單獨的 QA 環(huán)境。該環(huán)境用于驗證來自業(yè)務(wù)邏輯、數(shù)據(jù)治理、數(shù)據(jù)安全和視圖集成測試的作業(yè)。

2g 運(yùn)維/ETL/批處理工作負(fù)載：

運(yùn)維工作負(fù)載是指需要滿足有保證的服務(wù)水平協(xié)議 (SLA) 的抽取或計算作業(yè)。這些服務(wù)的任何中斷都可能影響公司的正常業(yè)務(wù) (BAU) 運(yùn)營或戰(zhàn)略業(yè)務(wù)決策。需要了解作業(yè)的整體計算、存儲、數(shù)據(jù)安全和時間敏感性，并確保有足夠的容量和冗余，以防止對其 SLA 產(chǎn)生任何影響。

2h分布式查詢處理/可視化層工作負(fù)載

許多業(yè)務(wù)報告不需要對底層數(shù)據(jù)集進(jìn)行任何修改，而只需要在內(nèi)存中處理大型數(shù)據(jù)集。有幾個用于大數(shù)據(jù)的分布式查詢處理引擎（如 Trino/Apache Presto、Apache Impala、Apache Drill 甚至 SparkSQL）可用于報告或可視化工具（如 superset、tableau、Qlikview 或構(gòu)建的自定義儀表板），并且提供 SQL 接口展示到可視化/圖表庫上。

關(guān)于存儲虛擬化的說明：

許多組織希望利用對象存儲來實現(xiàn)更廉價的數(shù)據(jù)歸檔。然而，就 CAP 定理而言，S3 犧牲了一致性以確保其他兩個。同時，考慮到公有云 s3——將大量的大數(shù)據(jù)計算負(fù)載直接放到網(wǎng)絡(luò)通道上，會造成系統(tǒng)的可靠性不一致。各種工具提供存儲虛擬化，實際上是通過仲裁層為最終用戶提供查詢接口，因此很難建立模式（因為不知道用戶何時使用接口進(jìn)行查詢）。除非用戶的查詢操作在辦公時間，那么可以提升容量在這一時段的利用率，又或者通過可以隔離和分配容量為用戶提供預(yù)定查詢的服務(wù)。同時，容量需求可以通過項目級隔離和相應(yīng)的容量冗余來處理。

2i 流式工作負(fù)載、 處理工作負(fù)載

新建項目常常會通過流式數(shù)據(jù)抽取將運(yùn)營和業(yè)務(wù)的數(shù)據(jù)導(dǎo)入到數(shù)據(jù)倉庫中。Apache Kafka、Apache Storm、Spark Streaming 和 AWS Kinesis 是常用的數(shù)據(jù)抽取工具。Kafka 平臺自帶一套高可用性、多租戶和容量治理功能的工具集。根據(jù)源系統(tǒng)的網(wǎng)絡(luò)和性質(zhì)，大多數(shù)情況下，流式作業(yè)的 CPU/RAM 占用率不會出現(xiàn)激增的情況，因為流式引擎有效解決了復(fù)制和彈性的問題（水平擴(kuò)展）。

2j持久層、存儲遍歷和占用

數(shù)據(jù)集（保存到存儲層）的最終大小可能取決于源系統(tǒng)的性質(zhì)和大小、壓縮類型、復(fù)制要求、標(biāo)記化和加密以及抽取/計算作業(yè)的性質(zhì)。因此，需要通過遍歷持久層的方式去識別數(shù)據(jù)集的實際大小，然后將其與計算作業(yè)、租戶和源系統(tǒng)產(chǎn)生關(guān)聯(lián)。

編寫的存儲遍歷模塊就是建立這種關(guān)聯(lián)，通過元數(shù)據(jù)和多租戶結(jié)構(gòu)連接它們的大小，然后得出數(shù)據(jù)集增長的趨勢。最終，才能預(yù)測數(shù)據(jù)集增長的性質(zhì)和大小，從而使我們能夠根據(jù)要求確保存儲層冗余。

YARN（或 Future Spark-on-Kubernetes）調(diào)度程序的容量治理：

本質(zhì)上，大數(shù)據(jù)框架中計算工作負(fù)載的容量管理利用了 YARN 容量調(diào)度程序。Spark 社區(qū)正在努力將相同的功能引入 Kubernetes 上的 Spark?；旧蠈τ谝粋€特定的隊列，我們有一個最小的保證容量，即使集群負(fù)載很重，我們也會保證隊列的容量，其他作業(yè)將被搶先提供給隊列。另一方面，需要設(shè)置最大容量，因為即使在集群正常負(fù)載的情況下，也可能無法分配資源的限制。

最小保證容量和最大限制之間的差異來自公共池。在高峰時段，如果非關(guān)鍵作業(yè)具有較高的 Max Limit 值，則可能會影響具有合理最小值和最大值的關(guān)鍵作業(yè)。例如，Apache Hadoop 2.4.1 — Hadoop Map Reduce Next Generation-2.4.1 — 容量調(diào)度程序。

編輯搜圖

例如，上面是操作集群中的 YARN 隊列之一。紅線表示最小保證容量為 100 個 vCore。而最大值被限制在 270 個 vCore 左右。最小保證容量和最大限制之間的差異來自公共池，如果此時Yarn處于負(fù)載狀態(tài)，則可以搶占該區(qū)域中的作業(yè)?，F(xiàn)在，隊列可能在一天內(nèi)包含數(shù)千個運(yùn)行的作業(yè)，如何識別最大的浪費并進(jìn)行優(yōu)化需要通過單獨的文章來描述。

基本上，我們想要做的是讓 VM Infrastructure 成本更接近隊列分配的成本。一旦 CPU 或 RAM 被分配給一個作業(yè)，從 YARN 的角度來看，它被認(rèn)為是被占用/使用的。

但我們的目標(biāo)是采購更接近隊列中使用/分配的內(nèi)容，并設(shè)置合理的冗余來處理激增的工作負(fù)載。在應(yīng)用該分配方式的同時，我們也通過不斷地衡量的方式使利用率更接近分配的內(nèi)容。在這個過程中，避免了分配不足（避免意外涌入集群）和過度分配（避免浪費）的情況發(fā)生。此外，我們希望避免在高峰時段安排非關(guān)鍵作業(yè)，以避免對具有更高 SLA 的時間關(guān)鍵作業(yè)產(chǎn)生影響。對于容量和進(jìn)度優(yōu)化，需要有不同的策略。

SRE 日歷和合規(guī)，每日、每周、每月花名冊

每個生產(chǎn)變更請求都需要我們的 L1 支持和站點可靠性工程（SRE）團(tuán)隊為我們的開發(fā)和 DevOps 團(tuán)隊做好準(zhǔn)備。SRE 團(tuán)隊必須清楚地了解通知 BAU 團(tuán)隊的停機(jī)時間或服務(wù)中斷時間，尤其是在生產(chǎn)環(huán)境中。

另一方面，合規(guī)熱圖提供了關(guān)鍵技術(shù)風(fēng)險可交付成果的綜合視圖。

SRE 日歷提供了為 SRE 團(tuán)隊安排上述技術(shù)風(fēng)險行動項目的地方。它還允許開發(fā)團(tuán)隊在軟件發(fā)布、升級和補(bǔ)丁期間通過 L1 支持和 SRE 團(tuán)隊預(yù)訂和協(xié)調(diào) BAU 停機(jī)時間。

3. 供應(yīng)/基礎(chǔ)設(shè)施流

該分類的靈感來自 Mirco Hering 的DevOps for the Modern Enterprise。根據(jù) DevOps 與相應(yīng)平臺的交互方式，基礎(chǔ)設(shè)施供應(yīng)主要分為三個流。這三個基礎(chǔ)架構(gòu)域在我們實現(xiàn)高可用性、供應(yīng)/部署自動化和自動擴(kuò)展的方式上會有所不同。實施基礎(chǔ)設(shè)施運(yùn)營和管理技術(shù)風(fēng)險以及合規(guī)的模式也存在不同。

3a本地基礎(chǔ)設(shè)施

雖然一些組織希望將基礎(chǔ)設(shè)施維護(hù)工作交給公共云提供商來負(fù)責(zé)，并希望他們提供具有競爭力的價格。但隨著市場上可用的 IT 基礎(chǔ)設(shè)施越來越便宜，但能源效率卻在不斷升高；將客戶數(shù)據(jù)進(jìn)行遷移、存儲和檢索到公共云的成本如滾雪球般越來越多，同時還存在公司客戶數(shù)據(jù)遭到破壞或 PII 數(shù)據(jù)被盜的風(fēng)險——許多組織更愿意在虛擬私有云本身中構(gòu)建具有成本效益的功能。

3b容器化（云原生）基礎(chǔ)設(shè)施

根據(jù) Gartner 的這項研究——到 2021 年，全球 98% 的基礎(chǔ)設(shè)施將部署到容器中。使用 Kubernetes/Openshift 等容器編排器將我們的應(yīng)用程序部署到容器中，從而可以提供更深層次的操作系統(tǒng)級別隔離、高效配置管理、自動擴(kuò)展等高級功能、高可用性、可維護(hù)性和自愈能力。

甚至 Spark 社區(qū)也在努力將 Spark 引入 Kubernetes。盡管動態(tài)資源分配和隊列管理仍在進(jìn)行中，但一些組織已設(shè)法在生產(chǎn)中使用它。

3c公有云（IAAS / PAAS / SAAS）

公有云易于配置或擴(kuò)展，同樣也會存在浪費。如果不對用例使用最合適的解決方案，很容易浪費資源。對于每個公有云，最好使用托管服務(wù)。例如，雖然可以設(shè)置 Argo 管道來啟動 vanilla Kubernetes 集群，但為了更好的集成，首選 EKS。同樣，與自行部署的 Jupyterhub 和 Hadoop + Spark 部署相比，Sagemaker + EMR 將是首選組合。無論如何，我們僅將公有云用于 IAAS 或 PAAS，或者將業(yè)務(wù)工作負(fù)載重新設(shè)計為公有云產(chǎn)品的本地托管服務(wù)——有必要開發(fā)一個全面的資產(chǎn)清單并將消費數(shù)據(jù)疊加在上面其中。

基礎(chǔ)設(shè)施供應(yīng)反饋回路

隨著越來越多的計算和抽取作業(yè)加入，并在集群應(yīng)用中不斷增長，必須通過容量反饋來確保容量冗余。除了入住率和增長分析外，還應(yīng)將其傳達(dá)給業(yè)務(wù)用戶。通過上面的需求規(guī)模模塊圖中描述的各種前向和后向反饋工作揭示需求和供應(yīng)的相互作用關(guān)系，并且進(jìn)行分析。

結(jié)論

在構(gòu)建容量治理框架的同時，保持站點可靠性、高可用性和合規(guī)性，需要在虛擬私有云 (VPC) 中的各種基礎(chǔ)設(shè)施產(chǎn)品中實施 DevOps 和站點可靠性工程 (SRE)，并且將這些原則和經(jīng)驗進(jìn)行結(jié)合，應(yīng)用到容器化、公有云平臺以及大數(shù)據(jù)產(chǎn)品的工作中。同時需要充分考慮業(yè)務(wù)用戶的觀點、平臺的多租戶結(jié)構(gòu)和照舊業(yè)務(wù) (BAU)的 服務(wù)水平協(xié)議 (SLA)、數(shù)據(jù)安全以及正常運(yùn)行時間要求。隨著時間的推移構(gòu)建的容量治理框架能夠提供洞察力，增強(qiáng) SRE 團(tuán)隊的能力，并能夠通過容量優(yōu)化節(jié)省數(shù)百萬美元的基礎(chǔ)設(shè)施成本。