一、數據治理概況

業界對于數據治理的定義有很多種，螞蟻在數據治理時主要關注對企業運轉非常關鍵的架構、安全、合規、質量和價值這五個方面。

為什么是這五個方面呢？

• 首先，要保證整個數據在業務上是可以流轉起來的、是可用的，包含兩個基本要求：首先是要符合最近關注度非常高的用戶隱私、反洗錢等監管法律的要求，保障數據是合規的；第二是要保證數據在各個環境上的存儲、流轉和使用都是安全的。這些是在安全合規領域要重點去解決的問題。
• 其次，交付給業務的數據不能錯漏，也不能延遲，這屬于數據質量范疇，這個領域主要解決讓業務敢用數據的問題。
• 另外，大數據領域有非常多的人在協同開發，希望產出的數據是有序的，既是可復用的又是好用的，所以，需要重點做好數據架構的規劃和治理，包括數據模型設計、數據標準規范和主數據等。
• 最后，數據是一個閉環的生態，從拿到數據到加工數據，再到賦能業務，希望整個過程是可持續的，在這個可持續的過程中需要有數據價值的體現。價值可以分成兩類，一類是負向的價值成本，包括數據運轉過程中計算、存儲、數據資產帶來的機器資源成本；另一類是正向的業務價值，是指數據被使用消費過程中發揮的價值。業界一直在關注數據的正向價值，從數據要素來講，核心是將數據從原來的資源或者產品，轉化成面向未來的商品。對數據價值的衡量是未來一大趨勢。

本次分享聚焦于其中的兩個命題：數據質量治理和計存治理。接下來將分別進行介紹。

二、數據質量治理

1. 數據質量產生分析

螞蟻的數據來源眾多，包括行為日志、系統服務端收集的數據等。從類型上看，有DB 類、日志類、log 類等，還有消息類的和非結構化的數據。大模型出來之后，我們通過一系列工具，將這些數據都存儲到了螞蟻一站式的大數據工作平臺上，經過批流的處理進行分析洞察、決策服務。也就是說，數據從業務中來，通過模型算法加工，最終又回到了業務中去。整個流轉過程非常復雜，涉及到很多的工具引擎，中間任何環節和操作都可能引發數據質量問題。提供給業務的數據錯了、漏了或者延遲了，是經常遇到的一個痛點。

2. 數據質量治理挑戰

在介紹螞蟻如何進行數據質量治理之前，先來了解一下螞蟻的業務形態。第一部分是大家感知的“冰山之上”的 C 端業務，包含芝麻分、螞蟻森林、花唄、借唄等；第二部分是面向機構監管的“冰山之下”的業務，包括機構清算、計息、計提等，這些業務需要大量的技術支撐，甚至是數據加算法融匯，以追求價值的最大化。在金融業務極度嚴苛的要求下，做好整體的數據質量保障是非常重要的。

數據質量治理面臨著諸多挑戰，主要包括：

• 業務方面：螞蟻業務發展快，變更非常多，任何一次變更出錯都可能有很大的影響。無論從用戶體驗，還是智能化角度，對數據產出的時效都有非常高的要求。
• 數據方面：大部分是金融層面的業務，對數據質量的要求也非常高。
• 用戶方面：整條鏈路上有非常多的角色參與，比如有 BI 團隊、技術團隊、數據團隊和產品運營團隊等等。每個人的基本認知和專業水平都不一樣，人為操作可能也會帶來一定的風險。

目前螞蟻整體日均變更任務量在幾千次以上，每天日運行任務調度實例達到了百萬次以上，數據應用的核心消費場景有數萬個，數據質量已經成為螞蟻業務發展的基石和驅動器之一。這也是為什么今天螞蟻非常重視數據質量建設的原因。

3. 數據質量頂層設計

在這么復雜的情況下，怎么解決數據質量的問題呢？單點處理問題很難全面保障數據質量，很有可能拆東墻補西墻，或者這里解決了那里卻漏掉了。進行全面的數據質量治理，需要有良好的頂層設計，我們將風險分成三類：數據技術引擎風險、數據內容風險及數據應用風險。

具體落地的核心思路如下。首先，保障目標重點聚焦于高可用和資金安全業務場景：

• 事前，做到整體的研發質量保障，包括測試、仿真等工作；
• 事中，重點解決變更風險的管控；
• 事后，當出現問題的時候，要確保整個生產運行是高可用的，需要重點建設主動發現和快速恢復的能力。
• 另外，還成立了數據和技術的聯合藍軍對整個保障體系去做攻擊，來驗證布防是否可靠。

