SQL性能改进一眼就在Apache 3.0火花

下载幻灯片

这个演讲解释了火花3.0可以提高SQL应用程序的性能。火花3.0提供了许多性能特征,如动态分区和增强的叠加。每个人都可以提高不同类型的SQL应用程序的性能。由于功能的数量很大,这不是应用程序开发人员容易理解这些特性。这个演讲简要解释这些特性的示例程序并解释它是如何工作的以及如何提高性能。

这里有外卖的谈话:

  1. 什么优化的SQL特性引发3.0支持。
  2. 3.0项目火花可以加速。

看更多的火花+人工智能会话

免费试着砖

视频记录

——早上好,下午和晚上,取决于你在哪里看。感谢各位出席今天的会议,虽然许多并行会话。我的名字叫Kazuaki Ishizaki。今天,我想谈论的简要概述Apache火花3.0改进性能,您的SQL应用程序。

我把这个演讲我SlideShare这个演讲之后。让我介绍一下我自己。我IBM研究院研究员,东京。

关于我的——Kazuaki Ishizaki

我的专长是编译器优化。两年前我成为了一名提交者在Apache火花。

我已经工作了SQL包。特别是,整个舞台与Java虚拟机的协调和互动。我一直在为IBM Java虚拟机工作了20多年,1996年。特别是,我负责研究和开发Java即时编译器。

火花3.0

3.0火花,我们等待很久火花2.4已经发布。

这里有重大变化引发3.0。SQL的性能提升,我个人选择。火花3.0改进与开发人员交流。引入新的动态优化没有手动参数调优。更多的催化剂,应用优化和更新基础设施、Java和Scala。让我们看看近代史的Apache引发释放。

当火花2.4发布?

让我们回到2018年底。社区引发2.4在2018年11月发布。

去年我们预期什么?

在最后火花峰会在旧金山,Kyenote,这里有一个公告,火花3.0预计今年晚些时候,这意味着2019年。

不幸的是,它并没有真正发生。

火花3.0看起来真实

相反,2019年年底,该委员会是火花的预览版3.0。后一年后,火花3.0被释放了。

祝贺你,火花3.0已经发布,今年六月初。

社区工作引发的3.0版本

所以社区广泛工作释放引发3.0。大约有3500个问题,社区报告,包括新功能改进和错误修复。

很多变化为1.5年

3500年,很难理解的新SQL性能改进。在这个火花峰会上,有多个会话来解释,介绍和深度潜水火花3.0的新特性。

这会议指导您了解的新SQL性能。这里的七个主要变化从我的角度来看。

七个主要变化为SQL性能1。新的解释格式

所以请投票,你感兴趣的物品。在一分钟内。

很明显,还有其他的许多变化。如果你感兴趣的其他变化,所以请加入其他会话,纠正他们。

所以,这七个变化可以分为四个方面,我已经在这个会话交谈。前两个,新解释格式和所有类型的加入提示。他们是相关的交互与开发人员理解和改进性能。项目3和4是动态优化没有手动参数调优。项目5和6是催化剂改进、优化,应用于SQL程序扩大范围的催化剂。最后一项是在Scala和Java版本更新。这是因为火花2.4支持他们的旧版本。

什么是重要的提高性能?=»了解查询优化

所以,首先,让我谈谈新的解释格式。

那么,什么是重要的提高SQL应用程序的性能?是非常重要的,了解你的查询优化。

要理解一个查询计划,显然要轻松地重做一遍。

读一个查询计划

这是一个简单的查询。让我们来看看这个查询计划显示在火花2.4和3.0。

不容易读一个查询计划引发2.4

2.4火花,当解释执行命令,显示的查询计划太长了。一行太忙,这是因为一行有很多属性。不幸的是,它是不容易理解。

容易阅读3.0火花的查询计划

因此引发3.0引入了新的选择,格式。显示查询两个部分,第一部分是一组操作符。第二部分是一组属性。在第一部分,它使我们容易理解一眼就将执行什么操作。

如果你想看到的细节信息,如每个操作的输入和输出。

你可以看到属性为每个操作部分在第二部分。例如,您可以连接第一部分和第二部分之间使用数量。例如,第一,二号人物。所以让我们去第二个改变。

只有一个连接类型可用于火花2

这是一个扩展的加入提示。

火花2.4,我们可以设置广播加入提示催化剂6,作为连接类型,我们并不期望。

所有的连接类型可用于一个提示

从火花3.0,我们可以设置任何加入类型作为一个提示,如果催化剂选择作为联合类型,我们不希望。

