数据治理之参考数据与主数据管理

简介：最近凑巧参与了一次某行业的业务共创会议，期间讨论到了主数据系统，还有我们该如何参与主数据系统建设的话题。说实话，我一直以为我不会有机会参与到主数据与参考数据系统的话题中去，所以，又去把DAMA的书籍翻了翻。顺便也重新思考了一下主数据与参考数据这个数据治理的课题。

一、参考数据与主数据

最近凑巧参与了一次某行业的业务共创会议，期间讨论到了主数据系统，还有我们该如何参与主数据系统建设的话题。说实话，我一直以为我不会有机会参与到主数据与参考数据系统的话题中去，所以，又去把DAMA的书籍翻了翻。顺便也重新思考了一下主数据与参考数据这个数据治理的课题。

1. 基本定义

在DAMA指南中对主数据和参考数据的基本定义如下：

参考数据和主数据管理是对参考数据和主数据进行持续的协调一致和维护工作。

参考数据管理是对定义的数据域值（也称为词汇、术语）进行控制，包括对标准化术语、代码值和其他唯一标识符一级每个取值的业务定义的控制，和对数据域值列表内部和跨不同列表之间的业务关系的控制；并且对准确、及时和相关参考数据值的一致、共享使用进行控制，以进行数据分类和目录整编。

主数据管理对主数据值进行控制，以时序跨系统的一致、共享、上下文相关地使用主数据，以及对核心业务实体的真实情况的最准确、集市和相关的版本进行控制。

这段话，大部分人其实看了有点懵。换个简单的说法：主数据管理就是管理交易系统中的各种核心活动对象实体（常见的对象有组织、个人、产品等）在一个大型组织内部的一致性，参考数据管理就是管理交易系统中各种实体的属性的定义（代码值或者枚举值）的一致性。

2. 简明定义

在DAMS中国数据智能管理峰会的官网一篇文章中这样简明的描述了主数据管理和参考数据管理，内容如下（引用文章地址在本文最后）。

主数据--企业黄金数据记录

主数据（master data）主要是指经实例化的企业关键数据。

如上图，我们在上面设计完成数据模型设计的“城市表”中填写了相应的城市数据，例如，北京、上海、广州、南宁等等。这些在城市表中填充的数据，正是组织中国地理协会的主数据，因为这些数据是中国地理协会这个组织的关键业务实体，它为组织的业务开展提供关联环境，而且它可能在企业业务开展过程中被反复引用。针对这些核心关键数据，组织和企业无论从数据的质量、一致性、可用性、管理规范等方面都应该有着最严格的数据要求。

那么一般而言，以下涉及企业经营的人、财、物的数据最有可能纳入企业主数据管理的范畴，例如：

企业产品及其相关信息：包括企业相关产品、服务、版本、价格、标准操作等等；

企业财务信息：包括业务、预算、利润、合同、财务科目等等；

企业相关利益相关者：如客户、供应商、合作伙伴、竞争对手等；

企业组织架构：如员工、部门等；

可见，主数据就是企业被不同运营场合反复引用关键的状态数据，它需要在企业范围内保持高度一致。它可以随着企业的经营活动而改变，例如，客户的增加，组织架构的调整，产品下线等；但是，主数据的变化频率应该是较低的。所以，企业运营过程产生过程数据，如生产过程产生各种如订购记录、消费记录等，一般不会纳入主数据的范围。当然，在不同行业，不同企业对主数据有不同的看法和做法，正如我们与国内大型航空企业的实施相关数据项目时，也在为航班动态是不是主数据而纠结不已。

因此，有鉴于主数据对于企业的重要性，企业和组织需要对其主数据进行有效的管理：包括理解主数据应用需求，识别主数据来源及源头，梳理主数据上下游关系，数据整合和发布，提升主数据的数据质量等。

参考数据-数据的字典

在本文引用的假设案例中，我们将会注意到刚才填写的地市这类数据有些列，如省份、城市类型等。如果没有缺少上下文的环境，我们是无法理解其具体含义，这时候我们往往引入参考数据（reference data）加以解释和理解，如下图红色标注所示。

参考数据是增加数据可读性、可维护性以及后续应用的重要数据。例如，你看到“性别”的这个字段，很可能是1代表男性、2代表女性。在许多企业中有这样的约定俗成，而更多的参考数据可能记录在开发人员和运营人员的大脑当中。但问题是一旦这些人离开，您系统里面的数据就成了一堆没有注释的天书。

大家可能觉得，这所谓参考数据不就是数据字典吗？对，我们在很多系统里面都会有这样和那样的数据字典。但是正是由于这些数据字典局仅限于个别系统而没有统一标准，从一个侧面间接造就了大量的数据孤岛。企业为了进行更有效率的数据整合、数据共享和数据分析应用，开始尝试对参考数据进行企业或者部门层面的整合和管理，利用参考数据集记录系统尝试为范围内的IT系统中的数据库提供统一的参考数据。

小结

主数据则是真实的企业业务数据，是企业的关键业务数据。

参考数据则是对数据的解释，针对一些数据范围和取值的数据解释，让人们容易读取相关的数据。

