数据老兵谈数据基础功之 数据标准的认知

应约写数据标准的文章。

认识我的人知道我对数据管控治理（现在叫数据资产管理）这个领域很熟悉，从05年开始接触这个领域，一直到现在，接近14年了，算是数据管控这个领域的老兵了。但是一直不想下手写这个领域。

人往往就是这样，自己越熟悉的领域越不愿意去写，两个原因吧。

第一、如果你每年要给客户讲这个领域几十遍，会不会觉得自己都很烦？而且现在还要逼着自己把讲的东西梳理，写下来。

第二、越熟悉的领域，越觉得头绪和思路太多了，越觉得还有很多东西需要努力去探知，越不敢下手去写。

硬着头皮上。

关于数据标准我会分为两篇，六部分内容来写。

第一篇：国内近年来数据标准发展历程、标准的本质、标准分类和目标；

第二篇：标准的定义、标准执行策略、标准和其他治理领域的关系；

先谈谈国内数据标准近年来发展的历史过程：

第一个阶段：

开始涉猎数据标准，是07年，得益于我的一位业内甲方老大姐，是原来某银行的科技副总，主管数据，当年我在乙方负责管理这家银行的数据业务。是她很有意识的提出来做数据标准，按照银行数据仓库主题模型分类的角度，逐个主题进行数据标准定义，开始从客户、产品、账户（CAP模型，也就是我们说的客户、产品以及和客户达成的协议，这三个主题通常是以客户和产品为核心的企业的主要的三个主题内容）这三个主要主题入手开展定义，当时作为乙方也是摸着石头过河，但是自己有做过工行和建行数据仓库实践，遇到很多具体的数据质量问题和业务口径问题，这种困惑感觉是依赖标准能够逐步解决问题的。

从这以后，逐步变有了广发、国开等几家银行的具体实践了。

第二个阶段：

从10年人民银行的金融标准化工程（金标）、到11年银监会推动非现场检查EAST工程，配套进行数据标准建设（银标）、到12年开始参与证监会的行业数据模型和标准化工程（证标）、到16年适度参与了保监会委托中保信的保单要素标准化咨询（保标）。逐步通过这金融领域的四大标准化工程，理解了金融行业依赖底层数据治理驱动，如何借助外力推动金融经营实体进行内部数据治理体系建设；如何借助于数据治理提升监管数据标准；如何借助于数据治理提升行业系统性风险防范能力。

这个过程中，借着这些行业数据标准化工程的推动，我参与了不下50个金融机构的交流和项目实践。有意识的机构把这种行业级驱动力理解为自身变革的契机，也有机构只把它当作监管强制性的要求；有意识的机构逐步开始建立责权利明确的新组织去逐步推动，也有机构仍然靠原有工作机制阶段性解决问题；有意识的机构以自身业务特点为出发开展标准咨询和实践，也有机构以外部标准直接作为标准反向对标寻找差距。

不过这个过程中最值得大家去研究的是银监会的数据治理体系推动策略，从12五的《良好标准》检查工作，到13五的《XX指引》，行业级，系统性的推动这个工作，是我看到最有效的行业工程。做这个领域的同事一定要去找银监会的这两个发文，进行比较性阅读，以分析其中的道理。

主要经历过这个阶段的乙方企业，逐步通过自己的实践形成了成熟的帮助企业制定数据标准的咨询方法论，对市场提供服务。

第三个阶段：

在16年我从金融行业开始逐步涉猎其他行业的过程中，开始意识到金融行业在这个数据治理领域都在其他行业的前列，而且不是超前一点点。

过程中参与了一些政府的大数据治理工程，无论是数据资产目录编制还是数据标准定义，基本都是务虚性值，没有形成持续的有效策略，这也是政府大数据工程、多委办局协同、即使有大数据管理机构，因为缺乏治理业务驱动力，所以工作比较难开展。

