黯灭_邓彬个人页面-阿里云开发者社区

降本增效利器！趣头条Spark Remote Shuffle Service最佳实践

王振华，趣头条大数据总监，趣头条大数据负责人曹佳清，趣头条大数据离线团队高级研发工程师，曾就职于饿了么大数据INF团队负责存储层和计算层组件研发，目前负责趣头条大数据计算层组件Spark的建设范振，花名辰繁，阿里云计算平台EMR高级技术专家，目前主要关注开源大数据技术以及云原生技术。 1. 业务场景与现状趣头条是一家依赖大数据的科技公司，在2018-2019年经历了业务的高速发展，主App和其他创新App的日活增加了10倍以上，相应的大数据系统也从最初的100台机器增加到了1000台以上规模。多个业务线依赖于大数据平台展开业务，大数据系统的高效和稳定成了公司业务发展的基石，在大数据的架构上我们使用了业界成熟的方案，存储构建在HDFS上、计算资源调度依赖Yarn、表元数据使用Hive管理、用Spark进行计算，具体如图1所示：图1 趣头条离线大数据平台架构图其中Yarn集群使用了单一大集群的方案，HDFS使用了联邦的方案，同时基于成本因素，HDFS和Yarn服务在ECS上进行了DataNode和NodeManager的混部。在趣头条每天有6W+的Spark任务跑在Yarn集群上，每天新增的Spark任务稳定在100左右，公司的迅速发展要求需求快速实现，积累了很多治理欠债，种种问题表现出来集群稳定性需要提升，其中Shuffle的稳定性越来越成为集群的桎梏，亟需解决。 2. 当前大数据平台的挑战与思考近半年大数据平台主要的业务指标是降本增效，一方面业务方希望离线平台每天能够承载更多的作业，另一方面我们自身有降本的需求，如何在降本的前提下支撑更多地业务量对于每个技术人都是非常大地挑战。熟悉Spark的同学应该非常清楚，在大规模集群场景下，Spark Shuffle在实现上有比较大的缺陷，体现在以下的几个方面： Spark Shuffle Fetch过程存在大量的网络小包，现有的External Shuffle Service设计并没有非常细致的处理这些RPC请求，大规模场景下会有很多connection reset发生，导致FetchFailed，从而导致stage重算。 Spark Shuffle Fetch过程存在大量的随机读，大规模高负载集群条件下，磁盘IO负载高、CPU满载时常发生，极容易发生FetchFailed，从而导致stage重算。重算过程会放大集群的繁忙程度，抢占机器资源，导致恶性循环严重，SLA完不成，需要运维人员手动将作业跑在空闲的Label集群。计算和Shuffle过程架构不能拆开，不能把Shuffle限定在指定的集群内，不能利用部分SSD机器。 M*N次的shuffle过程：对于10K mapper，5K reducer级别的作业，基本跑不完。 NodeManager和Spark Shuffle Service是同一进程，Shuffle过程太重，经常导致NodeManager重启，从而影响Yarn调度稳定性。以上的这些问题对于Spark研发同学是非常痛苦的，好多作业每天运行时长方差会非常大，而且总有一些无法完成的作业，要么业务进行拆分，要么跑到独有的Yarn集群中。除了现有面临的挑战之外，我们也在积极构建下一代基础架构设施，随着云原生Kubernetes概念越来越火，Spark社区也提供了Spark on Kubernetes版本，相比较于Yarn来说，Kubernetes能够更好的利用云原生的弹性，提供更加丰富的运维、部署、隔离等特性。但是Spark on Kubernetes目前还存在很多问题没有解决，包括容器内的Shuffle方式、动态资源调度、调度性能有限等等。我们针对Kubernetes在趣头条的落地，主要有以下几个方面的需求：实时集群、OLAP集群和Spark集群之前都是相互独立的，怎样能够将这些资源形成统一大数据资源池。通过Kubernetes的天生隔离特性，更好的实现离线业务与实时业务混部，达到降本增效目的。公司的在线业务都运行在Kubernetes集群中，如何利用在线业务和大数据业务的不同特点进行错峰调度，达成ECS的总资源量最少。希望能够基于Kubernetes来包容在线服务、大数据、AI等基础架构，做到运维体系统一化。因为趣头条的大数据业务目前全都部署在阿里云上，阿里云EMR团队和趣头条的大数据团队进行了深入技术共创，共同研发了Remote Shuffle Service（以下简称RSS），旨在解决Spark on Yarn层面提到的所有问题，并为Spark跑在Kubernetes上提供Shuffle基础组件。 3. Remote Shuffle Service设计与实现 3.1 Remote Shuffle Service的背景早在2019年初我们就关注到了社区已经有相应的讨论，如SPARK-25299。该Issue主要希望解决的问题是在云原生环境下，Spark需要将Shuffle数据写出到远程的服务中。但是我们经过调研后发现Spark 3.0（之前的master分支）只支持了部分的接口，而没有对应的实现。该接口主要希望在现有的Shuffle代码框架下，将数据写到远程服务中。如果基于这种方式实现，比如直接将Shuffle以流的方式写入到HDFS或者Alluxio等高速内存系统，会有相当大的性能开销，趣头条也做了一些相应的工作，并进行了部分的Poc，性能与原版Spark Shuffle实现相差特别多，最差性能可下降3倍以上。同时我们也调研了一部分其他公司的实现方案，例如Facebook的Riffle方案以及LinkedIn开源的Magnet，这些实现方案是首先将Shuffle文件写到本地，然后在进行Merge或者Upload到远程的服务上，这和后续我们的Kubernetes架构是不兼容的，因为Kubernetes场景下，本地磁盘Hostpath或者LocalPV并不是一个必选项，而且也会存在隔离和权限的问题。基于上述背景，我们与阿里云EMR团队共同开发了Remote Shuffle Service。RSS可以提供以下的能力，完美的解决了Spark Shuffle面临的技术挑战，为我们集群的稳定性和容器化的落地提供了强有力的保证，主要体现在以下几个方面：高性能服务器的设计思路，不同于Spark原有Shuffle Service，RPC更轻量、通用和稳定。两副本机制，能够保证的Shuffle fetch极小概率（低于0.01%）失败。合并shuffle文件，从M*N次shuffle变成N次shuffle，顺序读HDD磁盘会显著提升shuffle heavy作业性能。减少Executor计算时内存压力，避免map过程中Shuffle Spill。计算与存储分离架构，可以将Shuffle Service部署到特殊硬件环境中，例如SSD机器，可以保证SLA极高的作业。完美解决Spark on Kubernetes方案中对于本地磁盘的依赖。 3.2 Remote Shuffle Service的实现 3.2.1 整体设计 Spark RSS架构包含三个角色: Master, Worker, Client。Master和Worker构成服务端，Client以不侵入的方式集成到Spark ShuffleManager里（RssShuffleManager实现了ShuffleManager接口）。 Master的主要职责是资源分配与状态管理。 Worker的主要职责是处理和存储Shuffle数据。 Client的主要职责是缓存和推送Shuffle数据。整体流程如下所示(其中ResourceManager和MetaService是Master的组件)，如图2。图2 RSS整体架构图 3.2.2 实现流程下面重点来讲一下实现的流程： RSS采用Push Style的shuffle模式，每个Mapper持有一个按Partition分界的缓存区，Shuffle数据首先写入缓存区，每当某个Partition的缓存满了即触发PushData。 Driver先和Master发生StageStart的请求，Master接受到该RPC后，会分配对应的Worker Partition并返回给Driver，Shuffle Client得到这些元信息后，进行后续的推送数据。 Client开始向主副本推送数据。主副本Worker收到请求后，把数据缓存到本地内存，同时把该请求以Pipeline的方式转发给从副本，从而实现了2副本机制。为了不阻塞PushData的请求，Worker收到PushData请求后会以纯异步的方式交由专有的线程池异步处理。根据该Data所属的Partition拷贝到事先分配的buffer里，若buffer满了则触发flush。RSS支持多种存储后端，包括DFS和Local。若后端是DFS，则主从副本只有一方会flush，依靠DFS的双副本保证容错；若后端是Local，则主从双方都会flush。在所有的Mapper都结束后，Driver会触发StageEnd请求。Master接收到该RPC后，会向所有Worker发送CommitFiles请求，Worker收到后把属于该Stage buffer里的数据flush到存储层，close文件，并释放buffer。Master收到所有响应后，记录每个partition对应的文件列表。若CommitFiles请求失败，则Master标记此Stage为DataLost。在Reduce阶段，reduce task首先向Master请求该Partition对应的文件列表，若返回码是DataLost，则触发Stage重算或直接abort作业。若返回正常，则直接读取文件数据。总体来讲，RSS的设计要点总结为3个层面：采用PushStyle的方式做shuffle，避免了本地存储，从而适应了计算存储分离架构。按照reduce做聚合，避免了小文件随机读写和小数据量网络请求。做了2副本，提高了系统稳定性。 3.2.3 容错对于RSS系统，容错性是至关重要的，我们分为以下几个维度来实现： PushData失败当PushData失败次数(Worker挂了，网络繁忙，CPU繁忙等)超过MaxRetry后，Client会给Master发消息请求新的Partition Location，此后本Client都会使用新的Location地址，该阶段称为Revive。若Revive是因为Client端而非Worker的问题导致，则会产生同一个Partition数据分布在不同Worker上的情况，Master的Meta组件会正确处理这种情形。若发生WorkerLost，则会导致大量PushData同时失败，此时会有大量同一Partition的Revive请求打到Master。为了避免给同一个Partition分配过多的Location，Master保证仅有一个Revive请求真正得到处理，其余的请求塞到pending queue里，待Revive处理结束后返回同一个Location。 Worker宕机当发生WorkerLost时，对于该Worker上的副本数据，Master向其peer发送CommitFile的请求，然后清理peer上的buffer。若Commit Files失败，则记录该Stage为DataLost；若成功，则后续的PushData通过Revive机制重新申请Location。数据去重 Speculation task和task重算会导致数据重复。解决办法是每个PushData的数据片里编码了所属的mapId，attemptId和batchId，并且Master为每个map task记录成功commit的attemtpId。read端通过attemptId过滤不同的attempt数据，并通过batchId过滤同一个attempt的重复数据。多副本 RSS目前支持DFS和Local两种存储后端。在DFS模式下，ReadPartition失败会直接导致Stage重算或abort job。在Local模式，ReadPartition失败会触发从peer location读，若主从都失败则触发Stage重算或abort job。 3.2.4 高可用大家可以看到RSS的设计中Master是一个单点，虽然Master的负载很小，不会轻易地挂掉，但是这对于线上稳定性来说无疑是一个风险点。在项目的最初上线阶段，我们希望可以通过SubCluster的方式进行workaround，即通过部署多套RSS来承载不同的业务，这样即使RSS Master宕机，也只会影响有限的一部分业务。但是随着系统的深入使用，我们决定直面问题，引进高可用Master。主要的实现如下：首先，Master目前的元数据比较多，我们可以将一部分与ApplD+ShuffleId本身相关的元数据下沉到Driver的ShuffleManager中，由于元数据并不会很多，Driver增加的内存开销非常有限。另外，关于全局负载均衡的元数据和调度相关的元数据，我们利用Raft实现了Master组件的高可用，这样我们通过部署3或5台Master，真正的实现了大规模可扩展的需求。 4. 实际效果与分析 4.1 性能与稳定性团队针对TeraSort，TPC-DS以及大量的内部作业进行了测试，在Reduce阶段减少了随机读的开销，任务的稳定性和性能都有了大幅度提升。图3是TeraSort的benchmark，以10T Terasort为例，Shuffle量压缩后大约5.6T。可以看出该量级的作业在RSS场景下，由于Shuffle read变为顺序读，性能会有大幅提升。图3 TeraSort性能测试（RSS性能更好）图4是一个线上实际脱敏后的Shuffle heavy大作业，之前在混部集群中很小概率可以跑完，每天任务SLA不能按时达成，分析原因主要是由于大量的FetchFailed导致stage进行重算。使用RSS之后每天可以稳定的跑完，2.1T的shuffle也不会出现任何FetchFailed的场景。在更大的数据集性能和SLA表现都更为显著。图4 实际业务的作业stage图（使用RSS保障稳定性和性能） 4.2 业务效果在大数据团队和阿里云EMR团队的共同努力下，经过近半年的上线、运营RSS，以及和业务部门的长时间测试，业务价值主要体现在以下方面：降本增效效果明显，在集群规模小幅下降的基础上，支撑了更多的计算任务，TCO成本下降20%。 SLA显著提升，大规模Spark Shuffle任务从跑不完到能跑完，我们能够将不同SLA级别作业合并到同一集群，减小集群节点数量，达到统一管理，缩小成本的目的。原本业务方有一部分SLA比较高的作业在一个独有的Yarn集群B中运行，由于主Yarn集群A的负载非常高，如果跑到集群A中，会经常的挂掉。利用RSS之后可以放心的将作业跑到主集群A中，从而释放掉独有Yarn集群B。作业执行效率显著提升，跑的慢 -> 跑的快。我们比较了几个典型的Shuffle heavy作业，一个重要的业务线作业原本需要3小时，RSS版本需要1.6小时。抽取线上5~10个作业，大作业的性能提升相当明显，不同作业平均下来有30%以上的性能提升，即使是shuffle量不大的作业，由于比较稳定不需要stage重算，长期运行平均时间也会减少10%-20%。架构灵活性显著提升，升级为计算与存储分离架构。Spark在容器中运行的过程中，将RSS作为基础组件，可以使得Spark容器化能够大规模的落地，为离线在线统一资源、统一调度打下了基础。 5. 未来展望趣头条大数据平台和阿里云EMR团队后续会继续保持深入共创，将探索更多的方向。主要有以下的一些思路： RSS存储能力优化，包括将云的对象存储作为存储后端。 RSS多引擎支持，例如MapReduce、Tez等，提升历史任务执行效率。加速大数据容器化落地，配合RSS能力，解决K8s调度器性能、调度策略等一系列挑战。持续优化成本，配合EMR的弹性伸缩功能，一方面Spark可以使用更多的阿里云ECS/ECI抢占式实例来进一步压缩成本，另一方面将已有机器包括阿里云ACK，ECI等资源形成统一大池子，将大数据的计算组件和在线业务进行错峰调度以及混部。欢迎试用自建Spark或使用EMR Spark集群的客户都可以测试，测试加入钉钉群（如下），并在群内@黯灭 @扬流

