每天在世界各地超过10,000个城市，数百万人依靠优步旅行，订购食品和船舶货物。我们的应用程序和服务有超过69个国家，每天24小时运行。在我们的全球范围内，这些活动产生了大量的日志记录和运营数据，实时通过我们的系统运行。这包括有关消费者需求，驱动程序合作伙伴可用性和其他运营任务（如付款，通知等）的信息。经营诸如我们的复杂市场需要我们的工程师，数据科学家，数据分析师和运营管理人员根据我们平台上观察到的趋势来采用实时业务决策。

为了帮助我们的团队更容易地发现和理解这些数据，我们构建了数据库。这是Uber的内部平台，它曲面和管理与各种数据实体相关的元数据，如数据集，内部仪表板，业务度量等。

随着优步扩大，我们的系统变得更加复杂，我们的数据系统的广度呈指数增长。同样，我们的团队的需求也变得更加复杂，因为他们现在在数据集，仪表板和商业指标上依赖于，以制定全球规模的业务决策。

DataBook无法扩展以满足这些新需求，提示我们重新思考我们的假设并重建我们的工具，以更好地支持我们的用户及其不断发展的需求。在这里，我们描述了我们如何发展我们的方法来简化数据发现和流利程度，以及我们在方式学到的教训。

数据谱的演变

我们最初于2016年推出了DataBook，当优步的数据不那么分布式和复杂。它足以维护一组静态HTML文件，我们以定期更新，我们手动更新。这些文件只是列出了优步的数据集的内部位置和所有者。

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

从那时起，优步扩展到世界各地的数百个城市，并将其产品增长，包括食品交付，货物运输，自驾驶车辆和其他业务单位。就体积和系统复杂性而言，这显着改变了我们的数据景观。

我们的工程师，数据科学家，数据分析师和运营管理人员努力跟上并定期转向DataBook，这是我们对数据探索的第一步。我们设想的是，即搜索数据集和浮出语描述和所有者的基本系统不再足够了。

在我们分析了使用模式并进行了广泛的用户研究之后，我们发现Databook的用户不仅希望了解数据本身，还希望了解相关的数据资产雷竞技是骗人的。例如，许多人想知道哪些管道将数据加载到哪些表中，我们从这些表派生出哪些业务指标，以及哪些仪表板显示这些指标。团队还想了解数据实体的其他方面，比如它的质量、我们使用它的频率，以及我们是否可以在机器学习等具有高影响力的应用中随时使用它。

建立在Databook上以满足这些新需求变得越来越困难。当我们考虑对实体类型而不仅仅是数据集的支持时，我们意识到我们现有的技术正在减慢我们的速度。它迫使我们构建一个不满足用户需求的劣质解决方案。考虑到这一点，我们重新思考了元数据管理和发现的方法，并从头开始重新设计了Databook。

该行业还致力于提高数据科学家和数据分析师的生产力，使元数据能够为电力数据见解。具有大型和分布式数据集的其他公司面临着类似的挑战，并建立了创新的数据目录，在其独特的业务需求和技术的背景下解决类似的问题。例子包括Airbnb的DataPortal.，netflixMetacat.Linkedin的datahub., LyftAmundsen., Spotify的lexikon.等等。

重建Databook架构的原则

多年来跑步多年来，我们了解客户的需求和期望。后端服务限制了我们快速有效地包括非数据集的元数据，例如业务指标和仪表板。

通过与我们的团队合作，我们定义了我们重新设计和重新建筑的基础指导原则：

• 元数据的含义很重要

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

• 真正可扩展的数据模型

原始Databook专注于数据集和数据模型存储的元数据，与数据集相关联。迫使所有数据实体符合一个挑战的单一模型，并阻止我们以明确和理解的方式表达元数据。例如，DataSet实体在表的列上具有元数据，但仪表板实体没有列。通过具有更灵活和可扩展的数据模型，我们可以利用其特定元数据定义每个数据实体，而不是必须适合于预定义的数据模型。

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