下面是例子如何指定加入提示在SQL或DataPrep程序。

所以它是很重要的,很容易理解查询计划知道加入催化剂类型被选中。如果部分不合适,你可以建议使用这个特性更好的连接类型。

七个主要变化为SQL性能1。

让我们去下一个类别。

自动调优参数加入和增加

自适应查询优化。这可以通过使用运行时自动调整三种类型的参数统计信息而异径接头的数量。下一个是连接策略。最后一个是分区的数量加入倾斜。他们自动完成没有run-by-run调谐特性,用手。根据我研究的数据,该查询DPCDS查询优化可以实现良好的性能改进。

使用预设数量的减少引发2.4

这是一个自动的还原剂。

这是一个很过去的项目。火花2.4确定spark.sql还原剂使用属性的数量。suffle分区。

如果你想问五种键组合,五个还原剂将推出五分区分区大小无关。

因此,在每个还原剂分配分区可能会导致公正的工作负载。例如,减速器0,很快将完成,这是因为分区0,很小。另一方面,减速器3需要多少时间。总执行时间是由减速器3,显然,这是低效的。这是因为4 0和减速机减速机有很多空闲时间,而其他还原剂是忙碌的。

3.0调整引发的还原剂

所以在火花3.0,选择数字的还原剂来满足平均分区大小。在这种情况下,火花3.0将推出三种还原剂。一个减速机有3个分区。没有所有减速机需要同样的时间。这是高效相比以前的情况。这是因为将做同样的事情。三个减速机和五个还原剂。

要启用这个特性,我们需要设置这两个属性在这些幻灯片的底部。

2.4静态选择加入战略火花

下一个选择加入策略。火花2.4决定加入策略基于静态信息,如表大小,100 g或80 g。

在查询优化时间,过滤结果的大小,表2是未知的。因此,在这种情况下选择排序合并连接。

3.0动态更改加入战略火花

火花3.0基于运行时自动加入战略变化等信息,过滤结果的大小。在这个例子中,火花3.0应用优化基于运行时动态信息,过滤结果的大小。

在这种情况下,滤波器的结果非常小。

引发的变化加入策略从排序合并连接,广播加入。作为结果,总执行时间将会减少。这是因为两个排序操作消除。要启用这个特性,我们需要设置底部的财产。

倾斜连接是缓慢在火花2.4 =连接时间是由处理最大的分区

最后一个是应用优化加入倾斜。在火花2.4,天真地在连接时创建分区。因此,有时像分区2发生倾斜。这是因为,总时间是由处理分区2。这是最大的分区加入。

倾斜在火花加入快3.0 =大分区分为多个分区

在火花3.0,大分区分裂为多个分区大小更小。现在分区3极没有主宰的总时间。因此,总时间会减少。因此,紫色是短相比空间。所以火花自动复制分区对应分割分区。轻微调整,手动运行,这种决定,分裂和重复执行底部设置这两个属性。

七个主要变化为SQL性能1。

让我们去另一个动态特性。

动态分区修剪

因此,动态分区修剪可以减少I / O访问通过避免不必要的阅读使用建立压低分区。修剪是自动操作数。

根据报告,在过去的火花AI在欧洲峰会,这可以达到DPCDS查询的性能改进。

天真的广播散列连接在火花2.4«大表中所有的数据读取

这是一个概述2.4天真广播散列连接的火花。

在这种情况下,所有的数据,表读取。

过滤器的结果,表小,播放。然后,加入发生播出。

既然其他表大非常巨大,在左边的部分,大量的I / O发生和浪费很多的时间由于阅读和在连接时使用的数据。

3.0删除数据和动态过滤火花

动态分区过滤器允许表大执行建立压低来避免不必要的阅读数据。

动态过滤信息发送到广播数据。基于过滤操作的动态过滤信息在右边。当读取表大,压低是正直的基于动态过滤信息。最后,只有从表中读取所需的分区。

它基本上可以做很多不必要的数据读取,然后我们可以改进这个查询的性能。

动态分区修剪的例子

这是一个例子的动态分区修剪。正如你所看到的,在物理计划,表大修剪使用动态信息,在分区过滤器,用蓝色。此信息用于压低拼花为已读。因此,表大可以减少被读取的数据量。

七个主要变化为SQL性能1。

让我们去其他类别。催化剂的改进有关嵌套列。

2.4嵌套列修剪火花

