用湖倉一體實現基于業務本質的監管數據治理

2022年9月3日，由北京區塊鏈技術應用協會（BBAA）主辦的“Web 3.0發展趨勢高峰論壇暨2022元宇宙、區塊鏈、金融科技藍皮書發布會”成功舉行，偶數科技應邀出席。

大會隆重發布《中國金融科技發展報告》、《中國區塊鏈發展報告》、《中國元宇宙發展報告》三部年度藍皮書。其中偶數科技參與了本年度的《中國金融科技發展報告》編寫。

會上，北京偶數科技有限公司產品負責人蔣秀峰就主題《用湖倉一體實現基于業務本質的監管數據治理》進行了分享，以下為發言實錄：

嘉賓發言現場

非常高興有這個機會把偶數科技在數據治理領域的一些實踐和探索成果跟大家分享。

今天我分享的題目是《用湖倉一體實現基于業務本質的監管數據治理——如何做好數據資產化工作》。數據治理是我們完成數據資產轉化一個非常重要的手段，所以小標題是數據資產化。

如何做好數據資產化相關工作？難道之前數據資產化（如數據治理）的工作我們做的不好嗎？過去10到15年我們的金融機構其實做了大量的數據管控和數據治理相關的工作，取得了非常不錯的成績。我們可以回顧一下我們數據管理類系統經過了十幾年建設之后的數據應用的現狀。

幾個數字跟大家分享一下：

第一個，90%

可以說接近90%的金融機構已經完成了數據倉庫、大數據平臺、或是現在經常提到的數據湖、湖倉一體等這類平臺的建設工作。

第二個，100%

已經建設完數據平臺的企業幾乎100%同時做了數據管控和數據治理相關的工作。

第三個，80%

我們已經完成了這些數據管控和數據治理的前提下，我們看到約80%的數據管控系統應用情況并不樂觀，他的效費比相對是比較低的。

第四個，100%

現在幾乎所有的數據治理的工作呈現出“運動式”治理的特點，針對不同領域每個階段進行數據治理工作。

第五個，60%

數據使用過程中接60%的工時和資源消耗在數據準備的過程，并且更多的是通過外包的開發資源，外包的資源實際存在上面 第1、第2和第3的特點，一個外包資源在做數據準備工作的第一年可能質量、效果、效率都不是很能滿足要求，第二年各方面做的不錯，第三年可能就走了，這意味著一些重復性的工作，挑戰性不大。

第六個，80%

以監管為例，我們發現在監管報送的數據質量方面， 80%會出現一些錯報、漏報，更多是因為數據治理沒有很好的解決底層業務復雜性，稍后我會講為什么業務復雜性會影響到整個數據質量。

數據資產化工作現狀

以上是當前數據應用過程中遇到的問題和特點，由這幾個特點可以得出：我們的數據治理工作過去10到15年雖然取得了非常不錯的成效，但是仍然有進一步的提升空間，這個提升空間就是我們做好數據治理工作的目標，我們把這個目標再提煉一下，至少從偶數科技實踐和觀察角度應該包括三個部分：

第一點，要形成一套基于業務視角的統一數據模型，這套數據模型是要解決底層業務邏輯復雜性的。

第二點，這套數據模型能夠切實解決數據應用過程中數據看不懂、數據找不到、數據找不全，以及數據應用過程中主要依靠個人經驗的問題。

第三點，能夠形成一套滿足不同用戶、不同應用場景的數據架構。

這是我們認為做好數據資產化工作最基礎的三點。

為什么要基于業務本質進行數據治理工作？過往在數據治理過程中更多的是偏向于業務的數據質量治理，以及業務數據的可讀性，主要集中在元數據缺失治理和準確性治理，這種治理帶來的好處是在使用數據的時候可以用表的名稱來判斷表中業務數據的范圍以及業務含義，比如，我們經?？吹降摹秾蛻粜畔⒈怼房梢耘袛嗥浒袑蛻舻男畔?，這種判斷大多數情況是有效的。

但是我們也發現，今年一季度銀保監會發布了一個EAST處罰信息，1/5以上的金融機構都被處罰，總共罰款8000多萬。處罰原因是數據的錯報、漏報、瞞報，為什么會發生錯報、漏報、瞞報？我們可以通過一個簡單的例子分析其原因。