我们在多个系统中传播元数据。在先前的尝试统一元数据系统时，DataBook将请求直接发送给这些系统，用于外部元数据，它没有存储在它自己的存储中。

正如我们开始构建搜索和发现基础架构，我们也需要索引此外部元数据。此外，不同元数据系统的数量增加，它们的用例相似。即，我们希望在数据实体上存储元数据。

依赖不同的元数据系统会导致没有集中的视图和重复的工作。集中式元数据存储为数据实体上的元数据创建了一个统一的位置。因此，其他服务不再重复创建相同目的的元数据存储。如果没有一个有效的集中元数据管理系统，我们也可能错误地处理数据，它将变得不可信和无法被发现。

• 专注于用户体验

从UI到后端API，我们鼓励用户探索我们的元数据系统。我们强调了使我们的API探险和易于使用的重要性。对于生产元数据的团队，我们已经标准化了贡献和摄取不同数据实体的过程。这增加了添加各种元数据的效率。现在，我们的元数据消费者可以通过DataBook UI或API发现元数据。专注于用户体验使得元数据生产者和消费者的努力简单方便。

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

Uber中的数据流量之一是从Kafka主题到蜂巢表Hadoop data摄入。在具有数据集实体的原始DataBook中，我们在数据集之间捕获了这种关系。这提供了对数据集如何在其当前状态以及数据来自哪里的见解。

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

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

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

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

DataBook架构

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

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

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

DataBook组件

为了为数据服务和产品进行数据发现，DataBook从数据存储系统和服务中摄取数百万数据实体。DataBook的设计和架构是解决大数据生态系统中元数据的音量并满足用户要求的关键。

DataBook有多个组件：

• 元数据来源—关于数据实体的元数据。Databook从不同的来源获得了这些信息。这包括数据存储系统，如Hive和Cassandra以及服务、日志等。
• 元数据摄取- 从各种来源到Databook的过程。
• API-用于通过图形引擎检索元数据和修改数据。这还可以捕获元数据事件日志中的更改。
• 持久存储- 包含所有数据实体和关系的完整记录。
• 元数据事件日志- DataBook中的所有更改都在事件日志中。我们使用事件来构建派生存储。这与搜索和缓存等其他用例相遇。在其他情况下，附加服务订阅了这些变化。然后，他们构建事件驱动的系统，以满足他们的要求，例如通知或触发工作流程。
• 派生的存储- 可以有效地支持不同的数据用例和要求的存储。团队可以从Metadata事件日志中构建和重建工具。此外，我们可以扩展DataBook API以直接从这些派生源检索元数据。

DataBook是一个数据密集型应用程序，遍布优步的大量各种元数据。我们有不同的数据存储来处理不同的用例。可以有效地处理所有访问模式和需求的单系统数据存储是不现实的。这是因为不同的数据存储系统地址的特定目标，从低延迟数据检索到灵活的数据分析。

Databook支持我们想要实现的目标，从吸收各种数据实体的灵活性到支持健壮的数据发现(为其他数据产品提供动力)。接下来，我们将看看数据建模如何帮助实现这些目标。

数据模型

拥有灵活的型号帮助我们解决我们在优步中收集的不同类型的实体。例如，在数据集实体和度量标准实体之间，存在常见和罕见的元数据。因此，我们不能强制指标与数据集具有相同的数据模型。

可扩展性在DataBook的核心，它可以帮助我们快速有效地添加新的元数据。使用标准数据实体onboard过程，我们可以为可重复使用和可理解的所有贡献元数据。

要注册新数据实体或更新现有数据实体的模型，我们使用调用的数据模型转换工具龙。这有助于我们为每个实体类型定义数据模式。域专家可以提交定义，并在专家中央委员会批准建议的架构后，DataBook生成数据模型。

除了数据模型之外，我们还在优步共享相应的节俭，protobuf和Avro。这提供了一致和可重复使用的元数据的托管词汇。我们还查看此架构中的所有更新，并确保它们是向后兼容的。

基于元数据类型某人定义，DataBook创建灵活的数据模型。鉴于Dragon Schema，我们可以为每个实体创建特定数据模型。我们有两类数据：