也参与了机场、航空、地产、制造领域的企业相关数据标准化咨询工作，这些企业以解决自身紧迫业务问题为出发点，意识到通过主数据标准化定义，通过主数据统一构建、主数据管理策略落实，解决企业主数据一致性和规范性的问题。这个领域不同的企业都有一些不错的实践，又让我对不同行业、不同业态、不同数据主题的标准有了新的认知。

再谈谈标准本质：

“什么是标准“

要准确认知什么是数据标准，我们需要先从对“标准”的认知开始，然后才有对“数据标准”的认知。有了对本质的认知，我们才能找到正确的方法去做。

我们先来看看怎么形成标准：

公认的标准必须是标准协会颁布的，而各领域的标准协会（如金融标准委员会，简称金标委），在中国被认可，必须在中国标准化协会注册。

标准化协会受质检总局指导，让我们想到最原始的标准就是“度量衡”。

学历史的时候，我们知道秦统一了度量衡，秦始皇统一全国后，推行”。当时使用的度量衡标准和我们现在使用的有区别。

“一米

后来为了计量更为准确，我们利用光速把它定义为“1/299 792 458秒内行进的距离“

我们当时使用的是子午线的1/4000万，如果我们按照1/5000万，则目前我们使用的标准就和当前不一样了。但是一样可以作为一米（度的标准）来使用。前提是大家都认可，全世界有共识！

“什么是数据标准“

如果这种共识是企业级的，就是企业的数据标准；同理，如果是行业级的就是行业的数据标准或者国家、国际的数据标准。

• 那么大家对业务产生的数据信息应该是什么样子，如何达成共识？首先是大家对业务的理解能够达成共识。
• 最后如何达成共识？因为人理解问题的角度和局限性是不可避免的，因此就是集体讨论和决议是达成共识最好的方法。所以“舶来“的标准，可以作为参考借鉴，但是无法成为企业内部达成的共识，针对标准，达成共识的过程比结果更加重要。
  
  

结合数据分类看数据标准分类：

通常我们对数据的分类方法：

第一层：元数据和业务数据

第二层：我们把业务数据分为基础数据和衍生数据

国际上针对元数据是有规范和标准的，这部分，以后我讲元数据的时候再谈。

而业务数据是我们制定数据标准的重点。

因此我们把业务数据的标准也分为：基础数据标准定义；衍生数据标准定义。

• 基础数据就是针对按照业务作业流程原始操作发生，应该被记录的原始明细数据要素。所以基础数据标准帮助企业解决的应该是“依赖于基础业务共识，推动基础业务规范化，以及业务在信息系统中落地实现后产生数据的规范性问题。“
• 衍生数据就是针对业务统计分析过程中加工处理产生的数据信息。所以衍生数据标准化就是帮助企业解决“数据衍生加工依赖的的业务统计口径和规则的一致性问题。“
  
  

在这个分类的前提下，我们下一篇文章，展开两类数据标准的定义、执行策略讨论。以及再探讨数据标准和数据管控治理领域其它概念（数据质量、数据认责、元数据、主数据）的关系。

上一篇我们讲了数据标准在国内的一些发展过程，什么是数据标准，以及数据标准的基本分类。本篇开始我们重点探讨数据标准细节内容。今天决定把基础数据标准和衍生数据标准分开写，写两篇，写的透彻一些。

本片先写基础数据标准。

一、基础数据标准分类以及和主数据的关系：

当我们面对一个企业帮他定义数据标准的时候，首先考虑这个企业的数据标准的主题分类。个人的建议数据标准的主题定义还是应该和企业数据模型的主题分类统一考虑。

企业数据模型是利用关系实体模型描述现实业务模型，业务模型可以按照业务对象、业务规则和业务流程（行为）三种定义，所以思考企业的数据模型主题划分的逻辑思路应该是：

（1）    明确业务对象，确定描述业务对象的数据主题（可以包括客户、组织、员工、项目、产品、渠道等）。这类型数据大部分都是企业的主数据信息。

