Datahub中文社区

dazdata

OpenMetadata和DataHub是目前最流行的两种开源数据编目工具。这两种工具在功能方面都有明显的重叠，但是，它们也有一些区别。在这里，我们将根据它们的体系结构、引入方法、功能、可用集成等来比较这两种工具。

OpenMetadata
OpenMetadata是创建Databook以解决Uber数据编目问题的团队学习的结果。OpenMetadata查看了现有的数据编目系统，发现拼图中缺少的部分是统一的元数据模型。

最重要的是，他们增加了元数据的灵活性和可扩展性。虽然，因为它在市场上的新鲜感;其可靠的数据治理引擎，以及强大的搜索引擎的支持，OpenMetadata引起了极大的关注。

DataHub
DataHub是LinkedIn解决数据发现和编目问题的第二次尝试;他们早些时候开源了另一个名为WhereHows的工具。

在第二次迭代中，LinkedIn通过创建充当 DataHub 主干的通用元数据服务，解决了拥有非常广泛的数据系统、查询语言和访问机制的问题。

OpenMetadata和DataHub有什么区别？
让我们根据以下标准比较OpenMetadata与DataHub：

架构和技术堆栈
元数据建模和引入
数据治理功能
数据沿袭
数据质量和数据分析
上游和下游集成
我们精心策划了上述标准，以便在了解关键知识的情况下对这些工具进行比较 - 特别是如果您要选择其中一个作为元数据管理平台，为您的组织推动特定用例。

让我们详细考虑这些因素中的每一个，并澄清我们对它们表现的理解。

OpenMetadata vs. DataHub：架构和技术堆栈
DataHub使用Kafka介导的摄取引擎将数据存储在三个独立的层中 - MySQL，Elasticsearch和使用Kafka流的neo4j。

这些层中的数据通过 API 服务层提供。除了标准的 REST API 之外，DataHub 还支持 Kafka 和 GraphQL 用于下游消费。DataHub使用Pegasus定义语言（PDL）和自定义注释来存储模型元数据。
替代文字
OpenMetadata使用MySQL作为数据库，将所有元数据存储在统一元数据模型中。元数据是完全可搜索的，因为它由Elasticsearch提供支持，与DataHub相同。OpenMetadata 不使用专用的图形数据库，但它确实使用 JSON 模式来存储实体关系。

使用 OpenMetadata 的系统和个人与 REST API 交互，可以直接调用它，也可以通过 UI 调用它。要了解有关数据模型的更多信息，请参阅解释 OpenMetadata 高级设计的文档页面。
替代文字
OpenMetadata vs. DataHub：元数据建模和摄取
这两种工具之间的主要区别之一是，DataHub专注于基于拉取和推送的数据提取，而OpenMetadata显然是为基于拉取的数据提取机制而设计的。

默认情况下，DataHub和OpenMetadata都主要使用基于推送的提取，尽管不同之处在于DataHub使用Kafka，而OpenMetadata使用Airflow来提取数据。

DataHub中的不同服务可以过滤来自Kafka的数据并提取它们需要的内容，而OpenMetadata的Airflow将数据推送到API服务器DropWizard，用于下游应用程序。

这两种工具在存储元数据的方式上也有所不同。如上一节所述，DataHub使用带注释的PDL，而OpenMetadata使用基于注释的JSON模式的文档。

OpenMetadata vs. DataHub：数据治理功能
在今年早些时候的发布中，DataHub集成了他们所谓的行动框架，以增强数据治理引擎。操作框架是一个基于事件的系统，允许您触发外部工作流以实现可观测性。数据治理引擎会自动批注新的和更改的实体。

OpenMetadata和DataHub都有内置的基于角色的访问控制，用于管理访问和所有权。

OpenMetadata 引入了其他几个概念，例如重要性，以通过其他上下文提供更好的搜索和发现体验。DataHub 使用称为“域”的构造作为常规标记和词汇表术语之上的高级标记，以便为您提供更好的搜索体验。

OpenMetadata vs. DataHub：数据沿袭
借助最新版本的 DataHub，它现在能够支持列级数据沿袭。OpenMetadata预计将于2022年<>月中旬发布，也有望增强列级谱系。

OpenMetadata的Python SDK for Lineage允许您使用用于存储世系数据的entityLineage架构规范从数据源实体获取自定义世系数据。

除了自动世系捕获之外，DataHub 还提供从名为“基于文件的世系”的数据源将世系数据作为文件引入的功能。数据中心使用此处指定的基于 YAML 的世系文件格式。

OpenMetadata vs. DataHub：数据质量和数据分析
尽管DataHub不久前已经为某些数据质量相关功能制定了路线图项目，但它们尚未实现。但是，DataHub确实提供了与Great Expectations和dbt等工具的集成。您可以使用这些工具来获取元数据及其测试和验证结果。

在 DataHub 上查看这个“Great Exceptions”的演示。

OpenMetadata对质量有不同的看法。他们将数据质量和剖析集成到工具中。因为有许多用于检查数据质量的开源工具，所以有很多方法可以定义测试，但 OpenMetadata 选择在定义测试的元数据标准方面支持远大期望。

如果远大期望已经与您的其他工作流程集成，并且您更愿意将其作为您的中央数据质量工具，那么您可以通过 OpenMetadata 的Great Exceptions成来实现它。

