作者 | 吳建陽

引 言

隨著業(yè)務(wù)快速發(fā)展，大數(shù)據(jù)平臺(tái)所支撐的業(yè)務(wù)矩陣愈發(fā)龐大且繁雜多樣，數(shù)據(jù)業(yè)務(wù)在高速發(fā)展建設(shè)階段，更關(guān)注的是數(shù)據(jù)交付效率、穩(wěn)定性、平臺(tái)易用性等方面，與此同時(shí)，數(shù)據(jù)規(guī)模爆炸式增長和計(jì)算需求的不斷攀升，使大數(shù)據(jù)平臺(tái)成本呈現(xiàn)快速上揚(yáng)態(tài)勢(shì)，如何有效控制和優(yōu)化這些成本，成為數(shù)據(jù)團(tuán)隊(duì)面臨的巨大挑戰(zhàn)。

樸樸數(shù)據(jù)平臺(tái)建設(shè)歷經(jīng)多個(gè)發(fā)展階段：從早期的報(bào)表取數(shù) -> 數(shù)倉體系建設(shè) -> 以指標(biāo)平臺(tái)為數(shù)據(jù)建設(shè)核心 -> DATA+AI，而每個(gè)階段的發(fā)展變更均會(huì)對(duì)成本造成巨大沖擊。我司開展較大規(guī)模成本治理迄今已三度春秋，個(gè)中艱辛難以言表，整體可概括為“降本增效”三部曲：成本發(fā)現(xiàn)與分析、成本優(yōu)化與控制、體系化治理構(gòu)建。本文是對(duì)過往成本治理過程做階段性總結(jié)，意在復(fù)盤亦為分享，希望對(duì)大家如何開展云上大數(shù)據(jù)平臺(tái)成本治理有所幫助。

成本發(fā)現(xiàn)與分析

2022 年某個(gè)時(shí)間節(jié)點(diǎn)，云廠商 TAM 團(tuán)隊(duì)反饋我司月成本急劇上漲，在此之前，數(shù)據(jù)團(tuán)隊(duì)核心關(guān)注點(diǎn)在數(shù)據(jù)中臺(tái)建設(shè)，由于云產(chǎn)品服務(wù)計(jì)費(fèi)規(guī)則較為精細(xì)復(fù)雜，需要投入大量時(shí)間學(xué)習(xí)和對(duì)接才能掌握有效的成本分析方法。初期的成本跟進(jìn)依賴于 TAM 團(tuán)隊(duì)月會(huì)反饋，缺少主動(dòng)洞察手段，面對(duì)成本急劇上漲的情況，著手進(jìn)行第一階段成本分析與治理工作。

1.1 分析 & 治理初試

初期，在 SA 和 TAM 團(tuán)隊(duì)的幫助下對(duì)大數(shù)據(jù)成本進(jìn)行分析，主要集中在：存儲(chǔ)、計(jì)算、網(wǎng)絡(luò)流量和 EMR 托管四大方面，根據(jù)服務(wù)類別的成本占比分析結(jié)果，確立下一步優(yōu)化方向和優(yōu)先級(jí)。

計(jì)算層優(yōu)化

EMR 作為大數(shù)據(jù)平臺(tái)基礎(chǔ)架構(gòu)底座，可針對(duì)不同實(shí)例組配置靈活調(diào)度組合各類計(jì)算資源，結(jié)合其彈性伸縮能力滿足不同時(shí)段業(yè)務(wù)計(jì)算所需，關(guān)于 EMR 的使用可參考筆者另一篇文章《EMR 實(shí)戰(zhàn)心得淺談》。EMR 的成本組成可拆分為兩大部分：

• EMR 集群管理費(fèi)

• • 經(jīng)由 EMR 啟動(dòng)計(jì)算實(shí)例時(shí)產(chǎn)生的管理費(fèi)用，按小時(shí)、實(shí)例規(guī)格大小階梯式收取

• EMR 計(jì)算實(shí)例 (我司主要使用 EMR ON EC2 模式)

• • EC2 計(jì)算實(shí)例本身費(fèi)用 (On Demand、Spot、Savings Plan 三種計(jì)費(fèi)模式）

  • EC2 計(jì)算實(shí)例產(chǎn)生的跨可用區(qū)流量費(fèi)

  • EC2 計(jì)算實(shí)例所掛載的 EBS 卷費(fèi)用 (系統(tǒng)盤、數(shù)據(jù)盤)

從已產(chǎn)生的 EMR 成本清單數(shù)據(jù)細(xì)化分析，進(jìn)而得出治理方向和措施：

• 削減 EMR 托管費(fèi)用

• • 全面下線小規(guī)格機(jī)型使用 (低于 8x)，最大化減少托管費(fèi)用

  • 結(jié)合業(yè)務(wù)計(jì)算峰谷，配置適當(dāng)?shù)臄U(kuò)縮容策略

• 降低 EC2 計(jì)算實(shí)例單價(jià)

• • 在不降低業(yè)務(wù)計(jì)算性能前提下，使用單價(jià)相對(duì)便宜的機(jī)型 (如 INTEL -> AMD)

  • 降低 On Demand 計(jì)費(fèi)類型占比，提升 RI & Savings Plan 合約購買比例

  • 有溢出的部分，盡可能多使用 Spot 競(jìng)價(jià)機(jī)型

• 調(diào)整集群內(nèi)計(jì)算實(shí)例掛載 EBS 卷

• • 啟用 Core 分區(qū)獨(dú)占模式，將存儲(chǔ)與計(jì)算節(jié)點(diǎn)徹底分離

  • 實(shí)踐測(cè)算，在存算分離離線 EMR 集群中，EBS 的配置可結(jié)合計(jì)算節(jié)點(diǎn)核心數(shù)規(guī)格線性配比 (如 1C:10G)，實(shí)時(shí)計(jì)算集群中因狀態(tài)存儲(chǔ)，比例可酌情往大調(diào)整

  • 自動(dòng)化批量調(diào)整 GP2->GP3

存儲(chǔ)層優(yōu)化

在云上，前期主要使用 EBS 卷和 S3 兩類存儲(chǔ)服務(wù)。前者由于單價(jià)較低，使用者容易忽視其成本影響，當(dāng)集群擴(kuò)大一定規(guī)模時(shí)，特別是早期低規(guī)格實(shí)例數(shù)量較多時(shí)，EBS 卷的使用容量會(huì)隨之激增，導(dǎo)致成本上漲，EBS 卷的治理方向可參考上文所列，本節(jié)不再贅述。

由于湖倉的建設(shè)和推廣使用，S3 存儲(chǔ)用量每年均大幅度上漲，導(dǎo)致存儲(chǔ)費(fèi)用極其可觀。早期對(duì) S3 的使用缺乏認(rèn)知，結(jié)合業(yè)務(wù)讀寫的特性 (缺少熱度觀測(cè)和存在歷史數(shù)據(jù)回刷)，數(shù)據(jù)均存放在標(biāo)準(zhǔn)層 (Standard Storage)，避免請(qǐng)求費(fèi)大于存儲(chǔ)費(fèi)的情況。因此，首次針對(duì) S3 存儲(chǔ)開展治理行動(dòng)，集中在：

