该示例包含三种类型的实体-用户，组和数据集-由图中的蓝色圆圈表示。我们使用箭头表示这些实体之间的三种关系类型，即OwnedBy，HasMember和HasAdmin。换句话说，一个组由一个管理员和用户的多个成员组成，而用户又可以拥有一个或多个数据集。
与传统的ERD不同，我们将实体和关系的属性分别直接放置在圆圈内和关系名称下。这使我们可以将一种称为“元数据方面”的新型组件附加到实体。不同的团队可以为同一实体拥有和发展元数据的不同方面，而不会互相干扰，从而满足了分布式元数据建模的需求。上例中包含绿色矩形的三种类型的元数据方面：所有权，配置文件和成员身份。使用虚线表示元数据方面与实体的关联。例如，配置文件可以与用户相关联，所有权可以与数据集相关联，等等。
您可能已经注意到，实体和关系属性与元数据方面存在重叠，例如，用户的firstName属性应与关联的配置文件的firstName字段相同。重复信息的原因将在本文的后半部分中进行解释，但是到目前为止，将属性视为元数据方面的“有趣部分”就足够了。
为了在Pegasus中为示例建模，我们将每个实体，关系和元数据方面转换为单独的Pegasus Schema文件（PDSC）。为简便起见，我们在此仅列出每个类别中的一个模型。首先，让我们看一下User实体的PDSC：
{ "type": "record", "name": "User", "fields": [ { "name": "urn", "type": "com.linkedin.common.UserUrn", }, { "name": "firstName", "type": "string", "optional": true }, { "name": "lastName", "type": "string", "optional": true }, { "name": "ldap", "type": "com.linkedin.common.LDAP", "optional": true } ] }每个实体都必须具有URN形式的全局唯一ID ，可以将其视为类型化的GUID。User实体具有的属性包括名字，姓氏和LDAP，每个属性都映射到User记录中的可选字段。
接下来是OwnedBy关系的PDSC模型：
{ "type": "record", "name": "OwnedBy", "fields": [ { "name": "source", "type": "com.linkedin.common.Urn", }, { "name": "destination", "type": "com.linkedin.common.Urn", }, { "name": "type", "type": "com.linkedin.common.OwnershipType", } ], "pairings": [ { "source": "com.linkedin.common.urn.DatasetUrn", "destination": "com.linkedin.common.urn.UserUrn" } ] }每个关系模型自然包含使用其URN指向特定实体实例的“源”和“目的地”字段。模型可以选择包含其他属性字段，在这种情况下，例如“类型”。在这里，我们还引入了一个称为“ pairings”的自定义属性，以将关系限制为特定的源和目标URN类型对。在这种情况下，OwnedBy关系只能用于将数据集连接到用户。
最后，您将在下面找到所有权元数据方面的模型。在这里，我们选择将所有权建模为包含type和ldap字段的记录数组。但是，在建模元数据方面时，只要它是有效的PDSC记录，实际上就没有限制。这样就可以满足前面提到的“元数据也是数据”的要求。
{ "type": "record", "name": "Ownership", "fields": [ { "name": "owners", "type": { "type": "array", "items": { "name": "owner", "type": "record", "fields": [ { "name": "type", "type": "com.linkedin.common.OwnershipType" }, { "name": "ldap", "type": "string" } ] } } } ] } 元数据摄取DataHub提供两种形式的元数据摄取：通过直接API调用或Kafka流。前者适合离线，后者适合实时。
DataHub的API基于Rest.li，这是一种可扩展的，强类型的RESTful服务架构，已在LinkedIn上广泛使用。由于Rest.li使用Pegasus作为其接口定义，因此可以逐字使用上一节中定义的所有元数据模型。从API到存储需要多层转换的日子已经一去不复返了-API和模型将始终保持同步。
对于基于Kafka的提取，预计元数据生产者将发出标准化的元数据更改事件（MCE），其中包含由相应实体URN键控的针对特定元数据方面的建议更改列表。
对API和Kafka事件模式使用相同的元数据模型，使我们能够轻松地开发模型，而无需精心维护相应的转换逻辑。
元数据服务旦摄取并存储了元数据，有效地处理原始和派生的元数据就很重要。DataHub旨在支持对大量元数据的四种常见查询类型：
面向文档的查询
面向图的查询
涉及联接的复杂查询
全文搜索
为此，DataHub需要使用多种数据系统，每种数据系统专门用于扩展和服务于有限类型的查询。