D3：检测数据漂移的自动化系统(译文-来自:Uber)

闪念基因 07-04 524

前言：

眼前姐妹们对“程序集成探查器”大约比较珍视，同学们都需要分析一些“程序集成探查器”的相关文章。那么小编在网络上网罗了一些关于“程序集成探查器””的相关内容，希望大家能喜欢，小伙伴们快快来了解一下吧！

介绍

数据为 Uber 几乎所有面向客户的关键流程提供支持。糟糕的数据质量会影响我们的 ML 模型，导致糟糕的用户体验（错误的票价、ETA、产品等）和收入损失。

尽管如此，许多数据问题是在问题开始几周甚至几个月后由用户手动检测到的。数据回归很难捕捉到，因为最具影响力的回归通常是沉默的。它们不会以明显的方式影响指标和 ML 模型，直到有人注意到出现问题，最终发现数据问题。但到那时，错误的决定已经做出，机器学习模型已经表现不佳。

这使得彻底监控数据质量变得至关重要，以便主动发现问题。

数据问题示例

让我们举个例子来了解数据事件的影响。

事件

优步票价由不同的组成部分组成，例如涨价、通行费等。乘客对这些不同组成部分的反应和行程转化率对于构建票价 ML 模型至关重要。我们遇到过一个事件，即美国主要城市 10% 的会话的关键票价数据集中缺少票价部分“X”。

根本原因

根本原因是应用程序实验开始以不同方式记录票价。

它是如何被发现的？

一位数据科学家在 45 天后手动检测到此事件。

影响此数据集用于训练关键票价 ML 模型。票价成分是用于训练该模型的重要特征。为了量化此类数据事件的影响，Fares 数据科学团队构建了一个模拟框架，该框架可以从实际生产事件中复制损坏的数据，并评估对票价数据模型性能的影响。30% 的会话中损坏的票价部分严重影响模型性能，导致增量总预订量下降 0.23%。在美国主要城市 10% 的会话中，票价组成数据损坏的事件持续 45 天，将转化为数百万美元的收入损失。具有特定票价组成部分的会话百分比是领导层和全球运营人员用来做出重要决策和了解市场健康状况的关键指标。此外，当发生数据事件时，跨数据科学、数据工程和产品工程的多个团队在试图确定数据事件的根本原因时会失去生产力。数据事件类别

深入研究这些事件以制定更快地发现这些问题的策略非常重要。我们分析了 2022 年 Uber 的数据事件，并将它们分为不同的类别。我们过滤掉了与数据集中的数据质量无关的事件（例如，访问控制和查询层问题）。

我们进一步将剩余的事件分为导致部分数据丢失的事件和导致完整数据丢失的事件。后者通常是由 ETL 管道故障或基础设施故障（例如，Spark、Yarn、Hive 中断）引起的；这些问题更容易检测和缓解。但是导致部分/不完整数据的事件通常是无声的，并且更难被发现。

图 1：按类别划分的数据事件分布

监控和检测部分数据事件的难度体现在这些事件的平均 TTD（检测时间）比ETL/基础设施故障引起的数据事件多 5 倍。

我们设计的框架的目标是将部分数据事件的 TTD 降低到与基础设施/ETL 中断相同的水平。

检测策略

数据不完整的原因很多，并且遍布整个堆栈：

新功能和实验

新功能可能会改变日志，使后端数据集不准确（例如，由于架构更改，可能会省略某个字段，或者可能会更改某个字段的含义）。

ETL 逻辑变化

上游 ETL 更改可能会破坏数据，从而在数据集中引入不准确性（例如，连接实现中的错误更改，因此数据可能开始丢失）。

上游中断和迁移

由于错误或大规模迁移，上游服务可能会停止记录记录。

第三方数据源质量问题

通常，数据集会从质量不受我们控制的第三方数据源获取日志。这些第三方数据源可能会产生数据不一致的情况。

我们研究了各种方法来监控和检测这些问题。以下是按该方法可能捕获的事件数量分布的监控方法：

图 2：检测数据漂移的测试类型

我们发现，检查列值漂移的列级测试套件可能已经检测到许多（将近 50%）事件。

什么是监视器？

监控器是本博客中经常使用的一个术语，表示基于某种聚合类型计算的统计值，用于识别列值的漂移。

监视器示例空百分比错误百分比百分位数（P50、P75、P99、P1）标准差、平均值、中位数不同计数我们需要什么显示器？

根据我们管理关键数据集和处理数据事件的经验，我们发现以下监视器很有用：

空检查