• 清理無效數(shù)據(jù)和調(diào)整數(shù)據(jù)保留周期

• 關(guān)閉數(shù)據(jù)桶的版本控制

• 未完成分段上傳清理

治理完成后，共計(jì)清理數(shù)據(jù)容量 PB+，以標(biāo)準(zhǔn)層費(fèi)率計(jì)算月削減成本十萬 +。

流量層優(yōu)化

云服務(wù) (S3、EC2 等) 使用過程若存在跨可用區(qū)數(shù)據(jù)傳輸是需要額外收取費(fèi)用，具體收費(fèi)條目可查看官網(wǎng)說明。為保障計(jì)算集群可用性和穩(wěn)定性，我司在 A/B 區(qū)分別構(gòu)建了多個(gè)業(yè)務(wù) EMR 集群，直接加劇了此類費(fèi)用的產(chǎn)生，由于流量費(fèi)用夾雜在 EC2 的費(fèi)用中，難以被直接觀測(cè)到，直至成本出現(xiàn)較大異常增量時(shí)才被分析識(shí)別出來。

在 SA 和 TAM 的協(xié)助下，分析各 VPC 間數(shù)據(jù)流向及所產(chǎn)生的成本條目，最終完整地呈現(xiàn)流量成本構(gòu)成：

• VPC Peering：主要成本產(chǎn)生自離線 Bigdata 和在線 PROD 的 VPC 之間數(shù)據(jù)往返傳輸流量

• DTAZ-Bigdata VPC：bigdata VPC 內(nèi)部 DTAZ 流量，業(yè)務(wù)流向?yàn)?AZ1 的 kafka 到 AZ2 的 EMR，再返回到 AZ1 的分布式數(shù)據(jù)庫

• NAT GW Bigdata：主要為 EMR 通過 NAT GW 拉取 S3 數(shù)據(jù)

• S3 DTO 與 EC2 VPN DTO：S3 公網(wǎng)拉取數(shù)據(jù)與建立專線通道從 bigdata VPC 拉數(shù)據(jù)

以此依據(jù)可得出優(yōu)化措施為：

• 分析跨可用區(qū)流量熱點(diǎn)，調(diào)整 EMR 集群計(jì)算任務(wù)分布架構(gòu)，盡量往數(shù)據(jù)源可用區(qū)靠近

• 調(diào)整 EMR 集群訪問 S3 endpoint 方式

1.2 構(gòu)建更周全的分析方法

CUR+ 自定義標(biāo)簽

首次治理即取得明顯成效后，深刻認(rèn)知到洞察成本花費(fèi)在哪里的重要性，而要實(shí)現(xiàn)洞察的前提是要熟悉并掌握 CUR(Cost and Usage Report) 清單分析 (詳見鏈接：CUR 連接)。CUR 清單里提供較為精細(xì)的費(fèi)用明細(xì)數(shù)據(jù)，結(jié)合各種計(jì)費(fèi)規(guī)則基本可還原出月成本構(gòu)成，計(jì)費(fèi)規(guī)則可從 TAM 團(tuán)隊(duì)對(duì)接獲取。

除 CUR 基本數(shù)據(jù)詞典定義外，我司設(shè)計(jì)了一套標(biāo)簽體系，進(jìn)一步區(qū)分清單中每條費(fèi)用對(duì)應(yīng)使用方歸屬，標(biāo)簽涵蓋：

• 系統(tǒng)標(biāo)簽：數(shù)據(jù)中心 region、環(huán)境 env、應(yīng)用 appId、歸屬域 domain

• 應(yīng)用擴(kuò)展標(biāo)簽：平臺(tái)類型 system、實(shí)例類型 instance-type ......

• 特定領(lǐng)域標(biāo)簽：emr 集群名 emr-cluster、emr 實(shí)例角色 emr-role、kafka 集群名 kafka-cluster ......

為便于統(tǒng)一分析，我們對(duì) CUR 清單數(shù)據(jù)建模后使用 Spark 匯入湖倉，再整合對(duì)接到自研 BI 平臺(tái)，便于持續(xù)監(jiān)控和上卷下鉆分析。也可采用云原生服務(wù)組合方式實(shí)現(xiàn)，如 Glue+Lambda+Athena+QuickSight。下圖為 S3 成本下鉆分析的一個(gè)示例，通過細(xì)分操作類型可進(jìn)一步確定成本分布是否合理。

基于這份每日成本清單明細(xì)，在后續(xù)的一項(xiàng)治理行動(dòng) (針對(duì)桶級(jí)別全局開啟智能分層上線) 提供了很重要的數(shù)據(jù)依據(jù)，而智能分層的全面上線在存儲(chǔ)層帶來年節(jié)約上百萬的治理效果。

inventory 和 access log 組合

S3 本身提供了一些監(jiān)控工具，其中筆者認(rèn)為最為重要的有兩個(gè)：inventory 和 access log。

inventory

inventory 是一個(gè)元數(shù)據(jù)信息統(tǒng)計(jì)鏡像功能，用戶自定義前綴匹配和指定時(shí)間點(diǎn)后，可導(dǎo)出一份對(duì)象元數(shù)據(jù)信息到指定數(shù)據(jù)桶 (詳見: s3 inventory)，用戶可據(jù)此開展治理行動(dòng)項(xiàng) (抓大放小)，這也是前期我們針對(duì) S3 治理的一個(gè)重要數(shù)據(jù)依據(jù)來源。inventory 導(dǎo)出后由 manifest 和 symlink 分割不同時(shí)間周期的元數(shù)據(jù)情況，對(duì)于 ORC 和 Parquet 格式的清單文件，不支持使用 Apache Hive 和 Spark 讀取 symlink.txt 文件，因此建議 symlink 設(shè)置為 CSV 格式導(dǎo)出，便于進(jìn)一步數(shù)據(jù)處理。

