本文根據王琤先生在【DQMIS 2020第四屆資料質量管理國際峰會】現場演講內容整理而成。

圖1.1

Datablau數語科技創始人 王琤

演講嘉賓介紹 - 王琤

• 信通院資料資產專家委員會成員，資料資產白皮書主要撰寫人，IEEE member，OMG member，DAMA CDMP，復旦大學、人民大學、北京航空航天大學的客座講師 。

• 2006年加入CA，曾任CA ERwin全球研發負責人；在資料建模領域有十幾年經驗,客戶多來自世界500強，如美國銀行（BOA），SunTrust，AT&T，殼牌等。深度參與建設銀行新一代系統資料模型設計。

• 2016年率ERwin原研發team部分骨幹創立Datablau，創新型資料治理理念及國際水準的建模工具DDM、資料資產平臺DAM、資料目錄DDC產品市場高度認可。公司已成功服務多家國內大型企業的資料治理專案，包括華為，中國人壽，平安銀行，微眾銀行，國電水電，嘉實基金，東方航空等大型企事業單位，具有豐富的資料治理專案諮詢，管理和實施經驗。

演講目錄

• 資料架構簡史

• 資料架構最新趨勢

• 阿里中臺與資料架構

• 資料模型設計

• 資料模型管控

• 實戰案例分享

王總：各位新老朋友，好久不見，這是疫情之後首個數據治理線下大規模的會，如今各個企業的資料治理制度體系都已經慢慢地建立起來了，下一步就是我今天主要演講的內容，中臺架構，包括資料模型管控，這塊就是躬身入局，開始真正落地資料治理了。大家對我都很熟悉了，資料管理的老兵，以前做產品ERwin，負責整個ERwin全球研發，做了十幾年，如果大家需要做模型設計肯定都會用到這個產品。我們2016年成立Datablau這家公司，現在服務了國內很多的大型企業，提供資料治理相關的產品和服務。

圖1.2

公司核心的團隊都是以前ERwin的研發團隊，相關的資料治理的產品已經到了5.0，這是我們的一些客戶，現在的客戶Logo比去年又多了一倍，涉及銀行、保險、證券、基金，能源、製造業、航空等等。

我看到今天很多嘉賓有提到DAMA DMBOK，我所講的涉及到DMBOK上的資料架構(DataArcchitecture)和資料模型（Data Modeling& design），資料建模是一個行為活動，而資料架構其實是一個產物，最主要就是資料模型。

圖1.3

圖1.4

進入到正題，先介紹一下資料架構簡史，資料架構的概念從上個世紀60年代已經開始有了，最早是E.F Codd提出資料關係建模，後來General Mills提出了一些維度和事實。

再之後Peter Chen，他是一個臺灣華人，他1976年提出來ER圖，到80年代、Inmon、Kimball，如果大家做數倉比較多，肯定看過兩個大師的著作，一個是叫《The Data Warehouse Toolkit》，一個是《Building the data warehouse》。

圖1.5

今天主要涉及敏捷數倉，包括Data Vault模型。今天提到的很多概念都來自於這幾本基礎書籍，如果大家後面有一些概念不太熟悉，可以回頭翻這幾本書，一個就是《Data Warehouse Toolkit》，還有一個《Building the Data Warehouse》，《資料架構》裡面談到Data Vault模型，當然也會涉及到阿里比較經典的書《大資料之路》，這本書前段時間很熱，大家可能都有翻到過。

今天我講的內容是基於這些再往上的實踐。

先說一說Inmon和Kimball的差別，我相信如果涉及到資料架構、資料數倉，一定會用其中的一種模式。

圖1.6

Inmon的核心是三正規化的企業級數倉（EDW），右邊Kimball會更直接一點，直接上一個星型模型，簡單靈活直接。

圖1.7

當然也有一些更細節的差別，比如說Inmon通常是分階段來建設的，剛才前面國網的老師也提到了，一個階段一個階段地去設計整個企業級的數倉。Kimball更合適快速交付，比如說有一些業務、財務部門很著急出一些報表，直接設計一個星型模型把這個數先拉出來。從開發難度上看， Inmon企業級數倉會難一點，但未來的投入會不斷減少，而Kimball未來的投入是不斷遞增的。

星型模型其實涉及一個非常嚴重的問題，就是數倉重構，一旦我們的數倉有改變，不管是前面引入一些新的業務資料來源，還是後面的資料需求有變化，都會引起整個數倉的重構。

圖1.8

