全栈算力,加速行业AI落地 了解详情
写点什么

机器学习平台建设指南

  • 2021-05-11
  • 本文字数:9787 字

    阅读完需:约 32 分钟

机器学习平台建设指南

伴随着数据化、智能化的浪潮,很多大企业为了沉淀通用技术和业务能力;加快企业智能化、规模化智能开发,开始了自建机器学习平台。从零搭建一个机器学习平台的复杂度是不容小觑的,关于平台的定位、需要解决的问题;及其架构、技术选型等需要提前考量和设计。本文根据几个从零到一的机器学习平台构建经历,再结合目前新兴热门的云上机器学习平台,试图对机器学习平台做一个概念和技术拆解。

平台的业务

从平台这个概念本身来说,它提供的是支撑作用,通过整合、管理不同的基础设施、技术框架,一些通用的流程规范来形成一个通用的、易用的 GUI 来给用户使用。通用性是它的考量之一、也是所有平台的愿景之一:希望平台能适用于各个不同的业务线来产生价值。所以从业务上来说,作为一个平台本身是不会、也不应该有太多 specific 的业务功能的。当然这只是理想情况,有时候为了平台使用方的需求,也不得不加上一些业务领域特定的功能或者补丁来适应业务方,特别是平台建设初期,在没有太多业务的使用的时候。整体来看,平台自身的业务可谓是非常简单,可以用一张图来表示:

上面这个分支是标准的机器学习流程的抽象。从数据准备,数据处理,模型训练,再到模型上线实现价值完成整个流程。


下面这个分支,也是机器学习和数据科学领域中不可或缺的,主要指的是类似于 Jupyter Notebook 这类,提供高度灵活性和可视化的数据探索服务,用户可以在里面进行数据探索、尝试一些实验来验证想法。当然当平台拥有了 SDK/CLI 之后,也可以在里面无缝集成上面这条线里面的功能,将灵活性与功能性融合在一起。

基础设施

上面提到平台本身是整合了不同的基础设施、技术框架和流程规范。在正式开始之前,有必要介绍下本文后续所使用的的基础设施和框架。


在容器化、云化的潮流中,Kubernetes 基本上是必选的基础设施,它提供灵活易用的基础设施和应用管理能力,同时扩展性非常好。它可以用于


  1. 部署平台本身

  2. 调度一些批处理任务(这里主要指离线任务,如数据处理、模型训练。适用的技术为:Spark on kubernetes/Kubernetes Job),

  3. 部署常驻服务(一般指的是 RESTful/gRPC 等为基础的服务,如启动的 Notebook、模型发布后的模型推理服务。适用的技术为 Kubernetes Deployment/Kubernetes Statefulset/Service 等)。


机器学习的主要场景下,数据量都是非常大的,所以 Hadoop 这一套也是必不可少的,其中包含基础的 Hadoop(HDFS/HIVE/HBase/Yarn)以及上层计算框架 Spark 等。大数据技术体系主要用于数据存储和分布式数据处理、训练的业务。


最后就是一些机器学习框架,Spark 系的(Spark MLlib/Angel),Python 系的(Tensorflow/Pytorch)。主要用途就是模型训练和模型发布(Serving)的业务。

原始数据

原始数据,也叫做数据源,也就是机器学习的燃料。平台本身并不关心原始数据是如何被收集的,只关心数据存储的方式和位置。存储的方式决定了平台是否能支持此种数据的操作。存储的位置决定了平台是否有权限、有能力去读取到此数据。按主流的情况来看,原始数据的存储一般支持四类形式:


  1. 传统的数据库,例如 RDS/NoSQL。这类数据源见得比较少,因为一般在大数据场景下,通用的解决方案是将此类数据源通过一些工具导入到大数据体系中(如 Sqoop)。对于此类数据源的支持也是很简单的,使用通用的 Driver 或者 Connector 即可。

  2. 以 HDFS 为媒介的通用大数据存储。此类数据源使用较为广泛,最常见的是 HDFS 文件(parquet/csv/txt)和基于 HDFS 的 HIVE 数据源。另外,由于是大数据场景下的经典数据源,所以上层的框架支持较为完善。

  3. NFS。NFS 由于其快速的读写能力,以及悠久的历史。很多企业内部都有此基础设施,因而已有的数据也极有可能存储在上面。

  4. OSS(对象存储)。最过于流行的要属 S3 了。对象存储是作为数据湖的经典方案,使用简单,存储理论上无限,和 HDFS 一样具备数据高可用,不允许按片段更改数据,只能修改整个对象是其缺点。