检查具有空列值的行百分比的漂移。

外键 (FK) 测试（跨数据集列比较）

外键测试检查数据集之间实体计数的一致性（例如，将表 X 中的行程与行程的真实来源 (SOT) 表进行比较）。

使用百分位数检查检查数字列中的漂移

数字列值的剧烈变化表明该列的含义已经改变。

分类列中的分布

检查枚举列值分布的漂移，例如，值 X、Y 和 Z 均匀出现的列具有不成比例的高 X 计数。

其他需求维度监控

数据问题通常始于城市或新发布的应用程序版本。按维度监控可以更快地发现这些问题。

为什么手动应用列级监视器无法扩展它需要数千人-周的努力手动设置的静态阈值不适合我们在 Uber 拥有的动态和趋势数据跨数据集的不同测试无法扩展 PB 级数据很难跟上架构更新（新列）为数百个城市设置基于维度的监控器是不可行的介绍 D3（数据集漂移检测器）

从以上部分可以清楚地看出，我们需要一个强大的自动化系统来衡量和监控列级数据质量。D3 或数据集漂移检测器就是为了这个目标而构建的。

D3 特点

自动入职。该框架根据离线使用情况确定数据集中的重要列，并对这些列应用监视器。从数据集所有者到板载它几乎不需要配置。

跨维度的自动化监控。该框架自行按维度（如应用程序版本和 city_id）进行监控。这有助于更快地检测数据问题。这也可以更准确地了解数据质量，因为即使整体数据质量没有太大变化，严重影响少数城市的数据问题仍会影响数据消费者。

自动异常检测。无需手动设置阈值。

建筑学

下图表示 D3 架构中的高级组件视图：

图 3：D3 总体高层架构

Uber Data Platform 管理的架构中有一些核心系统与我们相关。我们偶尔会在本博客中提及这些系统：

Databook：这是 Uber 内部的一个内部门户，用于探索数据集、它们的列、沿袭、数据质量测试、指标、SLA、数据一致性、重复项等。UDQ： UDQ 代表统一数据质量。它是 Uber 的一个集中式系统，负责如何定义、执行和维护数据集的数据质量测试以及这些测试的大规模警报机制。数据集所有者可以通过 Databook 创建 UDQ 测试。Michelangelo：这是一个部署 ML 模型的平台，用于跨 Uber 内部数据集进行实时预测。

D3 架构由 3 个主要组件组成，我们将详细介绍：

计算层异常检测协调器计算层

图 4：计算层高级架构

计算层构成了 D3 框架的关键。任何载入的 D3 数据集生命周期都将有两种类型的作业作为计算层的一部分执行：

一项一次性数据探查器作业，用于计算过去 90 天数据集的历史列监视器统计信息。这形成了异常检测模型的训练数据。计算最近一天的列监视器统计信息并使用异常检测算法预测统计阈值并识别当天的列漂移的每日计划作业。

这些计算作业是针对每个数据集执行的通用Spark作业。监视器是表示为 Jinja 模板的 SQL 语句。D3 数据集配置用于将模板转换为在 Spark 应用程序中执行的真实 SQL 查询。来自数据分析器和每日计划作业的计算统计数据持久保存在 Hive D3 统计数据表中。在此表之上设置警报和监视。

可插拔监视器

每个数据集的 D3 配置都包含需要成为监控一部分的列列表以及要配置这些列的监视器类型。监视器类型的一些示例是 Null 百分比、错误百分比、零百分比、百分位数检查（第 25 个百分位数、第 50 个百分位数和第 75 个百分位数值）、平均值、标准偏差等。

D3 框架和计算层中新增的监视器是使用 jinja 模板的可插入组件。一旦新的监视器被添加到框架中，任何数据集都可以配置自己的一组 D3 支持的列监视器监视器类型。

动态过滤器

还有一个配置选项，用于为每个列监视器提供动态过滤。过滤器可以是在 where 子句语句中应用的任何有效的配置单元 SQL 表达式。

方面

具有基于维度的统计计算是框架中的另一个关键要求。每当发布新版本的应用程序或在特定城市发布时出现错误时，我们经常会在所有上游数据中发现问题。在这种情况下，数据集列在整体水平上不会有任何漂移，但我们可以看到针对这些维度削减（例如城市级别或应用程序版本和设备操作系统级别）的计算统计数据出现显着峰值。

但是在框架中提供基于维度的统计计算支持存在一些挑战：

首先是维度具有高基数时出现的可扩展性挑战，从而导致计算的高资源消耗。其次，由于可用于了解趋势的抽样数据较少，导致误报率较高的风险。

