基于Kubeflow的机器学习调度平台落地实战

最新推荐文章于 2024-06-27 09:04:29 发布

糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖糖

最新推荐文章于 2024-06-27 09:04:29 发布

阅读量1.6k

点赞数 1

本文链接：https://blog.csdn.net/cpongo4/article/details/89148800

版权

机器学习，特别是深度学习，在蘑菇街这样的电商平台有大量实际业务的落地场景，比如搜索推荐、图像算法、交易风控反作弊等等。随着业务的快速发展，之前已有的基于 Yarn 的调度平台已经无法满足大规模机器学习的计算需求，因此我们在 2018 年和算法工程团队一起建设了基于 Kubeflow 和 Kubernetes 的分布式机器学习平台，并深入到业务层面进行分布式改造，并且从Kubernetes、Tensorflow和业务等多个层面进行了一系列的性能调优。

背景

随着机器学习和人工智能的迅猛发展，业界出现了许多开源的机器学习平台。由于机器学习与大数据天然的紧密结合，基于 Hadoop Yarn 的分布式任务调度仍是业界主流，但是随着容器化的发展，Docker + Kubernetes 的云原生组合，也展现出了很强的生命力。

公司	平台名称	集群管理和调度
百度	PaddlePaddle	Docker+Kubernetes
腾讯	Angel	Docker+Yarn
阿里	X-DeepLearning	Docker+Yarn
360	XLearning	Yarn
京东	登月平台	Docker+Kubernetes
才云科技	Clever	Docker+Kubernetes

表1. 互联网业界机器学习平台架构对比

痛点

在建设分布式训练平台的过程中，我们和机器学习的各个业务方，包括搜索推荐、图像算法、交易风控反作弊等，进行了深入沟通，调研他们的痛点。从中我们发现，算法业务方往往专注于模型和调参，而工程领域是他们相对薄弱的一个环节。建设一个强大的分布式平台，整合各个资源池，提供统一的机器学习框架，将能大大加快训练速度，提升效率，带来更多的可能性，此外还有助于提升资源利用率。

痛点一：对算力的需求越来越强烈

算力代表了生产力。深度学习在多个领域的出色表现，给业务带来了更多的可能性，同时对算力提出了越来越高的要求。深度学习模型参数的规模陡增，迭代的时间变的更长，从之前的小时级别，变成天级别，甚至月级别。以商品推荐为例，面对几亿的参数，近百亿的样本数量，即使采用 GPU 机器，也需要长达一个星期的训练时间；而图像业务拥有更多的参数和更复杂的模型，面对 TB 级的训练样本，单机场景下往往需要长达近一个月的训练时间。

再者，机器学习具有试错性非常强的特点，更快的训练速度可以带来更多的尝试，从而发掘更多的可能性。Tensorflow 从 0.8 版本开始支持分布式训练，至今为止，无论高阶还是低阶的 API，对分布式训练已经有了完善的支持。同时，Kubernetes 和 Hadoop 等具有完善的资源管理和调度功能，为 Tensorflow 分布式训练奠定资源层面的基础。

Tensorflow On Yarn 和 Tensorflow On Spark 是较早的解决方案，奇虎360的 Xlearning 也得到众人的青睐。而基于 Kubernetes 的 kubeflow 解决了 Yarn 的痛点，展现出旺盛的生命力。

上述方案无一例外的将各个部门分散的机器纳入到统一的资源池，并提供资源管理和调度功能，让基于 Excel 表的资源管理和人肉调度成为过去，让用户更专注于算法模型，而非基础设施。在几十个 worker 下，无论是 CPU 还是 GPU 的分布式训练，训练速度都能得到近乎线性的提升，将单机的训练时间从月级别缩短到一天以内，提升效率的同时也大大提升了资源利用率。

蘑菇街早期的业务方往往独立维护各自团队的GPU机器“小池子”，机器的资源分配和管理存在盲区，缺乏统一管理和调度。GPU的资源存在不均衡和资源利用率低下的问题。事实上，大数据团队之前已经将 CPU 类型的训练任务接入了 Xlearning，尝到了分布式训练的甜头，但也发现一些问题：

公司目前的 Yarn 不支持 GPU 资源管理，虽然近期版本已支持该特性，但存在稳定性风险。
缺乏资源隔离和限制，同节点的任务容易出现资源冲突。
监控信息不完善。在发生资源抢占时，往往无法定位根本原因。
缺少弹性能力，目前资源池是静态的，如果能借助公有云的弹性能力，在业务高峰期提供更大的算力，将能更快的满足业务需求。

痛点二：人肉管理的成本很高

业务方反馈的第二大问题是人肉管理的成本问题。人肉化的管理主要包含了部署和训练任务管理两大方面。

人肉部署

一个典型的场景是：团队内的成员共享一批机器，每次跑训练任务前，用户手动登陆机器，下载代码，安装对应的 python 包，过程繁琐且容易出现安装包版本的冲突。

由于不同的训练任务对 python 的版本和依赖完全不同，比如有些模型使用 python 2.7，有些使用 python 3.3，有些使用 tensorflow 1.8，有些使用 tensorflow 1.11 等等，非常容易出现依赖包冲突的问题。虽然沙箱能在一定程度上解决这问题，但是也带来了额外的管理负担。

此外，不同GPU机型依赖的 Nvidia 驱动也不同，较新的卡，比如 V100 所依赖的版本更高。人肉部署还需要管理和维护多个不同的驱动版本。