🥇开源 DataHub：LinkedIn 的搜索和元数据发现平台

开源 DataHub：LinkedIn 的元数据搜索和发现平台

对于任何依赖大量数据来制定数据驱动决策的公司来说，快速找到所需的数据至关重要。这不仅会影响数据用户（包括分析师、机器学习开发人员、数据科学家和数据工程师）的生产力，还会对依赖于高质量机器学习 (ML) 管道的最终产品产生直接影响。此外，实施或构建机器学习平台的趋势自然提出了一个问题：内部发现特征、模型、指标、数据集等的方法是什么。

在本文中，我们将讨论如何在开放许可下发布数据源数据中心在我们的元数据搜索和发现平台中，从项目的早期开始哪里如何。 LinkedIn 独立于开源版本维护自己的 DataHub 版本。我们将首先解释为什么我们需要两个独立的开发环境，然后讨论使用开源WhereHows的早期方法，并将我们的DataHub内部（生产）版本与上的版本进行比较 GitHub上。我们还将分享有关推送和接收开源更新以保持两个存储库同步的新自动化解决方案的详细信息。最后，我们将提供有关如何开始使用开源 DataHub 的说明，并简要讨论其架构。

WhereHows 现在是一个数据中心！

LinkedIn 的元数据团队之前介绍过数据中心（WhereHows 的后继者），LinkedIn 的搜索和元数据发现平台，并分享了开放该平台的计划。在此公告发布后不久，我们发布了 DataHub 的 alpha 版本并与社区分享。从那时起，我们不断为存储库做出贡献，并与感兴趣的用户合作，添加最需要的功能并解决问题。我们现在很高兴地宣布正式发布 GitHub 上的数据中心.

开源方法

WhereHows 是 LinkedIn 最初用于查找数据及其来源的门户，最初是一个内部项目；元数据团队打开了它 2016年的源代码。从那时起，该团队始终维护两种不同的代码库——一种用于开源，一种用于 LinkedIn 内部使用——因为并非所有为 LinkedIn 用例开发的产品功能都普遍适用于更广泛的受众。此外，WhereHows 有一些非开源的内部依赖项（基础设施、库等）。在接下来的几年里，WhereHows 经历了多次迭代和开发周期，这使得保持两个代码库同步成为一个巨大的挑战。多年来，元数据团队尝试了不同的方法，试图保持内部和开源开发同步。

第一次尝试：“开源第一”

我们最初遵循“开源优先”的开发模型，其中大多数开发发生在开源存储库中，并针对内部部署进行更改。这种方法的问题在于，代码总是先推送到 GitHub，然后再进行内部全面审查。在对开源存储库进行更改并进行新的内部部署之前，我们不会发现任何生产问题。如果部署不佳，也很难确定罪魁祸首，因为更改是批量进行的。

此外，该模型在开发需要快速迭代的新功能时降低了团队的生产力，因为它迫使所有更改首先推送到开源存储库，然后推送到内部存储库。为了减少处理时间，可以首先在内部存储库中完成所需的修复或更改，但是当将这些更改合并回开源存储库时，这成为一个巨大的问题，因为这两个存储库不同步。

与全功能自定义 Web 应用程序相比，该模型对于共享平台、库或基础设施项目更容易实现。此外，此模型非常适合从第一天开始开源的项目，但WhereHows 是作为完全内部的 Web 应用程序构建的。完全抽象掉所有内部依赖项确实很困难，因此我们需要保留内部分叉，但保留内部分叉并开发大部分开源代码并不太有效。

第二次尝试：“内在第一”

**作为第二次尝试，我们转向“内部优先”开发模式，其中大多数开发都在内部进行，并定期对开源代码进行更改。尽管该模型最适合我们的用例，但它存在固有的问题。直接将所有差异推送到开源存储库，然后稍后尝试解决合并冲突是一种选择，但这很耗时。在大多数情况下，开发人员尽量不要在每次检查代码时都这样做。因此，批量执行此操作的频率会大大降低，从而使以后解决合并冲突变得更加困难。

