MaxCompute Spark与Spark SQL对比分析及使用注意事项

595 阅读8分钟

以下内容根据演讲视频以及PPT整理而成。
本次分享主要围绕以下三个方面:

一、功能特性
二、代码开发
三、DataWorks模式

一、功能特性

1.Spark部署模式
Spark开源文档中表明部署模式支持几种部署模式,如stand alone模式、on yarn模式、on k8s模式等。但是其中并不包括Spark on MaxCompute模式。Spark on MaxCompute其实是 MaxCompute平台对开源的Spark做的兼容支持,使得 MaxCompute平台得以支持运行Spark的作业。在部署的集群方式上,on yarn、on k8s集群云上部署时需要购买ECS部署Hadoop集群或者容器集群,或者是使用阿里云的产品,如EMR、容器服务。与用于自己搭建的Hadoop环境(CDH或者EMR的环境)对比时,自建的环境需要登录到集群中,进行查询和维护的工作,但在MaxCompute平台中,使用侧无法登陆,无需关心集群的运维等操作,相比on yarn等开源模式只需将精力放在Spark业务逻辑开发上。当用户部署完集群去客户端提交作业时,开源模式是从官网下载Spark客户端,通过Spark-submit提交作业。但开源的Spark-submit客户端无法到MaxCompute平台中提交作业。这时则需要注意使用MaxCompute中Github上提供的Spark,部署开发环境,并在开发本地处理测试提交的工作。
图片 1.png

2.支持的数据源
Spark on yarn/K8s限制条件:首先,开源模式需要确认支持数据源操作的jar包是否存在。在常规做Spark作业开发分析时,需要需要考虑数据的来源以及去向,即Spark支不支持对对应的数据库进行读写访问。在开源开发模式下,需要将对应数据源支持的jar包加进去,在代码引用时则可以对对应的数据库进行读写访问。其次,开源模式还需要保证平台环境网络是否可打通。尽管代码层面上的接口都可以调用访问对应的库,但还需要检查Spark集群所运行的环境。如果作业是在集群中运行,在Hadoop中将作业提交上去,Work接点里面跑出来,在Spark并发跑的时候,拉取数据时要保证集群能访问到数据库,否则作业里会报连接超时的错误。云上环境网络连通上如常见的云上ECS搭建、自建Hadoop、k8s容器服务、EMR或者常见的VPC环境。如果VPC环境下集群和数据库之间要在网络评估的话,需要在同一个VPC下,否则默认情况下内网不通。

Spark on MaxCompute限制条件:若用户需要将一个作业迁到MaxCompute运行,需要检查MaxCompute是否支持所要访问的数据源,只有支持了,才能迁到MaxCompute上并借助其分布式能力让作业运行起来。目前MaxCompute支持访问的数据源包括oss、VPC下的ECS、RDS、redis等。基本上云上VPC下环境的数据源都支持。用户可从文档中获取具体支持数据源的所有信息,以及做访问配置时的配置方式等信息。
图片 2.png

2.提交方式
开源模式在Spark客户端提交作业时,开发完成后需要在本地运行测试,运行测试的时候可以以Local模式运行,在集群运行时用Cluster的方式,做交互式时用Client的方式。Spark on MaxCompute同样也支持这三种方式,只有有些点与开源不同。首先,使用Spark on MaxCompute的客户端做MaxCompute表时,代码中计划访问MaxCompute表,拉取RDD数据进行分析。随即在本地测试时将MaxCompute表里的数据下载下来,再进行处理。此时如果MaxCompute表较大的话,拉取数据的时间会比较长,导致作业运行的时间也会变长。
其次,在测试时UDF会拉张表写到本地的Warehouse目录下,在下次测试使用缓存数据。但Spark on MaxCompute本地测试时,都需要重新拉数据。所以针对这个特性做功能测试时,在拉的取的表中选定一部分特征,或者选一些分区下载,使得数据量变少,避免将所有数据都下载再运行作业。此外,在Client的模式下,正常开源模式中提交时客户端Driver需要启动,而Spark on MaxCompute在Client模式下运行时,客户端不用启Driver。
图片 3.png