（2）    明确业务对象之间的关系，关系连接对象，通过关联关系和关系表的方式进行表达，形成实体和主题之间的关系。（大部分关系数据不构成独立的数据主题，而是依附于主数据主题存在）。

（3）    明确业务流程和基于业务流程发生产生的行为，确定事件（日志）数据包括的内容。（事件主题，可以按照业务领域进行事件分类组织。）

（4）    业务规则通常只是作为一些规则判定表或者参数表存在，构建的是事件类数据和业务主题数据之间的逻辑连接关系。也不作为独立的数据主题存在。

因此基础数据标准的定义主要集中在：

（1）    主数据主题定义和主数据相关的参考数据标准定义；（Master Data & Reference Data）

（2）    事件类数据的核心数据要素的数据标准定义；(Transaction Data)

二、基础数据标准定义前的数据认责：

在定义基础数据标准之前，先解决数据认责的问题。数据的认责就是明确数据的业务责任方，具体按照业务管理，负责这个业务数据的产生、修改、删除、维护的部门就是这个数据的认责方。

数据认责方的责任是什么？

l  数据认责方需要对数据的标准定义，特别是标准的业务要素定义承担责任。需要负责起草认责的数据标准，而且负责协同相关业务参与方讨论确认数据标准。

l  数据认责方需要在提出业务系统建设需求的过程中，提出按照数据标准进行执行的要求。保证自己的数据标准能够落地执行。

l  数据认责方对产生数据提出质量要求，并且对已经产生的数据质量问题的治理驱动承担业务部门应尽的责任。

l  数据认责方需要针对自己认责的数据定义数据安全等级，以及明确数据授权访问的机制。

三、基础数据标准定义：

对于每个数据主题的数据标准定义应该包括：

• 主数据对象的业务定义（主要明确在企业业务开展过程中，针对该类业务对象的定位）
• 主数据编码策略（包括主数据的业务主键定义和主数据唯一识别原则）
• 主数据分类原则（主要明确企业对该类业务对象不同类型的差异化管理策略）
• 主数据核心数据要素定义（主要包括每个数据要素的业务属性定义、管理属性定义和技术属性定义）
• 主数据相关参考数据的定义（主要明确参考数据编码和枚举值策略）
• 主数据相关关系属性的定义（明确不同类型主数据对象之间建立关系的过程中的关系类型定义）
  
  

对于附属于某类大主数据主题的小类中主数据，也是同样的定义方法。

需要重点强调的是分类原则，在一些企业内不同业务部门和不同管理目的针对某种主数据很难（或者说没必要）达到一种公认分类维度，例如：在针对资本市场基金行业的时候，针对基金的分类定义，从融资方式、管理方式、投资标的等每个角度都可以产生一个分类方法。因此很难用一种分类方法解决问题。

遇到这种问题如何解决问题？我们尽量找到多种分类方法用于分类的核心要素，把核心要素定义清楚就可以了。不要刻意强调一定有某类分类方法。这种情况下把分类方法用在衍生数据标准化的维度定义和维度数据映射中来解决问题就可以了。

基础数据标准定义，应该尽量参考高阶标准（国际标准、国标、行业标准）做到参考，而且可以完全映射到高阶标准的同时，再满足自身个性化的扩展。

对于没有可参考高阶标准的数据标准内容，就应该结合业务现状、数据现状、业务前瞻性考量在相关方之间充分调研讨论的情况下，达成共识。

四、基础数据标准的落地方法：

如果数据标准定义之后，只是形成一个定义，没有驱动标准落地执行，标准就是一个“形而上学”的纸片，因此标准的落地非常重要，而标准的落地又是一个很难得事情，需要企业业务和技术积极努力持续得推动才能解决问题。

标准落地的两个途径：

• 途径一：在业务系统中整改，特别是伴随业务系统重构和业务系统大规模优化调整的过程推动数据标准的落地执行。其中最重要的就是在业务系统中的标准落地应该作为业务需求的一个重点环节加入业务需求内容中，而不是作为科技强迫执行的策略。
• 途径二：对于短期无法在业务系统中整改的数据标准，尽量通过数据平台的转化策略进行执行。但是这种执行往往受制于当前数据并不符合标准的规范，而妥协。
  
  