所以，可以看到前階段是引入新的資料來源，在這個過程中引起很大的變化，後面就是需求有變化的時候，又會引起新的變化，這經常會引起非常混亂的狀態。

圖1.9

比如說，以前有財務的、銷售的資料，現在引入採購的系統，引進後整個數倉都涉及重構問題，比如說我們原來有一些維度表，可能資料會有丟失，如果大家做數倉年頭比較久，肯定碰到過這樣的痛點。

圖1.10

像我們說的Kimball星型模型，這個維護量其實是逐步遞增的，一開始我有一個星型設計，然後越來越複雜，可能一開始我只需要幾十萬的投入，90天就把這個事做完了，再之後就是逐步遞增。我們知道一個數倉的建設週期經常是過百萬的，蠻大的一個專案，裡面涉及到是數倉的重構，交付時間、難度、維護成本，都越來越高。我們看到有一些業務部門開始自己去搞自己數倉，放棄找資料部門來幹這個事了。這對資料部門是非常被動的情況。

圖1.11

我們現在看到很多企業，最終就是銷售部門、財務部門、市場部門把整個的數倉拷走，自己再找一個供應商去幹這個事，這個是星型模型Kimball的原罪。

圖1.12

怎麼解決？這裡涉及到剛才談的敏捷數倉，關鍵是業務規則的前置，弱化維度模型的模式。第一是各行業裡都是有主題域的概念，比如說涉及到財務域、客戶域、營銷域等。這主要分兩大類，一個面向業務的，一個面向分析的。面向業務的其實就是我們的業務規則，我們叫它硬規則，面向分析的叫軟規則，就是跟著業務需求來的。

硬規則有很多可以參考的東西，比如說以前IBM FSDM這些行業模型，像金融行業的，製造業、零售業、交通業，包括航空有一些行業模型，可以把我們的業務抽象化。

圖1.13

這是今天要講的最重要最核心的。要把硬規則和軟規則分開，整個企業架構，資料架構最核心的問題之一是要把這兩塊的內容分離，把硬規則前置，放到EDW企業的數倉之前，也就是客觀的業務邏輯，比如剛才談到國網SG-CIM4.5，就是國網輸電、裝置臺帳等相關的核心業務，放到前置作為硬規則。

後面這個軟規則其實是很主觀的業務需求，這些業務需求是跟著業務部門的需求而變化的，要把它分離到後面去。

這是我們現在講的敏捷數倉或者是Data Vault模型的核心的本質。

圖1.14

一開始打基礎會比較花時間，因為要做企業級資料模型，也可以按不同的業務域來逐步迭代，之後的成本是一路往下走的。

圖1.15

這是Data Vault模型的基本概念了，裡面分成Hub， Link、Satellite，3個核心概念，還是強調它是一個三正規化的模型。

從企業級數倉在往後的業務需求軟規則，才到數倉的模型，那塊您可以繼續使用星型模型。

圖1.16

簡單回顧一下，其實我們核心就是3個模型的正規化：

第一個是星型模型，這裡專門用了一個保時捷的圖，因為它是比較靈活的，建星型模型的時候，面向某一個主題，一個聚合的場景，適合多維的分析，它的問題就是大量的輔助表。

圖1.17

三正規化的模型，這裡用大卡車的圖，很強壯，尤其是支援多對多的關係，高度結構化，沒有冗餘，相對來說容易擴充套件，這個是三正規化模型最強悍的地方，我們以前業務系統設計的時候都用三正規化模型。

它的劣勢，第一是不能直接對接BI，因為它是一個多對多的關係，我們最終對接BI的時候沒有辦法多對多，不利於下鑽，物理模型的設計跟業務會有不匹配的情況。

圖1.18

最後這塊就是Data Vault模型，它其實是把三正規化模型跟星型模型做了結合，所以它既有三正規化的一些優勢，又有星型模型的優勢，既適合敏捷的場景又能快速構建一個星型模型，所以一般星型模型是在Data Vault模型之後的，涉及到一些業務的關聯的表達方式，也是比較靈活的，剛才講的分成Hub、Link和Satellite（類似於我們以前的維度，會把它的屬性拆出去），但是它的劣勢是實體拆的比較零散，所以涉及到大量的表連線，這塊我們一般都是在ETL Staging時處理，也不會太擔心它的效能，因為這塊不是直接對BI。

圖1.19

我建議大家可以考慮企業級數倉用Data Vault模型，做整體業務表述的構建，這裡涉及到Hub、Link、Sat Link，後面再出相應的星型模型或寬表的資料集市，來構建整體的企業架構。