在 inventory 文件中存儲(chǔ)每個(gè)對(duì)象的信息 (絕對(duì)路徑，如 s3://bucket1/xxxx/xxxx/file1.parquet)，而在實(shí)踐過程中，此類明細(xì)數(shù)據(jù)對(duì)于治理開展幫助不大，因?yàn)橛脩粜枰氖敲恳患?jí)路徑的情況。針對(duì)此問題，我們使用 spark 對(duì) inventory 文件中每個(gè)對(duì)象信息按路徑拍平，并逐級(jí)處理兩類操作：

• 聚合出每級(jí)路徑大小、文件數(shù)

• 遞歸將底層文件最后更新時(shí)間反射到上層每一級(jí)路徑

path                      size      files_cnt      last_modified_date
s3://bucket1/xxx          20g          2000        2025-08-28 15:28:30
s3://bucket1/xxx/xxxx     10g          1000        2025-08-28 15:28:30

經(jīng)此處理后的 inventory 數(shù)據(jù)，可迅速確定各級(jí)路徑 (對(duì)象存儲(chǔ)中無路徑這一概念，此為虛擬概念) 的大小和最后更新時(shí)間，這為治理過程判斷極大地提高了效率和準(zhǔn)確性。

access log

access log 詳細(xì)記錄了上層各類應(yīng)用對(duì) S3 存儲(chǔ)桶提交的各種請(qǐng)求操作，因此在安全審計(jì)和訪問查詢方面很有用，開啟方式詳見：s3 access log。以我們的數(shù)據(jù)規(guī)模對(duì)應(yīng)每日產(chǎn)生的 access log 量達(dá)數(shù)十億條，分析 access log 的難度和成本無疑是巨大的。到了治理第二階段，再依靠于人工確認(rèn)數(shù)據(jù)訪問情況顯然不現(xiàn)實(shí)，此時(shí)迫切需要真實(shí)的數(shù)據(jù)文件訪問熱度信息。我們使用 Spark 將每日產(chǎn)生的 access log 做 ETL 處理后接入湖倉 ODS 層，再將其與 inventory 結(jié)合，最終還原出每一級(jí)路徑的訪問和元數(shù)據(jù)信息:

bucket：桶名
path：路徑信息
size：路徑大小
files_count：路徑文件數(shù)
request_count：請(qǐng)求總次數(shù)
operation：操作類型
operation_count：操作次數(shù)
operation_datetime：最后請(qǐng)求時(shí)間
last_modified_date：最后修改時(shí)間
cur_time：日期分區(qū)

s3 inventory 是隔日類鏡像式導(dǎo)出，客觀上會(huì)存在元數(shù)據(jù)空洞，例：在兩次導(dǎo)出間隔期間若存在某些對(duì)象文件創(chuàng)建和刪除，所操作的對(duì)象文件不會(huì)被 inventory 記錄，但會(huì)存在于 access log 中。針對(duì)此問題，我們的做法是將 inventory 和 access log 以 bucket+path 為關(guān)聯(lián)鍵，按生成時(shí)間點(diǎn)切割后做 Full Join，如此可將數(shù)據(jù)訪問熱度最大化進(jìn)行還原，過程實(shí)現(xiàn)參考下圖：

inventory 和 access log 組合為后續(xù)開展的一系列 s3 治理專項(xiàng)提供極為重要的數(shù)據(jù)依據(jù)，在存儲(chǔ)層成本節(jié)約做出巨大貢獻(xiàn)。

1.3 階段一治理小結(jié)

第一階段治理通常具有最高 ROI，主要得益于前期粗放式資源使用模式下存在的優(yōu)化空間。歷經(jīng)一個(gè)季度分批推進(jìn)，以成本占比作為優(yōu)化順序，完成上述三個(gè)層面優(yōu)化專項(xiàng)后，實(shí)現(xiàn)不影響業(yè)務(wù)增長前提下月成本同比削減 32% 的治理成果，也為第二階段更深層次的治理奠定了一些分析基礎(chǔ)。

成本優(yōu)化與控制

完成第一階段的成本分析方法構(gòu)建與治理后，雖然取得了顯著的成本節(jié)約效果，但隨著業(yè)務(wù)持續(xù)增長和數(shù)據(jù)規(guī)模不斷擴(kuò)大，僅依靠一次性治理行動(dòng)難以實(shí)現(xiàn)長期的成本控制目標(biāo)。因此，需要從更深層次的平臺(tái)能力建設(shè)和技術(shù)架構(gòu)改造入手，構(gòu)建可持續(xù)的成本優(yōu)化措施。

第二階段圍繞兩個(gè)維度展開：一是平臺(tái)能力建設(shè)，從數(shù)據(jù)生命周期管理、任務(wù)性能診斷、計(jì)算效率提升等方面提升平臺(tái)的內(nèi)在效率；二是技術(shù)改造專項(xiàng)，從計(jì)算引擎升級(jí)、架構(gòu)遷移、資源使用優(yōu)化等方面實(shí)現(xiàn)技術(shù)棧的整體成本降低。通過這種"內(nèi)外兼修"的優(yōu)化策略，建立長效的成本管控機(jī)制，確保在業(yè)務(wù)快速發(fā)展的同時(shí)，成本增長保持在可控范圍內(nèi)。

2.1 平臺(tái)能力建設(shè)

數(shù)據(jù)生命周期管理

數(shù)據(jù)平臺(tái)建設(shè)過程中，為滿足業(yè)務(wù)使用所需引入多種數(shù)據(jù)源，主要有 Hive、Clickhouse、Elasticsearch、Cassandra。隨著數(shù)據(jù)業(yè)務(wù)擴(kuò)增和時(shí)間推移，大量歷史數(shù)據(jù)長期占用存儲(chǔ)資源，但實(shí)際訪問頻次不一，造成資源浪費(fèi)。若以人工方式實(shí)現(xiàn)數(shù)據(jù)清理，面臨著效率低下和難以規(guī)?；芾淼膯栴}，因此需要一個(gè)自動(dòng)化數(shù)據(jù)生命周期管理工具。

該工具設(shè)計(jì)之初即涵蓋數(shù)據(jù)平臺(tái)常用數(shù)據(jù)源對(duì)象，數(shù)據(jù)源對(duì)象從資產(chǎn)元數(shù)據(jù) API 接口獲取，自動(dòng)按域過濾，從源頭上規(guī)避用戶配置規(guī)則執(zhí)行時(shí)誤操作其他域同名對(duì)象。數(shù)據(jù)生命周期是基于預(yù)定義規(guī)則自動(dòng)管理數(shù)據(jù)平臺(tái)存量數(shù)據(jù)的系統(tǒng)化解決方案，支持對(duì)數(shù)據(jù)集按不同執(zhí)行窗口實(shí)現(xiàn)自動(dòng)清理，保障數(shù)據(jù)留存在合理區(qū)間。同時(shí)具備執(zhí)行監(jiān)控能力，支持清理容量大小、記錄數(shù)等量化指標(biāo)，便于事后治理效果評(píng)估。運(yùn)營至今，每日清理的數(shù)據(jù)容量可觀，實(shí)現(xiàn)清理量抵消增量的目標(biāo)。

此外，還開發(fā)了任務(wù)生命周期管理，用于數(shù)據(jù)開發(fā)驗(yàn)證階段的任務(wù)運(yùn)行管控，避免開發(fā)驗(yàn)證類任務(wù)長期運(yùn)行造成計(jì)算資源浪費(fèi)。

Spark 任務(wù)診斷治理

進(jìn)入主題之前，先提個(gè)問題：為什么需要診斷治理？

數(shù)據(jù)開發(fā)者經(jīng)常面臨的問題有：

• 資源使用不平衡：比較常見的情況是集群中內(nèi)存被申請(qǐng)滿了，但是 CPU 還有剩余，亦或 CPU 用光但內(nèi)存還有剩余

• 運(yùn)行時(shí)間不穩(wěn)定：同個(gè)作業(yè)多次運(yùn)行時(shí)間波動(dòng)幅度大

• 資源濫用：每個(gè)業(yè)務(wù)方都希望自己的作業(yè)能盡可能快的完成，導(dǎo)致資源被濫用，帶來一些不必要的資源緊張

從這些問題不難得出任務(wù)診斷治理的必要性。

