"导读目前互联网行业已经进入成熟的大数据应用时代，数据'用起来'的问题已基本得到解决，随之而来的就是数据治理的问题，尤其是其中的数据质量问题。数据质量，是指在业务环境下，数据符合数据消费者的使用目的，能满足业务场景具体需求的程度。这次分享主要聚焦在数据质量智能化和自动化方面的思考和实践。从应用场景视 ...."

Fork me on GitHub

AIPreacher
AI发布小助手
 大数据 • 0 回帖 • 132 浏览 • 9 个月前

智能化、自动化，揭秘抖音集团数据质量前沿探索

以下文章来源于 https://zhuanlan.zhihu.com/p/644140720

导读目前互联网行业已经进入成熟的大数据应用时代，数据"用起来"的问题已基本得到解决，随之而来的就是数据治理的问题，尤其是其中的数据质量问题。数据质量，是指在业务环境下，数据符合数据消费者的使用目的，能满足业务场景具体需求的程度。这次分享主要聚焦在数据质量智能化和自动化方面的思考和实践。从应用场景视角来看待数据质量问题，通过自动化、智能化技术让数据质量可以被"观测"，把数据质量融入到研发、协作的流程中。

今天的介绍会围绕下面几点展开：

全文目录：

行业动向
数据质量基础概念及检测方法
智能数据质量

分享嘉宾｜周方圆火山引擎 DataLeap资深研发工程师

编辑整理｜天天 golden tech

内容校对｜李瑶

出品社区｜DataFun

01/行业动向

近年来，随着大数据技术的不断发展，云上大数据体系的不断成熟和稳定，使得大数据技术更加易用、低门槛，国内互联网行业更彻底地进入了大数据的应用时代。在数据"用起来"的问题基本已得到解决之后，随之而来的是数据治理的问题。

"现代"大数据系统中的数据质量问题

当前，大数据基础架构日臻完善，以字节的火山引擎大数据产品为例，其核心就是一套云上的大数据体系，包括数据收集、存储、加工、处理，数据应用及可视化等一系列的技术栈。

随着大数据应用的发展，大数据技术栈也越来越成熟，与前些年大数据技术相比，一个很明显的特征就是更加易用，使用门槛大大降低，大部分的数据开发任务都可以通过模版化编程或者编写SQL来完成。同时，数据应用工具也更加成熟，包括数据可视化，自动决策，机器学习等，通过拖拽、点击等操作就可以完成看板搭建、决策分析甚至机器学习模型的部署和使用。

总之，随着大数据技术的发展，可以简单、方便地使用一些工具去解决数据使用的问题，当处理的数据越来越多，数据处理任务也逐步增多的时候，随之而来的就是数据治理问题，数据质量属于数据治理中非常经典的一个领域，但最近一段时间，数据质量在行业内部又引起了广泛关注。

下图右边部分是Gartner 2022数据管理成熟度曲线图，用红框标出的部分，是三个最近受到关注的应用点，其中一个是Augmented Data Quality，即增强数据质量，就是对数据质量的整个流程进行自动化，其核心概念是自动化以及数据语义级别的质量问题。另外一个是DataOps，具体是指把数据开发的整个流程，包括数据建模、数据开发、数据测试、上线监控等环节打造成一整套流水线。

在这个过程中，会关注两方面的内容，一个是研发效率，另外一个就是数据质量问题，因为数据质量是研发效率中非常重要的环节。第三个关注点是Data Observability，即数据可观测性，这是目前行业内最新的一个理念，它的核心在于把数据链条中各种关键的指标及环节以更直观的方式，例如可视化、关键特征提取、关键信息提取总结的方式，在数据开发的各个环节中展现出来，从而可以更有效地去操纵一个庞大的数据流水线。

总之，需要重视数据质量，因为当数据规模较小的时候，需求响应越快，开发速度越快，效率就越高。但是当数据规模日益增长，规模大到一定程度的时候，例如像字节这样的公司，表的数量已经达到了百万级别，此时在协作和数据质量上的问题就会越来越多，所花费的时间也会越来越长，在这种情况下，数据质量越高，效率就越高，如果还是一味追求速度，反而会降低效率，带来无尽的麻烦。

接下来，回顾一下数据质量的基础概念。

02/数据质量基础概念及检测方法

