全球最具影响力的数据智能产业服务和职业发展平台

168大数据

 找回密码
 立即注册

QQ登录

只需一步,快速开始

1 2 3 4 5
开启左侧

[数据治理体系] 面向数据中台的数据治理:构建中台融合模型

[复制链接]
发表于 2019-8-12 21:10:57 | 显示全部楼层 |阅读模式
第二篇:构建中台融合模型



题记
前一篇中重点介绍了如何盘点业务和基础模型的内容,本篇重点介绍融合模型的来龙去脉。融合模型是数据中台的核心,我们来重点探讨什么是融合模型?如何构建?核心价值是什么?



在前一篇文章发布后,根据有同学问的问题,写点我自己的看法,欢迎讨论。

问题1 :数据中台是不是需要大动作高投入才可以做?比如要有大数据平台,甚至是云平台。
这个其实是要看企业的规模和发展阶段。数据中台是融合数据/服务业务的思想,它需要的是企业数据驱动的战略/业务和IT的整合治理能力等。大数据平台/云平台等都是这个灵魂的躯壳,对数据团队要求最关键的是数据融合建模能力。有这个能力,我相信用传统数据库业也可以对接业务需求,实现中台的能力输出。这不是说大数据平台不重要,而是应该把握最核心的东西,因地制宜,打造自己的中台模式。

问题2:数据中台与传统的数据仓库有何区别?
可以简单这么说,数据中台是一种数据驱动业务框架思想,数据仓库是一种技术实现,都还是商业智能范畴。广义的商业智能涵盖了从建模到建仓到数据服务的整个过程,数据中台更强调了整合和服务的概念。因此传统数仓同学要转变思维,从被动取数转变到主动提供服务,数据目录服务,自服务分析,嵌入式BI等都是这个趋势,数据最终需要业务人高度参与,才能利于价值挖掘。



言归正传,接下来我们讨论一些操作层面的东西,前文已经介绍了数据盘点的内容,那么我们来讨论一下数据中台的融合模型。我们先看一下数据仓库的层级架构。
图中的原系统模型和ODS模型就是上一篇所说的基础模型,ODS是原系统1:1复制,理论上它们的模型是一样的,这些模型是面向事务设计即所谓OLTP。这些模型是典型的状态型模型,有些甚至不是ER模型。图中的绿色部分统称为中台模型即传统的OLAP,经典是分两层:数仓层(DWD/DWS)和集市层,其中数仓层就是今天文中所言的融合模型。

设计水平是工业制造水平体现的决定性因素,数据作为科技文明最重要的资产,设计能力更为重要。融合模型是对复杂现实的抽象描述,面对复杂而多变的需求,如何设计融合模型是一项创新的挑战。那么做好融合模型需要具备哪些条件?我认为需要下面四个要素。


第一篇已经说了业务和数据的重要性,做的工作也是补齐这个短板。这里说一下需求,主要指了解企业的数据战略,业务对数据需求,数据可以支撑的业务场景,数据创新和应用的领域等。数据中台既是设计出来的,也是需求实践出来的,两者缺一不可。从工程角度讲,需求可以决定中台项目的路线图,是项目阶段性成功的关键,同时满足需求也是验证融合模型能力的重要手段。需要注意的是要用设计来把控和抽象需求,不然会迷失在繁忙的报表工作中。

当然核心是人才,从这个三个条件的高要求看,靠个人是不现实的。正确的做法是靠团队和数据治理水平(体系),把知识库沉淀为各种模型,有效管控,所以有人说中台考验的是企业知识管理能力是非常有道理的。建模团队一般是业务和数据的混合团队,具备业务知识和抽象能力的人是最佳队友。



建立融合模型的总体实施步骤,细节非本文篇幅所能描述清楚,抛砖引玉,欢迎探讨。
第一步:建立数据对象体系
这里主要是指第一篇的业务对象体系,它是融合模型的脚手架体系,通过业务域和数据域有效的管理核心数据对象,使它成为宏观的施工图纸,由具有数据架构职责和能力的把控,在企业应对需求变化和创新过程中,有序进行,长期积累,持续构建。除此之外并没有新鲜的方法。