診斷治理平臺(tái)的實(shí)現(xiàn)分為 4 個(gè)模塊：數(shù)據(jù)采集 -> 診斷分析 -> 生成報(bào)告 -> 治理優(yōu)化。

數(shù)據(jù)采集

利用原生 spark listener bus 機(jī)制，任務(wù)指標(biāo)數(shù)據(jù)采集后推送到 kafka，如下圖所示：

診斷分析

使用 Flink 對(duì) kafka 中指標(biāo)數(shù)據(jù)做診斷分析處理，支持診斷類型：

• 資源成本類：任務(wù) CPU 利用率、任務(wù)內(nèi)存利用率、任務(wù)花費(fèi)

• 耗時(shí)類：Application 運(yùn)行時(shí)長、Job/Stage 階段運(yùn)行時(shí)長

• 失敗類：Application/Job/Stage/Task 粒度失敗檢測(cè)

• 空跑類：任務(wù) submit 之后未提交 Job 運(yùn)行

• 效率類：數(shù)據(jù)傾斜、Task 長拽尾 or 讀寫卡頓、大表掃描、GC 異常...

診斷類型較多，以任務(wù) CPU 和內(nèi)存利用率的診斷為例簡(jiǎn)述實(shí)現(xiàn)過程

• 任務(wù) CPU 利用
  

• 任務(wù)內(nèi)存利用率 (以堆內(nèi)內(nèi)存為例)

• 實(shí)現(xiàn)過程類似 CPU 利用率，不同之處是采用 peakMemory 作為計(jì)算指標(biāo)，若能采集 executor GC 獲取內(nèi)存利用率，會(huì)更精準(zhǔn)一些

生成報(bào)告

上游診斷分析處理后，診斷服務(wù)按 application 粒度將結(jié)果指標(biāo)整合，形成最終的任務(wù)診斷報(bào)告。報(bào)告采用結(jié)構(gòu)化設(shè)計(jì)，從兩個(gè)方面呈現(xiàn)：一是任務(wù)元數(shù)據(jù)信息，如歸屬集群、任務(wù) ID、任務(wù)名、負(fù)責(zé)人、耗時(shí)等；二是診斷信息，除診斷異常等級(jí)、命中異常項(xiàng)這類概要信息外，用戶可切換診斷類型頁查看詳情數(shù)據(jù)分析，便于快速異常定位。

治理優(yōu)化效果

所產(chǎn)生的診斷數(shù)據(jù)結(jié)果，平臺(tái)運(yùn)維人員可推進(jìn)數(shù)據(jù)開發(fā)人員優(yōu)化。工具上線后，數(shù)據(jù)運(yùn)維團(tuán)隊(duì)多次開展 Spark 任務(wù)資源利用率治理，實(shí)測(cè)結(jié)果顯示，在執(zhí)行時(shí)間相近前提下，離線計(jì)算集群資源水位線最高能下降 20~30%，成本節(jié)約效果顯著。

Spark 小文件自動(dòng)合并

作為數(shù)據(jù)從業(yè)人員，對(duì)于 Spark 計(jì)算生成小文件的問題應(yīng)不陌生。數(shù)據(jù)開發(fā)者常見做法是增加 repartition 算子以減少小文件的生成，但通常來說，每個(gè)批次生成數(shù)據(jù)集大小、動(dòng)態(tài)分區(qū)插入數(shù)據(jù)量等均會(huì)給數(shù)據(jù)開發(fā)人員造成困擾，如何配置才能達(dá)到理想狀態(tài)是個(gè)難題。為此，我們深入研究社區(qū)內(nèi)幾種小文件合并實(shí)現(xiàn)方案后，最終選擇自研實(shí)現(xiàn)。

合并的核心思路是在 Commit 前進(jìn)行攔截，通過重寫 SparkSqlParquetOutputCommitter 方式加入合并 job 檢測(cè)，當(dāng)數(shù)據(jù)開發(fā)人員提交的 Spark 任務(wù)生成的小文件達(dá)到閾值時(shí)，會(huì)串行觸發(fā) compact 和 delete Job，且針對(duì)小文件眾多的情況，會(huì)多輪觸發(fā) compact 直至達(dá)到預(yù)設(shè)閾值。

小文件合并插件上線后效果 (取一線上表為例)

從圖中可以看出，小文件合并插件上線后，天分區(qū)文件個(gè)數(shù)大幅下降，對(duì)應(yīng)的天分區(qū)路徑訪問次數(shù)也隨之明顯減少，具體數(shù)據(jù)顯示：?jiǎn)我惶旆謪^(qū)文件數(shù)減少 97%，下游訪問頻次減少 85%，其他小文件表的合并效果因小文件規(guī)模數(shù)量而異。

小文件合并過程會(huì)對(duì)上游任務(wù)造成一定延時(shí)，但換來的是下游計(jì)算任務(wù)效率大幅提升和資源有效削減，產(chǎn)生的影響正面大于負(fù)面。這一點(diǎn)可通過小文件合并插件上線后運(yùn)行一段時(shí)間的數(shù)據(jù)得到驗(yàn)證：離線任務(wù)診斷系統(tǒng)新生成的低資源利用率待治理任務(wù)數(shù)達(dá)到總 DAG 數(shù) 25%，證實(shí)了整體計(jì)算任務(wù)效率得到提升。

2.2 技術(shù)架構(gòu)改造專項(xiàng)

EMR 升級(jí)

我司自 2019 年開始使用 EMR。

彼時(shí)，Spark3.0 發(fā)布不久，雖推出許多重磅特性，但其穩(wěn)定性有待提升，結(jié)合 hudi 官方建議的集成版本，內(nèi)部研討決定基于 Spark 2.4.x 和 Hudi 0.5.x 構(gòu)建離線湖倉 1.0 版本。之后 Hudi 社區(qū)發(fā)展迅猛，陸續(xù)推出許多數(shù)據(jù)湖領(lǐng)域稀缺特性，且在實(shí)時(shí)湖倉領(lǐng)域 flink-hudi 也日趨完善，結(jié)合數(shù)據(jù)業(yè)務(wù)發(fā)展在性能和功能方面述求，使得升級(jí)成為剛需。

持續(xù)至今，已完成兩次 EMR 原地升級(jí) (EMR5 -> EMR6 -> EMR7)，第二次是今年剛完成，均涉及集群管理、元數(shù)據(jù)、存儲(chǔ)、離線計(jì)算、實(shí)時(shí)計(jì)算等全平臺(tái)范圍組件，核心組件版本迭代如下：

spark: 2.4.5 -> 3.1.1 -> 3.5.2
hudi: 0.5.3 -> 0.10.0 -> 0.15.0
flink: 1.11 -> 1.13 -> 1.18
hadoop: 2.8.5 -> 3.2.1 -> 3.4.0
hive: 2.3.4 -> 3.1.2 -> 3.1.3

每次 EMR 升級(jí)難度極大，過程中如履薄冰，需大膽規(guī)劃，小心求證。升級(jí)推進(jìn)過程較為漫長，時(shí)間跨度周期以半年計(jì)，可概括為如下步驟：

• 風(fēng)險(xiǎn)評(píng)估：了解鏈路主要組件新版本特性，梳理風(fēng)險(xiǎn)點(diǎn)，確定升級(jí)目標(biāo)大致可行性

