DataHub 元数据写入三通道实战datahub-rest / datahub-kafka / datahub-lite Sink 配置与原理全解析【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub导读本文聚焦 DataHub 摄取管道Ingestion Pipeline中元数据“写出去”的最后一环——Sink系统讲解datahub-rest、datahub-kafka与datahub-lite三种官方 Sink 的安装方式、完整配置项、适用场景与底层实现。无论你是把元数据推送到 GMS REST 接口、通过 Kafka 异步高吞吐投递还是本地用 DuckDB 做探索式验证读完本文都能直接写出一份可运行的 recipe并理解每种通道在源码层面的工作方式。本文以仓库内 metadata-ingestion/sink_docs/datahub.md 为骨架结合 metadata-ingestion/src/datahub/ingestion/sink/datahub_rest.py、datahub_kafka.py、datahub_lite.py 等源码与 metadata-ingestion/examples/recipes/secured_kafka.dhub.yaml 示例展开。开始之前建议先阅读元数据摄取入门指南了解 recipe 的基本写法。一、先理解 Sink 在摄取管道中的位置一条完整的 DataHub 摄取任务Recipe由source从哪读与sink写到哪两部分组成。Sink 负责消费 source 产出的MetadataChangeEventMCE、MetadataChangeProposalMCP与MetadataChangeProposalWrapper三类元数据记录并将其投递到目标系统。仓库中 Sink 的抽象定义位于 metadata-ingestion/src/datahub/ingestion/api/sink.py所有 Sink 都实现write_record_async接口管道据此实现“一个记录进来、一个回调出去”的统一契约。本文讲解的三种 Sink 都是官方内置实现Sink 类型安装 extra投递方式核心优势datahub-restacryl-datahub[datahub-rest]GMS REST API同步/近同步错误立即可见datahub-kafkaacryl-datahub[datahub-kafka]Kafka 消息MCE/MCP Topic异步、高吞吐、解耦 GMSdatahub-liteacryl-datahub[datahub-lite]本地 DuckDB Lite 库零部署、本地探索二、DataHub Rest Sink面向 GMS 的标准投递通道datahub-rest是使用最广泛的 Sink通过 GMS 的 REST API 把元数据推送到 DataHub 服务端。REST 接口的最大优势是错误可以立即反馈——每次 HTTP 调用的成败都能直接反映到运行报告中便于排查问题。2.1 安装pip install acryl-datahub[datahub-rest]2.2 能力与定位通过 GMS REST API 推送元数据datahub_rest.py 中的DatahubRestSink是核心实现类支持SYNC、ASYNC、ASYNC_BATCH三种工作模式见下文Sink 初始化时会主动请求 GMS 的 server configself.emitter.server_config把 GMS 版本写入运行报告若连接失败会抛出ConfigurationError立即失败——这也是“错误立即报告”的底层体现。2.3 Quickstart Recipe最基础的 recipe 只需指定 GMS 地址datahub.mdsource: # source configs sink: type: datahub-rest config: server: http://localhost:8080连接托管版 DataHub Cloud时需要追加 Bearer Tokensource: # source configs sink: type: datahub-rest config: server: https://your-instance.acryl.io/gms token: token容器Docker内部互连若摄取任务与 GMS 都跑在 Docker 中参考 docker/README.md应使用 GMS 容器的内部主机名sink: type: datahub-rest config: server: http://datahub-gms:8080Kubernetes 集群内互连若 GMS 通过 Helm Charts 部署在 K8s 中见 docs/deploy/kubernetes.md且摄取任务也位于同一集群应使用 GMS 的 Kubernetes Service 名称sink: type: datahub-rest config: server: http://datahub-datahub-gms.datahub.svc.cluster.local:8080若使用 UI 方式创建摄取任务server该填什么完全取决于 GMS 的部署位置本机 / Docker / K8s规则与上述场景一致。2.4 配置项全表recipe 中使用.表示嵌套字段。以下为 datahub.md 中的完整配置表并补充了源码中的默认值出处FieldRequiredDefaultDescriptionserver✅DataHub GMS 端点 URLtoken用于认证的 Bearer Tokentimeout_sec30每个 HTTP 请求的超时时间秒同时作用于连接与读取超时retry_max_times1HTTP 请求失败时的最大重试次数重试间隔按指数递增retry_status_codes[429, 502, 503, 504]对这些 HTTP 状态码触发重试extra_headers附加到每个请求的自定义 Headermax_threads15REST API 调用的最大并行线程数modeASYNC_BATCH[高级] 工作模式SYNC/ASYNC/ASYNC_BATCHca_certificate_pathHTTPS 校验时使用的服务端 CA 证书路径client_certificate_pathHTTPS 双向认证时客户端 CA 证书路径disable_ssl_verificationfalse是否关闭 SSL 证书校验respect_mcp_sync_markerfalse[高级] 当任一 MCP 携带emitModeMarkersync系统元数据标记时将批次升级为同步执行详见下文源码补充说明timeout_sec在 datahub_rest.py 中被同时用于connect_timeout_sec与read_timeout_secretry_max_times与retry_status_codes直接透传给底层的DataHubRestEmitterrest_emitter.py构成 requests 适配器的重试策略其中对 429 的重试次数还会乘以环境变量DATAHUB_REST_EMITTER_429_RETRY_MULTIPLIER默认 2认证既支持token也支持通过auth配置 OAuth Token ProviderTokenProviderAuth。源码中_resolve_auth会在 recipe 未配置任何凭证时尝试继承环境变量DATAHUB_AUTH_TYPE配置的 OAuth 认证前提是 sink 的server与环境变量DATAHUB_GMS_URL指向同一来源详见 datahub_rest.py连接池与批次的扩展参数同样支持pool_connections、pool_maxsize默认均为 100见 env_vars.py。2.5 三种工作模式mode深入解读datahub_rest.py 定义了RestSinkMode枚举三种模式的差异直接决定吞吐与实时性的取舍SYNC逐条同步调用 GMS每个记录等待 HTTP 响应后才处理下一条。实时性最好、失败立即可知但吞吐最低适合低量级或强一致场景ASYNC通过PartitionExecutor按 URN 分片并行提交线程池大小由max_threads默认 15控制待处理请求上限为max_pending_requests默认 2000。记录按实体 URN 分片可保证同一实体的写入顺序ASYNC_BATCH默认使用BatchPartitionExecutor调用 GMS 新增的ingestProposalBatch端点进行批量提交效率显著高于前两者但要求服务端版本支持该端点。批次大小由max_per_batch默认 100上限受BATCH_INGEST_MAX_PAYLOAD_LENGTH约束、批处理最小间隔min_process_interval_seconds默认 30 秒控制。当单个批次过大被拆分时运行报告会记录async_batches_split并提示适当调小max_per_batch。模式与 GMS 端 emit 模式的关系源码中的_resolve_gms_emit_modedatahub_rest.py会校验环境变量DATAHUB_EMIT_MODE与 sink 模式是否同族——SYNC模式要求同步族SYNC_PRIMARY等ASYNC/ASYNC_BATCH要求异步族ASYNC若不匹配会打印 WARNING 并回退到安全默认值。此外 Sink 为每个工作线程维护独立的 emitterthread-local避免 requests session 的跨线程复用问题源码注释引用了 requests 的经典讨论。2.6 Marker 感知的同步路由respect_mcp_sync_marker这是文档强调的[高级特性]datahub.md启用后若某个批次中的任一 MCP 在系统元数据中携带emitModeMarkersync标记该批次会被升级为同步执行asyncfalse否则保持配置的mode不变。该特性只会增加同步性绝不会降低同步性Sink只读取、不生产该标记需要由生产者如自定义 aspect mutator/validator 或上游处理步骤在必须同步写入的记录上写入emitModeMarkersync系统元数据属性该特性仅在 DataHub Cloud 的特定配置组合下受支持且要求启用专用的逻辑模型传播 worker 池并开启 MCP 限流。自建 OSS 部署如需强一致写入应直接使用SYNC模式。三、DataHub Kafka Sink高吞吐异步投递datahub-kafka把元数据直接发布到 Kafka 的 MCE/MCP Topic由 DataHub 的 MAE/MCE Consumer 消费后写入 GMS。相比 REST 路径Kafka 路径完全异步、吞吐更高且写入压力不直接落在 GMS 的同步 HTTP 链路上。3.1 前置条件必须能直连 Kafka这是使用datahub-kafka的硬性前提datahub.mdSink 直接向 Kafka 集群生产消息运行摄取任务的进程必须能通过网络访问 broker 与 Schema Registry。这一点对 OSS 与集群内托管的摄取任务同样成立位于集群外、无法直连 Kafka 的 executor如 remote executor不能使用该 Sink应改走datahub-rest。3.2 安装pip install acryl-datahub[datahub-kafka]3.3 Quickstart Recipesource: # source configs sink: type: datahub-kafka config: connection: bootstrap: localhost:9092 schema_registry_url: http://localhost:80813.4 Kafka 搭配 OAuth以 AWS MSK IAM 为例当 Kafka 集群启用 SASL/OAuth 认证如 AWS MSK 的 IAM 认证时通过connection.producer_config透传 librdkafka 配置并使用oauth_cb指定 OAuth 回调函数source: # source configs sink: type: datahub-kafka config: topic_routes: MetadataChangeEvent: custom_mce_topic_name # 可选覆盖默认 MCE topic MetadataChangeProposal: custom_mcp_topic_name # 可选覆盖默认 MCP topic connection: bootstrap: b-1.your-msk-cluster.region.amazonaws.com:9098 schema_registry_url: http://datahub-gms:8080/schema-registry/api/ producer_config: security.protocol: SASL_SSL sasl.mechanism: OAUTHBEARER sasl.oauthbearer.method: default oauth_cb: datahub_actions.utils.kafka_msk_iam:oauth_cb # OAuth 回调注意MSK IAM 认证需要额外安装pip install acryl-datahub-actions1.3.1.2以提供该 OAuth 回调函数。更多带安全配置的完整示例可参考 metadata-ingestion/examples/recipes/secured_kafka.dhub.yaml。3.5 配置项全表FieldRequiredDefaultDescriptionconnection.bootstrap✅Kafka bootstrap 地址connection.producer_config.option透传给 Confluent KafkaSerializingProducer的配置项connection.producer_config.oauth_cb认证用的 OAuth 回调函数如 MSK IAM 的datahub_actions.utils.kafka_msk_iam:oauth_cbconnection.schema_registry_url✅所使用的 Schema Registry URLconnection.schema_registry_config.option透传给SchemaRegistryClient的配置项topic_routes.MetadataChangeEventMetadataChangeEvent覆盖 MCE 写入的 Kafka Topic 名topic_routes.MetadataChangeProposalMetadataChangeProposal覆盖 MCP 写入的 Kafka Topic 名源码补充说明配置模型KafkaEmitterConfig定义于 metadata-ingestion/src/datahub/emitter/kafka_emitter.pyproducer_config与schema_registry_config分别透传给 confluent-kafka 的SerializingProducer与SchemaRegistryClienttopic_routes的校验逻辑要求必须包含MetadataChangeProposal路由否则直接断言失败MCE 路由缺失时仅告警见 kafka_emitter.py底层实现 datahub_kafka.py 中MCE 会被拆解为逐 aspect 的 MCP 再逐条投递并使用_AggregatingKafkaCallback聚合 N 个投递回调为一次写回调保证“1 记录进 1 回调出”的契约librdkafka 的投递回调运行在后台线程因此该聚合器内部使用锁保证线程安全遇到 Schema Registry 404 时源码会追加提示topic 名可能与 schema registry 不匹配应通过topic_routes指定正确的 topic 名见_enhance_schema_registry_error。3.6 将 Kafka 设为默认 Sink托管 / executor-only 场景正常情况下recipe 若省略sink:默认使用 REST Sink。在能访问 Kafka 集群的 executor 部署中可以通过环境变量把“无 sink 的 recipe”的默认 Sink 翻转为datahub-kafka让写入直接走 MCP topic把写压力从 GMS 的同步 REST 路径上移走。该特性默认关闭完全通过 executor 上的环境变量控制recipe 本身不变显式声明sink:时总是以 recipe 为准不受影响。相关环境变量如下均定义于 env_vars.py环境变量默认值说明DATAHUB_INGESTION_DEFAULT_SINKdatahub-rest设为datahub-kafka时无 sink 的 recipe 默认走 Kafka未设置或为其他值则保持 REST行为逐字节不变KAFKA_BOOTSTRAP_SERVERSink 生产的 broker 地址沿用 DataHub 全局约定。未设置则该次运行回退到 RESTKAFKA_SCHEMAREGISTRY_URLMCP schema 所用的 Schema Registry沿用现有约定默认通过 GMS base path 使用 GMS 托管的 registryDATAHUB_KAFKA_SINK_QUEUE_MAX_KBYTES131072每个 producer 本地发送缓冲区上限KiB在 OOM 之前触发背压DATAHUB_KAFKA_SINK_QUEUE_MAX_MESSAGES20000每个 producer 本地发送缓冲区的消息数上限DATAHUB_KAFKA_SINK_LINGER_MS100producer 的linger.ms发送批聚合窗口DATAHUB_KAFKA_SINK_MAX_MESSAGE_BYTES5242880发送到 Kafka 的最大序列化消息大小字节把 librdkafka 约 1 MiB 的默认上限提升到 MCP topic 的 max必须 ≤ broker/topic 的max.message.bytesDATAHUB_KAFKA_SINK_INIT_PROBE_TIMEOUT10管道初始化时对 broker schema registry 可达性探测的每次超时秒注意CLI 的datahub ingest永不设置DATAHUB_INGESTION_DEFAULT_SINK因此 CLI 运行始终保持 REST 默认。该变量应只设置在希望走 Kafka 的那类运行上如集群内托管的 executor。3.7 DELETE / 软删除走 Kafka 的特殊处理GMS 的异步Kafka路径只接受UPSERT/UPDATE/CREATE/CREATE_ENTITY外加PATCH这些变更类型DELETE与RESTATE仅支持 REST时序timeseriesaspect 则只支持 UPSERT。因此当 Kafka 默认 Sink 生效时它会自动装配一个 REST 回退通道复用 REST Sink 同样的客户端配置把上述变更类型同步地通过 REST 发送。这一点在源码中体现为_needs_rest_fallbackdatahub_kafka.py非时序 aspect 仅当 changeType 不在_KAFKA_SUPPORTED_CHANGE_TYPESUPSERT/UPDATE/CREATE/CREATE_ENTITY/PATCH时走 REST时序 aspect 只要不是 UPSERT 就走 REST。几个关键行为务必理解有状态摄取stateful ingestion清理陈旧实体时发出的是Status(removedtrue)UPSERT因此正常走 Kafka不受回退影响——回退只处理字面的DELETE/RESTATEMCP如硬删除与非 UPSERT 时序变更普通摄取源一般不会发出这类记录两条路径的排序是尽力而为的在执行回退 DELETE 之前Sink 会先 flush 本地 producer 队列但不会等待 MCP consumer 真正应用之前的 Kafka 写入。在 consumer 滞后时同步的 REST DELETE 仍可能先于同一实体更早的 Kafka UPSERT 到达 GMS如果本次运行中此前的异步 Kafka 写入尚未确认存在 undelivered 或投递失败回退 DELETE 会被跳过并以失败上报而不是删除一个写入从未落地的实体详见_delivery_failed事件与 flush 计数逻辑因此混合变更类型且以 DELETE 为主的 recipe应优先选择 REST Sink。3.8 失败行为与可观测性文档与源码共同描述了 Kafka Sink 的失败处理策略初始化时 broker / registry 不可达选择 Kafka 默认 Sink 时会运行一次有界探测若任一端点不可达或KAFKA_BOOTSTRAP_SERVER未设置本次运行降级到 REST并打印WARNING日志。若跨多次运行持续降级说明 Kafka 已宕机、GMS 又重新承受全部写入负载——应针对此告警producer 队列打满Sink 会阻塞并轮询以施加背压而不是崩溃最长阻塞max_queue_full_block_seconds默认 300 秒后失败该次运行aspect 过大超过DATAHUB_KAFKA_SINK_MAX_MESSAGE_BYTES或 broker/topic 的max.message.bytes的 aspect 会通过投递回调上报该记录失败并计入运行失败——绝不会静默丢弃。需要更大 aspect 时应同时调大该环境变量与 topic 的限制。若配置了 REST 回退超大的 MCP 会降级为 REST 同步发送REST 端上限约 16 MiB高于 Kafka topic 的约 5 MiB运行报告Sink 报告会暴露kafka_backpressure_engagements、kafka_backpressure_blocked_seconds与kafka_undelivered三个指标定义于 datahub_kafka.py使限流与丢弃在运行摘要中可见而不仅限于日志。建议配合 MCP topic 的 consumer-lag 监控确认写入真正被消费应用。四、DataHub Lite Sink实验性本地探索首选datahub-lite提供与 DataHub Lite 的集成用于本地元数据探索与服务适合快速验证摄取结果无需启动完整的数据栈。4.1 安装pip install acryl-datahub[datahub-lite]4.2 能力与定位把元数据推送到本地 DataHub Lite 实例datahub_lite.py 中的DataHubLiteSink默认使用DuckDB作为存储后端数据库文件默认写入~/.datahub/lite/目录源码中DataHubLiteSinkConfig默认值为typeduckdb、config{file: ~/.datahub/lite/datahub.duckdb}经os.path.expanduser展开写入实现直接调用get_datahub_lite(...).write(record)。4.3 Quickstart Recipe最简单的写法零配置source: # source configs sink: type: datahub-lite指定 DuckDB 数据库文件位置source: # source configs sink: type: datahub-lite config: type: duckdb config: file: path_to_duckdb_file⚠️注意事项DataHub Lite 目前不支持有状态摄取stateful ingestion使用该 Sink 时必须在 recipe 中关闭 stateful ingestion通常在 source 配置里将stateful_ingestion.enabled置为false。文档注明该限制将很快修复。4.4 配置项全表FieldRequiredDefaultDescriptiontypeduckdb使用的 DataHub Lite 实现类型config{file: ~/.datahub/lite/datahub.duckdb}透传给 DataHub Lite 实现的配置字典DuckDB 实现接受的字段见下DuckDB 实现配置FieldRequiredDefaultDescriptionfile~/.datahub/lite/datahub.duckdbDuckDB 存储使用的数据库文件options{}透传给 DuckDB 库的选项字典支持的选项见 DuckDB 官方配置文档源码补充说明DataHub Lite 的后端抽象与本地服务能力详见 docs/datahub_lite.md。由于它面向本地轻量场景DataHubLiteSink.write_record_async仅支持 MCE 与MetadataChangeProposalWrapper类型遇到其他类型会记录 warning写入失败时通过回调上报失败成功则上报成功并计入运行报告。五、三种 Sink 的选型建议结合文档定位与源码实现给出实践选型参考场景推荐 Sink理由标准 OSS 部署、单机或少量摄取任务datahub-rest配置简单只需server错误立即可见默认ASYNC_BATCH模式已具备不错吞吐大规模、多任务、对吞吐要求高datahub-kafka异步 批量 与 GMS 解耦但要求运行环境能直连 Kafka 与 Schema Registry集群外 executor / 无法直连 Kafkadatahub-restKafka Sink 的硬性前置条件不满足时必须走 REST本地开发、快速验证摄取结果datahub-lite零部署、DuckDB 落盘无需启动任何服务需要可靠删除 / 强一致写入datahub-restSYNC模式Kafka 异步路径不支持 DELETE/RESTATE排序仅为尽力而为同时记住几个贯穿始终的原则显式sink:永远优先环境变量控制的“默认 Sink”翻转只作用于省略sink:的 recipe显式声明不会被覆盖运行报告是你的第一道监控REST Sink 报告 GMS 版本与批次拆分信息Kafka Sink 报告背压与未投递消息数摄取后应养成查看运行报告的习惯版本前提ASYNC_BATCH模式与respect_mcp_sync_marker等特性依赖较新的 GMS 服务端能力升级前请核对服务端版本支持情况。六、结语本文从安装、配置到源码原理完整梳理了 DataHub 元数据摄取的三大输出通道datahub-rest的三种模式与 Marker 同步路由、datahub-kafka的直连前提、OAuth 认证、默认 Sink 翻转与 DELETE 回退机制以及datahub-lite的本地 DuckDB 落盘。相关核心实现均可在 metadata-ingestion/src/datahub/ingestion/sink/ 目录下找到配置模型集中在 metadata-ingestion/src/datahub/configuration/env_vars.py 与 metadata-ingestion/src/datahub/emitter/ 中。掌握了这些细节你就能针对不同部署环境选择最合适的写入通道并准确解读运行报告中的每一项指标。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
DataHub 元数据写入三通道实战datahub-rest / datahub-kafka / datahub-lite Sink 配置与原理全解析【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub导读本文聚焦 DataHub 摄取管道Ingestion Pipeline中元数据“写出去”的最后一环——Sink系统讲解datahub-rest、datahub-kafka与datahub-lite三种官方 Sink 的安装方式、完整配置项、适用场景与底层实现。无论你是把元数据推送到 GMS REST 接口、通过 Kafka 异步高吞吐投递还是本地用 DuckDB 做探索式验证读完本文都能直接写出一份可运行的 recipe并理解每种通道在源码层面的工作方式。本文以仓库内 metadata-ingestion/sink_docs/datahub.md 为骨架结合 metadata-ingestion/src/datahub/ingestion/sink/datahub_rest.py、datahub_kafka.py、datahub_lite.py 等源码与 metadata-ingestion/examples/recipes/secured_kafka.dhub.yaml 示例展开。开始之前建议先阅读元数据摄取入门指南了解 recipe 的基本写法。一、先理解 Sink 在摄取管道中的位置一条完整的 DataHub 摄取任务Recipe由source从哪读与sink写到哪两部分组成。Sink 负责消费 source 产出的MetadataChangeEventMCE、MetadataChangeProposalMCP与MetadataChangeProposalWrapper三类元数据记录并将其投递到目标系统。仓库中 Sink 的抽象定义位于 metadata-ingestion/src/datahub/ingestion/api/sink.py所有 Sink 都实现write_record_async接口管道据此实现“一个记录进来、一个回调出去”的统一契约。本文讲解的三种 Sink 都是官方内置实现Sink 类型安装 extra投递方式核心优势datahub-restacryl-datahub[datahub-rest]GMS REST API同步/近同步错误立即可见datahub-kafkaacryl-datahub[datahub-kafka]Kafka 消息MCE/MCP Topic异步、高吞吐、解耦 GMSdatahub-liteacryl-datahub[datahub-lite]本地 DuckDB Lite 库零部署、本地探索二、DataHub Rest Sink面向 GMS 的标准投递通道datahub-rest是使用最广泛的 Sink通过 GMS 的 REST API 把元数据推送到 DataHub 服务端。REST 接口的最大优势是错误可以立即反馈——每次 HTTP 调用的成败都能直接反映到运行报告中便于排查问题。2.1 安装pip install acryl-datahub[datahub-rest]2.2 能力与定位通过 GMS REST API 推送元数据datahub_rest.py 中的DatahubRestSink是核心实现类支持SYNC、ASYNC、ASYNC_BATCH三种工作模式见下文Sink 初始化时会主动请求 GMS 的 server configself.emitter.server_config把 GMS 版本写入运行报告若连接失败会抛出ConfigurationError立即失败——这也是“错误立即报告”的底层体现。2.3 Quickstart Recipe最基础的 recipe 只需指定 GMS 地址datahub.mdsource: # source configs sink: type: datahub-rest config: server: http://localhost:8080连接托管版 DataHub Cloud时需要追加 Bearer Tokensource: # source configs sink: type: datahub-rest config: server: https://your-instance.acryl.io/gms token: token容器Docker内部互连若摄取任务与 GMS 都跑在 Docker 中参考 docker/README.md应使用 GMS 容器的内部主机名sink: type: datahub-rest config: server: http://datahub-gms:8080Kubernetes 集群内互连若 GMS 通过 Helm Charts 部署在 K8s 中见 docs/deploy/kubernetes.md且摄取任务也位于同一集群应使用 GMS 的 Kubernetes Service 名称sink: type: datahub-rest config: server: http://datahub-datahub-gms.datahub.svc.cluster.local:8080若使用 UI 方式创建摄取任务server该填什么完全取决于 GMS 的部署位置本机 / Docker / K8s规则与上述场景一致。2.4 配置项全表recipe 中使用.表示嵌套字段。以下为 datahub.md 中的完整配置表并补充了源码中的默认值出处FieldRequiredDefaultDescriptionserver✅DataHub GMS 端点 URLtoken用于认证的 Bearer Tokentimeout_sec30每个 HTTP 请求的超时时间秒同时作用于连接与读取超时retry_max_times1HTTP 请求失败时的最大重试次数重试间隔按指数递增retry_status_codes[429, 502, 503, 504]对这些 HTTP 状态码触发重试extra_headers附加到每个请求的自定义 Headermax_threads15REST API 调用的最大并行线程数modeASYNC_BATCH[高级] 工作模式SYNC/ASYNC/ASYNC_BATCHca_certificate_pathHTTPS 校验时使用的服务端 CA 证书路径client_certificate_pathHTTPS 双向认证时客户端 CA 证书路径disable_ssl_verificationfalse是否关闭 SSL 证书校验respect_mcp_sync_markerfalse[高级] 当任一 MCP 携带emitModeMarkersync系统元数据标记时将批次升级为同步执行详见下文源码补充说明timeout_sec在 datahub_rest.py 中被同时用于connect_timeout_sec与read_timeout_secretry_max_times与retry_status_codes直接透传给底层的DataHubRestEmitterrest_emitter.py构成 requests 适配器的重试策略其中对 429 的重试次数还会乘以环境变量DATAHUB_REST_EMITTER_429_RETRY_MULTIPLIER默认 2认证既支持token也支持通过auth配置 OAuth Token ProviderTokenProviderAuth。源码中_resolve_auth会在 recipe 未配置任何凭证时尝试继承环境变量DATAHUB_AUTH_TYPE配置的 OAuth 认证前提是 sink 的server与环境变量DATAHUB_GMS_URL指向同一来源详见 datahub_rest.py连接池与批次的扩展参数同样支持pool_connections、pool_maxsize默认均为 100见 env_vars.py。2.5 三种工作模式mode深入解读datahub_rest.py 定义了RestSinkMode枚举三种模式的差异直接决定吞吐与实时性的取舍SYNC逐条同步调用 GMS每个记录等待 HTTP 响应后才处理下一条。实时性最好、失败立即可知但吞吐最低适合低量级或强一致场景ASYNC通过PartitionExecutor按 URN 分片并行提交线程池大小由max_threads默认 15控制待处理请求上限为max_pending_requests默认 2000。记录按实体 URN 分片可保证同一实体的写入顺序ASYNC_BATCH默认使用BatchPartitionExecutor调用 GMS 新增的ingestProposalBatch端点进行批量提交效率显著高于前两者但要求服务端版本支持该端点。批次大小由max_per_batch默认 100上限受BATCH_INGEST_MAX_PAYLOAD_LENGTH约束、批处理最小间隔min_process_interval_seconds默认 30 秒控制。当单个批次过大被拆分时运行报告会记录async_batches_split并提示适当调小max_per_batch。模式与 GMS 端 emit 模式的关系源码中的_resolve_gms_emit_modedatahub_rest.py会校验环境变量DATAHUB_EMIT_MODE与 sink 模式是否同族——SYNC模式要求同步族SYNC_PRIMARY等ASYNC/ASYNC_BATCH要求异步族ASYNC若不匹配会打印 WARNING 并回退到安全默认值。此外 Sink 为每个工作线程维护独立的 emitterthread-local避免 requests session 的跨线程复用问题源码注释引用了 requests 的经典讨论。2.6 Marker 感知的同步路由respect_mcp_sync_marker这是文档强调的[高级特性]datahub.md启用后若某个批次中的任一 MCP 在系统元数据中携带emitModeMarkersync标记该批次会被升级为同步执行asyncfalse否则保持配置的mode不变。该特性只会增加同步性绝不会降低同步性Sink只读取、不生产该标记需要由生产者如自定义 aspect mutator/validator 或上游处理步骤在必须同步写入的记录上写入emitModeMarkersync系统元数据属性该特性仅在 DataHub Cloud 的特定配置组合下受支持且要求启用专用的逻辑模型传播 worker 池并开启 MCP 限流。自建 OSS 部署如需强一致写入应直接使用SYNC模式。三、DataHub Kafka Sink高吞吐异步投递datahub-kafka把元数据直接发布到 Kafka 的 MCE/MCP Topic由 DataHub 的 MAE/MCE Consumer 消费后写入 GMS。相比 REST 路径Kafka 路径完全异步、吞吐更高且写入压力不直接落在 GMS 的同步 HTTP 链路上。3.1 前置条件必须能直连 Kafka这是使用datahub-kafka的硬性前提datahub.mdSink 直接向 Kafka 集群生产消息运行摄取任务的进程必须能通过网络访问 broker 与 Schema Registry。这一点对 OSS 与集群内托管的摄取任务同样成立位于集群外、无法直连 Kafka 的 executor如 remote executor不能使用该 Sink应改走datahub-rest。3.2 安装pip install acryl-datahub[datahub-kafka]3.3 Quickstart Recipesource: # source configs sink: type: datahub-kafka config: connection: bootstrap: localhost:9092 schema_registry_url: http://localhost:80813.4 Kafka 搭配 OAuth以 AWS MSK IAM 为例当 Kafka 集群启用 SASL/OAuth 认证如 AWS MSK 的 IAM 认证时通过connection.producer_config透传 librdkafka 配置并使用oauth_cb指定 OAuth 回调函数source: # source configs sink: type: datahub-kafka config: topic_routes: MetadataChangeEvent: custom_mce_topic_name # 可选覆盖默认 MCE topic MetadataChangeProposal: custom_mcp_topic_name # 可选覆盖默认 MCP topic connection: bootstrap: b-1.your-msk-cluster.region.amazonaws.com:9098 schema_registry_url: http://datahub-gms:8080/schema-registry/api/ producer_config: security.protocol: SASL_SSL sasl.mechanism: OAUTHBEARER sasl.oauthbearer.method: default oauth_cb: datahub_actions.utils.kafka_msk_iam:oauth_cb # OAuth 回调注意MSK IAM 认证需要额外安装pip install acryl-datahub-actions1.3.1.2以提供该 OAuth 回调函数。更多带安全配置的完整示例可参考 metadata-ingestion/examples/recipes/secured_kafka.dhub.yaml。3.5 配置项全表FieldRequiredDefaultDescriptionconnection.bootstrap✅Kafka bootstrap 地址connection.producer_config.option透传给 Confluent KafkaSerializingProducer的配置项connection.producer_config.oauth_cb认证用的 OAuth 回调函数如 MSK IAM 的datahub_actions.utils.kafka_msk_iam:oauth_cbconnection.schema_registry_url✅所使用的 Schema Registry URLconnection.schema_registry_config.option透传给SchemaRegistryClient的配置项topic_routes.MetadataChangeEventMetadataChangeEvent覆盖 MCE 写入的 Kafka Topic 名topic_routes.MetadataChangeProposalMetadataChangeProposal覆盖 MCP 写入的 Kafka Topic 名源码补充说明配置模型KafkaEmitterConfig定义于 metadata-ingestion/src/datahub/emitter/kafka_emitter.pyproducer_config与schema_registry_config分别透传给 confluent-kafka 的SerializingProducer与SchemaRegistryClienttopic_routes的校验逻辑要求必须包含MetadataChangeProposal路由否则直接断言失败MCE 路由缺失时仅告警见 kafka_emitter.py底层实现 datahub_kafka.py 中MCE 会被拆解为逐 aspect 的 MCP 再逐条投递并使用_AggregatingKafkaCallback聚合 N 个投递回调为一次写回调保证“1 记录进 1 回调出”的契约librdkafka 的投递回调运行在后台线程因此该聚合器内部使用锁保证线程安全遇到 Schema Registry 404 时源码会追加提示topic 名可能与 schema registry 不匹配应通过topic_routes指定正确的 topic 名见_enhance_schema_registry_error。3.6 将 Kafka 设为默认 Sink托管 / executor-only 场景正常情况下recipe 若省略sink:默认使用 REST Sink。在能访问 Kafka 集群的 executor 部署中可以通过环境变量把“无 sink 的 recipe”的默认 Sink 翻转为datahub-kafka让写入直接走 MCP topic把写压力从 GMS 的同步 REST 路径上移走。该特性默认关闭完全通过 executor 上的环境变量控制recipe 本身不变显式声明sink:时总是以 recipe 为准不受影响。相关环境变量如下均定义于 env_vars.py环境变量默认值说明DATAHUB_INGESTION_DEFAULT_SINKdatahub-rest设为datahub-kafka时无 sink 的 recipe 默认走 Kafka未设置或为其他值则保持 REST行为逐字节不变KAFKA_BOOTSTRAP_SERVERSink 生产的 broker 地址沿用 DataHub 全局约定。未设置则该次运行回退到 RESTKAFKA_SCHEMAREGISTRY_URLMCP schema 所用的 Schema Registry沿用现有约定默认通过 GMS base path 使用 GMS 托管的 registryDATAHUB_KAFKA_SINK_QUEUE_MAX_KBYTES131072每个 producer 本地发送缓冲区上限KiB在 OOM 之前触发背压DATAHUB_KAFKA_SINK_QUEUE_MAX_MESSAGES20000每个 producer 本地发送缓冲区的消息数上限DATAHUB_KAFKA_SINK_LINGER_MS100producer 的linger.ms发送批聚合窗口DATAHUB_KAFKA_SINK_MAX_MESSAGE_BYTES5242880发送到 Kafka 的最大序列化消息大小字节把 librdkafka 约 1 MiB 的默认上限提升到 MCP topic 的 max必须 ≤ broker/topic 的max.message.bytesDATAHUB_KAFKA_SINK_INIT_PROBE_TIMEOUT10管道初始化时对 broker schema registry 可达性探测的每次超时秒注意CLI 的datahub ingest永不设置DATAHUB_INGESTION_DEFAULT_SINK因此 CLI 运行始终保持 REST 默认。该变量应只设置在希望走 Kafka 的那类运行上如集群内托管的 executor。3.7 DELETE / 软删除走 Kafka 的特殊处理GMS 的异步Kafka路径只接受UPSERT/UPDATE/CREATE/CREATE_ENTITY外加PATCH这些变更类型DELETE与RESTATE仅支持 REST时序timeseriesaspect 则只支持 UPSERT。因此当 Kafka 默认 Sink 生效时它会自动装配一个 REST 回退通道复用 REST Sink 同样的客户端配置把上述变更类型同步地通过 REST 发送。这一点在源码中体现为_needs_rest_fallbackdatahub_kafka.py非时序 aspect 仅当 changeType 不在_KAFKA_SUPPORTED_CHANGE_TYPESUPSERT/UPDATE/CREATE/CREATE_ENTITY/PATCH时走 REST时序 aspect 只要不是 UPSERT 就走 REST。几个关键行为务必理解有状态摄取stateful ingestion清理陈旧实体时发出的是Status(removedtrue)UPSERT因此正常走 Kafka不受回退影响——回退只处理字面的DELETE/RESTATEMCP如硬删除与非 UPSERT 时序变更普通摄取源一般不会发出这类记录两条路径的排序是尽力而为的在执行回退 DELETE 之前Sink 会先 flush 本地 producer 队列但不会等待 MCP consumer 真正应用之前的 Kafka 写入。在 consumer 滞后时同步的 REST DELETE 仍可能先于同一实体更早的 Kafka UPSERT 到达 GMS如果本次运行中此前的异步 Kafka 写入尚未确认存在 undelivered 或投递失败回退 DELETE 会被跳过并以失败上报而不是删除一个写入从未落地的实体详见_delivery_failed事件与 flush 计数逻辑因此混合变更类型且以 DELETE 为主的 recipe应优先选择 REST Sink。3.8 失败行为与可观测性文档与源码共同描述了 Kafka Sink 的失败处理策略初始化时 broker / registry 不可达选择 Kafka 默认 Sink 时会运行一次有界探测若任一端点不可达或KAFKA_BOOTSTRAP_SERVER未设置本次运行降级到 REST并打印WARNING日志。若跨多次运行持续降级说明 Kafka 已宕机、GMS 又重新承受全部写入负载——应针对此告警producer 队列打满Sink 会阻塞并轮询以施加背压而不是崩溃最长阻塞max_queue_full_block_seconds默认 300 秒后失败该次运行aspect 过大超过DATAHUB_KAFKA_SINK_MAX_MESSAGE_BYTES或 broker/topic 的max.message.bytes的 aspect 会通过投递回调上报该记录失败并计入运行失败——绝不会静默丢弃。需要更大 aspect 时应同时调大该环境变量与 topic 的限制。若配置了 REST 回退超大的 MCP 会降级为 REST 同步发送REST 端上限约 16 MiB高于 Kafka topic 的约 5 MiB运行报告Sink 报告会暴露kafka_backpressure_engagements、kafka_backpressure_blocked_seconds与kafka_undelivered三个指标定义于 datahub_kafka.py使限流与丢弃在运行摘要中可见而不仅限于日志。建议配合 MCP topic 的 consumer-lag 监控确认写入真正被消费应用。四、DataHub Lite Sink实验性本地探索首选datahub-lite提供与 DataHub Lite 的集成用于本地元数据探索与服务适合快速验证摄取结果无需启动完整的数据栈。4.1 安装pip install acryl-datahub[datahub-lite]4.2 能力与定位把元数据推送到本地 DataHub Lite 实例datahub_lite.py 中的DataHubLiteSink默认使用DuckDB作为存储后端数据库文件默认写入~/.datahub/lite/目录源码中DataHubLiteSinkConfig默认值为typeduckdb、config{file: ~/.datahub/lite/datahub.duckdb}经os.path.expanduser展开写入实现直接调用get_datahub_lite(...).write(record)。4.3 Quickstart Recipe最简单的写法零配置source: # source configs sink: type: datahub-lite指定 DuckDB 数据库文件位置source: # source configs sink: type: datahub-lite config: type: duckdb config: file: path_to_duckdb_file⚠️注意事项DataHub Lite 目前不支持有状态摄取stateful ingestion使用该 Sink 时必须在 recipe 中关闭 stateful ingestion通常在 source 配置里将stateful_ingestion.enabled置为false。文档注明该限制将很快修复。4.4 配置项全表FieldRequiredDefaultDescriptiontypeduckdb使用的 DataHub Lite 实现类型config{file: ~/.datahub/lite/datahub.duckdb}透传给 DataHub Lite 实现的配置字典DuckDB 实现接受的字段见下DuckDB 实现配置FieldRequiredDefaultDescriptionfile~/.datahub/lite/datahub.duckdbDuckDB 存储使用的数据库文件options{}透传给 DuckDB 库的选项字典支持的选项见 DuckDB 官方配置文档源码补充说明DataHub Lite 的后端抽象与本地服务能力详见 docs/datahub_lite.md。由于它面向本地轻量场景DataHubLiteSink.write_record_async仅支持 MCE 与MetadataChangeProposalWrapper类型遇到其他类型会记录 warning写入失败时通过回调上报失败成功则上报成功并计入运行报告。五、三种 Sink 的选型建议结合文档定位与源码实现给出实践选型参考场景推荐 Sink理由标准 OSS 部署、单机或少量摄取任务datahub-rest配置简单只需server错误立即可见默认ASYNC_BATCH模式已具备不错吞吐大规模、多任务、对吞吐要求高datahub-kafka异步 批量 与 GMS 解耦但要求运行环境能直连 Kafka 与 Schema Registry集群外 executor / 无法直连 Kafkadatahub-restKafka Sink 的硬性前置条件不满足时必须走 REST本地开发、快速验证摄取结果datahub-lite零部署、DuckDB 落盘无需启动任何服务需要可靠删除 / 强一致写入datahub-restSYNC模式Kafka 异步路径不支持 DELETE/RESTATE排序仅为尽力而为同时记住几个贯穿始终的原则显式sink:永远优先环境变量控制的“默认 Sink”翻转只作用于省略sink:的 recipe显式声明不会被覆盖运行报告是你的第一道监控REST Sink 报告 GMS 版本与批次拆分信息Kafka Sink 报告背压与未投递消息数摄取后应养成查看运行报告的习惯版本前提ASYNC_BATCH模式与respect_mcp_sync_marker等特性依赖较新的 GMS 服务端能力升级前请核对服务端版本支持情况。六、结语本文从安装、配置到源码原理完整梳理了 DataHub 元数据摄取的三大输出通道datahub-rest的三种模式与 Marker 同步路由、datahub-kafka的直连前提、OAuth 认证、默认 Sink 翻转与 DELETE 回退机制以及datahub-lite的本地 DuckDB 落盘。相关核心实现均可在 metadata-ingestion/src/datahub/ingestion/sink/ 目录下找到配置模型集中在 metadata-ingestion/src/datahub/configuration/env_vars.py 与 metadata-ingestion/src/datahub/emitter/ 中。掌握了这些细节你就能针对不同部署环境选择最合适的写入通道并准确解读运行报告中的每一项指标。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