OpenMetadata vs. DataHub：上游和下游集成
DataHub和OpenMetadata都有一个基于插件的元数据摄取架构。这使它们都能够与数据堆栈中的一系列工具顺利集成。

DataHub提供了一个GraphQL API，一个开放API和几个SDK，用于开发DataHub和与DataHub交互的应用程序或工具。此外，您可以使用 CLI 安装所需的插件。这些与数据中心交互的各种方法允许您将数据摄取到数据中心，并将数据从数据中心取出以供进一步使用。

OpenMetadata 支持五十多个用于摄取元数据的连接器，从数据库到 BI 工具，从消息队列到数据管道，包括其他元数据编目工具，如 Apache Atlas 和 Amundsen。OpenMetadata目前提供两种集成 - Great Expectations和Prefect。

OpenMetadata vs. DataHub：比较摘要
DataHub和OpenMetadata都试图解决数据编目，搜索，发现，治理和质量方面的相同问题。这两种工具都是出于为需要支持大量数据源、团队和用例的大型组织解决这些问题而诞生的。

尽管这些工具在发布历史和成熟度方面略有不同，但它们的功能存在显着重叠。

dazdata

1、命令行方式
给定一个配置文件./home/ubuntu/datahub_ingest/mysql_to_datahub.yml

source:
type: mysql
config:
# Coordinates
host_port: localhost:3306
database: dbname

# Credentials
username: root
password: example

sink:
type: datahub-rest
config:
server: http://localhost:8080

我们可以使用Datahub CLI 摄取元数据，如下所示

datahub ingest -c /home/ubuntu/datahub_ingest/mysql_to_datahub.yml

这将从配置文件中配置的源中摄取元数据。这执行一次引入。随着源系统的变化，我们希望将更改反映在Datahub中。为此，有人需要使用配方文件重新运行摄取命令。

2、使用 Cron
假设您的机器上有一个配置文件/home/ubuntu/datahub_ingest/mysql_to_datahub.yml

source:
type: mysql
config:
# Coordinates
host_port: localhost:3306
database: dbname

# Credentials
username: root
password: example

sink:
type: datahub-rest
config:
server: http://localhost:8080

我们可以使用 crontab 将摄取安排为每天午夜后五分钟运行，使用 DataHub CLI。

5 0 * * * datahub ingest -c /home/ubuntu/datahub_ingest/mysql_to_datahub.yml

3、使用Airflow
如果您使用 Apache Airflow 进行调度，那么您可能还希望使用它来调度您的摄取配方。

我们提供了一些有关如何配置 DAG 的示例：

mysql_sample_dag将完整的 MySQL 引入配置嵌入到 DAG 中。

snowflake_sample_dag避免在配方中嵌入凭据，而是从Airflow的连接功能中获取它们。您必须在 Airflow 中配置连接才能使用此方法。

4、使用 Kubernetes
如果您使用k8s部署了数据中心，则可以使用用于计划引入的Datahub引入 cron 子图表。

下面是该配置在 values.yaml 中的外观示例：

datahub-ingestion-cron:
enabled: true
crons:
mysql:
schedule: “0 * * * *” # Every hour
recipe:
configmapName: recipe-config
fileName: mysql_recipe.yml

这假设预先存在一个 Kubernetes ConfigMap，该 ConfigMap 将所有配置保存在与 cron 作业将运行的位置。

一个例子可以是：

apiVersion: v1
kind: ConfigMap
metadata:
name: recipe-config
data:
mysql_recipe.yml: |-
source:
type: mysql
config:
# Coordinates
host_port: :3306
database: dbname

    # Credentials
    username: root
    password: example

sink:
  type: datahub-rest
  config:
    server: http://<GMS_HOST>:8080

dazdata

转换
什么是转换？
通常，我们希望在元数据到达引入接收器之前对其进行修改，例如，我们可能希望添加自定义标记、所有权、属性或修补某些字段。转换使我们能够做这些事情。

此外，转换允许对引入的元数据进行精细控制，而无需自己修改引入框架的代码。相反，您可以编写自己的模块，该模块可以根据需要转换元数据事件。要将转换包含在配置中，只需要转换的名称以及转换所需的任何配置。

内置的转换
除了编写自己的转换器的选项（见下文）之外，我们还提供了一些简单的转换器，用于添加：标签、词汇表术语、属性和所有权信息。

Datahub为数据集提供的转换器是：

简单添加数据集所有权
模式添加数据集所有权
简单删除数据集所有权
标记数据集状态
简单添加数据集全局标记
模式添加数据集全局标记
添加数据集全局标记
设置数据集浏览路径
简单添加数据集术语表
模式添加数据集词汇表术语
模式添加数据集架构字段术语表
模式添加数据集架构字段全局标记
简单添加数据集属性
添加数据集数据集属性
简单添加数据集域
模式添加数据集域

dazdata

介绍

从版本开始0.8.25，DataHub支持使用DataHub用户界面创建，配置，计划和执行批处理元数据摄取。这使得
通过最大程度地减少操作自定义集成管道所需的开销，更轻松地将元数据导入 DataHub。

本文档将介绍在 UI 中配置、计划和执行元数据引入所需的步骤。

