一、相关概念和框架
首先来看一下数据标准的概念我们可能经常听到这个词语，却并不清楚其定义，不知道其中包含了什么。
在国际数据管理协会的关于职能域的车轮图中，并没有数据标准这一项。国内的 DCMM 框架中有数据标准一项。
另外， IBM 的数据治理框架，以及 CMMI 的框架中也是没有数据标准的。我们可以去分析一下国内的权威机构关于数据标准的定义，如下图所示：
通过总结国内对数据标准的定义，再去看 DAMA 框架就会发现，其数据治理中是包含了对数据标准的定义的。
国外的企业一般不会使用 Data Standards 这个词，它会具体映射到左边的，比如 Glossary，就是业务术语，或者说 Data Dictionary、数据字典，还有 Data Elements 就是数据元或数据项。在他们的语境当中业务术语是面向公司所有受众的，需要确保在一个组织中大家都使用正确的术语。数据字典更多的是给技术员工在管理数据的时候用的，它定义描述数据集，还有数据字段相关的属性。
对于业务术语而言，它的业务属性就是这个词语代表了业务含义，在技术层面就是数据的表现形式、取值范围等。管理属性是这个术语对应在组织内的一个归属。
下面是业务术语的数据标准的举例，比如企业法人，我们对它有一个定义和分类，它里面的这个数据元会有对应的描述，我们对这个描述会有很多的约定。当我们去梳理一个企业内部的所有数据的时候，从上往下去看会把它分成多个 level，第一个就是企业所有数据主题域的分组，它体现的是从数据的视角去看企业所有数据，它真正在业务层面映射的相关大领域对应的主题域是互不重叠的。
再举个例子，比如货品管理，它可以分为订货、库存，这两个是可以去分析的主题域或者业务上关心的主题域，对应的业务对象是订货，相关的订单就是它的业务对象。再下层去拆解的话，会有业务关系和逻辑实体，那逻辑实体是真正具有逻辑关系的一些属性组合，比如订单表本身是一个实体，然后表中的对应的字段是这个实体所干预的业务中定义的一些属性。最后的属性是我们经常提到的这个数据元或者数据项。
从业务角度对这些属性进行分辨。比如业务规则就是基础元数据，包括主数据、参考数据、计算方法、统计口径等。从技术角度来看，字段类别、字段格式长度属于来源，统计粒度还有统计周期，就是指标类树立标准所必须的。相关的管理属性，包括标准本身的版本、标准的创建日期，还有标准的管理部门等。
下面是主数据和参考数据的数据标准举例，比如北京、上海、广州，它所属的省份的简称可以对它进行定义为对应的中文名称的拼音第一个字母，城市的类别把它定义为一线城市、二线城市。这个是对所有的主数据当中的字段的一个描述，也就是元数据。这是指标的梳理标准。
下面有一个具体的例子，比如拨备覆盖率就是指标的名称，把它归类为基本属性，然后对指标的业务含义进行定义，指的就是贷款损失准备对不良贷款的一个比率。指标的类型属于比率类。从技术角度来看，它在底层占有的长度是 8，精度是 4。管理属性就是它的第一部门是谁，这个指标的版本是多少号。对于指标的数据标准，要从下面的 5 个角度去考量它，需要能够比较准确地去表达业务含义。
指标必须要有非常可信的来源，所以来源也是重要的考量指标可信度的维度。
下面看下数据标准的成熟度评估，第一个是数据标准有没有被完全解读，大家有没有充分的理解？标准本身够不够完整，够不够清晰？标准在组织内部的发布还有传播有没有到位，有没有贯彻，标准的管理变更流程够不够全面，执行是不是够彻底？我们可以从这几个角度去看一个企业内部的标准当前建设的成熟度到了什么样的程度。
数据质量指的是在特定的业务环境下，数据满足业务运行、管理与决策的程度，是保障数据应用效果的一个基础。数据质量管理指的是运用相关的技术来衡量、提高和确保数据质量的规划、实施与控制的一系列活动。所以从这里面可以看出数据质量也是一个非常庞大的系统工程。数据质量真正要去落地的时候，有以下几点需要注意：
（1）真正去落地是需要和具体的企业当中的经营管理痛点相结合，需要企业内部的 IT 数据团队和业务团队一起解决问题。
（2）PDCA 的循环要做起来，走通一个闭环之后，后面要持续去迭代。
（3）不能够期望仅仅依靠一个工具或者多个工具就能够解决数据质量的问题，它只能够解决一部分的通用问题。
数据质量的考量维度有很多分法，最重要的一个就是数据的真实性，它必须真实地去表达客观实体或者真实的业务。其次还有准确性或者叫可靠性，它适用于分析和识别那些不准确无效数据的一些方法。唯一性就需要我们去识别，还有度量重复数据，去掉冗余的数据，重复的数据会导致业务很难协同。还有数据的完整性，如果说模型设计不完整，那数据会有很多缺失或者很难使用。一致性其实是现在数据质量建设的重点，因为内部的多源系统，它的数据模型不统一，那它代表的各种约束也不一致，实体代表的含义也不一致。数据的关联性指的是比如有主外间关系，那两者的分析结果也会有对应的关联，然后及时性也是现在大家比较关心的数据质量的问题，实时地能够去反映我们的业务的状况，然后对应的快速决策实现在企业的一个非常重要的竞争力。
数据质量出现问题的原因非常多。从技术角度来看，有可能会出现数据的不完整。数据源本身如果没有做质量的控制，数据就会比较杂乱。还有采集的过程当中，如果对于采集数据的定义没有理清楚，采集的数据可能和我们想要的不太一样，传输过程当中可能会有网络闪断，或者中间出现传输问题，数据有可能会丢失。
在业务方面最大的问题是业务团队和数据团队交流的时候，对于需求没有互相对齐，或者需求不太明确，理解不一致。另外需求变更很频繁也会导致质量问题。在管理方面最大的难题是缺少管理的机构和目标机制。
下面举个例子，比较适合于大型集团。制度规范有数据质量管理的规范，管理的办法有考核办法，有事中的监控管理、事后的处理、事前的防范等相应的方法。技术的规范和模板包括数据质量的检查规则。
数据质量的考量维度可以根据不同的需求去评估，最重要的是我们能够去解决具体的经营管理的问题，从这个导向来出发，把它转变成对于数据的需求，从解决具体的某一个小问题出发去形成一个闭环。如果数据质量的管控想要真正落地的话，KPI 绩效是一个非常重要的点。
下面举一个例子是如何去评估数据质量管理的牵头团队，可以把它分成两个方向。质量问题本身可以有如下的这个角度，第一个是问题的个数、影响的范围和严重的程度，考核对象可以是问题的个数，考核对象就是数据管理团队的这个负责人。
质量问题的处理可以根据问题的及时性来进行评估，可以从事后治理、事中监控还有事前防范三个方面进行管理。
历史数据是大多数企业进行数据质量项目的第一步，数据质量的事后治理可以从这个问题的发起，发现问题提交给相关方，然后制定解决问题的规则，去思考问题出现的基本原因和相关的影响范围，最后制定出相关的方案进行实施。
事中监控最好是通过工具来执行，它的输入是根据过往经验得到的梳理标准和业务的需求，把它转变成 PDCA 自动化的流程，对应的标准转变成数据质量的监控规则，在工具中进行配置落地，并进行实时的执行，最终输出数据质量报告。
事前防范是最难的一项，它是为了总结业务需求，编成经过思考的一些模板。
对于数据质量解决效果的评估可以从四个方面进行评估，第一个是管理流程是不是够完善，相应的组织够不够健全。第二个是质量规则的落地和识别。
当我们去管理数据标准和数据质量时，对应的组织保障把它分成了 3 个类别，分别适用于不同的机构。
第一种是集中式的，它的特点是数据管理的负责人和数据管理团队是专职的、永久的，他们对所有数据的产生、演变、维护进行集中式的管控。这一种管控方式的优势是它有一个强有力的数据管理的专业组织，负责企业级的数据管理，职责明确，目标清晰。组织是固定的，组织内可以做专业化的分工，整个汇报条线清晰，自上而下的执行具有驱动力。他的问题是对于数据管理人员的能力要求非常高，整个组织比较庞大，成本也比较高，其他部门可能没有数据管理的能力，所以需要跨部门的沟通，成本比较高，对协作的要求也比较高。因为比较集中，所以容易僵化，会影响工作效率，所以这个集中式的方式非常适合于集团企业，比如大型的央企、大型的集团。
第二种是联邦方式，它的特点是在总部设立一个数据管理的负责人，对数据管理整体的活动进行协调管控，在各个业务单元设立专门的组织或者角色，他负责业务领域的数据管理工作。整个组织的成员可以是专人专岗，也可以是兼职。它的优势是数据管理和业务管理可以更好地融合，可以根据职责的需要设置岗位，执行效率比较高，同时它能够比较好地实现横向的协调和拉通。另外就是专业化的分工也具备，所以有助于团队对应的能力的提升。它的挑战是纵向需要加强组织影响力，还有协调能力，驱动企业数据管理的工作。还有一个挑战是数据管控的力度相对于集中式会弱一些，所以需要通过其他手段，比如评价进行监督。
第三种是分散式的，它的特点是不存在一个企业级的数据管理负责人，数据相关的活动分散在各个部门，它的成员也是以监管为主，它的优势是每个业务单元能够比较好地去理解自己的业务，每个业务单元容易在单个的业务领域上和系统上实现数据管理的工作。另外在应用需求的基础上树立的问题可以在单部门中快速被解决，所以一般服务满意度会相对比较高。挑战是缺乏一个企业级的管理视角，跨业务部门的协作会比较困难。所以对于联邦式比较适合于大部分的中小企业。
这个是对于集中式管理的组织保障的拆解，首先应该有个决策组织，这决策组织可以是数据治理的委员会，然后在下面去做管理的应该有一个数据治理的办公室。对于每一个职能域都有对应的负责人，在每个业务单元有对应的数据的责任人，在 IT 层面也有对应的比较明细的分工，去解决我们梳理当中出现的问题。
二、工具和技术
接下来分享第二部分是数据标准和数据质量相关的工具。
首先去采集数据标准内部的信息模型，还有标准相关的文档，把它转变成标准管理系统中的一些内容。然后标准当中有些内容可以转变成质量中的检查规则，有些业务需求也可以变成数据质量监控规则。他们会不断调用统一的元数据管理内容去进行检查。
这是系统管理数据元的演示。对于数据元可以去约束它的名称、状态、类型、数据格式、来源、关系等，这个标准可以映射到具体的表中字段进行审核处理。
对于结构化数据标准比较好理解，那非结化数据标准有哪些方法进行管理？
第一种方法是在业务场景中进行治理，海量的非结构化数据治理的成本非常高，所以必须在业务流程当中识别出其中业务价值比较大的数据进行治理，获取最大的投资回报。在业务场景当中提炼出关键数据和客户现在系统中的数据进行融合，通过数据服务的方式供业务去调用。
第二种它是把非结构化数据转变成结构化数据，用结构化的数据进行管理。
第三种是映射结构化的元数据，简化元数据模型。第四种方法是构建一个非结构化数据资产体系，把数据融合到数据资产管理当中，通过对废弃化数据资产进行智能化的标签识别管理。
数据标准的映射在承接数据标准之后，很容易把它映射到具体的数据项当中。
在过往的很多数据类的项目当中，很多企业都进行过数据质量的相关管控，其中的重点是能够把 PDCA 的整个闭环做好，从需求开始到最终形成规则去检查，然后自动化地去调度执行，形成对应的知识库。
另外管理标准和质量现在比较火的一个方向是主动的数据治理，首先在数据进入的时候，可以自动把数据标准和具体的数据做关联，这个标准可以和建立数据模型的对应的数据项关联起来，之后在数据开发过程当中可以去执行，执行完之后在生产调度过程当中产生的新的数据，对应的标准规则会自动执行对它进行评估。
另外一个能够提升标准和质量的比较新的一个方式是提供企业级的数据目录，通过数据目录形成数据资产的整个的详细清单，清单的底层依赖元数据去管理数据，它可以帮助分析师、科学家还有工程师快速找到他需要的数据。
三、典型案例
第三部分是典型案例。客户本身期望能够做到数据资产化，数据能够大集中，能够统一的存储和计算，能够有一套先进的数据架构，能够有统一的规范打通各个业务单元，使用的时候能够进行数据化的运营，能够快速地让数据为业务所用。整个项目分成几个阶段。
首先是满足业务用户的需要，对应的是需要数据模型自助地让业务去使用，同时有数据标准能够去规范数据本身。主数据对应的内容能够让业务人员快速使用，并且业务之间、业务系统之间主数据能够打通，形成统一的标准。
在这个项目当中我们为客户做的事情是构建了数据治理体系。
第二个典型案例是数据质量的提升项目。客户要求是希望能够让数据可知、可管、可视，希望能够提升数据质量监控规则覆盖的业务领域，实现覆盖各类营销等业务系统，让集团知道数据质量的情况，有系统进行自动化的检查，数据质量对应的指标能够可以及时感知，数据指标本身能够洞察业务驱动数据价值的变现。
我们细分之后会发现可以分成这么几类，第一个是对于单表质量的检测，这是针对 Hive code、 Oracle 等数据源类型的数据质量的监控。第二个是对流式数据质量的检测，针对 Kafka 类型的数据进行检查。第三个希望能够进行多表的数据比对分析，能够设定各种规则。第四个能够进行数据指标的分析。第五个是质量的规则能够关联内置的客户已有模板，能够自定义 SQL 的规则。最后是能够进行质量规则的合规校验，可以通过固定的阈值周期性统计波动的方式来判定目标是不是合规。
我们提供的数据质量的监控工具，可以提供多表的对比，所以可以针对这个源表和目标表的记录条数，还有具体的数据进行比对，可以及时告警发现问题。第二个具体的问题是数据质量问题的红绿灯机制，它的场景是每天都会进行任务的加工过程，当中可能会出现数据异常，比如异常如果影响业务的话，希望能够阻断并告知相关的责任人。
同时这个问题的处理希望能够指派给不同等级的工单，给不同岗位的人去处理，面对这样的需求，首先我们的工具里面可以设置强弱规则，工单系统可以设定不同的规则，给不同的人进行处理。
四、问答环节
Q1：数据质量评估的标准和数据质量的规则是什么？
A1：我觉得有好几个层面，第一个是纯粹技术层面的评估，技术层面的评估可以去看，比如在这个工具上有了数据质量的一些要求，这个要求在我们检查实现的时候，实现的程度是不是满足了业务的需要？第二个是现在图中展示的，就是当一个企业从组织层面想看一下数据质量的整个执行怎么样？那它不仅仅是包括技术内容本身，它还包含数据质量的整个管理有没有执行到位。
Q2：数据模型是否属于数据标准的范畴？
A2：是属于的，我们可以看一下前面的数据治理的理论框架，就是数据标准，它是一个典型的大词，和建模相关、和架构相关、和质量相关。当我们去看广义的数据标准的时候，它有一些和数据治理相似的地方，比如它会要求组织保障上有对应的人员，然后还有制度流程有没有对应的规范。那数据模型其实当我们把它拆解开来的时候，会发现这个模型里面，比如主数据的，还有因为模型这个概念比较大，主数据本身是数据标准管理的一个范畴，那主数据管理我们对它还会有标准的要求。
Q3：现在有哪些数据标准？
A3：数据标准这边有一个分类，如果是一个广义的数据标准的话，会包含很多方面。但是我们看到我们去讨论细而微的事情的时候，数据标准可以看里面的分类包含我们要对业务数据进行数据标准的管理，对主数据、参考数据还有指标进行数据标准的管理。
Q4：如何对历史留存的建模或者指标进行统一的梳理标准？
A4：刚才我们去讲数据质量的时候，有一个事后管控，就是对存量数据进行数据标准的管理，最佳的实践根据我们过往的经验，其实是我们先选择。首先我们应该有一个对应的经营管理当中的痛点，以这个痛点为抓手，然后我们去寻找这个数据所属的那个主题域，我们可以拿一个小小的主题域作为其中的一个试点，那这样一种方式是相对而言比较容易落地的方式。
Q5：在启动数据治理项目后如何解决甲方信息部门无法协调各业务部门，导致各类组织架构流程无法落地，只能停留在纸面上的问题？对乙方来说，如果要陪甲方无限度的持续治理，那项目的周期和成本如何处理？
A5：这个问题是作为乙方经常遇到的很常见的问题，我个人的建议最好的解决方式还是甲方自己需要有一个组织的保障。我前面有一部分就是讲我们的对于数据标准和数据质量，如果要落地的话，组织保障相应的一些类别，我觉得可以参考这里面的内容。
首先组织保障是第一位的，是最重要的，那有了这个组织保障我们要选择，如果说是那种特别大的企业的话，其实需要有个强有力的数据治理的部门，他们需要有非常高的权威去推动这件事情执行落地。然后如果是相对中小型的话，可以选择联邦的这种方式。对于乙方如果要陪甲方无限度地持续治理项目的周期和成本如何处理？这个问题比较难以回答，我觉得最关键的其实是把我们的数据治理的范围确定好，甲方是做无限期的持续数据治理的时候，如果出现这样的问题，那是不是我们在做这个项目的前期没有把这个边界梳理得足够清楚？然后它应该是分阶段的，然后数据治理应该伴随着一个企业的整个生命周期，所以每个阶段只能做每个阶段的事情，我觉得最关键应该是把我们的整个的每个项目的这个边界理清楚。
Q6：后续如果因为业务的变更，数据的口径需要更改，是否可以低代码完成维护操作？
A6：像这类问题的话其实是可以解决，有一类工具它可以做到数据指标的可视化的管理。然后在这个数据指标的定义过程当中去设定口径的时候，如果说需要更改，那可以在这类工具上进行更改，更改之后他会把所有历史数据进行一个重算，通过这种方式就可以实现低代码的方式完成工作。
Q7：从整个数据治理的理论，所谓治理的工作无法界定工作边界，比如一个系统有 1000 张表，对其中关键表做数据质量的治理，或者对所有表进行治理，其工作量是完全不同的。而一个项目的预算是有边界的，如何去界定数据的项目在界定数据治理范围后，如何在项目结束时给需求方展示数据治理的实际价值？
A7：您问的这个问题非常好，治理一张表和千张表确实工作量是完全不一样的，所以我们真正去落地数据治理项目的时候，需要在确定边界的时候，最好的一个边界的点就是如何给需求方展示数据治理的这个价值。所以我们去启动一个数据治理的项目，第一个就是要找到这个经营管理当中的痛点，可以寻找其中的一个主题域，甚至说找到一个主题域当中的一部分的关心的业务问题，先解决这一部分数据的这个问题。所以这个是一个关键，就是我们从主题域的角度出发这个数据这个项目，还有要解决这个具体的经营管理当中的一些痛点问题。
Q8：数据质量管理的效果如何评估？
A8：管理的效果的话，这边有一个给大家的一个示例可以看一下，比如我们去评估这个数据质量的管理效果的话，这四个维度偏向于管理维度，那我们可以增加一个维度，就是数据质量真正解决了问题业务问题的不是业务痛点的个数，所以这些结合起来的话就可以去评估管理的效果。
Q9：数值标准和质量有什么技术壁垒吗？
A9：我觉得数据标准和数据质量最关键的点可能不是技术壁垒，最关键点应该是我们经营管理当中对于标准和质量的一个要求，找到这个突破点。然后另外的关键就是对应的执行过程当中要把它形成一个闭环，那这个闭环其中对标准和质量的这个工具会有大量的这个定制化的一个要求。那这个定制化的要求怎么实现？我觉得可能是一个甲方企业需要去考虑的问题，因为它牵扯到供应商提供的一定是一个标准化的工具，所以我们这个甲方企业如何去把这一些我们的个性化的一些规则变成通用工具，在上面可以运转的这个规则尽量覆盖质量的问题。我觉得是我们这数据标准和数据量这两个主题最关键需要解决的问题。
Q10：元数据能否自动抽取和管理？
A10：其实这个是可以的，就是所有的数据的集成工具要能够从源端去抽取数据，首先要识别它的源数据，所以元数据本身也是可以使用同类的工具去识别、抽取和管理的。