• 实体类型——这些是具有唯一标识字段的记录类型。在Databook中，我们将所有带有ID字段的记录类型视为实体。数据集、HiveTable和仪表板是实体类型的例子。
• 价值类型 - 这些保持定义一致和可重复使用。实体类型可以重用现有值类型。Tablename，DataCenterErgion和ColumentType是价值类型的示例。

我们将元数据表示为一组属性和关系，因为模型是灵活的，并且可以随时间轻松发展。DataBook使用MySQL作为持久存储，原因如下：

• 灵活且可扩展的型号 - 我们将数据存储为较少的模式JSON集合，以便使用新的元数据不断发展。它还支持索引，事务，参照完整性和其他MySQL功能。
• 高可用性——我们可以通过复制和活动/活动设置跨地理区域访问数据。
• 熟悉
  • SQL是标准的，大多数人都熟悉使用它。这使得工程师更容易进行贡献、调试和测试。
  • 我们可以从外部论坛和内部专家提供许多资源和帮助，例如我们的专用团队支持MySQL。
  • MySQL的许多开源工具，如数据可视化工具都降低了查询分析的速度。
• 成熟 - 经过证明MySQL在规模上运行多年。

使用MySQL作为主持久性数据库，可帮助Databook以可扩展可靠的方式支持各种实体类型。它还有助于支持内部和外部社区的支持。

数据实体之间的关系很重要。我们需要捕获这一点以导出与每个数据实体相关的元数据的见解。我们可以回答“与商业公制有关的仪表板是如何定义的问题？或者“管道如何转换数据集？”我们的数据用户希望了解数据实体如何彼此相关。具有表示这些关系的图形是采取的自然方向。通过我们的灵活数据模型，我们可以将数据实体之间的关系转换为如下所示的图形。

拥有一个可以支持来自不同元数据源的各种数据实体的数据模型，可以增强我们的元数据管理系统。

元数据来源

有关数据实体的信息在优步的许多系统上生活。这些系统是DataMook可以收集，索引和使用用于发现的元数据的源。使用来自许多元数据源的不同数据实体，DataBook需要一个灵活的数据模型，可以有效地处理各种用例。

数据实体上的元数据源从数据存储系统到其他微猎猎犬的数据。有爬网程序定期扫描每个系统以获取信息并将数据摄入数据型。这包括索引Cassandra表和收集数据集级别统计信息。我们还具有基于事件的来源，如数据新鲜度和质量检查。每个源都要求DataBook具有强大的界面。

DataBook获取来自各种源的元数据，以提供优步数据生态系统的中心视图。元数据来源范围从OLTP和OLAP数据库到其他服务中的数据实体，例如仪表板和机器学习功能。使用元数据源的数量缩放，我们标准化了摄入过程和DataBook API。

数据摄取API

元数据来源是优步的许多团队和组织。我们的同事有不同的需求和用例，可以与DataBook集成并进行数据发现。

DataBook提供了一个简单的过程，可在数据实体上摄取元数据。通过元数据摄入，元数据源将元数据推到Kafka主题，然后数据填充流程处理它们。我们建议摄入过程，虽然根据紧迫性和要求，但API也可以进行同步写入，例如在UI中显示更新。

DataBook以简化的方式摄取元数据，并且易于出错。一旦DataBook摄取元数据，它会推动详细信息，详细说明元数据事件日志的更改以审核和服务其他重要要求。

事件簿

一旦DataBook摄取元数据，我们将为Kafka的元数据事件日志添加所有更改。事件日志记录应用程序中的所有元数据，按顺序排列，这使其易于使用。

我们利用我们的日志架构来实现以下操作：

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

元数据事件日志为DataBook活动提供了基本信息。它还提供可扩展性，以满足集中式元数据管理系统进行数据发现的许多要求。

搜索和发现

使用Metadata事件日志，DataBook支持在数据实体上的搜索和发现，这些实体反映在近实时的变化。DataBook在数据集等数据实体上收集元数据，例如数据集，业务指标，仪表板，管道等。因此，DataBook支持在其他数据产品中的发现：

