Azure Databricks 7.3 LTS ML Runtime导入mlflow失败

• 核心故障是Azure ML相关依赖版本严重错配：当前环境中azureml-core为1.8.0.post1，但其余所有azureml组件（azureml-telemetry、azureml-train、azureml-pipeline系列等）均为1.19.0版本，高版本组件强制要求依赖azureml-core~=1.19.0，直接导致所有azureml运行类型提供器加载失败。
• 版本冲突连锁破坏mlflow加载链路：环境中azureml-mlflow为1.8.0版本，和已安装的mlflow 1.11.0、1.19.0版本的其余azureml组件完全不兼容，加载时找不到mlflow 1.11中已调整存储路径的mlflow.store.rest_store模块，才会反复弹出“请升级到Mlflow 1.4.0或更高”的误导性提示——当前安装的mlflow 1.11.0本身版本满足要求，只是插件加载流程被依赖冲突打断了。
• 存在次级依赖缺口：当前环境msrest版本为0.6.18，而azure-mgmt-containerregistry要求msrest版本>=0.6.21，会进一步加剧组件加载失败问题。
• 之前重装mlflow无效的原因很明确：故障点根本不在mlflow包本身，是上层azureml包的版本冲突卡死了mlflow的导入流程。
• 日志末尾两条tensorflow相关的DeprecationWarning是Python 3.7和旧版tensorflow的兼容提示，和mlflow导入失败无关，可直接忽略。

按优先级选择对应操作即可：

方案1：全量对齐azureml包版本（推荐，适配需要对接Azure ML的场景） #

在Notebook首个单元格执行以下命令，将所有azureml相关包统一到兼容版本，执行完成后重启集群内核即可恢复正常：

%pip install azureml-core==1.19.0 azureml-mlflow==1.19.0 msrest==0.6.21 --force-reinstall

注意：所有azureml-*前缀的包必须保持完全一致的版本号，禁止单独升级/降级某一个azureml组件，否则必然出现依赖冲突。

方案2：卸载冲突插件（适配仅需本地使用mlflow的场景） #

如果不需要将mlflow对接Azure Machine Learning工作区，直接卸载导致冲突的azureml-mlflow插件，切断报错加载链路即可：

%pip uninstall -y azureml-mlflow

执行完成后重启内核，mlflow即可正常导入，不会再出现版本类报错。

长期避坑提示 #

• 7.3 LTS ML Runtime属于较早的版本，预装组件版本固定，不要在集群全局库中单独安装某一个高版本azureml包，如需安装必须全系列对齐版本。
• 安装第三方包前可先执行pip check扫描现有依赖冲突，可提前规避绝大多数导入类故障。

内容的提问来源于stack exchange，提问作者Mariana