1.前言

数据质量是悬在每个数据同学头顶的达摩克里斯之剑。一旦我们对其缺少敬畏，或是我们的“武器”不够丰富，缺乏有效的质量保障措施；这把剑就会无情落下。数据质量保障符合蝴蝶效应，只要数据链路上任何一个小的细节点出现问题，则实时数据的质量会大幅度下降，因此需要构建数据质量的全链路监控，从数据研发到数据消费都需要重点监控，并通过一定的流程机制保障数据参与方的规范性，以此来保障数据全生命周期的质量健康度。本文会结合离线和实时数据建设场景谈谈对数据质量全链路建设认知。

2.数据质量类别

无论是离线和实时数据建设，对于数据质量的要求是一致的，都是追求数据的完整性，规范性，一致性，准确性，关联性。

1.完整性（ Completeness）：完整性用于度量哪些数据丢失了或者哪些数据不可用。

2.规范性 （Conformity）：规范性用于度量哪些数据未按统一格式存储。

3.一致性 （Consistency）：一致性用于度量哪些数据的值在信息含义上是冲突的。

4.准确性 （Accuracy）：准确性用于度量哪些数据和信息是不正确的，或者数据是超期的。

5.唯一性 （Uniqueness）：唯一性用于度量哪些数据是重复数据或者数据的哪些属性是重复的。

6.关联性 （Integration）：关联性用于度量哪些关联的数据缺失或者未建立索引。

3.离线数据质量建设

离线数据建设是围绕数据采集，数据建模，数据应用进行的，整个数据链路彼此之前存在着相互依赖，因此这个链路上的任何一个环节出了数据问题，都会波及到下游依赖和应用。因此离线数据质量建设也是围绕着整个批任务数据链路展开；

3.1 基本概念

数据资产质量：是指数仓数据资产表的质量，包含表的设计质量、开发质量、产出质量；

1.设计质量：指资产表在业务数据链路中的定位是否合理，信息覆盖与整合是否达到要求；

2.开发质量：指资产表在数据开发编码过程中，是否遵循约定的开发规范，数据加工逻辑是否正确；

3.产出质量：指资产表对应任务的产出时间是否符合预期，产出结果数据是否达到要求；

3.2 影响因素

1.信息因素：开发人员是否了解资产表的具体需求目标，是否了解具体的业务数据链路和信息分布；

2.工具因素：平台工具是否稳定，是否有DQC能力，是否有优先级控制能力 ；  

3.流程因素：研发流程是否合理，是否有代码质量卡点，是否有数据质量卡点，是否有SLA执行保障机制 ;

4.人为因素：人员编码水平是否打标，流程执行是否到位，需求理解是否到位。

3.3 流程设计

3.4 流程管理

需求文档落地

数据类需求文档是数据开发前的资料收集与整理的重要产出，基于文档和业务方对齐具体数据需求，包括各种数据来源信息、加工逻辑信息、结果数据格式等等；

需求迭代记录

项目类数据需求往往因进度问题，需求调整较多，为保证信息对齐，建议使用迭代开发，使用需求管理系统或在线笔记记录迭代需求；

非项目类需求迭代，必须提需求系统单排期处理；

资产设计

中间层资产按照中间层建设设计要求，需要在资产关联大图上标明，并给出明确的实体&单据定义，防止重复建设；

项目类应用层资产按需求逻辑，明确数据资产间的流转依赖关系，给出明确的数据维度&粒度定义，保证资产关系清晰；

非项目应用层资产按需求文档，给出明确的数据 维度&粒度 定义，保证资产关系清晰；

数据自测

所有数据表交付验收前，必须进行自测，保证数据表数据量符合预期，保证数据粒度符合预期，保证指标字段取值符合预期；

QA验收

涉及业务回流的资产表，由业务QA同学负责验证数据质量；因数仓不存在测试环境，所以，可与QA同学沟通，采用uat、预发环境验证；

部分特殊情况下，可在数仓dev环境 人工写入数据进行逻辑验证；