值得注意的是,NFS 和 OSS 一般用于存储非结构化数据,例如图片和视屏。或者用于持久化输出目的,如容器存储,业务日志存储。而 HDFS 和数据库里面存放的都是结构化、半结构化的数据,一般都是已经经过 ETL 处理过的数据。存储的数据不一样决定了后续的处理流程的区别:


  1. NFS/OSS 系数据源,基本上都是通过 TensorFlow/Pytorch 来处理,数据一般通过 Mount 或者 API 来操作使用。当然也有特例,如果是使用云服务,例如 AWS 的大数据体系的话,绝大多数场景下,是使用 S3 来代替 HDFS 使用的,这也得益于 AWS 本身对于 S3 的专属 EMRFS 的定制化。当然 Spark 本身等大数据处理框架也是支持此类云存储的。

  2. HDFS 系和传统数据库系数据源,这个大数据框架、Python 系框架都是可以的。

平台一般会内嵌对以上数据源的支持能力。对于不支持的其他存储,比如本地文件,一般的解决方案是数据迁移到支持的环境。

数据导入

这应该是整个平台里较为简单的功能,有点类似于元数据管理的功能,不过功能要更简单。要做的是在平台创建一个对应的数据 Mapping。为保证数据源的可访问,以及用户的操作感知。平台要做的事情可以分为三步:


  1. 访问对应的数据源,以测试数据是否存在、是否有权限访问。

  2. 拉取小部分数据作为采样存放在平台中(如 MySQL),以便于快速展示,同时这也是数据本身的直观展现(Sample)。对于图片、视频类的,只需要存储元信息(如资源的 url、大小、名称),展示的时候通过 Nginx 之类的代理访问展示即可。

  3. 如果是有 Schema 的数据源,例如 Hive 表,数据源的 Schema 也需要获取到。为后续数据处理作为输入信息。


技术上来说,平台中会存在与各种存储设施交互的代码,大量的外部依赖。此时,外部依赖可能会影响到平台本身的性能和可用性,比如 Hive 的不可用、访问缓慢等,这个是需要注意的。


业务上来说,更多考量的是提高系统的易用性,举个例子,创建 Hive 表数据源,是不是可以支持自动识别分区,选择分区又或者是动态分区(支持变量)等。

数据处理

这里的数据处理是一个大的概念,从我的认知上来看。大体可以分成两个部分, 数据标注以及特征处理。

数据标注

数据标注针对是的监督学习任务,目前机器学习的应用场景大多都是应用监督学习任务习得的。巧妇难为无米之炊,没有足够的标注数据,算法的发挥也不会好到哪儿去。对于标注这块。业务功能上来说,基本上可以当成是另一套系统了,我们可以把它叫做标注平台。但从逻辑关系上来说,标注数据是为了机器学习服务的。本质上也是对数据的处理,所以划到机器学习平台里面也没有什么问题。


标注平台对应了之前提到平台的另一功能:提供通用的流程规范。这里,流程指的是整个标注流程,规范指的是标注数据存储的规范,比如在图像领域,目前没有通用而且规范的存储格式,比较需要平台来提供一种通用的存储格式。


数据标注有两种,一种是人工标注; 另一种是使用已训练好的机器学习模型来标注,然后再辅以人工确定和修订。无论是使用哪种方式,最后都需要人工介入。因为数据标注的正确性是非常重要的,大家应该都听过一句话:数据和特征决定了机器学习的上限,而模型和算法只是逼近这个上限而已。如果给你的数据都是有问题的,那模型如何能学习到正确的能力呢。


