Uber数据可视化实践

在全球 1 万多个城市，每天都有数百万人依靠 Uber 出行、订餐和运送货物。我们的应用在超过 69 个国家和地区提供 24 小时的服务。从全球范围来看，这些活动生成了大量的日志记录和操作数据，这些数据可以在我们的系统中实时运行。其中包括有关消费者需求、司机伙伴可用性以及其他运营任务（如支付、通知等）的信息。运营像我们这样复杂的市场，需要工程师、数据科学家、数据分析师和运营经理根据平台上观察到的趋势作出实时业务决策。

为了帮助团队轻松发现并更好地理解这些数据，我们构建了 Databook。这是 Uber 的内部平台，用于显示和管理与各种数据实体相关的元数据，如数据集、内部仪表板、业务指标等。

随着 Uber 的扩张，我们的系统在技术上变得越来越复杂，数据系统的广度也成倍增长。同样，团队的需求也变得更加复杂，因为他们现在更多地依靠数据集、仪表板和业务指标来制定全球范围的业务决策。

Databook 无法通过扩展来满足这些新的需求，这促使我们重新思考我们的假设，并重建我们的工具，以更好地支持用户和他们不断变化的需求。在本文中，我们阐述了如何改进简化数据发现和流畅性的方法，以及我们从中吸取的经验教训。

Databook 的演变

我们最初于 2016 年推出 Databook，当时 Uber 的数据分布和复杂程度都要小得多。这足以维护一组静态 HTML 文件，我们定期手动更新这些文件。这些文件只是列出了 Uber 数据集的内部位置和所有者。

随着数据存储规模不断扩大，团队开始对数据进行分类。他们还收集了有关如何生成数据，哪些管道将数据加载到数据存储系统，数据集的简要描述和每个表中的列的元数据。所有这些关于我们业务的元数据帮助人们发现并理解数据本身。所以它加速了我们将见解应用到决策中，并可以改进 Uber 的产品。因此，在 2017 年，我们推出了第一个版本的 Databook，它通过以一个响应迅速且易于导航的用户界面来满足这些即时需求。

图 1：2017 年推出的 Databook

从那时起，Uber 将业务扩展到全球数百个城市，并将其服务范围扩大到送餐、货运、自动驾驶车辆和其他业务等领域。无论是从数据量还是从系统复杂性来看，这都极大地改变了 Uber 的数据格局。

工程师、数据科学家、数据分析师和运营经理都在努力跟上时代的步伐，并定期转向 Databook，这是每次探索数据的第一步。而我们所设想的用于搜索数据集、显示描述和所有者的基本系统，已经不能满足需要了。

通过对使用模式的分析和广泛的用户研究后，我们了解到 Databook 的用户希望了解相关的数据资产以及数据本身。例如，许多人想知道哪些管道将数据加载到哪些表中，我们从这些表格中获得了哪些业务指标，以及哪些仪表板显示了这些指标。团队还想了解数据实体的其他方面，比如它的质量，我们使用它的频率，以及是否可以在机器学习等高影响力的应用中随时使用它。

在 Databook 的基础上满足这些新的需求变得越来越困难了。在考虑对实体类型而不仅仅是数据集的支持时，我们认识到现有的技术正在拖累我们。这迫使我们建立一个劣质的解决方案，不能满足用户的需求。有鉴于此，我们重新思考了元数据管理和发现的方法，并重新设计了 Databook。

该行业也在努力提高数据科学家和数据分析师的生产力，利用元数据来推动数据洞察力。其他拥有大型和分布式数据集的公司也面临着类似的挑战，并结合其独特的业务需求和技术，建立了创新的数据目录来解决类似的问题。例如 Airbnb 的 Dataportal、Netflix 的 Metacat、Linkedin 的 Datahub、Lyft 的 Amundsen 和 Spotify 的 Lexikon 等。

重建 Databook 架构的原则

经过多年 Databook 的运行，我们了解到客户的需求和期望。后端服务限制了我们快速有效地包含非数据集（如业务指标和仪表板）的元数据的能力。

通过与团队合作，我们确定了一些指导原则，这些原则是重新设计和重新架构的基础。

• 元数据的意义很重要

随着数据实体种类的增加，由于缺乏适当的文档和所有权，我们失去了向 Databook 添加元数据的目的。为了提供有意义的、结构化的和管理良好的元数据，我们通过使用模式生成工具 Dragon 的数据标准化过程建立了元数据管理。它建立了元数据的标准词汇表，促进了 Uber 所有元数据类型的一致性和可重用性。

