開篇

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

介紹

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

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

編輯搜圖

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

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

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

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

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

交付方式：

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

1、全面盤點(diǎn)

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

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

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

此外，監(jiān)控?cái)?shù)據(jù)必須解決這兩個(gè)問題：

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

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

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

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

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

4、性能優(yōu)化

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1.需求/BAU 流

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

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

編輯搜圖

需求規(guī)模模塊：

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

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

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

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

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

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

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

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

度量單位與比例單位：

在考慮整個(gè)平臺(tái)的可擴(kuò)展性時(shí)，我們需要考慮三個(gè)重要因素：

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

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

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

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

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

2. 處理/中間件流

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

2j持久層、存儲(chǔ)遍歷和占用

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

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

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

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

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

編輯搜圖

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

結(jié)論

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