运行元数据引入

先决条件

若要查看和管理基于 UI 的元数据引入，必须具有Manage Metadata Ingestion&Manage Secrets
分配给您的帐户的权限。这些可以通过平台政策.

拥有这些权限后，可以通过导航到 DataHub 中的“引入”选项卡来开始管理引入。

在此页面上，您将看到活动列表引入源.引入源是引入的元数据的唯一源
从外部来源（如 Snowflake、Redshift 或 BigQuery）进入 DataHub。

如果您刚刚开始，您将没有任何来源。在以下部分中，我们将介绍如何创建
你的第一个引入源.

创建引入源

在引入任何元数据之前，需要创建新的引入源。首先单击**+ 创建新源**.

步骤 1：选择平台模板

在第一步中，选择一个食谱模板对应于要从中提取元数据的源类型。选择其中之一
各种原生支持的集成，从Snowflake到Postgres再到Kafka。
选择Custom从头开始构建摄取配方。

接下来，你将配置引入食谱，它定义了如何和什么从源系统中提取。

步骤 2：配置配方

接下来，您将定义引入食谱在亚姆.一个食谱是一组配置，它是
由数据中心用于从第三方系统中提取元数据。它通常由以下部分组成：

一个来源类型：您要从中提取元数据的系统类型（例如雪花、mysql、postgres）。如果您选择了本机模板，则已为您填充该模板。
查看当前支持的完整列表类型退房此列表.
一个来源配置：特定于源的一组配置类型.大多数源支持以下类型的配置值：
- 坐标：要从中提取元数据的系统的位置
- 凭据：用于访问要从中提取元数据的系统的权限凭据
- 定制：有关将提取的元数据的自定义，例如，要在关系数据库中扫描哪些数据库或表
一个水槽类型：一种接收器类型，用于路由从源类型中提取的元数据。官方支持的数据中心接收器
类型是datahub-rest和datahub-kafka.
一个水槽配置：将元数据发送到提供的接收器类型所需的配置。例如，数据中心坐标和凭据。

下图显示了配置为从 MySQL 摄取元数据的完整配方示例。

每种源类型的详细配置示例和文档可以在数据中心文档网站。

创建密钥

对于生产用例，敏感的配置值（如数据库用户名和密码），
应该隐藏在您的摄取配方中，不让普通人看到。为此，您可以创建和嵌入秘密.机密是命名值
加密并存储在数据中心的存储层中。

要创建密钥，请先导航到“密钥”标签。然后单击+ Create new secret.

创建密钥以存储 MySQL 数据库的用户名

在表单中，提供密钥的唯一名称以及要加密的值和可选说明。点击创造当你完成时。
这将创建一个密钥，可以使用其名称在摄取配方中引用该密钥。

引用机密

创建密钥后，可以从您的食谱使用变量替换。例如
要将 MySQL 用户名和密码的机密替换为配方，您的配方将定义如下：

source:
    type: mysql
    config:
        host_port: 'localhost:3306'
        database: my_db
        username: ${MYSQL_USERNAME}
        password: ${MYSQL_PASSWORD}
        include_tables: true
        include_views: true
        profiling:
            enabled: true
sink:
    type: datahub-rest
    config:
        server: 'http://datahub-gms:8080'

从配方定义引用数据中心机密

当具有此配方的引入源执行时，数据中心将尝试“解析”在 YAML 中找到的机密。如果可以解析密钥，则在执行之前将引用替换为其解密值。
机密值不会在执行时间之后保存到磁盘，并且永远不会传输到 DataHub 外部。

注意力：任何被授予Manage Secrets 平台特权将能够使用 GraphQL API 检索明文机密值。

步骤 3：计划执行

接下来，您可以选择配置执行新引入源的计划。这样就可以根据组织的需求按月度、每周、每天或每小时的节奏安排元数据提取。
计划是使用 CRON 格式定义的。

在洛杉矶时间每天上午 9：15 执行的引入源

要了解有关 CRON 调度格式的更多信息，请查看维基百科概述。

如果计划临时执行引入，可以单击跳以完全跳过计划步骤。不用担心-
你总是可以回来改变这一点。

第 4 步：完成

最后，为引入源命名。

对配置感到满意后，单击“完成”以保存更改。

高级：使用特定 CLI 版本运行

数据中心预配置为使用最新版本的数据中心 CLI （亚克力数据中心）兼容
与服务器。但是，您可以使用“高级”源配置覆盖默认包版本。

为此，只需单击“高级”，然后更改“CLI版本”文本框以包含确切版本
您要使用的数据中心 CLI。

将 CLI 版本固定到版本0.8.23.2

对更改感到满意后，只需单击“完成”即可保存。

运行引入源

创建引入源后，可以通过单击“执行”来运行它。不久之后，
应会看到引入源的“上次状态”列从N/A自Running.这
表示数据中心引入执行程序已成功选取执行引入的请求。

如果引入已成功执行，应会看到其状态显示为绿色Succeeded.

取消引入运行

如果引入运行挂起，则引入源中可能存在 bug，或者其他持续存在的问题，例如指数超时。如果出现这些情况，
您可以通过单击取消在有问题的运行中。

取消后，可以通过单击详.

调试失败的引入运行

