Uber通过推动数十亿次打车数据，为数百万的司机，企业，餐馆和快递员提供动力，从而彻底改变了世界的生活方式。这个庞大的运输平台的核心是大数据和数据科学，可为Uber所做的一切提供支持，例如更好的定价和匹配，欺诈检测，降低ETA以及试验。每天收集和处理PB级的数据，成千上万的用户获得洞察力，并根据这些数据做出决策以构建/改进这些产品。
大数据问题
出现的一些具体问题包括：
- 数据重复：我们没有某些关键数据和指标的真实来源，这会导致重复，不一致和消耗大量数据和指标时造成混乱。消费者必须通过进行大量的尽职调查来弥补这一点，这需要花费一些时间来解决业务问题。使用自助服务工具创建的数十万个数据集加剧了这一问题，但没有明显表明哪些数据集很重要。
- 发现问题：没有丰富的元数据和多面搜索，很难在数十万个数据集中发现数据。发现不佳会导致重复的数据集，重复的工作以及不一致的答案，具体取决于用来回答问题的数据。
- 断开连接的工具：数据流经许多工具，系统和组织。但是我们的工具没有相互集成，导致工作重复和开发人员经验欠佳-例如，人们将不得不跨多个工具复制和粘贴文档和所有者信息；开发人员无法自信地更改架构，因为不清楚它是如何在下游使用的。
- 记录不一致：在移动设备上的登录是手动完成的；日志没有一种结构可以启用一种简单而一致的方法来衡量实际用户行为，从而导致推断用户行为是低效且错误的。
- 缺乏流程：各个团队之间缺乏数据工程流程会导致不同程度的成熟度和差异。各个团队之间在数据质量和流程的定义或衡量上并不一致。
- 缺乏所有权和SLA ：数据集没有适当拥有-它们通常没有质量保证，用于漏洞修复的SLA不一致，应召唤，事件管理与我们为服务所做的方式相去甚远。
这些问题不是Uber独有的-根据我们与其他公司的工程师和数据科学家的对话，这些是常见的问题，特别是对于增长非常快的问题。
采用整体方法处理数据
下图显示了从移动应用程序和服务到我们的数据仓库以及最终消耗表面的高级数据流。我们最初的零散被动尝试仅在出现问题的数据流中解决问题，而不是解决根本原因。我们意识到，我们需要一种整体方法来解决这些问题并端到端解决这些问题。我们的目标是重组数据记录系统，工具和流程，以在整个Uber中实现数据质量的阶梯式变化。我们将跨端到端数据流堆栈的团队召集在一起，其中包括堆栈中每个部分的工程师和数据科学家，最终修改了20多个现有系统。
为了使精力集中在整体思维上，我们对“关键”数据进行了“切片”，这些数据与Rider应用程序中的行程和会话信息相关，并尝试为他们创建真相（SoT）来源并修复登录问题。应用程序，处理数据的工具，数据本身以及将其维护为SoT所必需的过程。
从第一性原理获取数据
与试图隐藏数据并暴露服务外部狭窄接口的服务不同，仓库中的脱机数据更多地是要暴露来自相关服务和域中的数据，以便一起进行分析。我们有一个关键的认识，就是要做到这一点，我们不仅要解决数据工具，还要解决数据的人员和流程方面。因此，我们提出了一些指导原则：
- 数据作为代码：数据应视为代码。数据工件的创建，弃用和关键更改应在设计审查过程中进行，并考虑到消费者的意见，并采用适当的书面文件。模式更改具有强制性的审阅者，他们会在更改登陆之前退出。模式重用/扩展是创建新方案的首选。数据工件具有与之相关联的测试，并且会不断进行测试。这些是我们通常应用于服务API的实践，我们应该将同样的严格程度扩展到考虑数据方面。
- 数据拥有：数据是代码，所有代码都必须拥有。每个数据工件都应具有明确的所有者，明确的用途，并且在其实用程序结束时不应使用。
- 数据质量是众所周知的：就像我们对服务所做的那样，数据工件必须具有用于数据质量的SLA，用于错误的SLA以及事件报告和管理。所有者负责维护这些SLA。
- 加快数据生产力：必须设计数据工具以优化生产者和消费者之间的协作，必要时具有强制所有者，文档和审阅者。数据工具必须与其他相关工具集成在一起，从而无缝地绕过必需的元数据。数据工具应达到与服务相同的开发人员等级，具有在着陆更改之前编写和运行测试，在过渡到生产环境之前测试登台环境中的更改以及与现有监视/更改生态系统良好集成的能力。
- 整理数据：团队应该以“全栈”人员为目标，以便有必要的数据工程人才来全面了解数据的整个生命周期。尽管可以由更多的中央团队拥有复杂的数据集，但是大多数生成数据的团队都应该针对本地所有权。我们应该拥有必要的培训材料，并优先考虑培训工程师，以使他们对基础数据的生产和使用实践有所了解。最后，团队负责人应对他们产生和使用的数据的所有权和质量负责。
该文的其余部分中，我们将从我们对该程序的经验中重点介绍一些最有用和最有趣的收获。点击标题见原文