查询生产工作负载和交互式数据分析经常重叠,即。多个查询共享部分的计算。这些裁员增加用户的处理时间和总成本。重用计算,许多大数据处理系统支持物化视图。然而,它是具有挑战性的手动选择常见的计算在给定的工作负载的大小和发展自然查询工作负载。在这次演讲中,我们将引发巡航,自动计算重用系统开发的火花。它可以自动检测重叠计算过去查询工作负载和启用自动实体化和重用在未来引发的SQL查询。
SparkCruise不需要从用户积极参与的物质化和重用应用自动在后台查询处理的一部分。我们可以执行所有这些步骤不改变引发的代码,从而展示火花的SQL引擎的可扩展性。火花巡航表明TPC-DS查询的总体运行时提高30%。我们的谈话将被分为三个部分。首先,我们将解释端到端系统设计,重点放在如何增加工作负载意识火花查询引擎。然后,我们将展示所有的步骤包括分析、反馈、实体化和重用在集群的火花。最后,我们将展示工作负载的见解笔记本。这个Python笔记本显示的信息查询工作负载在一个平面表的计划。这个表可以帮助用户和管理员了解他们的工作负载的特点,使SparkCruise的成本/收益的权衡。
——你好,每个人。这是一事。我是一个开发人员的火花团队在Azure数据。我主要的工作分析作为一个服务平台。bob体育客户端下载今天我们要看SparkCruise引发系统和自动计算重用,我们已经建立了。
这是一个疯狂的时间与大流行。我很高兴会议是虚拟的,我想感谢大家参加我们今天的会议。让我们快速回顾今天的议程。今天的谈话将会被分成了两个部分。今年上半年,我们要复习SparkCruise,自动计算系统,我们构建重用。我们将研究面临的问题、系统设计和演示它实际上是如何运作的。在这个演讲的第二部分,我们将会在一个工作负载的见解笔记本。它是一个工具,我们已经为你们建造能够分析SparkCruise是你的工作量是否能从中受益。——谢谢你,要不是。我们生活在一个时代,数据库管理员完全不知所措。 Traditionally the databases were located on premise. These systems had experienced database administrators who can tune the query workloads with sophisticated administrator tools. These installations also have offline cycles which can be used to schedule maintenance tasks such as collecting statistics or creating views.
今天,像Azure云提供商提供完全管理数据库服务。在这种基于云的数据服务,用户可以简单地指向自己的数据集,并开始查询,而无需支付任何前期成本。这导致了巨大的用户数量的增加和查询工作负载的大小。
尽管在此设置云数据库管理员和开发人员可以调优查询工作负载,但是他们缺乏工具来分析和优化等巨大的工作量。还要注意,没有离线周期serverless系统可用于运行维护任务,比如更新视图。
我们已经投入了大量建设优秀的查询优化器。火花本身添加基于成本的优化器,2017年自适应查询执行3.0火花。但是,这些查询优化器处理一个查询。这是因为查询被认为是相互独立的。和相同的一组规则应用在每一个时间。
然而,在生产工作负载的查询与彼此互动。查询可以共享计算,可以依赖的执行顺序。例如,下一个查询前面的查询完成后才可以开始。和某些查询工作负载可以共享一个共同的模板。因此,我们认为,我们应该优化工作负载,而不是单独的查询。还有很多在工作负载优化机会。优化工作负载也会降低用户的总成本。
现在让这趟旅程从查询优化器到工作负载优化器,我们需要一个工作负载反馈循环。我们可以学习模式从过去的将来再次查询工作负载和应用它们。我们的系统还应该能够适应不断变化的工作负载。因此我们需要一个持续的反馈回路优化器可以对工作负载的变化作出反应。
在SparkCruise系统,我们增加了一个火花查询引擎的工作负载反馈回路。
现在,让我们看一个特定的工作负载优化问题,计算重用的问题。在这个问题上,部分计算重复在查询。例如,在这里,我们看到两个查询Q1和Q2,处理相同的数据集。这两个查询共享一个共同的过滤器和一个共同的加入。我们的分析显示,95%的查询在TPC-DS重叠与至少一个其他查询。我们得到如此高的比例TPC-DS重叠的工作量,因为它有许多查询在同一组数据或在同一组表。
我们现在分析TPC-DS工作负载在稍后讨论。同样,在生产中我们观察到60%的查询有重叠。
挑战美国在应用计算重用是不断发展的。
例如,工作负载都不是固定的而是反复出现。在重复工作量,提交查询是在一个固定的频率变化的数据,可能有不同的参数。我们解决了这个问题通过实现两个不同的查询散列。我们的研究论文有关于它们的实现细节。
现在,让我们看看SparkCruise系统是如何工作的。考虑相同的查询工作负载与常见的连接操作。SparkCruise高实用程序可以自动找到这样的重复计算。
现在一旦SparkCruise打开,再次运行第一个查询,可能是一个新版本的数据集,查询会自动实现连接操作的结果。
然后第二个查询运行时可以直接读取物化的输出,而不是计算一遍。注意,这些步骤需要任何活跃的用户干预。SparkCruise也健壮的小查询工作负载的变化。例如,在这个工作负载过滤器改变日期从6月26日1到6月27日一天2。但SparkCruise成功能够处理这些类型的变化。
现在,让我们看看SparkCruise使自动计算的组件重用成为可能。
首先,查询提交给服务器火花。我们添加了听众,可以登录查询计划注释sub-plans的标识符。
这些记录查询计划传递给表生成一个工作负载。
在这个生成工作负载表我们运行视图选择算法来选择常见的计算效用高。
这组然后反馈优化器选择计算。我们已经启用了优化器火花的扩展特性。我们用两个规则补充传统的火花优化器。一个规则具体化和另一个规则以便重用。
这些规则可以直接读取反馈并将它们应用在一个在线时尚再次提交查询。现在,要不是将演示SparkCruise Azure突触。——谢谢你的阿布。在今天的演示,我们首先有一个我们已经跑前的查询工作负载运行并收集工作负载的应用程序日志。后,我们会经过第二步的分析,对这些应用程序日志并识别潜在的查询,可以重用。最后我们重新运行相同的查询,我们看看之间的比较与SparkCruise启用并没有计划,这是与实体化和重用。所以,让我们看一下演示。我在这里有一个笔记本在Azure突触分析工作区目前在公共预览为我们的客户提供一个无限的分析经验。我跑这个笔记本就在几分钟前。这是一个简单的笔记本,我们读一些示例数据,运行一组查询。 We do a count and some projections and filters. We’ll take a closer look at this notebook in just a few minutes. I also have the Spark history server open for this notebook session which we’ll use as a reference after we’ve applied SparkCruise. Now, we have a Spark job that we have and we will make available for users and this job is to analyze the application logs and provide a feedback file with queries which can be materialized and reused. I’m gonna go ahead and run this job against the same workspace and while this is running I’ll walk you through exactly what we expect to see.
反馈文件的生成由于这份工作,如果我运行一个查询,已经运行结果首次被物化视图和后续的相同的查询我们可以重用结果自动。根据您的工作负载和频率数据变化可以运行分析工作所需的频率。这可以每天,每周或每月。反馈文件的位置可以提供作为这项工作的一部分,在我的例子中,我提供了一个位置是主存储器的一部分帐户是与我的工作还可以浏览相关权利。一旦这项工作运行结束之后我们会看到一个反馈文件的生成。我们还可以提供自定义位置生成我们想要的视图物化。所以,让我们把这几秒。好吧。那么我们现在的文件,这是将用于随后的运行。让我继续,重新运行同样的工作。
它运行时,让我们仔细看看笔记本。所以我有一个CSV文件与一些示例表读取和写入到临时视图。还有一串火花我运行的SQL查询。第一个是选择计数*。你看到有两个事件。这样做的原因是,第一次我反馈的基础上运行这个文件我们会知道我们看到这种查询过去,我们决定在这里实现的第二个实例正在运行的相同查询我们可以重用查询结果。同样的,当我第一次运行这个是选择不同的市场,我的项目的一个列,querytime像11过滤器的应用,我们将看到,这个过滤器被应用在过去我们会决定实现滤波器的结果。所以当我运行第二个查询预计不同的列,但相同的过滤器我们会使用现有的物化结果上运行该查询。让我们给这几秒,我们就可以看看之间的区别已经生成的查询计划旧的工作,新的工作。让我拉出来。 This is going to be the old job which is one the right side and this is the currently executing job. Let’s give this a few more seconds to finish running.
的第一个实例计算已经完成。现在发生的第二个实例计算。我们从示例表,选择不同的市场运行querytime像11。
其次是选择国家和国家querytime像11。
好吧。让我们停止这个会话和火花历史观服务器会话。和提醒你,旧的工作是在右边和新的火花历史服务器将在左边。
太好了。这是申请的笔记本就跑。
让我们看看收集的实例。这就是我们看到的工作,我要选择收集的新工作。提醒你,右边是年长的工作和一个左边是新工作。所以在右边,我们看到,我们必须扫描和聚合与左边的扫描以及聚合一步跳过我们可以重用现有的视图。同样地,我们来看看另一个行动,我们表演的节目的一部分应用过滤器。
再次来到这里,我们可以看到扫描和过滤器已经跳过了,我们只使用一个现有的视图。需要注意的另一件事是,SparkCruise非常健壮的小过滤器等的变化,如果你改变querytime 12,应该很好,你不需要重新运行分析工作,因为它是一个经常性的工作,它只是一个过滤器的变化,因为也许你有日常工作或每小时的工作我们将仍然能够实现自动和重用视图。和另一种方法做这个作为工作负载的一部分可以用笔记本和添加一个管道添加分析工作作为管道从突触的一部分。你还应该能够运行批处理作业的方式从IntelliJ我跑它或者你也可以创建一个火花工作并提交相同的工作定义。我们评估系统TPC-DS工作负载。TPC-DS工作负载由102查询。我们看到在这个阴谋与SparkCruise查询运行时间之间的比例,没有启用。的比率小于1意味着查询运行时启用了SparkCruise更快和红酒吧这里显示查询的比例。我们确实看到这些红酒吧,因为这些查询首先触及子查询这意味着他们支付实体化的开销成本,但我们看到,整体工作负载中有许多绿色的酒吧这意味着大多数的查询实际上受益于重用这些物化视图。
总体而言,我们看到一种进步30%的挂钟时间和CPU时间。
的第一部分我们今天的会议到此结束。我们看着一个免提计算重用系统的火花。
我们发现有一个工作负载反馈回路火花查询引擎,我想提到这些建造完全使用火花扩展点这意味着你不需要一个特殊叉的火花得到这个工作。它的工作。我们有这些自动应用。我会去阿布总结如何分析SparkCruise是你的工作量是否能从中受益。——谢谢你一事。我们看到SparkCruise可以降低整体成本计算工作负载的自动重用。启用此功能我们已经添加了一个工作负载反馈回路在火花查询引擎。SparkCruise可以选择高实用程序常见的计算和应用自动实体化和重用查询处理的一部分。,这一切都不需要任何更改在火花。用户可以添加我们的图书馆和一些配置参数设置为开始。
但是用户还想了解是否SparkCruise将有利于他们的工作量。一般来说,用户可以了解单个查询。但是很难分析完整的工作负载。
火花历史服务器也有一个很好的可视化单个查询但是没有地方我们可以看到在总工作量统计。因此为了解决这个问题,并通知用户有关裁员的工作负载和潜在的储蓄SparkCruise我们开发工作量的见解笔记本。
演示工作负载的见解笔记本之前,让我们举例说明工作负载在火花是什么样子。在火花,工作量包含应用程序中,一个应用程序包含查询逻辑计划和执行计划。这些实体也有元数据和指标。在一个工作负载随时间而变化的查询。我们将所有这些实体链接在一起来创建一个表格表示的工作负载。这个工作负载表可即时查询。
看到我们的见解可以来自这个工作负载表让我们去演示工作负载的见解的笔记本。工作负载的见解笔记本是一个互动的笔记本分析查询工作负载。我们使用Azure突触工作室的工作负载的见解笔记本。在这个演示中,我们将分析和见解来自TPC-DS工作负载。我们还将展示SparkCruise这个工作负载的好处。
工作负载分析工作所示SparkCruise演示创建一个查询工作负载的表格表示。第一步是加载表和选择的列表视图。
现在,让我们看一看表的一个子集。
表中的属性包括应用程序和查询级别信息,如查询执行时间、操作细节,签名识别sub-plans等指标行数和专属时间。每个运营商都有一行查询计划。例如,第一行是一个聚合算子。
我们现在可以开始查询工作负载表。
有多少查询和运营商在这个工作负载?它说,这种工作负载有102 3824查询和运营商。另一个问题,我的任务是,运营商工作负载的频率是什么?例如,有多少过滤器和加入我们这个工作负载?我们可以看到,我们有933过滤器和735连接。
注意,我们查询这个表使用SQL工作负载。我们可以很容易地想象这些表在Azure突触笔记本。
现在,让我们检查是否有冗余工作量。SparkCruise去除这些冗余的计算来实现性能提升。
在这个工作中,我们发现95 102查询与至少两个重叠查询非末端水平。这是预期因为TPC-DS工作量有许多相同的表的查询。
现在,让我们试着了解运营商重叠。所以我们组重叠计算由操作员的名字。在这个表中,第一列有运营商名称,第二列操作频率,第三列的重复计算,第四列有许多不同的重复计算。我们看到,97过滤器是重复了513次。还有18连接和10聚集共同之处。让我们去这个表的阴谋。
在这个工作负载,50%以上的过滤器是重复。因为连接和聚集经常出现在查询计划减少百分比是重复的。但它仍有可能有用重用他们的结果,因为他们通常更昂贵。令人鼓舞的是看到这些TPC-DS工作负载中冗余。接下来,我们试图确定与SparkCruise多少我们可以重用。
这个表总结了我们的视图选择算法的结果。视图选择算法选择了18个过滤器是重复138次,12连接和其他运营商的重用。我们也报告收益的计算成本和物化成本/视图。这种分析可以用来确定冗余在任何负载。有额外的示例查询在这个笔记本可以,例如,
报告的选择性过滤器。
或者找到尺寸的中间打乱。
甚至识别重复工作独立作业提交系统的工作负载。这笔记本是可扩展的,用户可以编写自己的自定义查询。我们希望这个笔记本可以帮助你回答问题查询工作负载。谢谢你看这个演示。感谢您的收看见解笔记本的演示。我们希望你尝试SparkCruise感到兴奋和洞察力的笔记本在你的查询工作负载。SparkCruise可用作为实验功能Azure HDInsight,它很快就会发布Azure突触。如果你想知道更多细节关于这个SparkCruise系统请参阅我们的论文中列出这张幻灯片或直接与我们联系。
微软
阿布罗伊是灰色系统实验室的研究工程师(GSL)在微软。他的研究集中在改善大云中的数据查询引擎的性能。在加入GSL之前,他是一个研究生研究员在马萨诸塞大学阿默斯特数据库组。作为论文的一部分,他与纽约基因组中心合作建立一个大数据平台对基因组数据管道。bob体育客户端下载最终,他希望他的作品能使数据处理资源更快和更高效的终端用户。
微软
要不是Gomatam是一个软件工程师在微软Azure数据。微软之前,她曾在构建一个AI和ML平台签证。bob体育客户端下载一事已经完成了她从宾夕法尼亚州立大学计算机科学硕士学位。她的利益建立在云级别Analytics-as-a-Service平台和大数据系统。bob体育客户端下载