• 真正可扩展的数据模型

最初的 Databook 侧重于数据集，数据模型存储了专门与数据集相关联的元数据。强迫所有的数据实体都适合于单一的模型，这带来了挑战，使我们无法以一种清晰易懂的方式来表示元数据。例如，Dataset 实体在表的列上具有元数据，但 Dashboard 实体没有列。有了更加灵活和可扩展的数据模型，我们就可以用其特定的元数据来定义每个数据实体，而不必根据预定义数据模型进行调整。

• 集中式与分散式元数据系统的比较

我们在多个系统中传播元数据。在统一元数据系统的前期尝试中，Databook 直接向这些系统发送请求，以获取外部元数据，而这些数据并没有存储在自己的存储中。

当我们开始构建搜索和发现基础设施时，还需要索引这个外部元数据。此外，不同元数据系统的数量增加了，它们的用例也相似。也就是说，要在数据实体上存储元数据。

依赖不同的元数据系统会导致视图不集中，工作重复。集中化的元数据存储为数据实体上的元数据创建了一个统一的位置。这样，其他服务就不会重复创建用于相同目的的元数据存储。在缺乏有效的集中式元数据管理系统的情况下，我们也可能会错误地处理数据，使其变得不可信、不可发现。

• 关注用户体验

我们鼓励用户从用户界面到后端 API 来探索元数据系统并强调了开发和使用 API 的重要性。对于生成元数据的团队，我们已经实现了提供和接收不同数据实体的过程的标准化。这提高了添加各种元数据的效率。现在，通过 Databook 用户界面或 API，元数据使用者可以发现元数据。对用户体验的关注使得元数据生产者和使用者的工作变得简单而方便。

• 数据实体之间关系的重要性

Uber 中数据流的许多方式之一是通过 Hadoop 数据提取 从 Kafaka 主题到 Hive 表。在数据集实体的原始 Databook 中，我们捕获了数据集之间的这种关系。这提供了对数据集当前状态以及数据来源的深刻见解。

随着数据实体种类的增加，不同数据实体之间的关系变得更加复杂。这包括依赖于多个数据集和具有不同业务指标的仪表板的机器学习功能。

图数据结构是表示这些关系的最自然的方式。数据实体的知识图谱具有很好的灵活性和可扩展性。它通过使我们的系统能够捕获这些数据实体之间的关系来做到这一点。它也回答了关于最重要的元数据关系的问题，这些问题在以前是具有挑战性的，甚至是不可能的。

图 2：数据实体有许多连接。每个实体之间至少有一种关系

上图显示了 Databook 中捕获的多种数据实体，并且这个数字还在持续增长。一个仪表板可以依赖于多个数据集，而一个报表可能有多个要查询的业务指标。团队可以管理或拥有各种数据实体，比如数据集、业务指标、仪表板、管道等等。

这些指导原则是基于我们在管理元数据方面的经验，阐述了 Databook 的核心价值。这些指导原则影响了我们在新的 Databook 架构中的设计决策，该架构是可展开的、可靠的、可扩展的，以满足 Uber 大数据系统的需求。

Databook 架构

根据这些原则，Databook 架构需要：

• 受控元数据词汇表，
• 真正可扩展的数据模型，可以获取各种元数据和元数据关系，
• 良好的用户体验。

此外，我们必须支持查询各种数据实体的元数据的不同需求。

Databook 组件

为了支持数据服务和产品的数据发现，Databook 从数据存储系统和服务中提取了数百万个数据实体。Databook 的设计和架构是解决大数据生态系统中元数据量和满足用户需求的关键。

图 3：Databook 架构从各种来源提取元数据。随后向派生存储和服务基于的事件日志发出更改。

Databook 由几个组件组成：

• 元数据源：关于数据实体的元数据。Databook 可从各种源获得。其中包括 Hive 和 Cassandra 等数据存储系统，以及服务、日志等等。
• 元数据提取：将元数据从各种源提取到 Databook 的过程。
• API：用于元数据检索和通过图形引擎修改数据。这还将捕获元数据事件日志中的更改。
• 持久存储：包含所有数据实体和关系的完整记录。
• 元数据事件日志：Databook 中的所有更改都位于时间日志中。使用事件来构建派生存储。这适合其他用例，如搜索和缓存。在其他情况下，其他服务会订阅这些更改。然后他们构建事件驱动的系统来满足其需求，比如通知或触发工作流。
• 派生存储：能够有效地支持不同数据用例和需求的存储器。团队可以从元数据事件日志构建和重建工具。此外，还可以扩展 databookapi，直接从这些派生源检索元数据。