圖1.20

這裡我也拿阿里的OneData舉個例子，我發現那本書大家更關注架構元件，其實那本書有一個精華，我看大家沒有談太多，OneData裡涉及到統一定義、標準建模、規範研發和工具保障，這是OneData裡面最核心的東西，可以看到它其實跟剛才我講的內容一樣。

最底層是ODS，中間是公共的維度模型CDM，這更多講的統一的業務模型。到上面ADS是變化的需求，是跟我們講的Data Vault這個模型的概念思想一致的。

圖1.21

這裡引用阿里書裡的一些東西，像它的命名標準，前面資料治理制度體系做完了，管理流程設立了，後面就是執行落地，資料庫設計的怎麼樣，資料資產使用的怎麼樣。命名規範就是非常重要的落地手段，這裡涉及到數倉分層，而且都是有規範的，在DW層、DW的明細層還是彙總層，業務主題分類，二級主題分類，描述性修飾符，及對應指標的資訊，其實這些都是OneData裡面的一些精華。

圖1.22

涉及到模型設計，包括模型評審，模型的規範，怎麼去命名它，要有一個統一的模型庫來管理，有統一的模型設計工具來設計，設計完了以後涉及到評審，這一整套東西是中臺架構裡面最精華的東西。

圖1.23

我們的資料建模工具，支援從三正規化模型到Data Vault模型，到後面的寬表的資料模型設計。可以基於這個設計，比如說前面這三張表，直接生成一個寬表，或者生成一個Data Vault為模型，可以基於對映關係直接生成它的資料操作指令碼，資料開發那部分的DML指令碼已經在這裡面直接生成。

當然我們最近也是跟阿里的Data Works有一些合作，假如大家說用的是比較輕的方式，基於阿里的雲平臺，可以前面的邏輯模型、物理模型，包括資料庫的設計在我們的建模工具裡，到資料開發、資料遷移、資料服務的時候在這個Data Works裡面，這也是我們當前跟阿里合作的主要模式。

圖1.24

資料模型的概念不多說了，三層：概念模型、邏輯模型、物理模型。

資料標準，大家可能都會涉及到，管理屬性、業務屬性、技術屬性，這個階段大家有制度了，有標準了，然後像建行一些頭部的客戶，他們把這個標準做成一個企業級資料模型，然後把這個模型作為標準，這是更高階的一個用法。

圖1.25

圖1.26

這是個例子，資料模型管控從需求分析，從概念模型到物理模型，到物理模型。

要形成閉環，後面還有幾步，一個是上線交付的時候，要把模型封版，然後到執行維護的時候，要跟生產態的資料庫做比對，當前封版這個模型與當前的生產庫元資料做比對，這是整體的模型管控流程。

所以，事前做模型設計，事中做模型評審，事後的做模型檢查和運維，其實模型管控和資料標準的管理運維要形成一個閉環的，因為現在落標這件事情一直是行業裡最痛的點，怎麼把資料標準落進去，通過釋出標準，跟開發新建系統的模型設計結合在一起，在源端生產設計態做這個事情。

圖1.27

整體實施落地過程，先將模型匯入，之後基於當前匯入的模型做設計，最終發版到投產，這樣一個過程。

圖1.28

最後開個腦洞，我們最近也是有一些超大型的客戶，他們業務系統的開發本身是先設計邏輯模型，先把資料庫裡面不同業務系統的ER圖抽出來，發現這個ER圖的業務關聯關係，基於這些關聯關係的業務邏輯，再去開發上面的UI，這個是從資料模型驅動的開發業務系統。

簡單總結一下今天的演講，第一個是躬身入局，因為前面的資料治理制度體系都有了，後面一定是開始去落地，核心就是資料架構、資料模型。第二是統一的資料模型工具，有模型的管控流程。第三是中臺的架構分離成硬規則和軟規則，企業級數倉 EDW之前是硬規則，出去之後偏分析的、偏變動更強的軟規則，構建起這套資料架構。

我們Datablau提供國內唯一的資料建模工具，及資料模型管控平臺，在很多的大型企業已經大面積使用。同時我們本身也是提供一些資料架構相關的諮詢服務內容，我們團隊很多以前一直都在搞模型，本身我們對這些行業模型都蠻熟悉的，銀行、保險、證券、基金、電力、航空等等，我們也是積累了很多行業的命名詞典、行業規範等。我們也可以提供相關的培訓服務。

這大概是我今天介紹的內容，大家如果有興趣可以線下到我們展位那邊做更多的瞭解，謝謝大家。