新闻资讯

中台架构与数据模型管控

本文根据王琤先生在【DQMIS 2020第四届数据质量管理国际峰会】现场演讲内容整理而成。


各位新老朋友,好久不见,这是疫情之后首个数据治理线下大规模的会,如今各个企业的数据治理制度体系都已经慢慢的建立起来了,下一步就是我今天主要演讲的内容,中台架构,包括数据模型管控,这块就是躬身入局,开始真正落地数据治理了。


我看到今天基本上每个嘉宾上面的片子都有DAMA DMBOK,所以我这个演讲涉及到DMBOK上面这两块,数据架构(DataArcchitecture)和数据模型(Data  Modeling& design),数据建模是一个行为活动,而数据架构其实是一个产物最主要就是数据模型。

数据治理.jpg


进入到正题,先介绍一下数据架构简史,数据架构从上个世纪60年代已经开始有这个概念了,最早是E.F  Codd提出数据关系建模。后来General  Mills这个公司跟大学合作的时候,提出了一些维度和事实这两个概念。


再之后Peter  Chen,他是一个台湾华人,他1976年提出来ER图,;到80年代、Inmon、Kimball,如果大家做数仓比较多,肯定看过两个大师的著作,一个是叫《The Data Warehouse Toolkit》,一个是《Building the data warehouse》。

数据治理.jpg


今天涉及到主要是敏捷数仓,包括Data  Vault模型。今天提到很多的概念都来自于这几本基础书籍,如果大家后面有一些概念不太熟悉,可以回头翻这几本书,一个就是《Data  Warehouse  Toolkit》,还有一个《Building  the  Data  Warehouse》,《数据架构》里面谈到Data  Vault模型,当然也会涉及到阿里比较经典的书《大数据之路》,这本书前段时间很热,大家可能都有翻到过。


数据治理.jpg


今天我讲的内容是基于这些再往上的实践。


先说一说Inmon和Kimball的差别,这个我相信如果涉及到数据架构、数据数仓,一定会用其中的一种模式。


Inmon的核心是三范式的企业级数仓(EDW),右边Kimball会更直接一点,直接上一个星型模型,简单灵活直接,所以左边是三范式EDW,右边是星型模型数仓。


数据治理.jpg


当然也有一些更细节的差别,比如说Inmon通常是分阶段来建设的,刚才前面国网的老师也提到了,一个阶段一个阶段地去设计整个企业级的数仓。Kimball更合适快速交付,比如说有一些业务、财务部门很着急出一些报表,直接设计一个星型模型把这个数先拉通出来。当然这一块我们可以看到从开发难度上, Inmon企业级数仓会难一点,但未来的投入会不断减少,而Kimball未来的投入是不断递增的。


星型模型其实涉及一个非常严重的问题,就是数仓重构,一旦我们的数仓有改变,不管是前面引入一些新的业务数据源,还是后面的数据需求有变化,都会引起整个数仓库的重构。


数据治理.jpg


所以,可以看到引入新的数据源,会在这个过程中引起很大的变化,后面就是需求有变化的时候,又会引起新的变化,这经常会引起非常混乱的状态。


比如说,以前有财务的、销售的数据,现在我引入采购的系统,引进来整个的数仓库都涉及到它的重构,比如说我们原来有一些维度表,涉及到它的数据会有丢失,如果大家做数仓年头比较多,肯定碰到过这样的痛点。


像我们说的Kimball星型模型,这个维护量其实是逐步递增的,一开始我有一个星型设计,然后越来越复杂,可能一开始我只需要几十万的投入,90天就把这个事做完了,再之后就是逐步递增,甚至我们现在看到一个数仓,一个建设周期经常是过百万的,蛮大的一个项目,里面涉及到是数仓的重构,交付时间、难度、维护成本,都越来越高。我们看到有一些业务部门开始自己去搞自己数仓,放弃找数据部门来干这个事了。这对数据部门是非常被动的情况。

数据治理.jpg


我们现在看到很多企业,最终就是销售部门、财务部门、市场部门把整个的数仓拷走,自己再找一个供应商去干这个事,这个是星型模型Kimball的原罪。

数据治理.jpg

数据治理.jpg

怎么解决?这里涉及到刚才谈到的敏捷数仓,关键是业务规则的前置,弱化维度模型的模式。第一是各行业里都是有主题域的概念,比如说涉及到财务域、客户域、营销域等。这里面其实主要可以分两大类,一个面向业务的,一个面向分析的。面向业务的其实就是我们的业务规则,我们叫它硬规则,面向分析的叫软规则,就是跟着业务需求来的。