Databook 是一种数据密集型的应用，可以在 Uber 中捕获大量不同的元数据。有不同的数据存储来处理不同的用例。单系统数据存储，能够有效地处理所有访问模式和需求是不切实际的。原因在于不同的数据存储系统都有其特定的目标，从低延迟的数据检索到灵活的数据分析。

Databook 支持我们想要实现的目标，从提取各种数据实体的灵活性到支持驱动其他数据产品的健壮的数据发现。接下来，我们将研究数据建模如何帮助实现这些目标。

数据模型

拥有一个灵活的模型可以帮助我们处理在 Uber 中收集到的不同类型的实体。例如，在 Dataset 实体和 Metric 实体之间，存在常见的和不常见的元数据。因此，不能强制 Metric 拥有与 Dataset 相同的数据模型。

可扩展性是 Databook 的核心，它有助于快速有效地添加新的元数据。通过标准的数据实体加载流程，我们都可以提供可重用的且可理解的元数据。

为了注册新的数据实体或更新现有数据实体的模型，我们使用名为 Dragon 的数据模型转换工具。这有助于为每个实体类型定义数据模式。领域专家可以提交定义，Databook 在中央专家委员会批准所提议的模式后生成数据模型。

除了数据模型之外，我们还在 Uber 上分享了相应的 Thrift、Protobuf 和 Avro。这就提供了一个一致且可重用的元数据托管词汇表。我们还将检查此架构中的所有更新，并确保它们是向后兼容的。

基于某人定义的元数据类型，Databook 创建了灵活的数据模型。有了 Dragon 模式，可以为每个实体创建一个特定的数据模型。数据有如下两类：

• 实体类型：这些是具有唯一标识字段的记录类型。在 Databook 中，我们将具有 ID 字段的所有记录类型视为一个实体。Dataset、HiveTable 和 Dashboard 都是实体类型的示例。
• 值类型：这些类型保持了一致性和可重用性。实体类型可以重用现有的值类型。TableName、DataCenterRegion 和 ColumnType 是值类型的示例。

图 4：Dragon 模式描述了 HiveTable 和 Column 元数据之间的关系。它们还包含标准和可重用类型。

由于模型是灵活的，而且很容易随时间变化，所以我们将元数据表示为一组属性和关系。由于以下不同的原因，Databook 使用 MySQL 作为持久存储：

• 灵活且可扩展的模型：将数据存储为无模式的 JSON 集合，该集合随着新的元数据不断发展。它还支持索引、事务、引用完整性和其他 MySQL 特性。
• 高可用性：可以通过复制和主动 / 主动设置跨地理区域访问数据。
• 为人所熟：
  • SQL 是标准的，并且大多数人都熟悉它的用法。这使得工程师更容易贡献、调试和测试。
  • 可以从外部论坛和内部专家那里获得许多资源和帮助，例如专门支持 MySQL 的团队。
  • 许多 MySQL 的开源工具，比如数据可视化工具，可以降低查询分析的速度。
• 成熟：MySQL 已经被证明可以大规模运行多年。

将 MySQL 用作主要的持久化数据库有助于 Databook 以可扩展和可靠的方式支持各种实体类型。它还有助于获得内部和外部社区的支持。

数据实体之间的关系很重要。我们需要捕捉这一点，以便深入了解与每个数据实体相关的元数据。我们可以回答诸如“仪表板如何与业务指标相关？”或者“管道如何转换数据集？”，数据用户想知道数据实体之间是如何关联的等问题。用图来表示这些关系是一个很自然的做法。有了灵活的数据模型，就可以将数据实体之间的关系转换为如下图所示的图：

图 5：通过将一个 HiveTable 节点连接到多个 Column 节点来表示 HiveTable 与 Column 的关系。

拥有一个能够支持来自不同元数据源的各种数据实体的数据模型，可以为元数据管理提供强有力的支持。

元数据源

有关数据实体的信息存在于 Uber 的许多系统中。这些系统是 Databook 可以收集、索引和用于发现的元数据源。由于来自多个元数据源的不同数据实体，所以 Databook 需要一个灵活的数据模型来有效地处理各种用例。