各种因素都可能导致引入运行失败。失败的常见原因包括：

配方配置错误：配方未为摄取源提供所需或预期的配置。您可以参考
到元数据引入框架源文档，以了解有关源类型所需配置的更多信息。
无法解析机密：如果 DataHub 无法找到配方配置引用的机密，则摄取运行将失败。
验证配方中引用的密钥名称是否与已创建的密钥名称匹配。
连接性/网络可达性：如果 DataHub 无法访问数据源，例如由于 DNS 解析
失败，元数据引入将失败。确保部署数据中心的网络可以访问数据源
你正在尝试到达。
认证：如果您已启用元数据服务身份验证，则需要提供个人访问令牌
在您的配方配置中。为此，请将接收器配置的“令牌”字段设置为包含个人访问令牌：

每次运行的输出都会被捕获，并可在 UI 中查看，以便更轻松地进行调试。要查看输出日志，请单击详
在相应的引入运行中。

常见问题

我尝试在运行“数据中心 docker 快速入门”后引入元数据，但引入失败并出现“无法连接”错误。我该怎么办？

如果不是由于上述原因之一，这可能是因为运行引入的执行程序无法
以使用默认配置访问数据中心的后端。尝试更改摄取配方以使sink.config.server变量指向 Docker
的 DNS 名称datahub-gms荚：

当我尝试运行摄取时，我看到“N/A”。我该怎么办？

如果看到“不适用”，并且引入运行状态永远不会更改为“正在运行”，这可能意味着
您的遗嘱执行人（datahub-actions）容器已关闭。

此容器负责在请求传入时执行请求以运行引入，或者
按特定时间表按需提供。可以使用以下命令验证容器的运行状况docker ps.此外，您可以通过查找容器 ID 来检查容器日志
对于datahub-actions容器和运行docker logs <container-id>.

何时不应使用 UI 引入？

在不使用基于 UI 的引入计划程序的情况下引入元数据存在有效情况。例如

已编写自定义引入源
在部署了数据中心的网络上无法访问数据源
引入源需要来自本地文件系统的上下文（例如输入文件、环境变量等）
您希望在多个生成者/环境之间分发元数据引入

如何将策略附加到操作容器，以授予其从各种源拉取元数据的权限？

这因基础平台而异。对于 AWS，请参阅此处指导.

演示

点击这里以查看 UI 引入功能的完整演示。

反馈/问题/疑虑

我们希望收到您的来信！对于任何查询，包括反馈、问题或疑虑，请联系松弛!

dazdata

集成选项

数据中心支持两者基于推送和基于拉动元数据集成。

基于推送的集成允许您在元数据更改时直接从数据系统发出元数据，而基于拉取的集成允许您通过连接到数据系统并以批处理或增量方式提取元数据来从数据系统中“爬网”或“摄取”元数据。支持这两种机制意味着您可以以最灵活的方式与所有系统集成。

基于推送的集成示例包括气流,火花,远大的期望和Protobuf Schemas.这允许您从数据生态系统中的“活动”代理获得低延迟元数据集成。基于拉取的集成示例包括BigQuery，Snowflake，Looker，Tableau等。

本文档介绍 DataHub 中内置的基于拉取的元数据摄取系统，以便与数据堆栈中的各种源轻松集成。

开始

先决条件

在运行任何元数据引入作业之前，应确保 DataHub 后端服务全部正在运行。可以通过用户界面或通过命令行界面.您可以在浏览此页面时参考那里提供的 CLI 使用指南。

核心概念

来源

请参阅我们的“集成”页面浏览我们的摄取源并筛选其功能。

我们从中提取元数据的数据系统称为来源.这Sources边栏中左侧的选项卡显示可用于从中摄取元数据的所有源。例如，我们有来源大查询,美人,画面等等。

元数据引入源状态

我们将支持状态应用于每个元数据源，以帮助您一目了然地了解集成可靠性。

：认证来源经过充分测试，并被DataHub社区广泛采用。我们希望集成是稳定的，很少有面向用户的问题。

：孵化源已准备好采用数据中心社区，但尚未针对各种边缘情况进行测试。我们热切地征求社区的反馈意见，以加强连接器;将来的版本中可能会出现次要版本更改。

：测试源可供DataHub社区成员试用，但如有更改，恕不另行通知。

汇

接收器是元数据的目标。为 DataHub 配置引入时，可能会通过REST （datahub-sink）或Kafka （datahub-kafka）沉。在某些情况下，文件接收器还有助于在调试期间存储元数据的持久脱机副本。

大多数引入系统和指南假定的默认接收器是datahub-rest水槽，但您也应该能够将它们全部适应其他水槽！

食谱

配方是将它们组合在一起的主要配置文件。它告诉我们的引入脚本从何处（源）提取数据以及将数据放在何处（接收器）。

：：：提示
命名您的食谱**.dhub.yaml**扩展点喜欢myrecipe.dhub.yaml使用 VSCoD 或 IntelliJ 作为具有自动完成功能的配方编辑器
和语法验证。

确保为您的编辑器安装了 yaml 插件：

对于 vscode 安装Redhat的yaml插件
对于智能安装官方 yaml 插件

:::

因为acryl-datahub版本>=0.8.33.2，则默认接收器假定为数据中心 REST 终结点：