• 制定計(jì)劃：制定升級(jí)改造計(jì)劃，拆解升級(jí)目標(biāo)映射到個(gè)人，以串行與并行方式推進(jìn)

• 升級(jí)測(cè)試：升級(jí)功能細(xì)粒度測(cè)驗(yàn)，評(píng)估是否符合預(yù)期以及投入人力周期

• 兼容性驗(yàn)證：涉及平臺(tái)底層，需特別關(guān)注上層應(yīng)用兼容性，如讀寫訪問、任務(wù)提交、數(shù)據(jù)兼容性等

• 切換方案：制定升級(jí)切換計(jì)劃和回滾方案，分批次進(jìn)行切換，將問題影響程度降至最小

• 逐步升級(jí) & 復(fù)盤整改：組件 & 服務(wù)單位功能按自測(cè) -->PRE 集群 -->PROD 集群逐步升級(jí)，將遇到的問題均記錄下來，總結(jié)、復(fù)盤和整改。當(dāng)存在較大范圍共性問題時(shí)，修復(fù)后視情況校正切換方案 (主體不變，細(xì)節(jié)調(diào)整隨機(jī)應(yīng)變)，直至完成全線切換

事后復(fù)盤整個(gè)升級(jí)專項(xiàng)推進(jìn)過程，存在諸多思慮不周之處。雖然主體方向未變，但過程中充滿各種變數(shù) (客觀和主觀因素)，有些變數(shù)甚至足以影響專項(xiàng)的落地實(shí)施，尤其是行進(jìn)至中后期，非主觀性阻力因素尤為嚴(yán)重。得益于數(shù)據(jù) & 上下游業(yè)務(wù)部門的大力支持，團(tuán)隊(duì)以不變應(yīng)萬變，見招拆招，攻克諸多困難，一起完成升級(jí)專項(xiàng)落地。

經(jīng)歷兩次全面升級(jí)后，數(shù)據(jù)平臺(tái)在多個(gè)維度取得收益。性能方面，Spark 的新特性在大部分離線場(chǎng)景計(jì)算效率提升 30~50%，成本優(yōu)化效果明顯；功能方面，hudi 和 flink 大量的新版本特性完善了流式湖倉管理能力，滿足業(yè)務(wù)對(duì)數(shù)據(jù)新鮮度和計(jì)算效率的述求；穩(wěn)定性方面，計(jì)算任務(wù)穩(wěn)定性得到明顯提升的同時(shí)，生態(tài)兼容性也得到較好的整合，為數(shù)據(jù)平臺(tái)長期穩(wěn)定運(yùn)行奠定了堅(jiān)實(shí)的基礎(chǔ)。

Flink 架構(gòu)優(yōu)化

前文用較大的篇幅介紹了關(guān)于 Spark 成本優(yōu)化，本節(jié)著重闡述我司如何針對(duì) Flink 進(jìn)行成本優(yōu)化，圍繞兩個(gè)層面展開：Flink 容器化演進(jìn)和 Flink Hudi 優(yōu)化。

Flink 容器化

平臺(tái)建設(shè)初期，F(xiàn)link 任務(wù)運(yùn)行在 EMR YARN 集群中。持續(xù)幾年后，隨著業(yè)務(wù)團(tuán)隊(duì)計(jì)算任務(wù)擴(kuò)增，穩(wěn)定性逐漸成為數(shù)據(jù)平臺(tái)團(tuán)隊(duì)面臨的重大挑戰(zhàn)，主要體現(xiàn)在：資源隔離粒度粗糙存在資源爭(zhēng)搶、集群計(jì)算節(jié)點(diǎn)容易被大狀態(tài)任務(wù)打崩、集群擴(kuò)縮容速度有限等幾方面?；诜€(wěn)定性和成本因素考量，于 2024 年初啟動(dòng) Flink 容器化適配工作，簡(jiǎn)單列舉 Flink on YARN vs K8S 對(duì)比：

確定方向后，下一步則是部署模式的選型 (Native vs Operator)，選型期間做了較深入的調(diào)研，包含深度研讀社區(qū)文檔、部署驗(yàn)證、與業(yè)內(nèi)多個(gè)大廠技術(shù)團(tuán)隊(duì)交流，最終結(jié)合當(dāng)前平臺(tái)建設(shè)現(xiàn)狀及未來動(dòng)態(tài)彈性伸縮的需求，選擇 FKO(Flink Kubernetes Operator) 方案。選型 FKO 方案的關(guān)鍵因素：

• 便捷式管理集群作業(yè)：FKO 提供了更高級(jí)的抽象和管理功能，專用于管理和運(yùn)行 Flink 作業(yè)。它可以處理 Flink 特定的配置、依賴項(xiàng)和作業(yè)管理，簡(jiǎn)化作業(yè)的部署和操作，無需為不同 job 定義各自單獨(dú) YAML 聲明。FKO 可以自動(dòng)管理 Flink 作業(yè)的生命周期，包括創(chuàng)建、更新、擴(kuò)展和停止作業(yè)，同時(shí)可以按需求自動(dòng)縮放作業(yè)資源，并提供作業(yè)級(jí)別的操作和監(jiān)控功能。

• 聲明式：以腳本命令行創(chuàng)建需要額外確認(rèn)資源是否按預(yù)期創(chuàng)建成功，而借助 FKO 的控制器模式，用戶只需聲明所期望的集群運(yùn)行資源及狀態(tài)，其余全部交由 FKO 保證實(shí)現(xiàn)。如運(yùn)行中突然出現(xiàn) JM/TM 節(jié)點(diǎn)故障，F(xiàn)KO 會(huì)自動(dòng)重建節(jié)點(diǎn)以恢復(fù)集群運(yùn)行狀態(tài)。

• 故障恢復(fù)：FKO 集成了 Flink 的故障恢復(fù)機(jī)制，如 Checkpoint 和自動(dòng)重啟恢復(fù)：1. 用戶只需指定 autoSavePointSeconds 和保存路徑，F(xiàn)KO 會(huì)自動(dòng)定期保存快照；2. 流式任務(wù)的顯著特點(diǎn)是長期運(yùn)行，運(yùn)行過程中可能面臨各種因素導(dǎo)致任務(wù)失敗，借助 FKO，用戶可以指定任務(wù)恢復(fù)策略 FromSavePointOnFailure，自動(dòng)處理作業(yè)的狀態(tài)恢復(fù)和故障處理，提供更可靠的作業(yè)運(yùn)行環(huán)境。

• 生態(tài)集成成熟度：FKO 與 Flink 生態(tài)系統(tǒng)緊密集成，可以使用 Flink 的特性和工具，如保存點(diǎn)、檢查點(diǎn)、狀態(tài)后端、指標(biāo)等，還支持 Flink 配置和用戶代碼的自定義，以滿足特定的需求。同時(shí)集成 Ingress，方便用戶訪問 WEB UI 查看作業(yè)運(yùn)行情況或者查看運(yùn)行日志。