目前，我们支持一些固定的维度集。一个是针对 city_id 的单一维度支持，另一个是针对应用程序版本和设备操作系统的二维支持，因为这些维度用例在识别数据漂移方面很常见。但我们计划在未来的版本中支持任何临时维度，并在框架中支持多达 5 个维度的列组合。

异常检测

截至目前，Uber 的数据可观察性是基于手动策划的基于 SQL 的测试和静态警报阈值。这需要持续关注和重新校准以适应不断变化的数据趋势。有了异常检测，我们可以有更灵活和动态的警报。对于 D3 用例，我们正在调整模型以获得高精度，以减少误报。

异常检测集成

将任何异常检测模型集成到 D3 框架中都是即插即用的。它基于通用 UDF 接口，任何模型都可以定义自己的实现。在配置时，用户可以选择他们选择的异常检测，而不必担心幕后发生的事情。

对于任何异常检测模型，输入是时间序列数据，预期输出是监控值应落入的预测限值。基准限值有时会更激进，并会产生许多误报。由于我们想要一个高精度模型，通常我们会在基本警报限制之上定义保守的警报限制。这些警报限制是基本限制的函数并且动态变化。

图 5：即插即用异常检测

预言家

我们已将 Prophet 集成为 D3 的默认异常检测。Prophet 是一种非线性回归模型，比移动平均线等直观技术有了一步改进。它是完全自动化的，可以很好地适应不断变化的趋势和季节性。与其他一些异常检测模型相比，即使训练数据较少，它也能很好地工作。

处理异常值（反馈）

真实数据通常包含离群的观察结果。与他们打交道有时会很麻烦，而且会搞乱预测。离群值是与时间序列中的大多数观察值非常不同的观察值。如果出现任何故障或错误，它们可能是错误或问题。为了尽量减少这些观察传播到预测中的长期影响，反馈机制已经到位。在这里，用户可以启用选项来手动将异常值标记为真或假。这些输入被馈送到异常检测模型，其中与真实警报相对应的数据点从未来预测的考虑中删除。

处理噪音（诊断）

我们已经看到许多自然嘈杂（下降和尖峰）并导致大量警报的时间序列。为了解决这个问题，我们有一个明确的诊断工作，可以帮助识别和过滤预测错误百分比很高的嘈杂时间序列。与这些时间序列对应的监视器已禁用警报。

协调器

Orchestrator 是一个服务组件，通过它对外暴露 D3 的能力。它充当优步数据平台和 D3 之间的中介。

图 6：Orchestrator 架构

协调者的角色资源管理

编排器管理两个重要资源：

元数据：每个数据集都有一些元数据：维度、聚合器、支持的监视器类型、排除的列、数据集分区相关信息等。元数据决定了可以在数据集上定义哪些监视器。它还有助于一键自动加载数据集。

Monitor：编排器公开 gRPC 端点以获取和更新给定数据集的监视器级信息。

生命周期管理

协调器：

管理 D3 监视器生命周期——分析数据、统计计算、异常检测、Uber 数据平台组件的状态更新使 D3 与数据集模式更改保持同步支持计划的和临时的基于触发器的统计计算设施监视器更新：如果有一些元数据变化（例如，维度或聚合器变化）或监视器级别属性更新（例如，阈值或监视器类型更新等），则必须更新相应的监视器，并且应该更新统计信息。协调器集成

由于 D3 的目标是尽可能快地大规模发现数据质量问题，因此利用 D3 的一种有效方法是通过 Databook UI 创建支持 D3 的测试。为此，编排器已与 Uber 数据平台集成。

通用数据平台合同

Uber 数据平台（更具体地说，UDQ）有一个通用的 API 合同，任何系统都可以使用它来集成、创建和维护数据质量测试及其生命周期。编排器实现这些功能以满足数据消费者的需求：

建议测试：推荐显示器到板载增删改查 API回填测试：重新计算过去几天的统计数据挑战规模

简单描述一下扩展复杂度，Uber 有超过 1000+ 层级数据集，平均每个数据集有 50+ 列。考虑到至少有两种监控器类型（例如 Null Percentage 和 P75）被添加到监控列中，并且如果数据集至少有 1 个维度和 1 个聚合器，这可以很容易地转化为每个数据集 100 多个监控器和 100k 多个监控器用于 Uber-wide数据集。

图 7：D3 的当前规模

这导致需要解决以下一些复杂性：