托管在“http://localhost:8080”或环境变量${DATAHUB_GMS_URL}如果存在
使用空的身份验证令牌或环境变量${DATAHUB_GMS_TOKEN}如果存在。

下面是一个简单的方法，它从 MSSQL（源）中提取元数据并将其放入默认接收器（数据中心休息）。

# The simplest recipe that pulls metadata from MSSQL and puts it into DataHub
# using the Rest API.
source:
  type: mssql
  config:
    username: sa
    password: ${MSSQL_PASSWORD}
    database: DemoData
# sink section omitted as we want to use the default datahub-rest sink

运行此配方非常简单：

datahub ingest -c recipe.dhub.yaml

或者，如果要覆盖默认终结点，可以在命令中提供环境变量，如下所示：

DATAHUB_GMS_URL="https://my-datahub-server:8080" DATAHUB_GMS_TOKEN="my-datahub-token" datahub ingest -c recipe.dhub.yaml

许多食谱包含在示例/食谱目录。有关每个源和接收器的完整信息和上下文，请参阅插件表.

请注意，一个配方文件只能有 1 个源和 1 个接收器。如果你想要多个来源，那么你将需要多个食谱文件。

处理配方中的敏感信息

我们在配置中自动扩展环境变量（例如${MSSQL_PASSWORD}),
类似于 GNU bash 或 docker-compose 文件中的变量替换。有关详细信息，请参阅
https://docs.docker.com/compose/compose-file/compose-file-v2/#variable-substitution。此环境变量替换应用于屏蔽配方文件中的敏感信息。只要您可以将 env 变量安全地引入过程，就无需在配方中存储敏感信息。

CLI 用于引入的基本用法

pip install 'acryl-datahub[datahub-rest]'  # install the required plugin
datahub ingest -c ./examples/recipes/mssql_to_datahub.dhub.yml

这--dry-run选项ingest命令执行除写入接收器之外的所有引入步骤。这对于验证
引入配方在将元数据事件引入数据中心之前生成所需的元数据事件。

# Dry run
datahub ingest -c ./examples/recipes/example_to_datahub_rest.dhub.yml --dry-run
# Short-form
datahub ingest -c ./examples/recipes/example_to_datahub_rest.dhub.yml -n

这--preview选项ingest命令执行所有引入步骤，但将处理限制为仅源生成的前 10 个工作单元。
此选项有助于对引入配方进行快速的端到端烟雾测试。

# Preview
datahub ingest -c ./examples/recipes/example_to_datahub_rest.dhub.yml --preview
# Preview with dry-run
datahub ingest -c ./examples/recipes/example_to_datahub_rest.dhub.yml -n --preview

默认情况下--preview创建 10 个工作单元。但是，如果您想尝试生产更多的工作单元，您可以使用另一种选择--preview-workunits

# Preview 20 workunits without sending anything to sink
datahub ingest -c ./examples/recipes/example_to_datahub_rest.dhub.yml -n --preview --preview-workunits=20

报告

默认情况下，CLI 会向 DataHub 发送引入报告，以便你在 UI 中查看所有基于 cli 的引入的结果。这可以通过--no-default-report旗。

# Running ingestion with reporting to DataHub turned off
datahub ingest -c ./examples/recipes/example_to_datahub_rest.dhub.yaml --no-default-report

这些报告包括用于引入的配方。可以通过向摄取配方添加附加部分来关闭此功能。

source:
  # source configs

sink:
  # sink configs

# Add configuration for the datahub reporter
reporting:
  - type: datahub
    config:
      report_recipe: false

转换

如果要在数据到达引入接收器之前对其进行修改（例如，添加其他所有者或标记），可以使用转换器编写自己的模块并将其与 DataHub 集成。变压器需要使用新部分来扩展配方，以描述要运行的变压器。

例如，从 MSSQL 引入元数据并将默认“重要”标记应用于所有数据集的管道如下所述：

# A recipe to ingest metadata from MSSQL and apply default tags to all tables
source:
  type: mssql
  config:
    username: sa
    password: ${MSSQL_PASSWORD}
    database: DemoData

transformers: # an array of transformers applied sequentially
  - type: simple_add_dataset_tags
    config:
      tag_urns:
        - "urn:li:tag:Important"
# default sink, no config needed

查看变压器指南详细了解如何使用 Transformers 创建真正灵活的管道来处理元数据！

用作库（SDK）

在某些情况下，你可能希望直接构造元数据事件，并使用编程方式将该元数据发送到 DataHub。在这种情况下，请查看蟒蛇发射器和Java 发射器可以从您自己的代码调用的库。

程序化管道

在某些情况下，你可能希望完全从自定义 Python 脚本中配置和运行管道。下面是如何执行此操作的示例。

programmatic_pipeline.py- 一个基本的 mysql 到 REST 编程管道。

发展

请参阅以下指南：发展,添加源和使用变压器.

兼容性

数据中心服务器使用 3 位版本控制方案，而 CLI 使用 4 位方案。例如，如果您使用的是 DataHub 服务器版本 0.10.0，则应使用 CLI 版本 0.10.0.x，其中 x 是修补程序版本。
我们这样做是因为我们发布 CLI 的频率比服务器发布的频率高得多，通常每隔几天发布一次，而不是每月发布两次。