PAI：一站式云原生AI平台

本文是《飞天大数据产品价值解读系列》之《PAI:一站式云原生AI平台》的视频分享精华总结，主要由阿里云机器学习PAI团队的产品经理高慧玲(花名：玲汐)向大家介绍了阿里巴巴整体的AI情况以及一站式云原生的AI平台PAI，并且做了简单的DEMO演示。以下是视频内容精华整理，主要包括以下三个部分：1.阿里巴巴整体AI介绍；2.PAI：一站式云原生AI平台；3.快速上手演示案例。一、阿里巴巴整体AI介绍阿里巴巴致力于打造A+B+C+D+E的AI研发、应用和生态合作体系。经过前面的几次直播，相信大家已经了解MaxCompute、Flink等大数据计算引擎。在我们的AI架构里，算法和大数据不分家，如下图所示，AI架构最底层由算法（A）、大数据（B）以及计算能力（C）提供了我们整个AI架构的基础能力。基于ABC孵化出了各个垂直领域里的AI应用场景（D），这些应用场景也在不断的反哺我们下层的算法及算力的不断前进和衍生。在ABCD之上，构建基于AI的生态体系（E）。阿里巴巴认为只有全面布局上述五个方面，形成软硬一体、应用驱动的研发形态，才能在人工智能时代形成强大技术优势。基于上图所示的架构所蕴含的指导思想，阿里在AI领域打造了完整的技术能力体系。如下图所示，最下面的灰色部分是基础设施层，提供CPU、GPU、NPU、FPGA等在AI中发挥重要作用的异构计算硬件。中间的橙色部分是产品PaaS层，是阿里AI能力中能力最厚实的产品体系层，也是本文重点要介绍的部分。 *AI云服务，包括虚机、容器、存储、加速芯片等底层资源的管控能力。 *高性能计算，包括多种计算加速以及引擎加速的能力。 *AI系统框架既包括了阿里自研的各种框架以及模型，同时兼容丰富的开源生态，并且阿里一直和开源社区共建，为大家提供更好建模迭代和部署能力。 *AI托管平台层是直接面向AI用户的产品层，PAI推出了从数据准备到模型训练，再到最终的模型部署，全链路、全环节上的开发以及应用平台。整个AI体系孵化出众多的SaaS垂直领域能力，包括图像、视觉、语音、NLP、推荐系统等等，用来帮助用户提升数据资产利用率，解决不同场景需求。前面介绍的AI技术栈已经在阿里集团内部非常多的应用场景下进行了渗透和落地。如下图中所示的众多丰富业务场景下，会产出大量比如电商广告、娱乐、地图、物流等不同类型的数据，阿里巴巴AI体系能力为这些数据提供了价值提升和创造性业务加持。我们相信上述的海量数据以及多样的场景在实际应用中具有广泛性和通用性，并且也希望在阿里内部沉淀的经验能够更好地为外部客户带来相同的业务价值提升。因此阿里逐渐地打磨出了阿里巴巴PAI平台对外提供服务，其整个发展历程如下图所示。接近十年的发展，PAI已经脱变为优秀的一站式云原生AI平台。二、PAI：一站式云原生AI平台下图是PAI目前的完整产品矩阵，从中大家可以看到我们已经形成了非常丰富的产品形态，包括智能标注、可视化建模、交互式建模、云原生深度训练、自动学习等离线环节产品，同时我们训练出来的模型可以通过在线的预测服务与实际业务系统进行对接。并且我们还建立了“商品”丰富的AI“淘宝”平台（智能生态市场），大家可以在市场中沉淀各种算法和模型，进行交换和共享。众所周知，一个完整的AI开发链路主要包括数据准备、实验构建及模型训练、到最终的模型部署与在线服务，接下来重点会介绍PAI的云原生产品家族，包括上图中高亮的PAI-DSW交互式建模平台、PAI-DLC云原生深度学习训练平台、PAI-EAS在线预测体系以及其中PAI-Blade编译优化产品，我们会按照用户的使用链路进行介绍。（一）实验构建：PAI-DSW2.0 完成数据准备之后，用户会从小规模的建模和实验构建部分开始进行AI实践。PAl-DSW(Data Science workshop)是PAI平台推出的交互式编程环境，是一款针对Al开发者量身打造的云端机器学习开发IDE，集成了开源的JupyterLab，并以插件化的形式进行了深度定制化开发，无需任何运维配置，可直接开启Notebook编写、调试、运行Python代码，是PAI建模产品中使用方式最为灵活的一个产品，深受广大AI开发者的喜爱。今年PAI基于云原生的架构，进一步推出推出了产品形态更丰富，使用方式更多样，使用架构更安全的PAI-DSW2.0，其主要的新特色包括多AI编程模式、灵活开放的AI开发环境、安全高效以及集成易用，具体如下图所示。下图是PAI-DSW2.0的技术架构。从中可以看到它完全基于云原生的架构，基于ACK的调度体系，向下对接了多种灵活的存储，向上我们通过不同的插件不断的扩展和丰富我们的产品能力，同时把这些能力和接口也对用户进行了开放。在PAI-DSW2.0中，我们提供了灵活开放的AI开发环境，无论用户习惯于用轻量的JupyterLab交互式AI开发，还是习惯于用VS Code做复杂工程的开发和管理，或者说习惯于直接在terminal里进行命令行或者vim开发，DSW都可以满足。基于以上多样和灵活的产品形态，我们在云上提供了云原生的在线AI建模方案，非常适用于一些在线开发场景，比如说团队的AI在线协作开发，线上AI教学以及本地的AI研发迁移上云。当前除了天池社区的大量开发者用户外，PAI-DSW还吸引了不同行业的企业客户，比如在线教育行业、互联网消费行业以及AI创业公司等。（二）大规模分布式训练：PAI-DLC 在算法实验到出一定效果之后，用户通常需要用大规模的生产数据来进行的模型生产训练。在这一阶段，很多开发者以及公司都会面临在数据量规模扩大带来的问题，比如说分布式的扩展，以及模型训练加速。针对这样的问题，PAI在今年重磅推出了PAI-DLC云原生深度学习训练平台，其架构图如下图所示。可以看出，PAI-DLC是Kubernetes-native架构，可以做到完全的容器化部署和使用。基于ACK/ECI，PAI-DLC能够提供资源的弹性扩展，进行不同任务下的资源调度和分配，向下兼容支持了非常多的CPU机型以及GPU机型，无论面向大规模稀疏数据的训练，还是面向感知类场景的训练，都可以快速适配合适的云原生资源。另外，PAI-DLC的核心能力是提供支持接近线性加速的内核，可以让训练任务在多种引擎上做到性能增强。下图benchmark展示了DLC上的性能数据和开源框架的对比，下图（左）展示的是在很多电商广告、推荐信息流等场景下会遇到的大规模的稀疏矩阵的训练加速问题，PAI-DLC基于Parameter Server架构能够支持到百亿特征，千亿样本以及上千个节点的并发训练，对比开源框架最高能做到7倍的性能提升。另外在一些深度学习感知类场景中--比如NLP、图像等--算法开发常面临参数量巨大的问题，有时可能达到几亿级别，做到高效的分布式扩展往往也会成为巨大的挑战。PAI-DLC针对性提供了稠密分布式训练加速的能力，通过benchmark数据的对比（下图右），可看出集群规模越大的情况下，PAI-DLC的性能优势越明显。总的来说，无论在推荐广告，还是音视频解析、语音识别、语义识别等场景，都可以应用PAI-DLC获得非常好的训练性能加速效果。基于云原生架构以及极致的性能加速体验，PAI-DLC在云上吸引了非常多的人工智能企业以及互联网Top企业客户。最近某个自动驾驶行业客户的实践案例中，通过PAI-DLC产品的加速，一个大规模模型的训练时间从5天缩短为5小时，所消耗的分布式资源仅14.5倍，足以见加速效果的显著。遇到类似分布式加速的难题，欢迎来试用PAI-DLC，在分布式训练这个环节上做到降本提效。（三）模型推理服务：PAI-EAS+Blade （1）PAI-EAS 在模型构建及训练完成之后，将模型应用到业务中的重要环节是让模型去预测业务中源源不断产出的未知数据，通常有离线预测推理/在线预测推理两种方式。现在越来越多的场景追求极致的实时性，因此PAI在模型应用到业务的最后一公里环节推出了在线模型推理服务，其中核心产品是PAI-EAS，其架构图如下所示。 PAI-EAS是完全基于阿里云容器服务ACK的云原生服务，其主要优势有多环境、灵活弹性、面向生产以及丰富的产品能力，具体如下图所示。基于上面的产品优势，PAI-EAS对内对外都服务了非常多的客户，在最近的双十一大促中，EAS支持了智能客服等众多核心业务，其中单模型服务峰值高达40万QPS，依然平稳度过。在线推理服务不同于离线训练操作，需要资源常驻，并且随着业务量的提升，模型服务的线上QPS通常也会不断提升，这就带来了资源需求增长的问题。在这种情况下，怎么能够做到不影响业务QPS增长，降低成本投入，是很多AI公司，尤其是AI创业公司面临的“两难问题”。（2）PAI-Blade 为了解决这个“两难问题”，PAI在在线服务环节推出了PAI-Blade这款工具型产品，为用户在资源常驻的在线服务环节提供降本提效的利器，其整体架构如下图所示。在PAI-Blade中，我们将模型压缩、系统优化和模型分析等完整技术能力通过最简单最易用的产品形态提供出来，用户可以不需要理解底部处理的逻辑，只需要提交模型，然后经过大约十分钟的优化任务，就可以直接获得一个经过加速的新模型，然后将新模型做相应的部署和更新就可以得到一个效率更高的模型在线服务。在整个过程中，甚至可以做到零输入优化，获得精度无损的优化模型，为线上服务提效降本。 PAI-Blade已经帮助阿里内部非常多的业务场景获得了不错的模型优化效果，比如在安全部鉴黄业务场景中的优化效果达到了5.48倍，意味着线上GPU卡消耗仅需原先的约20%。同时，PAI-EAS+Blade的组合拳在云上也有很多客户的实践，目前在在线直播、在线教育以及移动分发场景下都有应用和落地。例如某典型的智能教育企业客户的应用案例中，他们自己实现了业务OCR模型，应用在识别学生作业等场景。由于业务流程复杂造成的模型复杂，导致在线推理服务需要上百张卡才能支持。用户模型在PAI-Blade进行优化之后，顺利地将资源成本降低到了原先的一半，资源开销节省50%。未来，我们将推出更完整的推理服务体系，让大家快速的将优化后的模型部署到端侧，做到云/边/端的扩展，以及无论在哪种环境下，都可以实现推理服务的降本提效。三、快速上手演示案例最后，通过PAI-DSW和PAI-EAS的一个小案例，让大家来感受一下我们产品的使用方式，也欢迎大家自己直接进行试用。下图是相关的社区和群，大家可以在其中进行关于PAI的交流和学习。整个Demo主要包括（1）数据读取，探索与分析（2）模型构建与训练（3）模型部署三个部分。（一）数据读取，探索与分析在支持Python原生读取数据的基础之上，为了方便用户读取数据，DSW提供了dswmagic command来帮助用户从MaxCompute项目中读取数据，同时在DSW中，还可以通过使用一些类似pandas的库来对数据进行整理和分析，同时也可以通过各种用户熟悉的库将数据可视化。比如下图所展示的是从MaxCompute的公开项目中读取Iris鸢尾花数据，并进行可视化。（二）模型构建与训练了解完数据后，我们就可以开始构建模型了。我们使用sklearn快速构建一个对Iris鸢尾花数据集的决策树模型，并且对模型进行可视化，代码和效果如下图所示。（三）模型部署在完成了上面的模型训练过程之后，我们也已经将模型导出为了pmml文件。接下来我们使用EASCMD对模型进行部署。在从DSW到EAS模型部署中，我们需要完成如下图所示的主要步骤。这样，我们就完成了一个简单的机器学习项目从数据读取，分析，建模，训练到部署，如需要调试模型，进入EAS管控台就能看到刚刚部署的模型服务，点击在线调试即可，比如下图。基于以上几个步骤，我们就完成了一个简单的数据读取，分析建模，离线模型训练，再到在线的模型部署这样的完整链路。如果大家有兴趣的话，也可以直接在阿里云官网的产品->人工智能栏目下找到机器学习PAI产品，来体验完整的从数据准备到模型开发训练，模型管理再到模型部署的完整全流程的一站式AI服务。关键词：AI平台、云原生、AI、PAI、PAI-DSW、PAI-DLC、PAI-EAS、PAI-Blade、机器学习在线服务