在标注平台中,往往都是人工+模型混合使用的,整体流程如下:

  1. 在最开始可能没有模型来辅助进行标注(这里的预标注),这个时候就需要人为手工介入,以此来训练出一个模型

  2. 当我们根据标注出的数据(训练数据集)训练出不错的模型之后,就可以使用此模型来对新输入的数据做一个预标注的工作,然后再辅以人工确认和修订

  3. 如此反复迭代,随着输入数据的增多,当我们训练出的模型准确率达到一个很高的水准之后,需要人工操作的数据就会越来越少。以此减少人工成本费


标注平台中需要考量的问题有几点:

  1. 一般来说,需要标注的数据量都是非常巨大的。不存在说两三个人随便标几下就完事。所以更为通用的做法是做一个众包平台,外包给其他公司或者自由职业者(标注员)来做。参考 AWS 的 Amazon Mechanical Turk。这就涉及到了权限控制、角色控制。

  2. 标注数据的准确性问题。不能避免有些标注员划水摸鱼,随意标注。此时是需要己方人员去做一个审计工作的,这里就是一个工作流,和上图所示差不多。是一个相对来说较为规范的流程,可以随着业务来增加额外的流程。

  3. 标注工具的开发。如果有合适开源工具,可以集成开源工具,如 VGG-VIA/Vatic, poplar。开源工具一般不会满足所有的需求,在开源上做二次开发往往成本更高。这里更倾向于自己开发,这样更能满足需要,自定义程度高,灵活性强

  4. 标注数据的存储。最好是一个相对通用的格式,以便于往各种其他格式做一个转换。在使用时做一个数据格式转换。这里更偏好 Json 格式类似的存储,可读性和代码可操作性都非常高


技术上的考量,这里并不是太多。唯一需要注意的可能是数据的处理,如图片、视频标注,资源的拆剪、缩放,各种标注数据的保存,坐标计算等。相对而言,后端主要是工作流处理,前端的各种标注工具是技术核心点。

特征处理

在正式开始模型构建与训练之前,对数据做特征处理基本上是必不可少的环节。特征处理的输入是之前创建的数据集、或者是标注完成后产生的数据集。它的输出是经过一系列数据操作后、可以直接输入到模型中的数据,这里称它为训练数据。


这里又可以分为两类,一类是不需要太多操作的特征处理,常见于非结构化数据,如图片、视屏。另一类是针对结构化/半结构化数据的特征处理流程,这类数据往往不是拿来即可用的,需要一定的特征处理。

首先来看第一类,第一类的典型应用场景就是 CNN 图像领域。对于输入的图片,一般不需要太多的操作。此类数据源往往也是存储在 NFS/OSS 上的。对于此类数据的处理,一般也不会使用到大数据框架,一般都是自己手撸 Python(C++)来处理;或者是放在模型训练一起处理,不单独拎开。Spark2.3 开始是支持图片格式的,不过目前没有看到太多的使用案例。整体流程如下:

本质上是一个批处理过程,Kubernetes 的 Job 天然适用于此类问题。当然其他调度框架来做这个任务调度也是可以的。


然后是第二类,这种基本上就是传统的特征工程了,以 Hive/HDFS 输入为经典例子。由于对数据的操作是非常多样的,所以一般倾向于构建一个数据处理的流水线,也就是 Pipeline:

把对数据的操作拆分成一个一个的操作运算(也就是一个 Pipeline Node 节点),可以把它叫做算子,然后利用 Pipeline 把操作进行自由组合,从而达到对数据进行各种变换处理的过程。使用过 Sklearn pipeline 或者 Spark MLlib pipeline 的小伙伴应该对此并不陌生,事实上,这就是基于此的可视化建模。使得用户可以在界面上进行拖拉拽,选择和输入一些参数来完成对于数据的操作,提供更灵活的功能。


那么这条 Pipeline 里面都有哪些操作呢,整个算子大致可以分为这几类别:

技术上,使用 Spark MLlib 是个不错的选择,可以适应不同数据量的规模。且天然支持这种 Pipeline 的形式,只需要对此做一定的封装。同时,考虑到业务功能,还需要手动定制、修改一些算子;对于扩展这点,它的支持也是非常不错的,自定义算子、算法都比较简单。当然也可以基于其他框架(如 Azkaban)或者自己造轮子。需要注意的是,在大数据场景下,Spark MLlib 里面部分自带的算子会有性能问题(有些直接 OOM),需要分析源码定位然后修复。包括我们自己实现的算子,也都要考量大数据场景下这个问题,这对于测试而言是个 Case。


整个 Pipeline 的核心是构造一个 DAG,解析后,提交给对应的框架来做处理。抛开技术来说,功能上来说,易用性和快速反馈是 Pipeline 需要注意的。比如:


  1. 所有的算子都应该能自动获取到可用的输入、对应类型,自动生成输出

  2. 支持参数校验,Pipeline 完整性校验

  3. 支持调试/快速模式,利用部分 Sample data 快速验证效果,相当于一个试验功能

  4. 日志查看,每个算子状态查看,以及操作完成后的 Sample data 查看

  5. 支持一些变量、SQL 书写,以扩展更灵活的功能,比如参数动态化

  6. 支持定时调度,任务状态邮件、短袖及时告警、同步等

模型训练

到了模型训练这块。从功能上来看需要的不是很多,更多是体验上的设计。比如参数在界面上的展示和使用,日志、训练出的 Metrics 的可视化、交互方式,模型的一些可视化等。核心功能包含这几块儿:

1.预置算法/模型

这里考量的点是:

  1. 支持界面手动调参

  2. 训练中日志、Metrics 的可视化。支持同时使用不同的参数多次训练,直观对比结果方便调参

  3. 需要支持常用的框架,如 Spark MLlib/Tensorflow/Pytorch,或者一些特定的框架(业务方需要的)


预置算法/模型很简单,在不同的框架上封装一层并且暴露对应的参数给到用户即可。有些算法可能框架不支持,这种根据情况决定如何解决(自己实现或者其他解决方案)。有一点就是,框架不宜太多,否则在后续模型发布的 Serving 上,也需要多套解决方案。对于训练本身来说,分为两种:单体/单机训练和分布式训练,分布式训练是训练这块的大头(也是技术难点所在)。


对于单体/单机训练的解决方案,和上诉特征处理中的解决方案一致。优先使用 Kubernetes 的 Job,或者使用 Spark,控制下 Executor 即可。


对于分布式训练,目前接触到的,基本上都是数据并行:

以 Spark 为基础的基本都使用的是 PS 模式。PS 模式一般使用的都是异步更新参数,每个 Worker 只需要和 PS 通信,所以容错管理上会更加简单。AllReduce 模式则是同步的参数模式,而且每个 Worker 都需要上下游通信,相对而言,容错处理会更苛刻一些。


Spark 系的分布式训练,经典的算法可以由 Spark MLlib 提供。但是其对于 DNN 的支持并不好,而且 Spark 的训练是一个同步的过程,如果数据倾斜的话,整个训练的速度取决于最慢的 RDD。如果要在 Spark 上跑深度学习的模型,一般会选用其他框架或者基于 Spark 的框架,如腾讯的 Angel、 Intel 的 BigDL。两者的思想都是一致的,同属于 PS 模式下的分布式训练,整个流程可以概括为这几步:


  1. 利用 Spark 来作为任务调度、资源分配、数据读取和容错处理的容器

  2. 从 PS 拉取参数,然后将数据和参数通过 JNI 喂到底层的框架代码中去(如 Pytorch C++ Frontend)完成训练,返回梯度

  3. 使用优化算法和梯度,更新参数,再将新的参数更新到 PS。如此反复


借用一张 Angel 的图:


顺着这个思路,可以以 Spark 为基础,兼容任何深度学习框架。只要底层框架:

  1. 支持模型/代码序列化,以支持分发模型到所有 Worker 中进行本地训练

  2. 通过 JNI 能调用模型提供的接口,如 Forward/Backward


这要比自己造轮子更加便利和友好,毕竟 Spark 已经是一个成熟的分布式计算框架了。


