面向数据中台的数据治理

第一篇：梳理业务和数据

题记

数据中台是今年的热门话题，从一个数据治理的角度，阐述数据治理与中台的关系，以及具体的实施手段。与同学共同探讨，欢迎指正，共同进步。

---

中台实际是一种思想和模式，其核心思想是使企业或组织的资源进行组合和重用，最大限度的复用资源，加速前端业务的敏捷和创新。既然是一种思想，那么现实中就早已有大量的实践，比如中台的数据链系统，现代军队的班级单位可以通过信息化调度火炮/导弹等进行精确打击，提升了战场应变能力；通过中台的电商平台，一个偏远山区的大妈织的锦就可以行销全球，物流支付信用都有中台服务提供，这些都是中台模式的强大威力。所以整体来说，随着社会大生产分工越来越细，中台模式是社会生产发展的必然趋势，比如计算能力（云计算），支付能力（API Bank），后勤能力等等，越来越呈现社会化大生产组织的中台模式，能够迎合这个趋势是企业的业务战略和创新的主要方向。

让我们脚踏实地回到具体工作。对于IT部门来说，如何实现数据中台是各位思考的问题。阿里作为一个互联网企业，电商业务，面向2C用户，强IT属性，业务创新驱动，我想这些条件与大量传统企业有所不同的。所以我们重点探讨几个关键问题：

1、业务问题

你的企业哪些业务像电商那样具有相似模式，可能是面对的同一类用户，或者是其他相关联业务对象呢。如果有的话，那就很大的价值潜力可挖。

2、人的问题

企业的IT水平如何，主要是业务的数字化能力，IT的掌控和服务能力。我们应该客观认识到，中台模式是企业数字化和信息化的高阶模式，如果企业从来没做过数据仓库，业务对数据驱动没什么概念，那要是直接中台了，甚至是AI中台，就有点穿越了，做起来难，用起来也难。正确的做法是从治理着手，一步步把数据管起来和用起来，同时把人培养起来。事实上，数据建模人才是中台的关键，企业需要培养自己的数据架构师，核心业务建模能力靠外包和空降都是很难见效的。

3、数据的问题

中台是业务和数据的双驱动模式，数据治理水平决定了中台的整合能力。如果企业的基础数据模型比较混乱，没有具备数据架构和业务抽象能力的人才，那基本上比较困难。阿里的人才能力和数据能力积累到了一定的水平，做这个事情仍然需要有勇气的人来担纲完成。

那么，在企业的数据基础一般，人力资源不足的情况下，如何来落地实施自己的数据中台战略呢，我总结可以分这么几步完成。

第一步，盘点业务和数据

为什么要有这一步，阿里的经典经验里并没有着重提及这一块。究其原因是过去我们大多数的企业在数据这一块的管理是不够的，构建业务时，并没有遵循业务模型->逻辑模型->物理模型的系统化和规范化的建设思路，今天我们想整合业务数据的话，第一件事就是对数据进行逆向业务建模，目标是构建出数据与业务的关联关系。这是为数据中台摸清基础数据，所做的补历史欠账的工作，这一块希望随着企业IT治理水平的提升，通过规范化运营和管理，使基础模型成为企业数据与业务对应的中间层，为数据中台的敏捷运营奠定前提。

所以这一块的工作内容主要是盘点清楚数据资产，业务属性以及业务数据，它是企业架构工作的一部分，为了构建整合数据层，我们选择核心的业务流程和基础建模工作。

1、梳理业务流程  

业务架构是把企业的业务战略转化为日常运作的渠道，包括业务流程、信息、人员、位置、事件活动和业务战略目标，具体请参考Zachman和TOGAF的经典理论。然而由于设计和维护上的难度，业务架构的管理普遍不甚理想，那么也不用担心，本文提到的业务架构实施与经典理论的要求其实是不同的，对于数据中台来说，只需要简化的业务架构即可。简化的业务架构是充当业务与技术之间的桥梁，使用业务域和数据域的坐标框架体系，为数据的业务对象抽象和数据对象的管理，提供有效的实现路径，而这也是抽象业务需求，进行数据建模的必备知识。

（数据对象的业务坐标系）工作重点是梳理业务流程，就是盘点企业主要的业务职能，业务流程，业务对象。与传统EA工作内容相比，可以在梳理的粒度上进行控制，以主要的业务对象为中心，避免陷入旷日持久的后台工作而不见成效。

2、梳理基础数据模型

根据业务架构和业务流程的规划，进行主要业务域和数据域的定义。基础模型的作用就是对原系统数据进行数据盘点，将业务流程和业务对象进行物理层数据的映射，建立数据与业务的关联关系，为中台的整合模型打下基础。

• 构建模型主题，基础模型的主题可以对应到一个业务流程或者主要的业务活动，粒度可以根据业务的重要程度而定。
• 定位业务对象的物理对象，梳理物理对象的业务属性，排除非业务属性，建立业务对象和物理对象的关系。
• 复建物理对象之间的业务关系，也就是主外键关系，进行数据拉通的准备。这一部分工作非常重要。
• 建立数据标准，通过盘点业务属性信息，建立企业的数据标准，过程中进行同名不同义的统一。这即为排除重复业务属性，也是企业长期数据建设的规范。
  
  

限于篇幅，无法将工作的粒度展开。行文至此，已经盘点清晰了现状的数据资产，可以做到从业务找到数据，也可以反之。技术可以拿着清单与业务讨论需求，共同甄别不同域的客户统一问题，这为数据中台的整合层构建打下基础。

后记：数据模型的整合过程，请见第二篇：构建数据资产；至于盘点过程，盘点工具，策略选则等，请见本文的第三篇：数据盘点和常态运营。

第二篇：构建中台融合模型

题记

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

---

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

问题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