Spotify开源了自研的Terraform模块，用于在Google Kubernetes Engine（GKE）上运行机器学习流水线软件Kubeflow。通过将企业内部机器学习平台转换至 Kubeflow，Spotify 工程师缩短了上市时间，将运行的实验规模扩大为原平台的 7 倍。
在 Spotify 的最新博客帖子中，产品经理 Josh Baer 和机器学习工程师 Samuel Ngahane介绍了Spotify在为机器学习“铺平道路”（Paved Road）上的做法。“基于我们推荐的基础架构，使用经慎重考虑过的产品和配置，部署端到端的机器学习解决方案”。通过执行此标准，Spotify 的机器学习工程师得以专注于开展机器学习实验，无需费心基础架构的构建和维护。该平台自 2019 年中旬启动以来，得到约 100 个内部用户的采用，并已运行了 18000 多项实验。
Spotify 长期使用机器学习技术，为用户自动生成定制的播放列表。例如，“每周发现”（Discover Weekly）频道可为用户推荐新的音乐。企业最初的策略是允许各团队自己选择工具和框架。不少现有的基础架构采用了Scala语言，并使用了包括Scio在内的多个由 Spotify 开源的自定义库。Scio 是一种Apache Beam数据处理库，但其在扩展性上存在问题，使得团队需要支持多种框架，导致从概念原型到生产系统之间的迭代时间延长。此外，许多工程师“完全不考虑在基于 Python 的工作流中添加 Scala”。上述问题促使 Spotify 重新考虑自身的框架选取问题，并由此提出了“铺平道路”（Paved Road）这一理念。
“铺平道路”意在解决端到端机器学习工作流中存在的问题。工作流定义了机器学习模型开发和部署的各个阶段，其中包括：
数据预处理
特征转换
模型训练
模型评估
模型上线
具体而言，Spotify 聚焦于各阶段间的数据接口问题，选择采用谷歌TensorFlow Extended （TFX）机器学习平台定义的TFRecord格式和tf.Example类 。团队通过对现有工具构建 TFX 连接器，实现向通用框架的迁移。团队正致力于使用Tensorflow Data Validation（TFDV）等 TFX 组件，支持开发人员检测偏斜分布和错误值等数据问题。但其中依然存在一些挑战。例如，现有工具尚未解决端到端的编排框架问题。
最终，团队决定迁移到开源机器学习工作流平台 Kubeflow Pipelines（KFP）。该平台上的工作流的组件，将打包为受 Kubernetes 管理的 Docker 容器。KFP 为 TFX 提供开箱即用的支持，因此团队无需再去学习新的框架。KFP SDK 的另一个优点是预先打包了许多常用任务，支持代码共享和重用。Spotify 实现了共享 Kubeflow 集群的部署和管理，使得开发人员得以专注于机器学习实验本身，不必操心基础架构管理的细节。群集托管在 Google Kubernetes Engine（GKE）上，使用Terraform配置。
KFP 是一类机器学习全生命周期管理工具。此类工具多由一些大型企业开源提供。例如，Databricks 的MLFlow，以及 Uber 的Michaelangelo。最近，AWS 也新发布了几项Sagemaker服务，力图为机器学习生命周期的各阶段提供统一的接口。在 KubeCon 2019 大会上，Spotify 的机器学习工程师 Ryan Clough 和 Dai Keshi 介绍了 Spotify 的平台。此后，Clough 发了如下推文：
如果要说参与 KubeCon 大会的最大收益，那就是我们同样面对着类似的问题，这些问题会由于各自企业的不同环境而表现各异。尽管我们一直在努力去提供最好的产品，但是没人能独自解决所有的问题。是的，没有人。
Spotify 在 GitHub 上维护了多个开源项目，其中包括TensorFlow helpers等机器学习的相关类库。
原文链接：
Spotify Open-Sources Terraform Module for Kubeflow ML Pipelines
腾讯大规模云原生技术实践案例集
本案例集详细阐释了 QQ、腾讯会议、和平精英、小红书、斗鱼、微盟等十多个亿级用户产品背后的大规模云原生...
评论