所以基础数据标准落地的前提是业务对数据标准的认责！保障机制是科技的评审策略！

对于已经有存量数据的数据标准落地执行，策略分为三步：

• 第一步：调研现有数据的情况。
• 第二步：形成现有数据内容和数据标准的差异分析。
• 第三步：进行数据标准的落地方案建议，对于分类和标准不统一的数据，应该通过重新映射方式，映射到新的数据标准定义，但是这种重新映射必须是业务部门认可的。
  
  

  

五、基础数据标准和元数据关系

基础数据标准包括了数据的业务定义和技术定义。但是如果数据标准没有经过落地过程和数据建立关系，则数据标准仅仅是数据标准；当数据标准经过落地过程和数据建立了关系，则数据标准直接转化为该数据的元数据定义。

因此我们讲数据标准本身就是元数据（关于数据的定义和描述信息的“标准范本”），只有将它转化为真正的元数据，才有意义。

六、基础数据标准和业务术语

在IBM的数据治理工具体系内，并没有完整的数据标准功能，他们有一个叫做“Business Glossary”的东西，也就是我们说的业务术语。

业务可以将业务术语进行定义，同时在定义具体的数据的过程中引用业务术语。

我们可以将业务术语理解为数据标准的一部分，或者说它是数据标准业务部分的可以参考的局部范本。

七、数据标准和数据质量的关系

我在讲课的时候，总讲一句话“衡量质量的依据是标准，质量治理的目标也是标准”。也就是说治理工作标准先行！当然这种说法不代表没有数据标准定义就无法开展数据质量工作，而是说有了数据标准定义更便于系统性的开展数据质量工作。依赖于数据标准展开对于业务系统产生数据的数据质量规则校验，是系统性的侦测数据质量问题的方法。

以上是针对基础数据标准化的核心内容，我们下一个章节讲衍生数据标准化。

本篇我们换一个角度理解什么是衍生数据标准。

衍生就是数据按照业务需求进行加工处理。

那么我们在RDBMS时代，数据所有的加工基本都是通过SQL来完成的。

而SQL是有语法格式的。我们来剖析一下。

Select AAA,sum(BBB)

From CCC

Left Join DDD on EEE

Where  FFF=fff

Group by AAA

这就是基本的处理逻辑。包括几部分：

（1）    最后结果集我们选择的AAA一般来说是维度，同时也是分组计算的条件。

（2）    Sum(BBB)是我们计算出来的度量值。

（3）    CCC是我们的分析对象主体。

（4）    CCC关联DDD是我们构建的分析场景。使用的EEE是构建场景的关联条件。

（5）    FFF是我们进行筛选和判断的条件。是基于场景内的范围进一步控制。

基于这个分析过程我们来思考一个问题：

“如果我们说贷款余额是一个指标，是否对？” 甚至我们干脆说“日终余额”是一个指标吧。其实他们都只是一个度量值。

基于以上思考，我们想要给出来，什么是衍生数据标准化定义:

那么我们针对最终的指标的标准定义应该包括什么呢？应该包括：

（1）    分析场景：通常我们在定义衍生数据标准的时候，用指标分类替代。换句话说我认为指标分类就应该是分析场景定义。

从业务应用场景角度来针对衍生数据标准进行分类。因此衍生数据的分类场景定义应该和企业的应用体系规划基本吻合。关于企业的应用体系规划，我在《数据老兵谈数据基础功（七）、应用体系规划》一文中已经进行了阐述。不在重复写了。

另外分类可以有层级，也就是某个大的应用场景，可以细分为多个子应用场景。也就是指标细类。

（2）    分析主体：基于分析场景下，我们首选要选择的是我们分析的主对象。

