DataHub 集成 MLflow 元数据导入指南连接器配置、认证与数据集血缘实践【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub导读本文围绕 DataHub 元数据摄取框架中的mlflow模块展开讲解如何将 MLflow 的 Experiments、Runs、Registered Models、Model Versions 以及数据集血缘Lineage导入 DataHub。读完本文你将掌握 MLflow 连接器的完整配置项含义、认证方式、数据集平台映射策略、版本兼容性边界以及如何在生产环境中排查摄取失败问题可直接套用文中的 recipe 配置投入实际使用。一、模块概述mlflow摄取什么mlflow模块是 DataHub 元数据摄取Metadata Ingestion框架中用于从 MLflow 摄取元数据的生产级连接器适用于正式生产环境的数据摄取工作流。其核心类为 MLflowSource在源码中被标注为BETA 支持状态support_status(SupportStatus.BETA)与platform_name(MLflow)。从 get_workunits_internal 的调度逻辑可以看出一次完整摄取会依次生成三类工作单元WorkunitStage 标签Tags为 MLflow Model Registry 中的每个 StageProduction、Staging、Archived、None创建 DataHub 全局标签Experiment 相关每个 Experiment 作为 DataHub 容器Container实体其下所有 Run 摄取为 DataProcessInstance训练运行并附带指标、超参数、输入数据集血缘模型相关每个 Registered Model 摄取为 MLModelGroup每个 Model Version 摄取为 MLModel 实体并关联对应的训练 Run。这三类元数据共同构成了 MLflow → DataHub 的完整映射实验组织模型运行驱动模型版本模型版本再通过 Stage 标签在 DataHub 中呈现生命周期状态。二、前置条件Prerequisites官方文档对运行摄取前的基础要求如下网络连通性确保运行摄取的环境能够访问 MLflow Tracking Server / Registry Server 的地址tracking_uri/registry_uri有效认证凭据若 MLflow 服务端启用了认证需要准备可用的用户名与密码元数据 API 读权限连接所用的账号必须具备读取 MLflow 元数据 API 的权限如读取 Experiments、Runs、Registered Models、Model Versions 等搜索接口。从源码实现看这些前置条件的缺失通常会在客户端初始化或搜索遍历阶段直接抛错或在 report 中记录 warning/failure属于先验证后摄取的硬性门槛。三、版本兼容性需要 MLflow Server 1.28.0连接器对 MLflow 服务端版本有明确要求必须为 1.28.0 或更高版本。若使用更早版本Experiments 与 Runs 的摄取会被跳过。这一要求背后有源码依据在 _traverse_mlflow_search_func 中连接器通过捕获MlflowException的ENDPOINT_NOT_FOUND错误码来兼容旧版本服务端——当 MLflow 服务端缺少search_experiments、search_runs等较新的分页搜索 API 端点时会记录一条 warningPlease upgrade to version 1.28.0 or higher...并跳过 Experiments/Runs 的摄取而不会导致整个管道崩溃。这也解释了为什么低版本下模型注册表Registered Models / Model Versions仍可能摄取但实验与运行数据会缺失。四、完整连接器配置官方 recipe 模板 给出了最小配置骨架source: type: mlflow config: # Coordinates tracking_uri: tracking_uri sink: # sink configs仓库中另有一份可直接运行的最小示例 mlflow_to_datahub.dhub.yamlsource: type: mlflow config: tracking_uri: http://127.0.0.1:5000 sink: type: datahub-rest config: server: http://localhost:8080基于 MLflowConfig 的字段定义全部可配置项如下配置项默认值说明tracking_uri无使用 MLflow 默认值Tracking Server URI。不设置时使用本地mlruns/目录或MLFLOW_TRACKING_URI环境变量registry_uri无使用 MLflow 默认值Registry Server URI。不设置时使用tracking_uri的值或MLFLOW_REGISTRY_URI环境变量username/password无MLflow 服务端认证凭据详见下文认证章节model_name_separator_分隔模型名与版本号的字符串如model_1或model-1base_external_url无构建指向 MLflow UI 的外部 URL 时使用的基础地址不设置时若tracking_uri为 HTTP URL 则回退使用它两者都没有则不生成外部链接materialize_dataset_inputsfalse是否将每次 Run 的数据集输入实体化创建为新数据集source_mapping_to_platform无MLflow 数据集 source type 到 DataHub platform 的映射字典stateful_ingestion无有状态摄取配置继承自 StatefulIngestionConfigBase支持陈旧实体移除env继承PROD环境标识来自 EnvConfigMixin参与 MLModel / MLModelGroup 的 URN 构建4.1tracking_uri与registry_uri的作用_configure_client方法使用这两个地址构造MlflowClient。注意仅当tracking_uri以http开头时才会被用于生成指向 MLflow UI 的外部链接见_make_external_url/_make_external_url_from_run若指向本地mlruns/目录则不生成外部 URL对应单元测试test_make_external_link_local断言返回None。五、认证配置Auth Configuration连接器支持通过username与password配置项对 MLflow 服务端进行认证source: type: mlflow config: tracking_uri: http://127.0.0.1:5000 username: username password: password源码层面的细节password字段类型为TransparentSecretStr说明密码属于敏感配置应通过 DataHub 的密钥解析机制注入避免明文落盘在 _configure_client 中若username与password仅设置其一布尔值不相等会直接抛出ValueError(Both username and password must be set together)即二者必须成对出现两者都设置时连接器将它们写入MLFLOW_TRACKING_USERNAME/MLFLOW_TRACKING_PASSWORD环境变量后创建MlflowClient。六、数据集血缘Dataset LineageMLflow Run 可以记录输入数据集Dataset Inputs。连接器通过source_mapping_to_platform将不同 MLflow 引擎source type的数据集映射到指定的 DataHub 平台source_mapping_to_platform: huggingface: snowflake # Maps Hugging Face datasets to Snowflake platform http: s3 # Maps HTTP data sources to s3 platform默认行为仅按平台与名称链接到已存在的数据集不会创建新数据集。如需自动创建不存在的数据集需开启materialize_dataset_inputsmaterlize_dataset_inputs: true # Creates new datasets if they dont exist两个选项可以独立组合使用# Only map to existing datasets materlize_dataset_inputs: false source_mapping_to_platform: huggingface: snowflake # Maps Hugging Face datasets to Snowflake platform pytorch: snowflake # Maps PyTorch datasets to Snowflake platform # Create new datasets and map platforms materlize_dataset_inputs: true source_mapping_to_platform: huggingface: snowflake pytorch: snowflake说明原文档中该配置键写作materlize_dataset_inputs拼写与源码中的materialize_dataset_inputs不一致实际生效的字段名以 MLflowConfig 中的materialize_dataset_inputs为准。6.1 平台解析优先级源码实现_get_dataset_platform_from_source_type 展示了 source type → DataHub platform 的解析顺序用户配置映射优先使用source_mapping_to_platform中的显式映射内部映射gs→gcs的固定转换直接匹配若 source type 本身就是KNOWN_VALID_PLATFORM_NAMESDataHub 已注册的平台名中的合法平台则直接使用以上都不满足时返回None视为无法识别的平台。6.2 不同 source type 的处理分支_get_dataset_input_workunits 将数据集输入分为两类处理local/code类型始终创建 DataHub platform 为mlflow的本地数据集引用不涉及外部平台托管hosted类型开启materialize_dataset_inputs时先创建托管数据集platform 为映射结果再创建带COPY类型 upstream 的引用数据集若找不到映射平台则记录 failure 并跳过该数据集未开启时仅创建数据集引用并尽量与已存在的数据集建立 upstream 关系通过 graph 查询确认存在性所有数据集引用最终作为 RunDataProcessInstance的inputEdges写入DataProcessInstanceInputClass形成运行 → 输入数据集的血缘边。6.3 数据集 Schema 解析_get_dataset_schema 尝试解析 MLflow 数据集 schema优先提取mlflow_colspec中的字段名与类型列表JSON 解析失败时记录 warningschema 不可用时将其原始内容放入custom_properties[schema]保证信息不丢失。七、元数据映射原理Experiment → Run → Model 链路7.1 Experiment 作为容器每个 Experiment 通过 Container 摄取为 DataHub 容器实体subtype 为MLFLOW_EXPERIMENT描述取自mlflow.note.content标签附加属性中包含artifacts_location与 Experiment 自定义标签。7.2 Run 作为训练运行每个 Run 摄取为DataProcessInstancesubtypeMLFLOW_TRAINING_RUN携带MLTrainingRunPropertiesClass超参数hyperParams、训练指标trainingMetrics、artifact_uri输出地址、run_idDataProcessInstanceRunEventClass运行状态映射FINISHED→SUCCESS、FAILED→FAILURE、其他→SKIPPED及耗时durationMillis与所属 Experiment 容器的归属关系ContainerClass若 Run 产生了 Model Version则输出边指向对应 MLModelDataProcessInstanceOutputClass运行用户通过PlatformResourceInfoClass记录作为创建审计信息AuditStampClass.actor的载体。7.3 Registered Model 与 Model Version每个 Registered Model 摄取为MLModelGroup属性含创建/更新时间、描述、注册表标签、最新版本号URN 形如urn:li:mlModelGroup:(urn:li:dataPlatform:mlflow,模型名,env)每个 Model Version 摄取为MLModel模型名由model_name_separator拼接模型名 分隔符 版本号并关联所属 MLModelGroupgroups字段产生该版本的训练 RuntrainingJobs若模型注册时没有关联 Run则超参数与训练指标为None对应单元测试test_model_without_run版本集合VersionSetUrn与版本别名aliases外部链接指向 MLflow UI 的/#/models/name/versions/version。7.4 Stage 标签体系连接器为 Model Registry 的四个 Stage 预定义了 DataHub 标签mlflow_production绿、mlflow_staging黄、mlflow_archived灰、mlflow_none每个 Model Version 通过_get_global_tags_workunit打上对应 Stage 标签从而在 DataHub 中可视化模型的注册生命周期对应单元测试test_stages。八、能力与限制Capabilities Limitations连接器的能力声明见 MLflowSource 装饰器描述Descriptions提取 Registered Models 与 Model Versions 的描述容器Containers提取 MLflow ExperimentssubtypeMLFLOW_EXPERIMENT标签Tags提取 MLflow Registered Model Stages 标签。限制方面官方文档指出模块行为受限于源平台的 API、权限与暴露的元数据未支持或有条件支持的功能以能力说明为准。从源码可推断的实际限制包括需要 MLflow Server ≥ 1.28.0否则跳过 Experiments/Runs本地mlruns/目录模式不生成外部链接未提供平台映射的托管数据集在开启实体化时会被跳过并记录 failure模型未关联 Run 时MLModel 缺少超参数与训练指标。九、故障排查Troubleshooting官方文档给出的排查顺序建议先验证基础三要素凭据credentials、权限permissions、连通性connectivity再检查作用域过滤确认 scope filters如有没有误过滤掉目标实体最后审查摄取日志针对 source-specific 错误调整配置。结合源码补充两类可预期的日志现象版本不兼容日志中出现 MLflow API Endpoint Not Found... warning 时代表 Experiments/Runs 被跳过应升级 MLflow 服务端到 1.28.0实体化失败日志中出现 Unable to materialize dataset inputs... Please addmaterialize_dataset_inputs.source_mapping_to_platformin config. failure 时说明某个数据集 source type 缺少平台映射需要在source_mapping_to_platform中补充认证配置错误ValueError: Both username and password must be set together说明用户名与密码未成对配置。十、测试与验证仓库为连接器提供了两层测试保障可用于验证配置与行为是否符合预期单元测试test_mlflow_source.py覆盖 Stage 标签生成、model_name_separator的 URN 拼接、无 Run 模型的行为、分页遍历工具_traverse_mlflow_search_func、外部链接构造本地/远程/自定义 base URL以及本地数据集引用、实体化开关、平台映射等核心逻辑集成测试tests/integration/mlflow/test_mlflow_source.py使用临时mlruns目录模拟完整 MLflow 场景创建 Experiment、Run、注册模型、创建 Model Version、转换 Stage运行真实摄取管道并将输出 MCP 与 golden 文件 mlflow_mcps_golden.json 比对验证端到端元数据产出。这为在生产环境引入连接器前的本地验证提供了现成的参考范式先以 file sink 输出 MCP检查实体与血缘是否符合预期再切换到datahub-rest等真实 sink 正式上线。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
DataHub 集成 MLflow 元数据导入指南：连接器配置、认证与数据集血缘实践
DataHub 集成 MLflow 元数据导入指南连接器配置、认证与数据集血缘实践【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub导读本文围绕 DataHub 元数据摄取框架中的mlflow模块展开讲解如何将 MLflow 的 Experiments、Runs、Registered Models、Model Versions 以及数据集血缘Lineage导入 DataHub。读完本文你将掌握 MLflow 连接器的完整配置项含义、认证方式、数据集平台映射策略、版本兼容性边界以及如何在生产环境中排查摄取失败问题可直接套用文中的 recipe 配置投入实际使用。一、模块概述mlflow摄取什么mlflow模块是 DataHub 元数据摄取Metadata Ingestion框架中用于从 MLflow 摄取元数据的生产级连接器适用于正式生产环境的数据摄取工作流。其核心类为 MLflowSource在源码中被标注为BETA 支持状态support_status(SupportStatus.BETA)与platform_name(MLflow)。从 get_workunits_internal 的调度逻辑可以看出一次完整摄取会依次生成三类工作单元WorkunitStage 标签Tags为 MLflow Model Registry 中的每个 StageProduction、Staging、Archived、None创建 DataHub 全局标签Experiment 相关每个 Experiment 作为 DataHub 容器Container实体其下所有 Run 摄取为 DataProcessInstance训练运行并附带指标、超参数、输入数据集血缘模型相关每个 Registered Model 摄取为 MLModelGroup每个 Model Version 摄取为 MLModel 实体并关联对应的训练 Run。这三类元数据共同构成了 MLflow → DataHub 的完整映射实验组织模型运行驱动模型版本模型版本再通过 Stage 标签在 DataHub 中呈现生命周期状态。二、前置条件Prerequisites官方文档对运行摄取前的基础要求如下网络连通性确保运行摄取的环境能够访问 MLflow Tracking Server / Registry Server 的地址tracking_uri/registry_uri有效认证凭据若 MLflow 服务端启用了认证需要准备可用的用户名与密码元数据 API 读权限连接所用的账号必须具备读取 MLflow 元数据 API 的权限如读取 Experiments、Runs、Registered Models、Model Versions 等搜索接口。从源码实现看这些前置条件的缺失通常会在客户端初始化或搜索遍历阶段直接抛错或在 report 中记录 warning/failure属于先验证后摄取的硬性门槛。三、版本兼容性需要 MLflow Server 1.28.0连接器对 MLflow 服务端版本有明确要求必须为 1.28.0 或更高版本。若使用更早版本Experiments 与 Runs 的摄取会被跳过。这一要求背后有源码依据在 _traverse_mlflow_search_func 中连接器通过捕获MlflowException的ENDPOINT_NOT_FOUND错误码来兼容旧版本服务端——当 MLflow 服务端缺少search_experiments、search_runs等较新的分页搜索 API 端点时会记录一条 warningPlease upgrade to version 1.28.0 or higher...并跳过 Experiments/Runs 的摄取而不会导致整个管道崩溃。这也解释了为什么低版本下模型注册表Registered Models / Model Versions仍可能摄取但实验与运行数据会缺失。四、完整连接器配置官方 recipe 模板 给出了最小配置骨架source: type: mlflow config: # Coordinates tracking_uri: tracking_uri sink: # sink configs仓库中另有一份可直接运行的最小示例 mlflow_to_datahub.dhub.yamlsource: type: mlflow config: tracking_uri: http://127.0.0.1:5000 sink: type: datahub-rest config: server: http://localhost:8080基于 MLflowConfig 的字段定义全部可配置项如下配置项默认值说明tracking_uri无使用 MLflow 默认值Tracking Server URI。不设置时使用本地mlruns/目录或MLFLOW_TRACKING_URI环境变量registry_uri无使用 MLflow 默认值Registry Server URI。不设置时使用tracking_uri的值或MLFLOW_REGISTRY_URI环境变量username/password无MLflow 服务端认证凭据详见下文认证章节model_name_separator_分隔模型名与版本号的字符串如model_1或model-1base_external_url无构建指向 MLflow UI 的外部 URL 时使用的基础地址不设置时若tracking_uri为 HTTP URL 则回退使用它两者都没有则不生成外部链接materialize_dataset_inputsfalse是否将每次 Run 的数据集输入实体化创建为新数据集source_mapping_to_platform无MLflow 数据集 source type 到 DataHub platform 的映射字典stateful_ingestion无有状态摄取配置继承自 StatefulIngestionConfigBase支持陈旧实体移除env继承PROD环境标识来自 EnvConfigMixin参与 MLModel / MLModelGroup 的 URN 构建4.1tracking_uri与registry_uri的作用_configure_client方法使用这两个地址构造MlflowClient。注意仅当tracking_uri以http开头时才会被用于生成指向 MLflow UI 的外部链接见_make_external_url/_make_external_url_from_run若指向本地mlruns/目录则不生成外部 URL对应单元测试test_make_external_link_local断言返回None。五、认证配置Auth Configuration连接器支持通过username与password配置项对 MLflow 服务端进行认证source: type: mlflow config: tracking_uri: http://127.0.0.1:5000 username: username password: password源码层面的细节password字段类型为TransparentSecretStr说明密码属于敏感配置应通过 DataHub 的密钥解析机制注入避免明文落盘在 _configure_client 中若username与password仅设置其一布尔值不相等会直接抛出ValueError(Both username and password must be set together)即二者必须成对出现两者都设置时连接器将它们写入MLFLOW_TRACKING_USERNAME/MLFLOW_TRACKING_PASSWORD环境变量后创建MlflowClient。六、数据集血缘Dataset LineageMLflow Run 可以记录输入数据集Dataset Inputs。连接器通过source_mapping_to_platform将不同 MLflow 引擎source type的数据集映射到指定的 DataHub 平台source_mapping_to_platform: huggingface: snowflake # Maps Hugging Face datasets to Snowflake platform http: s3 # Maps HTTP data sources to s3 platform默认行为仅按平台与名称链接到已存在的数据集不会创建新数据集。如需自动创建不存在的数据集需开启materialize_dataset_inputsmaterlize_dataset_inputs: true # Creates new datasets if they dont exist两个选项可以独立组合使用# Only map to existing datasets materlize_dataset_inputs: false source_mapping_to_platform: huggingface: snowflake # Maps Hugging Face datasets to Snowflake platform pytorch: snowflake # Maps PyTorch datasets to Snowflake platform # Create new datasets and map platforms materlize_dataset_inputs: true source_mapping_to_platform: huggingface: snowflake pytorch: snowflake说明原文档中该配置键写作materlize_dataset_inputs拼写与源码中的materialize_dataset_inputs不一致实际生效的字段名以 MLflowConfig 中的materialize_dataset_inputs为准。6.1 平台解析优先级源码实现_get_dataset_platform_from_source_type 展示了 source type → DataHub platform 的解析顺序用户配置映射优先使用source_mapping_to_platform中的显式映射内部映射gs→gcs的固定转换直接匹配若 source type 本身就是KNOWN_VALID_PLATFORM_NAMESDataHub 已注册的平台名中的合法平台则直接使用以上都不满足时返回None视为无法识别的平台。6.2 不同 source type 的处理分支_get_dataset_input_workunits 将数据集输入分为两类处理local/code类型始终创建 DataHub platform 为mlflow的本地数据集引用不涉及外部平台托管hosted类型开启materialize_dataset_inputs时先创建托管数据集platform 为映射结果再创建带COPY类型 upstream 的引用数据集若找不到映射平台则记录 failure 并跳过该数据集未开启时仅创建数据集引用并尽量与已存在的数据集建立 upstream 关系通过 graph 查询确认存在性所有数据集引用最终作为 RunDataProcessInstance的inputEdges写入DataProcessInstanceInputClass形成运行 → 输入数据集的血缘边。6.3 数据集 Schema 解析_get_dataset_schema 尝试解析 MLflow 数据集 schema优先提取mlflow_colspec中的字段名与类型列表JSON 解析失败时记录 warningschema 不可用时将其原始内容放入custom_properties[schema]保证信息不丢失。七、元数据映射原理Experiment → Run → Model 链路7.1 Experiment 作为容器每个 Experiment 通过 Container 摄取为 DataHub 容器实体subtype 为MLFLOW_EXPERIMENT描述取自mlflow.note.content标签附加属性中包含artifacts_location与 Experiment 自定义标签。7.2 Run 作为训练运行每个 Run 摄取为DataProcessInstancesubtypeMLFLOW_TRAINING_RUN携带MLTrainingRunPropertiesClass超参数hyperParams、训练指标trainingMetrics、artifact_uri输出地址、run_idDataProcessInstanceRunEventClass运行状态映射FINISHED→SUCCESS、FAILED→FAILURE、其他→SKIPPED及耗时durationMillis与所属 Experiment 容器的归属关系ContainerClass若 Run 产生了 Model Version则输出边指向对应 MLModelDataProcessInstanceOutputClass运行用户通过PlatformResourceInfoClass记录作为创建审计信息AuditStampClass.actor的载体。7.3 Registered Model 与 Model Version每个 Registered Model 摄取为MLModelGroup属性含创建/更新时间、描述、注册表标签、最新版本号URN 形如urn:li:mlModelGroup:(urn:li:dataPlatform:mlflow,模型名,env)每个 Model Version 摄取为MLModel模型名由model_name_separator拼接模型名 分隔符 版本号并关联所属 MLModelGroupgroups字段产生该版本的训练 RuntrainingJobs若模型注册时没有关联 Run则超参数与训练指标为None对应单元测试test_model_without_run版本集合VersionSetUrn与版本别名aliases外部链接指向 MLflow UI 的/#/models/name/versions/version。7.4 Stage 标签体系连接器为 Model Registry 的四个 Stage 预定义了 DataHub 标签mlflow_production绿、mlflow_staging黄、mlflow_archived灰、mlflow_none每个 Model Version 通过_get_global_tags_workunit打上对应 Stage 标签从而在 DataHub 中可视化模型的注册生命周期对应单元测试test_stages。八、能力与限制Capabilities Limitations连接器的能力声明见 MLflowSource 装饰器描述Descriptions提取 Registered Models 与 Model Versions 的描述容器Containers提取 MLflow ExperimentssubtypeMLFLOW_EXPERIMENT标签Tags提取 MLflow Registered Model Stages 标签。限制方面官方文档指出模块行为受限于源平台的 API、权限与暴露的元数据未支持或有条件支持的功能以能力说明为准。从源码可推断的实际限制包括需要 MLflow Server ≥ 1.28.0否则跳过 Experiments/Runs本地mlruns/目录模式不生成外部链接未提供平台映射的托管数据集在开启实体化时会被跳过并记录 failure模型未关联 Run 时MLModel 缺少超参数与训练指标。九、故障排查Troubleshooting官方文档给出的排查顺序建议先验证基础三要素凭据credentials、权限permissions、连通性connectivity再检查作用域过滤确认 scope filters如有没有误过滤掉目标实体最后审查摄取日志针对 source-specific 错误调整配置。结合源码补充两类可预期的日志现象版本不兼容日志中出现 MLflow API Endpoint Not Found... warning 时代表 Experiments/Runs 被跳过应升级 MLflow 服务端到 1.28.0实体化失败日志中出现 Unable to materialize dataset inputs... Please addmaterialize_dataset_inputs.source_mapping_to_platformin config. failure 时说明某个数据集 source type 缺少平台映射需要在source_mapping_to_platform中补充认证配置错误ValueError: Both username and password must be set together说明用户名与密码未成对配置。十、测试与验证仓库为连接器提供了两层测试保障可用于验证配置与行为是否符合预期单元测试test_mlflow_source.py覆盖 Stage 标签生成、model_name_separator的 URN 拼接、无 Run 模型的行为、分页遍历工具_traverse_mlflow_search_func、外部链接构造本地/远程/自定义 base URL以及本地数据集引用、实体化开关、平台映射等核心逻辑集成测试tests/integration/mlflow/test_mlflow_source.py使用临时mlruns目录模拟完整 MLflow 场景创建 Experiment、Run、注册模型、创建 Model Version、转换 Stage运行真实摄取管道并将输出 MCP 与 golden 文件 mlflow_mcps_golden.json 比对验证端到端元数据产出。这为在生产环境引入连接器前的本地验证提供了现成的参考范式先以 file sink 输出 MCP检查实体与血缘是否符合预期再切换到datahub-rest等真实 sink 正式上线。【免费下载链接】datahubThe Context Platform for your Data and AI Stack项目地址: https://gitcode.com/GitHub_Trending/da/datahub创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考
