读数据自助服务实践指南：数据开放与洞察提效19质量可观测性服务

1. 质量可观测性服务

1.1. 数据用户需要确保峰值实际上反映了真实情况，而不是有数据质量问题的结果
1.2. 导致质量问题的情况

• 1.2.1. 不正确的源模式更改
  
• 1.2.2. 数据元素属性的更改
  
• 1.2.3. 接入问题
  
• 1.2.4. 源系统和目标系统的数据不同步
  
• 1.2.5. 处理失败
  
• 1.2.6. 生成指标的业务定义不正确
  

1.3. 生产管道的质量跟踪是一个复杂的问题

• 1.3.1. 在数据管道中没有E2E统一的、标准化的多源数据质量跟踪
  
  
  
  • 1.3.1.1. 这就导致发现和修复数据质量问题会有很长的延迟
    
  • 1.3.1.2. 需要团队应用和管理自己的软硬件基础设施来解决问题
    
  
  
• 1.3.2. 定义并大规模运行质量检查需要大量的工程工作
  
  
  
  • 1.3.2.1. 数据用户依赖一次性检查，在大量数据流经多个系统的情况下，这种检查是不可扩展的
    
  
  

1.4. 不仅要检测数据质量问题，而且要避免将低质量的数据记录与其他数据集分区混合

• 1.4.1. 质量检查应该能够在增量数据集上运行，而不是在整个PB级数据集上运行
  
• 1.4.2. 洞察质量耗时包括分析异常的数据属性、调试质量问题的根本原因以及主动防止低质量数据影响仪表盘和模型的洞察等花费的时间
  

1.5. 理想情况下，一个自助质量可观测性服务应该允许注册数据资产、定义数据集的质量模型，并在检测到问题或异常时进行监控和告警

• 1.5.1. 数据特征异常是质量问题的潜在信号
  
• 1.5.2. 该服务收集足够的详细分析信息和配置更改历史，以帮助找到根本原因并进行调试
  
• 1.5.3. 在将低质量的数据记录添加到数据集之前，该服务应该能够通过模式约束（schema enforcement）和隔离等方式主动预防质量问题
  

1.6. 确保洞察的质量是实施阶段最具挑战性和最关键的方面之一
1.7. 质量可观测性服务的关键成功标准是分析大量的可用信号，以主动检测质量问题，而不是用假阳性告警让数据用户应接不暇
2. 路线图

2.1. 监控洞察质量是一项持续的活动

• 2.1.1. 影响洞察质量的关键因素是基础数据的质量，而基础数据是不断演进的
  
• 2.1.2. 质量可观测性是一项必须具备的服务，尤其是在使用对数据噪声敏感的机器学习算法时
  

2.2. 每日数据质量监控报告

• 2.2.1. 数据用户需要确保生成的洞察对消费是有效的
  
• 2.2.2. 该过程涉及验证从源到消费时的数据正确性
  
• 2.2.3. 需要对生产中部署的数据集进行连续跟踪，以确保每日接入数据的质量
  
• 2.2.4. 数据不完整、数据解释不明确、数据重复和元数据目录过时等数据质量问题会影响生成的机器学习模型、仪表盘和其他生成的洞察的质量
  
• 2.2.5. 目标是防止低质量的数据影响生成的洞察
  
• 2.2.6. 验证数据类型匹配、源-目标基数和值分布，以及根据历史趋势分析统计数据以检测异常和潜在的质量问题
  
• 2.2.7. 当大量数据跨多个平台流动时，验证数据质量既困难又昂贵
  
• 2.2.8. 数据用户通常会重新发明轮子来实现不同数据集的质量检查
  

2.3. 调试质量问题

• 2.3.1. 在解释洞察的背景下，数据用户花费大量时间来确定它是指示数据问题还是反映实际情况
  
• 2.3.2. 做出这个决定需要对管道沿袭以及与管道中不同系统相关联的监控统计信息和事件日志进行深入分析
  
• 2.3.3. 需要花费大量时间来检测和分析每个变化
  

2.4. 处理低质量数据记录

• 2.4.1. 没有明确的策略来隔离、清理和回填具有低质量数据的分区
  
• 2.4.2. 质量的定义可以扩展到其他属性，即检测数据中的偏差
  
• 2.4.3. 对于数据集不是正态分布的机器学习模型，偏差是一个越来越重要的问题
  

3. 最小化洞察质量耗时

3.1. 包括验证数据准确性的时间、剖析异常数据属性的时间以及主动防止低质量数据记录污染数据湖的时间
3.2. 验证数据的准确性

• 3.2.1. 数据质量模型定义了数据、元数据、监控统计、日志消息等质量规则，涵盖了不同的数据质量维度，如准确性、数据剖析、异常检测、有效性和及时性
  