数据实体上的元数据源因数据存储系统和其他微服务而异。爬虫程序定期对每个系统进行扫描以获取信息，并将数据提取到 Databook 中。这包括索引 Cassandra 表和收集数据集级别的统计信息。还有基于事件的数据源，例如数据新鲜度和质量检查。每个源都要求 Databook 有一个健壮的接口。

图 6：Databook 提取来自不同数据系统的元数据源

Databook 从各种源获取元数据，从而提供 Uber 数据生态系统的中心视图。元数据源包括 OLTP 和 OLAP 数据库，以及仪表板和机器学习功能等其他服务中的数据实体。为了根据元数据源的数量进行扩展，我们对提取过程和 databookapi 进行了标准化。

数据提取 API

Uber 的许多团队和组织都拥有元数据源。对于集成 Databook 和进行数据发现，我们的同事有不同的需求和用例。

Databook 提供了一个简单的过程来获取数据实体上的元数据。通过元数据提取，元数据将元数据推送到 Kafaka 主题，然后从 Databook 中对其进行处理。虽然根据紧急情况和需要，API 也可以进行同步写操作，比如在用户界面中显示更新，但我们建议采用提取过程。

图 7：使用 databookapi，元数据提取和其他服务将元数据存储在数据实体上

Databook 以一种简化的方式提取元数据，而且不容易出错。一旦 Databook 获取了元数据，它就会详细描述变更的信息推送到元数据事件日志中，以审核并满足其他重要需求。

事件日志

一旦 Databook 提取了元数据，我们就会向 Kafaka 的元数据事件日志中添加所有的更改。事件日志以顺序的方式记录应用程序中的所有元数据更改，从而使其易于使用。

图 8：当 databookapi 成功处理更改时，我们将事件推送到日志中

利用面向日志的架构，我们实现了以下功能：

• 支持不同的查询需求。更改日志帮助我们为特定用例构建额外的存储。这包括对时间序列数据的基于图形的分析，因为任何存储系统都不能有效地支持每种查询模式。
• 重建存储。如果存储系统出现问题，我们可以通过事件日志重建存储系统，或者从某个时间点重新应用更改。
• 支持时间驱动的架构。微服务可以依靠事件日志来触发任务，如通知系统、触发数据质量检查等。
• 审核更改。当前时间点中的数据可能不够。我们可能需要确定某个数据实体是如何达到其当前状态的。

元数据事件日志为 Databook 活动提供了必要的信息。它还提供了扩展性，以满足集中式元数据管理系统对数据发现的众多需求。

搜索和发现

通过元数据事件日志，Databook 支持对数据实体的搜索和发现，可以近实时反映变化。Databook 收集数据实体的元数据，比如数据集、业务指标、仪表板、管道等等。因此，Databook 支持在其他数据产品中进行发现，例如：

• Databook 用户界面，
• 为 Uber 数据库提供前端功能的内部功能，如 Querybuilder，以及
• 最先进的可视化工具，如 Dashbuilder 等。

由于有数以百万计的数据实体，用户需要知道他们正在寻找一个合适的搜索和发现平台。

在 ElasticSearch 中，通过使用元数据事件日志中的事件来构建搜索索引。这保证了用户搜索结果中的所有更改都是近实时的。在这种方法中，利用了面向日志的架构。这样做有一些好处，例如从日志的任何时间点重建搜索索引，并且只有在发生更改时才有效地进行更新。

图 9：搜索引擎是根据元数据事件日志构建的。这支持实时搜索体验

搜索和发现帮助 Databook 的用户找到相关的数据实体，减少了寻找正确资源所花费的时间。Databook 架构满足了用户的需求，并提高了他们的日常工作效率。

Databook 2.0 架构的优点

在将新的 Databook 投入生产 18 个月后，我们看到了用户通过使用该服务来管理元数据并进行发现的出色结果。该解决方案涉及到数十万个数据集、数百万个列 / 字段以及数十万个其他数据实体，如仪表板和管道。

此外，其他内部 Uber 工具使用 Databook 的元数据进行数据发现并增强其产品。有了新的 Databook，就可以在一个小时内迅速建立新的实体。在过去，实现和测试新实体需要数周时间。加载体验现在变得更简单了，我们对最终用户的正确性充满了信心。

