当前位置：首页 > news >正文

第十八章：数据治理之数据质量：“数据质量”不仅仅和“数据质量”有关

news 来源：原创 2025/5/27 20:26:35

按照顺序，这一章应该写【数据标准】，但是对于数据标准的理解，一直逻辑上说不通。说来有意思的是，虽然不能完全理解数据标准，但是，仍旧设计过相应的产品。

数据标准到底在哪里用？和数据指标是什么关系？又和数据质量什么关系？有了码表值，有了字段类型、长度、精确度的限制，就是数据标准了吗？现有的国家标准，行业标准是怎么影响数据标准的？问题太多，一时没有答案，也暂时没有想清楚，就先跳过数据标准。这一章我们说说【数据质量】，当什么时候理清楚了数据标准，对于数据标准有一个自己的理解的时候，再来补这一章。

提到数据质量，第一时间想到的就是数据质量模块。似乎只要用了数据质量模块的能力就能够解决数据质量的问题了。

但是，个人想说的是，“数据质量”不仅仅和“数据质量”有关。第一个“数据质量”是指数据的质量，第二个“数据质量”是指数据质量模块。

1、“数据质量”不仅仅和“数据质量”有关

”数据质量“不仅仅和”数据质量“相关。这句话说起来有点拗口，在有相互对比的情况下，提到”数据质量“时，就是指数据的质量，提到”数据质量模块“时，就是指一个专门的功能能力模块。在没有特殊的对比要求时，“数据质量”，可以简单理解为就是说“数据质量模块”。

所以标题这就话，应该说是，”数据质量“不仅仅和“数据质量模块”有关。

数据质量是一个系统化的工程，甚至可以说，整个数据治理的直接目标就是提升数据质量，进而实现终极目标发挥数据价值。

这件事情会涉及到很多模块，前面提到的【数据源】模块，通过对数据源的监控，保证数据源的连通稳定，以及提前发现数据源中是否变更表结构。来保证数据的按时产出，实现数据质量的及时性要求。

通过合理的【数据架构】，搭建合理的数据模型，理清数据的流转关系，确保整个数据加工过程，加工逻辑合理，实现数据质量的准确性要求。

通过后面要介绍的【数据指标】模块，使用合理的、统一的数据指标体系，来保证数据的一致性的要求。

甚至于大数据平台的运行稳定性，也是保证数据能够及时产出，满足及时性要求的一个前提。

所以你看数据质量是不是会和其他很多模块都产生关联。这是一个系统化的事情，有的时候，是一个见招拆招，遇到问题不断解决问题的过程。并不是说有了数据质量模块，或者说做了什么，就一定不会有数据质量问题了。业务是复杂的，只要有业务的运转，就可能出现新的情况，提供一个体系能够规律性的发现数据质量问题，解决数据质量问题，才是目的。

本章对于数据质量的介绍，不会涉及其他模块的内容，主要介绍数据质量模块，也就是提供质量规则，创建质量任务，进行质量校验，进而生成质量报告，这样的一个过程。

2、数据质量模块处理的时机

数据质量模块在进行数据质量操作时，一般会有【事前，事中，事后】这样的说法。这里所说的“事”，指的是“数据加工”这件事。

事前：也叫“事前预防”。在数据加工之前，即数据产生的过程中，将大部分数据质量问题解决掉。
事中：也叫“事中监控”。在数据加工过程中，同步进行数据质量的监控、告警或者任务中断处理。
事后：也叫“事后反馈”。在数据加工之后，进行一些监测，反馈。

说到这三个处理时机，一般的说法是，“事前”解决，效果最好，成本最小，是最重要的，也是解决问题的根本。“事后”解决，更多是反馈的作用，起到的作用很小。“事中”的解决，是现在的大部分方案，也是最便利，可控的。现实情况是不是如此，也仅仅说下我个人的想法。

3、事前数据质量的可行性

说到事前数据质量，先看看主要想做什么？主要是想在数据加工之前，也即数据产生的过程中就根据一些数据质量规范、要求，规范数据产生的过程，保证数据在产生时就是高质量的。

数据产生的过程，就是业务运行的过程，所以说事前的数据质量，是希望能够对业务系统提要求，让业务系统进行改造，来从源头处提升整体的数据质量。

这里就涉及到【数据治理的边界】中提到的问题，在这个章节中我们提到做数据治理的第一件事情就是确定数据治理的边界，同时也给出了一个结论：在开始做数据治理时，只能做入湖后的数据治理，而后不断通过，问题驱动、场景驱动的方式进行入湖前的治理，从而实现全局的治理。