假如要統計全機構風險數據資產，針對委托貸款風險數據資產是否應該納入進來，這是非常細節的問題。委托貸款可以在現金管理項下，也可以在非現金管理項下。（1）從業務口徑角度，我們可能對“委托貸款風險數據資產”的定義有理解偏差，進而直接影響到監管報送的數據質量；（2）即便沒有理解偏差，我們在實際進行“委托貸款風險數據資產”數據提取整合過程中，該數據分散在不同的業務系統（如信貸、國際結等系統）仍然會對數據提取造成障礙，最終造成錯報和漏報。

因此，偶數科技通過實踐和分析發現，錯報、漏報背后的根本原因是金融機構在數據處理過程中沒有基于業務本質對底層邏輯化繁為簡。

除了基于業務本質的數據治理，還有一個關鍵詞是監管數據治理。前面我們分享提到，金融行業數據管理及應用領域普遍外包的現象，少有企業有意愿、有能力投入大量的資源進行相關工作。但監管機構例外，監管機構面向的是幾千家不同的金融機構，無論從業務能力、技術能力以及職能目標，都需要建立一個基于風控視角的數據模型，這個數據模型現在以EAST最為典型（審計署也有一套統計數據模型起到了同樣的作用）。

實踐層面來看，EAST從1.0、2.0到5.0，一直是基于業務本質的設計思路，我們是可以借鑒監管研究成果進行基于業務本質的數據治理工作的。

我們前面說到的相關數據治理成果，形成風控視角的統一數據模型，其應用場景也是豐富的、有價值的。應用場景最有價值之處在于如何構建數據湖或者湖倉一體平臺。通過這張圖，我們看到的是技術發展的脈絡，通過技術發展這個脈絡，我們總結出數據管理平臺的現狀和不足。

監管數據治理成果的應用（湖倉一體）

第一個階段是早期傳統OLTP數據庫的出現。

從第二階段，大規模并行處理技術MPP出現的同時，數據管理平臺對應的是我們數據倉庫建設的階段，大概是在2004年、2005。有些起步較早的國際廠商（如IBM和TD）既有底層的數據庫平臺，也有上層的數據倉庫建設方法和統一的數據模型，這套數據模型在市面上得到了金融客戶的認可?，F在數據湖廠商的一個特點是只關注底層技術平臺，上層的平臺建設方法呈現出百家爭鳴的特點，并沒有形成一套行業標準和被認可的數據模型，偶數也在思考和探索湖倉一體的數據模型到底應該如何建設。

實際上，基于監管數據治理后形成的面向風險管控的統一數據模型是非常重要的，能夠指導我們建設湖倉一體平臺。高性能的底層基礎平臺加上上層的整合的數據模型，能夠更便捷的支撐我們的數據應用，成為數據應用的加速器。

當然數據治理不僅是剛才說到的基于業務本質做數據整合，還包括數據資產本身的盤點、傳統數據管控三大項、基于數據向上做的元數據治理、業務數據治理、數據畫像工作和數據資產運營。傳統的數據管控或數據治理是為治而治，并沒有建立管控與應用之間的抓手，抓手的問題其實要通過數據應用相關策略和手段進行。

以上是偶數科技數據治理的研究，目前偶數已經有一些實踐和探索成果，并且我們研發了一套統一的監管數據模型，我們把這套統一的監管數據模型叫做偶數模式。偶數模式與進階模式不同，在進階模式，雖然很多銀行都有統一的監管數據平臺或監管報送系統，但是其底層架構仍然是數據分體的，這也是為什么金融機構即便正確理解了某一業務口徑（如委托貸款風險數據資產），實操層面仍然不可避免受到技術架構掣肘，造成疏漏。

偶數科技監管數據治理研究成果

偶數不但已經探索研發的監管數據模型以外，還有一套完整的實施方法和流程，這套實施方法流程區別于傳統方法的，是引入了數據資產這個概念，結合前面提到的數據資產的運營手段，偶數實施方法論完成底層業務復雜邏輯所要求的模型整合。

此外，我們還有之配套的工具類產品，包括基于數據開發和數據管理的組件Lava，向上數據應用、數據分析的組件 Kepler和LittleBoy建模平臺。因此，偶數從工具層面、實施方法層面、模型層面都能更好的支撐金融機構完成基于業務本質的監管數據治理，應用到統一的報送平臺。當然，這套方法也可以擴展出如剛才提到的面向審計的統一數據治理和數據模型、面向營銷的統一數據治理和數據模型。

我的分享就到這里。謝謝大家！