在 Google Colab 上使用 Fancy Stateful Metaflow 服务 + UI？
未来人工智能在企业中更广泛的应用在于许多小型专业模型和持续训练，持续训练是指使模型能够随着新数据的可用而随时间推移进行调整和改进。
我们的目标是帮助更多的机器学习工程师享受可扩展性、自动化、性能监控和持续集成带来的乐趣。我知道你可能会说这听起来很拗口。但这不像听起来那么无聊。
多年来，由于对复杂性的沮丧，我们决定更广泛地尝试帮助普及 MLOps（机器学习操作）以及与机器学习流程工业化相关的一切。我们认为不应该到处都是障碍，尤其是在机器学习实验和机器学习产品化之间（注意，我在这里不是在谈论研究，尽管我秘密希望有朝一日“工业化研究”会普及——但这又是另一个故事了）。
首先，我们认为一个好的切入点是**框架**。这些小巧而美好的东西让我们的生活变得更轻松。其中之一是 Metaflow。还有其他解决方案，例如 Kubeflow 或 ZenML，我也都很喜欢。
免责声明：不，这不会充满技术术语或令人应接不暇的指令。如果你是一个喜欢修修补补的人，请耐心等待，你可能会享受这次旅程。让我们深入探讨。
什么是 Metaflow？
我长话短说。Metaflow是一个基于Apache 2许可的开源框架，用于数据科学和机器学习工作流。它于2017年在Netflix内部创建，并于2019年开源。我们可以说它根基深厚。
对于每个工作流步骤，它通过管理 conda 或 pypi 依赖项来提供环境隔离，以及诸如 Ray、Kubernetes 或 AWS Batch 等远程任务和可伸缩计算的选项。您还可以指定为每个步骤分配的资源，例如内存大小或 CPU 和/或 GPU 的数量。我们最喜欢的部分是：它通过用户友好的 API 完成所有这些，使开发和部署变得容易。
它上手快，使用便捷。
为什么需要有状态（但可废弃）的机器学习框架实例？
毕竟，我们小故事中的第二个大玩家 Google Colab 只是一个临时运行时。那么，为什么还要在那里跟踪和记录任何东西呢？
嗯，提供有状态但可废弃的机器学习框架实例的重点其实并非跟踪，而是为了快速草拟的便利性。开发者喜欢快速完成草稿，并乐于从头开始，丢弃所有那些混乱的中间尝试，以使某个东西运行起来。谁没有因为缺少逗号或缩进问题而不得不重新运行草稿脚本呢？显然，从那些试运行中存储训练工件是不可取的。
而且，说真的，当你只是在草拟你的再训练管道时，为什么还要追踪版本化的数据集分割和训练过的模型版本等东西呢？把所有这些存储在企业环境的云上会花费一大笔钱，尤其是当谈到成千上万次试运行时，即使对于小型团队也是如此。
在企业环境中，开发人员和机器学习工程师喜欢的是能够自由地启动一个虚拟机，在上面安装一个本地 Metaflow，如果需要的话，花几天时间草拟他们的再训练管道，然后一旦完成就丢弃整个主机（并随意迭代）。所有这些都同时对他们的再训练管道代码进行版本控制，而这才是现阶段唯一重要的事情。
哦，友情提示：“有状态”的 Metaflow/Colab 故事确实面向那些忙碌的人，并且涉及 Google Drive，但我们稍后会深入探讨。
既然我们已经涵盖了这些，那么让我们深入探讨吧！
Metaflow 是如何发布的？
AWS 提供了一个简单托管的 Metaflow 版本，可以轻松部署。 Outerbounds，Netflix 现在的衍生公司，也在 AWS 上提供大量的企业级服务和支持。
总的来说，如果你想以自托管的方式使用它，例如在本地，如果你想安装 Metaflow，需要克隆两个 GitHub 仓库：Metaflow 服务和Metaflow UI。后者只有一个 Docker 容器，所以相当简单。另一方面，前者包含由 Docker Compose 管理的小型 Docker 容器集群。清单如下：
我们想
- 避免对 AWS S3 桶的需求，这不是一件容易的事。
- 通过单一设置入口点简化部署
- 允许 Google Colab 托管，因此需要克服那里缺少 Docker 支持的问题
黑子们尽管黑吧！
我们提供的 Google Colab Metaflow 版本是什么样的？
首先，我们完全去掉了 metaflow-migration 容器，主要是因为它实在太大了（几乎是所有其他容器的总和），而且显然是多余的。我们只是通过从源代码检索到的 sql 查询在初始启动时构建数据库模式，仅此而已。
然后，我们没有使用 Docker，而是依赖 UDocker。这是所有一切的奇迹。所有阅读本文的人都应该立即在 GitHub 上给他们点赞。当然，它与 Docker 相比有一些限制，但没有什么我们无法克服的。其中一个限制是它不能从 Dockerfile 构建镜像。所以，我们做了这件事，并将镜像推送到 hub，以便 UDocker 可以拉取它们。没什么大不了的。
从那时起，我们所做的是：
- 创建一个单独的 bash 脚本，完成 100% 的设置、所有繁重的工作和所有清理工作。省心。
- 挂载一个中央卷，所有东西都放在那里。PostgreSQL 数据文件、所有容器的日志，当然还有数据存储。
- 此外，我们还实现了一个反向代理。为此，我们借鉴了 @radames（此处）的灵感。
备注：MF_ROOT 挂载的默认值为 /data，但可以通过同名环境变量设置为任何本地目录。
- 设置
export MF_ROOT=/content/drive/MyDrive/Metaflow将是实现有状态性的理想选择，但还有一个小细节。PostgreSQL（Metaflow 使用的数据库技术）使用预写日志（WAL）写入磁盘，而 Google Drive 不支持 WAL。因此，为了实现有状态性，我们不得不采取创造性的方式，添加可选的PGDATA_DIR环境变量，并将其设置为/content/pgdata。
现在，为了保持数据库和其他部分的有状态性，我们通过inotifywait（GPL2 许可证）监控该位置，并通过rsync（GNU 许可证，随 Ubuntu 提供）进行同步。 - 为了使这个有状态的 Metaflow 服务+UI 可用于另一个 Google Colab 笔记本（例如具有 GPU 运行时的笔记本），我们将其
7860端口暴露（到托管 Metaflow 的 [CPU] Google Colab 笔记本外部）。为此，我们参考了 Cloudflare 快速隧道。
它们很棒，免费使用，甚至不需要帐户。如果你问我，梦想成真。
结果看起来像这样：
我们将所有这些打包在 2 个 Google Colab 笔记本中：
-
metaflow_service.ipynb，其中包含您需要执行的步骤，以启动您的个人有状态 Metaflow 服务+UI：
- 挂载您的 Google Drive
- 启动 inotifywait 进程
- 生成 Cloudflare tunnel 的外部访问 URL
- 下载并运行我们的 安装 bash 脚本
-
remote_local_metaflow.ipynb，其中所有设置都已完成，您可以运行 Metaflow "Hello World" 流程，它会将所有内容跟踪和记录到您的个人 有状态 Metaflow 服务+UI 中。
非常适合您开始草拟机器学习模型的再训练管道，该模型可能需要 Google Colab 免费层提供的 GPU。有了第二个 Google Colab 笔记本，您就万事俱备了。
最后的话
我们已经初步了解了标准的 Metaflow 架构，以及如何在不需要 S3 存储桶的情况下安装和使用它。这不是很酷吗？
您可以在此 Github 页面上找到本文的精简版，以及一些额外内容，包括在本地机器上安装和使用的另一种方法。
好事多磨。这只是我夏天以来一直在构建的某个非常酷的东西的序曲，我很快就会在这里发布相关内容，所以，请给我点赞并保持关注！