很显然，这里事前数据质量，目标是直接给业务系统提质量规范，提质量要求，进行系统调整，是不符合上面的结论的。从根本上是很难推进下去的，具体可以再回顾下【数据治理的边界】这一章。

而且，即使抛开数据治理边界这个问题。我们来说说事前数据质量的这个“事前”时间点的问题。

如果在业务系统规划初期，就有各种规矩、标准。这样每产生一个业务系统，数据就是干净的，是不是也能解决问题？针对这个问题，个人有一个观点，就是数据，或者说数据质量一定是在一个先污染，再治理的过程。

一方面，这是一个事物发展的规律。你不可能指望一个业务系统，在立项初期，就为了一个其他的目标（即数据质量的目标），一个非本业务的目标而自缚双手。即使有这样强有力的组织，我也很怀疑是否有这样强有力的执行。

另一方面是，在没有被污染的情况下，你都不知道应该治理什么，什么样的数据是质量高的。拿一个产品编号举例，有的编号9位，有的编号11位，如果只有一个系统那么9位就是正确的，就是后续不断增多的其他系统，才产生出了同一类编号位数不一致这种问题，从而需要统一编号。也没有办法说先建立的9位编码，就一定合理。

没有这种待治理的已经污染的数据，也就无所谓提高质量，进行数据治理了。（类似于上升到了“有魔，才有佛”的哲学境地了。）这一点在【维度：数据】部分“是否能够在建设系统初期就完全解决掉数据问题”这一部分也有类似的说明。

所以，针对事前数据质量，个人认为一上来推行的可行性不高，一定是有质量问题的数据进入数据中台，之后经过事中、事后数据质量，发现了问题，再通过问题驱动，才能够逐步的过渡到部分事前的数据质量。

而且，这个事前的时间点，个人也是认为是已经被污染了，然后在数据治理过程中，从入湖后的数据治理（也就是事中、事后的）数据治理，逐步的过渡到入湖前的数据治理（也就是事前）的数据治理。

（题外话：这里我们把数据集成过程中也算在数据加工的范畴内，也就是说如果是在数据集成中进行一些数据质量的规则校验，仍旧算是“事中”的过程，而不算“事前”。）

4、事中数据质量任务的成本陷阱

事中数据质量，主要是一个监控的作用，整个事中监控的过程是完全随着数据加工的整个过程的。在形象上可以想象是两条基因双螺旋，或者是两条缠在一起的蛇。

事中需要工具的支撑，在工具交互上，因为离线数据加工过程是各个加工节点形成的有向无环的DAG图，事中数据质量，就是在DAG图中，跟每一个数据加工任务节点对应，对产生新的数据的加工任务所产生的数据进行数据质量的校验。

在这个校验的过程中，就会有各种质量规则，质量规则我们后面小节会介绍。如果发现数据不符合质量规则，事中能够做的，就是发出告警和进行任务中断。当然，告警级别以及是否选择进行任务中断，也都是根据具体情况而定的。所以，可以看到事中的数据质量，其本身并不能提升数据质量，只能发现质量问题，发出告警或熔断任务。

这个数据质量的熔断能力，就是指数据质量问题达到了数据质量任务设置的阀值，整个任务流就会中断。防止不符合质量的数据继续后续的加工。

在不考虑中间表的情况下，如果按照上面的描述，就需要为每一个加工任务，对应一个（有时多个）数据质量检核任务，每当完成数据加工任务之后，就会触发一个数据质量任务，来检测，刚刚加工的表数据是否符合质量要求。

这样，每一个数据任务加工节点会对应一个甚至多个数据质量监控节点。那么整个离线任务的DAG节点数可能会翻倍，这样对应的成本也会翻倍。包括资源成本和时间成本。

资源成本

事中质量监控任务本质上就是跑了一个离线的作业，运行的时候需要使用离线资源。所以，如果给全部任务增加事中质量监控节点，那么增加出来的质量监控节点，必然需要增加相应的资源量，这就增加了资源成本，这个成本可能是翻倍的、甚至更多。
时间成本

离线任务的运行一般需要在凌晨启动，第二天上班前能够运行结束，有结果产出。如果，每个加工任务需要对应质量监控任务，整体任务运行的时间势必会拉长。原本能够按时运行完成的任务，就有可能延期，这又是一个时间成本的问题。当然，这个时间成本，有一定可能性通过增加资源转换成资源成本。

这就是说的事中数据质量的成本陷阱。当然，这是在假设，所有的表都需要进行数据质量保证的前提下，实际中也并非如此，更多的是关注关键的数据，这个在后面【数据治理的原则】中会介绍。

解决这个陷阱的思路有两个，一个是靠前，一个是灵活的增减。

靠前