歷經(jīng)一個(gè)季度的開發(fā)迭代，內(nèi)部流計(jì)算任務(wù)管理平臺(tái)集成 FKO 正式上線，之后逐步推廣給數(shù)據(jù)開發(fā)者使用。得益于前期的充分調(diào)研和驗(yàn)證，F(xiàn)link ON YARN -> Kubernetes 的切換過程整體較為平滑，雖有間歇性問題出現(xiàn)，但都被數(shù)據(jù)團(tuán)隊(duì)攻克解決，未發(fā)生重大阻塞。最終我們花費(fèi)近兩個(gè)季度時(shí)間完成全部通用性任務(wù)切換，再結(jié)合資源利用率的治理推進(jìn)，實(shí)現(xiàn)通用流計(jì)算集群月成本削減 30% 的目標(biāo)。

Flink Hudi 優(yōu)化

社區(qū)內(nèi)關(guān)于 Flink Hudi 的優(yōu)化案例眾多，本節(jié)僅列舉我司內(nèi)部實(shí)踐后效果明顯的兩個(gè)專題案例。

Hudi 表入湖合并

Flink Hudi 實(shí)時(shí)表入湖從零開始擴(kuò)大使用規(guī)模，初期出于表接入效率考量，采用表與實(shí)時(shí)任務(wù)一對(duì)一捆綁關(guān)系。至第二階段成本治理時(shí)，實(shí)時(shí)表入湖所占用的計(jì)算資源已上千核，成本比重較為明顯。因此，實(shí)時(shí)表入湖合并很自然地被列為一個(gè)成本優(yōu)化方向。

社區(qū)雖提供了一套單 job 多表 sink 解決方案，但經(jīng)過一段時(shí)間實(shí)踐后，發(fā)現(xiàn)在性能和穩(wěn)定性方面難以滿足我司使用需求，主要問題包括：?jiǎn)?job 內(nèi)大表可能占用過多資源影響小表寫入、單表接入問題可能導(dǎo)致整個(gè)作業(yè)失敗、單 job 表數(shù)量增加時(shí)性能會(huì)急劇性下降、不同表引用不同配置時(shí)管理復(fù)雜。經(jīng)調(diào)研后，另行實(shí)現(xiàn)合并方案，核心設(shè)計(jì)思路：同源 source 接入后按表粒度構(gòu)建 multi job 提交運(yùn)行，作業(yè)內(nèi)表和 job 保持一對(duì)一捆綁關(guān)系，提交后每個(gè) job 各自運(yùn)行 Pipelines.hoodieStreamWrite。以一個(gè) topic(mysql db) 多表配置為例，數(shù)據(jù)管理人員可在自研數(shù)據(jù)集成服務(wù)中按不同階段表數(shù)據(jù)量級(jí)拆分為多個(gè)批次分別創(chuàng)建作業(yè)運(yùn)行，從而極大地消除了穩(wěn)定性方面的影響。

合并分批推進(jìn)，該項(xiàng)完成后取得 Flink Hudi 入湖集群計(jì)算資源削減 20% 的治理收益。

Bucket Index

實(shí)時(shí)表入湖合并方案上線后雖然使集群資源用量得到削減，但在數(shù)據(jù)業(yè)務(wù)團(tuán)隊(duì)對(duì)數(shù)據(jù)新鮮度愈發(fā)強(qiáng)烈的背景下，一段時(shí)間后規(guī)模用量再度翻涌上來。此外，在 flink on emr yarn 模式下經(jīng)常因計(jì)算節(jié)點(diǎn)異常導(dǎo)致任務(wù)重啟現(xiàn)象，而 flink hudi 每次重啟狀態(tài)恢復(fù)的代價(jià)極大，個(gè)別大表會(huì)卡在 bootstrap 階段長達(dá)半小時(shí)以上，導(dǎo)致實(shí)時(shí) ODS 層數(shù)據(jù) SLA 頻繁遭受質(zhì)疑。

針對(duì)此問題的解法來自于社區(qū)，這正是開源技術(shù)的魅力所在。Apache Hudi 在 0.14 版本支持 Bucket Index 方案，與其他索引機(jī)制相比尤為特殊，其核心實(shí)現(xiàn)原理是基于記錄鍵哈希值進(jìn)行確定性分桶，通過預(yù)分桶機(jī)制避免全局索引性能開銷，客戶端在插入過程中，直接定位傳入記錄對(duì)應(yīng)的待寫入文件位置，無需顧及全局性記錄鍵分布情況，原有備受詬病的 bootstrap 和大狀態(tài)存儲(chǔ)問題也隨之得到根除。

因 Bucket Index 改造涉及實(shí)時(shí) ODS 層數(shù)據(jù)，需嚴(yán)加謹(jǐn)慎對(duì)待。數(shù)據(jù)團(tuán)隊(duì)先針對(duì)該方案實(shí)現(xiàn)原理進(jìn)行剖析研究，接著集成到平臺(tái)上驗(yàn)證測(cè)試，平臺(tái)開發(fā)人員按功能和性能類別分別進(jìn)行驗(yàn)證，覆蓋十幾種測(cè)試用例場(chǎng)景，充分驗(yàn)證效果符合預(yù)期后再結(jié)合 Flink & Hudi 升級(jí)規(guī)劃，分批切換生效，最終無損完成全量 flink hudi ods 表 (上千張) 的升級(jí)切換。

在推進(jìn)升級(jí)切換的同時(shí)，也完成全量 hudi 表任務(wù) flink on yarn -> k8s 的平滑切換，Hudi Bucket Index 方案上線后效果極其明顯，以如下一組數(shù)據(jù)體現(xiàn)：

2.3 階段二治理小結(jié)

相比于第一階段，第二階段的成本治理邁入更深層次的優(yōu)化領(lǐng)域，為達(dá)成治理目標(biāo)，除上文列舉的典型優(yōu)化方案外，內(nèi)部還制定了多個(gè)治理專項(xiàng)，采用雙線并行推進(jìn)模式，在保持業(yè)務(wù)增量的前提下再度實(shí)現(xiàn)月成本節(jié)約 30% 的治理效果。

體系化治理構(gòu)建

前兩個(gè)階段成本治理以技術(shù)視角開展，在取得成果的同時(shí)也意識(shí)到一些局限性，即單純依賴技術(shù)優(yōu)化難以實(shí)現(xiàn)可持續(xù)性的體系化成本管控，需從更高維度的能力建設(shè)入手。阿里的數(shù)據(jù)治理實(shí)踐指出，成本治理的核心目標(biāo)應(yīng)聚焦于人效和資源，通過技術(shù)平臺(tái)建設(shè)提升單位人效也是一種至關(guān)重要且有效的降本措施，這也是我司投入大量資源建設(shè)大數(shù)據(jù)研發(fā)治理平臺(tái)套件的一大根因。