业务验收

非业务回流类资产表，如报表等，由业务同学自行验收，部分高保障报表（如管理决策层看板）可由业务同学评估 引入数据质量管理团队相关同学帮助验收，业务同学作为验收最终责任人；

因统计指标等数据逻辑加工复杂，业务同学发现问题周期较长，可与业务同学约定部分验证case，通过后可先上线，再迭代；

任务发布

所有回流类任务发布，必须按要求注册业务风险场景( 无系统支持时可采用文档记录)，按业务产出要求配置任务优先级(如基线控制)；

对于高风险场景任务，要求进行代码review ，保证代码质量；

DQC配置

按需进行数据质量监控规则配置，要求中间表必须配置空表检测、重复值检测；高风险应用表必须配置空表检测、重复值检测、业务逻辑检测等；

全部采用强规则控制，检测异常时中断任务并告警，防止影响下游任务；

资产文档更新

中间层数据资产表上线后需要更新中间层资产文档，方便进行中间层数据资产管理；

项目类应用层数据资产表上线后，可在各自项目文档库维护，方便需求方查看项目产出数据资产情况；

非项目应用层数据资产表可不做要求，按需求交付即可;

4.实时数据质量建设

相较于周期性跑批离线任务，虽然实时任务的计算维度不会像离线那么复杂，但是因为数据源大多来自消息中间件，加上流数据自身的特点，无边界，乱序性，很难对实时数据进行数据质量保障，而且实时任务上线后会一直运行，对于实时数据保障可以说是24小时制的。所以该如何构建全链路的实时数据质量保障体系，相较于离线数据质量建设是有很大挑战的。

4.1 实时数据质量是什么

实时数据质量是实时研发过程中重要但最容易被忽视的问题，一方面是因为大家花了很大的力气才搞定一个实时数据需求，相较于实时研发和上线过程的惊心动魄相比，实时数据质量的保障来的有点儿风平浪静；另一方面，实时数据质量的保障工作，在大家观念里更多是通过数据质量工具来完成的，这些工具又都是在研发上线的后链路中，会因为忽视或观念不足导致监控覆盖不全。因此实时数据质量在整个实时研发过程中关注度是不够的，但出现一次实时数据质量问题后，质量保障问题会被重点拿上台面，从机制到工具都会着重讨论，这就是实时数据质量螺旋式发展的过程。

当前的现状可能由观念、机制、工具等外部问题导致，抛开这些，我们试图从实时数据质量内部去解剖他最核心的要点，并依此指导其自身发展，最终服务于实时数据体系的发展。不管我们设计多复杂的链路，使用多厉害的计算方案，最终是要交付符合要求的数据，实时数据质量也是为了这个目的而存在，那么是否可以说，实时数据质量最核心解决的问题是：让实时数据符合预期。

怎么来看实时数据是符合预期的呢？我们从三个角度来分析：

【基础】有无明显异常

实时任务是否延迟、Failover？checkpoint是否失败，上游数据流是否无输入，下游数据是否无输出，交互的组件是否运行正常？数据查询引擎是否报错，这些都是对实时数据的基础监控。只要任何一个基础监控进行报警，都有可能导致实时数据的异常；但如果基础监控都没有报警，是否代码实时数据肯定无异常，答案是否定的。因为这些基础监控，只是实时监控中露头的冰山一角，下面还有更加庞大的隐藏问题点。

【对照】同参照物对账

这里的参照物很多，如离线数据、主备数据、在线库数据，在数据测试和上线后，进行不同数据源的数据对比，能有效的发现当前链路的数据问题，也是实时数据监控中的重要手段。

【高阶】符合数据逻辑

如果上述两种情况都没有问题，首先能保证实时数据和他相关的场景具有一致性，那么就需要从业务数据特性的角度进行监控。

举个例子：有个项目是是实时省钱账单项目，D11 期间，有业务反馈某个用户核销金额比领取金额大，最后查看具体case，发现某个用户在D9期间领取的券，在D11期间核销，最后导致计算的核销金额比领取金额大。出现这种问题主要是是业务数据特性导致。