对于引入源，任何重大更改都将在发行说明.当字段被弃用或以其他方式更改时，我们将尝试保持两个服务器版本的向后兼容性，大约 4-6 周。每当使用已弃用的选项时，CLI 还将打印警告。

dazdata

Datahub快速入门指南

部署Datahub

若要部署Datahub的新实例，请执行以下步骤。

为您的平台安装 Docker 和 Docker Compose v2。

在 Windows 或 Mac 上，安装docker desktop.
在 Linux 上，安装Docker for Linux和docker-compose.

：：：注意

确保为 Docker 引擎分配足够的硬件资源。
测试和确认的配置：2个CPU，8GB RAM，2GB交换区域和10GB磁盘空间。

:::

从命令行或桌面应用程序启动 Docker 引擎。
安装Datahub命令行界面

一个。确保已安装并配置了Python 3.7+。（检查使用python3 --version).

b.在终端中运行以下命令
```
python3 -m pip install --upgrade pip wheel setuptools
python3 -m pip install --upgrade acryl-datahub
datahub version
```

：：：注意

如果您看到“找不到命令”，请尝试运行前缀为“python3 -m”的 cli 命令，而不是像python3 -m datahub version
请注意，DataHub CLI 不支持 Python 2.x。

:::

要在本地部署Datahub实例，请从终端运行以下 CLI 命令

datahub docker quickstart

这将使用docker-compose.
如果您好奇，docker-compose.yaml文件将下载到您的主目录下.datahub/quickstart目录。

如果一切顺利，您应该会看到如下消息：

Fetching docker-compose file https://raw.githubusercontent.com/datahub-project/datahub/master/docker/quickstart/docker-compose-without-neo4j-m1.quickstart.yml from GitHub
Pulling docker images...
Finished pulling docker images!

[+] Running 11/11
⠿ Container zookeeper                  Running                                                                                                                                                         0.0s
⠿ Container elasticsearch              Running                                                                                                                                                         0.0s
⠿ Container broker                     Running                                                                                                                                                         0.0s
⠿ Container schema-registry            Running                                                                                                                                                         0.0s
⠿ Container elasticsearch-setup        Started                                                                                                                                                         0.7s
⠿ Container kafka-setup                Started                                                                                                                                                         0.7s
⠿ Container mysql                      Running                                                                                                                                                         0.0s
⠿ Container datahub-gms                Running                                                                                                                                                         0.0s
⠿ Container mysql-setup                Started                                                                                                                                                         0.7s
⠿ Container datahub-datahub-actions-1  Running                                                                                                                                                         0.0s
⠿ Container datahub-frontend-react     Running                                                                                                                                                         0.0s
.......
✔ DataHub is now running
Ingest some demo data using `datahub docker ingest-sample-data`,
or head to http://localhost:9002 (username: datahub, password: datahub) to play around with the frontend.
Need support? Get in touch on Slack: https://slack.datahubproject.io/

完成此步骤后，您应该能够导航到Datahub UI
在http://localhost:9002在您的浏览器中。您可以使用datahub作为两者
用户名和密码。

：：：注意

在装有 Apple Silicon（M1、M2 等）的 Mac 电脑上，您可能会看到类似no matching manifest for linux/arm64/v8 in the manifest list entries，这通常意味着Datahub CLI 无法检测到您是否在 Apple 芯片上运行它。若要解决此问题，请通过发出datahub docker quickstart --arch m1

:::

要摄取示例元数据，请从终端运行以下 CLI 命令
```
datahub docker ingest-sample-data
```

：：：注意

如果您已启用元数据服务身份验证，则需要提供个人访问令牌
使用--token <token>命令中的参数。

:::

就是这样！现在请随意玩转Datahub！

排查问题

Command not found: datahub

如果运行Datahub cli 在终端内产生“找不到命令”错误，则系统可能默认为
旧版本的 Python。尝试在datahub命令与python3 -m:

python3 -m datahub docker quickstart

另一种可能性是您的系统路径不包括点的$HOME/.local/bin目录。在 Linux 上，您可以将其添加到您的~/.bashrc:

if [ -d "$HOME/.local/bin" ] ; then
    PATH="$HOME/.local/bin:$PATH"
fi

Port Conflicts

默认情况下，快速入门部署需要在本地计算机上提供以下端口：

3306 for MySQL
9200 for Elasticsearch
9092 为 Kafka 经纪人
8081 用于架构注册表
2181 for ZooKeeper
9002 用于Datahub Web 应用程序（Datahub前端）
8080 用于Datahub元数据服务（datahub-gms）

如果默认端口与您已经在计算机上运行的软件冲突，您可以通过将其他标志传递给datahub docker quickstart命令。
例如，要使用 53306（而不是默认的 3306）覆盖 MySQL 端口，您可以说：datahub docker quickstart --mysql-port 53306.用datahub docker quickstart --help以查看所有支持的选项。
对于元数据服务容器（datahub-gms），您需要使用环境变量，DATAHUB_MAPPED_GMS_PORT.例如，要使用端口 58080，您会说DATAHUB_MAPPED_GMS_PORT=58080 datahub docker quickstart