第二步:建立治理体系
融合模型是标准化和规范化的模型,在实施模型过程中,需要构建三个子体系,并在实施过程中应用和把控。
  • 数据标准体系,包含企业级数据标准,代码以及代码映射表等。作为一个国家的象征,度量衡的是必须的。对于数据质量问题,不合标问题(如代码不匹配)都应该进行处理,使数据符合数据标准要求。这里没有包含指标,因此本文的融合模型在基础层,不涉及具体分析型指标等。
  • 数据命名体系,包括企业标准化的业务词根,命名方法等。既然是一个家族了,按资排辈儿的起好名字很关键,好名字是最好的文档。
  • 数据设计规范,这个规范包括了数据库级别的分区索引规范,数据库映射规范,数据建模规范等。


第三步:模型设计,拉通数据
这是融合(Integration)模型的关键所在。阿里的中台案例里的ID-Mapping,就是为了拉通数据的目的。对于普通企业来说,做好主数据治理,保持客户/产品等主要业务对象的标准化唯一编码,可以有效提升数据拉通的能力。



从建模方法上主要是:范式建模 vs 维度建模,那么融合模型应该选择哪一种?这两种模型设计方法各有优缺点,一般设计都是采用有主有辅的混合设计。

  • 范式模型是从面的角度解决问题,本身就是一套系统,相对比较稳定,相承于源系统,易于维护,可以局部反范式设计,适度冗余提高服务能力,建设期就需要较强的架构和掌控能力,所以适合做底层模型。另外行业模型比如金融业的FSDM等也大多是范式模型。


  • 维度模型是从点方面解决问题,容易理解,易于建设,面向特定需求的服务能力强。然而稳定性不足,维护成本较高。维护不好会造成宽表爆炸,甚至数据不一致和烟囱式数据分析等问题,所以运行后期同样需要架构和管控。

业务相对稳定的企业,可以采用范式模型为主的方法,尤其是有行业模型借鉴的情况下。然后在范式模型后,建一个维度模型为主的集市层,进行应用层设计。这种架构在金融、能源、电信等应用很广。
互联网行业和新兴业务企业通常使用维度模型,如阿里的中台介绍的那样。这是因为业务变化频繁,没有稳定的行业模型借鉴,使用维度模型可以快速响应业务和需求,尤其是需求驱动强烈的情况下。

无论是哪一种数据中台模型,都需要基于源系统模型的进行抽象整合,原系统模型的标准化和规范化的水平,是直接影响建设数据中台难度的关键因素,因此原系统模型管控是数据治理的重要任务之一。

总之,模型是中台的核心能力,其抽象业务和连接数据的建模工作不是一时之功,也不是仅个人能力所能完成的,它需要企业级的积累,这也是数据治理的任务所在。目前大部分企业对模型的认识已经有了很大的提高,但并没有很好的方法来提升企业建模能力。举贤不避亲,Datablau提供了从原系统到中台的企业级建模和数据治理一体化平台,通过平台不同开发团队和业务部门的可以协作,使中台部门在庞大的组织中也能快速掌握业务知识,应对需求变化,为数据中台建立生态型的模型共建能力。

关于Datablau
Datablau创建于2016年,核心创始和研发团队全部来自于原CA erwin,天然具有世界级产品厂商的血缘和水准,是国内数据治理的第一品牌。依托多年的行业积累和技术沉淀,Datablau在产品设计层面充分发挥了后天优势,实现了集数据建模、数据目录、数据质量和数据准备为一体的企业级数据治理平台,全面满足企业对于数据治理的客观需求。
目前Datablau在嘉实基金、中国人寿、国电大渡河和四川航空等大型客户得到实际应用并深受好评,客户范围已经覆盖到银行、保险、制造业和能源行业等核心领域,Datablau已成为企 业数据治理领域的领导厂商。


原创文章作者
朱金宝  CTO
目前供职于北京数语科技有限公司,实施了多家大型企事业单位的数据治理项目,有丰富的企业数据管理工具开发经验。前ERwin总架构师,10年ERwin研发经验,负责产品全生命周期的发布,丰富产品发布和架构设计经验,多个大数据建模专利所有者和技术文章作者。
来源:Datablau

楼主热帖
168大数据(www.bi168.cn)是国内首家系统性关注大数据科学与人工智能的社区媒体!
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

关闭

站长推荐上一条 /1 下一条

关于我们|小黑屋|Archiver|168大数据 ( 京ICP备14035423号|申请友情链接

GMT+8, 2019-12-11 00:01 , Processed in 0.102386 second(s), 18 queries , Xcache On.

Powered by BI168社区

© 2012-2014 海鸥科技

快速回复 返回顶部 返回列表