关于嵌套列第一个改进,是一个列修剪。列修剪可以从拼花必要只读列列。2.4火花,列上修剪工作等一些操作限制。正如你可以看到,在这些嵌套的第一列,在列两个,蓝色是阅读。我们可以成功避免阅读不必要的数据列,第二列在两列。

实现列上修剪嵌套列在火花特设2.4。例如,它不作为运营商,比如重新分区。正如你所看到的,在底部,大多数列是阅读和重新分区。重新分区后,进行修剪。当我们比较两种情况下,底部是低效的。这是因为,下一个读取两列与上一个相比。所以上面的一个,读只需要一列。

3.0推广嵌套列修剪火花

所以火花3.0选择这个问题。火花3.0可以应用嵌套列列修剪与任何操作。它可以提高性能对任何操作列修剪。

嵌套列修剪的例子

下面是例子计划列修剪。如您所见,大多数查询限制下进行重新分区。ReadSchema在铺有两列,第一列。因此,拼花将只读一列。

我们可以减少大量的I / O,避免不必要的数据读取。

2.4没有嵌套列叠加火花

另一个改进的嵌套列是压低拼花、兽人等。

在火花2.4,压低适用于non-nested列如列。小的意思是橙色。然而,它并不为嵌套列如列两个工作。正如你所看到的,查询计划,降低过滤器没有关于列两个条件,一个等于100。因此,所有分区在火花从铺读取列号2.4。

火花3.0修复这个问题。压低拼花和兽人适用于嵌套列。正如你所看到的蓝色,蓝色博览会通过拼花,然后拼花可以应用谓词下推。所以拼花不发送所有数据引发,但发送所有必要的数据分区的列。因此,我们可以提高性能相比,最近压低在之前的阶段。所以,一般来说,使用嵌套列在复杂和大型的模式。它会有用的处理复杂和大型数据在你的用例。你可以改善这种情况下的性能。

七个SQL性能的主要变化

下一个是改进复杂的聚合。

2.4复杂的聚合是缓慢的火花

在火花2.4,一个复杂的聚合查询很慢。这是因为,查询不转化为本机代码。例如,它发生在DPCDS查询。为什么会发生?

SQL是如何翻译hative代码

这是一个快速概述如何查询翻译成原生代码。给定查询翻译成Java代码的火花的查询优化催化剂。然后在OpenJDK HotSpot编译器将Java代码转换为本机代码。

然而,如果Java代码太大,HotSpot编译器放弃生成本机代码的性能不是很好。

让小聚合Java代码

火花3.0修复这个问题,通过聚合Java代码小。火花3.0分裂大Java方法成小方法。

HotSpot编译器可以为多个小方法生成本地代码。因此,性能得到了改进而引发2.4。

小聚合的例子代码

这是一个示例程序来执行平均函数到50列。

现在,生成的代码大小很小可以看到蓝色的。

所有这些方法8000磅的Java字节码方法。

所有的方法将被使用HotSpot编译器翻译成本机方法。

当我们禁用此功能,大小超过8000可以看到红色部分。HotSpot编译器生成的本地代码不会。

因此,性能不是很好相比,上述情况。

七个SQL性能的主要变化

最后,让我谈谈更新Scala和Java。

支持新版本的语言

2.4火花,Java 8和Scala 2.11通常是支持。

从3.0火花,Java 11和Scala 2.12通常支持。对本地Java 11有很大改进协调和垃圾修正。因此,在通用的性能将得到改善。从维护视图,OpenJDK 11是一个长期的,支持的版本。它将在2026年支持。

在Scala, Scala 2.12利用新特性的Java 8。

这是好的比Scala 2.11。

外卖

这是一个外卖,火花3.0引入了许多功能

一年半。从我的角度来看,这七个功能,帮助提高SQL应用程序的性能。如果你想重新审视这个演讲,请访问这个URL SlideShare明天。这个演讲后我将把我的演讲。

资源

所以我把一些资源,良好的阅读,

在博客条目和表示。

看更多的火花+人工智能会话

免费试着砖
«回来
关于Kazuaki Ishizaki

IBM

Kazuaki Ishizaki博士是一个高级技术人员在IBM研究——东京。他有超过25年的经验进行研究和开发动态编译器的Java和其他语言。他是一个专家在编译器优化,运行时系统和并行处理。他一直在IBM Java即时编译器和虚拟机从Java JDK 1.0最近。他的研究集中在如何系统软件可以自动使程序员能够利用硬件加速器在高级语言和框架。他是一个Apache火花提交者,为SQL组件工作。他是ACM杰出的成员。