• 数据手册UI,
• 为优步数据库提供前端功能的内部工具，如Querybuilder和
• 最先进的可视化工具，如Dashbuilder等。

对于数以百万计的数据实体，用户需要通过一个合适的搜索和发现平台来知道他们在寻找什么。

我们通过从元数据事件日志中消耗事件来构建弹性电池中的搜索索引。这可确保用户搜索结果的所有变化都在近实时。在这种方法中，我们利用了面向对线的架构。这提供了从日志中的任何时间点重建搜索指数的好处，并且只有在发生变化时才有效更新。

搜索和发现帮助DataBook用户找到相关的数据实体，并降低寻找合适资源的时间。DataBook架构符合我们用户的需求，并在整个日常任务中提高其生产力。

Databook 2.0架构的好处

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

此外，其他内部优步工具使用DataBox的元数据进行数据发现，并增强其产品。使用新数据策略我们可以在不到一小时内快速滚动新实体。在过去，它需要多个星期的时间来实施和测试新实体。船上的体验现在更简单，我们对我们在为最终用户提供工作的正确性方面充满信心。

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

通过DataBook的UI可视化数据关系

DataBook下面的技术堆栈的进步使我们能够为用户提供更丰富的数据发现体验。它还有助于我们保持符合我们将数据转化为知识的使命。

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

• RPC和GraphQL API，或
• 通过基于Web的UI。

我们在前几节中讨论过的API支持公司的其他数据工具。这将通过查询引擎、工作流编排系统等向用户提供即时信息和见解。基于web的UI仍然是与Databook交互的主要方式，每周都有成千上万的用户使用它来发现数据。

动机

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

我们希望确保我们的ui与后端所做的改进相匹配，并且保持易于修改和升级。所以我们用模块化的标准组件重新设计了前端，所有其他团队都在使用这些组件。这个前端是用超级反应基本Web组件。这通过重用先前由Uber的其他团队建造的现有UI组件来帮助我们快速发展。这些工具与a接口GraphQL.服务器有效数据检索。

已经决定重建DataBook的网络UI，我们提出了一些指导原则：

1. 通过API和Web UI继续访问我们的系统中的元数据
2. API将与UI保持强大或更强大。我们建议团队与此API集成，以在自己的产品中呈现丰富的元数据驱动的洞察力
3. DataBook的UI专注于讲述大多数用户发现有用的洞察力。我们监控了API的使用，以确定新功能，以便在DataBook UI中提供更广泛的受众

通过这些创始原则，我们开始了我们的用户研究。雷竞技是骗人的我们希望确定我们如何重组我们的UI，以使我们转向知识的使命。DataBook的主要功能是数据发现。

以前，我们只处理数据集 - 现在我们的范围扩展到包括商业指标，仪表板，管道等。我们的新架构允许我们收集关于每个数据实体的其他元数据，并识别它们之间的趋势和关系。最后，我们投资于数据质量监测和异常检测。这是我们的客户所说的一个区域。有了这些信息，我们设计了这些支柱周围的数据键体验：

• 发现：为用户提供强大的搜索体验，有助于它们执行复杂的多面搜索，有足够的过滤器来快速筛选结果。为数据实体添加支持，如仪表板，业务指标，ML功能等。这确保了DataBook成为单个目的地搜索在优步。
• 理解:增加我们的数据实体的信号数量，但也确保用户可以跳过细节。帮助用户综合推荐，同时他们仍然可以选择查看细节。
• 管理：由于我们的数据卷增长，因此不再可能策划一小组数据实体。当我们向我们的存储库添加新数据实体时，我们需要一种方法来播放源有用信息，例如描述。我们还需要一种创造者可以组织这些信息的方式

下面，我们描述了我们如何接近这些支柱，并说明了刷新的经验看起来像什么。

发现

数据发现是用户频繁DataBook的主要原因。通过此重新设计，我们希望轻松搜索和发现数据实体。这包括数据集，指标，仪表板，管道和机器学习功能。

