数据权力优先权

优步彻底改变了世界如何通过提供数十亿个乘客，企业，餐馆，司机和快递公司的游乐设施和交付方式移动。在这个巨大的运输平台的核心，是大数据和数据科学，使优步所做的一切力量，例如更好的定价和匹配，欺诈检测，降低eta和实验。每天收集和处理数据的Petabytes，数以千计的用户派生洞察力并从该数据中做出决定，以构建/改进这些产品。

除了规模问题

虽然我们能够扩展我们的数据系统，但我们之前没有足够关注一些重要的数据问题，这些问题在规模上变得更加重要。出现的一些具体问题包括:

• 数据重复我们没有一些关键数据和参数的真实来源，这导致在使用数据和参数时出现重复、不一致和许多混乱。为了弥补这一点，消费者必须做大量的尽职调查，从解决业务问题中抽出时间。使用自助工具创建的成千上万的数据集加剧了这个问题，没有明显的指示哪些数据集是重要的。
• 发现问题：发现数十万个数据集之间的数据很难，没有富裕的元数据和刻面搜索。糟糕的发现导致重复的数据集，重复工作和不一致的答案，具体取决于使用哪些数据来回答问题。
• 断开连接工具：数据流过许多工具，系统和组织。但我们的工具没有彼此集成，并导致重复的努力和糟糕的开发人员体验 - 例如，必须在多个工具中复制和粘贴文档和所有者信息;开发人员无法自信地改变模式，因为它是明显的，它是如何消耗下游的。
• 日志不一致:在手动下记录移动设备;日志没有结构，以实现轻松且一致的方式来测量实际的用户行为，导致推断效率低下和错误的用户行为。
• 缺乏过程跨团队缺乏数据工程过程导致了不同级别的成熟度和变化。在跨团队的数据质量和过程的定义或度量上没有一致性。
• 缺乏所有权和sla：数据集没有正确拥有 - 他们往往没有提出质量保证，SLA for Bug修复是不一致的，随叫随到的，事件的管理远远远远远离我们为服务所做的方式。

这些问题不是优步 - 基于我们与其他公司的工程师和数据科学家的对话，这些是常见问题，特别是对于那些生长的人。虽然服务和服务质量倾向于获得更多焦点，但由于在故障/破坏的立即可见，数据和相关工具通常往往倾向于留下后座。但是，将它们与服务工具/管理中的严谨程度为单位进行修复并在规模变得非常重要，特别是如果数据在产品功能和创新中发挥着关键作用，那么它为优步效果。

需要一种与数据的整体方法

下图显示了从移动应用程序和服务到我们的数据仓库和最终消费表面的高级数据流。我们最初的分段反应式尝试仅在数据流中出现数据问题的点修复问题，解决的是症状，而不是根本原因。我们意识到，我们需要一个整体的方法来解决这些问题，并端到端地解决这些问题。我们的目标是重组数据日志系统、工具和流程，以在整个优步提供数据质量的阶梯式变化。我们在端到端数据流堆栈上召集了团队，其中包括来自堆栈每个部分的工程师和数据科学家，最终修改了20多个现有系统。

保持努力关注整体的思考,我们“切片”的关键数据,有关旅行骑手和会话信息应用,并试图为他们创建一个真理的来源(说)以及修复登录应用程序,处理数据的工具,数据本身,需要维护的流程说。

从第一个原则接近数据

与试图隐藏数据并向服务外部公开狭窄接口的服务不同，仓库中的脱机数据更多地是公开来自相关服务和待一起分析的域的数据。我们认识到的一个关键问题是，为了做好这一点，我们不仅应该处理数据的工具，还应该处理数据的人员和处理方面。所以我们提出了一些指导原则:

• 数据代码:数据应被视为代码。对数据构件的创建、弃用和关键更改应该经过设计评审过程，并使用适当的书面文档，其中要考虑消费者的视图。架构更改需要强制审查人员在更改登陆之前签署。模式重用/扩展优先于创建新模式。数据工件具有与之相关联的测试，并且不断地进行测试。这些是我们通常应用于服务api的实践，我们应该将这种严谨性扩展到考虑数据。
• 数据是拥有：数据是代码，所有代码必须拥有。每个数据工件都应该具有明确的所有者，明确的目的，并且应该在其实用​​程序结束时弃用。
• 数据质量已知:数据工件必须有用于数据质量的sla、用于bug的sla、以及事件报告和管理的sla，就像我们对服务所做的那样。船东负责维护这些sla。
• 加速数据生产力：必须设计数据工具，以优化生产者和消费者之间的协作，必要时具有强制所有者，文档和审稿人。数据工具必须与其他相关工具集成，良好地绕过必要的元数据。数据工具应符合相同的开发人员等级作为服务，提供在登陆后编写和运行测试的能力，以在滚动到生产之前测试暂存环境中的变化，并与现有的监控/警报生态系统相结合。
• 组织的数据：团队应旨在成为“全堆栈”的人员，因此必要的数据工程人才可以追随数据的整个生命周期。虽然有更多的中央团队拥有的复杂数据集，但大多数生产数据的团队都应该瞄准当地所有权。我们应该具备必要的培训材料，并优先考虑培训工程师，以合理良好地精通基本数据生产和消费实践。最后，团队领导应该对他们生产和消费的数据的所有权和质量负责。