如果使用的是 Python 系的深度学习框架有两点需要注意:

  1. 如何读取分布式存储上的数据以支持数据并行。也就是 Spark 里面 Partition 的概念。当然最简单的方法,就是将数据拆分成块,不同的节点读取不同的数据来训练。

  2. 另外一点在于容错性,基于 Spark 的分布式训练的优势就在于数据的分配、容错处理。现在就得自己去保障这两点了。


训练部署上面。Spark 系的,使用 Spark 支持的即可(Yarn/Kubernetes/Standalone)。Python 系的更倾向于云原生、或者基于 Kubernetes 的解决方案(自定义 Operator 是个比较好的选择),这里有个为云原生和容器化而生的框架:Polyaxon,值得一试。

2. 自定义算法

关于自定义算法,个人更倾向于将这个功能放在 Notebook 中而不是界面化的操作上,因为这个功能的自由度很高,允许用户自己写代码。平台其实只需要提供:


  1. 数据读取能力,这里包括源数据、平台内生成的数据

  2. NFS/OSS 使用 Mount 形式或者 API 提供(如 Databricks 的 DBFS)

  3. HDFS 系列的 API 提供支持(如提供 pyspark)

  4. 调度能力,能根据需求调度起任务。


以上两者功能,都或多或少依赖于 SDK/API/CLI。可以参考大厂的实现 Amazon SageMaker、Databricks Notebooks。


另外一点是 GPU 的支持,这点,如果是选择 Kubernetes 作为基础设施,是有基本的功能支持的,利用 Extended Resource(ER)配合 Device plugin 体系:

对于 Hadoop 体系的话,3.1.X 之后也是支持的。


这两者对于 GPU 的支持都非常有限,都是处于一个能用,但是不好用的状态。使用的时候,淌坑可能在所难免。

3. AutoML

关于 AutoML 这块。目前还没有太多的接触。从我看来,做个简单的随机搜索还是问题不大的,集成算法来自动调参、自动构建模型也是不难的。就跟上诉集成算法进来是一样的。唯一考量的是,集成那些算法进来以及计算资源的考量,尤其是深度学习大行其道的今天,类似于随机搜索这样耗费的资源是巨大的。如何设计这个功能,以及具体实现还是需要非常专业的领域知识。


总的来说,模型训练这块。是一个很偏技术的功能。完成一个 Demo 的端到端,实现基本的功能很简单。但是要做到好用、稳定性这两点就并不那么容易。尤其是分布式机器学习这一块儿,还是需要不断淌坑的。

模型发布

终于来到最后一步,是整个平台产生价值的最后一环。模型发布,通常包含两种发布:


  1. 发布成 API(RESTful/gRPC),以供业务侧实时调用。这类服务通常对于性能要求苛刻

  2. 发布成批处理形式,用于批处理数据,上述标注平台中的预标注属于此类任务


对于批处理形式的发布,较为简单。一般框架本身都支持模型的序列化和加载做预测:


  1. Spark 系的就依旧走原始路线,提交 Spark Job,做批处理预测

  2. TensorFlow 类似的,配合不同的镜像环境,Mount 模型,读取数据,配合 Kubernetes Job 的方式来启动批处理达到一个统一的处理流程