4. 數據質量治理架構

從縱向來看，螞蟻的數據質量治理架構總體分為三層：

• 能力層，包含質量管控、質量識別、故障恢復和風險治理的能力，并建立了統一質量元數據中心，為后面 AI 加質量的嘗試及相關能力的演進打下了一個非常好的基礎。建議在做質量風險保障時，要重視元數據的建設，而且前期就要做好規劃。同時，圍繞元數據，我們結合大規模機器學習等算法去嘗試探索智能化的波動、異常、離散等異常及風險點的識別。
• 系統層，主要圍繞數據測試、發布管控、變更管理、質量監控、應急演練和質量治理建設六大產品的能力。
• 業務層，作為數據中臺，產品能力開放給業務數據團隊、質量團隊使用，幫助建設每個業務數據質量的門戶，包含整個應用分級管控研發流程、全鏈路的質量監控運維平臺等。

從橫向來看，質量治理貫穿全鏈路系統，并建設了組織文化和制度規范。組織文化包含數據攻防、質量審計、質量保障小組等，做到了全局高效拉通。制度規范包含質量保障規范、基線管理手冊、發布變更手冊等，形成了全局制度上的規范。

在整個實施過程中，重點是以止損量/故障數核心指標為抓手，發現保障體系里面的問題，通過核心指標驅動整個體系持續地迭代和優化。

5. 數據質量治理方案

接下來深入介紹數據質量治理圍繞事前、事中、事后的技術能力。技術上處理離線數據故障有一個核心目標——“五分鐘內發現故障，五十分鐘內恢復執行”。處理線上數據故障的目標是“一分鐘發現問題，五分鐘定位問題，十分鐘恢復執行”。之所以離線和線上的目標不同，是因為離線數據整條鏈路比較長，定位和恢復需要較長的時間，另外，當前的故障發現能力、元數據時效性等也存在一定局限性。

執行的核心策略包括事前、事中、事后三部分。

• 事前要做到可管控、可仿真和可灰度，在需求階段做分級變更定義，在研發階段做規范、測試和發布，在預發階段做仿真回放和 AB 灰度；
• 事中要做到可監控、可演練、可應急，數據全鏈路和應急監控等各個環節都能做演練和巡檢；
• 事后要做到可度量、可審計和可持續，包括事件管理、問題故障審計報告、案例學習和晉級可晉級考試等，螞蟻每年會有一次公司級別的數據紅藍攻防，也有一年兩到三次的必須參加的安全生產晉級考試的運營活動。

6. 數據質量治理案例

（1）數據變更免疫

數據變更免疫的核心目標是希望讓錯誤代碼不發布到生產。為了實現這一目標構建了幾道防線：事前構建變更準入防線，將變更必須滿足的“三板斧”要求、發布窗口要求等風險底線要求植入到變更準入的防線；事中構建變更灰度防線，在變更生效之前，用真實的流程去預驗驗證，提前發現問題；事后重點是變更監控，變更生效之后，能夠持續監控變更的業務變化，有問題快速進行恢復。

下面這張圖，是面向發布環節研發的發布管控產品。

所有的變更在通過該產品發布都需要進行校驗，類似于現在業界比較火 DataOps，將測試、灰度、仿真、監控全部納入到流程中，做到在發布的時候自動化地進行質量監控和巡檢。

（2）紅藍攻防

紅藍攻防的核心思路是通過故障的注入，對生產鏈路進行模擬攻擊，發現防控體系的薄弱點。

模擬在線環境，用任務攻擊和數據攻擊兩種方法進行攻擊。在進行數據紅藍攻防的過程中需要解決三個核心問題：

• 如何不影響生產？因為數據是一條鏈，上游污染了，整條數據就污染了，而且恢復成本極高。在生產環境中，構建仿真無損環境進行無差別的供給，通過攻防平臺相應的數據鏈路在無損環境里面去植入，從而不影響生產環境。
• 如何選擇攻擊對象？主要選擇數據入口，比如數據同步、回流任務、人群標簽、有時效性保障的業務基線場景等，要重點關注有止損、有輿情的場景，比如算錢等更重要的且效果更顯性化的場景。
• 如何有效地攻擊？要確保所有的攻擊字段能夠幫助業務發現有效的生產風險，核心是通過歷史故障的分析和平移，以及重大業務變更的演練。另外，在核心的攻擊能力方面，構建了 SQL 注入等能力，以及數據大幅度波動、內容格式突然異常、資金字段錯位、任務重復的回流等多種方法。