解决此类问题的方法，一方面是接入实时流的时候需要深入调研数据源的生成逻辑和业务含义，另一方面则是构建分小时和分天数据的对账链路，及时发现差异，快速定位问题。

4.2 实时数据质量保障

数据开发主要面向的是实时任务的构建，从数据需求对接到数据系分再到数据测试，都应该考虑到数据质量问题，综合实时数据特点和消费方式，这三个大的节点的质量保障点包括：

如上图所示，本着特殊问题特殊分析的思路，不同的场景和需求会有不同的保障措施，但无外乎需要cover以上的思考点。

数据需求确认

数据需求确认，除了对焦交付的数据和口径之外，还需要确认好数据使用的场景，以及数据的风险等级(如流量调控类，资金类)，并最终规划相对应的数据保障方案。此环节作为我们后续数据研发和测试系分的基础，例如标签场景，除了基础的人群命中测试以外，是否对C端的页面链路、数据更新的时效性进行了解。

数据研发系分

数据研发系分重点抽象了四个点

1.运维方便：任务启动停止、代码升级是否简便，是否可以抽象一些逻辑在维表中；

2.排查方便：可输出一份数据到离线或其它存储介质中，方便查询；亦或在保证查询性能的情况下，分析类场景可以使用明细数据进行构建；

3.修复快速：在出现线上问题时，按照规划多长时间可完成修复，甚至对于重点的场景（比如双十一、五福），还需要设计作战手册，避免问题修复中出现二次的操作失误；

4.兜底全面：兜底的设计首先需要考虑到全链路中的风险项，并对各节点可能发生的问题进行梳理和兜底。兜底方案的设计可以站在消费方的角度，当数据不符合预期后需要进行数据的兜底处理(比如用离线小时数据来修复)，针对不同情况设计兜底方案，并且和业务确认方案。

数据测试系分

数据测试系分，则可以围绕着实时数据符合预期的三大监控点进行针对性的测试。

1.任务运行状态：基础的任务运行状态，是否发生Failover，压测QPS是否达标，是否有任务反压和CP失败等情况，这些状态在任务上线后可通过任务基础监控cover风险项。

2.数据质量校验：一般是和对照物进行对比，比如和离线数据、业务库数据进行对比。实时数据相较于离线数据，需要重点关注任务运行多天后的数据情况。

3.业务逻辑模拟：除了需求方、BI同学等提供的数据逻辑，比如A应该大于B、A等于C的总和以外，可从统计周期、维度、指标这三方面的关联关系和业务逻辑入手，去校验数据是否符合业务逻辑。

4.3 实时任务发布质量保证

数据上线，包括从数据产出到数据消费的全链路节点的上线过程。在对接不同的需求时，因为每个人的经验不同，大家每次上线的东西不一定都是标准的，解决标准化上线的方式则是流程化和透明化，流程化和标准化落地的方式是电子化。

拿高保障任务实时大促看板举例，需要涉及到业务PD，数据研发，后端开发，前端开发，QA，我们需要搭建实时数据研发的标准SOP，其中涉及到上线阶段的，则将所有的确认点在流程中体现，并逐个确认，各参与方明确各职责，完成流程的推进。

4.4 实时数据质量工具建设

研发链路

综合以上实时研发和上线流程，从单任务延迟监控到全链路延迟监控，从任务粒度监控到数据质量监控，从上线前的质量保障到线上运维的质量巡检，抽象出事前到事中两大阶段来构建研发链路的质量工具能力建设。

事前保障

事前保障侧重在研发态中提供质量测试原子能力，除了基本的任务调试和代码诊断以外，我们还希望通过压测和限流防降的能力，对实时任务的稳定性进行保障。

【基础】压测能力：压测在实时研发中是一个核心的数据稳定性保障工具，其它的工具更多的是在事中对数据问题进行发现，而压测则可以事前将一些问题暴露。压测有多种方案，可以是单任务的，也可以是全链路的，都是为保障日常流量高峰和大促活动场景极端情况下的任务稳定性。