对于实时推理服务,于平台而言,能使用通用的框架/技术来做那当然是极好的。然鹅,现实很残酷。通用的解决方案,要么性能不够(如 MLeap),要么支持的算子/操作/输入有限(如 ONNX。想要在真正的业务场景下发挥价值都是需要淌坑的。用的更多的,往往都是性能领域强悍的 C/C++/RUST 来实现,比如自研、或者框架本身自带的(如 TensorFlow 的 Serving),会更能满足性能需求。平台选用的框架最好是不要太多,这样做 Serving 会比较麻烦,不同的框架都要去找解决方案实现一遍。


虽然做不到通用的模型 Serving 方案,但是通用的模型发布、提供服务的平台却是可以做到的。这是这部分的重点,即如何设计一个通用的推理平台。一个推理平台需要考量的点如下所示:


  1. 支持各种框架,多语言、多环境

  2. 模型版本管理

  3. API 安全性

  4. 可用性、可扩展性,服务状态监控、动态扩容

  5. 监控、告警,日志可视化

  6. 灰度上线/AB Testing


把 Serving 看做是普通的 Web 服务。对于上诉的点,Kubernetes 体系是绝佳的选择:

  1. 镜像,配合 NFS 的模型,启动时 Mount 再复制到容器内部。可以支持多语言、多环境

  2. 版本管理,每个版本在 NFS 上创建新的版本目录,比如 0.0.1,放入对应的模型和启动脚本配合一个 Service。这样就允许不同版本的 Service 同时在线,或者部分在线

  3. API 安全性,与 Kubernetes 本身无关。简单的做法是为每个 API 生成对应的调用 Token 来做鉴权,或者使用 API 网关来做

  4. 可用性、可扩展性。利用 Kubernetes 原生的 Liveness/Readness probe,可以检测单个 Pod 中服务的状态。使用 Kubernetes 的 HPA、或者自己实现监控再配合 Autoscale 可以满足需求,而且这些都可以成为一些配置暴露给用户

  5. 监控、告警。可以 Prometheus+Grafana+Alertmanager 三件套,或者配合企业内部的运维体系

  6. 交给 Istio 即可。灰度发布肯定妥妥的,利用一些 Cookie/Header 来做分流到不同版本的服务也可以做到部分 AB Testing 的事情


由于 Serving 服务与服务之间是没有关系的,是一个无状态的单体服务。对于单体服务的各种处理就会比较简单。比如不使用 Kubernetes,使用 AWS 云的 EC2 来部署,配合 Auto Scaling、CloudWatch 等也是非常简单的。

Addons

除开上诉的核心功能。一般来说,机器学习平台还有一些扩展。最经典的当属 CLI 和 SDK 了。

CLI 就不用多说了,主要提供快捷入口。可以参考 AWS 的 CLI。需要包含的点主要是:

  1. 提供基本的操作功能,满足用户的使用

  2. 以及导入导出功能。方便用户共享配置、快速创建和使用平台的功能

  3. 支持多环境、认证

  4. 完善的操作使用文档、帮助命令、模板文件等


对于 SDK 这块,需要和平台本身的功能做深度集成;同时,还需要一定的灵活性。比如上诉的自定义算法,用户可以在 Notebook 里面读取平台生成的数据集,写完代码后,还得支持提交分布式训练。既要集成平台功能,又得支持一定程度的自定义,如何设计会是一个难点。

探索实验(Notebook)

Notebook 本身功能并不复杂。实质上就是对 Jupyter Notebook/JupyterLab 等的包装。通常的做法是使用 Kubernetes 的 Service,启动一个 Notebook。以下几点是需要考量的:


  1. 存储要能持久化,需要引入类似于 NFS 这样的持久目录以供用户使用

  2. 内置 Demo,如读取平台数据、访问资源、提交任务

  3. 预置不同的镜像,支持不同的框架,以及 CPU/GPU 诉求用于启动不同的 Notebook

  4. 安全问题,一个是 Notebook 本身的安全。另一个是容器本身的安全

  5. 有可用的安全源,以供用户安装和下载一些包和数据

  6. 能够访问到基础设施里面的数据,Mount/API

  7. 最好能有 Checkpoint 机制,不用的时候回收资源。需要的时候再启动,但环境不变


大致的解决思路如下:

  1. 持久化需要 Mount 存储。Storage class 可以帮助

  2. Notebook 自身的安全,可以在里面增加 Handler 或者外面配置一层 Proxy 来鉴权。容器的安全大概有这几点需要考量(要做到更严格还有很多可以深挖):

  3. 限制容器内部用户的权限

  4. 开启 SELinux

  5. Docker 的—cap-add/—cap-drop

  6. heckpoint 机制的实现,数据已经持久化在外部存储了。只需要 Save 新的镜像,作为下次启动的镜像即可,可使用 Daemonset+Docker in dokcer 的形式做一个微服务来提交镜像。

平台的基石

这一节主要讨论的是做平台一定绕不开的问题。首先逃脱不了的是多租户问题:

  1. 可能要和已有的系统进行集成。而不是新开发

  2. 租户间权限、数据隔离

  3. 租户资源配额、任务优先级划分


技术上来说,系统自身的租户功能难度不高。主要是数据、资源隔离这块。要看对应的基础设施:

  1. Hadoop 可以使用 Keberos

  2. Kubernetes 可以使用 Namespace


再配合不同的调度队列。即可完成需求。


另外一点是偏技术层面的调度功能。这可以算是整个平台运行的基础,无论是数据处理还是模型训练、模型部署都依赖于此, 调度系统分为两块:

  1. 调度本身,即如何调度不同的任务到不同的基础设施上

  2. 状态管理,有些任务可能存在依赖关系,会触发不同的 Action。这也是一个状态机的问题

状态管理这块,业务场景不复杂的情况下自己实现即可。一般平台上也没有太复杂的依赖关系,经典的模型训练也不过单向链路而已。如果过于复杂,可以考虑其他开源任务编排工具:



调度本身是一个任务队列+任务调度组合而成。队列用啥都可以,数据库也可以。只要能保证多个 Consumer 的数据一致性即可。任务调度,如果不考虑用户的感受,可以直接丢给对应的基础设施,如 Yarn/Kubernetes 都可以。由这些基础设施来负责调度和管理,这样最简单。


如果想做的尽善尽美,那还是需要维护一个资源池。同步基础设施的使用情况,然后根据剩余资源和任务优先级来做调度。


状态更新方面。对于 Yarn 体系,只能通过 API 去轮询状态、获取日志。


对于 Kubernetes 体系,推荐一个 Informer 机制,通过 List&Watch 机制可以方便、快速获取整个集群的情况:


关于如何提交任务到基础设施:

  1. Spark/Yarn - 直接 API、包装下命令行者 Livy 都可

  2. Kubernetes - SDK

最终 Boss

做平台,最怕的是什么?当然不是某某技术太过于复杂,攻克不下。而是没有用户使用平台,或者不能通过平台产生真实业务价值,这才是最重要的。有某一业务场景在平台实现端到端产生价值,才能证明这个平台的价值,才能吸引其他用户来使用。


对于用户来说,一般都已经有自己成熟的技术线。想要他们往平台上迁移,实属不易,除非已有系统满足不了他们的需求、或者已有系统不好用。毕竟,自己用的好好的系统,迁移是需要耗时耗力的,用别人的东西也没有自己做来的灵活;学习一个新的系统使用也是如此,有可能一开始用着并不习惯。此外,新的系统,没有人期望第一个来当小白鼠的。有这么多缺点,当然平台本身也有其优点。比如将基础设施这块甩给了第三方,不用去关注底层的东西,只要关注自己的业务了。


事实上的流程往往都是,随着平台 MVP 的发布。部分用户开始上来试用,然后提各种想法和需求;紧接着,会逐渐迁移部分功能上来试用,比如搞些数据上来跑跑 Demo,看看训练的情况等。同时,在这个阶段,就会需要各种适配用户原始的系统了,比如原始数据导入与现有系统不兼容,需要格式的转换;再比如只想用平台的部分功能,想集成到自己现有的系统中等。最后才是,真正的在平台上使用。想要用户能端到端的使用平台,来完成他们的业务需求,还是需要漫长的过程的。


相对而言,至上而下的推动往往更为有效。总有一批人要先来体验、先来淌坑,给出建议和反馈。这样这个平台才会越来越好,朝好的地方发展。而不是一开始上来就堆功能,什么炫酷搞什么、大而全。但是在用户使用上,易用性和稳定性并不好,或者是并不能解决用户的需求和难点。那这种平台是活不下去的。


本文转载自:ThoughtWorks 洞见(ID:TW-Insights)

原文链接:机器学习平台建设指南

公众号推荐:

跳进 AI 的奇妙世界,一起探索未来工作的新风貌!想要深入了解 AI 如何成为产业创新的新引擎?好奇哪些城市正成为 AI 人才的新磁场?《中国生成式 AI 开发者洞察 2024》由 InfoQ 研究中心精心打造,为你深度解锁生成式 AI 领域的最新开发者动态。无论你是资深研发者,还是对生成式 AI 充满好奇的新手,这份报告都是你不可错过的知识宝典。欢迎大家扫码关注「AI前线」公众号,回复「开发者洞察」领取。

2021-05-11 08:005507

评论

发布
暂无评论
发现更多内容

腾讯系广告合作渠道 微信朋友圈广告利润8成 个人轻创业项目

Geek-76961b

合合信息携手业界专家,解码数据资产管理方法与入表的关键路径

合合技术团队

合合信息 数据资产管理

全媒体广告信息流广告加盟 互联网广告代理 月入十万

陈老师讲创业

AnyMP4 Video Converter for Mac:高质量视频转换与编辑工具

影影绰绰一往直前

运行Adobe应用提示非正版This non-genuine Adobe app has been disabled soon如何解决

Rose

2024深圳国际汽车照明技术展览会

吹吹晚风

理解 Webhook 和 API:详细导读

Apifox

程序员 前端 后端 API WEBHOOKS

Freemesh云原生框架介绍

如水

云原生

2024 年 4月,公链领域关键发展包括:比特币减半、市场下跌以及 TON 和 Base 发展迅猛。

Footprint Analytics

公链

妙笔WonderPen for Mac:智能同步,写作无忧

影影绰绰一往直前

WonderPen妙笔 WonderPen下载 WonderPen中文版 WonderPen激活版

青否数字人有哪些应用场景和优势?

青否数字人

Mac上软件闪退(意外退出)的解决方法

Rose

华为云引领首个代码大模型国际标准立项

华为云开发者联盟

人工智能 华为云 华为云开发者联盟 企业号2024年5月PK榜 代码大模型

全媒体信息流广告-正规授权加盟 腾讯广告加盟创业

全媒体广告楚老师

DiskSlim - Disk Cleanup Pro for Mac:保护隐私,智能清理

影影绰绰一往直前

国家网络与信息系统安全产品质量检验检测中心是什么机构?成立于一年?有什么用?

行云管家

网络安全 等保 等保测评 等级测评

2024开源之夏|来自MatrixOne社区的邀请函

MatrixOrigin

数据库 分布式 云原生

互联网广告投放项目代理怎么对接的 腾讯朋友圈广告代理有市场吗?

互联网创业说

敏捷开发最佳实践:自驱团队实践案例之心情曲线回顾会

PingCode

敏捷开发 敏捷实践

网络安全软件堡垒机推荐行云管家云堡垒机!

行云管家

网络安全 数字化 数据安全 堡垒机

Smartproxy谷歌代理插件与Chrome扩展的操作指南

摘星星的猫

互联网广告代理加盟利润高易上手,提供一站式扶持,轻资产创业首选

互联网广告小哥

Flink中基于Chandy-Lamport算法的分布式快照实现详解

木南曌

flink 实时计算

ON1 Effects 2024 for Mac:创意无限,图像处理新选择

影影绰绰一往直前

ON1 Effects 2024下载 ON1 Effects 2024 mac ON1 Effects 2024激活版 ON1 Effects 2024破解版

10分钟了解Golang泛型

伤感汤姆布利柏

苹果电脑/macbook查看已连接wifi密码的两种简单方法

Rose

2024上海国际封头与膨胀节技术设备展览会

吹吹晚风

腾讯广告代理项目如何加盟?怎么成为微信广告代理商

微点全媒体广告运营

微信广告代理加盟 互联网广告代理加盟 朋友圈广告代理加盟 信息流广告代理加盟 小红书广告代理

开发者体验活动|TinyEngine 低代码引擎:带你5分钟快速构建游戏登录界面

OpenTiny社区

开源 前端 低代码 OpenTiny

Mac电脑(苹果电脑)非App Store软件如何安装?

Rose

Mac电脑怎么设置动态桌面,heic动态桌面壁纸怎么使用

Rose

机器学习平台建设指南_AI&大模型_张凯峰_InfoQ精选文章