紅藍攻防在螞蟻連續組織了四到五年，整個公司級別的紅藍攻防自動化的攻擊次數達到四十多萬次，推動數據質量核對規則和配置超過了五十萬家，也發現了非常多的潛在問題。

三、數據計存治理

1. 數據計存治理面臨的挑戰

下面這張圖是 2019 年螞蟻離線集群存儲使用率的曲線圖，安全存儲的水位線是 85%，一旦超過了 85% 就可能引發異常問題。從圖中不難發現，2019 年下半年集群存儲使用率都在 85% 以上，當時出了不少安全生產問題。

計存治理會影響到安全生產。當時集群的物理容量規模已經達到了 EB 級，大概有幾百萬張數據表，參與數據研發的人員數量是幾千級別的。在這樣一個背景下，我們開始思考計存治理的方案。

2. 數據計存治理核心思路

計存治理的核心思路是從組織設計、規范制定和平臺建設三個方面去落地。執行的時候，通過戰役拉動支撐整個業務并進行資產升級，通過運營活動進行成本規范的傳播和文化的建設。

• 在組織設計層面，成立了數據架構小組。從架構域的維度統籌整個公司的數據架構和成本治理的工作。設立數據管理崗位和晉升的通道，制定研發協作機制和流程。其中，數據管理的崗位和晉升通道的設置非常關鍵，因為數據治理和數據管理，與數據研發，雖然都屬于數據域領域，但能力與技能要求是不一樣的，成長需要以不同的視角去看，所以設計了獨立的晉升通道。
• 在規范制定層面，產出了螞蟻數據架構規范、研發管理規范和數據治理管控規則。
• 在平臺建設層面，研發側正向地提升研發質量和管控資產無序增長，治理側搭建平臺化的治理工具，形成一套自動化的治理機制。

3. 數據計存治理策略

從開源和節流兩個方面具體落地實施。

• 開源：數倉原來的資源是獨享的，數倉和在線是分開的，而且數倉資源需求量非常大。在線數據庫的資源使用率不高，基本在 25% 左右，夜間使用率可能更低，而輸出儲藏在夜間有非常高的計算資源需求，能不能把在線數據庫空閑的資源共享給數倉離線計算呢？
• 節流：整體邏輯是數倉從任務和數據的角度盡可能去優化和節約，包含存儲治理、計算治理、任務治理。

4. 面向開源的數據計存治理方案

以前數倉是獨立的專用集群，機器、存儲均獨立購買。為了提供高效服務，在線應用會在本地化進行多層部署。要能與在線應用混合部署，首先要把數倉集群的架構變更到能跟在線應用混部的跨層模式，既可以提升資源利用率，又能保證穩定性。如果做成這樣的“機房架構”，有兩個問題必須解決：首先，如何確保數倉在高峰期不受在線資源的搶占，保證數倉高保業務在高峰期仍然可以穩定運行；其次，數倉有大量的數據交互，一旦跨層會有大量的跨層數據訪問，從而帶來大量的網絡開銷，這也會直接影響數倉的正常運行。

為了解決這兩個問題，核心有三件事：

• 將數倉應用層的數據訪問統一收斂到數據中間層；
• 對數據中間層的熱數據做跨層冗余；
• 將業務進行分級，對于高保的業務給予獨占的資源，跟在線資源做適當的隔離，防止資源擠占。

存量的數據任務都是開放讀取的，也存在大量的跨層訪問，需要將存量也無風險遷移到整個混部的集群上來。

事前做項目規劃，對業務項目劃分、資源使用進行評估，產出遷移的列表；事中進行遷移的改造工作，包括部署巡檢規則、進行代碼改造和架構的升級、部署發布管控，避免熱度及大表跨集群拷貝等；事后，做日常的巡檢和持續優化，包括對跨層任務持續的監控、對不合理的代碼進行改造、對熱表做集群的緩存等，減少網絡帶寬帶來的集群負載。

完成混合部署后，數倉可以共享在線資源，在沒有額外增加機器成本的情況下，整個數倉增加了 50% 的可用彈性計算資源，而且數倉任務平均等待時長降低了 50%，同時，在線應用的 CPU 利用率也從 25% 提高到了 40%，從全局來看，資源利用率提升非常明顯。

總結來說，開源的思路就是在做數據治理的時候不僅僅是只看數倉，還要將數倉的上下游及周邊環節協同起來，作為一個整體來看。

5. 面向節流的數據計存治理方案

面向節流的優化可以分成幾類：