3. 驱动因素

在任何组织中，都存在一些需要跨业务领域、跨系统使用的数据。如果这些数据实现了共享，所有的业务部门就可以访问相同的客户清单、地理位置代码、业务不么清单、交付选项、部件清单、成本核算中心代码、政府税收代码以及用于运营业务的其他数据，那么整个组织及其客户都会从中受益。数据使用者在看到不一致的数据之前，通常会建设这些数据在整个组织中具有一定的一致性。

在大数据多组织中，系统和数据的变化速度比数据管理专业人员所希望的要快。特别是大型组织中，各种项目和方案、合并和收购以及其他商业活动导致存在多套在本质上作业相同的系统，它们相互隔离，无法沟通。以上这些情况不可避免地导致了系统间数据结构和数据值的不一致，从而增加了成本和风险。组织可以通过对参考数据和主数据进行管理来降低成本和风险。

参考数据管理和主数据管理都是专门的数据质量改进规划，依赖有效的数据管理制度和数据治理活动。是一项持续的质量改进计划才能获得成功，不可能毕其功于一役。

参考数据和主数据质量改进计划的成本和复杂性由业务驱动决定，常见的业务驱动因素是：

a) 跨数据源、应用和技术的条件下提升数据治理和整合度。

b) 对于重要的业务相关方、角色和产品提供综合的360度视图，特别是提供更有效的报表和分析。

参考数据和主数据管理的目标包括：

a) 确保组织在各个流程中都拥有完整、一致、最新且权威的参考数据和主数据。

b) 促使企业在各个业务单元和各个应用系统之间共享参考数据和主数据。

c) 通过采用标准的、通用的数据模型和整合模式，降低数据使用和数据整合的成本及复杂性。

二、与其他系统关系

1. 现实情况

理论上在联机事物处理（OLTP）系统和数据仓库及商务智能系统都存在参考数据和主数据管理。理论上组织内所有的联机事物处理（OLTP）系统都使用相同的黄金记录和数据值，实际上在所有的大型企业内部跨交易系统环境中都存在不一致的参考数据和主数据。这不仅需要数据仓库系统来确认最真实的记录系统，同时还有确定最准确的参考数据和主数据。数据仓库构建构成中要花很大的代码用于清晰和整合不同来源的主数据，或者在数据仓库和商务智能环境中使用维度表维护主数据和参考数据，而不是在主操作系统数据库中维护并复制到其他业务数据库和数据仓库中。

如上所述，理论上参考数据和主数据管理是在联机事物处理（OLTP）系统层面需要去治理和解决的问题，但是实际上很多时候在数据仓库与决策分析系统使用数据的时候才会花很大的代价去解决。

如下所述，这是《数据仓库》一书中对数据转换和集成复杂性的描述。这些多源不一致的描述在数据仓库中去解决并不是从根本上解决了不一致的问题，只是利用这个整合的平台进行了一次表面上的掩盖，并未真实从源头解决主数据和参考数据的一致性与质量问题。

转换和集成的复杂性

a) 存在多个输入数据源。在某些情况下数据仓库中数据项的来源是一个文件，而在另外一些情况下，则为另外一个文件。逻辑上必须分清楚，以便由适当的数据源提供正确条件下的数据。

b) 当存在多个输入文件时，进行文件合并之前要首先进行键码解析。这意味着如果不同的输入文件使用不同的键码结构。那么，完成文件合并的程序必须提供键码解析功能。

c) 当存在多个输入文件时，这些文件的顺序可能不相同甚至互不相容。在这种情况下这些输入文件需要进行重新排序。当有许多记录需要进行重新排序时可能有些困难，但可惜的是，通常都是这种情况。

d) 存在多个输入数据源。在某些情况下数据仓库中数据项的来源是一个文件，而在另外一些情况下，则为另外一个文件。逻辑上必须分清楚，以便由适当的数据源提供正确条件下的数据。

e) 当存在多个输入文件时，进行文件合并之前要首先进行键码解析。这意味着如果不同的输入文件使用不同的键码结构。那么，完成文件合并的程序必须提供键码解析功能。

f) 当存在多个输入文件时，这些文件的顺序可能不相同甚至互不相容。在这种情况下这些输入文件需要进行重新排序。当有许多记录需要进行重新排序时可能有些困难，但可惜的是，通常都是这种情况。

2. 层次关系

从上一部分的介绍可以了解到，参考数据和主数据管理是涵盖数据产生的“联机事物处理（OLTP）系统”和“数据仓库及商务智能系统”的。但是应该是在“联机事物处理（OLTP）系统”这个层次去解决，并把标准化的数据同步给“数据仓库及商务智能系统”去使用。

作为一个做数据仓库的数据研发人员，我其实一直都认为参考数据和主数据管理是“联机事物处理（OLTP）系统”（业务系统）范围内的事情，而不是分析型系统需要去实施的。很多时候如果所服务的企业内部有参考数据和主数据管理系统，做了参考数据和主数据管理，对于我的“数据仓库及商务智能系统”工作来说是大大有益的。虽然很多时候这个主数据和参考数据的识别和标准化的工作，会被带到数据仓库与商务智能环境中来解决，但是从数据使用者的角度来看还是希望在底层解决。

