Apache 3.2火花就在上周(见被释放发布说明),现在可供任何人想要运行火花在Kubernetes(或者只是火花在码头工人)作为我们更新DockerHub库图像优化码头工人的火花。
在本文中,我们想带你参观了新特性的Apache引发我们兴奋。我们首先看看一般的改进有利于整个社区,然后为Spark-on-Kubernetes用户关注一个令人兴奋的新发展。
主要特点,改进
Hadoop 3.3.1 -性能改进
火花3.2现在使用Hadoop 3.3.1在默认情况下(而不是Hadoop 3.2.0之前)。你可能认为这并不适用于你(特别是如果你运行火花Kubernetes),但实际上Hadoop库中使用火花即使你不运行在一个Hadoop基础设施。特别是,火花时使用Hadoop库读取从一个对象存储(S3),所以这是重要的。
Hadoop 3.3.1释放带来了显著的性能改进S3A连接器(hadoop - 17400)。这些改进优化的性能s3清单和消除许多不必要的调用s3 API,因此减少的风险被扼杀了,一般改善火花从s3阅读时的性能。
另一个值得注意的变化是事实”魔法S3提交者”现在更易于使用和推荐作为默认,因为我们现在可以受益于这一事实S3支持强劲read-after-write 2020年12月以来全球一致性。火花3.2和Hadoop 3.3.1版本修正了一些错误和改进这个提交者显著的性能。
你现在可以使魔法提交者把星星之火配置标志(不是很多),<桶>就是你写的S3 bucket数据:“spark.hadoop.fs.s3a.bucket。<桶> .committer.magic.enabled”:“真正的”。
如果你失去了S3提交者是什么,我们建议阅读本文档,有点过时,但让一个伟大的介绍S3提交问题。还要注意,Hadoop维护人员正在一个类似的提交者的对象存储优化谷歌云计算和Azure。
自适应查询执行的性能改进
火花开发团队不断寻找方法来提高火花SQL的查询优化器的效率。查询优化器负责选择适当的连接方法,任务执行顺序和决定加入顺序的策略基于各种统计数据来自底层数据。
自适应查询执行这些优化技术之一,在火花3.0中首次发布。3.2与火花,自适应查询执行默认启用(你不需要配置启用了的标志),并成为兼容其他查询优化技术,如动态分区修剪,使它更强大。
AQE允许查询优化器在某些阶段收集数据完成后,重建查询计划基于查询执行的新收集的统计数据,并应用这些更改查询计划中应用程序的执行。
自适应查询执行SQL查询优化火花虽然它正在运行。
数据源V2总叠加——性能改进
当火花从任何读取数据存储(铺文件对象存储,数据仓库,HDFS, SQL数据库…),它使用一个库,实现一个特定的API。火花2.3在2018年发布,新的API(称为数据源V2)被释放,和主要公共数据连接器(读者和作者)移植到它。基本的API (V1)只允许火花在一个分布式的方式读/写数据。新的API (V2)使很多优化在数据源层如阅读较少的数据通过过滤器“向下”的数据源。
火花3.2,你现在可以受益于从查询谓词下推包含一个聚合过滤器或选择一个聚合列。给一个具体的和简单的例子,让火花计算拼花文件中的行数将会更快,火花可以直接读取它的元数据文件,而不是扫描(见火星- 35511)。
支持聚合功能包括数、总和、最小、最大和平均水平。总叠加,火花可以应用聚合谓词到数据源,减少文件通过网络阅读和重组。如果查询中包含多个聚合和聚集支持的数据源,火花将压低所有的总量。
注意,如果您选择一个总*和维列*,总不会被下推到数据源。还需注意,这种优化将看到最影响当使用镶花或δ作为数据源。
对熊猫考拉——PySpark改进用户
熊猫考拉,火花实现流行的图书馆,已经越来越受欢迎的首选PySpark转换库。3.2与火花,考拉现在将与火花捆绑在默认情况下,它不需要安装额外的库。目的是让火花甚至更容易人用来运行在单个machien纯python代码,事实上,现在更快运行相同的代码使用PySpark比使用纯熊猫,即使你不运行的分布式功能火花(多亏了许多优化建于火花SQL)。
Api的变化
以前,如果你想切换熊猫,考拉,或引发功能,您需要应用转换函数来获得适当的DataFrame对象允许您利用特定的转换。火花3.2的发布,现在熊猫运行本地火花和包含在PySpark API。
上面的单元格描述了利用熊猫的工作流功能,创建一个熊猫DataFrame和转换成一个火花DataFrame。这个操作的效率特别低,你将收集整个的测试。csv”你的驱动你的火花开始操作之前,放弃的一个关键的好处火花,分布式处理。此外,代码本身变得乏味,我们需要切换库为了利用和功能的转换,我们渴望我们的应用程序。
在火花3.2中,您可以导入read_csv函数直接从PySpark API和接收一个火花DataFrame,删除需要两库之间来回转换。此外,read_csv函数现在使用火花作为后端实现,意味着你将受益于并行读取和处理csv到内存中。这个实现不仅允许开发人员生产清洁PySpark应用程序,但它也将消除混乱执行哪些操作只有在火花司机和分布在执行人。
可视化
熊猫标准的Python实现包装matplotlib作为默认绘制图书馆。3.2、PySpark熊猫用途情节默认情况下。情节提供了大量的改进,如原生支持交互式图形的放大和缩小,以及验算情节视图使用火花。如果你选择切换回matplotlib,您可以指定PySpark策划火花配置库。
RocksDB——火花流改进
标准的火花流配置支持有状态操作如流聚合或连接通过存储在内存中保存的值。对于一些流负载高基数,在内存中存储状态可能不足,导致应用程序泄漏数据到磁盘,影响性能。
火花现在支持RocksDB的持久性键值存储性能状态管理。RocksDB提供显著提高查询性能和延迟与遗产相比,内存解决方案。运行与RocksDB火花应用程序添加以下配置设置:
“spark.sql.streaming.stateStore。providerClass org.apache.spark.sql.execution.streaming.state.RocksDbStateStoreProvider“:
Spark-on-Kubernetes改进
执行器故障原因在火花UI
火花UI现在在其执行人页面添加一个新列给你火花执行人死的原因。这不仅改善适用于所有用户,火花Spark-on-Kubernetes。对于Spark-on-Kubernetes用户来说,一个缺陷预防传播的错误代码是固定的,和一些额外的见解,如码头工人退出代码翻译成(一些)人类理解的东西。
遗嘱执行人重启Kubernetes持久性体积要求重用
在3.1版本中,引发了动态生成的能力,安装和删除持续的体积要求(pvc)火花Kubernetes工作负载,它基本上是卷装在你的火花豆荚,由Kubernetes,由物理云卷(比如一个EBS在AWS,磁盘丰富持久,或一个Azure磁盘)。看到我们的文档如果你想这样做对我们的平台。
如果一个执行人丢失由于现货杀死或失败(例如JVM运行OutOfMemory),成交量持续失去的同时执行程序pod死了,迫使火花应用程序验算失去工作(洗牌文件)。
火花3.2增加了PVC重用和洗牌复苏处理这个场景(火星- 35593)。如果遗嘱执行人或节点失去了在运行时,火花将保持持久卷声称最初与失去的执行人,请求一个新的从Kubernetes舱,并附上现有卷,这样珍贵的洗牌文件不会丢失,并引发可以恢复工作已经完成,而不是再计算。
此功能将大大提高Spark-on-Kubernetes的健壮性和效率在处理零星的执行器故障,以及促进现货/抢占式节点的使用,提供60% +节省成本而传统点播节点。这是一个巨大的胜利Spark-on-k8s用户!
结论
Apache 3.2火花为火花带来显著的性能改进所有用例——从火花SQL用户(AQE),熊猫开发者(考拉)和流媒体用户(RocksDB)。这也是另一个版本Spark-on-Kubernetes添加稳定和成熟的项目(正式投入使用以来引发3.1),如PVC重用健壮的方式解决的问题失去火花执行人在应用程序运行时。
我们期待显示这些影响你升级你的工作量3.2引发我们的平台。如果你没有一个客户,但迁移到Spark-on-Kubernetes感兴趣,订一个演示与我们!