硬规则有很多可以参考的东西,比如说以前IBM FSDM这些行业模型,像金融行业的,制造业、零售业、交通业,包括航空有一些行业模型,可以把我们的业务做抽象。


数据治理.jpg


这是今天要讲的最重要最核心的。要把硬规则和软规则分开,这是我们看到整个企业架构,数据架构最核心的问题之一是要把这两块的内容分离,把硬规则前置,放到EDW企业的数仓之前,也就是客观的业务逻辑,比如刚才谈到国网SG-CIM4.5,就是国网输电、设备台帐等相关的核心业务,放到前置作为硬规则。


后面这个软规则其实是很主观的业务需求,这些业务需求是跟着业务部门的需求而变化的,这要把它分离到后面去。


这是我们现在讲的敏捷数仓或者是Data  Vault模型的核心的本质。


一开始打基础会比较花时间,因为要做企业级数据模型,也可以按不同的业务域来逐步迭代,之后的成本是一路往下走的。

数据治理.jpg



Data  Vault模型的基本概念里面分成Hub, Link、Satellite,3个核心概念,还是强调它是一个三范式的模型。


数据治理.jpg


从企业级数仓在往后的业务需求软规则,才到数仓的模型,那块您可以继续使用星型模型。


简单回顾一下,中台架构核心就是三个模型的范式,


第一个是星型模型,这里面专门用了一个保时捷的图,因为它是比较灵活的,建星型模型的时候,面向某一个主题,一个聚合的场景,适合多维的分析,它的问题就是大量的辅助表。

数据治理.jpg


三范式的模型,这里用大卡车的图,很强壮,尤其是支持多对多的关系,高度结构化,没有冗余,相对来说容易扩展,这个是三范式模型最强悍的地方,我们以前业务系统设计的时候都用三范式模型。


数据治理.jpg


它的劣势,第一是不能直接对接BI,因为它是一个多对多的关系,我们最终对接BI的时候没有办法多对多,不利于下钻,物理模型的设计跟业务会有不匹配的情况。


最后是Data  Vault模型,它其实是把三范式模型跟星型模型做了结合,所以它既有三范式的一些优势,又有星型模型的优势,既适合敏捷的场景又能快速构建一个星型模型,所以一般星型模型是在Data  Vault模型之后的,涉及到一些业务的关联的表达方式,也是比较灵活的,刚才讲的分成Hub、Link和Satellite(类似于我们以前的维度,会把它的属性拆出去),但是它的劣势是实体拆的比较零散,所以涉及到大量的表连接,这块我们一般都是在ETL Staging时处理,也不会太担心它的性能,因为这块不是直接对BI。

数据治理.jpg


我建议大家可以考虑企业级数仓用Data  Vault模型,做整体业务表述的构建,这里涉及到Hub、Link、Sat Link,后面再出相应的星型模型或宽表的数据集市,来构建整体的企业架构。

数据治理.jpg



这里我也拿阿里的OneData举个例子,我发现那本书大家更关注架构组件,其实那本书有一个精华,我看行业里头大家没有谈的太多,OneData里涉及到统一定义、标准建模、规范研发和工具保障,这是OneData里面最核心的东西,可以看到它其实跟刚才我讲的内容一样。


最底层是ODS,中间是公共的维度模型CDM,这更多讲的统一的业务模型。到上面ADS是变化的需求,是跟我们讲的Data  Vault这个模型的概念思想一致的。


数据治理.jpg


这里引用阿里书里的一些东西,像它的命名标准,前面数据治理制度体系做完了,管理流程设立了,后面就是执行落地,数据库设计的怎么样,数据资产使用的怎么样。命名规范就是非常重要的落地手段,这里涉及到数仓分层,而且都是有规范的,在DW层、DW的明细层还是汇总层,业务主题分类,二级主题分类,描述性修饰符,及对应指标的信息,其实这些都是OneData里面的一些精华。


数据治理.jpg


涉及到模型设计,包括模型评审,模型的规范,怎么去命名它,要有一个统一的模型库来管理,有统一的模型设计工具来设计,设计完了以后涉及到评审,这一整套东西是中台架构里面最精华的东西。

数据治理.jpg