第三次就成功了！

上述两次失败的尝试导致WhereHows GitHub 存储库在很长一段时间内仍然过时。团队不断改进产品的功能和架构，使得WhereHows for LinkedIn的内部版本变得比开源版本更加先进。它甚至还有一个新名称——DataHub。基于之前的失败尝试，团队决定开发一个可扩展的长期解决方案。

对于任何新的开源项目，LinkedIn 的开源团队都会建议并支持一种开发模式，其中项目的模块完全以开源方式开发。版本化工件被部署到公共存储库，然后使用以下命令重新签入内部 LinkedIn 工件外部库请求 (ELR)。遵循这种开发模型不仅有利于那些使用开源的人，而且还可以产生更加模块化、可扩展和可插拔的架构。

然而，成熟的后端应用程序（例如 DataHub）将需要大量时间才能达到此状态。这也排除了在所有内部依赖关系完全抽象之前开源完全工作的实现的可能性。这就是为什么我们开发了一些工具来帮助我们更快、更轻松地做出开源贡献。该解决方案对元数据团队（DataHub 开发人员）和开源社区都有好处。以下各节将讨论这种新方法。

开源出版自动化

Metadata 团队对开源 DataHub 的最新方法是开发一个自动同步内部代码库和开源存储库的工具。该工具包的高级功能包括：

将 LinkedIn 代码与开源同步，类似 rsync的.
许可证头生成，类似于阿帕奇鼠.
从内部提交日志自动生成开源提交日志。
防止破坏开源构建的内部更改依赖性测试.

以下小节将深入研究上述具有有趣问题的函数。

源代码同步

与开源版本的 DataHub 不同，DataHub 是单个 GitHub 存储库，LinkedIn 版本的 DataHub 是多个存储库的组合（内部称为多产品）。 DataHub 接口、元数据模型库、元数据仓库后端服务和流作业驻留在 LinkedIn 上的单独存储库中。但是，为了让开源用户更容易使用，我们为 DataHub 的开源版本提供了一个存储库。

图 1：存储库之间的同步 LinkedIn 数据中心 和一个存储库 数据中心 开源

为了支持自动构建、推送和拉取工作流程，我们的新工具会自动创建与每个源文件相对应的文件级映射。但是，该工具包需要初始配置，并且用户必须提供高级模块映射，如下所示。

{
  "datahub-dao": [
    "${datahub-frontend}/datahub-dao"
  ],
  "gms/impl": [
    "${dataset-gms}/impl",
    "${user-gms}/impl"
  ],
  "metadata-dao": [
    "${metadata-models}/metadata-dao"
  ],
  "metadata-builders": [
    "${metadata-models}/metadata-builders"
  ]
}

模块级映射是一个简单的 JSON，其键是开源存储库中的目标模块，值是 LinkedIn 存储库中的源模块列表。开源存储库中的任何目标模块都可以由任意数量的源模块提供。要指示源模块中存储库的内部名称，请使用字符串插值以 Bash 风格。使用模块级映射文件，这些工具通过扫描关联目录中的所有文件来创建文件级映射文件。

{
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Foo.java":
"metadata-builders/src/main/java/com/linkedin/Foo.java",
  "${metadata-models}/metadata-builders/src/main/java/com/linkedin/Bar.java":
"metadata-builders/src/main/java/com/linkedin/Bar.java",
  "${metadata-models}/metadata-builders/build.gradle": null,
}

文件级映射由工具自动创建；但是，它也可以由用户手动更新。这是 LinkedIn 源文件到开源存储库中文件的 1:1 映射。有几个与自动创建文件关联相关的规则：