有了 Databook 架构，我们拥有一个真正可展开、可扩展且可靠的元数据管理平台。我们在大数据生态系统中提取了数以百万计的数据实体，并支持在 Uber 的数据产品中进行搜索和发现。拥有一个可扩展的后端使我们能够重新考虑 Databook 的用户界面。这将进一步改善用户在数据发现和见解方面的旅程。

数据关系通过 Databook 的用户界面实现可视化

Databook 底层技术的改进使我们能够为用户提供更丰富的数据发现体验。它还帮助我们忠于将数据转化为知识的使命。

Databook 提供了两种发现数据的主要方式：

• RPC 和 GraphQL API，以及
• 通过基于 Web 的用户界面。

在前几节中所讨论的 API 为公司提供了对其他数据工具的支持。这将为用户提供时间点信息和见解，例如，通过查询引擎、工作流编排系统等等。基于 Web 的用户界面仍然是与 Databook 交互的主要方式，每周都有成千上万的用户使用它进行数据发现。

动机

在重新设计了 Databook 的技术架构之后，我们将重点放在理解这些改进在用户界面中如何体现出来。从 2017 年推出的用户界面帮助了团队发现数据集。但是，它的可扩展性并不强，用户很难发现其他数据实体，如指标、仪表板和管道等等。我们以前用来构建它的前端组件不再受支持。它们在维护、升级和修改方面都很麻烦。

我们希望确保用户界面与后端的改进相匹配，并且易于修改和升级。因此重新设计了前端，使用模块化的标准组件，所有其他团队在 Uber 上使用的组件。这个前端是使用 Uber React Base Web 组件构建的。这有助于通过重用先前由 Uber 其他团队构建的现有用户界面组件快速开发。这些工具与 GraphQL 服务器建立接口，以便进行有效地检索数据。

在决定重建 Databook 的 Web 用户界面之后，我们提出了一些指导原则：

1. 通过 API 和 Web 用户界面继续访问系统中的元数据。
2. API 将与用户界面一样强大，甚至更强大。建议团队集成该 API，以在自己的产品中展示丰富的元数据驱动的见解。
3. Databook 的用户界面专注于展示大多数用户认为有用的见解。监控 API 的使用情况，以确定新的特性，从而在 Databook 用户界面中为更广泛的用户提供。

根据这些基本原则，我们开始进行用户研究。完成将数据转化为知识的使命，我们希望确定如何重构用户界面。Databook 的主要功能是数据发现。

在此之前，我们只处理数据集，而现在范围已经扩展到包括业务指标、仪表板、管道等等。新架构允许收集关于每个数据实体的额外元数据，并识别它们之间的趋势和关系。最后，我们对数据质量监控和异常检测进行了投资。这是客户说他们关心的领域。有了这些信息，我们围绕这几个方面设计了 Databook 的体验：

• 发现：给用户一个强大的搜索体验，帮助他们执行复杂的、多方面的搜索，有足够的过滤器快速筛选结果。添加对数据实体的支持，比如仪表板、业务指标、机器学习功能等等。这确保了 Databook 成为 Uber 的唯一搜索目的地。
• 理解：增加关于数据实体的信号数量，但是也要确保用户能够跳过细节。帮助用户综合推荐，同时他们仍然可以选择查看细节。
• 管理：随着数据量的增长，管理一小组数据实体已经不再可能。在向存储库中添加新的数据实体时，需要一种方法来大量获取有用的信息，如描述。而且，还需要创造者可以组织这些信息的方法。

下面，我们将描述是如何实现这些方面的，并说明更新后的体验是什么样的。

发现

用户频繁使用 Databook 的主要原因是数据发现。经过这次重新设计，想要使对数据实体的搜索和发现变得更加容易。这包括数据集、指标、仪表板、管道和机器学习功能。

从用户研究和用户模式分析中，发现有 75% 的用户会定期返回 Databook 来查看相当少量的一组数据实体。这些通常是针对其工作的组织的一部分，或是针对整个公司的流行数据实体。

为了让 Databook 用户界面更加直观，引入了精选数据实体。其中包括公司的热门实体或某个组织的推荐实体。还根据用户的使用模式自动向他们推荐数据实体，他们也可以将这些实体添加到书签中以便快速访问。

图 10：主页显示了热门和推荐的数据实体