之前服务过的某银行在08年实施了“统一客户管理系统”，实现了银行间多个业务系统的唯一客户识别，并对不同系统的遗留客户的归一做了识别。这是我接触过的一个主数据识别的业务系统，这个系统解决了银行之前个贷、理财、基金等多个业务系统的客户唯一识别。但是，后来我还是遇到了一个个人信息是以个贷的个人信息为准还是信用卡的个人信息为准的主数据识别的问题。是组合着来还是以某个为准，真是难以入目。个贷的数据是一个历史数据，都是在办理贷款业务的时候录入的，这个信息相对要准确真实，但是如果这是一笔10年前的贷款，这些数据可能早就不能使用了。信用卡的数据一般比较新，更新也相对频繁一点，但是信用卡的数据质量可能不太好，可信度要低一些。这是数据仓库能解决的问题么？同一个信息不一致的情况下，不管使用哪个数据都是猜的。我本人看了一些业务人员给的规则计算后的结果，只能说凑合着用吧，也没得选（我的选择最后就变成了数据仓库中的用户主数据信息）。这也是参考数据和主数据系统建设的重要意义，如果从源头解决这个问题，何必这么为难。

主数据的问题其实非常广泛。在税务领域，我们遇到了不同企业在异地注册的识别问题。多地注册企业是否一个企业的问题，在缺乏主数据系统的情况下这个问题回答的极为艰难。在公共安全领域，不同个人使用不同证件在多个不同场合，如何识别是同一个个人的问题，也是非常有挑战。所以，在业务系统这层做好主数据系统，真是非常的必须。

3. 与中台关系

数据中台概念和阿里提出ONEID概念后，突然间整个数据治理的事情都是阿里中台化的革命使命了。所以，我们在越来越多的项目中遇到了参考数据和主数据管理的事情。

谈到阿里的主数据管理，一定会提到ONEID的概念。阿里的ONEID是给阿里系的诸多APP识别同一个用户的一套个人身份识别的规则算法，如果对应在主数据管理系统中应该是对应“匹配规则”这个概念。在《DAMA数据管理知识体系指南》8.2.7章节中指出“主数据管理在未来面临的最大挑战是在多个系统中对于通一个人、群组和事物的数据进行匹配、合并、连接”。ONEID的实现与纯在交易型系统去解决主数据问题有一些形式上的区别：第一，ONEID是根据实际业务需求提出的主数据数据治理的一个小应用，而不是主数据管理系统，其覆盖的范围是传统主数据管理的“客户数据”。第二，ONEID的实现利用了数据仓库和机器学习与算法规则，是一种相对交易规则更加复杂的规则算法，是一种事后（数据仓库和商务智能）与事前（联机事物处理（OLTP）系统）共用的相对弱规则。

从数据中台和业务中台拆分的角度来看，主要从事数据中台工作的我对主数据和参考数据管理这个领域的划分还是在业务中台，不是自己的日常工作范围。因为业务中台的概念提出后，就提出了业务中心的概念。像“用户中心”、“产品中心”、“参数中心”这种中心化的业务系统全局设计，已经可以从根本上解决了主数据的企业级标准化的问题。

但是从实现的角度来说，只有少量大型企业能把全局的业务系统全部重构一遍？大多是渐进式和改造式。何况很多大型企业还有很多收购公司与关联公司，很难做到覆盖全面的管控。所以，主数据管理和参考数据管理，还是我们眼前大型企业必备核心数据治理工作。只是我们是否能利用当前技术上的更多的进步，来改善我们的治理工作实施方法和治理效果。

从另外一个角度来看，数据仓库或者数据中台所面临的数据整合的问题其实也是主数据和参考数据的问题。我们在数据仓库中构建了全局一致的业务模型，实现了数据中台中数据仓库级别的主数据和参考数据识别，并以此向下游的数据集市发布了数据仓库中甄别的主数据和参考数据。很多参考数据和主数据系统本身就有数据模型管理、数据采集、实体解析、数据共享等工作，其实很多时候也是利用数据仓库平台来实现的（或者自己构建了一个小型数据平台）。只是从最终服务对象上来说，服务的系统是主数据和参考数据管理系统。

看了两个传统的MDM系统供应商，STIBO SYSTEMS(思迪博)和IBM。从这两个公司对MDM系统的介绍来看STIBO SYSTEMS(思迪博)似乎在行业能力上更加领先，介绍也更加传统第一眼看到的是其涉及多领域的能力。IBM似乎更注重宣传功能，介绍诸如自助访问、更深入的洞察、同意管理、使用直观的仪表板来更主动地管理数据。总的来说，感觉落地一套这种系统从交付角度来说难度会非常有挑战，需要非常厚的行业沉淀，需要日积月累的持续的协调推进这个数据治理活动。我一直记得曾经坐在我对面的一个负责数据治理的同事，好像一年搞的事情就是几张代码表，我也不知道她最后搞完了没有。对于做这个事情的同事，我觉得心态一定要平稳，做好持续推进的运营计划，不用想着一次性解决问题，这样才能把事情做成。