数据探查器和日常计划作业的高资源利用率数据集的入职监视器中繁琐的手动过程数据分析作业触发不同场景的重复数据删除，例如在回填、模式演变和临时触发器期间计算层优化

图 8：查询优化

鉴于计算作业是针对 Uber 中的任何数据集应用的通用 Spark 作业，并且具有上述规模，这可能导致每个数据集至少有 100 多个监视器，每个 Spark 作业有 100 多个查询。这转化为对 Uber 范围内数据集的数百万次查询。数据探查器和每日计划的 Spark 作业都经过优化和微调，以根据投影、分组和过滤表达式的类型将这些多个 SQL 查询组合成一组固定的逻辑模板，从而最大限度地减少混洗和数据传输（示例示例显示在上图中）。这种优化导致每个数据集的查询数量从200 多个减少到 8 个查询，进而减少了显着的混洗和数据解析，从而使资源消耗提高了 100 倍. 每个数据集的平均计算成本从1.5 美元减少到 0.01 美元。

此计算层的另一个主要瓶颈是数据分析器作业或大容量数据集的历史数据计算。我们需要调整数据探查器作业以支持每天数据量 >1TB 的数据集，用于 90 天以上的历史计算。对于此类数据集，作业以较小的块并行执行，以减少每个阶段传输的混洗量。连同其他一些 Spark 参数调整，我们可以支持任何具有最佳资源利用率的大容量数据集数据分析器作业。

自动化入职

当我们开始加载数据集时，我们注意到为每个数据集加载 100 多个监视器是一个乏味的过程。这需要大量手动用户输入，例如联系所有者以找出应实施哪些监视器。这需要几天时间。我们希望 D3 以最少的用户干预支持单击入职。

我们目前支持所有按日期以 YYYY-MM-DD 格式分区并至少每天更新的数据集。我们通过以下方式开始入职：

根据使用情况获取前 X% 的重要列根据列数据类型配置监视器为数据集配置默认监视器类型和维度映射通过在 T – X 分区上运行 D3 来处理由于数据延迟到达而导致的数据/分区延迟

通过这种方法，我们将入职时间从几天缩短到几秒钟，并使其成为完全自动化的单击操作。

处理统计重新计算

多个场景会导致统计数据重新计算。这可能是由于添加了新的监视器或更新了现有的监视器或自定义重新运行，或者用户请求的事件回填以获取真正的肯定警报。用户需要进行源回填并请求重新计算统计数据和阈值。

这里的主要挑战之一是多个重新计算请求可能导致多个作业重复处理相同的数据。这可能是非常低效的，因为监视器的数量可能会非常多。为了解决这个问题，我们设计了一个基于批处理的解决方案，该解决方案异步处理重新计算请求（触发器）。

图 9：高级触发器处理程序

定期的 Piper 任务计划每两小时命中一次 Orchestrator 触发器处理程序端点并异步处理触发器。触发器处理程序在内部获取所有待处理的请求并将它们一起批处理为每个数据集的单个触发器请求。如果尚未为数据集运行，它会进一步启动统计计算管道。

数据质量警报和监控

从数据分析器和每日计划作业生成的计算统计值和动态阈值持久保存在基于 Hive 的统计表中。统计表用于验证数据质量并用于标记数据集的完整性正常运行时间。与任何其他优步服务一样，警报与数据簿监控服务和寻呼机值班集成在一起。只要持久化统计表中发生阈值违规，就会触发警报。统计表还用于配置 tableau 仪表板以实现可视化，它与数据手册集成在一起。

警报视图

图 10：数据消费者 UI 上的警报

仪表板视图数据集监视器中的样本时间序列趋势

图 11：可视化数据漂移的仪表板

数据集中的示例警报趋势

图 12：给定数据集随时间变化的警报趋势

到目前为止我们的进展

开头提到的票价数据事件是在 45 天后手动检测到的。在 D3 框架发布后，我们已经监测了300 多个 Tier 1 数据集。TTD 大幅减少了 20 倍以上，平均为 2 天。我们在事实表上以高精度 ( 95.23% ) 检测到超过 6 个关于市场/票价数据集的生产问题。我们所看到的那种事件——

由于上游更改或错误发布，关键列为空由于源数据损坏，关键列为空数字列中的意外值激增缺少数据的大量查询数据集（每周约 13K 次查询）

这些列用于导出关键指标、分析乘客行为以及计算乘客在应用程序上看到的票价。根据博客开头描述的模拟，及早发现这些数据问题为我们节省了数千万美元的增量收入。

图 13：在市场数据集上发布 D3 之前和之后检测事件所花费的时间

下一步是什么