好的商业决策不能用糟糕的数据做出。在优步，我们使用汇总和匿名数据来指导决策，从财务规划到让司机知道在给定时间乘车请求的最佳位置。
但我们如何确保为这些决策提供高质量的数据呢?管道中的中断可能会带来麻烦的异常，例如缺少行或字段，并影响我们未来决策所依赖的数据。
传统观点认为，要用一些不同的统计模型来解释大量数据中的异常现象。然而，优步每天提供1400万次出行，相关数据的规模与这种传统观点相左。由于托管了数万个表，我们不可能手动评估管道中每个后端数据的质量。
多年来，Uber的团队已经建立了多种服务来帮助评估数据质量，从监控各种指标到让工程师和数据科学家为每个数据表创建定制测试。
为此，我们最近推出了Uber的数据质量监控器(DQM)，这是一种利用统计建模来帮助我们将数据质量分析的不同元素联系在一起的解决方案。基于历史数据模式，DQM自动定位最具破坏性的异常，并提醒数据表所有者检查来源，但不会标记太多错误，使所有者不堪重负。这种新方法已经被证明对优步的各个团队都很有价值。我们希望我们的工作和我们所获得的见解将有益于未来使用类似大数据的其他人。
Uber的数据质量异常检测架构
确保优步复杂而动态的业务基础设施的高数据质量，需要利用我们所有现有的工具，包括阿哥斯以及表面数据度量的过程数据手册．我们构建这个异常检测体系结构的主要目标是自动化数据质量监控。以优步的规模，手动梳理如此大量的数据是站不住脚的。我们必须尽可能减少人为干预的需要。
通过最少的手动指导，DQM可以告诉我们当前数据是否与我们过去观察到的数据有所不同。DQM对数据表进行历史描述，以评估数据质量以及任何高级更改。例如，如果给定数据表中的行数在一个月和下一个月之间急剧下降，那么我们就知道可能发生了数据质量问题。DQM允许服务所有者在为下游数据分析管道设置计算参数之前了解传入数据是否符合历史模式。
当出现异常时，会警告数据用户谨慎进行下游分析和建模。至关重要的是，数据科学家和运营团队事先知道数据是值得信赖的，因为许多业务决策是通过基于仪表板的管道做出的，这些管道被构建为整体而简洁的。虽然易于理解，但这些仪表板并不是为日常手动监控和干预底层数据本身而设计的。因此，当异常存在但隐藏时，基于仪表板的管道可能导致糟糕的决策。幸运的是，通过识别这些异常，DQM可以防止这些降级影响我们的服务。
下面的图1描述了我们如何将DQM与数据源和数据质量检测系统的前端UI连接起来:
数据质量指标是我们系统的基础。在Uber，我们内部用于DQM的度量生成器被称为数据统计服务(DSS)。构建DSS是为了查询任何日期分区蜂巢而且Vertica表，为每个表列生成时间序列质量度量。对于数字数据，我们查看包括平均值、中位数、最大值和最小值在内的指标。对于字符串数据，我们获得的指标包括唯一值的数量和缺失值的数量。底层功能越普遍，系统在优步整个产品领域的表现就越好。
我们完整的数据质量检测服务的前端是一个数据质量平台，这是一个通用工具，允许数据表用户通过直观的仪表板执行数据质量测试。这些数据质量测试是基于查询的;例如，我们可以测试在任何给定时期内缺失值的数量是否超过某个阈值。每当测试失败时，仪表板就会发出警报，表所有者就会收到关于测试失败的电子邮件。可以通过仪表板设置一套测试，以实现广泛的覆盖。根据这些测试的失败模式，数据表所有者可以了解可能的根本原因。
将数据源与前端仪表板绑定在一起的是DQM，它分析来自这些数据源的传入数据，并在异常出现在仪表板之前扫描异常。使任务复杂化的是，DQM需要覆盖Uber的所有产品领域，这意味着它需要足够广泛，以处理不同的情况。不同的数据表有不同的季节性模式，有些数据表可能没有表现出可以被定义为正常的模式。
随着数据大小的增加，潜在数据问题的数量也会增加。在一天结束的时候，我们需要能够始终如一地解决这个问题:当前的数据看起来是否正常，如果不正常，我们如何将用户指向异常的数据度量来修复系统管道?我们将这些信息以质量分数的形式在数据质量平台上进行自动测试。
DQM背后的统计方法
为了增强DQM标记异常数据表的能力，我们利用传统的统计方法，通过分析帮助我们理解历史数据模式，并将它们与正在测试的当前数据进行比较。
对于每个数据表，DSS生成多维时间序列输出。这对于较小的表很有用，但是对于非常大的表，时间序列的数量就变得很麻烦了。我们如何着手将这类数据集转化为可操作的异常警报?如何进行异常检测?我们如何建立一个适用于整个优步不同用例的评分标准?简而言之，我们需要把复杂的问题转化为简单的问题。然后，在更简单的空间中，我们提出了一个评分策略来衡量数据质量。
多维时间序列数据投影
我们面临的第一个问题涉及处理数据质量度量的多维性。我们需要一种有效的方法来浓缩我们的数据，以揭示历史趋势和模式。监视数据表的演变及其随时间的变化有助于将质量指标归结为单个异常得分。
为了便于建模，我们将每个表的指标视为捆绑，因为数据表的列是通过相关事件记录在一起的。例如，行程持续时间与行程距离相关。由于列之间的内在关系，我们可以执行主成分分析(PCA)将许多度量时间序列的演化分解为几个具有代表性的束，以便在下游进行更可扩展的计算，如下图2所示。由于相关时间序列可能具有相同的潜在季节性，具有代表性的时间序列也表现出这种季节性模式。
在通过PCA将数百个指标捆绑后，我们获得了几个主成分(PC)时间序列，这是本质上代表整个数据表的关键复合指标。其中，排名第一的PC系列解释了数据中90%以上的变化，因此将它们可视化可以让我们检查表级行为。例如，在上面图2所示的数据表中，我们观察到第二个PC(或PC2)对应于一周中的天数。
同样的相关性也存在于构成PC2的基础指标中，但很难从原始形式的数据中看到。分析顶级pc对于拥有超过两个月历史的表尤其有效，因为我们可以捕捉状态变化，例如变化的趋势和季节性，如下图3所示:
每当我们观察到季节性趋势的中断时，很可能数据模式也发生了变化——可能是因为缺少数据值、不正确的数据记录，或者数据表或其祖先的模式发生了变化。
异常检测设置
在绑定数据表指标之后，DQM要解决的第二个挑战是在这些预测的PC时间序列中实际执行异常检测。
提前一步预测，这意味着只预测时间序列的下一步，是解决方案。我们使用预测区间来验证当前提前一步的值是否符合历史模式。如果不是，那就是异常。虽然有很多时间序列模型，但我们关注的是Holt-Winters模型，因为它解释简单，对预测问题非常有效。特别地，我们利用Holt-Winters的加法方法对时间序列数据建模。模型组件的设置如下:
提前一步估计，ŷT + 1 | T，是基于三个底层组件:级别lt，趋势bt，以及季节项t．这个设置的一个有用的属性是指数平滑法，其中最近的点对我们的预测的影响比之前的点更大。
虽然指数平滑会产生对旧数据的偏向，而有利于新数据，但它非常有用，原因有两个。首先，由于各种经济力量和限制，我们的业务发展非常迅速，因此我们今天看到的数据模式可能很快就会成为过去。其次，由于在我们复杂的系统中很难去除异常或类似异常的模式(即，每年假日在不同的日子，并影响乘客的需求)，因此最好淡化局部趋势;然而，我们的季节性成分仍然帮助我们的模型记住过去的季节性趋势，这是我们业务的标志。
超级的阿哥斯平台为我们的后端异常检测运行提供动力，我们插入这个平台来完成我们的方法设置。为了验证我们的方法，我们首先对来自Uber的数百个数据表进行了回溯测试。由于我们要对每个PC系列执行提前一步的验证，因此需要进行两次预测——一次不使用最新数据点，另一次使用最新数据点，因为绑定时间序列的最新值的任何剧烈变化都可能改变预测结果。在某种程度上，我们需要这种行为，因为最新数据点中的任何剧烈变化都可以通过这个投影策略放大，它可以帮助我们搜索数据质量问题。
基于异常模式的表质量评分
此时，异常检测就完成了。然而，我们需要标准化我们的异常评分系统，并提出一种警报策略，让DQM与优步各个部门的表一起工作。最重要的是，我们希望防止在不需要任何操作时发出警报，使数据表所有者不知所措。
在我们的实现中，异常分数是根据最近日期的PC值与预测值之间的距离来确定的，给定几个预测区间宽度。间隔范围决定了偏差的严重程度，从0(正常)到4(极度异常)。给定日期的数据表的总体异常得分是所有三个顶级PC时间序列的异常得分之和。
使用这种方法，每个PC时间序列的贡献加权相同，即使每个PC序列解释了表度量变化的不同百分比。我们决定采用这种未加权的评分系统，以帮助揭示可能被高级pc中更大的变化所掩盖的异常行为。另一方面，在这个评分系统中有太多的pc会导致不准确或误导的分数。
通过将这种异常检测处理应用于我们的大数据基础设施的在线Vertica和Hive表，我们能够可视化随着时间的推移表集群异常行为的总体可能性。因此，我们观察到DQM下的数据表级警报比传统的度量级警报少得多，从而减少了数据工程师出现警报疲劳的机会。一般来说，我们建议遵循基于历史模式的表级警报，以及精心挑选的度量级警报。当这些警报触发时，用户可以引用其他测试来确定数据质量是否下降，如下面的图4所示:
DQM实现
为了方便地将DQM插入Uber的大数据生态系统，我们使用PySpark．PySpark允许DQM建立对现有平台的API调用，将输入数据转换为所需的格式，实现底层统计方法，并将结果输出到HDFS。
一旦我们计算了表级和列度量级的质量分数，我们就使用其他工具(例如数据质量平台上的表面测试)执行下游可视化和数据科学工作。这就是我们从后端连接到前端的完整监控系统。
在前端，用户每天都会收到数据质量分数，并可以设置额外的质量测试，以配合DQM统计计算生成的自动分数。例如，当数据出现问题时，我们的自动测试会在数据质量平台上触发警报。收到警报后，数据表所有者知道检查质量测试是否存在潜在的问题表，如果许多测试和指标失败，他们可以继续进行根本原因分析和故障缓解。
下一个步骤
自从优步的数据质量监控器(DQM)投入生产以来，该解决方案已经为公司各个团队标记了数据质量问题，为全球用户提供了更好的服务。
我们希望行业内的其他人能够发现我们的数据质量监控方法是有用的，特别是处理pb级及以上质量问题的组织。
我们正在扩展这项工作，使我们的服务的根本原因分析更加自动化和智能。这些改进需要额外的数据，例如表和列的谱系，以及将指标捆绑到更可操作解释的特性中。在实验过程中，我们观察到，通过对数据质量分数进行聚类，我们可以发现具有相似质量退化的相似数据表，这表明通过数据管道传播常见异常。然后，我们可以使用这些相似性来识别复杂流程中的潜在断点。
确认
这个项目是优步许多团队之间的巨大合作。我们要感谢我们的合作者，包括Kaan Onuk、Lily Lau、Maggie Ying、Peiyu Wang、Zoe Abrams、Lauren Tindal、Atul Gupte、Yuxi Pan、Taikun Liu、Calvin Worsnup、Slawek Smyl和Fran Bell。