解决问题

在本文的其余部分中，我们将重点介绍从我们使用该程序的经验中获得的一些最有用和最有趣的收获。

数据质量和级别

由于数据质量不佳，我们经历了很多艰辛。我们已经看到在实验中不准确的测量导致了大量的体力劳动，并在验证和纠正数据时失去了生产力。事实证明，随着大数据的广泛使用，这个问题变得越来越普遍IBM学习和HBR.由于数据差，估计由数据提供支持的企业遭受巨大的负面影响。

为了减少工作量和对业务的负面影响，我们希望开发一种讨论数据质量的通用语言和框架，这样任何人都可以以一致的期望生成或消费数据。为了做到这一点，我们开发了两个主要概念:标准数据质量检查和数据集层的定义。

数据质量

数据质量是一个复杂的主题，许多不同的方面值得深入考试，因此我们将对我们的数据质量讨论限制为我们取得重大进展的领域，并遗漏了其他讨论。在优步生成和使用数据的上下文在我们选择要专注于的数据质量方面具有重要作用。虽然一些可转让给他人，但有些则不是。Uber中数据生产者和消费者面临的常见问题是以下内容：如何在最新鲜数据上进行分析与完整数据之间的分析之间进行权衡吗？鉴于我们在不同的数据中心并行运行管道，我们应该如何推理不同DCS中数据的一致性？应在给定的数据集上运行哪些语义质量检查？我们想选择一组检查，为推理这些问题提供了一个框架。

数据质量检查

经过几次迭代，我们得到了下面描述的五种主要的数据质量检查类型。每个数据集必须带有这些检查和一个默认的SLA配置:

• 新鲜:从数据产生到目标系统中包含完整性水印(默认设置为39s)达到99.9%的完整性之间的时间延迟，因为简单地优化新鲜度而不考虑完整性会导致糟糕的质量决策
• 完整性:与源系统中的行数相比，目的地系统中的行的百分比
• 重复：具有重复的主要或唯一密钥的行的百分比，默认为0％在原始数据表中复制，同时在建模表中允许少量复制
• Cross-data-center一致性：将当前数据中心中数据集的副本与另一个数据中心中的副本进行比较时，数据丢失的百分比
• 语义检查：捕获数据中的字段的关键属性，例如null / not-null，唯一性，唯一值的数量和值范围
  

DataSet所有者可以选择提供不同的SLA，具有适当的文档和对消费者的推理 - 例如，根据数据集的性质，一个可能想要牺牲新鲜度的完整性（思考流数据集）。同样，消费者可以选择基于这些度量的数据集 - 基于完整性触发而不是简单地基于时间触发来获取数据集。

我们正在继续进行更复杂的检查，包括跨数据集概念的一致性检查和在时间维度检查之上的异常检测。

数据层

除了质量措施外，还有必要有办法将数据集与业务不同程度的重要性联系起来，因此我们可以轻松突出最重要的数据。通过分配“层” - 基于数据的业务关键性，我们已经习惯了为服务进行服务。这些层有助于确定中断的影响并提供关于数据的基层应该用于目的的指导方针。例如，如果某些数据影响合规性，收入或品牌，那么它应该标记为Tier-1或Tier-2。用户创建的临时数据集以获得ad hoc探索在默认情况下，较不重要的被标记为第5层，如果不使用，可以在一段固定的时间后删除。轮胎还确定必须归档的事件级别和用于修复针对数据集创建的bug的SLA。分层的副产品是我们依靠业务关键决策的数据资产的系统库存。本练习的另一个好处是实际数据集的重复数据删除类似或不再作为真理来源。最后，通过分层启用的可见性帮助我们重构了数据集更好的建模和相干数据粒度和归一化水平。

