01、數據治理概覽

1. 國家及監管動態分享

從國家及監管動態上來看，目前，數據治理已經不止停留在監管層面，更上升到國家的高度，這個趨勢體現在最近發布了一系列相關的法律法規，包括數據安全法、個人信息技術保護法、個人信息保護法、網絡安全法等。2018 年，銀行業整合了近十年的歷史經驗，發布了《銀行業金融機構數據指引》，該指引從審計、監管等方面規范了銀行業的行為準則；2020 年 1 月，監管部門首次針對數據治理問題，對某農村商業銀行開出罰單，表明數據治理真正納入監管范圍。繼而，銀保監會發布的各項制度愈發細化，陸續發布了針對數據質量、數據標準、信息管理等方面的制度。2020 年 5 月，銀保監會首次針對 EAST 報送開出罰單，并發布了關于《配合做好監管標準化數據（EAST）質量稽核調查相關工作的通知》。
2. 監管要求概覽

相對于互聯網和傳統行業而言，銀行業在數據治理方面起步早，在 21世紀初已經開始布局數據治理的相關工作，目前處于較前沿的位置。2018 年發布的《銀行業金融機構數據指引的通知》從治理架構和治理機制方面對銀行業近十年的經驗進行總結，明確提出要建立組織架構健全、職責邊界清晰的數據治理架構、制定全面科學有效的管理制度、確立數據質量管理目標并建立質量控制機制、建立數據質量監控體系和數據質量考核評價體系、建立數據治理問責機制、建立數據治理自我評估機制、建立數據質量整改制度等。該指引共 7 章 55 條，第一章為總則，第二章到第六章分別從數據治理架構、數據管理、數據質量控制、數據價值實現和監督管理方面解讀了銀行業的數據治理機制，第七章為附則。該指引重點針對銀行業金融機構如何制定數據治理體系以及數據治理應當發揮的作用。

3. 數據治理體系

首先，數據治理體系的基本原則是全覆蓋，包括指標數據、數倉、業務系統、標簽、特征等；
事項上，須涵蓋數據安全、數據生命周期、元數據、數據標準等；
架構上，明確要求須包括組織架構、制度政策、管理流程等；

另外，該指引還對數據治理的技術支撐、數據治理體系的建設和元數據的管理也作了明確要求。

02、數據治理痛點
1. 推動難

首先，數據治理面臨推動難的問題。

一是數據治理的范圍大，在做數據處理的過程中涉及的范圍較廣，例如，銀行涉及的數據主要包括業務主體基礎數據（即業務系統中的數據）、指標數據（包含數倉數據、數據報表數據、指標維度數據等）、風控特征數據和營銷標簽數據四類；

二是治理領域較廣，需要針對數據的標準、質量、數據安全、主數據、數據生命周期、數據資產等領域進行治理；

三是涉及部門多，整體而言，數據治理是一個全行級、自上而下的工作，需要管理部門、業務部門、科技部門協同配合。

2. 落地難

數據治理還面臨落地難的問題。數據治理在落地的過程中，會面臨諸多挑戰。

其一是數據標準落地難，以業務主體基礎數據，即業務系統的數據為例，新業務系統的上線及數據表的頻繁變動都可能是引發該問題的原因。如果想對這些標準進行全方位管理，需要耗費巨大的人力和物力，尤其在三方系統上線時，其改造成本也非常大，包括核心、賬管等核心系統的變更及修改時，也需要對數據進行攔截、將數據標準落地，其難度也非常之大。據了解，建行、工行在該方面成效較好，但其投入的人力、物力是一些小銀行、小企業很難做到的。所以，大家往往會陷入疲于奔命的狀態。
其二是數據質量整改難，以業務系統數據為例，由于數倉數據、數據指標相對簡單很多，對數倉數據進行一次重構可能就能解決相應問題；但對業務系統的數據（即源頭的數據)進行治理是非常之難的，應該以何種力度來推動數據治理的進程是一個值得思考的問題。舉個例子，業務可能會對數據質量提出問題，但是科技部門和業務部門的資源是否能夠支持整改，是否能明確數據質量的價值。
其三是數據安全管控難，在進行數據安全管控的過程中，經常會遇到一些強勢業務部門的挑戰。例如數據出航，業務為了數據合作臨時需要出具部分個人信息，但事先并未得到用戶的授權。此時，作為數據安全的管理部門，即數據治理組織，如何平衡業務合作與數據安全之間的關系，是否能堅守住數據安全這個原則是十分重要的。
3. 數據治理的“兩張皮”