no matching manifest for linux/arm64/v8 in the manifest list entries On Mac computers with Apple Silicon (M1, M2 etc.), you might see an error like `no matching manifest for linux/arm64/v8 in the manifest list entries`, this typically means that the datahub cli was not able to detect that you are running it on Apple Silicon. To resolve this issue, override the default architecture detection by issuing `datahub docker quickstart --arch m1` Miscellaneous Docker issues There can be misc issues with Docker, like conflicting containers and dangling volumes, that can often be resolved by pruning your Docker state with the following command. Note that this command removes all unused containers, networks, images (both dangling and unreferenced), and optionally, volumes.

docker system prune

Still stuck?

跳到我们的松弛社区并在#troubleshoot渠道！

后续步骤

引入元数据

要开始将公司的元数据推送到 DataHub，请查看基于 UI 的引入指南，或者要使用 CLI 运行引入，请查看元数据摄取指南.

邀请用户

要将用户添加到您的部署以与您的团队共享，请查看我们的将用户添加到Datahub

启用身份验证

要启用 SSO，请查看配置 OIDC 身份验证或配置 JaaS 身份验证.

要启用后端身份验证，请查看 [DataHub 后端中的身份验证]（身份验证/引入元数据服务身份验证.md#配置元数据服务身份验证）。

迁移到生产环境

我们建议使用 Kubernetes 将 DataHub 部署到生产环境。我们提供帮助掌舵图表以帮助您快速启动和运行。退房将 DataHub 部署到 Kubernetes以获取分步演练。

其他常见操作

停止Datahub

若要停止Datahub的快速入门，可以发出以下命令。

datahub docker quickstart --stop

重置Datahub（又称恢复出厂设置）

要清除Datahub的所有状态（例如，在摄取您自己的状态之前），您可以使用 CLInuke命令。

datahub docker nuke

备份Datahub快速入门（实验性）

不建议将快速入门映像用作生产实例。看迁移到生产环境以获取有关设置生产群集的建议。但是，如果要备份当前快速入门状态（例如，你即将向公司提供演示，并且想要创建快速入门数据的副本，以便将来可以还原它），则可以提供--backup标记到快速入门。

datahub docker quickstart --backup

将备份您的 MySQL 映像并将其默认写入您的~/.datahub/quickstart/目录作为文件backup.sql.您可以通过传递--backup-file论点。
例如

datahub docker quickstart --backup --backup-file /home/my_user/datahub_backups/quickstart_backup_2002_22_01.sql

：：：注意

请注意，快速入门备份不包含任何时序数据（数据集统计信息、配置文件等），因此，如果删除所有索引并从此备份还原，则会丢失该信息。

:::

还原Datahub快速入门（实验性）

正如您可能想象的那样，这些备份是可还原的。以下部分介绍还原备份所需的几个不同选项。

还原备份（主 + 索引）[最常见]

若要还原以前的备份，请运行以下命令：

datahub docker quickstart --restore

此命令将选取backup.sql文件位于~/.datahub/quickstart并恢复您的主数据库以及 Elasticsearch 索引。

要提供特定的备份文件，请使用--restore-file选择。

datahub docker quickstart --restore --restore-file /home/my_user/datahub_backups/quickstart_backup_2002_22_01.sql

仅恢复索引 [以处理索引不同步/损坏问题]

可能出现的另一种情况是索引可能会损坏，或者缺少一些更新。要从主存储重新引导索引，可以运行此命令以将索引与主存储同步。

datahub docker quickstart --restore-indices

还原备份（主索引，但没有索引）[很少使用]

有时，您可能只想还原主数据库（MySQL）的状态，而不是重新索引数据。为此，必须显式禁用还原索引功能。

datahub docker quickstart --restore --no-restore-indices

升级本地Datahub

如果你一直在本地测试 DataHub，发布了新版本的 DataHub，并且你想要尝试新版本，然后你可以再次发出快速入门命令。它将拉下较新的映像并重新启动实例，而不会丢失任何数据。

datahub docker quickstart

定制

如果您想进一步自定义Datahub安装，请下载docker-compose.yaml由 CLI 工具使用，根据需要对其进行修改，并通过传递下载的 docker-compose 文件来部署Datahub：

datahub docker quickstart --quickstart-compose-file <path to compose file>

dazdata

Datahub平台由下图所示的组件组成。
替代文字

元数据存储
元数据存储负责存储构成元数据图的实体和方面。这包括公开用于引入元数据、按主键提取元数据、搜索实体和提取实体。它由一个Spring Java服务组成，托管一组 Rest.li API端点，以及 MySQL，Elasticsearch和Kafka用于主存储和索引。

元数据模型
元数据模型是定义构成元数据图的实体和方面的形状以及它们之间的关系的模式。它们被定义使用 PDL，一种在形式上与 Protobuf 非常相似的建模语言，同时序列化为 JSON。实体表示特定类别的元数据数据集、仪表板、数据管道等资产。实体的每个实例都由称为 .方面表示附加的相关数据包到实体的实例，例如其描述、标记等。在此处查看当前支持的实体集。

元数据摄入框架
摄入框架是一个模块化、可扩展的 Python 库，用于从外部源系统（例如 Snowflake，Looker，MySQL，Kafka），将其转换为DataHub的元数据模型，并通过以下方法将其写入DataHub。 Kafka 或直接使用元数据存储 Rest API。数据中心支持广泛的源连接器列表可供选择，以及一系列功能，包括架构提取、表和列分析、使用情况信息提取等。

