面向数据科学与新一代人工智能的 K8S

数据科学家和软件工程师有许多相同的关注点:可重复的实验(比如可重复的构建);可移植和可复制的环境(如在开发、过渡和生产环境中具有相同的设置);凭证管理;跟踪和监控生产环境中的指标;灵活的路由;轻松扩展。不难看出,应用程序开发人员使用 Kubernetes 所做的事情与数据科学家可能想做的事之间有一些类似之处:

  • 可重复的批处理作业,如 CI/CD 管道,类似于机器学习管道,多个协同阶段在其中以可重复的方式一起处理数据、提取特征、训练、测试和部署模型;
  • 描述服务之间连接的声明性配置有助于创建跨平台的可重复学习管道和模型;
  • 微服务架构支持在管道中对机器学习模型进行简单地调试,并帮助数据科学家和他们团队中的其他成员进行协作。

数据科学家与应用程序开发人员面临许多相同的挑战,但他们也面临一些独特的挑战,这些挑战与数据科学家的工作方式以及机器学习模型比传统服务更难测试和监控这一事实有关。我们将重点讨论一个与工作流相关的问题。

大多数数据科学家使用交互式笔记本(interactive notebooks)工作,这是一个笔记本环境,通常由 Project Jupyter 开发,提供一种交互式 迭代编程环境,用户可以在其中混合说明性本文和代码、运行并更改代码、检查其输出。

这些特性使得该环境对探索性分析非常灵活。然而,它们并不是用于协作或发布的理想软件工件——想象一下,如果软件开发人员发布工作的主要方式是将来自交互式 REPL 脚本发布到 pastebin 服务。

与同事分享交互式笔记本就像分享实体笔记本一样——里面有一些很好的信息,但是必须仔细查找才能找到。由于笔记本的脆弱性和对环境的依赖性,同事在运行笔记本时可能会看到不同的输出——甚至更糟:它可能会崩溃。

数据科学家可能不想成为 Kubernetes 专家——这很好!Kubernetes 的优点之一就是构建更高级工具的强大框架。

Binder 服务 就是其中一个工具,采用一个 Jupyter 笔记本的 Git 存储库,构建容器镜像来提供服务,然后在路由公开的 Kubernetes 集群中启动镜像,这样就可以从公网访问。由于笔记本的一大缺点是其正确性和功能可能依赖于其环境,因此,如果有一个高级工具可用来构建不可变环境为 Kubernetes 上的笔记本提供服务的话,就可以避免许多让人头疼的事。

你可以使用托管的 Binder 服务或 运行自己的 Binder 实例,但是,如果你想在这个过程中获得更大的灵活性,你还可以使用 Source-To-Image(S2I)工作流和工具,以及 Graham Dumpleton 提供的 Jupyter S2I 镜像 上线自己的笔记本服务。事实上,对于基础设施专家或打包专家来说,Source-To-Image 工作流是构建可供主题专家使用的高级工具的良好起点。例如,Seldon 项目 使用 S2I 来简化模型服务发布——只要向构建器提供一个模型对象,它将构建一个容器并将其作为服务公开。

Source-To-Image 工作流的一个优点是,它支持在构建映像之前对源存储库进行任意操作和转换。有个例子可以说明这个工作流有多强大,我们 创建了一个 S2I 构建器镜像,该镜像以一个 Jupyter 笔记本作为输入,该笔记本展示了如何训练模型。然后,它处理这个笔记本以确定它的依赖关系,并提取 Python 脚本来训练和序列化模型。有了这些,构建器就会安装必要的依赖项并运行脚本来训练模型。构建器的最终输出是一个 REST Web 服务,它为由笔记本构建的模型提供服务。你可以看下 notebook-to-model-service S2I 的运行 视频。同样,这不是数据科学家必须开发的工具,但是,创建这样的工具是 Kubernetes 专家和打包专家与数据科学家合作的绝佳机会。