• 3.2.2. 验证过程包括创建数据质量模型，以分析E2E管道中的单个数据样本
  
• 3.2.3. 阶段
  
  
  
  • 3.2.3.1. 源头阶段
    

    3.2.3.1.1. 应用层内的数据创建（事务数据库、点击流、日志、物联网传感器等）
    

    
    
  • 3.2.3.2. 接入阶段
    

    3.2.3.2.1. 从源头批量或实时采集数据，并存储在数据湖中
    

    
    
  • 3.2.3.3. 准备阶段
    

    3.2.3.3.1. 目录中可用的数据，记录了数据的属性以及元数据属性，如值分布、枚举等
    

    
    
  • 3.2.3.4. 指标逻辑阶段
    

    3.2.3.4.1. 将数据转换为派生的属性或聚合，作为指标或特征提供
    

    
    
  
  
• 3.2.4. 创建数据质量模型是即席的，在不同的数据集之间不能通用
  
• 3.2.5. 可以使用SQL连接以及一次性脚本实现检查，用于分析监控统计数据和日志
  
• 3.2.6. 需要一种通用的比较算法来减轻数据用户的编码负担，同时要求算法足够灵活，能够满足大多数精度要求
  
• 3.2.7. 检查可以是通用数据属性和业务特定逻辑的组合
  

3.3. 检测质量异常

• 3.3.1. 异常检测包括分析数据属性，并将其与历史趋势进行比较，以确定预期范围
  
• 3.3.2. 异常现象是某些事物正在发生变化的迹象，有助于发现数据质量问题
  
• 3.3.3. 并非所有异常都与数据质量问题有关，可能只是配置更改或模式更改的结果，这些变化可能会导致指标偏离以前的模式
  
• 3.3.4. 区分真正的数据质量问题和简单的异常是一项挑战
  
  
  
  • 3.3.4.1. 没有一种算法对所有场景都适用
    
  • 3.3.4.2. 异常训练是个大问题，由于异常数据和正常数据之间的边界不精确，因此定义正常区域非常困难
    
  
  
• 3.3.5. 正常的定义在不断演变—今天被认为正常的东西在未来可能不正常
  
• 3.3.6. 每次误报都会导致调试和解释更改原因所花费的时间增加
  

3.4. 防止数据质量问题

• 3.4.1. 该任务则是防止低质量的数据记录被用于生成洞察
  
• 3.4.2. 在接入时，具有数据质量问题的记录将根据准确性规则和异常跟踪进行标记
  
• 3.4.3. 数据质量和可用性之间存在权衡
  
  
  
  • 3.4.3.1. 积极地检测和预防低质量数据可能会导致数据可用性问题
    
  • 3.4.3.2. 更高的数据可用性可能以牺牲数据质量为代价
    
  
  
• 3.4.4. 正确的平衡取决于用例
  
  
  
  • 3.4.4.1. 对于为多条下游管道提供数据的数据集，确保高质量更为关键
    
  • 3.4.4.2. 问题解决后，需要回填ETL来解决数据可用性问题
    
  
  
• 3.4.5. 避免低质量的数据导致的数据可用性问题
  
• 3.4.6. 不检查质量可确保高可用性，但需要后处理的方式，以确保一致的数据质量
  

4. 定义需求

4.1. 数据质量服务的有效性取决于生成的洞察的领域和类型

• 4.1.1. 实施质量检查可能会成为一项煮海战术，重要的是通过逐步实施质量模型来确定关键质量需求的优先级和阶段性
  
• 4.1.2. 对于对高数据精度敏感的洞察，质量可观测性是必不可少的
  

4.2. 检测和处理数据质量问题

• 4.2.1. 有多种不同的质量检查​，如空值检查、特定值检查、模式验证检查、列值重复检查和唯一性检查
  
• 4.2.2. 一致性、准确性、完整性、可审计性、有序性、唯一性和及时性
  
• 4.2.3. 基于首先验证表中单个列、多个列和跨数据库依赖项的一致性
  
• 4.2.4. 数据质量需要同时支持批处理和流式数据源
  
• 4.2.5. 需求的另一个方面是定义在日常接入过程中检测到低质量数据的处理过程
  

4.3. 功能性需求

• 4.3.1. 准确性度量
  
  
  
  • 4.3.1.1. 通过数据模式属性、值分布或业务特定逻辑，使用绝对规则对数据集的准确性进行评估
    
  
  
• 4.3.2. 数据剖析和异常检测
  
  
  
  • 4.3.2.1. 对数据集中的数据值进行统计分析和评估，以及预先构建算法函数，以识别不符合数据集中预期模式的事件（表明有数据质量问题）​
    
  
  
• 4.3.3. 主动避免
  
  
  
  • 4.3.3.1. 防止低质量数据记录与其他数据集混合
    
  
  

