MLflow 0.x 演进史从实验追踪到数据库存储、Docker 项目与插件生态的开源基石【免费下载链接】mlflowThe open source AI engineering platform for agents, LLMs, and ML models. MLflow enables teams of all sizes to debug, evaluate, monitor, and optimize production-quality AI applications while controlling costs and managing access to models and data.项目地址: https://gitcode.com/GitHub_Trending/ml/mlflow导读本文以 changelogs/v0.x.md 为骨架系统梳理 MLflow 从 0.1.02018-06-05到 0.9.12019-04-21这段打地基时期的版本演进包括 Tracking API 的三次重构、REST API 与 CLient 协议演进、SQLAlchemy 数据库后端引入、MLflow Projects 的 Docker 化、pyfunc/模型风味体系成型、Artifact Store 家族扩张以及基于 entry point 的插件系统诞生。文中每一项关键能力都会落到当前仓库 mlflow 源码中对应的实现位置帮助读者既理解 0.x 版本当时为什么这么做也看清这些设计如何延续至今。读完本文你将能够按版本还原 MLflow 早期核心 API 的调用方式与迁移路径对照源码定位数据库存储、FileStore、各 Artifact Repository 与插件注册表的实现并理解从脚本实验管理走向生产级 AI 平台的第一块基石是如何铺就的。说明本文所有源码现状均指当前仓库快照0.x 时期的具体行号与代码细节以历史版本为准此处仅借助现有实现印证当年引入的架构设计。一、版本全景0.1.0 → 0.9.1 的演进主线0.x 阶段共发布 16 个版本按发布节奏可划分为四个阶段阶段版本时间主线主题奠基期0.1.0 / 0.2.0 / 0.2.12018-06 ~ 2018-06首个版本、mlflow server远程追踪、TensorFlow 集成API 成型期0.3.0 ~ 0.4.22018-07 ~ 2018-08Spark MLlib、GCS/S3/DBFS/Azure Blob 存储、REST API 规范化SDK 多元化期0.5.0 ~ 0.6.02018-08 ~ 2018-09Keras/PyTorch 一等公民、Python SDK 正式化、Java 客户端、MLeap规模化与工程化期0.7.0 ~ 0.9.12018-10 ~ 2019-04R 客户端、删除/恢复 Run、SQL 数据库后端、Docker 项目、插件系统、Search API 重写贯穿始终的几条主线值得先记住Tracking API 的分层与收敛从单一的mlflow.tracking模块拆分为基础日志 APImlflow 追踪服务 APImlflow.tracking最终统一到MlflowClient后端存储从文件系统走向数据库0.9.0 引入 SQLAlchemy 兼容数据库MySQL / PostgreSQL / SQLite / MS SQL并保持与文件存储的兼容模型体系走向标准化save_model/log_model默认携带 Conda 环境pyfunc 成为通用打分入口application/json的 pandas-split 格式成为默认可扩展性从零开始mlflow.tracking_store、mlflow.artifact_repository、mlflow.run_context_provider三个 entry point 组定义了第三方插件生态。二、奠基期0.1.0 ~ 0.2.1第一个mlflow server与 TensorFlow 集成2.1 0.1.0项目起点0.1.0 是 MLflow 的初始版本2018-06-05。从 changelog 看它的核心使命是把实验追踪这件事做对提供 Tracking 基础 API、MLflow Projects 项目格式MLproject 文件描述入口点与依赖、以及模型打包能力。这些设计在 mlflow 目录中至今保留mlflow/tracking/fluent.py中的start_run、log_param、log_metric、set_experiment等函数见 fluent.py就是 0.1.0 时代 basic logging API 的直系后裔。2.2 0.2.0 / 0.2.1远程追踪服务与协议修正0.2.0 引入了mlflow server用于提供远程追踪服务它在mlflow ui基础上新增--host允许绑定任意端口#27--artifact-root将产物存储到远程位置此时仅支持 S3#78服务端改由 gunicorn 承载支持并发请求#61。0.2.1 是紧随其后的补丁版将 protobuf 实现切换为 C 实现修复 tensorflow/mlflow 导入顺序问题issue #33、#77PR #74允许在未安装 git 二进制的情况下运行mlflow server#90修复多节点集群上的 Spark UDF 支持#92。从源码看mlflow server的遗产就是今日的追踪服务端与各RestStore当前 rest_store.py 中的RestStore即负责把 Tracking 操作序列化为对远程服务器的 REST 调用。三、API 成型期0.3.0 ~ 0.4.2SparkML、云端存储与 REST API 规范化3.1 0.3.0Spark MLlib 与异步执行0.3.0 的关键能力Spark MLlib 集成支持在log_modelAPI、模型格式与 serving API 中直接记录 SparkML 模型#72Google Cloud StorageGCS作为 artifact 存储根#152支持异步/并行执行 MLflow runs#82SageMaker 部署支持删除与更新应用#145并简化部署参数、提供合理默认值#126。GCS 存储的遗产是当前 gcs_artifact_repo.py 中的GCSArtifactRepository它仍是今天 Artifact 家族的一员。3.2 0.4.0REST 协议收敛与可选依赖0.4.0 发生了三处影响深远的变更use_temp_cwd被移除#215本地项目运行直接以本地项目目录为工作目录Git 项目才拉取到临时目录。这使mlflow run的行为更符合直觉。GCS artifact 存储改为可插拔依赖#202不再随默认安装附带需要pip install google-cloud-storage且客户端与追踪服务器都要安装——这是 0.9.0 插件系统可插拔后端思想的第一次落地。JSON 双重序列化修复#2000.4.0 及以上的客户端要求服务器版本不低于 0.4.0但 0.4.0 服务器保持对旧客户端向后兼容#216。3.3 0.4.1 / 0.4.2环境与实验细节$MLFLOW_CONDA_HOME可指定 conda 安装目录默认回退到系统conda0.4.1#231实验 REST API 与mlflow experiments create支持--artifact-location0.4.2#232DBFS artifact store 加入0.4.2#226其实现延续至今为 dbfs_artifact_repo.py 中的DbfsRestArtifactRepository客户端 REST 请求统一使用 snake_case 字段名0.4.2#232。这一时期逐步勾勒出 MLflow 存储体系的骨架本地 FileStore、SQL/云 artifact repository、以及统一的mlflow.tracking_store注册机制。四、SDK 多元化期0.5.0 ~ 0.6.0Keras/PyTorch、Python SDK 正式化与 Java 客户端4.1 0.5.0Tracking API 的大分裂0.5.0 是 Python SDK 历史上最重要的重构之一将 Tracking API 拆为两半基础日志 API负责向当前激活的 run记录 metrics、parameters 与 artifacts位于mlflow顶层命名空间例如mlflow.log_param追踪服务 API负责管理实验与 run尤其是历史 run位于mlflow.tracking并预演了后续 R 与 Java SDK 的形态。由此带来的破坏性变更迁移指南旧写法新写法from mlflow.tracking import log_paramfrom mlflow import log_parammlflow.tracking.get_service().get_run()mlflow.tracking.get_service().get_run()需先经set_tracking_uri()或MLFLOW_TRACKING_URI配置mlflow.ActiveRun上的特殊方法对象变为mlflow.entities.Run的轻量包装支持with语法特殊方法迁移到 service APImlflow.entities.experiment.Experimentmlflow.entities.Experiment旧路径仍存在但已弃用此外0.5.0 还引入Keras / PyTorch 一等公民支持#280、#264可直接在log_modelAPI、模型格式与 serving API 中使用Compare Runs 散点图#268以任意两个 metric 为轴对比 runSFTP artifact store#260对应今天的 sftp_artifact_repo.pypyfunc 序列化携带 Python 版本主版本不一致时告警可用load_pyfunc(suppress_warningsTrue)关闭#230mlflow pyfunc serve/predict自动激活 MLModel 中存储的 conda 环境可用--no-conda关闭#225mlflow run支持无conda.yaml的项目默认创建空 conda 环境而不是直接失败#218。4.2 0.5.1 / 0.5.2关键修复with mlflow.start_run() as run现在真正把run设置为创建的 Run此前为 None0.5.1#322Python 3.7 tarfile 支持修复#329修复 Sparkload_model删除 DFS 临时目录的问题#335SageMaker ECR 客户端创建导致部署失败的问题0.5.2#366。4.3 0.6.0Java 客户端与 MLeap0.6.0 标志着 MLflow 从Python 专属走向多语言平台Java 客户端Maven 上以mlflow:mlflow发布支持 Tracking API可创建与管理 experiments、runs、artifactsMLeap 格式SparkML 模型在适用时同时保存为 MLeap 格式SageMaker 默认使用该格式以大幅降低预测延迟#324 等Experiment 删除与恢复REST API、Python Tracking API、CLI 三端打通#340 等Tag 机制重构通过 SetTag API 设置且从RunInfo迁移到RunData#342mlflow artifactsCLI用于列出、下载、上传 run artifact#391--host选项加入mlflow serve#401HTTP auth 环境变量username/password/token支持远程追踪服务器#402S3 endpoint 覆盖支持#451。0.6.0 同时做了命名收敛为 0.9.0 的MlflowClient铺路MLflowService→MlflowClientmlflow.tracking.get_service()→mlflow.tracking.MlflowClient()list_runs→list_run_infos返回RunInfo而非Runlog_artifact/log_artifacts改为接收run_id而非artifact_uri与list_artifacts、download_artifacts保持一致#444。这些 API 的当代形态仍可在 mlflow/tracking 与 mlflow/client.py 中找到。五、规模化与工程化期0.7.0 ~ 0.9.1R 客户端、SQL 后端与插件系统5.1 0.7.0R 客户端、Run 删除与笔记0.7.0 三大主题R 客户端 API即将发布到 CRAN#370、#471、#548删除 RunPython API、REST API、UI 三端支持#418、#473、#526、#579Run 笔记UI 支持为 run 添加说明#396。其他要点set_experimentAPI在执行 run 前激活某个实验#462Tracking 与 Projects API 支持指定 parent run 参数#547——这是嵌套 run 能力的 API 侧配套logMetric的 REST 参数由 float 改为 double#566每个 flavor 的load_pyfunc实现改为私有#539。5.2 0.8.xUI 性能、默认 conda 环境与 pandas-split0.8.0 的 UI 革新为今日 Experiments 界面定调metrics 与 params 默认合并在同一列可单独拆列对比嵌套 run 按父 run 分组展示可整体展开/折叠通过mlflow.start_run或mlflow.run在 run 内嵌套触发展示 run 名称而非 UUID便于图表对比表格的过滤器、排序、展开状态持久化到浏览器 localStorage。0.8.1 ~ 0.8.2 继续夯实pyfunc server 与 SageMaker 支持 pandassplitJSON 格式Content-Type: application/json; formatpandas-split该格式在 0.9.0 成为默认0.8.0#690默认在保存模型中附带 Conda 环境指定加载所需的全部版本化依赖0.8.1#705 等mlflow sklearn serve被移除统一改用mlflow pyfunc serve0.8.0#690CloudPickle 加入默认依赖修复模型保存时的缺失导入0.8.2#777PyTorch 模型可携带 code dependencies 保存0.8.2#842。5.3 0.9.0数据库后端、Docker Projects 与插件系统——0.x 时代的大版本0.9.0 是 0.x 系列信息量最大的一个版本其能力几乎全部沿用至今。5.3.1 数据库后端SQLAlchemy Tracking Store社区呼声最高的可扩展、高性能后端存储正式落地支持本地或远程 SQLAlchemy 兼容数据库官方列出的风味为MySQL、PostgreSQL、SQLite、MS SQL与基于文件的后端存储FileStore保持兼容实现位于当前仓库 sqlalchemy_store.py其类文档明确声明支持mysql、mssql、sqlite、postgresql四种方言数据库 URI 格式为dialectdriver://username:passwordhost:port/database未指定 driver 时使用方言默认驱动元数据落库于 SQL 表SqlExperiment / SqlRun / SqlTag / SqlMetric / SqlParamrun 的 artifact 则仍交给 ArtifactRepository 存到独立位置artifact 位置记录在 SqlRun 中见 sqlalchemy_store.py。与之相对的文件后端 FileStore 同样保留至今file_store.py其目录布局meta.yaml、metrics/、params/、tags/、artifacts/、.trash默认实验 ID 为0就是 0.9.0 之前 Tracking 的默认存储形态。值得一提的是当前版本中 FileStore 已进入维护模式初始化时会提示迁移到数据库后端并可通过MLFLOW_ALLOW_FILE_STOREtrue选择继续使用见 file_store.py——这正是 0.9.0 那次数据库优先决策的长期回响。5.3.2 Docker 容器中的 MLflow ProjectsProjects 支持在 Docker 容器中运行可以在项目环境中包含非 Python 依赖提供比 conda 更强的隔离性用法在 MLproject 文件中配置 Docker 环境镜像mlflow run时按镜像启动容器执行项目。这一能力的后代是 mlflow/projects 目录中的项目执行后端以及 docker 与 docker-compose 下的官方镜像与编排示例。5.3.3 简化自定义 Python 模型打包mlflow.pyfunc的 Python API 更新后可以方便地在模型中包含自定义预处理/后处理逻辑与数据依赖。pyfunc 成为所有模型风味的统一运行时接口mlflow pyfunc serve、mlflow pyfunc predict、以及 Spark UDF 打分都基于这一层。当前实现可见 mlflow/pyfunc 目录与 model.py。5.3.4 插件系统三大 entry point 组0.9.0 将第三方扩展从个案变成制度化机制通过三个 entry point 组实现mlflow.tracking_store注册额外的 Tracking Store 提供者#881。当前 registry.py 仍保留对mlflow.tracking_store组的入口点注册说明。mlflow.artifact_repository注册额外的 Artifact Repository 提供者#882。当前 artifact_repository_registry.py 中的register_entrypoints正是通过get_entry_points(mlflow.artifact_repository)逐个加载并注册第三方实现。mlflow.run_context_provider将从 run 上下文生成 run 元数据如source_name、source_version的逻辑重构为可扩展系统插件可以追加或覆盖基础库设置的 tag#913、#926、#930、#978。配合这三点的是 R 客户端对 Tracking Server 的 HTTP 认证支持可通过环境变量设置凭据或提供自定义插件例如随附的 Databricks 插件可自动探测既有 Databricks 凭据。5.3.5 pyfunc 打分服务器格式变更一个影响所有部署用户的行为变更0.9.0 起pyfunc 打分服务器要求application/json内容类型包含split 格式{columns: [...], data: [[...]]}的 JSON 序列化 pandas DataFrame而非 records 格式#960同时从 JSON 读取 pandas DataFrame 时不再自动推断数据类型以避免意外的类型转换#916。这意味着 0.8.x 中推荐切换到 pandas-split的迁移预告正式生效旧 records 格式客户端必须更新。5.3.6 REST API 与 Search API 的关键变更GetMetric/GetParam从 REST API 中移除由GetRun统一涵盖#879Search 过滤器迁移到查询字符串语法Java 客户端、Python 客户端与 UI 同步支持并改进引号、句点与特殊字符处理过滤器字符串还可搜索 tag#1042 等LogBatch 实验性支持引入批量日志基础能力但明确标注 experimental、行为将变#950 等批量日志 API 的限制与校验加入 OSS server#958。5.4 0.9.1为 1.0 铺路的补丁版0.9.1 是 0.9.0 之上的补丁版核心内容experiment_id从 long 泛化为 string#1067为不同后端存储的 ID 类型提供更宽松的兼容对 REST API 是破坏性变更但对 Python 与 R 客户端向后兼容Search API 显著改进过滤器迁移到查询字符串语法见 0.9.0 小节在 0.9.1 中获得大量完善MlflowClient.create_run重新引入parent_run_id参数计划在 1.0 移除#1137R 客户端补丁以 0.9.0.1 形式发布到 CRAN#1123 等。0.9.0.12019-04-09是 PyPI 专属补丁重建 JS 资源以修复 0.9.0 中表单输入损坏的问题#1056、#1113。六、贯穿 0.x 的架构主线从源码看今天的样子把 0.x 时代的三大发明与当前仓库一一对照可以更清晰地看到架构连续性6.1 Tracking 存储层Store 抽象0.9.0 确立的 Store 抽象层次至今未变AbstractStoremlflow/store/tracking/abstract_store.py ├── FileStore — 本地文件系统实现mlflow/store/tracking/file_store.py ├── SqlAlchemyStore — SQL 后端实现支持 mysql/mssql/sqlite/postgresql └── RestStore — 远程服务器 REST 客户端mlflow/store/tracking/rest_store.py与 0.x 时代文件存储兼容数据库存储的目标一致当前 SQL 后端的 artifact 位置信息仍存于数据库、实际文件交给 ArtifactRepository 管理说明元数据与制品分离的架构决策从 0.9.0 起就没有改变过。6.2 Artifact 层Repository 家族0.3.0 ~ 0.5.0 引入的云端存储都在今天的 mlflow/store/artifact 目录中留下了直接后代0.x 引入当前实现S3 artifact store0.2.0 起--artifact-roots3_artifact_repo.pyS3ArtifactRepositoryGCS0.3.00.4.0 起可插拔gcs_artifact_repo.pyGCSArtifactRepositoryDBFS0.4.2dbfs_artifact_repo.pyDbfsRestArtifactRepositoryAzure Blob0.4.0azure_blob_artifact_repo.pyAzureBlobArtifactRepositoryFTP0.8.0ftp_artifact_repo.pyFTPArtifactRepositorySFTP0.5.0sftp_artifact_repo.pySFTPArtifactRepository6.3 插件系统entry point 注册表0.9.0 的插件机制不仅存活而且成为 MLflow 生态扩展的标准入口Tracking Storemlflow.tracking_store见 registry.pyArtifact Repositorymlflow.artifact_repositoryartifact_repository_registry.py 中通过get_entry_points动态加载第三方实现模型注册表 Store 同样采用 entry point 注册模式见 mlflow/tracking/_model_registry/registry.py。七、给迁移者与读者的实践建议协议版本敏感0.4.0 起客户端/服务器存在版本耦合升级追踪服务器时先确认客户端版本不低于服务器关键版本0.9.1 起experiment_id为字符串旧 REST 调用需适配。pyfunc 格式先行如果你维护基于 REST 的打分客户端应使用 pandassplit格式application/json; formatpandas-split并显式声明列顺序不要依赖服务端自动推断数据类型。存储选型个人/小团队实验可用 SQLite URI如sqlite:///mlflow.db生产多用户场景选择 PostgreSQL 或 MySQLGCS、S3、Azure Blob 等制品仓库在 0.9.0 之后均通过mlflow.artifact_repository插件或内置实现接入。依赖管理从 0.8.1 起模型默认携带 Conda 环境0.9.0 起 Docker 项目提供更强的环境隔离。当前仓库的 examples 目录如mlflow-3、virtualenv、uv-dependency-management展示了从 conda 到 virtualenv/uv 的依赖管理演进。八、结语0.x 是 MLflow 架构的分水岭回看 changelogs/v0.x.md0.x 时代并非简单的早期补丁堆积而是完成了几项决定平台命运的架构决策Tracking 从单机文件到 SQL 数据库与 REST 服务化支撑了团队协作与大规模实验模型体系以 pyfunc 为轴心统一打包、打分、部署与 UDF 集成插件系统让存储与上下文生成成为开放扩展点第三方如 Databricks 凭据插件可以无缝接入多语言客户端Python / R / Java与多制品后端S3/GCS/Azure/DBFS/FTP/SFTP共同定义了开放平台的基本盘。这些决策在今天的 mlflow 源码、docs 与 examples 中仍然清晰可辨。理解 0.x 的演进就是理解 MLflow 为何能在后续版本中成长为面向 Agent、LLM 与 ML 模型的生产级 AI 工程平台。【免费下载链接】mlflowThe open source AI engineering platform for agents, LLMs, and ML models. MLflow enables teams of all sizes to debug, evaluate, monitor, and optimize production-quality AI applications while controlling costs and managing access to models and data.项目地址: https://gitcode.com/GitHub_Trending/ml/mlflow创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考