很多公司在數據治理方面經常陷入“兩張皮”的情況。其一是“組織、流程、制度”皮，組織的流程制度很多，也非常全面合理，考核體系、評價體系也建立得十分完善。但到了真正落地的時候卻推不動；其二是“推動、落地、工具”皮，這些制度可能不具備落地性，甚至會因為資源問題發生工具不健全的情況。這個問題在傳統行業和互聯網公司會更嚴重。

03數據治理組織架構
1. 數據治理組織架構建設

在數據治理的組織架構，主要是如何通過數據治理的組織架構來爭取管理的力度，這個是數據治理的核心。整個數據治理是一個自上而下的建設方案。首先，在百信銀行，數據治理的責任是落在董事會的，即由董事會牽頭完成整個數據治理工作、成立了數據安全管理委員會（其他銀行可能成立的是專門的數據管理部門）。高級管理層在其中要發揮決策的作用。繼而，由大數據部來牽頭全行的數據管理工作，包含業務部門、科技部門及一些專項工作小組，例如數據安全小組、數據標準小組、數據質量小組等。
2. 組織推動

數據治理是自上而下的工作，如果爭取不到高層的資源，就算工具和體系搭建得再好，只要業務部門或者科技部門不配合，又缺乏管理力度，其落地性可能只是空談。以數據安全、數據質量、數據標準分別舉例，數據安全方面，數據出航是一個非常敏感的話題，當科技部門受到了業務部門的挑戰，應該如何盡職守住底線。一般而言，科技部門是服務于業務部門的，話語權較小，基本上是很難做到堅守底線。此時，如果建立了完整的體系架構，就可以借助組織的力量來實現。在百信銀行的組織中會包含風險管理部、信貸管理部等，在遇到這類問題時，這些部門就會發揮其相關職能，如果依然受到了業務部門的挑戰，就需要往上匯報，發揮高層管理自上而下的管控力度。其實從整個數據安全來看，技術體系已經很成熟了，但是主要的問題是怎么去守住紅線。在一些互聯網公司里，即使技術部門都做的很好，但當業務部門一定要出數據的時候，技術部門是沒有太多話語權的。數據質量方面，我們最近在做EAST的數據質量問題整改，如果想達到效果，在業務系統方面是必須有非常強的推動力的，因為每一個數據治理、每一個存量數據治理的整改都是極耗資源的，以還款方式這個字段為例，在實際操作的過程中，顆粒度是很粗的，其牽扯的系統較多，在數倉層面無法解決細化顆粒度的問題，只能推動業務系統去改造。如何爭取到力度，獲取到資源讓大家去改造，讓各個業務部門以及科技部門配合，還是需要依靠于組織的力量。第三方面是數據標準，將數據標準的強制管控，無論是數據倉庫還是業務系統的數據標準，如果想達到前置管控的狀態，也就是對增量數據的前置管控，其本質上是開發的效率和管控的折中，這個過程一定會犧牲開發效率的，這時候就要根據監管條例以及行內的發展向組織去爭取力度，把工具真正的應用落實。

3. 總結

在數據治理的過程當中，從上而下推動是十分重要的，數據治理的核心點就在于如何向上獲取管理力度。如果一直是從下而上推動的話，數據治理就會被套著一層枷鎖，是很難落地的，除了一些管理力度比較弱的情況，例如以價值為驅動的數據治理落地，一般可能會關注指標數據治理。這也是為什么現在的公司做數據治理都是以指標數據治理為出發的。

04數據治理落地
1. 數據標準落地——分類和痛點

數據治理的落地和數據治理的落地，一方面是基礎數據的數據治理（即業務系統的數據治理），在落地層面存在以下三個問題： 如何制定適合企業發展的數據標準？ 數據標準工作量檢查大，如何確保落地？ 動輒就是幾十萬的數據標準，有沒有必要按照全部的數據標準去執行？ 另一方面是指標數據的數據治理在落地層面的三個痛點： 指標是否有必要全部管控？ 是否有必要對數倉進行管理？ 如何保障指標的質量？
2. 數據標準落地——業務主題基礎數據的標準制定

首先，指標數據的落地，百信銀行制定了一套業務主題基礎數據標準，核心思路是通過制定和達成這些標準，打通整個的關聯關系。如何制定這個標準？主要依據的是國家規范以及行業的規范，例如綜合EAST、反洗錢、金融數據安全分級、個人信息技術保護的相關規范去制定這個標準。
3. 數據標準落地——業務主題基礎數據的資產盤點