我们的数据建模工具,支持从三范式模型到Data  Vault模型,到后面的宽表的数据模型设计。可以基于这个设计,比如说前面这三张表,直接生成一个宽表,或者生成一个Data  Vault为模型,可以基于映射关系直接生成它的数据操作脚本,数据开发那部分的DML脚本已经在这里面直接生成。


数据治理.jpg


当然我们最近也是跟阿里的Data  Works有一些合作,假如大家说用的是比较轻的方式,基于阿里的云平台,可以前面的逻辑模型、物理模型,包括数据库的设计在我们的建模工具里,到数据开发、数据迁移、数据服务的时候在这个Data  Works里面,这也是我们当前跟阿里合作的主要模式。


数据模型的概念不多说了,三层:概念模型、逻辑模型、物理模型。


数据治理.jpg


数据标准,大家可能都会涉及到,管理属性、业务属性、技术属性,这个阶段大家有制度了,有标准了,然后像建行一些头部的客户,他们把这个标准做成一个企业级数据模型,然后把这个模型作为标准,这是更高级的一个用法。


数据治理.jpg


这是个例子,数据模型管控从需求分析,从概念模型到物理模型,到物理模型。


要形成闭环,后面还有几步,一个是上线交付的时候,要把模型封版,然后到运行维护的时候,要跟生产态的数据库做比对,当前封版这个模型与当前的生产库元数据做比对,这是整体的模型管控流程。

数据治理.jpg



所以,事前做模型设计,事中做模型评审,事后的做模型检查和运维,其实模型管控和数据标准的管理运维要形成一个闭环的,因为现在落标这件事情一直是行业里最痛的点,怎么把数据标准落进去,通过发布标准,跟开发新建系统的模型设计结合在一起,在源端生产设计态做这个事情。


整体实施落地过程,先将模型导入,之后基于当前导入的模型做设计,最终发版到投产,这样一个过程。

数据治理.jpg



简单总结一下今天的演讲,第一个是躬身入局,因为前面的数据治理制度体系都有了,后面一定是开始去落地,核心就是数据架构、数据模型。第二是统一的数据模型工具,有模型的管控流程。第三是中台的架构分离成硬规则和软规则,企业级数仓 EDW之前是硬规则,出去之后偏分析的、偏变动更强的软规则,构建起这套数据架构。


 


Datablau提供国内唯一的数据建模工具,及数据模型管控平台,在很多的大型企业已经大面积使用。同时我们本身也是提供一些数据架构相关的咨询服务内容,我们团队很多以前一直都在搞模型,本身我们对这些行业模型都蛮熟悉的,银行、保险、证券、基金、电力、航空等等,我们也是积累了很多行业的命名词典、行业规范等。我们也可以提供相关的培训服务。


Datablau Data Modeler简介


DDM(Datablau Data Modeler)是国内首创的专业建模工具,是数据治理体系的重要组成部分。数据模型是“所有系统、文档和流程中包含的所有数据的语境。是生数据的知识。”换句话说,如果没有数据模型,组织IT系统中收集和存储的所有数据都会失去意义,也就没有业务价值。



Datablau简介


北京数语科技有限公司(以下简称“数语科技”)成立于2016年,是专注于数据治理领域的国内自主知识产权的专业软件产品提供商,主要业务是数据治理软件产品的研发与销售。数语科技的创始团队全部来自CA erwin,天然具有世界级水准的软件产品开发能力。


创始人兼CEO王琤:曾任职erwin全球研发总监,拥有超过十年以上数据建模和数据管理的从业经验。


CTO朱金宝:曾任职erwin首席架构师,先后服务多家全球知名企业,并曾全程参与中国建设银行数据治理项目,目前全面负责Datablau软件平台的研发工作和关键项目的实施工作。


数语科技根据DAMA理论和中国国情独立研发Datablau新一代数据治理平台,平台由Datablau DDM数据建模产品和Datablau DAM数据资产管理平台两大部分组成,全部拥有软件著作权和知识产权,一站式全面满足中国企业的数据治理需求。其中数据建模产品DDM是Datablau填补国内空白的重量级产品,帮助中国客户摆脱国外产品的垄断现状。2018年,Datablau数据治理平台通过了中国信息通信研究院严格苛刻的产品评测并获得的“最佳大数据产品”奖。


更多渠道了解我们

官网:www.datablau.cn

关注我们,及时了解数据治理干货

24.jpg

推荐阅读 查看更多