**二、代码开发
1.POM配置**
在Spark业务代码开发时,Spark on MaxCompute代码开发可以参考对应Github中的POM配置文件Github.com/aliyun/MaxC…
POM文件配置完成后编译或者运行代码时会出现版本冲突,运行不过或者编译不通过等问题。这时需要注意的两个点,首先要注意spark和scala的版本,需要在在POM文件中指定Spark版本,Cupid版本和Scala的版本。对应的版本可以参考下图。此外,需要注意Scope配置是Provided类型。在涉及到Spark on MaxCompute资源包引用时,Scope的配置需要是Provided类型,否则编译时会出现问题。
图片 4.png

2.Jar包引用
下图是POM示例中关于ODPS数据源访问相关的jar包引用代码。关于Cupid-sdk,Spark底层其实是在Cupid平台运行的,由Cupid再去调用底层的调度资源进行协调,所以在做开发时Cupid版本需要引用进来。此外,如果在Spark需要访问oss数据源,需要将对应的jar包引用进来。odps-spark-datasource是对应ODPS支持源的jar包。
图片 5.png

2.使用建议
建议使用SparkSql,不要使用ODPSops:在前期开发时,如果需要访问ODPS结构化数据,建议使用SparkSql方式,推荐ODPSops方式。SparkSession包含很多配置,如下图,但不建议将配置全部写到代码里,只需制定常见参数,如生效逻辑,代码,提交和配置文件等。如果底层在Cupid平台运行,需要注意部分参数要在程序加载之前进行初始化,如果等程序加载好之后再进行参数初始化就无法生效,既代码里面写的部分参数最终运行起来会失效。所以建议线上运行时,将SparkSession代码中配置的参数写到Spark节点配置中。如此,作业开始运行之前,便会将对应的参数配置好,运行之前初始化好环境,让对应的参数生效。
图片 6.png

线上运行时SparkSession代码中参数写到Spark节点:Spark on MaxCompute在读MaxCompute表时,会被提示此项目不存在,如果确定项目的确存在,需要指定运行时端点的信息。通过运行时端点信息连接对应ODPS的元数据库,查询对应元数据是否来自对应的表,并查询项目是否存在。
配置spark.hadoop.odps.runtime.end.point:建议在做Spark节点配置时,加上runtime。
图片 7.png

引用jar资源使用spark.hadoop.odps.cupid.resources:当需要引用第三方的包,但是MaxCompute中并不具备这些包时,可以利用FatJar的方式运行。异或在直接编译完后,在需要引用一些其它jar包资源时,通过Cupid Resources参数引用。对应的jar包需要以资源方式上传到MaxCompute中。
图片 8.png

三、DataWorks模式
写好Spark作业后本地测试都正常,且要与其它作业形成工作流时需要添加依赖,还需要定时调度,这时需要将Spark作业部署到DataWorks中。在DataWorks中部署时需要进行以下几步操作。
**1.操作流程
创建spark节点:**找到DataWorks界面,找到对应的项,找到一个工作流,新建Spark节点。
图片 9.png

配置节点参数:新建的Spark节点中需要进行参数的配置。选择Spark版本,如Spark2.x。选择开发语言,如JavaScala或者Python。通过创建资源的方式将对应的jar包进行导入。再选择主jar包资源,如spark.oss.jar。再配置一些参数,如accessKey,指定runtime的endpoint,指定Cupid版本,通过domainlist指定需要访问VPC的数据源。以及Main Class表明main所在的组类。其余的参数可以通过参数选项进行自定义设置,如指定定时调度等。
进行测试运行:参数配置好后,保存,执行测试运行。可通过刷新日志,查看初始化的配置,如当前作业拉到了哪个项目。此时会生成Logview,与SQL作业类似,其中包含master节点和worker节点。
图片 10.png

提交发布:测试完成后,首先需要将Spark节点进行发布,才可以在生产环境正常的调度。在生产环境的运维环境下可以找到此节点。如果没有发布,只能在开发环境下看到此作业节点。
图片 11.png

但这时如果只发布Spark节点作业,在生产环境测试会报错。因为参数主jar包还没有发布,需要在测试环境下进行发布。所以需要注意,所引用的jar包都需要进行手动的发布。此外如果需要引入大的jar包,超过100M,可以通过命令行方式上传到MaxCompute开发和测试环境中。但这时可能无法在DataWorks界面看到这个包。但可以通过反向添加到DataWorks中。
图片 12.png



查看更多:https://yqh.aliyun.com/detail/6402?utm_content=g_1000106255

上云就看云栖号:更多云资讯,上云案例,最佳实践,产品入门,访问:https://yqh.aliyun.com/