在开源的目标模块有多个源模块的情况下，可能会出现冲突，例如相同的模块完全质量控制网络，存在于多个源模块中。作为一种冲突解决策略，我们的工具默认为“最后一个获胜”选项。
“null”表示源文件不属于开源存储库。
每次开源提交或提取后，该映射都会自动更新并创建快照。这对于识别自上次操作以来源代码中的添加和删除是必要的。

创建提交日志

开源提交的提交日志也是通过合并内部存储库的提交日志自动生成的。下面是一个示例提交日志，显示了我们的工具生成的提交日志的结构。提交清楚地表明该提交中打包了源存储库的哪些版本，并提供提交日志的摘要。看看这个犯罪使用我们的工具包生成的提交日志的真实示例。

metadata-models 29.0.0 -> 30.0.0
    Added aspect model foo
    Fixed issue bar

dataset-gms 2.3.0 -> 2.3.4
    Added rest.li API to serve foo aspect

MP_VERSION=dataset-gms:2.3.4
MP_VERSION=metadata-models:30.0.0

依赖性测试

领英有依赖测试基础设施，这有助于确保对内部多产品的更改不会破坏相关多产品的组装。开源DataHub存储库不是多产品，它不能是任何多产品的直接依赖项，但是借助获取开源DataHub源代码的多产品包装器，我们仍然可以使用此依赖项测试因此，对提供开源 DataHub 存储库的任何多产品的任何更改（稍后可能会公开）都会触发 shell 多产品中的构建事件。因此，任何无法构建包装产品的更改都会在提交原始产品之前通过测试并被恢复。

这是一种有用的机制，有助于防止任何破坏开源构建的内部提交，并在提交时检测到它。如果没有这个，就很难确定哪个内部提交导致开源存储库构建失败，因为我们批量对 DataHub 开源存储库进行内部更改。

开源 DataHub 和我们的生产版本之间的差异

到目前为止，我们已经讨论了同步两个版本的 DataHub 存储库的解决方案，但我们仍然没有概述为什么我们首先需要两个不同的开发流的原因。在本节中，我们将列出 DataHub 的公共版本和 LinkedIn 服务器上的生产版本之间的差异，并解释这些差异的原因。

差异的一个根源在于我们的生产版本依赖于尚未开源的代码，例如 LinkedIn 的 Offspring（LinkedIn 的内部依赖注入框架）。 Offspring 广泛用于内部代码库，因为它是管理动态配置的首选方法。但它不是开源的；因此我们需要找到开源 DataHub 的开源替代方案。

还有其他原因。当我们根据 LinkedIn 的需求创建元数据模型的扩展时，这些扩展通常非常特定于 LinkedIn，可能无法直接应用于其他环境。例如，我们为参与者 ID 和其他类型的匹配元数据提供非常具体的标签。因此，我们现在已将这些扩展从 DataHub 的开源元数据模型中排除。当我们与社区互动并了解他们的需求时，我们将在需要时开发这些扩展的通用开源版本。

易于使用和更容易适应开源社区也激发了两个版本的 DataHub 之间的一些差异。流处理基础设施的差异就是一个很好的例子。尽管我们的内部版本使用托管流处理框架，但我们选择对开源版本使用内置（独立）流处理，因为它避免创建另一个基础设施依赖项。

差异的另一个例子是在开源实现中使用单个 GMS（通用元数据存储）而不是多个 GMS。 GMA（通用元数据架构）是DataHub后端架构的名称，GMS是GMA上下文中的元数据存储。 GMA 是一种非常灵活的架构，允许您将每个数据构造（例如数据集、用户等）分发到其自己的元数据存储中，或者将多个数据构造存储在单个元数据存储中，只要注册表中包含数据结构映射即可GMS 已更新。为了便于使用，我们选择了一个 GMS 实例，将所有不同的数据结构存储在开源 DataHub 中。

下表给出了两种实现之间差异的完整列表。

产品特点
领英数据中心
开源数据中心

支持的数据结构
1) 数据集 2) 用户 3) 指标 4) ML 功能 5) 图表 6) 仪表板
1) 数据集 2) 用户

