Amazon Kinesis 数据源深度指南Firehose 跨平台血缘、Glue Schema Registry 与排障实战【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub本文基于 DataHub 官方kinesis数据源文档kinesis_post.md并结合仓库源码、配置与测试用例编写全面覆盖 Kinesis 连接器的 Capabilities、Firehose 跨平台血缘、Glue 表血缘、GSR 模式注册、过滤、标签所有权派生、Limitations 与 Troubleshooting。引言为什么需要一份面向 Kinesis 连接器的深度指南AWS 实时数据管道中Kinesis Data StreamsKDS负责缓冲与分发Amazon Data Firehose 负责将数据投递到 S3、Redshift、Snowflake、Iceberg、MongoDB、OpenSearch 等目标平台。DataHub 的kinesis连接器用一个 recipe、一份 IAM 策略、一个 ingestion job 同时接入这两类服务KDS 流以DatasetStream子类型入库携带区域 Container、StreamARN、分片数、保留期、加密与流模式等 custom propertiesFirehose 流以DataFlowFirehose Stream子类型入库内含单个DataJobDelivery子类型其dataJobInputOutput血缘边连接源 Kinesis 流与目标平台。因此本文深入讲解Firehose 六种支持的目的地及其 URN 格式destination_platform_map跨平台 URN 覆盖机制Glue 表血缘Parquet/ORC 格式转换Glue Schema RegistryGSR模式解析与use_naming_convention的取舍流/Firehose 过滤、标签所有权派生已知限制与常见故障排查。读完本文你将能正确配置 Kinesis 连接器、避免“血缘边存在但目标 URN 无效”的坑并理解其内部实现。Capabilities 总览Kinesis 连接器在源码KinesisSource类上声明了以下能力kinesis.pyCapability说明状态Descriptions默认启用生成实体描述Enabled by defaultContainers区域级 ContainerRegion containersLineage (coarse)Firehose → 目标平台血缘Firehose - destination lineageTags从 AWS 资源标签生成 DataHub globalTagsFrom AWS resource tagsSchema Metadata通过 GSR 解析 schemaAvro / JSON / ProtobufOpt-in viaglue_schema_registry.enabledDeletion Detection基于 stateful ingestion 的软删除Via stateful ingestion从源码结构看连接器模块位于 metadata-ingestion/src/datahub/ingestion/source/kinesis/包含kinesis.py—— 主入口与 region container、account_id 解析kinesis_config.py—— 配置模型与destination_platform_map/ GSR 配置kinesis_stream.py—— KDS 提取器kinesis_firehose.py—— Firehose 提取器与 DataJob 血缘组装kinesis_firehose_destinations.py—— 目的地 URN 处理器注册表kinesis_schema_registry.py—— GSR 解析器kinesis_tagging.py—— AWS 标签 → globalTags 工具kinesis_report.py—— 报告字段。Firehose 血缘支持的目的地六种支持的 AWS 目的地Firehose 投递目标平台会产生dataJobInputOutput.outputDatasets血缘边。以下目的地类型受支持文档表格AWS destinationDataHub 平台URN 格式Amazon S3 / Extended S3s3urn:li:dataset:(urn:li:dataPlatform:s3,bucket[/prefix],...)Amazon Redshiftredshifturn:li:dataset:(urn:li:dataPlatform:redshift,db.schema.table,...)Amazon OpenSearch / Elasticsearchelasticsearchurn:li:dataset:(urn:li:dataPlatform:elasticsearch,index,...)Snowflakesnowflakeurn:li:dataset:(urn:li:dataPlatform:snowflake,db.schema.table,...)Apache Icebergicebergurn:li:dataset:(urn:li:dataPlatform:iceberg,namespace.table,...)MongoDBmongodburn:li:dataset:(urn:li:dataPlatform:mongodb,database.collection,...)URN 名称默认统一小写与 Snowflake 源默认convert_urns_to_lowercaseTrue保持一致。如需按目的地覆盖通过destination_platform_map.platform.convert_urns_to_lowercase: false关闭。注意不支持的 Firehose 目的地HTTP、Datadog、Splunk、New Relic、Coralogix、LogicMonitor、Dynatrace、Honeycomb、Sumo Logic 等不会产生血缘边 —— 连接器记录一条 “Unsupported Firehose destination” 警告并将目的地配置作为 custom property 记在 DataJob 上DataJob 本身仍会生成。源码实现印证在 kinesis_firehose_destinations.py 中每个目的地都有对应的DestinationHandler子类S3Destination/ExtendedS3Destination/RedshiftDestination/OpenSearchDestination/SnowflakeDestination/IcebergDestination/MongoDBDestination它们通过matches()匹配 boto3DescribeDeliveryStream返回的 destination block再用build_urns()构造 URN。DESTINATION_HANDLERS注册表按“先匹配 modern S3、再匹配 legacy”的顺序排列。关键细节源码注释明确S3 处理器同时处理 legacyS3DestinationDescription与 modernExtendedS3DestinationDescription二者共享BucketARNPrefix键_build_s3_urn在 BucketARN 缺失时返回空列表防御urn:li:dataset:(s3,,PROD)这类畸形 URN。Redshift 处理器从CopyCommand.DataTableName取schema.table从ClusterJDBCURL解析数据库名数据库或表名缺失时拒绝生成 URN避免urn:li:dataset:(redshift,my_table,PROD)这种语法合法但语义错误的 URN。OpenSearch 处理器同时匹配 boto3 的AmazonopensearchserviceDestinationDescription老账户的 AWS 公共 API 名与ElasticsearchDestinationDescription。Iceberg 是唯一支持“单条投递流 → 多张目标表”的目的地DestinationTableConfigurationList是列表V1 假设 REST catalog 的点分隔 namespace 格式。跨平台血缘destination_platform_mapFirehose 目的地位于其他平台S3、Redshift、Snowflake 等因此 Kinesis 产生的血缘 URN 必须与这些平台自己的 DataHub 源的 URN 约定一致。destination_platform_map允许按目的地覆盖 URN 参数destination_platform_map: snowflake: platform_instance: prod-snowflake-east env: PROD # 仅当 Snowflake 源 recipe 也设置了 convert_urns_to_lowercase: false 时才需要 convert_urns_to_lowercase: false redshift: platform_instance: analytics-cluster env: PROD iceberg: # Iceberg catalog 区分大小写 —— 关闭小写化以保留原大小写 convert_urns_to_lowercase: false每个目的地平台有三个可调参数platform_instance—— 必须与目的地平台自己的源 recipe 中使用的字符串一致。否则 Firehose 血缘边会指向 DataHub UI 中无法解析的死 URN。env——PROD/DEV等。未设置时继承本源的env。convert_urns_to_lowercase—— 默认true。对于区分大小写的目的地Iceberg、MongoDB或使用自身convert_urns_to_lowercasefalse导入的 Snowflake / Redshift 源设为false。源码实现印证在 kinesis_config.py 中DestinationPlatformDetail定义了这三个字段其中env会被自动大写并校验为合法 FabricTypePROD/DEV/QA/STG 等与顶层env的处理保持一致。destination_platform_map的键被约束为DestinationPlatformLiterals3/redshift/elasticsearch/snowflake/iceberg/mongodb/glue未知键在解析时直接报错从源头杜绝拼写错误。在 kinesis_firehose.py 的_destination_urn中实现了覆盖逻辑detail self.config.destination_platform_map.get(platform) platform_instance detail.platform_instance if detail else None resolved_env env or (detail.env if detail and detail.env else self.config.env) if detail is None or detail.convert_urns_to_lowercase: name name.lower() return make_dataset_urn_with_platform_instance(...)注意convert_urns_to_lowercase的默认值同样是true对齐 Snowflake 源只有当 map 中显式设置false时才跳过小写化。测试验证test_kinesis_firehose.py 中test_destination_platform_map_overrides_snowflake_instance验证了platform_instance会被折叠进 URN 名称前缀prod-sf.db.s.tTestDestinationUrnCaseFolding类则专门验证默认小写化与按目的地关闭小写化的行为。配置层面的校验在 test_kinesis_config.py未知平台如datadog会在启动时报错glue作为合法的 map 键也被显式支持。Glue 表血缘Firehose 格式转换当 Firehose 流启用了Parquet/ORC 格式转换时其SchemaConfiguration会引用一张 Glue 表来定义输出 schema。连接器会把它作为 Firehose delivery DataJob 的第二个上游输入暴露出来源 Kinesis 流仍是输入既有行为目标 S3 路径仍是输出既有行为Glue 表被添加为第二个输入 —— 它的 schema 决定了写入 S3 路径的内容。要让 Glue 表 URN 被发出SchemaConfiguration必须包含DatabaseName和TableName。CatalogId不是必须的—— 当它与调用者账户相同时AWS 会在DescribeDeliveryStream响应中省略它按 AWS 文档它是 input-side default。存在SchemaConfiguration但缺少DatabaseName/TableName的情况会被记录到 source report 的firehose_glue_schema_skipped字段中用于诊断。如果 Glue catalog 是在非默认platform_instance下导入的需要设置覆盖destination_platform_map: glue: platform_instance: central-catalog env: PROD整个行为由include_table_lineage标志控制 —— 关闭时不会发出任何 Glue 血缘。源码实现印证在 kinesis_firehose_destinations.py 中ExtendedS3Destination.extract_schema_config_glue_urn从DataFormatConversionConfiguration.SchemaConfiguration读取DatabaseName/TableName构造urn:li:dataset:(glue,db.table,env)格式的 URN缺失字段时通过report_firehose_glue_schema_skipped记录原因。在 kinesis_firehose.py 中_process_destination会对ExtendedS3Destination调用该方法并把返回的 Glue URN追加到 inputs上游—— 因为该表的 schema 决定写入内容S3 路径仍是数据目的地。流与 Firehose 流过滤stream_pattern和firehose_stream_pattern使用标准 DataHubAllowDenyPattern结构。一个常见的 deny 规则用于排除内部 / 审计 / 调试流stream_pattern: deny: - ^_.* - .*-debug$stream_pattern过滤 Kinesis Data Streamsinclude_streams: true时生效firehose_stream_pattern过滤 Firehose 流include_firehose: true时生效。被过滤的流会记录在 report 的filtered_streams/filtered_firehose_streams字段中kinesis_report.py。从标签派生所有权连接器将 AWS 资源标签发布为 DataHubglobalTagsKeyValue变为urn:li:tag:Key:Value仅 Key 的标签变为urn:li:tag:Key。要把标签转成所有权请应用内置的extract_ownership_from_tagstransformer —— 这使所有权处理与 DataHub 其他源保持一致而不是在每个连接器里重新实现。例如把owner标签的值当作 corpuser 所有者transformers: - type: extract_ownership_from_tags config: tag_pattern: owner:该 transformer 还支持 corp group、owner types以及追加 email domain —— 完整选项见 dataset_transformer.md如owner_type、owner_type_urn、email_domain、extract_owner_type_from_tag_pattern等配置项。从源码看所有权刻意不在连接器内派生 —— kinesis_tagging.py 的注释明确说明它由extract_ownership_from_tagstransformer 通用地处理连接器只负责把 AWS 标签展平为GlobalTagsClass。Glue Schema RegistryGSRGSR 是可选开启的因为它需要额外的 IAM 权限glue:Get*/glue:List*。开启与关闭的差别关闭默认—— 流在没有schemaMetadataaspect 的情况下发出。所有其他元数据properties、tags、ownership、lineage不受影响也不需要glue:*权限。开启—— 对每个能解析出 schema 的流见下面的解析顺序连接器从 AWS Glue Schema Registry 获取 schema 并附带schemaMetadataaspect解析字段支持 Avro / JSON / Protobuf。解析不到 schema 的流仍会发出只是没有schemaMetadata—— 开启 GSR 永远不会丢流。需要GlueSchemaRegistryReadIAM statement。开启配置glue_schema_registry: enabled: true registry_name: default-registry # 推荐显式声明已知的 stream - schema 关联 stream_schema_map: events: events-v2 clicks: click-events-schema # 可选启发式 —— 见下文说明 use_naming_convention: false每个流的 schema 解析顺序如果流名是stream_schema_map的键使用映射的 schema 名否则如果use_naming_convention: true在配置的registry_name中查找与流名同名的 schema否则不带schemaMetadata发出该流。为什么 use_naming_convention 默认关闭与 Kafka Confluent Schema Registry定义了标准化的TopicNameStrategy即topic-key/-valuesubject 命名不同AWS 没有定义 Kinesis Data Stream 与 Glue schema 之间的任何关系。schema 由生产者按记录选择GlueSchemaRegistrySerializer会把 schema-id 嵌入每条记录流本身没有 schema 绑定。多个生产者可以用不同 schema 写入同一个流一个 schema 也可以被多个流复用。有些组织把 “schema 名 流名” 作为内部约定但这并非 AWS 最佳实践。如果你的组织遵循该约定可以设置use_naming_convention: true否则在stream_schema_map中声明已知关联 —— 这是最可预测的模式。对于启用了 Parquet/ORC 格式转换的Firehose流AWS 确实通过SchemaConfiguration定义了关系 —— 见上文 Glue 表血缘。该提取默认开启不受此标志影响。源码实现印证kinesis_config.py 中的KinesisGlueSchemaRegistryConfig有一个重要的 model validator当enabledfalse却设置了stream_schema_map或use_naming_convention时直接抛配置错误—— 因为这两个激活开关在禁用状态下是静默无效的用户几乎必然是“本想开启 GSR”。registry_name因有非空默认值而不作为激活信号。kinesis_schema_registry.py 实现了解析逻辑_resolve_schema_name先查stream_schema_map再按命名约定回退get_schema_metadata调用glue:GetSchemaVersionSchemaVersionNumber{LatestVersion: True}命名约定探针未命中EntityNotFoundException且非显式映射是预期结果记录到gsr_naming_convention_misses字段而不产生 WARNING 噪音而显式映射失败、AccessDenied、ValidationException 等真实错误会记入schema_resolution_failures并产生警告。测试方面test_kinesis_config.py 覆盖了禁用时get_schema_metadata短路不做任何 Glue 调用、命名约定关闭时不解析、以及“配置了但未启用”在启动即被拒绝。已知限制Limitations对于任何使用非默认platform_instance导入的目的地平台destination_platform_map是必须的。否则 Firehose 血缘边会引用语法合法但在 DataHub 中解析不到任何东西的 URN —— 在发出的 JSON 里血缘看起来正确但 UI 中目标是死链。始终为设置了platform_instance的目的地填充destination_platform_mapdestination_platform_map: snowflake: platform_instance: prod-snowflake-east redshift: platform_instance: analytics-clusterGlue Schema Registry 的跨 schema 引用不会被解析。带有$refJSON Schema或命名导入Avro / Protobuf的 schema 只发出顶层 schema —— 嵌套引用不会被追踪。依赖跨 schema 导入的流会缺失部分字段。每个 recipe 一个区域。连接器每次运行只导入一个 AWS 区域。多区域账户需要为每个区域运行一个 recipe并使用不同的platform_instance。每个 recipe 一个 Glue Schema Registry。只查询glue_schema_registry.registry_name指定的 registry。如果 schema 跨多个 registry需要运行多个 recipe。没有USAGE_STATS能力。每个流的读写吞吐量在 CloudWatch 中可用但此连接器不读取。不支持的 Firehose 目的地。Splunk、HTTP、Datadog、New Relic、Coralogix、LogicMonitor、Dynatrace、Honeycomb、Sumo Logic 等目的地会发出没有输出血缘边的 DataJob并在 report 中显示警告。六个受支持的目的地见上文的 Firehose 血缘表。不从记录采样推断 schema。连接器依赖 AWS Glue Schema Registry 获取 schema —— 没有注册 schema 的流会在没有schemaMetadata的情况下发出。没有 Lambda 消费者发现。连接器不会枚举消费某个流的 Lambda 函数因此不产生Stream → Lambda血缘。不支持 Kinesis Data AnalyticsKDA / 托管 Flink。该连接器不导入 KDA 应用。Troubleshooting 排障指南血缘边存在但目标数据集在 DataHub 中找不到。你的destination_platform_map与目的地平台自身的导入设置不匹配。检查destination_platform_map.platform中的platform_instance和env是否与该平台源 recipe 使用的值完全一致。参见限制 #1。Snowflake 或 Redshift 血缘无法解析且目的地标识符为混合大小写。连接器默认将目的地 URN 名称小写化。如果你的 Snowflake / Redshift 源 recipe 设置了convert_urns_to_lowercase: false请在 Kinesis 侧同样设置destination_platform_map: snowflake: convert_urns_to_lowercase: falseIceberg 或 MongoDB 血缘无法解析。这两个平台的标识符区分大小写。按上述方法为它们关闭小写化convert_urns_to_lowercase: false。导入成功但搜索不显示实体。你的 DataHub 后端可能因搜索索引磁盘压力进入只读状态。在运行 DataHub 的主机上docker exec opensearch-or-elasticsearch-container \ curl -s localhost:9200/_cluster/allocation/explain如果集群报告超出disk.watermark.low请释放磁盘空间并重新索引。kinesis:ListStreams报AccessDeniedException。recipe 使用的 IAM 身份缺少 AWS IAM 权限 一节中的KinesisDataStreamsRead权限。首页拒绝会记录为警告并跳过 KDS 部分用户可能故意只有 Firehose IAM分页中途失败会升级为report.failure以防止对未列出的流进行有状态软删除。Firehose 部分静默为空尽管 Firehose 流存在。IAM 身份缺少firehose:ListDeliveryStreams和/或firehose:DescribeDeliveryStream—— Kinesis Data Streams 权限不覆盖 Firehose。Firehose 权限缺失会被记录为警告“Permission denied for Firehose”而非失败请检查导入运行报告。流的 schema 找不到。glue:GetSchemaVersion对预期的 schema 名返回了EntityNotFoundException。要么在glue_schema_registry.stream_schema_map中添加显式条目要么将 GSR schema 重命名为与流名一致并开启use_naming_convention: true要么接受该流将在没有schemaMetadata的情况下发出。与 kinesis_pre.md / recipe 的衔接本文聚焦于连接器的 Capabilities、配置细节与排障。前置的 IAM 权限、认证方式与最小 recipe 参见 kinesis_pre.mdIAM 策略包含kinesis:ListStreams/kinesis:DescribeStream/kinesis:ListTagsForStream以及可选的 Firehose 与 Glue 权限认证遵循 boto3 标准链静态凭证 → 环境变量 → named profile → EC2/ECS/EKS IAM 角色 → SSO profile。一个带注释、可运行的完整 recipe 示例在 kinesis_recipe.yml。小结kinesis连接器是 DataHub 将 AWS 实时数据管道纳入元数据治理的核心入口。理解 Firehose 目的地 URN 的构造规则、destination_platform_map的覆盖机制、GSR 的解析顺序与大小写折叠的默认行为是避免“血缘边看起来正确但 UI 中全是死链”的关键。配合源码中的处理器注册表与单元测试你可以自信地排查任何 lineage 或 schema 相关的问题。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
Amazon Kinesis 数据源深度指南Firehose 跨平台血缘、Glue Schema Registry 与排障实战【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub本文基于 DataHub 官方kinesis数据源文档kinesis_post.md并结合仓库源码、配置与测试用例编写全面覆盖 Kinesis 连接器的 Capabilities、Firehose 跨平台血缘、Glue 表血缘、GSR 模式注册、过滤、标签所有权派生、Limitations 与 Troubleshooting。引言为什么需要一份面向 Kinesis 连接器的深度指南AWS 实时数据管道中Kinesis Data StreamsKDS负责缓冲与分发Amazon Data Firehose 负责将数据投递到 S3、Redshift、Snowflake、Iceberg、MongoDB、OpenSearch 等目标平台。DataHub 的kinesis连接器用一个 recipe、一份 IAM 策略、一个 ingestion job 同时接入这两类服务KDS 流以DatasetStream子类型入库携带区域 Container、StreamARN、分片数、保留期、加密与流模式等 custom propertiesFirehose 流以DataFlowFirehose Stream子类型入库内含单个DataJobDelivery子类型其dataJobInputOutput血缘边连接源 Kinesis 流与目标平台。因此本文深入讲解Firehose 六种支持的目的地及其 URN 格式destination_platform_map跨平台 URN 覆盖机制Glue 表血缘Parquet/ORC 格式转换Glue Schema RegistryGSR模式解析与use_naming_convention的取舍流/Firehose 过滤、标签所有权派生已知限制与常见故障排查。读完本文你将能正确配置 Kinesis 连接器、避免“血缘边存在但目标 URN 无效”的坑并理解其内部实现。Capabilities 总览Kinesis 连接器在源码KinesisSource类上声明了以下能力kinesis.pyCapability说明状态Descriptions默认启用生成实体描述Enabled by defaultContainers区域级 ContainerRegion containersLineage (coarse)Firehose → 目标平台血缘Firehose - destination lineageTags从 AWS 资源标签生成 DataHub globalTagsFrom AWS resource tagsSchema Metadata通过 GSR 解析 schemaAvro / JSON / ProtobufOpt-in viaglue_schema_registry.enabledDeletion Detection基于 stateful ingestion 的软删除Via stateful ingestion从源码结构看连接器模块位于 metadata-ingestion/src/datahub/ingestion/source/kinesis/包含kinesis.py—— 主入口与 region container、account_id 解析kinesis_config.py—— 配置模型与destination_platform_map/ GSR 配置kinesis_stream.py—— KDS 提取器kinesis_firehose.py—— Firehose 提取器与 DataJob 血缘组装kinesis_firehose_destinations.py—— 目的地 URN 处理器注册表kinesis_schema_registry.py—— GSR 解析器kinesis_tagging.py—— AWS 标签 → globalTags 工具kinesis_report.py—— 报告字段。Firehose 血缘支持的目的地六种支持的 AWS 目的地Firehose 投递目标平台会产生dataJobInputOutput.outputDatasets血缘边。以下目的地类型受支持文档表格AWS destinationDataHub 平台URN 格式Amazon S3 / Extended S3s3urn:li:dataset:(urn:li:dataPlatform:s3,bucket[/prefix],...)Amazon Redshiftredshifturn:li:dataset:(urn:li:dataPlatform:redshift,db.schema.table,...)Amazon OpenSearch / Elasticsearchelasticsearchurn:li:dataset:(urn:li:dataPlatform:elasticsearch,index,...)Snowflakesnowflakeurn:li:dataset:(urn:li:dataPlatform:snowflake,db.schema.table,...)Apache Icebergicebergurn:li:dataset:(urn:li:dataPlatform:iceberg,namespace.table,...)MongoDBmongodburn:li:dataset:(urn:li:dataPlatform:mongodb,database.collection,...)URN 名称默认统一小写与 Snowflake 源默认convert_urns_to_lowercaseTrue保持一致。如需按目的地覆盖通过destination_platform_map.platform.convert_urns_to_lowercase: false关闭。注意不支持的 Firehose 目的地HTTP、Datadog、Splunk、New Relic、Coralogix、LogicMonitor、Dynatrace、Honeycomb、Sumo Logic 等不会产生血缘边 —— 连接器记录一条 “Unsupported Firehose destination” 警告并将目的地配置作为 custom property 记在 DataJob 上DataJob 本身仍会生成。源码实现印证在 kinesis_firehose_destinations.py 中每个目的地都有对应的DestinationHandler子类S3Destination/ExtendedS3Destination/RedshiftDestination/OpenSearchDestination/SnowflakeDestination/IcebergDestination/MongoDBDestination它们通过matches()匹配 boto3DescribeDeliveryStream返回的 destination block再用build_urns()构造 URN。DESTINATION_HANDLERS注册表按“先匹配 modern S3、再匹配 legacy”的顺序排列。关键细节源码注释明确S3 处理器同时处理 legacyS3DestinationDescription与 modernExtendedS3DestinationDescription二者共享BucketARNPrefix键_build_s3_urn在 BucketARN 缺失时返回空列表防御urn:li:dataset:(s3,,PROD)这类畸形 URN。Redshift 处理器从CopyCommand.DataTableName取schema.table从ClusterJDBCURL解析数据库名数据库或表名缺失时拒绝生成 URN避免urn:li:dataset:(redshift,my_table,PROD)这种语法合法但语义错误的 URN。OpenSearch 处理器同时匹配 boto3 的AmazonopensearchserviceDestinationDescription老账户的 AWS 公共 API 名与ElasticsearchDestinationDescription。Iceberg 是唯一支持“单条投递流 → 多张目标表”的目的地DestinationTableConfigurationList是列表V1 假设 REST catalog 的点分隔 namespace 格式。跨平台血缘destination_platform_mapFirehose 目的地位于其他平台S3、Redshift、Snowflake 等因此 Kinesis 产生的血缘 URN 必须与这些平台自己的 DataHub 源的 URN 约定一致。destination_platform_map允许按目的地覆盖 URN 参数destination_platform_map: snowflake: platform_instance: prod-snowflake-east env: PROD # 仅当 Snowflake 源 recipe 也设置了 convert_urns_to_lowercase: false 时才需要 convert_urns_to_lowercase: false redshift: platform_instance: analytics-cluster env: PROD iceberg: # Iceberg catalog 区分大小写 —— 关闭小写化以保留原大小写 convert_urns_to_lowercase: false每个目的地平台有三个可调参数platform_instance—— 必须与目的地平台自己的源 recipe 中使用的字符串一致。否则 Firehose 血缘边会指向 DataHub UI 中无法解析的死 URN。env——PROD/DEV等。未设置时继承本源的env。convert_urns_to_lowercase—— 默认true。对于区分大小写的目的地Iceberg、MongoDB或使用自身convert_urns_to_lowercasefalse导入的 Snowflake / Redshift 源设为false。源码实现印证在 kinesis_config.py 中DestinationPlatformDetail定义了这三个字段其中env会被自动大写并校验为合法 FabricTypePROD/DEV/QA/STG 等与顶层env的处理保持一致。destination_platform_map的键被约束为DestinationPlatformLiterals3/redshift/elasticsearch/snowflake/iceberg/mongodb/glue未知键在解析时直接报错从源头杜绝拼写错误。在 kinesis_firehose.py 的_destination_urn中实现了覆盖逻辑detail self.config.destination_platform_map.get(platform) platform_instance detail.platform_instance if detail else None resolved_env env or (detail.env if detail and detail.env else self.config.env) if detail is None or detail.convert_urns_to_lowercase: name name.lower() return make_dataset_urn_with_platform_instance(...)注意convert_urns_to_lowercase的默认值同样是true对齐 Snowflake 源只有当 map 中显式设置false时才跳过小写化。测试验证test_kinesis_firehose.py 中test_destination_platform_map_overrides_snowflake_instance验证了platform_instance会被折叠进 URN 名称前缀prod-sf.db.s.tTestDestinationUrnCaseFolding类则专门验证默认小写化与按目的地关闭小写化的行为。配置层面的校验在 test_kinesis_config.py未知平台如datadog会在启动时报错glue作为合法的 map 键也被显式支持。Glue 表血缘Firehose 格式转换当 Firehose 流启用了Parquet/ORC 格式转换时其SchemaConfiguration会引用一张 Glue 表来定义输出 schema。连接器会把它作为 Firehose delivery DataJob 的第二个上游输入暴露出来源 Kinesis 流仍是输入既有行为目标 S3 路径仍是输出既有行为Glue 表被添加为第二个输入 —— 它的 schema 决定了写入 S3 路径的内容。要让 Glue 表 URN 被发出SchemaConfiguration必须包含DatabaseName和TableName。CatalogId不是必须的—— 当它与调用者账户相同时AWS 会在DescribeDeliveryStream响应中省略它按 AWS 文档它是 input-side default。存在SchemaConfiguration但缺少DatabaseName/TableName的情况会被记录到 source report 的firehose_glue_schema_skipped字段中用于诊断。如果 Glue catalog 是在非默认platform_instance下导入的需要设置覆盖destination_platform_map: glue: platform_instance: central-catalog env: PROD整个行为由include_table_lineage标志控制 —— 关闭时不会发出任何 Glue 血缘。源码实现印证在 kinesis_firehose_destinations.py 中ExtendedS3Destination.extract_schema_config_glue_urn从DataFormatConversionConfiguration.SchemaConfiguration读取DatabaseName/TableName构造urn:li:dataset:(glue,db.table,env)格式的 URN缺失字段时通过report_firehose_glue_schema_skipped记录原因。在 kinesis_firehose.py 中_process_destination会对ExtendedS3Destination调用该方法并把返回的 Glue URN追加到 inputs上游—— 因为该表的 schema 决定写入内容S3 路径仍是数据目的地。流与 Firehose 流过滤stream_pattern和firehose_stream_pattern使用标准 DataHubAllowDenyPattern结构。一个常见的 deny 规则用于排除内部 / 审计 / 调试流stream_pattern: deny: - ^_.* - .*-debug$stream_pattern过滤 Kinesis Data Streamsinclude_streams: true时生效firehose_stream_pattern过滤 Firehose 流include_firehose: true时生效。被过滤的流会记录在 report 的filtered_streams/filtered_firehose_streams字段中kinesis_report.py。从标签派生所有权连接器将 AWS 资源标签发布为 DataHubglobalTagsKeyValue变为urn:li:tag:Key:Value仅 Key 的标签变为urn:li:tag:Key。要把标签转成所有权请应用内置的extract_ownership_from_tagstransformer —— 这使所有权处理与 DataHub 其他源保持一致而不是在每个连接器里重新实现。例如把owner标签的值当作 corpuser 所有者transformers: - type: extract_ownership_from_tags config: tag_pattern: owner:该 transformer 还支持 corp group、owner types以及追加 email domain —— 完整选项见 dataset_transformer.md如owner_type、owner_type_urn、email_domain、extract_owner_type_from_tag_pattern等配置项。从源码看所有权刻意不在连接器内派生 —— kinesis_tagging.py 的注释明确说明它由extract_ownership_from_tagstransformer 通用地处理连接器只负责把 AWS 标签展平为GlobalTagsClass。Glue Schema RegistryGSRGSR 是可选开启的因为它需要额外的 IAM 权限glue:Get*/glue:List*。开启与关闭的差别关闭默认—— 流在没有schemaMetadataaspect 的情况下发出。所有其他元数据properties、tags、ownership、lineage不受影响也不需要glue:*权限。开启—— 对每个能解析出 schema 的流见下面的解析顺序连接器从 AWS Glue Schema Registry 获取 schema 并附带schemaMetadataaspect解析字段支持 Avro / JSON / Protobuf。解析不到 schema 的流仍会发出只是没有schemaMetadata—— 开启 GSR 永远不会丢流。需要GlueSchemaRegistryReadIAM statement。开启配置glue_schema_registry: enabled: true registry_name: default-registry # 推荐显式声明已知的 stream - schema 关联 stream_schema_map: events: events-v2 clicks: click-events-schema # 可选启发式 —— 见下文说明 use_naming_convention: false每个流的 schema 解析顺序如果流名是stream_schema_map的键使用映射的 schema 名否则如果use_naming_convention: true在配置的registry_name中查找与流名同名的 schema否则不带schemaMetadata发出该流。为什么 use_naming_convention 默认关闭与 Kafka Confluent Schema Registry定义了标准化的TopicNameStrategy即topic-key/-valuesubject 命名不同AWS 没有定义 Kinesis Data Stream 与 Glue schema 之间的任何关系。schema 由生产者按记录选择GlueSchemaRegistrySerializer会把 schema-id 嵌入每条记录流本身没有 schema 绑定。多个生产者可以用不同 schema 写入同一个流一个 schema 也可以被多个流复用。有些组织把 “schema 名 流名” 作为内部约定但这并非 AWS 最佳实践。如果你的组织遵循该约定可以设置use_naming_convention: true否则在stream_schema_map中声明已知关联 —— 这是最可预测的模式。对于启用了 Parquet/ORC 格式转换的Firehose流AWS 确实通过SchemaConfiguration定义了关系 —— 见上文 Glue 表血缘。该提取默认开启不受此标志影响。源码实现印证kinesis_config.py 中的KinesisGlueSchemaRegistryConfig有一个重要的 model validator当enabledfalse却设置了stream_schema_map或use_naming_convention时直接抛配置错误—— 因为这两个激活开关在禁用状态下是静默无效的用户几乎必然是“本想开启 GSR”。registry_name因有非空默认值而不作为激活信号。kinesis_schema_registry.py 实现了解析逻辑_resolve_schema_name先查stream_schema_map再按命名约定回退get_schema_metadata调用glue:GetSchemaVersionSchemaVersionNumber{LatestVersion: True}命名约定探针未命中EntityNotFoundException且非显式映射是预期结果记录到gsr_naming_convention_misses字段而不产生 WARNING 噪音而显式映射失败、AccessDenied、ValidationException 等真实错误会记入schema_resolution_failures并产生警告。测试方面test_kinesis_config.py 覆盖了禁用时get_schema_metadata短路不做任何 Glue 调用、命名约定关闭时不解析、以及“配置了但未启用”在启动即被拒绝。已知限制Limitations对于任何使用非默认platform_instance导入的目的地平台destination_platform_map是必须的。否则 Firehose 血缘边会引用语法合法但在 DataHub 中解析不到任何东西的 URN —— 在发出的 JSON 里血缘看起来正确但 UI 中目标是死链。始终为设置了platform_instance的目的地填充destination_platform_mapdestination_platform_map: snowflake: platform_instance: prod-snowflake-east redshift: platform_instance: analytics-clusterGlue Schema Registry 的跨 schema 引用不会被解析。带有$refJSON Schema或命名导入Avro / Protobuf的 schema 只发出顶层 schema —— 嵌套引用不会被追踪。依赖跨 schema 导入的流会缺失部分字段。每个 recipe 一个区域。连接器每次运行只导入一个 AWS 区域。多区域账户需要为每个区域运行一个 recipe并使用不同的platform_instance。每个 recipe 一个 Glue Schema Registry。只查询glue_schema_registry.registry_name指定的 registry。如果 schema 跨多个 registry需要运行多个 recipe。没有USAGE_STATS能力。每个流的读写吞吐量在 CloudWatch 中可用但此连接器不读取。不支持的 Firehose 目的地。Splunk、HTTP、Datadog、New Relic、Coralogix、LogicMonitor、Dynatrace、Honeycomb、Sumo Logic 等目的地会发出没有输出血缘边的 DataJob并在 report 中显示警告。六个受支持的目的地见上文的 Firehose 血缘表。不从记录采样推断 schema。连接器依赖 AWS Glue Schema Registry 获取 schema —— 没有注册 schema 的流会在没有schemaMetadata的情况下发出。没有 Lambda 消费者发现。连接器不会枚举消费某个流的 Lambda 函数因此不产生Stream → Lambda血缘。不支持 Kinesis Data AnalyticsKDA / 托管 Flink。该连接器不导入 KDA 应用。Troubleshooting 排障指南血缘边存在但目标数据集在 DataHub 中找不到。你的destination_platform_map与目的地平台自身的导入设置不匹配。检查destination_platform_map.platform中的platform_instance和env是否与该平台源 recipe 使用的值完全一致。参见限制 #1。Snowflake 或 Redshift 血缘无法解析且目的地标识符为混合大小写。连接器默认将目的地 URN 名称小写化。如果你的 Snowflake / Redshift 源 recipe 设置了convert_urns_to_lowercase: false请在 Kinesis 侧同样设置destination_platform_map: snowflake: convert_urns_to_lowercase: falseIceberg 或 MongoDB 血缘无法解析。这两个平台的标识符区分大小写。按上述方法为它们关闭小写化convert_urns_to_lowercase: false。导入成功但搜索不显示实体。你的 DataHub 后端可能因搜索索引磁盘压力进入只读状态。在运行 DataHub 的主机上docker exec opensearch-or-elasticsearch-container \ curl -s localhost:9200/_cluster/allocation/explain如果集群报告超出disk.watermark.low请释放磁盘空间并重新索引。kinesis:ListStreams报AccessDeniedException。recipe 使用的 IAM 身份缺少 AWS IAM 权限 一节中的KinesisDataStreamsRead权限。首页拒绝会记录为警告并跳过 KDS 部分用户可能故意只有 Firehose IAM分页中途失败会升级为report.failure以防止对未列出的流进行有状态软删除。Firehose 部分静默为空尽管 Firehose 流存在。IAM 身份缺少firehose:ListDeliveryStreams和/或firehose:DescribeDeliveryStream—— Kinesis Data Streams 权限不覆盖 Firehose。Firehose 权限缺失会被记录为警告“Permission denied for Firehose”而非失败请检查导入运行报告。流的 schema 找不到。glue:GetSchemaVersion对预期的 schema 名返回了EntityNotFoundException。要么在glue_schema_registry.stream_schema_map中添加显式条目要么将 GSR schema 重命名为与流名一致并开启use_naming_convention: true要么接受该流将在没有schemaMetadata的情况下发出。与 kinesis_pre.md / recipe 的衔接本文聚焦于连接器的 Capabilities、配置细节与排障。前置的 IAM 权限、认证方式与最小 recipe 参见 kinesis_pre.mdIAM 策略包含kinesis:ListStreams/kinesis:DescribeStream/kinesis:ListTagsForStream以及可选的 Firehose 与 Glue 权限认证遵循 boto3 标准链静态凭证 → 环境变量 → named profile → EC2/ECS/EKS IAM 角色 → SSO profile。一个带注释、可运行的完整 recipe 示例在 kinesis_recipe.yml。小结kinesis连接器是 DataHub 将 AWS 实时数据管道纳入元数据治理的核心入口。理解 Firehose 目的地 URN 的构造规则、destination_platform_map的覆盖机制、GSR 的解析顺序与大小写折叠的默认行为是避免“血缘边看起来正确但 UI 中全是死链”的关键。配合源码中的处理器注册表与单元测试你可以自信地排查任何 lineage 或 schema 相关的问题。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