就是指一方面在数据加工过程中，尽量在整个加工流的前面进行数据质量校验，如在数据集成过程中。这样能减少后面的一些工作量，另一方面，就是上一节提到了，通过事中数据质量的监控，发现问题，通过问题来反馈实现事前的数据质量。
灵活的增减

就是指虽然数据质量节点对应每一个数据加工节点，但是不能和数据加工节点有强绑定的关系。而是，当需要时，能够快速增加，当不需要时，能够灵活去掉。不影响数据加工本身的DAG流程，也就是不建立直接的上下游依赖。

对于灵活增减的设置，是否将事中数据质量校验作为数据加工开发的一部分也是具体情况具体分析了。如果作为数据加工的一部分，在进行上线发布时，就可以进行审核是否有数据质量任务，但是，增减的灵活性降低。如果不算数据加工的一部分，可以在上线后灵活增减，灵活性虽然提升了，但是是否有数据质量任务又没有办法保证了。

这里再说一句，因为事中数据质量仅仅是一个监控能力，能做的仅仅是发现问题，发出告警，或者中断任务。所以，一个好的事中数据质量处理跟进机制是很重要的。

5、事后数据质量的滞后性

完全的事后数据质量，就是说把数据加工和数据质量这两件事情分开来看。加工的时候整个加工流就单纯的进行数据加工，当所有加工流完成之后。进入数据应用阶段时，发现问题，再进行一个反馈。所以事后数据质量，又可以称为事后反馈。

这样虽然不会有事中数据质量的资源成本问题和时间成本问题。但是当发现某个表数据质量有问题的时候，那么可能上游的多个任务、多个表都是有问题的，如果需要重跑的范围就会扩大很多。

而且，已经到了数据应用阶段，不是数据中台内部的事情了。与其说是反馈，不如说是问责。所以，这种事后的数据质量，可能真的是“事后诸葛亮”了。

6、数据质量的原则

上面三小节，分别说了数据质量模块处理的时机的：事前、事中、事后。这里说一下数据质量的原则。

对于数据质量模块处理的时机，事后是效果最不好的。事前似乎是最理想的，但是也是难度最大的，能够推行的可行性极低。所以我们主要关注的重点是事中。

但是，如果按照给所有的表都进行数据质量校验，又会陷入成本陷阱，所以这里就需要提到数据质量的原则。

数据质量原则：将改进的重点集中在对组织及其客户最重要的数据上，这样做可以明确项目范围，并使其能够对业务需求产生直接的、可测量的影响。

实际中，我们并不需要对所有的表都进行数据质量校验，而是按照业务需求进行有条线的去做数据质量校验。这里的不同条线，就又会涉及到【数据架构】中提到的数据模型和数据流转关系，只有规划合理的数据模型和数据流转关系，才能理清楚一条完整清晰的条线，从而在业务对某个条线有质量要求的时候，能够明确，要在哪些模型上增加对应的质量监控任务。

7、数据质量只有进行时，没有完成时

数据质量是一个不断跟进的过程，数据每天产生，数据质量情况也是不断变动的。

而且，按照数据治理的原则，业务也可能随时对数据有新的质量要求，这里就需要进行数据质量的持续跟进。

数据质量没有完成时，只有进行时，需要对数据质量进行持续的跟进。

这个持续跟进的过程，就和政策机制有很大关系。谁来添加事中数据质量任务？出现质量问题了，通知谁，通知到什么范围？有没有评分、评比，质量分高了会怎样，质量分低了会怎样？发现质量问题，什么情况下通知数据产生方，从而推进到事前数据质量？

这些都影响数据质量的日常运转，从而影响最终的数据质量提升的因素。

8、数据质量任务的组成

说完了“事前、事中、事后”数据质量的不同，以及数据质量的原则，下面说下数据质量任务的组成，这里主要针对的就是“事中数据质量”。介绍这部分内容的文章很多，这里仅简单的介绍一下。

前面也说到，一个事中数据质量任务本质上就是一个离线任务。这个离线任务需要通过质量规则，作用在具体的表、字段上，生成一个质量任务。这个质量任务进行周期性运行，完成质量校验，通过质量校验除了发出告警，中断任务外，还需要定期生成质量报告。

这个过程也就包含了事中数据质量的几个关键：质量规则、质量任务、质量校验和质量报告。

质量规则

质量规则，有时候也被称为数据质量维度。术语“维度”可以类比于测量物理对象的维度（如长度、宽度、高度等）。数据质量维度提供了定义数据质量要求的一组词汇，通过这些维度定义可以评估初始数据质量和持续改进的成效。

因为数据质量维度这个词，个人使用的比较少，这里仍旧按照习惯，以质量规则来称呼。