数据集支持的元数据源
1) 安布里 2) 沙发底座 3) 达利兹 4) 浓咖啡 5) HDFS 6) Hive 7) 卡夫卡 8) MongoDB 9) MySQL 10) Oracle 11) 黑 12) 急速 12) 海域 13) Teradata 13) 矢量 14) 威尼斯
Hive Kafka RDBMS

发布-订阅
卡夫卡
汇流卡夫卡

流处理
托管
嵌入式（独立）

依赖注入和动态配置
领英后代
春季

构建工具
Ligradle（LinkedIn 的内部 Gradle 包装器）
格拉德鲁

CI / CD
CRT（LinkedIn 的内部 CI/CD）
特拉维斯CI 和 Docker中心

元数据存储
分布式多个GMS：1）数据集GMS 2）用户GMS 3）指标GMS 4）特征GMS 5）图表/仪表板GMS
单一 GMS 适用于：1) 数据集 2) 用户

Docker 容器中的微服务

码头工人简化应用程序部署和分发集装箱化。 DataHub中服务的每个部分都是开源的，包括Kafka等基础设施组件， Elasticsearch, Neo4j и MySQL的，有自己的Docker镜像。为了编排 Docker 容器，我们使用了 Docker撰写.

图 2：架构 数据中心 *开源**

您可以在上图中看到 DataHub 的高级架构。除了基础设施组件之外，它还有四个不同的 Docker 容器：

datahub-gms：元数据存储服务

数据中心前端：应用程序播放，服务于 DataHub 接口。

datahub-mce-consumer：应用程序卡夫卡流，它使用元数据更改事件 (MCE) 流并更新元数据存储。

数据集线器-mae-消费者：应用程序卡夫卡流，它使用元数据审核事件流 (MAE) 并创建搜索索引和图形数据库。

开源存储库文档和原始 DataHub 博客文章包含有关各种服务功能的更详细信息。

DataHub 上的 CI/CD 是开源的

开源 DataHub 存储库使用特拉维斯CI 用于持续集成和 Docker中心用于持续部署。两者都具有良好的 GitHub 集成并且易于设置。对于大多数由社区或私营公司开发的开源基础设施（例如连接点），Docker 镜像被创建并部署到 Docker Hub 以便于社区使用。 Docker Hub 中找到的任何 Docker 镜像都可以通过简单的命令轻松使用码头工人拉.

每次提交到 DataHub 开源存储库时，所有 Docker 映像都会自动构建并使用“最新”标签部署到 Docker Hub。如果 Docker Hub 配置了一些命名正则表达式分支，开源仓库中的所有标签也在 Docker Hub 中以对应的标签名称发布。

使用数据中心

设置数据中心非常简单，由三个简单的步骤组成：

克隆开源存储库并使用提供的 docker-compose 脚本通过 docker-compose 运行所有 Docker 容器以快速启动。
使用还提供的命令行工具下载存储库中提供的示例数据。
在浏览器中浏览 DataHub。

主动追踪吉特聊天还配置了快速提问。用户还可以直接在 GitHub 存储库中创建问题。最重要的是，我们欢迎并感谢所有反馈和建议！

未来的计划

目前，开源 DataHub 的每个基础设施或微服务都是作为 Docker 容器构建的，整个系统是使用泊坞窗，撰写。鉴于受欢迎程度和广泛 Kubernetes，我们也希望在不久的将来提供基于 Kubernetes 的解决方案。

我们还计划提供在公共云服务上部署 DataHub 的交钥匙解决方案，例如 Azure, AWS или 谷歌云。鉴于 LinkedIn 最近宣布迁移到 Azure，这将符合元数据团队的内部优先事项。

最后但并非最不重要的一点是，感谢开源社区中所有 DataHub 的早期采用者，他们对 DataHub 进行了 alpha 评级，并帮助我们发现问题并改进文档。

来源： habr.com