在平臺(tái)范圍內(nèi)，從數(shù)據(jù)生產(chǎn)到數(shù)據(jù)消費(fèi)涉及的環(huán)節(jié)和處理鏈路繁多且復(fù)雜，而首要難關(guān)就是如何識(shí)別并分離數(shù)據(jù)處理鏈路。若能針對(duì)每個(gè)處理環(huán)節(jié)給予標(biāo)簽定義，再輔以一定程度的量化 (計(jì)量和計(jì)費(fèi))，即可持續(xù)性進(jìn)行全鏈路數(shù)據(jù)成本治理。治理的理想狀態(tài)是經(jīng)由平臺(tái)工具化將治理過程的理念、方法、流程沉淀下來，再結(jié)合多維度治理措施，實(shí)現(xiàn)在數(shù)據(jù)開發(fā)交付過程中順帶完成數(shù)據(jù)治理，達(dá)成治技合一的效果。整體框架遵循如下原則：

3.1 成本數(shù)倉

成本數(shù)倉按 ODS、DWD/DWS、DIM、ADS 等經(jīng)典層級(jí)結(jié)構(gòu)設(shè)計(jì)即可，層級(jí)越簡(jiǎn)單計(jì)算損耗越小。

指標(biāo)定義

在大數(shù)據(jù)平臺(tái)中成本消耗來源眾多，典型成本來源包括：

• 物理機(jī)計(jì)算資源：CPU、GPU、內(nèi)存、硬盤等

• 網(wǎng)絡(luò)傳輸：交換機(jī)、路由器、網(wǎng)絡(luò)帶寬等

• 機(jī)房基礎(chǔ)設(shè)施：機(jī)柜租賃、電費(fèi)、防火墻等

• 大數(shù)據(jù)平臺(tái)架構(gòu)各層軟件服務(wù)研發(fā)成本

現(xiàn)實(shí)中，我們很難將單一性計(jì)算任務(wù)與上述所有環(huán)節(jié)鏈路花費(fèi)關(guān)聯(lián)起來，因此只需將數(shù)據(jù)平臺(tái)上可用于優(yōu)化和治理部分成本信息予以量化即可，于大數(shù)據(jù)平臺(tái)而言，主要以 存儲(chǔ)和計(jì)算 這兩類指標(biāo)作為量化表達(dá)，如：

• 離線計(jì)算任務(wù)：CPU、MEM、計(jì)算緩存容量、任務(wù)歸屬元數(shù)據(jù)信息

• Hive、S3：表 / 分區(qū)存儲(chǔ)容量、路徑訪問頻次及類型、資產(chǎn)歸屬元數(shù)據(jù)信息

量化

計(jì)算實(shí)際成本的規(guī)則極為復(fù)雜，如階梯式計(jì)費(fèi)、折扣、代金券、波動(dòng)用量、分?jǐn)偟?，需要系統(tǒng)性工程建設(shè)。受限于大量細(xì)分計(jì)費(fèi)項(xiàng)無法關(guān)聯(lián)到業(yè)務(wù)團(tuán)隊(duì)一級(jí)，一種較為可行的量化方案是結(jié)合業(yè)務(wù)用量再構(gòu)建一層抽象定價(jià)關(guān)系，即以達(dá)成收支平衡為目標(biāo)對(duì)云資源用量再作售賣。

計(jì)算層

對(duì)于計(jì)算任務(wù)的資源指標(biāo)量化均按 CPU(vcore_second)、MEM(mem_second) 每秒用量進(jìn)行量化，實(shí)現(xiàn)計(jì)算任務(wù)在 YARN 或 Kubernetes 運(yùn)行時(shí)指標(biāo)度量統(tǒng)一，便于后期資源使用分析、成本分?jǐn)偱c治理。

存儲(chǔ)層

以 S3 為例，其計(jì)費(fèi)體系極為龐大，有冷熱分層、階梯式存儲(chǔ)用量計(jì)價(jià)、操作分類計(jì)費(fèi)等數(shù)十種細(xì)分類型，概括起來可分為三大類：存儲(chǔ)、數(shù)據(jù)請(qǐng)求、數(shù)據(jù)傳輸。

計(jì)費(fèi)說明及定價(jià)實(shí)現(xiàn)參考

• 存儲(chǔ)

• • 按 S3 存儲(chǔ)類定義費(fèi)率

  • SS/FA 層：￥ 0.006122 per GB / day，IA 層：￥ 0.004397 per GB / day，AIA 層：￥ 0.001098 per GB / day

  • 各存儲(chǔ)層使用容量結(jié)合存儲(chǔ)類費(fèi)率，計(jì)算出存儲(chǔ)單價(jià)費(fèi)率

  • 假設(shè) A 用戶使用 s3 多個(gè)桶總存儲(chǔ) 1PB，各層存儲(chǔ)用量分布 (SS 層 /20TB、FA 層 /150TB、IA 層 /170TB 、AIA/660TB)，則日均存儲(chǔ)量化成本 = ￥ 2600.5504 / day，轉(zhuǎn)化為 GB 的存儲(chǔ)單價(jià)費(fèi)率為￥ 0.00248

  • 計(jì)算每日量化成本與賬單成本的差異系數(shù) (折扣影響)，如系數(shù)為 1，則存儲(chǔ)單價(jià)費(fèi)率不變

• 數(shù)據(jù)請(qǐng)求：處理 access log 訪問明細(xì)數(shù)據(jù)，按 operator 類型劃分 ETL 處理還原計(jì)算出路徑產(chǎn)生的讀寫請(qǐng)求費(fèi)用

• 數(shù)據(jù)傳輸：DTO 部分使用明確，一般按團(tuán)隊(duì)使用劃分歸屬

用戶可基于資產(chǎn)用量和每日單價(jià)費(fèi)率，以通俗易懂的方式計(jì)算得到存儲(chǔ)成本量化參考。

數(shù)據(jù)采集與建模入倉

在成本領(lǐng)域中除資源使用計(jì)量外，還需采集云廠商賬單數(shù)據(jù)、API 調(diào)用和日志數(shù)據(jù)等，以補(bǔ)充成本分析維度信息。數(shù)據(jù)采集入倉時(shí)命名需符合規(guī)范。示例：

• ODS 層，庫名：ods_govern

• DWD 層，庫名：dwd_govern_cost，表命名規(guī)范：{一級(jí)主題}_{二級(jí)主題}

成本數(shù)倉涉及業(yè)務(wù)過程較為單一，主要以實(shí)現(xiàn)成本 [量化 + 分?jǐn)俔 為業(yè)務(wù)核心，建模部分可遵循 OneData 概念，以維度建模為基礎(chǔ)構(gòu)建總線矩陣，定義業(yè)務(wù)域、數(shù)據(jù)域、業(yè)務(wù)過程、度量 / 指標(biāo)、維度、維度屬性。入倉 ETL 時(shí)需預(yù)先規(guī)劃數(shù)據(jù)加載和更新策略，分場(chǎng)景采取增量或批量處理等方式，確保成本數(shù)據(jù)及時(shí)、準(zhǔn)確地在各層傳遞。

3.2 持續(xù)化治理產(chǎn)物

數(shù)據(jù)治理平臺(tái)

治理到達(dá)一定程度后，為實(shí)現(xiàn)常態(tài)化、持續(xù)性的治理目標(biāo)，需要工具平臺(tái)提供支撐，數(shù)據(jù)治理平臺(tái)隨之誕生。我司的數(shù)據(jù)治理平臺(tái)自頂向下采用 <治理領(lǐng)域 - 治理對(duì)象 治理項(xiàng)> 三層設(shè)計(jì)。

