在全球 1 万多个城市，每天都有数百万人依靠 Uber 出行、订餐和运送货物。我们的应用在超过 69 个国家和地区提供 24 小时的服务。从全球范围来看，这些活动生成了大量的日志记录和操作数据，这些数据可以在我们的系统中实时运行。其中包括有关消费者需求、司机伙伴可用性以及其他运营任务（如支付、通知等）的信息。运营像我们这样复杂的市场，需要工程师、数据科学家、数据分析师和运营经理根据平台上观察到的趋势作出实时业务决策。
为了帮助团队轻松发现并更好地理解这些数据，我们构建了。这是 Uber 的内部平台，用于显示和管理与各种数据实体相关的元数据，如数据集、内部仪表板、业务指标等。
随着 Uber 的扩张，我们的系统在技术上变得越来越复杂，数据系统的广度也成倍增长。同样，团队的需求也变得更加复杂，因为他们现在更多地依靠数据集、仪表板和业务指标来制定全球范围的业务决策。
Databook 无法通过扩展来满足这些新的需求，这促使我们重新思考我们的假设，并重建我们的工具，以更好地支持用户和他们不断变化的需求。在本文中，我们阐述了如何改进简化数据发现和流畅性的方法，以及我们从中吸取的经验教训。
Databook 的演变
我们最初于 2016 年推出>
随着数据存储规模不断扩大，团队开始对数据进行分类。他们还收集了有关如何生成数据，哪些管道将数据加载到数据存储系统，数据集的简要描述和每个表中的列的元数据。所有这些关于我们业务的元数据帮助人们发现并理解数据本身。所以它加速了我们将见解应用到决策中，并可以改进 Uber 的产品。因此，在 2017 年，我们推出了第一个版本的>
图 1：2017 年推出的>
从那时起，Uber 将业务扩展到全球数百个城市，并将其服务范围扩大到送餐、货运、自动驾驶车辆和其他业务等领域。无论是从数据量还是从系统复杂性来看，这都极大地改变了 Uber 的数据格局。
工程师、数据科学家、数据分析师和运营经理都在努力跟上时代的步伐，并定期转向>
通过对使用模式的分析和广泛的用户研究后，我们了解到>
在>
该行业也在努力提高数据科学家和数据分析师的生产力，利用元数据来推动数据洞察力。其他拥有大型和分布式数据集的公司也面临着类似的挑战，并结合其独特的业务需求和技术，建立了创新的数据目录来解决类似的问题。例如 Airbnb 的Dataportal、Netflix 的、Linkedin 的、Lyft 的和 Spotify 的等。
重建>
经过多年>
通过与团队合作，我们确定了一些指导原则，这些原则是重新设计和重新架构的基础。
随着数据实体种类的增加，由于缺乏适当的文档和所有权，我们失去了向>
最初的>
我们在多个系统中传播元数据。在统一元数据系统的前期尝试中，Databook 直接向这些系统发送请求，以获取外部元数据，而这些数据并没有存储在自己的存储中。
当我们开始构建搜索和发现基础设施时，还需要索引这个外部元数据。此外，不同元数据系统的数量增加了，它们的用例也相似。也就是说，要在数据实体上存储元数据。
依赖不同的元数据系统会导致视图不集中，工作重复。集中化的元数据存储为数据实体上的元数据创建了一个统一的位置。这样，其他服务就不会重复创建用于相同目的的元数据存储。在缺乏有效的集中式元数据管理系统的情况下，我们也可能会错误地处理数据，使其变得不可信、不可发现。
我们鼓励用户从用户界面到后端 API 来探索元数据系统并强调了开发和使用 API 的重要性。对于生成元数据的团队，我们已经实现了提供和接收不同数据实体的过程的标准化。这提高了添加各种元数据的效率。现在，通过>
Uber 中数据流的许多方式之一是通过 Hadoop 数据提取从 Kafaka 主题到 Hive 表。在数据集实体的原始>
随着数据实体种类的增加，不同数据实体之间的关系变得更加复杂。这包括依赖于多个数据集和具有不同业务指标的仪表板的机器学习功能。
图数据结构是表示这些关系的最自然的方式。数据实体的知识图谱具有很好的灵活性和可扩展性。它通过使我们的系统能够捕获这些数据实体之间的关系来做到这一点。它也回答了关于最重要的元数据关系的问题，这些问题在以前是具有挑战性的，甚至是不可能的。
图 2：数据实体有许多连接。每个实体之间至少有一种关系
上图显示了>
这些指导原则是基于我们在管理元数据方面的经验，阐述了 top="3651">Databook 架构
根据这些原则，Databook 架构需要：
此外，我们必须支持查询各种数据实体的元数据的不同需求。
Databook 组件
为了支持数据服务和产品的数据发现，Databook 从数据存储系统和服务中提取了数百万个数据实体。Databook 的设计和架构是解决大数据生态系统中元数据量和满足用户需求的关键。
Databook 由几个组件组成：
Databook 是一种数据密集型的应用，可以在 Uber 中捕获大量不同的元数据。有不同的数据存储来处理不同的用例。单系统数据存储，能够有效地处理所有访问模式和需求是不切实际的。原因在于不同的数据存储系统都有其特定的目标，从低延迟的数据检索到灵活的数据分析。
Databook 支持我们想要实现的目标，从提取各种数据实体的灵活性到支持驱动其他数据产品的健壮的数据发现。接下来，我们将研究数据建模如何帮助实现这些目标。
数据模型
拥有一个灵活的模型可以帮助我们处理在 Uber 中收集到的不同类型的实体。例如，在>
可扩展性是>
为了注册新的数据实体或更新现有数据实体的模型，我们使用名为的数据模型转换工具。这有助于为每个实体类型定义数据模式。领域专家可以提交定义，Databook 在中央专家委员会批准所提议的模式后生成数据模型。
除了数据模型之外，我们还在 Uber 上分享了相应的 Thrift、Protobuf 和 Avro。这就提供了一个一致且可重用的元数据托管词汇表。我们还将检查此架构中的所有更新，并确保它们是向后兼容的。
基于某人定义的元数据类型，Databook 创建了灵活的数据模型。有了 Dragon 模式，可以为每个实体创建一个特定的数据模型。数据有如下两类：
图 4：Dragon 模式描述了 HiveTable 和 Column 元数据之间的关系。它们还包含标准和可重用类型。
由于模型是灵活的，而且很容易随时间变化，所以我们将元数据表示为一组属性和关系。由于以下不同的原因，Databook 使用 MySQL 作为持久存储：
将 MySQL 用作主要的持久化数据库有助于>
数据实体之间的关系很重要。我们需要捕捉这一点，以便深入了解与每个数据实体相关的元数据。我们可以回答诸如“仪表板如何与业务指标相关？”或者“管道如何转换数据集？”，数据用户想知道数据实体之间是如何关联的等问题。用图来表示这些关系是一个很自然的做法。有了灵活的数据模型，就可以将数据实体之间的关系转换为如下图所示的图：
图 5：通过将一个 HiveTable 节点连接到多个 Column 节点来表示 HiveTable 与 Column 的关系。
拥有一个能够支持来自不同元数据源的各种数据实体的数据模型，可以为元数据管理提供强有力的支持。
元数据源
有关数据实体的信息存在于 Uber 的许多系统中。这些系统是>
数据实体上的元数据源因数据存储系统和其他微服务而异。爬虫程序定期对每个系统进行扫描以获取信息，并将数据提取到>
图 6：Databook 提取来自不同数据系统的元数据源
Databook 从各种源获取元数据，从而提供 Uber 数据生态系统的中心视图。元数据源包括 OLTP 和 OLAP 数据库，以及仪表板和机器学习功能等其他服务中的数据实体。为了根据元数据源的数量进行扩展，我们对提取过程和 top="6502">数据提取 API
Uber 的许多团队和组织都拥有元数据源。对于集成>
Databook 提供了一个简单的过程来获取数据实体上的元数据。通过元数据提取，元数据将元数据推送到 Kafaka 主题，然后从>
图 7：使用>
Databook 以一种简化的方式提取元数据，而且不容易出错。一旦 top="6921">事件日志
一旦>
图 8：当>
利用面向日志的架构，我们实现了以下功能：
元数据事件日志为 top="7460">搜索和发现
通过元数据事件日志，Databook 支持对数据实体的搜索和发现，可以近实时反映变化。Databook 收集数据实体的元数据，比如数据集、业务指标、仪表板、管道等等。因此，Databook 支持在其他数据产品中进行发现，例如：
由于有数以百万计的数据实体，用户需要知道他们正在寻找一个合适的搜索和发现平台。
在 ElasticSearch 中，通过使用元数据事件日志中的事件来构建搜索索引。这保证了用户搜索结果中的所有更改都是近实时的。在这种方法中，利用了面向日志的架构。这样做有一些好处，例如从日志的任何时间点重建搜索索引，并且只有在发生更改时才有效地进行更新。
图 9：搜索引擎是根据元数据事件日志构建的。这支持实时搜索体验
搜索和发现帮助 top="8089">Databook 2.0 架构的优点
在将新的>
此外，其他内部 Uber 工具使用>
有了 top="8429">数据关系通过>
Databook 底层技术的改进使我们能够为用户提供更丰富的数据发现体验。它还帮助我们忠于将数据转化为知识的使命。
Databook 提供了两种发现数据的主要方式：
在前几节中所讨论的 API 为公司提供了对其他数据工具的支持。这将为用户提供时间点信息和见解，例如，通过查询引擎、工作流编排系统等等。基于 Web 的用户界面仍然是与 top="8803">动机
在重新设计了>
我们希望确保用户界面与后端的改进相匹配，并且易于修改和升级。因此重新设计了前端，使用模块化的标准组件，所有其他团队在 Uber 上使用的组件。这个前端是使用Base Web 组件构建的。这有助于通过重用先前由 Uber 其他团队构建的现有用户界面组件快速开发。这些工具与服务器建立接口，以便进行有效地检索数据。
在决定重建>
根据这些基本原则，我们开始进行用户研究。完成将数据转化为知识的使命，我们希望确定如何重构用户界面。Databook 的主要功能是数据发现。
在此之前，我们只处理数据集，而现在范围已经扩展到包括业务指标、仪表板、管道等等。新架构允许收集关于每个数据实体的额外元数据，并识别它们之间的趋势和关系。最后，我们对数据质量监控和异常检测进行了投资。这是客户说他们关心的领域。有了这些信息，我们围绕这几个方面设计了>
下面，我们将描述是如何实现这些方面的，并说明更新后的体验是什么样的。
发现
用户频繁使用>
从用户研究和用户模式分析中，发现有 75% 的用户会定期返回>
为了让>
图 10：主页显示了热门和推荐的数据实体
Databook 聚合了每个数据实体的元数据。这可以包括所有权细节、描述、使用统计信息、质量信息等等。为了提供多方面和多层面的搜索，我们在搜索方面投入了大量投资。这意味着用户可以输入一系列相关的术语，我们对这些术语进行解释，以提供一个相关结果的列表，这个列表是智能排序的。用户还可以使用过滤器来进一步缩小他们的搜索结果列表。
多年来，它改善了用户与我们的产品之间的日常交互。接下来，我们将重点帮助用户理解每个数据资产，而不需要使用多种工具或者依赖于错误或不足的资源。
理解
第一步是帮助用户找到所需的内容，但是我们也想帮助他们理解关于数据实体的关键细节。我们对>
当重新设计>
图 11：用户可以获得数据集质量信号的相信信息。他们可以看到我们如何衡量质量的各个组成部分，以及它们在过去七天的表现如何。
从主页到每个数据资产的各个详细信息页面，用户界面都包含了这些新元素，用户不再被这些信号所淹没。他们可以依靠 top="10882">管理
在构建>
随着在>
图 12：数据所有者可以在单一界面中编辑元数据并审查所有数据实体的未解决问题
数据实体所有者拥有其所有实体的单一视图。这有助于它们轻松地可视化资产质量、编辑元数据以及查看和响应用户问题。用户可以直接想数据实体所有者报告问题或提出问题。通过与现有的票务系统集成，我们为任何问题提供了可问责性、可跟踪性和可透明。在幕后，我们会删除重复的问题，并将它们发送到适当的团队的待命人员。
通过围绕这三个方面的设计过程，我们为 Uber 建立了一个世界级的数据目录，它将随着 Uber 的发展而不断发展壮大。
未来计划
当前的>
随着索引工具的发展，索引的数据种类也在不断增加，它的成功不仅仅在于对数据的访问，还在于从数据中获取见解。随着我们最近添加的数据，Uber 的数据更容易被发现和使用。这提高了工程师、数据科学家、数据分析师和机器学习研究人员的生产力。
我们的工作远未完成。今年，我们正在应对一些根本性的挑战：
这些只是我们对>
作者介绍：
Sunheng Taing，Uber 元数据平台团队高级软件工程师，热衷于构建可扩展、可靠和高质量的数据系统。
Atul Gupte，Uber 产品平台团队的前产品经理。在 Uber，他推动产品决策，以确保数据科学团队能够充分发挥潜力，为 Uber 的全球业务提供基础设施和先进软件。
原文链接：