還有一個問題是如何制定適合本行的數據標準，對百信銀行來說，正在使用的例如性別、還款方式這一套標準就與監管的要求不相符。所以需要基于自然語言處理技術，遍歷全行的數據標準，通過聚類等方式自動生成一些標準。在數據標準的制定過程中要綜合行業和國家的規范以及行內相關標準的實際情況（例如枚舉值是怎么樣的)。以機器學習的方式大大地減輕了整個數據標準制定的工作量，以自動化工具為輔，人工為主，大幅提升整個的數據資產的判斷能力。數據標準方面也會有一些信息相關的標簽，例如安全等級、個人金融信息等級、字段的編碼、字段的備注，都會落到數據標準上。接下來，我們要建立數據標準和數據表中字段的映射關系，打通整個數據資產。百信銀行根據上述方式制定出數據標準，根據自然語言處理技術發現涉及這個標準項的字段，并且將標準項與該字段的關系打通，維護到元數據的管理平臺，其核心是以自動化工具為主，人工為輔，人工智基本上是進行了簡單的審核工作，這就完成了整個數據資產的盤點。然后就可以依據這個數據標準采取一些管理動作。且在數據標準上也打了數據質量的標簽，例如某個字段為空、手機號必須是11位等，因此也包括數據質量的管理工作。然后包括安全的這些信息也都打在上面，就可以采取一些管理動作了。
4. 數據標準落地——業務主題基礎數據的前置管控

在制定了數據標準后，接下來是對于業務系統的數據標準落地的工作，就要在前置的管控環節對數據標準進行檢查。我們嵌入到了整個 DateBox 體系中，在上線的時候會使用一些工具進行檢查。

核心的邏輯是通過 AI 相關技術，包括自然語言處理技術，發現哪些字段涉及到了數據標準，例如一個 Cust ID，我們也能識別出它是 Consumer ID，即客戶號，這時我們會對這個字段的編碼和類型進行校驗，如果發現不符，我們會進行強制管理，要求必須按統一的標準進行更改。當然這個管理手段是向上匯報得來的，依賴于整個組織的架構去完成的。當不符合標準的時候，我們會拒絕上線，符合標準的時候才會通過元數據把相關信息記錄下來，再根據元數據去校驗其數據質量，是以數據標準為核心，對整個業務系統的數據進行管控。
5. 數據標準落地——指標數據的痛點

目前，指標數據的管理面臨幾個痛點，

第一是質量堪憂，包括在重要場合口徑不一致、同一個指標內容不一致、產出的延遲和數據準確性等一系列問題，造成管理者和分析人員對其可信度產生較大質疑；

第二是開發周期比較長，不能滿足業務的需求；
第三是復用率低，例如在報表中，同樣指標在多張報表中重復出現，造成大量重復開發的工作；
第四個是管理難度較高，指標是分布于數據倉庫、數據集市、報表平臺等多個系統中的，因為數據架構的層級較多，我們很難做到統一管理，也就是很難做到一個指標在這些平臺、數據倉庫中是一致的。但傳統 BI 無法解決這些問題。傳統 BI 的核心理念是，傳統 BI 工具只是對數據集市中數據表的引入，而沒有對數倉進行管理，只是在報表層進行管理；有一些工具可能是對數倉層進行管理，也就是說數據集市跟數倉是一體的，報表層就不一樣，這種管理是比較割裂的；公司可能很難做到數據口徑一致性的保證，因為可能一個指標會出現在多個報表或者多張表中；還有一個問題，當數據分布于不同的表中。
6. 數據標準落地——指標數據的架構

我們怎么來保證數據質量？其實有一個核心理念是“弱集市化”，甚至是沒有集市的概念。百信銀行的底層是數倉層，查詢引擎包括 Kylin、Clickhouse、Hive、MySQL、Presto、Druid 等一系列的查詢引擎，我們希望做到分析平臺是直接面向數倉的，具體做法是數倉會導入 Clickhouse 中，也就是按照維度建模來進行：實時表、維度表和指標維度會導入到整個平臺中，即導入 Clickhouse 這個引擎中；上層是完全沒有數據集市的，是通過選取指標維度自動拼裝 SQL，再對數倉進行查詢操作，完成從集市或從報表到集市到數倉的統計管理，也就是說指標口徑是在報表層和數倉層統一發揮作用，而不是割裂的，最后達成效果是完全去集市化的狀態。
指標管理，核心是把指標化成了原生指標、衍生指標和計算指標。例如，原生指標是授信用戶數，而衍生指標可能是某個產品的授信用戶數，計算指標可能是一個或多個指標兒通過某種計算后得來的一個指標。所有指標的定義都是在這套平臺中完成的，底層的數倉其實只存原生指標；所有衍生指標、計算指標都是自動生成的。然后就是維度的管理，我們會分成標準維跟雜項維來確定管理；接下來是對于模型的管理，就是在建模型的時候根據指標維度去建立整個模型，這是業內很標準的做法，也是整個數據標準的管理。最后達到的效果是在整個分析的過程中，業務只需要關心維度和指標，完全不會有報表的概念，即業務在分析的時候，只要選出授信戶數，我們會告訴業務，授信用戶是可以從哪些維度去看；在他選取某一個維度后，我們可以會告訴他，這些維度可以出哪些指標；最后通過保存模板的方式進行即時查詢，包括其他項目和報表的需求，也可以通過保存模板的方式去完成發布，包括在大屏上展示。

