What is Sagemaker

前言

市场上曾经有很多公司想要创建一套为 ML 服务的云基础设施. 而为 ML 的基础设施应该做成什么样的产品, 以什么样的方式让用户使用, 如何解决 ML 中的痛点, 业内并没有一套标准答案, 因为这个话题实在是太新了. AWS Sagemaker 算是市场上第一个比较成熟, 并且用户上手比较容易, 通用性较强的产品了.

Sagemaker 这款产品和其他的 AWS 产品不太一样, 很难用一句话让任何人理解 Sagemaker 到底是一个什么产品, 能解决什么问题. 因为机器学习是一个比较大的话题, 如果没有真正全程经历一个机器学习模型的 研发, 测试, 调优, 部署, 监控, 反馈 这一整套流程, 是很难理解这些流程中有哪些痛点的. 所以为了能理解 Sagemaker 的原理和价值, 我们先来回顾一下机器学习开发的整个流程, 看看在没有 Sagemaker 的过程中是数据科学家会和工程师的日常是怎样的.

传统的机器学习开发流程

1. 收集数据

当我们定义了一个想要用机器学习来解决的商业问题的时候, 我们需要定义数据的输入以及模型的输出. 这里的输出也是我们关心的目标, 在机器学习中通常叫 Label (标签). 例如:

  • 自动判断新闻稿件的主题, 给它打标签. 那么输入则是一长串文本, 输出则是一些词语.

  • 判断银行流水交易里是否存在欺诈. 那么输入则是一次交易的明细, 以及与该次交易相关的上下文数据, 而输出则是一个 0, 1 的布尔值等.

  • 判断一个图片的主题是什么. 输入则是 RGB 编码后的图片数据, 输出则是一个数字, 每个数字代表着一个具体的主题.

一旦我们定义了问题, 我们就要开始搜集数据了. 但我们能搜集到的数据通常都是只有数据, 没有 label 的. 我们往往要花费大量的人力物力去给数据集加上标签. 这个过程在机器学习中叫 Annotation (标注). 这也是说互联网公司最大的商业资产是它们的数据.

痛点

  • 获得高质量带标签的数据很耗时, 成本非常高.

2. 选择模型

机器学习的模型很多, 针对不同的问题, 例如分类, 回归, 预测, 聚类, 检测, 针对不同的数据类型, 数值, 文本, 图像, 音频, 都有不同的机器学习算法. 就算在同一类问题的语境下, 也有很多种算法可以选择. 机器学习很大程度上是一个工程, 不是理论, 真正算法好不好用只有用你的数据跑了之后才知道适不适合你. 所以数据科学家往往要进行很多尝试, 这些尝试可以被粗略的分为以下几个维度:

  1. 对数据进行不同的特征工程

  2. 使用不同的机器学习模型

  3. 尝试模型中的参数的排列组合

以上 3 个维度我们往往都要尝试几个选项, 排列组合下来工作量会成指数增长. 而对于每一个尝试, 我们都基本上会经历: 特征工程 (数据预处理), 模型训练, 调参, 评估 这几个步骤. 而我们又需要做很多尝试才能决定用什么模型, 这个工作量显然是巨大的.

痛点

  • 我们希望能用一个框架或者某种自动化机制能快速的进行大量尝试.

3. 模型训练

模型训练的本质就是把数据喂给算法, 然后得出一个有具体详细参数的模型. 这个参数可能是几百万个多项式系数, 也可能是一个巨型矩阵. 具有商业价值的模型的训练的过程往往不是个人电脑能承受的, 往往需要大量的计算和内存, 甚至需要计算机集群. 我们显然不希望说我们的数据科学家在自己的开发电脑上训练模型, 然后就占用了 CPU 内存然后只能干等. 毕竟人才是最贵的成本. 所以工程实践中往往是用服务器来进行训练的.

传统的方式是公司维护一个计算机集群, 工程师 SSH 到机器上, 上传代码和数据, 开始跑训练程序. 跑完一个把跑好的模型保存为二进制数据. 这里面就有很多痛点了.

痛点

  • 维护集群并不容易, 并且一般搞机器学习开发的都不懂维护集群

  • SSH 到机器上配置运行环境很繁琐, 在本地写好代码后往往还需要几个小时才能做好在服务器上跑程序的准备

  • 跑程序很耗时, 你只能频繁的去看才知道什么时候训练完成然后能进行下一步

4. 部署

当你训练出一个满意的模型后, 你希望把模型部署成一个服务, 以供外部的系统进行调用. 一旦涉及到部署, 往往就进入到一个 模型开发者不懂得运维, 而运维的开发者不懂机器学习 的尴尬窘境.

通常对于训练好的模型我们会用容器进行部署. 这里要注意的是, 你的训练模型所用的计算机平台和部署所用的计算机平台需要一致. 比如 X86, Arm, Windows, Linux. 因为机器学习的库和环境底层通常都是 C 写的, 而 C 的程序需要再特定的平台上编译后才能使用, 你构建你的模型用的一个平台, 显然是不能用另一个平台部署的.

这里我们以业内的通用做法 “用容器部署” 来举例

  • 用你的基础容器安装环境依赖

  • 拷贝你的模型

  • 把你的模型的输入输出包装成简单易用的接口

  • 把你的容器部署到服务器, 并对外暴漏 API

  • 你可能要部署多台容器, 并且启用自动伸缩机制, 以应对流量的波动

痛点

  • 在数据科学家看来用训练好的模型作预测仅仅是 my_model.predict([1, 3, 5, 7]) 一行代码, 但我们要将其部署成服务你看看上面有多少步骤, 工作之繁琐令人却步

AWS SageMaker 是如何传统开发流程的痛点的

AWS Sagemaker 它有三大杀手工具:

  1. 对机器学习中常用的步骤进行抽象和封装:

    • Estimator: 一个用于训练模型的对象. 其背后是一个算法. 例如很多人在接触第一个机器学习库 sklearn 的时候都会用到的 API. 一般 estimator = Estimator(...) 就能创建一个简单的模型. estimator.fit(X, y) 就能训练出一个模型. pickle.dump(estimator) 就能保存训练好的模型以供以后使用. estimator.predict(row) 就能用模型做出预测. estimator 通常用于在本地 (就是你的 notebook 或脚本运行环境, 而不是远程服务器) 使用和测试.

    • Endpoint: 对模型的部署进行封装. 通过调用已经训练好的 estimator, 然后运行 estimator.deploy(...) 就可以将模型部署成一个 Web 服务器, 而 Sagemaker 则是帮你处理好了 Docker Image 这些复杂的工作.

    • Batch Transform: 临时将你的模型部署到 EC2 上, 然后接收输入, 返回输出, 删除 EC2. 同样也是一行 API 就能自动化上面这些步骤, 用于批量对数据做 prediction

  2. 对机器学习中的各个步骤进行编排, 也叫做 Sagemaker Pipeline, 你可以将其理解为一个专门为 ML 设计的 Step Function.

  3. 对 Jupyter Lab 进行二次开发, 和 Sagemaker AWS Console 高度整合, 使得你在浏览器里就能开发, 监控 ML 资源.

参考资料