举例说明：都是利用客户表、账户表、产品信息表关联构建的分析场景。但是我们选择客户作为分析主体，关注的是客户持有不同类型产品的数量，以及产品余额；而我们选择产品作为分析主体，关注的是持有某种产品的客户数量，因此产生的维度和度量也是有差别的。就像我们写SQL，需要确定那个表是主表，再去确定其它表和它的关联关系一样。

（3）    约束条件：

基于以上两点，其实我们已经完成了业务场景构建和分析对象选择，从数据库加工策略上看，我们已经选择了数据集范围。但是在这个数据集范围内，不是所有的数据被关联之后都有意义，有一些和具体业务分析目标无关的数据就应该被剔除，不纳入计算范围。这就是我们说的约束条件。也就是通常写在Where条件之后的东西。

当然有两种写法，一种是剔除没有必要的数据内容；一种是选择必要的数据内容。皆可，因此我们在描述约束条件也就有两种方法：“剔除XXX的业务数据内容。”、“只选择XXX的业务数据内容。”或者类似的话述。

-------以上三点是我们通常在衍生数据标准定义中容易忽略的内容。因为我们一谈到指标定义就是度量值和维度的组合。

（4）    度量：

这个大家很容易理解了。也就是我们通常讲的指标了。在企业定义衍生数据标准化的过程中，我们定义度量值应该注意以下几个事项：

第一：尽量不要针对增长率，百分比之类的进一步衍生加工指标去定义标准，而是定义基础指标标准。因为制定基础指标标准的目的是指导共享数据加工处理。而这些占比和增长比的指标大部分是可以在分析和可视化展示阶段，借助于工具就可以进一步完成计算的。

第二：并非所有的指标都是简单统计汇总，有一些度量值是需要复杂计算逻辑或者模型算法才可以计算出来的。

（5）    维度：

针对维度的分析，我们需要从基础维度，到衍生加工维度，再到有效维度组合三个层次看问题。

• 通常我们直接使用主数据属性或者参考数据代码作为维度的信息叫基础维度数据；
• 把基于某些统计度量值分段分区后形成的维度，或者基础维度组合加工后形成的维度信息，叫做衍生维度；
• 每个分析场景可以有很多独立维度信息。那么指标基于哪些维度组合对于分析更加有意义？我们需要定义指标（度量值）常用的分析维度。这些常用的分析维度组合就是我们说的有效维度组合。
  
  
  

在维度处理上我们应该注意的事项包括：

• 第一：维度衍生也是需要有业务含义的，需要按照业务分析决策的需求进行衍生策略制定。
• 第二：基础维度信息和衍生维度信息都需要有独立的数据存储。存储维度信息。而有效维度组合通常是放在不同粗细汇总粒度的事实表设计中来完成的。
• 第三：并不是所有的维度组合对于度量值来说都是有意义的。因此有效维度组合定义只是枚举常用的组合场景，而不是群举所有的维度组合信息。
• 第四：定义维度，也不能仅仅是把所有单独的可用维度进行罗列，而不考虑有效维度组合的问题。
• 第五：实施过程中，并非所有的有效维度组合都需要形成事实表存储，而是结合维度值数据量、维度缓慢变化情况、维度层级设计、基础数据量、矩阵稀疏情况、和等综合情况进行取舍。
• 第六：不是所有的度量值基于维度都是汇总逻辑。有些度量值在维度发生变化的情况下是以来算法重新计算的。
  
  
  

因此有效维度组合设计，通常是指导针对这类型指标的常用分析和物理存储策略的。

这就是衍生数据标准化定义的基本内容。

另外需要强调一下，我从来不主张企业全面启动指标标准化定义项目。企业应该进行应用体系规划，作为指标分类框架，另外梳理衍生数据标准化（指标标准化）的定义模板和管控策略。细节的指标标准梳理最好伴随着应用主题领域的建设逐步去梳理定义和补充完善，而且需要按照管控策略进行持续性管控和维护。

来源：小星星的随笔