经典的数据质量保障方法即配置质量检查规则，这个质量检查规则称为：Assertions，相当于编程中的断言，下面列举出了一些比较典型的Assertions，如下图所示：

1.数据新鲜度

数据新鲜度是最基础的，也是备受关注的一个指标，尤其是在数据源不稳定的情况下，例如有些数据是人工录入，需要复杂的手工处理流程，或者源系统自身的一些问题，都会导致数据不能及时产出等情况。

2.数据量

数据量反映的是一些隐藏的问题，一般是由于数据链路中的变动、故障或者上下游的错误操作，导致数据变多或者变少，其影响面是比较大的。

3.数据正确性

数据正确性主要是指数值数据的分布是否正常，字符串类型的数据的模式是否满足要求等。

4.数据完整性

数据完整性主要是指一些数据字段的空值率是否在一个比较稳定的水平，一般而言大部分字段有一些空值是很正常的，但是有时也会产生一些异常的波动。

5.数据唯一性

数据唯一性对数据建模会造成比较大的影响，如果某些逻辑主键或者逻辑唯一键发生重复，会造成后续加工中的数据冗余等问题。

6.数据完整性(integrity)

数据完整性比较典型的例子是检查关键字段是否包含在另外一个表中（主外键关系）。

上述这些都是经典的数据保障方法，这些内容在字节都有成熟的应用体系，会有一整套系统来支持。

整体回顾Assertions的流程，这个流程相当于是软件开发中单元测试和持续监控的结合体。但不同于软件开发，数据开发中数据是一直是在变化的，数据开发只能控制形式化的组装代码逻辑，所以除了在上线时进行测试以外，也需要进行持续的例行监控。

一般来说Assertions设置的经典步骤如下：

（1）数据探查

数据探查（Profiling）是针对数据分布、缺失率、数据分位值、枚举值等一系列指标进行完整的探查，并通过可视化的方式展现。通过数据探查可以快速了解数据整体的情况，对后续配置数据规则以及数据单元测试提供支持。

（2）设置规则

基于数据探查的结果，可以进行规则的配置，一般会通过规则配置界面进行，其后台是通过类似DSL(Domain Specific Language)的一套规则去进行配置。

（3）例行监控

规则配置完成后，就会进行一次性的监控或者例行监控。其中一次性监控主要用于数据开发阶段，当每次开发完成后，进行单元测试，观察发生的情况，而例行监控主要是针对可能有安全隐患，影响整体数据质量的情况，进行日常周期性的监控。

对于成熟的数据质量，就像上图右半部分所示，Assertions是Data Quality一个非常重要的支柱，但是在实际践行这套规则的时候，还是会遇到下图所述的一些问题。

虽然数据质量相关的系统已经非常成熟，相关方法论数据开发也非常熟悉，但是经过数据分析发现，在实际的规则配置中，有两个规则占到了规则总数的80%以上：一个是表行数，另一个就是主键重复。

表行数规则

表行数规则配置主要是用于监控表记录行数过少的情况，例如表记录行数为0，这是个很严重的数据质量问题，会导致整个数据链路的任务空跑，这个规则几乎都会配置。

主键重复规则

如果发生主键重复问题，在做数仓开发的时候，例如通过主键做join操作，会对数据量以及后续的整个链路逻辑造成非常大的影响。

以上两个规则是配置最多的，但这也只是表象，更主要的原因是由于这两个规则是最容易配置的，另外还有一些其他原因，例如对健康分有要求，或者是有些团队会有一些规范性的要求，一定要配置质量检查等，所以这两个规则就会被配置，剩余的一些质量规则数量只占不到15%的比例。

从平台角度来看，质量规则的配置渗透率不及预期。通过调研分析这种情况产生的原因：首先，对字段级甚至是语义及配置质量规则，需要具体去理解其中的内容和含义，通常情况下表字段的数量非常多，基本都是几十甚至上百个字段，配置过程非常繁琐，配置成本很高。其次，细致的质量规则配置依赖数据开发的经验，需要具备很好的数据质量意识、能够预计可能发生质量问题的问题点的开发人员才可能配置完善的质量规则。最后，其实很多质量规则是事后进行补充的，例如发生事故后，进行复盘的时候，发现某些表很重要，也比较容易出问题，才把相关质量规则补充配置，并增加相应的监控和告警。