我们已经开发了自动生成“分层报告”的组织，显示需要分层的数据集，疲劳数据的使用，等等，作为一个度量组织的“数据健康状况”。我们还将跟踪这些度量作为“卓越工程”度量的一部分。随着更多的采用和反馈，我们不断迭代准确的定义和度量方法，进一步改进它们。

数据质量工具

如果我们不能使它们自动化，使它们易于使用和应用，那么仅仅有这些定义是不够的。我们将多个现有的数据质量工具合并到一个实现这些定义的工具中。我们自动生成有意义的测试(对于原始数据- Kafka主题转储到仓库-我们可以自动生成四种类型的测试，除了语义测试)，并使创建新测试更容易，从数据集所有者的输入最少。虽然这些标准检查为每个数据集提供了最小的测试集，但该工具的构建也足够灵活，生产者只需提供一个SQL查询就可以创建新的测试。我们学到了许多有趣的课程如何规模与低开销,这些测试的抽象,使它容易构建一套测试数据集,当安排测试减少假阳性和嘈杂的警报,这些测试适用于流媒体数据集,如何等等,我们希望在以后的帖子中发布。

databook和metadata.

如前所述，我们有数百万个数据集和数千个用户。如果我们考虑其他数据资产 - 报告，ML功能，指标，仪表板等 - 我们管理的资产数量甚至更大。我们希望确保：a）消费者正在使用正确的数据做出决策，而b）生产者正在制定智能决策，以发展数据，优先级泄露错误修复等，我们需要一个关于所有数据的单个目录。资产并根据其需求提供对用户的正确信息。事实上，我们意识到的糟糕的发现，先前导致了生产者和消费者的恶性循环，产生重复，然后被遗弃的冗余数据集。

我们希望向用户展示关于每个数据工件(表、列、指标)的全面元数据:

• 基本元数据:例如文档、所有权信息、管道、产生数据的源代码、样本数据、沿袭和工件层
• 使用元数据：统计有关谁使用它的何时，流行查询和一起使用的工件
• 元数据质量：对数据进行测试，它们何时运行，哪些是通过数据提供的（和聚合SLA）
• 成本元数据：用于计算和存储数据的资源，包括货币成本
• 错误和sla:针对工件、事件、最近的警报和响应所有者问题的总体SLA归档的bug

创建此单个元数据目录并提供强大的UI，具有上下文中的搜索和发现对于在生产者和消费者之间启用协作至关重要，以使用数据，以及整体UPLEVEL数据质量。

对此目标，我们完全修改了我们内部元数据目录的后端和UI，DataBook。我们标准化的元数据词汇表可以轻松地将新的元数据属性添加到现有实体，设计可扩展性以轻松地定义新实体类型，以最少的onboard努力定义新的实体类型，并将大多数关键工具集成到该系统中，并将其元数据发布到此中央位置各种数据资产，工具和用户之间的点。改进的UI干净利地呈现信息，并支持更容易的方式来过滤和缩小所需的数据。在这些改进后，刀具使用量急剧增加。我们在本博客文章中详细介绍了这些变化 -雷竞技到底好不好用raybet ．

应用程序上下文的日志

为了理解和改进产品，让我们的应用日志捕捉实际的用户体验是至关重要的。我们希望衡量用户体验，而不是推断出来，但是每个团队都有自定义日志记录方法导致如何测量用户体验的不一致。We wanted to standardize how logging is done across teams in the entire app, and even “platformizing” logging so developers are free to think less about logging information that’s necessary to capture across all product features such as: what’s shown to the user, the state of the app when a user interacted with it, the type of interaction, and interaction duration.

挖入移动框架以在优步构建应用程序后，我们意识到移动应用程序开发框架（以前开放）已经拥有自然结构，内置它可以在用户经历时提供有关应用状态的关键信息。自动捕获层次结构的肋骨将为我们提供应用程序的状态，以及哪些肋骨(大致将它们视为组件)当前是活动的。应用程序上的不同屏幕映射到不同的肋骨层次。

在这种直觉的基础上,我们开发了一个图书馆,捕捉当前的肋骨层次结构,序列化,并自动将它附加到每个分析事件发射的应用。后端网关接收这些消息,我们实现了一个轻量级的从肋层次结构映射到一组灵活的元数据(例如屏幕名称,应用程序中的舞台名称等等)。这个元数据可以独立地由生产者或消费者添加更多信息，而无需依赖于移动应用的更改(游戏邦注:由于构建和发布周期需要数周)。在后端，网关会在写入Kafka之前，将这个附加元数据附加到分析事件以及序列化状态。网关上的这个映射也可以通过API获得，因此当映射发展时，仓库作业可以回填数据。