【基础】限流：限流功能主要用来保障各实时组件水位在正常的范围内，当前实时研发组件中，很多还没有做到表粒度的资源隔离，单任务的高TPS，会导致部分机器及整个集群的压力，最终产生生产故障。

【基础】防降：防降功能用来应对线上数据异常及回刷过程中，结果数据下降的问题。防降的方案有很多种，可以通过开发防降任务兜底数据下降的情况，但此种方案对于数据真的错误需要回刷的场景，操作相对麻烦；另外可使用下游存储引擎的版本特性(Hbase、Lindorm.)，通过版本号对数据（读取最新时间的数据）进行防降处理。

下图是其中大屏中sink到 Redis防掉0方案，在服务端读取数据时的处理逻辑。

事中监控

事中监控围绕任务稳定性和数据质量进行监控，其中任务异常监控又分为单任务粒度和全链路基线监控（有无明显异常），数据异常监控分为有参照物的主备/异源核对（同参照物对比）和面向中间流/结果表的DQC监控（符合数据业务逻辑）。

【基础】单任务异常监控：单任务监控依赖于Flink的metric采集，对Failover、延迟、CP等重点指标进行定义和监控，超过指定阈值则进行报警，是实时监控中最基础但也是最重要的监控能力；

【基础】全链路基线监控：实时全链路基线监控能力，和离线基线监控类似，通过实时数据血缘，从上挂的节点往上追溯，监控全链路中任务的延迟情况。对于下游引用他人的实时资产情况，监控上游任务的运行状态有很大的帮助；

【对照】主备核对：部分的重点场景采用主备双链路的方式保障数据正确性，当因为不确定因素导致某一条链路上的数据发生异常时，下游消费方可以快速进行主备切换。那就有一个前提，怎么保障，我两条链路的数据是一致的呢，此时则需要主备核对的能力，对主备链路上的数据进行对比巡检；

【对照】异源核对：异源核对是另外一种参照物对比方式，Lambda架构会通过实时离线两条计算链路产出数据，则可对这两条链路产出的数据进行对比，保障每天离线回刷前数据的一致性。后续流批一体场景则使用Kappa架构进行数据的生产，对于Kappa架构中，实时离线数据的一致性问题需要思考；

【高阶】DQC监控：DQC巡检能力，可以分为两阶段来看，一部分是实时数仓中间层，主要采用流数据进行存储，对于流数据进行巡检则需要对明细数据进行Metric指标的采集，此处可以采用嵌入UDF的方式进行采集。而基于结果的DQC，则和离线DQC类似，对结果数据进行巡检以保障数据的符合业务逻辑。

消费链路

消费链路的数据监控，主要监控两个问题：1.写入到存储引擎的数据是否正确，2.存储引擎的数据是否和查询出的结果数据一致。

【高阶】写入数据是否正常：可以通过结果DQC进行监控，同时不同的消费场景，会有不同的监控手段，比如报表场景可以配置报表查询结果的DQC，在报表层进行数据逻辑的监控；在标签场景，则有标签枚举值分布监控。

【高阶】存储数据和展示数据是否一致：不管是报表看板还是标签服务，查询和消费链路中后端可能有很多黑盒的处理逻辑，对于这些黑盒逻辑，当前只有通过查询出的结果值和表中的数字进行对比，保障消费链路的数据一致性。

5.数据质量建设总结

不管是定义的研发上线流程规范，还是提供的数据质量保障能力，均会出现覆盖度不够的问题，除了工具能力的特性导致部分场景不适用以外，还需要重点思考怎么能将合适的能力应用在对应的场景中。构建如上的研发标准SOP是一个方案，其次，从产品设计角度，可以将基础的监控能力直接兜底而无需用户单独配置，把更高阶的工具能力嵌入到用户的研发和运维流程中，以此来保障质量工具的任务覆盖度，并最终实现流程机制+工具保障离线和实时链路的数据质量。