滴滴机器学习平台架构演进之路

现在很多互联网公司都有自己的机器学习平台，冠以之名虽然形形色色，但就平台所要解决的问题和技术选型基本还是大同小异。

所谓大同是指大家所要处理的问题都相似，技术价格和选型也差不太多，比如都会使用 GPU 集群、采用 Spark/K8S 平台等。所谓小异是指各家规模不同，各家都在结合自己的情况、所处的阶段并根据自己的特点解决平台化的问题。

以下就滴滴的机器学习平台做一些介绍，侧重于介绍机器学习平台不同阶段所要解决的问题，以及解决问题的思路和技术方案。

滴滴机器学习平台的治理思路主要是：减少重复，提高效率。

机器学习平台 1.0：从“作坊”向“集中化”过渡

滴滴的机器学习平台建设开始于 2016 年，当时滴滴内部各算法团队逐步开展机器学习、深度学习等 AI 相关的研究和实践应用，这类算法大都属于计算密集型应用，一般都会使用单价较昂贵的 GPU 服务器。但随着业务的开展，各算法团队仅针对各自的问题做规划，导致了一种小作坊式的生产局面。

作坊式生产方式在早期有其积极的一面，能够保证创新的灵活性，但是越往后，这种小作坊式算法生产模式的局限就越明显：资源缺乏统筹调度，无法形成规模化效应，大量重复性工作，自拥算力有限。逐渐增多的这种小作坊式生产方式致使整体投入产出的效益大打折扣。

滴滴机器学习平台在这种背景下应运而生，这个阶段也主要致力于解决这些问题。

这期间机器学习平台所采用的架构和技术选型主要针对作坊式生产方式的问题来展开，也就是提高复用性和规模化能力。

首先要解决的问题就是统一资源管理，这个“统一”要解决包括线下和线上两类问题。

线下“统一”的问题着重解决 GPU 的服务器选型、测试、引入、上线等的集中化。这类集中化一方面提高了服务器引入的上线质量；另一方面相比于作坊式模式，由于有 GPU 相关专业人员参与进来，GPU 的选型避免了一味追新的盲目性和发散性。再者，集中化能够和公司整体大局结合起来，从而可以做最优化的选型和引入方案。

线上“统一”需要解决的问题细分为资源管理问题和任务调度问题，使资源使用方能够用即申请，完即释放，从而盘活整个资源大池，对平台要求则需要做到资源的隔离和管理。

这个阶段需要解决资源统一管理后如何避免重复性工作的问题。此时所谓的避免重复性，意在让各个算法业务不需重复诸如 Caffe、TensorFlow、PyTorch 等运行环境的构建，而是要一次构建所有用户都可用。这对平台来讲，需要做到应用环境管理、用户自定义环境、快速环境部署。

厘清这些需求之后，结合当时的技术环境和成熟度来看及以上的基本要求，平台选择当下盛行的 Docker 来兼做环境的管理、资源的弱隔离和任务的调度。但由于此时支持 GPU 资源调度的资源管理器乏善可陈，所以我们选择对 Yarn 做了扩展以支持 GPU 资源维度上的资源管理和任务调度，环境上平台同时提供 Notebook、Jupyter 的交互接口给用户。

统一资源管理、环境管理后，不得不面对的问题是多个资源节点间数据共享的问题，用户在当前资源释放后申请新资源时往往对之前的数据有依赖。

多节点数据共享在作坊式时期受限于单个的规模，问题不会十分突出，但是集中化之后随用户增多就会逐渐尖锐起来乃至是个大的技术挑战。因为：

1. 机器学习的任务计算特点依赖于 GPU 的高速计算，它们对数据访问延迟有一定要求，这要求必须有足够高的 IO 带宽做支持；
2. 用户数量增加，对存储带宽的需求会变的非常大；
3. 对存储系统来说，支持 POSIX 接口的要求使得现有技术方案大大减小，另外也需在高可靠性、高性能以及成本之间做折中。

滴滴机器学习平台在存储系统上的尝试还是借用传统超算使用的 PFS 作为整个数据存储的一级，底层网络基础设施使用高带宽的以太网络，使用 RoCE 协议做 RDMA 的支持，并往这个方向演进。

机器学习平台架构-Yarn

总的来看，这个阶段所面对的问题以内部问题为主，从作坊式到集中化生产的发展阶段，要解决的相关重复性的问题也比较简单。其中有些问题本质属于集中化后产生的问题，但是解决思路还是作坊式的，技术选型上的局限性也没有完全暴露出来。

机器学习平台 2.0：平台发展