Beyond the core problems above, we had to solve a few other problems, which we won’t cover in detail here, such as: optimizing the serialized RIB hierarchy to reduce the analytics payload size, making the mapping efficient, keeping the mapping correct as the app changes via a custom testing framework, several intricacies in mapping RIB trees to state correctly, standardizing on the screen and state names, etc.

虽然这个库并没有完全解决我们打算解决的所有日志问题，但它确实提供了一种日志结构，使很多分析工作变得更容易，如下所述。我们正在迭代这个库来解决上面列出的其他问题。

骑手漏斗分析

使用上面的日志记录框架产生的数据，我们能够大大简化船员行为的漏斗分析。我们在几个小时内建造了一个仪表板，这将在过去几周内带来了我们。此数据目前正在为大量的实验监视和其他仪表板提供供电，以了解用户行为。

指标标准化

当我们创建Data180时，公司中有许多度量存储库。我们评估了这些解决方案的优缺点，并在一个名为uMetric的存储库上进行了标准化。事实上,它是一个多库——它拥有先进的功能,如让用户关注YAML格式的定义和拿走很多辛劳通过生成不同的查询系统的查询就像蜂巢/转眼间/火花,产生流指标和批处理管道,自动创建数据质量测试,等等。这一系统正在得到更广泛的采用，我们也在投资进一步加强它。我们正在自动化重复和近乎重复的度量检测，将这个系统与Databook和其他数据消费表面集成，这样消费者就可以只消费度量结果，而不是复制和运行度量的SQL(在那里，通过调整SQL更容易犯错误和重复度量)，改进自助服务性质，在着陆差异前检测bug等。这种标准化帮助我们大大减少了使用时的重复和混淆。本博客对该系统进行了详细的描述雷竞技到底好不好用度量标准化之旅．

其他工具和过程更改

除了上面列出的更改之外，我们还实现了其他几个工具和流程更改，以改进我们的数据区域性，简要描述如下:

共享数据模型:为避免在常见概念的模式定义中重复，我们改进了模式定义工具，以允许导入和共享现有类型和数据模型。我们现在正在建立更多的功能和流程来推动采用共享数据模型，并减少重复和近重复数据模型的创建。

移动分析强制代码审查和单元测试:我们重组了移动分析事件的模式，允许生产者和消费者将自己添加为强制审核人员，以避免在未经审查和通知的情况下推出更改。我们还构建了一个移动日志记录测试框架，以确保在构建时运行数据测试。

强制性所有权：我们在数据制作的根目的中改进了数据工具和表面（架构定义，Kafka主题创建，管道创建数据，度量标准创作，仪表板创建等），以便在我们无法自动推断所有者时制作所有权信息。所有权信息进一步标准化为整个公司的单一服务，并跟踪团队和组织，而不仅仅是个别创造者。这种变化消除了新的尚未数据。我们进一步进一步ran启发式算子将所有者分配给“被遗弃的”数据集，这些数据集没有人或业主不再在公司，让我们跟踪达到100％的所有权覆盖范围。

整合跨工具我们集成了工具，这样一旦在源工具上设置了文档、所有权和其他关键元数据，它就可以无缝地流过所有下游工具。我们将管道工具与标准警报和监视工具集成在一起，因此在为服务和数据管道生成和管理警报的方式上具有一致性。

未来的工作

我们开始了解数据 - 考虑到跨越人和系统的全部终端到最终数据流动 - 可以导致更高的整体数据质量。我们相信这项努力表明了有利于这一假设的有力证据。然而，最初的工作仅仅是我们对更好的数据文化的转型之旅的开始。建立这项工作的成功，我们将这个程序跨过优步汇集到不同的组织和应用程序。计划团队专注于分层，建立真理数据，UpleVel数据质量和SLA的数据，而平台团队继续改善上述工具等。两者都在一起工作，以改善在优步建立强大的数据文化的过程。正在进行的工作的一些例子包括：

• 对工具进行了更多基础性的改进，并提供了更多的自动化，以支持不同的数据质量检查;更多的整合来减少辛劳
• 对应用日志框架的改进，以进一步捕获更多关于用户实际上在应用上“看到”和“做”的视觉信息
• 改进工艺和工具以改善生产者和消费者之间的协作
• 对数据资产实施生命周期，以便从我们的系统中删除未使用的和不必要的工件
• 在工程师和数据科学家的日常数据开发工作流程中进一步采用上述原则

我们希望在未来实现更好的数据文化的过程中分享更多经验教训。如果你有兴趣在Uber解决有挑战性的数据问题，请申请这里或这里．