Databook 聚合了每个数据实体的元数据。这可以包括所有权细节、描述、使用统计信息、质量信息等等。为了提供多方面和多层面的搜索，我们在搜索方面投入了大量投资。这意味着用户可以输入一系列相关的术语，我们对这些术语进行解释，以提供一个相关结果的列表，这个列表是智能排序的。用户还可以使用过滤器来进一步缩小他们的搜索结果列表。

多年来，它改善了用户与我们的产品之间的日常交互。接下来，我们将重点帮助用户理解每个数据资产，而不需要使用多种工具或者依赖于错误或不足的资源。

理解

第一步是帮助用户找到所需的内容，但是我们也想帮助他们理解关于数据实体的关键细节。我们对 Databook 的架构进行了重构，以便它能够收集更多关于数据实体的信号。这包括实体之间的关系、与实体相关的数据质量、使用统计信息、示例、所有权和描述，以及使用它们时有关数据隐私影响的信息。

当重新设计 Databook 用户界面时，确定了哪些信号是最重要的，以及如何最好地显示出这些信息。为了服务于广大的用户群，我们现在提供可操作的建议一目了然，同时用户可以很容易地找到细节。我们以几种不同的方式介绍了这些功能：

• 对每个数据实体，通过一系列基本的检查来显示数据质量，并使用红绿灯指示器显示。用户只需依赖指示器的颜色来显示资产是否可用，是否异常或不安全。还提供了从每个数据质量测试中捕获的数据。
• 显示数据资产的趋势，例如使用情况。还通过趋势线显示了它所包含的数据的特征，如最小值、最大值、平均值、中值和空值比率。

图 11：用户可以获得数据集质量信号的相信信息。他们可以看到我们如何衡量质量的各个组成部分，以及它们在过去七天的表现如何。

从主页到每个数据资产的各个详细信息页面，用户界面都包含了这些新元素，用户不再被这些信号所淹没。他们可以依靠 Databook 来作出明智的决定。

管理

在构建 Databook 时，我们决定使用知识库模型，而不是基于 Wiki 的模型。这样做是为了保证拥有数据实体的人能够验证他们的信息。这还意味着从元数据中收集到的信号是可靠的。

随着在 Databook 中扩展数据实体的种类，并发现了更多关于这些实体的信号，我们希望让人们更容易地管理这些实体。我们还希望确保用户能够轻松地与所有者沟通、提出问题并提供反馈。

图 12：数据所有者可以在单一界面中编辑元数据并审查所有数据实体的未解决问题

数据实体所有者拥有其所有实体的单一视图。这有助于它们轻松地可视化资产质量、编辑元数据以及查看和响应用户问题。用户可以直接想数据实体所有者报告问题或提出问题。通过与现有的票务系统集成，我们为任何问题提供了可问责性、可跟踪性和可透明。在幕后，我们会删除重复的问题，并将它们发送到适当的团队的待命人员。

通过围绕这三个方面的设计过程，我们为 Uber 建立了一个世界级的数据目录，它将随着 Uber 的发展而不断发展壮大。

未来计划

当前的 Databook 版本包括一个改进的、模块化的用户界面前端，以及一个灵活的见解生成架构后端。这是最近的一次尝试，通过可操作的见解使 Uber 的数据变得更有用。每周，成千上万的工程师、数据科学家、数据分析师和运营经理都会向我们求助，以进行搜索、发现和执行各种操作。他们使用它来理解 Uber 的元数据图，其中包含数百万个数据实体，例如数据集、指标、仪表板、机器学习功能等。

随着索引工具的发展，索引的数据种类也在不断增加，它的成功不仅仅在于对数据的访问，还在于从数据中获取见解。随着我们最近添加的数据，Uber 的数据更容易被发现和使用。这提高了工程师、数据科学家、数据分析师和机器学习研究人员的生产力。

我们的工作远未完成。今年，我们正在应对一些根本性的挑战：

• 围绕元数据构建智能；
• 为用户提供个性化的体验；
• 扩展知识图谱

这些只是我们对 Databook 所做的一些有影响力的补充。通过支持大规模发现、探索和知识的特性，我们将继续扩展它的功能。

作者介绍：

Sunheng Taing，Uber 元数据平台团队高级软件工程师，热衷于构建可扩展、可靠和高质量的数据系统。

Atul Gupte，Uber 产品平台团队的前产品经理。在 Uber，他推动产品决策，以确保数据科学团队能够充分发挥潜力，为 Uber 的全球业务提供基础设施和先进软件。

原文链接：

https://eng.uber.com/metadata-insights-databook/