摄入框架入门非常简单：只需定义 YAML 文件并执行命令。

GraphQL API
GraphQL API 提供了一个强类型、面向实体的 API，可以与包含元数据的实体进行交互图形简单，包括用于添加和删除标签，所有者，元数据实体链接等的API！最值得注意的是，用户界面（下面讨论）使用此API来实现搜索和发现，治理，可观测性。等等。

用户界面
DataHub带有一个React UI，包括一组不断发展的功能，使发现，治理和调试数据资产变得简单而愉快。

dazdata

DataHub 是第三代元数据平台，支持数据发现、协作、治理和端到端可观测性这是为现代数据堆栈构建的。DataHub采用模型优先的理念，重点是解锁两者之间的互操作性不同的工具和系统。
替代文字

架构特点
DataHub的架构有三个主要特点。

元数据建模的架构优先方法
DataHub 的元数据模型使用与序列化无关的语言进行描述。REST 和 GraphQL API-s 都受支持。此外，DataHub支持基于AVRO的API通过Kafka来传达元数据更改并订阅它们。我们的路线图包括一个里程碑，即将支持无代码元数据模型编辑，这将允许更易于使用，同时保留类型化 API 的所有优势。在元数据建模中阅读元数据建模。
基于流的实时元数据平台
DataHub的元数据基础设施是面向流的，允许在几秒钟内在平台内传达和反映元数据的变化。您还可以订阅 DataHub 元数据中发生的更改，从而允许您构建实时元数据驱动的系统。例如，您可以构建一个访问控制系统，该系统可以观察以前全局可读的数据集，添加一个包含 PII 的新架构字段，并锁定该数据集以进行访问控制审查。
联合元数据服务
DataHub附带单个元数据服务（gms）作为开源存储库的一部分。但是，它还支持可以由不同团队拥有和运营的联合元数据服务 - 事实上，这就是LinkedIn内部运行DataHub的方式。联合服务使用 Kafka 与中央搜索索引和图形通信，以支持全局搜索和发现，同时仍支持元数据的分离所有权。这种架构非常适合正在实施数据网格的公司。

dazdata

DataHub 是一个现代数据目录，旨在实现端到端数据发现、数据可观测性和数据治理。此可扩展元数据平台专为开发人员构建，以驯服其快速发展的数据生态系统的复杂性，并为数据从业者利用其组织内数据的总价值而构建。

引入元数据
使用DataHub用户界面创建，配置，计划和执行批处理元数据摄取。这样可以最大程度地减少操作自定义集成管道所需的开销，从而更轻松地将元数据导入 DataHub。

搜索和发现
搜索数据堆栈的所有角落，DataHub 的统一搜索体验可跨数据库、数据湖、BI 平台、ML 功能存储、编排工具等显示结果。

跟踪端到端数据血缘
通过跨平台、数据集、ETL/ELT 管道、图表、仪表板等跟踪沿袭，快速了解数据的端到端旅程。

360度查看元数据
结合技术和逻辑元数据，提供数据实体的 360º 视图。
生成数据集统计信息以了解数据的形状和分布。

现代数据治理
实时治理，操作框架支持以下实时用例：

列表通知：在Datahub进行更改时生成特定于组织的通知。例如，在将“PII”标记添加到任何数据资产时，向治理团队发送电子邮件。
列表工作流集成：将Datahub集成到组织的内部工作流中。例如，在数据集上提出特定标记或术语时创建 Jira 票证。
列表同步：将Datahub中所做的更改同步到第三方系统。例如，将 DataHub 中的标记添加反映到 Snowflake 中。
列表审计：审核谁在Datahub上进行了哪些更改。

Group Details Private

administrators

Member List

介绍

运行元数据引入

先决条件

创建引入源

步骤 1：选择平台模板

步骤 2：配置配方

创建密钥

引用机密

步骤 3：计划执行

第 4 步：完成

高级：使用特定 CLI 版本运行

运行引入源

取消引入运行

调试失败的引入运行

常见问题

我尝试在运行“数据中心 docker 快速入门”后引入元数据，但引入失败并出现“无法连接”错误。我该怎么办？

当我尝试运行摄取时，我看到“N/A”。我该怎么办？

何时不应使用 UI 引入？

如何将策略附加到操作容器，以授予其从各种源拉取元数据的权限？

演示

反馈/问题/疑虑

集成选项

开始

先决条件

核心概念

来源

元数据引入源状态

汇

食谱

处理配方中的敏感信息

CLI 用于引入的基本用法

报告

转换

用作库 （SDK）

程序化管道

发展

兼容性

Datahub快速入门指南

部署Datahub

排查问题

后续步骤

引入元数据

邀请用户

启用身份验证

迁移到生产环境

其他常见操作

停止Datahub

重置Datahub（又称恢复出厂设置）

备份Datahub快速入门（实验性）

还原Datahub快速入门（实验性）

还原备份（主 + 索引）[最常见]

仅恢复索引 [以处理索引不同步/损坏问题]

还原备份（主索引，但没有索引）[很少使用]

升级本地Datahub

定制

用作库（SDK）