黯灭_邓彬个人页面-阿里云开发者社区

个人介绍

擅长的技术

Databricks数据洞察公开课！精彩案例，成功实践，技术解读都在这里！

降本增效利器！趣头条Spark Remote Shuffle Service最佳实践

Databricks数据洞察公测实例关闭通知

PAI：一站式云原生AI平台

E-MapReduce 4月产品新功能

Databricks数据洞察公开课！精彩案例，成功实践，技术解读都在这里！

降本增效利器！趣头条Spark Remote Shuffle Service最佳实践

Databricks数据洞察公测实例关闭通知

PAI：一站式云原生AI平台

datahub恶意扣费，我就是一个开发者，只是想了解产品，结果两天没注意，160就没有了。

原来GNN这么好上手，OMG！用它！

【通知】交互式分析将于2020.3.20正式商业化

图神经网络（AliGraph）在阿里巴巴的发展与应用

开源 | 全球首个批流一体机器学习平台 Alink

2684亿销售额背后的阿里AI技术

天猫精灵业务如何使用机器学习PAI进行模型推理优化

DataWorks独享资源组开通、使用教程

DataWorks开通指南

Databricks数据洞察公开课！精彩案例，成功实践，技术解读都在这里！

降本增效利器！趣头条Spark Remote Shuffle Service最佳实践

Databricks数据洞察公测实例关闭通知

PAI：一站式云原生AI平台

E-MapReduce 4月产品新功能

原来GNN这么好上手，OMG！用它！

阿里巴巴开源GNN框架Graph-Learn

【通知】交互式分析将于2020.3.20正式商业化

图神经网络（AliGraph）在阿里巴巴的发展与应用

开源 | 全球首个批流一体机器学习平台 Alink

2684亿销售额背后的阿里AI技术

天猫精灵业务如何使用机器学习PAI进行模型推理优化

DataWorks独享资源组开通、使用教程

DataWorks开通指南

【重要通知】DataWorks 6月6日正式商业化，请公测用户及时开通DataWorks！

机器学习PAI 可视化建模 Tensorflow升级通知

Spark DataFrame 的 groupBy vs groupByKey

欢迎加入Spark中国社区

【上海Meetup回放视频+PPT下载整理】Elasticsearch Meetup系列第二期

【南京Meetup】苏宁Elastic平台化实践中踩过哪些坑，又是如何解决的？

datahub恶意扣费，我就是一个开发者，只是想了解产品，结果两天没注意，160就没有了。

对“个性化推荐”有需求的同学请加群！