上述三个方面是即数据质量规则检查真实渗透率较低的主要原因，下面会阐述相关的解决方案。

03 /智能数据质量

在实际工作中，我们采取了如下图所示的四种方法来提高质量规则的真实渗透率，分别是推荐规则、自动检测、链路检查和协作机制，本质上还是要提升数据质量。

1.自动检测

自动检测主要针对非常明确的一些规则检查，不需要人工配置规则，完全依靠自动化检测的方式。自动检测其实是一个非常直观的想法，例如前文提到的表行数和主键重复规则的配置率是非常高的，针对这样的配置规则，可以实现自动检测，从而不需要进行人工配置。下图中展示了一些自动检测的案例：

首先是表行数规则，如果人工配置表行数规则的话，配置的规则往往是表行数为0，即整张表没有数据这种情况，如果使用了自动检测相关算法之后，不仅可以对表行数为0的情况进行判断，还可以对时序波动做出判断。例如上图中关于Volume时序波动的图表所示，可以针对数据量上下界进行有效的判断。右下方的图表中展示了实际的数据波动情况，根据图示可以发现数据量具有明显的周期性波动特点，橙色线是实际的数据波动线，可以发现其中一天的数据量有暴涨的情况，其实是由一些脏数据造成的，蓝色线是利用时序检测的方法做出的上下界，这样就可以自动去检查出这种异常。当然数据暴涨有时不一定是事故，但是往往需要提前去关注，因为有可能会造成数据下游或者数据产出延迟甚至任务失败。

另一个例子，左上方的图中展现了一个空值率的指标，从图中可以看出这是一个小时级的表，每天在零点的时候，其中一个字段就会变为0，产生这种情况的原因是由于依赖配置的原因，因为小时级的表依赖了天级的表，当天级的表还没有数据产出时，小时级的表就已经开始运行任务，这种情况下去join相关字段的时候，就会产生空值。这个问题隐藏的比较深，因为在数据开发的时候，或者白天数据高峰的时候，这个问题是不存在的，只有到了凌晨才可能出现，所以在数据开发时很难发现这个问题。

以上就是自动异常检测的一些应用，这个自动的异常检测或者说叫无规则，它的好处是自动化，不需要配置规则，更加全面和便捷。但是也会存在一些问题，例如复杂指标，因为每种指标的收集成本是不一样的，有很多指标尤其是复杂指标，像高基数的数据维度，字符串模式匹配，数据分布中分位点探查等收集成本还是比较高的，尤其是数据量很大的情况下。

2.推荐规则

规则推荐是针对某些规则进行比较智能化的推荐，包括基于阈值、字段、表等方面去做规则推荐，这样可以大幅减少配置规则的成本。

上文讲述的自动检测受限于收集成本，为了降低复杂指标的收集成本，需要基于场景做推荐。从数据来源到数据应用整个流转过程中，主要有五种类型的数据场景，如下图所示：

首先是外部数据入口，即ODS表、DIM表以及一些埋点的数据。其次是数据链路开发，是数仓内部的一些表，因为数仓内部的表是数据开发自行设计和开发的，所以相对比较了解。另外是数据应用，也就是从数仓出来的数据要进入各类线上应用系统，例如各类OLAP，Data Cache/Index等，这就是所谓的高价值数据质量的场景。再次就是模型特征，模型特征在不同的公司会有不同的架构，但是模型特征检查的核心逻辑跟数据质量其实是一致的或者高度相似的。最后就是关于业务应用,也就是数据使用者通过BI或者线上系统的时候，可能会再做一次数据质量异常的检测。

针对以上五个场景会针对性地做一些规则推荐，下图中简单概括了其中的一些核心问题：

对于外部数据入口，核心问题是稳定性，例如数据新鲜度、数据量是否正常，当然其中也会有脏数据问题，但是对于脏数据，在初步数据清洗的时候也还会做一层清洗，另外数据入口表的数据量是非常巨大的，很难对它做非常细致的检查。当然如果对于数据量较小的维表，或者是来自于类似MySQL这样的数据源，也是需要对其内容进行质量检查的。

对于数据开发链路，核心关注点就是数据模型是否符合预期，比如主键重复问题，约定的唯一性字段不可以重复，否则会造成SQL逻辑错误。