质量规则的分类上有各种各样的分类，个人认为华为的分类清晰简洁一些，也和2013年，DAMAUK发布了一份白皮书，描述了数据质量的6个核心维度基本一致，这里按照这个分类介绍一下。一共有6个。

完备性。存储数据量与潜在数据量的百分比。有时也成完整性。

唯一性。在满足对象识别的基础上不应多次记录实体实例（事物）。

及时性。数据从要求的时间点起代表现实的程度。

有效性。如数据符合其定义的语法（格式、类型、范围），则数据有效。

准确性。数据正确描述所描述的“真实世界”对象或事件的程度。

一致性。比较事物多种表述与定义的差异。

这6个质量规则在作用范围上有一定的区别，有的是针对表的，有的针对字段，有的单行就可以，有的必须多行，有的是单表就可以还有的是需要跨表。详细介绍暂不进一步介绍了。
质量任务

上面介绍了各种质量规则，但如何将各种规则进行表达是在创建质量任务时的重点。质量规则有不同的表达形式，有的用SQL来表示、有个是拖拽式的界面表示，表示方式不同，本质确是一致的，那就是能够灵活的表达出来这些质量规则，从而能够量化数据的数据质量表现。

通过质量规则，就可以创建质量任务。质量任务一般针对某张表的某个字段进行检核。有的也需要其他表的某个字段作为检核依据，不同的质量规则，会有不同的逻辑。
质量校验

创建完质量任务之后，就是质量任务的运行。质量任务本质上仍旧是一个离线任务，质量校验的过程，就是质量任务运行的过程。这个离线任务也需要运行资源，也需要设置周期性，也可能会失败，也会有日志信息。
质量报告

质量任务运行之后，一般都会有一个质量报告。汇总下平台有多少表绑定了质量任务，这些质量任务的分布情况是怎么样的。质量任务的运行结果有多少符合、有多少不符合。这些都是报告里面需要体现的。

质量报告也是评估初始数据质量和持续改进的成效的一个重要依据。

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

原本上一章是【数据标准】，这里会进一步介绍数据标准和数据质量之前的关系。举些例子，因为在数据标准中有枚举字段，某个字段的数据内容是不是超过了枚举字段的范围，就可以很自然的生成一个数据质量任务。数据标准中有字段长度，数据精度，某个字段如果长度不够，精度不足，也很自然的生成一个数据质量任务进行校验。

这些数据标准的标准，都可以是很自然的转换为数据质量的规则，从而生产一个数据质量任务。

但是，因为数据标准本身，并没有想的特别清楚，那么这里也就简单写一下了，后续想清楚了数据标准的内容，明确了定位，再进一步写和数据质量的关系吧。

10、五个维度

在五个维度层面，我们主要针对事中数据质量来说的。事前数据质量，这种问题驱动的，遇到具体问题具体分析。事后数据质量，更多事后反馈，也不过多提。

组织：在组织层面，需要明确，谁来提出数据质量要求，谁来监控数据质量这件事情，进行数据质量的评比、督促。一般是领域数据BP来负责。

谁来对数据质量有问题的任务进行调整。这个一般是直接开发人员。这个还需要在内部有层级监督关系，如果不处理谁来推进。

总之，数据质量作为一个持续推进的过程，必须有一个合理的组织来保障整个推进过程。

政策：

数据质量只有进行时，没有完成时。一个合理的政策才能够保证整个推进过程的可落地。

事中的数据质量，其本身并不能提升数据质量，只能发现质量问题，发出告警和中断任务。所以一个好的接收到告警之后的处理流程就显得尤为重要了。这个收到告警之后的处理流程政策，和组织里的人相互配合，从而保证政策到人。

所以，政策，在数据质量模块，还是很重要的。
工具：

事中数据质量的整个实现过程，都需要一个数据质量模块工具来做支持。市面上开源的、云厂商的也有各种各样的产品，这块都可以进行参考。

各种数据质量规则，如何能够合理的表达出来，有时是交互式的表达，有时可以通过SQL表达。如何将质量问题量化，从而触发告警机制，都是这个工具需要考虑的问题。

还有一点，如何和数据加工流程能够更好的融合，是需要工具具体考虑的事情。
业务：

数据质量的提升是永远没有极限的，是没有100%完成时，只要能够满足具体场景下，具体业务的数据质量需求，那么就是一个好的数据。

所以，具体的业务了解，也是数据质量需要了解的，而且事中数据质量的成本这么高。只有了解了业务，知道哪些业务重要，才能更好的针对重点业务，进行针对性的重点监控。这个也是上面【数据质量的原则】中提到的。
数据：

数据质量就是对数据的了解。只有了解了数据，才知道制定出具体的规则，从而按照规则进行数据质量校验。