從管理的角度來說，報表、指標、數倉、集市是一系列完全達成了統一管理的狀態；從用戶角度來說，用戶對于底層的邏輯基本上完全不用關心；從效率角度上來說，基本上不會重復的開發同一個指標，因為指標都是從底層同一個表中取出來的，如果不是從同一個表中取的，我們也會在底層對兩個指標進行校驗；對衍生指標和計算指標的邏輯來說，當需要衍生指標和計算指標是，直接就在平臺上完成配置，大大提升了開發效率。
7. 數據質量落地

這數據質量的落地，主要的還是推動工作。在 EAST 報送的相關工作中會遇到大量的底層明細數據的質量問題，那這些數據質量問題怎么通過“責任到人”來推動問題的整改呢？首先要建立機制，要讓業務部門認識數據質量的問題是業務的問題，而不是科技的問題；然后可以開整改單，劃分哪些是業務的問題，哪些是科技的問題，落實責任到人，發揮全行的力量去推動。核心上來說，是借助組織的力量去推動整改的工作。

8. 數據安全落地

數據安全的落地，就是以數據標準為核心，把數據安全分級、分類，把安全等級打到數據標準上去，最后以數據標準為核心，采取管理動作，例如增量數據的運營，我們會在增量數據產生的過程中，對這個數據中的字段進行打標操作；存量數據的運營，我們會定期掃描，包括對表中字段的變化，自動按標準打標；必須根據標準對三級以上的數據加密，對四級以上的數據不應該留存的。在數據訪問過程中，我們也是根據標準來控制表權限、字段權限以及敏感數據權限的；在數據共享的過程中，因為我們已經知道了數據所屬的等級，以及對應等級的防空要求和紅線的要求，包括對敏感數據的管控，在共享的時候是可以很容易實現的。以上就是今天的所有分享。

05問答環節
Q1：有沒有一套方法論來分辨生死指標、核心指標和普通指標？
A1：其實核心指標和普通指標靠工具是很難去分辨的，例如訪問量，都可以用但很難分辨。但是有一套比較好的方法論，也是用的比較多的，就是在行里直接去爭取管理力度，與業務部門溝通，定義出行級指標、部門級指標以及臨時性分期指標，主要在于梳理，把指標責任到人，例如逾期率這些核心指標，可能最后會落到某一個部門來負責，通過工具來把控數據質量、元數據之類的。生死指標的話，確實不太理解。
Q2：代碼字段進行重新標準化后，已下發給下游的數據如何隨之變化？如果影響太大的話，是否有必要進行重新標準化？
A2：數據的源頭其實是業務系統，在業務系統中的數據如果重新標準化后，有工具的話是最好的，將改動的操作通知到業務系統和數據倉庫；如果沒有工具，就需要一些監測手段來監測到變化，下發給數據倉庫；如果沒有監測手段的話，就需要建立機制，首先要劃分變動的是不是重要的標準，例如一些銀行，普通的數據標準可能有十萬個，但在業務系統真正實行管控的可能只有 2000 個，當這 2000 個變化以后，在機制上是要通知到上層的，讓上層做相應的改動。如果影響太大的話，就需要一個前置的環節。當已經識別到要改的這個標準是非常重要的，那從安全等級上來說，可能是三級。如果從整個行來說，可能是類似還款方式這種影響業務非常大的數據標準，是需要提前向相關方征求意見再做改動的。
Q3：在指標計算中可能涉及到很多個表之間的 join、聚合，如果在線并發數很高的話，怎么去解決動態計算過程中高并發訪問的問題？是否有比較好的實踐？
A3：其實這個是二八原則，現在這種做法肯定是有性能問題的，因為它是實時的計算，我們也會模仿 Kylin，在計算會非常多的情況下，我們整個平臺是支持 Cube 這種操作的。