作者：MarsLan,SeyiAdebajo,ShirshankaDas
译者：DataPieplineyaran
一、扩展元数据
为提高LinkedIn数据团队的工作效率，我们之前开发并开源了WhereHows，一个中央元数据存储库和数据集门户。存储的元数据类型包括技术元数据（例如，位置、模式、分区、所有权）和过程元数据（例如，沿袭、作业执行、生命周期信息）。WhereHows还有一个搜索引擎，以帮助定位感兴趣的数据集。
2.通用比具体更好WhereHows对数据集或作业的元数据应该是什么样子有着强烈意见。这就导致出现固定的API、数据模型和存储格式，一旦对元数据模型有微小地更改将导致堆栈上下的级联更改。如果我们设计一个通用的体系结构，该结构不受存储和服务的元数据模型的影响，那将更具可扩展性。这反过来将使我们能够专注于发展适合我们业务的元数据模型，而不必担心堆栈的较低层。
3.在线与离线同样重要
一旦收集了元数据，就很自然地想要分析元数据以获得价值。一个简单的解决方案是将所有元数据转储到离线系统，如Hadoop，可以执行任意分析。但是，我们很快发现仅仅支持离线分析是不够的。例如访问控制和数据隐私处理，必须在线查询最新的元数据。
4.关系扮演重要角色
我们意识到仅仅围绕单个实体（数据集）建模元数据是不够的。整个生态系统的数据，代码和角色实体（数据集，数据科学家，团队，代码，微服务API，指标，AI功能，AI模型，仪表板，笔记本等）都需要集成到元数据地图。
二、一起了解下DataHub
大约一年前，我们根据这些知识从头开始设计WhereHows。我们意识到LinkedIn越来越需要跨各种数据实体的统一的搜索和发现体验，以及将它们连接在一起的元数据图。因此，我们决定扩大项目范围，构建一个完全通用的元数据搜索和发现工具DataHub，其雄心勃勃的愿景是：将LinkedIn员工与对他们至关重要的数据联系起来。我们将单片WhereHows堆栈分成两个不同的堆栈：模块化UI前端和通用元数据架构后端。新架构使我们能够快速扩展元数据收集范围，而不仅仅是数据集和作业。在撰写本文时，DataHub已经存储并索引数千万条元数据记录，这些记录包含19个不同的实体，包括数据集，指标，作业，图表，AI功能，人员和组。我们还计划在不久的将来在机器学习模型和标签，实验，仪表板，微服务API和代码上，发挥元数据的作用。
三、模块化UI
组件服务框架
与DataHub交互
在最高级别，前端提供三种类型的交互：（1）搜索，（2）浏览，（3）查看/编辑元数据。以下是一些实际应用的截图（点开看更清晰哦）
DataHub应用截图
与典型的搜索引擎体验类似，用户可以通过提供关键字列表来搜索一种或多种类型的实体。他们可以通过筛选一系列方面来进一步实现结果。高级用户还可以使用OR，NOT和regex等运算符来执行复杂搜索。
DataHub中的数据实体可以以树状方式组织和浏览，其中每个实体都允许出现在树中的多个位置。这使用户能够以不同的方式浏览相同的目录，例如，通过物理部署配置或业务功能组织。树中甚至有一个专门的部分，仅显示“经过认证的实体”，这些实体可通过单独的治理过程进行策划。
四、通用元数据架构
为了充分实现DataHub的愿景，我们需要一种能够使用元数据进行扩展的架构。可扩展性挑战有以下四种不同形式：
1.建模：以开发人员友好的方式为所有类型的元数据和关系建模。2.获取：通过API和流，大规模获取大量元数据更改。3.服务：服务于收集的原始和派生元数据，以及针对元数据的各种复杂查询。4.索引：大规模索引元数据，并在元数据发生更改时自动更新索引。
元数据建模
简而言之，元数据是“提供关于其他数据的信息的数据。”在元数据建模方面，带来了两个不同要求：
1.元数据也是数据
为模拟元数据，我们需要一种通用的建模语言。
2.元数据是分布式的
我们选择利用Pegasus，这是一种由LinkedIn创建的开放源码和完善的数据模式语言。Pegasus专为通用数据建模而设计，因此适用于大多数元数据。但是，由于Pegasus没有提供模型关系或关联的明确方法，因此我们引入了一些自定义扩展来支持这些用例。
为了演示如何使用Pegasus对元数据建模，让我们看一个简单的例子，它由以下修改后的实体关系图(ERD)演示。
该示例包含三种类型的实体：用户、组和数据集，由图中的蓝色圆圈表示。我们用箭头来表示这些实体之间的三种关系类型，即OwnedBy，HasMember和HasAdmin。换句话说，一个组由一个管理员和多个用户组成，他们可以拥有一个或多个数据集。
您可能已经注意到实体和关系属性与元数据方面存在重叠，例如，User的firstName属性应该与关联的Profile的firstName字段相同。重复的原因将在本文的后半部分进行解释。以Pegasus为例，我们将每个实体，关系和元数据方面转换为单独的Pegasus架构文件（PDSC）。为简单起见，我们在此仅包含每个类别的一个模型。首先，让我们看一下用户实体的PDSC：
每个实体都需要具有URN形式的全局唯一ID，可以将其视为一种类型的GUID。User实体具有包括名字，姓氏和LDAP的属性，每个属性都映射到用户记录中的可选字段。接下来是OwnedBy关系的PDSC模型：
每个关系模型自然包含“源”和“目标”字段，这些字段使用其URN指向特定实体实例。该模型可以选择包含其他属性字段，例如本例中的“type”。在这里，我们还引入了一个名为“pairings”的自定义属性，以限制与特定的源和目标URN类型的关系。在这种情况下，OwnedBy关系只能用于将数据集连接到用户。
最后，您将在下面找到Ownership元数据方面的模型。在此，我们选择将所有权建模为包含type和ldap字段的记录数组。但是，只要它是有效的PDSC记录，对于元数据方面的建模几乎没有限制。这令满足先前所述的“元数据也是数据”的要求成为可能。
在创建所有模型之后，下个问题是如何将它们连接在一起以形成所提议的ERD。我们将把这个讨论推迟到本文后面的元数据索引部分。
元数据获取
DataHub提供两种获取元数据的形式：直接API调用或Kafka流。前者用于需要读写一致性的元数据更改，后者更适用于面向事实的更新。
DataHub的API基于Rest.li，这是一种可扩展，强类型的RESTful服务架构，广泛用于LinkedIn。由于Rest.li使用Pegasus作为其接口定义，因此可以逐字使用上一节中定义的所有元数据模型。从API到存储需要多级模型转换的日子已经成为历史-API和模型将始终保持同步。
对于基于Kafka的获取，元数据生成者被期望产生一个标准化的元数据改变事件（MCE），其包含一个由相应实体URN键控的对特定元数据方面的建议更改列表。MCE的格式是ApacheAvro，它是由Pegasus元数据模型自动生成的。
在API和Kafka事件模式中使用相同的元数据模型，使得我们可以轻松地改进模型，而无需费力地维护相应的转换逻辑。但是，要实现真正无缝的模式演变，我们需要将所有模式更改限制为始终向后兼容。这在构建时通过添加兼容性检查强制执行。
在LinkedIn，我们倾向于更多地依赖Kafka流，因为它在生产者和消费者之间提供了松散的耦合。我们每天都会收到来自不同制作人的数百万个MCE，随着扩大元数据收集的范围，预计该数量将呈指数级增长。为了构建流式元数据提取管道，我们利用ApacheSamza作为流处理框架。获取Samza作业的目的是快速简单地实现高吞吐量。它只是将Avro数据转换回Pegasus并调用相应的Rest.liAPI来完成获取。
元数据服务
一旦摄取存储了元数据，就必须有效地提供原始元数据和派生元数据。DataHub旨在支持四种常见的大量元数据查询：
1.面向文档的查询2.面向图形的查询3.涉及连接的复杂查询4.全文检索
为实现这一目标，DataHub需要使用多种数据系统，每种数据系统都专门用于扩展和提供有限类型的查询。例如，Espresso是LinkedIn的NoSQL数据库，特别适合大规模面向文档的CRUD。同样，Galene可以轻松索引和提供网络规模的全文搜索。当谈到非平凡的图形查询时，specializedgraphDB可以比RDBMS更好地执行数量级，这并不奇怪。然而，事实证明，图结构也是表示外键关系的自然方式，能有效地回答复杂的连接查询。
DataHub通过一组通用数据访问对象（DAO）进一步抽象底层数据系统，例如键值DAO，查询DAO和搜索DAO。进而，当修改DAO的实现时，无需再更改DataHub中的任何业务逻辑。这将使我们能够在充分利用LinkedIn专有存储技术的同时，能够为流行的开源系统提供参考实现的开源DataHub。
DAO抽象的另一个主要好处是标准化的变更数据捕获（CDC）。无论底层数据存储系统的类型如何，通过键值DAO的任何更新操作都将自动发出元数据审计事件（MAE）。每个MAE包含相应实体的URN，以及特定元数据方面的前后图像。这支持lambda架构，其中可以批量或流处理MAE。与MCE类似，MAE的模式也是由元数据模型自动生成的。
元数据索引
最后一个缺失的部分是元数据索引管道。该系统将元数据模型连接在一起，并在图形数据库和搜索引擎中创建相应索引，以促进有效查询。这些业务逻辑以索引构建器和图形构建器的形式捕获，并作为处理MAE的Samza作业的一部分执行。每个构建器都在作业中注册了它们对特定元数据方面的兴趣，并将使用相应的MAE进行调用。然后，构建器会返回到一个幂等更新列表，这些更新将应用于搜索索引或graphDB。
元数据索引管道也是高度可扩展的，因为它可以基于每个MAE的实体URN进行分区，以支持每个实体的有序处理。
五、结论和期待
过去六个月，DataHub在LinkedIn每周支持1500多员工的搜索和各种特定的操作工作。LinkedIn的元数据图包含超过一百万个数据集，23个数据存储系统，25k个指标，500多个AI功能，最重要的是所有LinkedIn员工都是该图的创建者，消费者和操作者。