通过用户的研究和分析用户模雷竞技是骗人的式，我们意识到约75％的用户定期返回DataBook，以查看相当小的数据实体。这些通常是他们在整个公司工作或适用于整个公司的流行数据实体的组织的一部分。

为了使Databook UI更直观，我们引入了策划数据实体。其中包括公司中流行的实体或某个组织推荐的实体。我们还根据用户的使用模式自动向他们推荐数据实体，用户可以将这些数据添加到书签中，以便快速访问

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

这改善了我们的用户与我们产品的日常互动，这已经有好几年了。接下来，我们将重点放在帮助用户理解每个数据资产，而不必访问多个工具或依赖不准确或不足的资源。

理解

帮助用户找到他们正在寻找的是第一步，但我们希望帮助他们了解有关数据实体的关键细节。我们重新构建了DataBook的架构，以便它可以收集更多关于数据实体的信号。这包括实体之间的关系，与实体，使用统计数据，样本，所有权和描述相关的数据质量以及有关使用它们的数据隐私界面的信息。

当我们重新设计DataBook UI时，我们确定了哪个信号最重要，以及如何最好地过滤这些信息。为了满足我们广泛的用户群，我们现在提供可操作的建议，而用户可以轻松找到详细信息。我们以几种方式介绍了这些功能：

• 我们通过对每个数据实体的一系列基本检查显示数据质量，并将其与流量光指示器显示。用户只依赖于交通灯信号颜色，该颜色显示是否准备好使用，可能是异常或不安全的。我们还提供我们从每个数据质量测试捕获的数据。
• 我们展示了关于数据资产的趋势，例如使用。我们还显示了它包含的数据的特征，例如最小，最大，平均值，中位数和空比率是通过趋势线。

在UI中的这些新元素，从主页到每个数据资产的单个细节页面，用户不再被这些信号所淹没。他们可以依靠数据薄，以做出明智的决定。

管理

当我们构建Databook时，我们决定了一个知识库模型而不是基于Wiki的模型。我们这样做是这样，我们可以保证拥有数据实体的人验证了他们的信息。这也意味着我们从元数据收集的信号是可靠的。

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

数据实体所有者拥有所有实体的单个视图。这有助于它们轻松可视化资产质量，编辑元数据和查看并响应用户问题或问题。用户可以将问题报告或直接向数据实体所有者提出问题。通过与我们现有的票务系统集成，我们为任何问题提供问责制，可销售性和透明度。在幕后，我们重复递交问题并将其路由到适当的团队随访。

通过将我们的设计过程聚焦在三个主要的支柱周围，我们为优步构建了一个世界级数据目录，这将继续发展和使用优步生长。

未来的计划

当前版本的DataBook包括一个改进的模块化UI前端，以及灵活的洞察生成架构后端。我们的最新尝试通过可操作的见解更有用。每周，数千名工程师，数据科学家，数据分析师和运营经理转向我们，以便于搜索，发现和执行各种动作。它们使用它来绘制Uber的元数据图，其中包含数百万数据集，例如数据集，指标，仪表板，ML功能等。

随着该工具增长索引更广泛的数据，它的成功不仅仅在于仅访问数据，而且还没有开发数据的见解。通过我们最新的添加，优步的数据更容易被发现和有用。这促进了我们的工程师，数据科学家，数据分析师和机器学习研究人员的生产力。雷竞技是骗人的

我们的工作远非完整。今年，我们正在研究一些基本挑战：

• 在元数据周围建立智能
• 个性化用户体验
• 展开知识图

这些只是我们对数据薄的一些有影响力的补充。我们将继续通过尺度发现，探索和知识的功能来扩展其功能。

致谢

在过去的两年中，数个数据团队都很喜欢Databook。几位工程师、产品经理、工程负责人、用户体验设计师和技术写手合作，打造了一个真正服务于Uber客户需求的产品。通过这个博客，我们感谢所有雷竞技到底好不好用在元数据平台团队工作多年的人，感谢他们为Databook的持续成功做出的贡献。我们还想强调我们从优步数据部门得到的支持，因为它在帮助Databook简化数据发现过程中发挥了重要作用。