DataHub Kinesis 连接器实战指南一键摄取 Amazon Kinesis Data Streams 与 Data Firehose 元数据及跨平台 Lineage【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub本文全面讲解 DataHub 开源仓库metadata-ingestion 模块中的kinesis摄取连接器。该连接器用一份 recipe、一份 IAM 策略、一个摄取任务同时覆盖 AWS 两大流式服务Kinesis Data StreamsKDS与 Amazon Data Firehose并将 Firehose 到 S3 / Redshift / Snowflake 等目标平台的跨服务血缘lineage渲染进 DataHub 血缘图。读完本文你将掌握该连接器的完整配置语法、最小权限 IAM 策略、认证方式、Glue Schema Registry 集成以及跨平台 URN 对齐这一最容易踩坑的配置项。连接器能力总览两个服务、统一元数据模型kinesis连接器将 AWS 两大流式服务统一建模为 DataHub 实体源码定位kinesisAmazon Kinesis Data Streams每个 KDS 流被建模为一个Dataset子类型Stream挂在所在区域Region的 Container 之下StreamARN、分片数、保留时长、加密方式、流模式等写入 custom propertiesAWS 资源标签转为 DataHub 全局标签globalTags并可选地从 AWS Glue Schema Registry 解析schemaMetadata。kinesis-firehoseAmazon Data Firehose每个 Firehose 流被建模为一个独立的DataFlow子类型Firehose Stream其内部包含唯一一个DataJob子类型Delivery由该 DataJob 的dataJobInputOutput承载从源 Kinesis 流到目标平台的 lineage 边。V1 支持六个目标平台S3、Redshift、OpenSearch/Elasticsearch、Snowflake、Apache Iceberg 和 MongoDB。于是KDS Stream → Firehose 流 → S3这样的跨服务数据流会在 DataHub 血缘视图中以跨平台边cross-platform edges的方式直接呈现数据流向一目了然。需要特别说明该连接器按 AWS 区域限定region-scoped——一份 recipe 只摄取一个区域多区域环境需要每个区域各跑一份 recipe。区域被编码进 Dataset 名称与 Firehose DataFlow id例如us-east-1.events因此同一账号的多个区域可以共享同一个platform_instance默认取账号 ID而不会发生 URN 冲突。前提条件最小权限 IAM 策略连接器需要 Kinesis、Firehose 以及可选的Glue 服务的只读权限。官方推荐的最小策略如下{ Version: 2012-10-17, Statement: [ { Sid: KinesisDataStreamsRead, Effect: Allow, Action: [ kinesis:ListStreams, kinesis:DescribeStream, kinesis:ListTagsForStream ], Resource: * }, { Sid: KinesisFirehoseRead, Effect: Allow, Action: [ firehose:ListDeliveryStreams, firehose:DescribeDeliveryStream, firehose:ListTagsForDeliveryStream ], Resource: * }, { Sid: GlueSchemaRegistryRead, Effect: Allow, Action: [glue:ListRegistries, glue:GetSchemaVersion], Resource: * } ] }对各条 Statement 的进一步说明均可在源码中找到对应行为Account ID 解析无需额外权限当 recipe 未显式设置platform_instance时连接器直接从资源 ARN来自它本就调用的kinesis:DescribeStream/firehose:DescribeDeliveryStream返回中解析出 AWS 账号 ID并作为默认platform_instance即account_id从而跨账号消歧区域则编码进 Dataset 名称和 DataFlow id 而非platform_instance。见 kinesis.py 的_resolve_account_id。实现上刻意不调用sts:GetCallerIdentity——因为该接口返回的是调用方账号在跨账号 AssumeRole 场景下会得到错误的账号而资源 ARN 反映的是资源真正所在的账号。若没有可用资源或查询失败连接器会记录 warning 并继续以platform_instanceNone运行此时 URN 不含账号 ID跨账号防冲突就依赖你在 recipe 中显式设置platform_instance。KinesisFirehoseRead仅在include_firehose: true默认开启时必需。若未授予该权限但开启了 Firehose 摄取连接器会记录Permission denied for Firehose警告并只继续摄取 KDSFirehose 部分被跳过不会导致任务失败。GlueSchemaRegistryRead仅在glue_schema_registry.enabled: true时必需。AWS 也提供了现成的托管策略AWSGlueSchemaRegistryReadonlyAccess可直接附加。KinesisDataStreamsRead若kinesis:ListStreams在第一页即被拒绝会记录警告并跳过 KDS 部分用户可能只打算摄取 Firehose。而分页中途失败会升级为report.failure——因为前几页已产出的 workunit 已被持久化若不报错下一轮 stateful ingestion 会把未列出的流误判为已删除而软删除。这一“首页失败警告、翻页中断失败”的差异化处理逻辑统一实现在 kinesis_report.py 的report_listing_failure。认证方式boto3 标准凭据链凭据遵循 boto3 标准解析链优先级从高到低aws_config中的静态凭据aws_access_key_idaws_secret_access_keySTS 临时凭据另加aws_session_token环境变量AWS_ACCESS_KEY_ID/AWS_SECRET_ACCESS_KEY以及适用的AWS_SESSION_TOKEN由aws_config.aws_profile指定的~/.aws/credentials中的 profile运行摄取任务的 EC2 / ECS / EKS 主机上附加的 IAM 角色AWS SSO profile。官方建议优先使用 IAM 角色或短期 SSO 凭据避免把长期 access key 写进入库的 recipe。以下三种模式覆盖大多数场景环境变量推荐用于 CI / 容器——注入AWS_ACCESS_KEY_ID与AWS_SECRET_ACCESS_KEY使用临时凭据时再加AWS_SESSION_TOKENrecipe 只保留区域aws_config: aws_region: us-east-1Assume-role推荐用于跨账号访问——将aws_config.aws_role设为目标角色 ARN上述 1–5 步解析到的凭据必须具备对目标角色的sts:AssumeRole权限aws_config: aws_region: us-east-1 aws_role: arn:aws:iam::123456789012:role/datahub-kinesis-read # aws_external_id: ${DATAHUB_EXTERNAL_ID} # 信任策略要求时使用命名 profile推荐用于本地开发——引用~/.aws/credentials中的 profileaws_config: aws_region: us-east-1 aws_profile: datahub-prodRecipe 完整配置解读以下是在官方示例 recipekinesis_recipe.yml基础上整理的完整配置几乎所有字段在 kinesis_config.py 中都有对应的 pydantic 定义与默认值pipeline_name: kinesis_ingestion source: type: kinesis config: # 一份 recipe 只对应一个 AWS 区域。platform_instance 默认取 AWS 账号 ID # 从资源 ARN 推导仅当需要跨账号消歧时才显式设置。 # platform_instance: prod-account env: PROD # 标准 DataHub AWS 连接配置。凭据由 boto3 链解析 # 环境变量、共享凭据文件、EC2/ECS/EKS 上的 IAM 角色、SSO profile。 # aws_config: # aws_region: us-west-2 # aws_access_key_id: ${AWS_ACCESS_KEY_ID} # aws_secret_access_key: ${AWS_SECRET_ACCESS_KEY} # aws_role: arn:aws:iam::123456789012:role/datahub-kinesis-ingest # --- Kinesis Data Streams (KDS) ----------------------------------- include_streams: true # 是否摄取 KDS 流默认 true stream_pattern: # KDS 流过滤标准 AllowDenyPattern deny: - ^_.* # 排除内部 / 调试 / 审计流 # --- Amazon Data Firehose ----------------------------------------- include_firehose: true # 是否摄取 Firehose 流默认 true firehose_stream_pattern: allow: - .* include_table_lineage: true # 是否产出 Firehose → 目标的 lineage 边 # --- Tags --------------------------------------------------------- extract_tags: true # AWS 资源标签 → DataHub globalTags # --- 跨平台 lineage见下文专门章节----------------------------- # destination_platform_map: # snowflake: # platform_instance: prod-snowflake-east # env: PROD # convert_urns_to_lowercase: false # --- Glue Schema Registry可选默认关闭------------------------ glue_schema_registry: enabled: true registry_name: default-registry stream_schema_map: {} # 显式 流 → schema 映射最推荐 # events: events-v2 # clicks: click-events-schema use_naming_convention: false # 命名约定启发式默认关闭 # --- 有状态摄取删除检测---------------------------------------- stateful_ingestion: enabled: true remove_stale_metadata: true fail_safe_threshold: 100关键字段默认值与行为来自 kinesis_config.py配置项默认值说明include_streamstrue提取 KDS 流stream_pattern/firehose_stream_patternallow_all标准AllowDenyPattern正则过滤include_firehosetrue提取 Firehose 流include_table_lineagetrue产出 Firehose → 目标平台的 lineage 边extract_tagstrue提取 AWS 资源标签为 globalTagsglue_schema_registry.enabledfalseGlue Schema Registry 集成开关需额外glue:*权限destination_platform_map{}目标平台 URN 覆盖映射键被DestinationPlatformLiteral 约束为s3/redshift/elasticsearch/snowflake/iceberg/mongodb/glue注意glue_schema_registry的一个校验细节如果设置了stream_schema_map或use_naming_convention但enabled: falsepydantic 校验会直接报错提示你设置enabledTrue或移除这两个字段——因为它们在关闭状态下是静默无效的见 kinesis_config.py 的模型校验器。另外若aws_region未能从 recipe、AWS_REGION/AWS_DEFAULT_REGION环境变量或 AWS profile 默认区域中解析出来连接器会在初始化阶段直接抛出ValueError见 kinesis.py 的区域解析。Firehose 血缘支持的目标平台与 URN 格式以下目标类型会产出dataJobInputOutput.outputDatasets边摘自 kinesis_post.md对应实现见 kinesis_firehose_destinations.pyAWS 目标DataHub 平台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 source 的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 等不会产生 lineage 边——连接器记录Unsupported Firehose destination警告并将目标配置作为 custom property 记在 DataJob 上DataJob 本身仍会正常产出。从源码看每种目标对应一个可插拔的 handlerDestinationHandler抽象基类约 50 行即可新增一种未匹配到 handler 的目标会走report_unsupported_destination路径kinesis_firehose_destinations.py。跨平台血缘对齐destination_platform_mapFirehose 目标都位于其他平台S3、Redshift、Snowflake 等因此 Kinesis 产出的血缘 URN 必须与这些平台自身 DataHub source 的 URN 约定一致。destination_platform_map允许按目标平台覆盖 URN 参数destination_platform_map: snowflake: platform_instance: prod-snowflake-east env: PROD # 若你的 Snowflake source recipe 也设置了 # convert_urns_to_lowercase: false保留 UPPER_CASE 标识符则设为 false convert_urns_to_lowercase: false redshift: platform_instance: analytics-cluster env: PROD iceberg: # Iceberg catalog 区分大小写 —— 关闭小写化以保留表名原始大小写 convert_urns_to_lowercase: false每个目标平台有三个可调旋钮对应 DestinationPlatformDetail 的三个字段platform_instance—— 与目标平台自身 source recipe 使用的字符串一致。不设置的话Firehose 血缘边会指向 DataHub UI 中解析不到的死 URN见下文“限制 #1”。env——PROD/DEV等。未设置时继承本 source 的env。该字段在校验时会被自动转大写并校验是否为合法 DataHub FabricTypePROD、DEV、QA等非法值直接报配置错误。convert_urns_to_lowercase—— 默认true。对区分大小写的目标Iceberg、MongoDB或按自身convert_urns_to_lowercasefalse摄取的 Snowflake / Redshift source需设为false。从实现看_destination_urn会先查destination_platform_map取不到 detail 时platform_instance为 None、env 回落为本 source 的envkinesis_firehose.py。注意destination_platform_map的键在解析阶段就被 pydantic 的DestinationPlatformLiteral 约束为闭集s3 / redshift / elasticsearch / snowflake / iceberg / mongodb / glue拼错键名会在配置校验时直接报错而非运行时静默失败。Glue 表血缘Firehose 格式转换当 Firehose 流启用了Parquet/ORC 格式转换时其SchemaConfiguration会引用一张定义了输出 schema 的 Glue 表。连接器会将其作为 Firehose delivery DataJob 的额外上游输入源 Kinesis 流仍是输入原有行为目标 S3 路径仍是输出原有行为Glue 表被追加为第二个输入——它的 schema 决定了写入 S3 路径的内容。要产出 Glue 表 URNSchemaConfiguration必须包含DatabaseName和TableNameCatalogId不是必需的——当它与调用方账号相同时AWS 会在DescribeDeliveryStream响应中省略它按 AWS 文档CatalogId 是输入侧默认值。存在SchemaConfiguration但缺少DatabaseName/TableName的情况会被记录到 source report 的firehose_glue_schema_skipped字段便于诊断相关实现见 kinesis_firehose_destinations.py 的extract_schema_config_glue_urn。如果你的 Glue catalog 是以非默认platform_instance摄取的可设置覆盖destination_platform_map: glue: platform_instance: central-catalog env: PROD整个行为受include_table_lineage开关控制——关闭后不产出任何 Glue lineage。流过滤与从标签派生所有权过滤stream_pattern与firehose_stream_pattern使用标准 DataHubAllowDenyPattern。常见做法是用 deny 规则排除内部 / 审计 / 调试流stream_pattern: deny: - ^_.* - .*-debug$从标签派生所有权连接器将 AWS 资源标签发射为 DataHubglobalTagsKeyValue标签 →urn:li:tag:Key:Value。要把某个标签转成所有权请套用内置的extract_ownership_from_tagstransformer——这样所有权处理与 DataHub 其他所有 source 保持一致而不是在连接器内部重复实现。例如把owner标签的值映射为 corpuser 所有者transformers: - type: extract_ownership_from_tags config: tag_pattern: owner:该 transformer 还支持 corp group、owner type以及追加 email 域名等完整选项详见其文档。Glue Schema Registry可选 schema 元数据GSR 是**可选opt-in**功能因为需要额外 IAM 权限glue:Get*/glue:List*。开启前后的差异关闭默认——流在产出时不带schemaMetadataaspect。其余元数据属性、标签、所有权、血缘不受影响无需任何glue:*权限。开启——对每个能解析出 schema 的流解析顺序见下连接器从 AWS Glue Schema Registry 拉取 schema 并附带schemaMetadataaspect字段已按 Avro / JSON / Protobuf 解析。解析不到 schema 的流照常产出只是没有schemaMetadata——开启 GSR 永远不会丢弃流。需要GlueSchemaRegistryReadIAM 语句。启用示例glue_schema_registry: enabled: true registry_name: default-registry # 推荐显式声明已知的 流 → schema 关联。 stream_schema_map: events: events-v2 clicks: click-events-schema # 可选启发式 —— 见下文说明 use_naming_convention: false每个流的 schema 解析顺序实现在 kinesis_schema_registry.py 的_resolve_schema_name流名是stream_schema_map的键时使用映射的 schema 名否则若use_naming_convention: true在配置的registry_name中查找与流名同名的 schema否则流不附带schemaMetadata产出。为什么use_naming_convention默认关闭与 Kafka Confluent Schema Registry定义了标准化的TopicNameStrategytopic-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 表血缘”该提取默认开启且不受此开关影响。从源码看解析成功的 schema 会转换为SchemaMetadataClass其中KafkaSchemaClass保存原始 schema 定义与格式类型字段通过 schema_util / JsonSchemaTranslator / protobuf_util 按 AVRO / JSON / PROTOBUF 三种格式分别解析格式不支持或解析失败均记录到 reportschema_resolution_failures而不中断摄取。一个值得注意的细节Protobuf 解析会把流名中的.替换为_如orders.v2→orders_v2因为.proto文件名中的点会破坏 Python 模块导入。源码层面的元数据建模细节理解实体如何建模有助于排查问题全部来自 kinesis_stream.py 与 kinesis_firehose.py区域 Container 延迟产出只有至少一个 KDS 流实体化后区域 Container 才会被发射get_workunits_internal中首见即发。因为每个 Firehose 流是独立 DataFlow不是区域 Container 的子节点若一个账号区域只有 Firehose 流而没有 KDS 流提前发射空区域 Container 只会污染目录导航。区域 Container 的external_url指向https://console.aws.amazon.com/kinesis/home?regionregionkinesis.py 的_emit_region_container。目录层级platform → account_id → region container → stream与 AWS 自身的资源模型一致。Dataset URN 含区域KDS Dataset 的 URN 名称为region.stream_name而display_name是裸流名因此 UI 中显示TestStream而非us-west-2.TestStream区域上下文已由父级 Region Container 体现同时同账号不同区域的同名流不会碰撞kinesis_stream.py 的_emit_dataset。Dataset custom propertiesstream_arn、stream_status、stream_modePROVISIONED/ON_DEMAND、shard_count、retention_hours、encryption_type、key_idDataJob 侧则为delivery_stream_arn、delivery_stream_status、delivery_stream_type、version_id空值字段会被剔除。Firehose DataFlow id 含区域region.firehose_stream_name因为 Firehose 流名只在账号区域内唯一账号由platform_instance承载DataJob id 固定为deliverykinesis_firehose.py。DirectPut 无上游DeliveryStreamType不是KinesisStreamAsSource的 Firehose 流没有上游输入边若声明了 Kinesis 源但 ARN 缺失/无法解析则记录Unresolved Firehose source stream警告并跳过该上游边有上游却解析失败属于必须暴露的问题。有状态摄取与删除检测连接器继承StatefulIngestionSourceBase支持标准 stateful ingestion 配置recipe 示例stateful_ingestion: enabled: true remove_stale_metadata: true fail_safe_threshold: 100它会软删除上次成功运行之后从 AWS 消失的实体按 ingestion job 维度 diff与platform_instance无关。这也是前文反复强调“分页中断必须升级为 failure”的原因如果列表分页中途失败却被当作正常结束已产出的页会被持久化下一轮运行会把失败点之后的实体全部误判为已删除。连接器还实现了TestableSource.test_connection可依次探测kinesis:ListStreams基础连通性、firehose:ListDeliveryStreamsFirehose / lineage 能力、glue:ListRegistriesGSR 能力并把每个探针的失败原因如AccessDeniedException、NoCredentialsError写进CapabilityReportkinesis.py 的test_connection。测试与验证集成测试如何兜底仓库提供了完整的集成测试tests/integration/kinesis/test_kinesis.py测试基于 Floci AWS 模拟器floci/floci在 Docker 中启动用 boto3 在进程内播种测试数据两个 KDS 流events/clicks、一个按 deny 规则过滤的_internal_audit流、一个 ON_DEMAND 流、两个 S3 bucket、两条 Firehose 流events-to-s3/clicks-to-s3跑完 pipeline 后与黄金文件 kinesis_mces_golden.json 逐条比对 MCP并对警告做严格断言——除已知的 Firehose 模拟器Source为空缺口外任何意外警告都会导致测试失败。测试 recipetests/integration/kinesis/recipe.yml演示了指向本地模拟器的aws_endpoint_url覆盖用法这对本地调试连接器同样有参考价值。已知限制任何以非默认platform_instance摄取的目标平台都必须配置destination_platform_map。否则 Firehose 血缘边引用的 URN 语法合法但无法解析——血缘在 JSON 输出里看似正确UI 里却是死链接。务必为所有设置了platform_instance的目标平台 source 补齐映射例如destination_platform_map: snowflake: platform_instance: prod-snowflake-east redshift: platform_instance: analytics-clusterGlue Schema Registry 的跨 schema 引用不会被解析。带$refJSON Schema或命名导入Avro / Protobuf的 schema 只发射顶层 schema嵌套引用不追踪依赖跨 schema 导入的流会缺失部分字段。一份 recipe 只对应一个区域。多区域账号需要每区域一份 recipe可共用platform_instance或显式区分。一份 recipe 只查询一个 Glue Schema Registry。只查询glue_schema_registry.registry_name指定的 registryschema 分散在多个 registry 时需运行多份 recipe。无USAGE_STATS能力。每流读写吞吐在 CloudWatch 中有但该连接器不读取。不支持的 Firehose 目标。Splunk、HTTP、Datadog、New Relic、Coralogix、LogicMonitor、Dynatrace、Honeycomb、Sumo Logic 目标产出无输出边且带警告的 DataJob六个受支持目标见上文血缘表。不做基于记录采样的 schema 推断。schema 依赖 AWS Glue Schema Registry未注册 schema 的流不附带schemaMetadata。不发现 Lambda 消费者。连接器不枚举消费流的 Lambda 函数因此Stream → Lambda血缘不产出。不支持 Kinesis Data AnalyticsKDA / managed Flink。KDA 应用不被该连接器摄取。故障排查速查血缘边显示了但目标 Dataset 在 DataHub 里找不到。destination_platform_map与目标平台自身摄取设置不匹配。检查destination_platform_map.platform中的platform_instance和env是否与该平台 source recipe 使用的值完全一致。参见限制 #1。Snowflake / Redshift 血缘不解析且目标标识符为混合大小写。连接器默认将目标 URN 名称小写。如果你的 Snowflake / Redshift source 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 身份缺少上文 IAM 策略中的KinesisDataStreamsRead权限。首页拒绝只记警告并跳过 KDS 部分用户可能故意只有 Firehose IAM分页中途失败会升级为report.failure防止 stateful 软删除未列出的流。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产出。快速上手小结按上文最小 IAM 策略授予只读权限仅摄取 KDS 可去掉 Firehose 段不启用 GSR 可去掉 Glue 段。准备好凭据优先 IAM 角色或短期 SSO 凭据其次环境变量。复制 kinesis_recipe.yml 作为起点设置aws_region与env按需开启 GSR、配置destination_platform_map和过滤规则。运行datahub ingest -c kinesis_recipe.yml同一 recipe 中默认 sink 为 datahub-rest取自~/.datahubenv由datahub init生成。每个区域各维护一份 recipe在 DataHub 血缘视图中查看跨平台数据流。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考