4.4. 非功能性需求

• 4.4.1. 及时性
  
  
  
  • 4.4.1.1. 可以及时执行数据质量检查，以更快地发现问题
    
  
  
• 4.4.2. 可扩展性
  
  
  
  • 4.4.2.1. 该解决方案可用于多个数据系统
    
  
  
• 4.4.3. 可伸缩性
  
  
  
  • 4.4.3.1. 该解决方案需要设计成可处理大数量级的数据（以PB为单位）​
    
  
  
• 4.4.4. 可定制化
  
  
  
  • 4.4.4.1. 该解决方案应允许用户可视化数据质量仪表盘，并个性化仪表盘视图
    
  
  

5. 实现模式

5.1. 准确性模型模式

• 5.1.1. 自动创建模型，以验证大数量级数据的准确性
  
• 5.1.2. 准确性模型模式计算数据集的准确性
  
• 5.1.3. 基本方法是通过匹配数据记录的内容、检查其属性和关系来计算出增量数据记录与现有源数据集的差异
  
• 5.1.4. 工作原理
  
  
  
  • 5.1.4.1. 用户将黄金数据集定义为事实来源
    
  • 5.1.4.2. 用户定义映射规则，指定数据记录和黄金数据集之间列值的匹配
    
  • 5.1.4.3. 映射规则作为质量作业，持续运行以计算数据质量指标
    
  • 5.1.4.4. Deequ
    

    5.1.4.4.1. 建立在Apache Spark之上，并且可以扩展以处理海量数据
    

    5.1.4.4.2. 提供了约束验证，允许用户定义质量报告的测试用例
    

    5.1.4.4.3. 提供了内置功能用于识别测试的约束，并根据测试计算指标
    

    5.1.4.4.4. 支持有状态的指标计算，提供了一种验证增量数据加载的方法
    

    
    
  
  

5.2. 基于剖析的异常检测模式

• 5.2.1. 自动检测质量异常，同时减少误报
  
• 5.2.2. 侧重于对历史数据剖析的自动分析来检测数据质量问题
  
• 5.2.3. 聚合数据集的历史特征，用来进行数据剖析
  
• 5.2.4. 异常检测，通过应用数学算法预测数据问题
  
• 5.2.5. 目标是识别指示质量问题的异常数据属性
  
• 5.2.6. 工作原理
  
  
  
  • 5.2.6.1. 跟踪空值、重复值等的简单统计信息
    
  • 5.2.6.2. 跟踪最大值、最小值、平均值、偏差等的汇总统计信息
    
  • 5.2.6.3. 高级统计信息，如频率分布、相关统计等
    
  • 5.2.6.4. 历史趋势被提供给数学和机器学习算法中
    
  • 5.2.6.5. 超出阈值的数据记录被标记为异常，表明存在质量问题
    
  • 5.2.6.6. 实际上，不同的算法组合被优化以检测不同类别的异常，并且能够结合短期和长期趋势以及季节性
    
  
  
• 5.2.7. Apache Griffin
  
• 5.2.8. LinkedIn的ThirdEye
  
• 5.2.9. Amazon的Deequ
  
• 5.2.10. Spark中的分析作业是自动调度的
  

5.3. 避免模式

• 5.3.1. 主动防止低质量记录污染数据集
  
• 5.3.2. 此模式可以防止低质量记录与数据集的其他部分合并
  
• 5.3.3. 是一种主动管理数据质量以减少对后处理数据的整理需求的方法
  
• 5.3.4. 在没有这种模式的情况下，具有质量问题的数据会被机器学习模型和仪表盘使用，从而导致错误的洞察
  
• 5.3.5. 调试洞察的正确性就像一场噩梦，需要根据具体情况进行不可持续的优化
  
• 5.3.6. 模式约束
  
  
  
  • 5.3.6.1. 模式在数据湖接入期间被指定
    
  • 5.3.6.2. 模式在接收数据时被验证和强制执行，以防止坏数据接入数据湖
    
  • 5.3.6.3. Databricks的Delta-Lake实现了这种模式
    
  
  
• 5.3.7. 断路器
  
  
  
  • 5.3.7.1. 类似于微服务架构中的断路器模式​，数据管道的断路器阻止低质量的数据传播到下游
    
  • 5.3.7.2. 结果是报告中将丢失低质量时间段的数据，但如果无质量问题，则保证数据是正确的
    
  • 5.3.7.3. 主动的方法使数据可用性与数据质量成正比
    
  • 5.3.7.4. Intuit的SuperGlue
    
  • 5.3.7.5. Netflix的WAP
    
  
  

来源：程序园用户自行投稿发布，如果侵权，请联系站长删除
免责声明：如果侵犯了您的权益，请联系站长，我们会及时删除侵权内容，谢谢合作！