背景
某企業實時數倉團隊通過資料收集、整合、計算和存儲建構實時資料倉庫，為企業提供快速、準确、可靠的實時資料分析和決策支援。目前該實時數倉團隊已運作了上萬的實時任務，依賴的元件繁多（例如：Flink、Yarn、Abase、Doris等）、開發人員衆多 、開發習慣和經驗程度參差不齊等各類主客觀因素，導緻任務穩定性、資源浪費等問題頻出。是以，任務治理已是勢在必行，但縱觀整個治理過程，仍存在以下沖突：
1. 業務階段與資料治理的沖突
業務階段大緻可以分為兩個階段：發展期，成熟期。發展期： 産品不斷疊代，需求不斷新增，實時任務持續增加。在此時期同時也是與業務建立信任的階段，實時任務的品質會被重點關注，成本控制的優先級小于品質保障。成熟期： 資源預算增量越來越少，業務需求數量不降反升，在此成熟階段實時團隊不僅要做好數倉品質保障，也需關注資源成本的合理配置設定和利用。
2. 人力成本與資料治理的沖突
實時任務的治理成本由于其技術複雜性和線上運作等屬性導緻治理要求一直較高，人力經常在資料治理和業務需求之間徘徊。由于實時任務治理必将占用業務支援精力，如何提高治理人效，降低治理成本，釋放個人精力，也是大家特别關注的點。
3. 治理問題與可評價的沖突
通常實時任務可以通過一定的規則篩選出存在問題的任務，并進行集中的運動式治理。這種方式雖然可以一定程度解決階段性治理問題，但是無法量化任務的健康程度以及待治理的緊迫程度，使得治理無法持續開展。是以，需要有一個可評價的體系對數倉健康程度進行評價，并通過評價後的分數持續推動治理。
走進DataLeap實時健康分
DataLeap實時健康分是一套集治理評價、目标制定、治理驅動、治理提效、效果量化于一身的一站式實時資料治了解決方案，滿足精準治理的訴求，降低治理成本，保障資料整體規範性、穩定性，逐漸成為公司内評價團隊實時資料治理水準和資源配置設定的風向标，讓治理成為一件簡單高效的事。
實時健康分方案大緻可以分為四個子產品：元數倉建設、治理項沉澱、分數計算、平台治理。
1. 元數倉建設
健康分元數倉指的是任務相關的中繼資料資訊，它是健康分加工過程中依賴的底層資料，包括任務的穩定性、品質、規範性、成本以及SLA等。
| 中繼資料類型 | 描述 |
| 穩定性中繼資料 | gc、failover、cp、state、反壓、傾斜等 |
| 品質中繼資料 | 時效性、準确性、名額監控覆寫度等 |
| 規範性中繼資料 | 任務配置、元件配置、報警配置等 |
| 成本中繼資料 | 隊列資源、計算資源、存儲資源等 |
| SLA 中繼資料 | 元件SLA、資料SLA、任務SLA 等 |
2. 治理項沉澱
治理項規則是Flink團隊通過引擎視角和各個BP實時數倉團隊通過業務視角積累沉澱出的一套通用規則，通過這套通用規則可達成快速複用的作用，可以快速發現實時任務中存在的成本浪費和品質隐患問題。現階段，越來越多的團隊加入實時治理，貢獻更多的治理經驗，總結出更通用的規則，吸引更多的團隊，進而形成正向循環。目前品質項規則14項，成本項規則2項。
3. 分數計算
名詞解釋：
治理項權重： 根據治理項規則的重要性，治理項權重不同，例如："CPU資源浪費"=40；"隊列配置不規範"=15；
任務等級系數：每個任務等級會有不同系數，等級越高，系數越高，對分數的影響越大，例如：D1/D2=10；D3=5；D4=3；D5=1
目前實時健康分涵蓋品質分和成本分兩套評價體系，其結果等于品質分與成本分的均值。每套評價體系采用扣分制算法，計分邏輯簡單、可解釋性強，能夠實作細到任務、個人粒度，粗到部門、公司粒度的分數計算結果。
- 品質分計算
口徑：∑(命中治理項的任務等級系數)∑(全部任務的任務等級系數) ∗治理項權重\frac {\sum(命中治理項的任務等級系數)}{\sum(全部任務的任務等級系數)} *治理項權重∑(全部任務的任務等級系數)∑(命中治理項的任務等級系數) ∗治理項權重
例如：
一共有1000個任務，∑(全部任務的等級系數)=2500\sum(全部任務的等級系數)=2500∑(全部任務的等級系數)=2500
其中有100個任務命中了任務未配置報警，∑(命中治理項的任務等級系數)=500\sum(命中治理項的任務等級系數)=500∑(命中治理項的任務等級系數)=500
未配置報警治理項（治理項權重：15）扣分為500 / 2500 * 15 = 3分
品質分=100-3=97分
- 成本分計算
口徑：∑(命中治理項的任務CPU配置設定數)∑(全部任務的任務CPU配置設定數) ∗治理項權重\frac {\sum(命中治理項的任務CPU配置設定數)}{\sum(全部任務的任務CPU配置設定數)} *治理項權重∑(全部任務的任務CPU配置設定數)∑(命中治理項的任務CPU配置設定數) ∗治理項權重
例如
一共有1000個任務，∑(全部任務的任務CPU配置設定數)=25000\sum(全部任務的任務CPU配置設定數)=25000∑(全部任務的任務CPU配置設定數)=25000
其中有100個任務命中了CPU資源浪費，∑(命中治理項的任務CPU配置設定數)=10000\sum(命中治理項的任務CPU配置設定數)=10000∑(命中治理項的任務CPU配置設定數)=10000
CPU資源浪費治理項（治理項權重：40）扣分為10000 / 25000 * 40 = 16分
成本分=100-16=84分
4. 平台治理
實時健康分依托平台提供高效的治理能力，其中包括治理全景、治理工作台以及治理輔助三個子產品：
- 治理全景：提供健康分趨勢、成本項治理趨勢、待治理問題分布等看闆，觀察健康程度趨勢。
- 治理工作台：提供治理項明細、推薦參數、一鍵治理、事後監控等工具，提高治理效率。
- 治理輔助：提供治理播報卡片、自定義場景治理輔助工具，完善治理場景。
| 一級項 | 二級項 | 描述 |
| 治理全景 | 健康分程度 | 展示各個業務線或個人目前健康分程度 |
| 健康分趨勢 | 展示健康分變化趨勢，其中也包括成本分和品質分的變化趨勢。 | |
| 成本項治理趨勢 | 展示成本項已治理、待治理、已節約CPU和待節約CPU趨勢。 | |
| 品質項治理趨勢 | 展示品質項規則命中待治理任務數和已治理任務數趨勢。 | |
| 待治理問題分布 | 展示各個規則命中的待治理問題數、扣分情況。 | |
| 治理工作台 | 治理項明細 | 展示待治理任務清單明細，可通過規則項、任務等級、任務類型、任務owner等進行篩選展示 |
| 治理參數推薦 | 給每一個任務命中的治理項給出優化參數建議。 | |
| 批量一鍵治理 | 通過治理參數推薦批量完成多個任務的治理。單任務治理人效從15min提升到30s | |
| 事後監控大盤 | 治理完成之後通過推動治理任務的lag監控大盤來觀察任務運作情況。 | |
| 治理輔助 | 治理播報卡片 | 每日給對應owner推送治理卡片，播報目前成本分、品質分、成本待治理項數、品質待治理項數和昨天已治理資訊等。 |
| 自定義場景治理 | 給業務提供一個可自定義治理項的能力，滿足業務個性化非通用的治理場景。 |
實時治理專項
某企業資料平台存在降本增效和穩定性保障訴求，日常任務存在CPU使用浪費、未配置報警、隊列使用不規範、CPU使用率過高等問題。是以，該實時數倉團隊聯合DataLeap團隊成立治理專項。專項設立虛拟小組與治理poc機制，自上而下拆分治理目标，快速響應治理阻塞問題，推動治理進度，協調治理資源，最終保障制定目标達成。
虛拟小組成員時刻關注業務線健康程度，評估目标完成風險，發現治理進度存在風險後及時與業務治理poc溝通治理過程中遇到的困難和阻塞，并由虛拟小組開發新的工具或制定新的治理方案，幫助業務治理poc克服治理困難，推動各業務方向達成既定季度目标。
1. 實時成本專項
該資料平台實時任務存在大量資源浪費問題，資源浪費任務數3.8k+，待治理CPU資源27.9w+core。基于資源浪費嚴重問題，成立實時成本專項，形成虛拟支援小組，深入業務，協助業務進行資源浪費治理，累計治理資源浪費任務1.15k，待治理CPU資源27.9w+core -> 17.7w+core。
2. 實時品質專項
同時，該資料平台實時任務存在多種品質穩定性隐患，例如：CPU使用過高、任務未配置報警、隊列使用不規範、資料傾斜等問題。基于穩定性隐患問題，多方聯合形成實時品質專項，沉澱出11個品質項規則，幫助企業資料平台發現3k+品質問題，推動資料平台進行品質治理，完成1.1k次品質治理。
3. 季度治理收益
名額解釋：
一鍵治理時長提升率：一鍵治理将治理時長從15min降到0.5min，是以提升率96.5%
一鍵治理場景覆寫率： 一鍵治理問題數所有治理問題數 \frac {一鍵治理問題數}{所有治理問題數} 所有治理問題數一鍵治理問題數
治理效率：一鍵治理時長提升率*一鍵治理場景覆寫率
收益如下：
- 該資料平台Q3季度健康分從80.57（新上9個治理項導緻分數下降）-> 81.85分
- 品質項治理問題1.11k+（其中“任務未配置報警”問題清零、“CPU使用率過高”治理700+）
- 一鍵治理場景覆寫率80%，一鍵治理時長提升率96.5%，治理效率提升77%
點選跳轉大資料研發治理套件-火山引擎了解更多