深入解析 DataHub Metadata Events（MXE）：MCP、MCL、Platform Event 与历史事件全指南

深入解析 DataHub Metadata EventsMXEMCP、MCL、Platform Event 与历史事件全指南【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub导读Metadata EventsMXE是 DataHub 元数据系统的血液循环系统——所有元数据的写入、变更通知与业务事件都通过一组以 Kafka 为载体的标准化事件在系统内部流转。本文基于 docs/what/mxe.md 展开逐一剖析 Metadata Change ProposalMCP、Metadata Change LogMCL、Platform EventPE三类核心事件的语义、Schema、Topic 与消费链路并延伸到失败事件FMCP与已废弃的 MCE/MAE/FMCE结合仓库源码与配置文件给出可落地的实践指引。读完本文你将能够准确区分各类 MXE 事件的用途与生命周期理解元数据从提议到落库再到通知下游的完整链路并学会通过 Actions Framework 等消费端能力基于这些事件构建自动化。Metadata Events 全景DataHub 的 Kafka 事件家族DataHub 依赖少量关键的 Kafka 事件完成日常运营。这些事件最初全部使用 PDL 目录下包括MetadataChangeProposal.pdlMCPMetadataChangeLog.pdlMCL继承 MCP 并扩展PlatformEvent.pdl与PlatformEventHeader.pdl、GenericPayload.pdlPEFailedMetadataChangeProposal.pdlFMCP已废弃的MetadataChangeEvent.pdl、MetadataAuditEvent.pdl、FailedMetadataChangeEvent.pdl支撑性结构GenericAspect.pdl、SystemMetadata.pdl、DataHubUpgradeHistoryEvent.pdl等三类最重要的当代事件是Metadata Change ProposalMCP——对元数据图变更的提议Metadata Change LogMCL——已发生的变更日志分为 Versioned 与 Timeseries 两种Platform EventPE——DataHub 自身产生的业务逻辑事件。MCP 与 MCL 呈提议—落库—通知的因果链MCP 被接受并提交后系统才发出对应的 MCLMCP 处理失败则产生 FMCP。理解这一关系是理解整套事件体系的关键。Metadata Change ProposalMCP元数据变更的请求语义一次对单个 aspect 的变更请求一个 MCP 代表对某个企业元数据图Metadata Graph上特定 aspect的一次变更请求。每个 MCP 为给定的 aspect 提供一个新值。例如一个单独的 MCP 就可以完成数据资产的所有权ownership、文档documentation、域domain或弃用状态deprecation的变更。值得强调的是 aspect 的定义它是一种结构化文档PDL 中的record表示特定种类的元数据如 ownership、schema、statistics、upstreams本身没有独立含义必须关联到某个实体entity才有意义。详细模型见 docs/what/aspect.md。生产Emission谁发出 MCPMCP 由 DataHub 低层摄取 API 的客户端例如各类 ingestion source在元数据摄取过程中发出。DataHub Python API 提供了便捷接口来发送 MCP——核心封装是 metadata-ingestion/src/datahub/emitter/mcp.py 中的MetadataChangeProposalWrapper通过 kafka_emitter.py 中的DatahubKafkaEmitter或 REST emitter 发送到 DataHub。值得注意的工程细节见 kafka_emitter.pyKafka 生产端对消息大小有限制topic 约 5 MiB对应配置MAX_MESSAGE_BYTES默认 5242880而 REST 接口可接受约 16 MiB当序列化消息超过 Kafka 上限时sink 会降级走 REST 回退而不是让整个摄取任务失败。此外 kafka_emitter.py 中的topic_routes允许分别配置 MCE 与 MCP 的目标 topic。MCP 的默认 Kafka topic 名为MetadataChangeProposal_v1。消费Consumption谁处理 MCPDataHub 的存储层持续监听新的 MCP尝试将请求的变更应用到元数据图。从源码看这一职责落在metadata-jobs/mce-consumer模块核心处理器 MetadataChangeProposalConsumer.java 将 Avro 记录反序列化为MetadataChangeProposalEventUtils.avroToPegasusMCP然后调用entityClient.ingestProposal(eventContext, event, false)执行落库一旦处理过程抛出异常则通过eventProducer.produceFailedMetadataChangeProposal(...)将事件转发至失败 topic见 MetadataChangeProposalConsumer.java。Schema 与字段说明MCP 的字段定义在 MetadataChangeProposal.pdl核心字段如下NameTypeDescriptionOptionalentityUrnString被变更实体的唯一标识例如某个 Dataset 的 URNFalseentityTypeString新 aspect 关联的实体类型对应 DataHub Entity Registry 中的实体名例如datasetFalseentityKeyAspectObject被变更实体的 key 结构。仅当 MCP 携带原始 key 结构时才出现TruechangeTypeString变更类型。当前支持 CREATE、UPSERT、DELETEPATCH 仅对特定 aspect 有有限支持FalseaspectNameString被变更的实体 aspect 名称FalseaspectObject新的 aspect 值。若 aspect 被删除则为 NullTrueaspect.contentTypeStringaspect 的序列化类型当前唯一支持application/jsonFalseaspect.valueString序列化后的 aspect是 PDL 定义文档的 JSON 序列化形式FalsesystemMetadataObject新的系统元数据包含摄取 run-id、model registry 等TruePDL 定义中的几个关键设计值得展开见 MetadataChangeProposal.pdlauditHeader: optional KafkaAuditHeader——Kafka 审计头开源版本目前未使用entityUrn与aspectName在 PDL 中均为optional当不填 aspectName 时表示写入方意图作用于整个实体仅对 CREATE、UPSERT、DELETE 有效headers: optional map[string, string]——模仿 HTTP 头的键值对可附加自定义元数据changeType的完整枚举定义在 ChangeType.pdl包括UPSERT存在则更新不存在则插入、CREATE不存在则插入存在则失败、UPDATE目前不支持、DELETE、PATCH增量修补而非整体替换、RESTATE例如索引刷新时重述 aspect、CREATE_ENTITY实体不存在则插入否则失败。aspect字段的类型是 GenericAspect.pdl 定义的GenericAspectvalue: bytes保存序列化后的 aspect 内容contentType: string标明序列化方式当前仅支持application/json。MCP 示例更新 Dataset 的 ownership{ entityType: dataset, entityUrn: urn:li:dataset:(urn:li:dataPlatform:hdfs,SampleHdfsDataset,PROD), changeType: UPSERT, aspectName: ownership, aspect: { value: {\owners\:[{\type\:\DATAOWNER\,\owner\:\urn:li:corpuser:datahub\}],\lastModified\:{\actor\:\urn:li:corpuser:datahub\,\time\:1651516640488}}, contentType: application/json }, systemMetadata: { lastObserved: 1651516640493, runId: no-run-id-provided, registryName: unknownRegistry, registryVersion: 0.0.0.0-dev, properties: null } }注意 aspect 载荷以 JSON 字符串形式序列化在value字段内。aspect 的确切结构由其 PDL Schema 决定例如这里的 ownership 结构由 metadata-models/src/main/pegasus/com/linkedin/common/Ownership.pdl 定义。systemMetadata的完整结构在 SystemMetadata.pdl 中定义除示例中出现的字段外还包括字段类型默认值含义lastObservedlong0元数据被观测到的时间戳runIdstringno-run-id-provided产生该元数据的原始 run id批量摄取时填充lastRunIdstringno-run-id-provided产生该元数据的最近一次 run idpipelineNamestring—产生元数据的摄取管道 idregistryName / registryVersionstring—处理该事件所使用的 model registry 名称与版本propertiesmap[string, string]—附加属性versionstring—aspect 版本schemaVersionlong1aspect 数据模型的 schema 版本用于判断是否需要迁移aspectCreated / aspectModifiedAuditStamp—aspect 的创建时间与最近修改时间及操作者Metadata Change LogMCL元数据变更的日志语义Versioned 与 Timeseries 两种 aspectMCL 代表已经发生的对元数据图的任何变更。MCL 事件在变更写入持久化存储后立即被发出到 Kafka。MCL 有两种形态对应被更新 aspect 的类型Versioned版本化aspect表示某些属性的最新状态例如一个资产最近的所有者或文档Timeseries时间序列aspect表示与资产相关的、发生在特定时间的事件例如对 Dataset 的 profiling 结果。这一区分的直接证据系统为 MCL 维护两个不同的 Kafka topic默认名分别为MetadataChangeLog_Versioned_v1版本化与MetadataChangeLog_Timeseries_v1时间序列。在 application.yaml 中可以看到Timeseries topic 额外设置了retention.ms: 777600000090 天的保留策略而 Versioned topic 则未设置该属性——这与版本化 aspect 需要长期保留最新状态、时间序列 aspect 属于短期事件流的语义完全吻合。生产EmissionMCL 在元数据图上的实体发生任何变更时发出包括对实体任意 aspect 的写入。发出动作发生在变更被持久化之后。消费Consumptionmae-consumer-job 与 Actions FrameworkDataHub 内置一个 Kafka 消费者任务mae-consumer-jobmetadata-jobs/mae-consumer-job监听 MCL 并用其更新 DataHub 的搜索索引search index与图索引graph index同时生成派生的 Platform Events见下文。该模块的 README.md 明确指出它当前消费两个重要 topicMetadataChangeLog_Versioned_v1MetadataChangeLog_Timeseries_v1为什么叫 MetadataAuditEvent Consumer纯粹是历史遗留这个任务此前消费的是已被废弃并从关键路径移除的单一MetadataAuditEventtopic名字就这样保留了下来见 metadata-jobs/mae-consumer-job/README.md。独立部署该任务的方式见 metadata-jobs/mae-consumer-job/README.md# 仅构建该模块 ./gradlew :metadata-jobs:mae-consumer-job:build # 直接命令行启动无需构建 Docker 镜像 MCL_CONSUMER_ENABLEDtrue ./gradlew :metadata-jobs:mae-consumer-job:bootRun启动后可通过 Spring Boot Actuator 检查健康状态与指标默认端口 9091健康检查http://localhost:9091/actuator/health指标http://localhost:9091/actuator/metrics此外Actions Framework 也消费 MCL用于支撑其 Metadata Change Log 事件 API。该事件在 Actions 中的类型名为MetadataChangeLogEvent_v1。Schema 与字段说明MCL 的 PDL Schema 是 MetadataChangeLog.pdl它直接includes MetadataChangeProposal继承 MCP 的全部字段并额外增加三个字段NameTypeDescriptionOptionalentityUrnString被变更实体的唯一标识FalseentityTypeString新 aspect 关联的实体类型对应 Entity Registry 实体名如datasetFalseentityKeyAspectObject被变更实体的 key 结构仅当 MCP 携带原始 key 结构时出现TruechangeTypeString变更类型当前支持 CREATE、UPSERT、DELETEFalseaspectNameString被变更的 aspect 名称FalseaspectObject新的 aspect 值删除则为 NullTrueaspect.contentType / aspect.valueString序列化类型application/json与序列化内容FalsepreviousAspectValueObject变更前的 aspect 值若此前不存在则为 NullTruepreviousAspectValue.contentType / previousAspectValue.valueString同 aspect 的序列化规则FalsesystemMetadataObject新的系统元数据TruepreviousSystemMetadataObject变更前的系统元数据TruecreatedObject关于谁在何时触发变更的审计戳Falsecreated.timeNumberaspect 变更发生时的毫秒时间戳Falsecreated.actorString触发变更的 actor如 corpuser的 URNFalse在 Actions 侧的文档 metadata-change-log-event.md 中changeType还列出了 RESTATE 等取值并明确提示MCL 事件能力强大但属于低层事件直接暴露底层元数据模型结构与语义的变化比高层事件更频繁建议在可行时优先使用 Entity Change Event见下文。MCL 示例ownership aspect 变更前后的完整对照{ entityType: dataset, entityUrn: urn:li:dataset:(urn:li:dataPlatform:hdfs,SampleHdfsDataset,PROD), changeType: UPSERT, aspectName: ownership, aspect: { value: {\owners\:[{\type\:\DATAOWNER\,\owner\:\urn:li:corpuser:datahub\}],\lastModified\:{\actor\:\urn:li:corpuser:datahub\,\time\:1651516640488}}, contentType: application/json }, previousAspectValue: { value: {\owners\:[{\owner\:\urn:li:corpuser:jdoe\,\type\:\DATAOWNER\},{\owner\:\urn:li:corpuser:datahub\,\type\:\DATAOWNER\}],\lastModified\:{\actor\:\urn:li:corpuser:jdoe\,\time\:1581407189000}}, contentType: application/json }, systemMetadata: { lastObserved: 1651516640493, runId: no-run-id-provided, registryName: unknownRegistry, registryVersion: 0.0.0.0-dev, properties: null }, previousSystemMetadata: { lastObserved: 1651516415088, runId: file-2022_05_02-11_33_35, registryName: null, registryVersion: null, properties: null }, created: { time: 1651516640490, actor: urn:li:corpuser:datahub, impersonator: null } }对比 MCP 示例可以发现MCL 通过previousAspectValue/previousSystemMetadata提供变更前快照通过created提供审计信息这正是日志与提议的本质区别。Actions 侧的文档还提供了 Tag 变更、Glossary Term 变更等更多 MCL 示例见 metadata-change-log-event.md。Platform EventPEDataHub 的业务逻辑事件语义与类型Platform Event 代表 DataHub 发出的任意业务逻辑事件。每个 Platform Event 都有一个name由其决定事件内容。最重要的 Platform Event 是Entity Change EvententityChangeEvent它记录 DataHub 上发生的语义级变更标签添加/移除、弃用状态变更等是 Actions Framework 的重要组件。所有已注册的 Platform Event 类型都声明在 DataHub 的 Entity Registryentity-registry.yml中。从 PlatformEvent.pdl 看PE 的结构极简header: PlatformEventHeader、name: string、payload: GenericPayload三个字段。其中PlatformEventHeader.pdl 仅含timestampMillis: long事件生成的 UTC 毫秒时间戳GenericPayload.pdl 与GenericAspect同构value: bytescontentType: string仅支持application/json。Entity Change Event 的结构定义在 metadata-models/src/main/pegasus/com/linkedin/platform/event/v1/EntityChangeEvent.pdl它通过Event {name: entityChangeEvent}注解与 PE 的name字段挂钩字段包括entityType、entityUrn、categoryTAG、GLOSSARY_TERM、OWNERSHIP、TECHNICAL_SCHEMA 等、operation、modifier、parameters、auditStamp与version。生产与消费所有 Platform Event 都由 DataHub 自身在正常运行过程中生成。PE 非常动态——根据name的不同可以包含任意载荷因此可在多种场景下产生。默认 topic 名为PlatformEvent_v1。生产端的关键实现是 PlatformEventGeneratorHook.java它以MetadataChangeLogHook的形式挂载在 mae-consumer 消费 MCL 的链路上通过EntityChangeEventGeneratorRegistry中注册的各类生成器把低层 MCL 转译为语义化的 Entity Change Event 并调用emitPlatformEvent(...)发出PlatformEventGeneratorHook.java。该 Hook 还支持配置开关entityChangeEvents.enabled默认 true与entityChangeEvents.entityExclusions等参数。消费端Actions Framework 消费 Platform Events 来支撑其 Entity Change Event APIActions 侧事件类型名为EntityChangeEvent_v1。Schema 与示例NameTypeDescriptionOptionalheaderObject头部字段Falseheader.timestampMillisLong事件生成的时间FalsenameString事件名称/类型FalsepayloadObject事件本身Falsepayload.contentTypeString载荷序列化类型仅支持application/jsonFalsepayload.valueString序列化载荷为 PDL 定义文档的 JSON 序列化形式False以下是一个给 Dataset 新增 owner时发出的 Entity Change Event 示例{ header: { timestampMillis: 1655390732551 }, name: entityChangeEvent, payload: { value: {\entityUrn\:\urn:li:dataset:abc\,\entityType\:\dataset\,\category\:\OWNER\,\operation\:\ADD\,\modifier\:\urn:li:corpuser:jdoe\,\parameters\:{\ownerUrn\:\urn:li:corpuser:jdoe\,\ownerType\:\BUSINESS_OWNER\},\auditStamp\:{\actor\:\urn:li:corpuser:jdoe\,\time\:1649953100653}}, contentType: application/json } }与 MCP/MCL 相同实际载荷以 JSON 字符串形式内嵌在payload.value中其确切结构由 PDL Schema 决定见 EntityChangeEvent.pdl。Entity Change Event 的完整事件目录非常丰富在 docs/actions/events/entity-change-event.md 中有系统性记录常见组合包括categoryoperation 示例说明TAGADD / REMOVE标签添加/移除GLOSSARY_TERMADD / REMOVE术语添加/移除DOMAINADD / REMOVE域添加/移除OWNERADD / REMOVE所有者添加/移除STRUCTURED_PROPERTYADD / REMOVE / MODIFY结构化属性操作DEPRECATIONMODIFY弃用状态修改TECHNICAL_SCHEMAADD / REMOVESchema 字段增删LIFECYCLECREATE / SOFT_DELETE / HARD_DELETE实体生命周期此外还包含以entityType: actionRequest表示、LIFECYCLECREATE的审批类提案事件如 DOMAIN_ASSOCIATION、OWNER_ASSOCIATION、TAG_ASSOCIATION、UPDATE_DESCRIPTION 等用于数据访问工作流以及WORKFLOW_FORM_REQUEST类型的审批工作流事件。Failed Metadata Change ProposalFMCP失败提议的死信队列当一个 MCP 无法被成功处理时事件会被写入死信队列Dead Letter Queue形成Failed Metadata Change ProposalFMCP。FMCP 事件简单地包装了原始的 MCP 与一条错误信息包含被拒绝的原因。该事件可用于调试潜在的摄取问题也可用于在必要时重新回放之前被拒绝的提议。生产当 MCP 无法成功提交到 DataHub 存储层时发出。默认 topic 名为FailedMetadataChangeProposal_v1。生产逻辑位于 MetadataChangeProposalConsumer.java 的异常分支——调用eventProducer.produceFailedMetadataChangeProposal(eventContext, List.of(event), throwable)消费当前没有活跃消费者Schema见 FailedMetadataChangeProposal.pdl结构为metadataChangeProposal: MetadataChangeProposalerror: string失败原因或堆栈。已废弃事件MCE、MAE 与 FMCEDataHub 还随附一组历史上用于提议与记录元数据图变更的废弃事件。这批事件被废弃的根本原因是灵活性不足——每当引入新 aspect 时都必须更新 Schema它们已被上文所述的更灵活的 MCP / MCL 取代。不建议基于废弃事件构建依赖。Metadata Change EventMCEMCE 代表一次针对同一实体的多个 aspect的变更请求。它利用了已废弃的Snapshot概念——即同一实体的强类型 aspect 列表。MCE 是元数据变更的提议与 MAE传达已提交的变更相对因此只有被成功接受并处理的 MCE 才会导致对应的 MAE / MCL 发出。生产由低层摄取 API 客户端如 ingestion source在元数据摄取期间发出默认 topic 为MetadataChangeEvent_v4消费DataHub 存储层监听并尝试应用变更Schema见 MetadataChangeEvent.pdl。MCE 示例变更某个 Dataset 的 ownership{ proposedSnapshot: { com.linkedin.pegasus2avro.metadata.snapshot.DatasetSnapshot: { urn: urn:li:dataset:(urn:li:dataPlatform:hive,SampleHiveDataset,PROD), aspects: [ { com.linkedin.pegasus2avro.common.Ownership: { owners: [ { owner: urn:li:corpuser:jdoe, type: DATAOWNER, source: null }, { owner: urn:li:corpuser:datahub, type: DATAOWNER, source: null } ], lastModified: { time: 1581407189000, actor: urn:li:corpuser:jdoe, impersonator: null } } } ] } } }注意与 MCP 的显著差异MCE 使用完整限定类名如com.linkedin.pegasus2avro.metadata.snapshot.DatasetSnapshot作为快照与 aspect 的键结构上是强类型嵌套这正是其新增 aspect 必须改 Schema这一僵硬性的来源。Metadata Audit EventMAEMAE 以变更前快照 变更后快照的形式捕获与某个特定 entity 关联的一个或多个元数据 aspect 的变更快照概念见 snapshot.md。每一个特定 metadata aspect 的事实来源source-of-truth都应在对该 aspect 的变更被提交时发出 MAE——这样任何 MAE 的监听者都能构建出所有 aspect 最新状态的完整视图同时由于每个 MAE 都包含变更后镜像发射错误可通过补发修正后的 MAE 轻易纠正新实体的初始引导问题也可以通过包含其全部最新 aspect 的 MAE 解决。注意在较新的 DataHub 版本中2022 年中起MAE 已不再活跃发出并将很快从 DataHub 中完全移除。请改用 Metadata Change Log。生产MAE 在元数据变更成功提交到存储层后发出默认 topic 为MetadataAuditEvent_v4当前已不再活跃发出消费无活跃消费者Schema见 MetadataAuditEvent.pdl。MAE 示例移除 Dataset 的一个 owner{ oldSnapshot: { com.linkedin.pegasus2avro.metadata.snapshot.DatasetSnapshot: { urn: urn:li:dataset:(urn:li:dataPlatform:hive,SampleHiveDataset,PROD), aspects: [ { com.linkedin.pegasus2avro.common.Ownership: { owners: [ { owner: urn:li:corpuser:jdoe, type: DATAOWNER, source: null }, { owner: urn:li:corpuser:datahub, type: DATAOWNER, source: null } ], lastModified: { time: 1581407189000, actor: urn:li:corpuser:jdoe, impersonator: null } } } ] } }, newSnapshot: { com.linkedin.pegasus2avro.metadata.snapshot.DatasetSnapshot: { urn: urn:li:dataset:(urn:li:dataPlatform:hive,SampleHiveDataset,PROD), aspects: [ { com.linkedin.pegasus2avro.common.Ownership: { owners: [ { owner: urn:li:corpuser:datahub, type: DATAOWNER, source: null } ], lastModified: { time: 1581407189000, actor: urn:li:corpuser:jdoe, impersonator: null } } } ] } } }Failed Metadata Change EventFMCE当 MCE 无法被成功处理时事件被写入死信队列形成Failed Metadata Change EventFMCE。与 FMCP 相同它包装了原始 MCE 与包含拒绝原因的错误信息可用于调试摄取问题与回放被拒绝的提议。生产MCE 无法成功提交到存储层时发出消费无活跃消费者Schema见 FailedMetadataChangeEvent.pdl默认 topic 为FailedMetadataChangeEvent_v4。事件拓扑与配置Topic 名称一览所有核心 MXE topic 均可通过环境变量覆盖默认配置集中在 application.yaml。汇总如下事件程序化标识默认 topic 名可覆盖环境变量默认分区默认副本MCPmetadataChangeProposalMetadataChangeProposal_v1METADATA_CHANGE_PROPOSAL_TOPIC_NAME${PARTITIONS:1}${REPLICATION_FACTOR:1}FMCPfailedMetadataChangeProposalFailedMetadataChangeProposal_v1FAILED_METADATA_CHANGE_PROPOSAL_TOPIC_NAME同上同上MCLVersionedmetadataChangeLogVersionedMetadataChangeLog_Versioned_v1METADATA_CHANGE_LOG_VERSIONED_TOPIC_NAME同上同上MCLTimeseriesmetadataChangeLogTimeseriesMetadataChangeLog_Timeseries_v1METADATA_CHANGE_LOG_TIMESERIES_TOPIC_NAME同上同上另设retention.ms: 7776000000PEplatformEventPlatformEvent_v1PLATFORM_EVENT_TOPIC_NAME同上同上MCE废弃—MetadataChangeEvent_v4———MAE废弃—MetadataAuditEvent_v4———FMCE废弃—FailedMetadataChangeEvent_v4———全局默认分区数与副本数分别由PARTITIONS默认 1与REPLICATION_FACTOR默认 1控制消息大小上限由MAX_MESSAGE_BYTES默认 5242880即 5 MiB控制见 application.yaml。总结如何选择与使用 MXE 事件场景推荐事件理由通过编程方式向 DataHub 写入/变更元数据MCP单 aspect 粒度的提议Schema 灵活Python API 与 ingestion source 均以其为默认通道实时监听所有元数据变更低层MCL包含变更前后快照与审计信息是 mae-consumer 更新搜索/图索引的输入构建基于语义变更的自动化如标签/owner/弃用通知Entity Change EventPE语义化、稳定的高层事件Actions Framework 原生支持推荐优先使用调试摄取失败、回放被拒提议FMCP死信队列包装了原始 MCP 与错误原因旧系统兼容MCE / MAE / FMCE已废弃Schema 僵硬不建议新依赖一句话概括整条链路MCP 提出变更 → 存储层接受并落库 → MCL 记录变更并驱动索引/派生事件 → PE 将低层变更转译为语义化业务事件供 Actions 消费任何一步失败则由 FMCP/FMCE 捕获并进入死信队列。掌握这套事件体系你就掌握了 DataHub 元数据流动的底层规律无论是排查摄取问题、自研下游消费者还是基于 Actions 构建数据治理自动化都能有的放矢。延伸阅读仓库内docs/what/aspect.md元数据 aspect 的定义、不可变性与版本化docs/what/entity.md、docs/what/snapshot.mdentity 与 snapshot 概念理解废弃事件所必需docs/actions/README.mdActions Framework 总览docs/actions/events/metadata-change-log-event.mdMCL 事件的 Actions 侧 API 与更多示例docs/actions/events/entity-change-event.mdEntity Change Event 完整事件目录metadata-models/src/main/pegasus/com/linkedin/mxe全部 MXE 的 PDL Schemametadata-jobs/mce-consumerMCP 消费与落库实现metadata-jobs/mae-consumer-jobMCL 消费任务索引更新 Platform Event 生成metadata-service/configuration/src/main/resources/application.yamlKafka topic 默认配置与覆盖环境变量【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考