• 引擎優化，比如參數優化，調度優化；
• 模型優化，比如數倉架構的鏈路、數倉設計、代碼語法、數據壓縮格式等；
• 代碼優化，比如 join 的優化、UDF 的優化等；
• 資產管理優化，如果整個鏈路在業務上都沒有應用，則考慮鏈路的整體下線，實現更敏捷的下線。

節流的整體思路就是用技術的方法提升治理自動化率，實現自動識別、歸因分析、自動清理，形成常態化的管控能力。

下面分享兩個“小成本，大收益”的案例。

（1）漸進計算

漸進計算的適用場景是固定窗口或者滑動窗口指標計算。有固定起止日期的時間段叫固定窗口（比如年度、1 月 1 日至今等），有固定時長的時間段叫做滑動窗口（比如近 30 天）。固定窗口和滑動窗口計算相同指標時有很多共性，兩者在計算過程中的中間表是可以復用的，如果每次查詢都重新計算就會造成計算資源的浪費。漸進計算的核心原理是“用空間換時間”，自動生成可持續滾動中間表，將中間計算的過程表保留下來，每次查詢時用哈希的方式快速去讀取，不用再重復計算。上圖右側是一個風控業務的案例，用漸進計算優化后，每天計算消耗從 795 CU 降到了 22 CU，收益非常顯著。

（2）存儲歸檔

存儲歸檔適用于數據查詢頻次不高的冷數據場景。通過對數倉數據的初步分析發現，一般訪問當天數據的頻率在 80% 左右，訪問前一天數據的頻率在 10%-15% 左右，3 天前的數據很少被訪問。同時，考慮到一旦對冷數據進行壓縮或者重排之后，存儲空間雖然會下降，但是讀取時的計算性能會消耗比較大，綜合考慮，將一定時間內（比如 7 天、30 天等）未被讀取的數據定為冷數據，對其進行壓縮處理。當然也不是“一刀切”的方式，可以基于更精細的分析進行冷數據的定義和處理。

冷數據的處理邏輯分為兩類：

一類叫歸檔，核心就是采用 RAID 格式的存儲，用 n 個數據塊和 m 個校驗塊的模式建設歸檔的能力。這樣，用 8 個數據塊和 3 個校驗塊就達到了 1.375 的備份，一般都是 3 備份。

另一類是重排壓縮，是 distribute 和 sort by 的結合，與電腦的磁盤整理一樣，當很多空間是碎片化存儲的時候，通過重排壓縮把行與行之間相似的字段壓縮存儲。比如，相鄰兩行都有彭歡，存儲的時候只存一個彭歡，并且告知兩行都有彭歡的信息，用這種模式去優化存儲。用技術的方法，不需要進行各個團隊到每個人的存儲或者優化，就可以帶來非常大的收益。在一個案例中，網關流量日志重排壓縮后，減少了約 30% 的存儲容量。當然在進行重排壓縮的時候也有一些注意事項：distribute 環節不要將數據打散；不適合 Json 串類型字段，重復率不?；不需要 order by 全局排序，sort by 分區內排序即可；歸檔操作降低了可靠性，不如默認的 3 副本。

進一步，希望根據數據的冷熱程度，建立自動化的識別和分級存儲方案，從而實現成本的分級優化。

將數據分級成四類，在用戶無感知的情況下進行自動化的數據差異化存儲。

• 高頻訪問：熱點數據，1 SSD  + 3 HDD
• 熱數據：訪問頻率正常，3HHD
• 歸檔數據：數據需要長期保留，訪問頻次低的，1.375 RAID HDD 歸檔模式
• 冷備存儲：數據需長期保留，訪問頻次極低（比如監管數據等），單獨建立了冷備集群，壓縮比非常高，但是讀取時耗費的計算資源比較高，一般是以 90 天的邏輯長期保留。

四、對數據治理未來的思考

最后，分享對數據治理未來的幾點思考。

• 一體化：數據在哪里治理就在哪里，隨著大模型、ChatGPT、AI 的出現，以及螞蟻自身業務的發展，目前關注在傳統離線上的數據治理，未來會轉變為基于湖倉一體（在線、離線、實時、圖計算等）做一體化的數據治理，解決成本、合規和效率的問題。
• 價值化：數據作為生產要素，從內部的產品變為流通的商品，涉及到共享交易和開放，在數據確權價值的衡量及隱私保護方面去探索和突破價值點。
• 智能化：加入大模型做更智能的數據治理，原來是人工走向規則，接下來會探索更智能的方向。