对于数据应用，核心问题是语义级的数据质量，具体会涉及到数值真实类型的判断，数值范围、字符串模式，时序范围的预估。其中时序范围是指一些指标是具有连续性的特点，例如空值率。除此之外还有完整性检查，针对数据应用会根据应用场景有很多的不同的内容检查。

对于模型特征，核心问题主要是数据分布漂移，其中一个核心指标是数据分布距离，总体来说模型最关心的场景就是模型训练时数据的分布跟线上保持一致，例如模型训练时某个特征是缺失的，线上也要保持该特征的缺失。当然如果模型长期不更新，但是线上数据发生变化，对模型也会造成一些影响。

对业务应用，可以把它看成是质量的一种特殊情况。当然其实业务应用还有一套专门的指标监控体系，比如波动率异常，或者是一些突升突降的行为等。

做完规则推荐之后，回顾一下上文提到的数据质量配置的流程，第一步就是做场景感知，着重分析表、数据的用途，识别其上下游。紧接着会做适应性数据探查，所谓的适应性数据探查其实跟数据探查区别不大，但是更有针对性，比如上文提到的应用数据，对其探查会比其他数据更详细，步骤更多一些。数据探查之后，会做自动检测与规则推荐和配置，最后进入例行监控环节，如下图所示：

虽然整个数据质量规则配置环节看上去会变多一些，但是需要人工操作的核心环节其实变少了。

3.链路检查

链路检查是依据表、字段之间的血缘关系、生产关系，自动对整个数据链路上下游的规则指标进行诊断，帮助查找分析数据质量问题的根因。数据链路通常来说是一个整体，大家比较关心的应用层数据质量问题，往往需要在上游各种表中去追查，比较常见的一种情况是维表发生变化。在实际追查中，借助了DataLeap 的全链路血缘功能，通过任务表之间字段级的血缘关系，再去结合链路的指标收集，尤其是自动收集的指标，可以去实现自动的链路根因诊断。

根因诊断的规则还在不断完善中，但是总体而言已经可以提供一些比较有用的诊断信息，比如下游数据发生了缺失，比较典型的情况就是缺失率整体上升，此时根据血缘可以查询上游相关指标是否也在上升，这样就可以快速定位到具体原因。

4.协作机制

虽然通过自动化、智能化的方式可以解决很多数据质量问题，但是有些数据质量问题往往是一个协作问题，不能够完全依靠工具解决，很多时候需要协作机制以及信息沟通。

通过协作来解决工具不能够完全解决的问题，在这里提出一个叫做数据开发者和数据应用者的质量预期鸿沟的问题，简单来说就是数据应用者认为数仓的质量有问题，例如数据应用者发现数仓中有金额为-1的数值，这个数据是不合理的，但是从数仓开发的角度看，根据业务建模，线上数据就是-1，这个数据是合理的，是一个特殊值。

另外，如果发现新增了枚举值，数据应用者会认为数据有问题，但是从数据开发的角度来看，枚举值增加是由于业务的逻辑变更引起的，跟数仓开发可能没有太大的关系，由此产生的问题不是数据质量问题。还有数据格式无效，某字段缺失率升高，或者由于节假日或者一些事件导致数据分布发生变化等问题都是比较典型的问题。这些由于业务不可控的原因或者事件驱动的原因导致的问题，数据应用者会认为是数据质量问题，最后的结论通常就是发生数据故障后，数据开发者根据数据应用者提出的需求，进行数据质量配置，运动式的配置一批监控，而且数据应用者会把能想到的所有问题全部列出，导致数据质量监控需求过量。

上述这些问题其实都是协作上的问题，可以通过分级质量协议的功能来解决。其核心逻辑在于数据开发者提供的通用质量协议，即数仓开发认为的建模正确，符合预期的数据质量保障。下游的数据应用者可以知晓该协议提供的质量保障的内容。另外数据应用者也会提供预期的质量指标。简单来说就是数据应用者建立一些额外的有针对性的规则，单独进行监控。

最终会形成一个整体的质量保障体系，相当于一个协议平台，数据开发者和数据应用者可以知晓他们签署的协议及其保障的功能，使得数据应用者主动参与到数据质量的工作中，同时也可以使数据开发者更好地去了解下游对数据质量的预期。经过一段时期，如果发现某些规则很重要，就可能将其升级为基础数据质量保障。整体而言需要通过协作的方式来解决上述这些问题。