• 治理領(lǐng)域?qū)樱喊礃I(yè)務(wù)特性劃分，如成本 (計(jì)算和存儲(chǔ))、質(zhì)量、穩(wěn)定性、安全等

• 治理對(duì)象層：領(lǐng)域內(nèi)治理目標(biāo)，如計(jì)算任務(wù)、存儲(chǔ)表、數(shù)據(jù)開發(fā)過程質(zhì)量等

• 治理項(xiàng)層：可執(zhí)行的具體動(dòng)作，如計(jì)算任務(wù)資源優(yōu)化、存儲(chǔ)表數(shù)據(jù)活性度等

用戶可在此框架內(nèi)定義和捆綁治理任務(wù)，底層治理項(xiàng)數(shù)據(jù)均來自指標(biāo)平臺(tái)，依托于成熟的指標(biāo)管理體系，最大程度削減口徑確認(rèn)和數(shù)據(jù)處理成本。

雙層治理協(xié)作模式

以過往的治理經(jīng)歷而言，采用雙層治理協(xié)作模式（用戶層治理和平臺(tái)層治理）效果最佳，雙方以 OKR 作為媒介對(duì)齊治理目標(biāo)后，各自開展治理行動(dòng)項(xiàng)。以成本治理為例，雙方協(xié)作方式如下圖所示：

平臺(tái)層治理

平臺(tái)層接入各類治理類指標(biāo)后抽象為計(jì)算、存儲(chǔ)兩類可治理資源，根據(jù)預(yù)設(shè)規(guī)則判定形成待治理項(xiàng)，確保治理過程標(biāo)準(zhǔn)化和自動(dòng)化，待治理項(xiàng)生成后推送給負(fù)責(zé)人做后續(xù)治理操作，同時(shí)平臺(tái)會(huì)監(jiān)控治理進(jìn)度，量化治理效果。除此之外，平臺(tái)層對(duì)技術(shù)架構(gòu)改進(jìn)優(yōu)化實(shí)現(xiàn)成本優(yōu)化的幅度是巨大的，如對(duì)平臺(tái)計(jì)算引擎升級(jí)、汰換和湖倉一體迭代升級(jí)等。

用戶層治理

用戶層負(fù)責(zé)具體治理措施的執(zhí)行和業(yè)務(wù)層面的優(yōu)化，基于已制定的預(yù)算和治理目標(biāo)，有節(jié)奏地開展治理事項(xiàng)，在治理完成后查看治理收益，評(píng)估投入產(chǎn)出比。需特別注意的是：平臺(tái)在建立用量管控機(jī)制的同時(shí)，需完善 <個(gè)人 -> 項(xiàng)目 ->組織架構(gòu)>層級(jí)關(guān)系，按組織架構(gòu)治理推進(jìn)的優(yōu)勢(shì)是方便直接找到相干人，便于追蹤和跟進(jìn)目標(biāo)進(jìn)度，依托于組織架構(gòu)的上下級(jí)匯報(bào)關(guān)系，能使治理推進(jìn)更加順暢。

治理健康分

治理類別劃分多個(gè)領(lǐng)域，涉及資源成本、數(shù)據(jù)質(zhì)量、數(shù)據(jù)安全、數(shù)倉 / 組件穩(wěn)定性等各個(gè)方面，圍繞著這些領(lǐng)域會(huì)各自形成具體的治理策略和方法，在運(yùn)營發(fā)展到一定階段時(shí)，就需要一個(gè)多方共認(rèn)的治理考核指標(biāo) (如健康分)，使各個(gè)團(tuán)隊(duì)有一個(gè)統(tǒng)一的量化標(biāo)準(zhǔn)，共同朝著同一個(gè)目標(biāo)努力。

健康分是以數(shù)據(jù)資產(chǎn)在數(shù)據(jù)生產(chǎn)、數(shù)據(jù)流通、數(shù)據(jù)特性、數(shù)據(jù)管理、任務(wù)性質(zhì)等元數(shù)據(jù)為依托，經(jīng)模型化數(shù)據(jù)處理后進(jìn)行綜合評(píng)估，在個(gè)人、組織的維度呈現(xiàn)資產(chǎn)狀態(tài)的綜合分值。以成本領(lǐng)域 -spark 任務(wù)計(jì)算這個(gè)治理對(duì)象為例，我們將其拆分為五個(gè)維度呈現(xiàn)：

這種多維度的健康分評(píng)估體系，能夠較全面地反映治理對(duì)象的健康狀況，同時(shí)結(jié)合數(shù)據(jù)治理運(yùn)營機(jī)制，周期性調(diào)整維度組合和權(quán)重，避免健康分計(jì)算失衡。

結(jié) 語

以當(dāng)前視角回顧大數(shù)據(jù)成本治理歷程，能深刻體會(huì)到成本、穩(wěn)定性、易用性三者之間既互斥又平衡的三角博弈關(guān)系，表象為：追求成本最優(yōu)往往需要在穩(wěn)定性和易用性做權(quán)衡取舍；過度成本壓縮會(huì)極大概率地增加系統(tǒng)不穩(wěn)定性；過分追求平臺(tái)易用性和穩(wěn)定性則會(huì)帶來資源成本浪費(fèi)。因此，成本治理絕非簡(jiǎn)單的降本行為，而是在多重約束條件下尋求最優(yōu)解的系統(tǒng)工程，這種平衡關(guān)系不能一蹴而就，需要在持續(xù)的實(shí)踐中不斷調(diào)整和完善。

道雖遠(yuǎn)，行則將至。在大數(shù)據(jù)成本治理這一漫長而復(fù)雜的道路上，從最初的被動(dòng)應(yīng)對(duì)成本壓力，到如今建立起相對(duì)完善的治理體系，這一路走來充滿挑戰(zhàn)與收獲，特別感謝在此歷程中內(nèi)外部團(tuán)隊(duì)的大力支持，才讓我們?cè)谥卫磉@條道路上披荊斬棘。

未來，隨著業(yè)務(wù)規(guī)模的持續(xù)擴(kuò)大和技術(shù)架構(gòu)的不斷演進(jìn)，成本治理工作亦將面臨新的挑戰(zhàn)和機(jī)遇。我們將繼續(xù)秉承精益求精的態(tài)度，在實(shí)踐中總結(jié)經(jīng)驗(yàn)，在創(chuàng)新中尋求突破，為構(gòu)建更加高效、穩(wěn)定、經(jīng)濟(jì)的大數(shù)據(jù)平臺(tái)而不懈努力，愿我們都能在各自的技術(shù)道路上行穩(wěn)致遠(yuǎn)。

作者信息

吳建陽，樸樸科技大數(shù)據(jù)運(yùn)維負(fù)責(zé)人，在大數(shù)據(jù)平臺(tái)離線 / 實(shí)時(shí)計(jì)算、數(shù)據(jù)湖、OLAP 等基礎(chǔ)設(shè)施，具有多年的大數(shù)據(jù)實(shí)戰(zhàn)經(jīng)驗(yàn)。