激进的速度对SQL查询数据砖:光子

格雷格Rahn:你好,欢迎来到今天的谈话,激进的速度对SQL查询数据砖:光子。我叫格雷格Rahn,和我是一个工作人员在砖产品经理。之后,我将加入了亚历克斯Behm,光子在砖项目的技术主管。
在今天的会议中,我们将向您介绍光子,光子的最新发展,讨论项目中接下来会发生什么,然后我们会总结这一切。
让我们先简单介绍光子。但首先,让我和你分享一些有趣的工作量趋势观察大量的客户数据砖。
首先企业快速移动,但一般数据移动得更快。这通常表现在团队花费更少的时间正确地建模数据,这经常会导致性能下降。两个具体的例子包括缺乏NOT NULL约束被列上定义,以及懒惰的数据类型选择。很容易选择的字符串,但是这真的可以消除的好处更具体的和优化的类型。
观察到的另一个趋势是一个数据生命周期模式的出现,让我总结一下。首先,着陆的原始数据,我们将称之为铜区。清洁和增加数据,将它移动到白银区,或符合区。然后最后,发布报告等数据表和骨料黄金区或模型的数据区。
这带来一个问题,“可能我们有灵活性和性能数据湖吗?在砖”,我们认为是可能的,但需要一些新的东西。
虽然这些趋势都是发生在砖工作负载,我们也有一个很常见的请求,SQL砖上的一等公民。这是正确的。从砖最大的问客户,比SQL支持的力量。
尽管砖经常一开始在一个组织等用例ETL、数据准备,和机器学习。很明显,方便的在一个地方的所有数据是SQL角色极具吸引力。然而,这些SQL形象不仅是想要SQL作为一等公民,SQL语言方面的意义。他们也习惯于迅速查询返回。这是这个要求光子背后的想法诞生了。丰富和快速的SQL,本地数据。
为了进一步阐明SQL作为一流的公民对我们意味着什么砖,这意味着语法和SQL的行为。这就是为什么我们有一个很大的努力背后将火花SQL, ANSI SQL标准的兼容性。这也意味着性能。这个具体是因地制宜的光子。最后,熟悉SQL分析师角色的本地工作区中内建了平台。bob体育客户端下载那么,让我们看看光子。
光子是一个新的,100% Apache火花兼容查询引擎设计的速度和灵活性。是从头构建现代云硬件上提供最快的性能,对所有数据用例,是一个工程数据,数据科学、数据分析和机器学习。
现在让我们双击光子的高水平的细节。这是如何构建下一代查询引擎。光子是最快的性能在真实世界数据架构应用程序,不仅受欢迎的基准或合成工作负载,它是用c++编写提供最高水平的性能。它有自己的自定义构建JVM内存管理器来避免瓶颈。和它实现了最新的数据处理技术,包括向量化,提供并行数据,指导,和记忆水平,推进性能的局限性,我们可以从现代云硬件提取。
光子是完全兼容火花SQL,火花DataFrame api,这意味着它与现有的代码。所以没有厂商锁定。最终用户也完全透明的,所以不需要涉及或调用任何新东西,它只是是开箱即用的。
我们希望用光子来帮助优化所有数据用例和工作负载。今天,它支持SQL和DataFrame工作负载,和我们希望添加流和数据科学工作负载,和用例。
现在你可能在想,“为什么离开和建立一个新的查询引擎?“让我告诉你为什么。
这里是一个规范化的性能图的每一砖运行时版本,回到2016年的2.1。你可以清楚地看到,性能继续随时间而增加,但在相对较小的增量。注意,DBR性能从2021年的8.0版本,大约是3倍的速度比从2016年的2.1版本。但它花费了五年,3 x的性能。
现在,进入光子。的大门,光子是两倍DBR 8.0版本,因此6倍的速度比2.1版本。我们刚刚开始。这就是为什么我如此兴奋光子。现在,希望我让你兴奋光子的性能。
让我们挖的光子如何适合砖Lakehouse平台。bob体育客户端下载这张幻灯片的目的是澄清光子中胜任的地方,特别是由光子哪部分不受影响。让我们先看的生命周期查询。
首先,客户端提交一个查询引发司机。查询解析、分析、计划和优化,像往常一样使用催化剂。
然后,我们做过物理计划来确定哪些部分可以运行在光子。我们可以进行少量修改,光子的计划。例如,更改分类合并连接散列连接。但总的来说,计划的结构,包括联合订单将保持不变。
然后查询计划分解成原子单元的分布执行,称为任务。和每一个任务运行在线程和工人节点,然后作用于特定的分区的数据。在这个层次上,光子引擎工作。你可以把它作为替代火花舞台CodeGen,本地引擎实现。光子库加载到JVM,火花和光子通过JNI通信。所以在一个高水平,这就是光子无缝集成到引发运行时在砖。
现在让我们触及光子的主要特征。这是关键点,用户应该意识到运行时光子。首先,它是完全透明的直接用户和完全集成到火花。你的代码只会工作。然而,它的工作原理与光子速度。在操作中不支持在光子,它只是落回引发运行时。光子与火花的内存管理器集成协调洒在混合计划。火花和光子都配置为使用堆内存,内存压力下和相互协调。
光子使用本机代码。为什么本地代码?高性能Java应用程序通常使用堆内存和不安全的操作。如果是这样的话,为什么不使用c++,避免所有JVM的垃圾收集的问题和JIT问题?光子使小的改变计划,就像我提到的,转换分类合并连接到哈希连接。
今天,光子只支持散列连接,因为一般来说,它是更好的性能。与舞台CodeGen,操作者可以融合或组合在一起,光子保留算子边界,因此能够提供非常丰富的度量在每个运营商的基础上,使其更容易理解资源消耗和瓶颈,所以撞到光子的关键方面。
现在我要把它交给亚历克斯,谁是在光子技术主管,谁来和你讨论更多的光子善良。亚历克斯,交给你了。

亚历克斯Behm:谢谢格雷格。既然我们已经分享什么是光子,背后的动机,砖平台及其带来的价值,让我们深入光子的最新发展。bob体育客户端下载我们的开发集中在三个领域,生产准备,查询范围和性能。
我们一直在努力使光子更有弹性,通过溢出内存压力下中间状态,以及使用不同的测试策略,尝试错误,当然,观察在真正的工作负载,提高光子的行为如何。
如你所知,光子从头开发,因此还没有原生支持所有SQL操作。最常见的运营商,数据类型和内置函数实现,我们继续扩大覆盖范围,所以更多的查询可以享受光子速度。
性能始终是最重要的思想和有趣的工作,但是有一种东西over-optimization。所以,我们尽量不要忘乎所以,优先考虑常见的使用模式。
更深,警告之前,在下面的幻灯片,我将分享一些性能数据集中在特定的业务控制设置。这些微基准测试不一定反映现实世界中,端到端性能。例如,对于测量性能的内置函数,我们试图消除扫描和I / O时间基准。
我们最近取得了一个重要的里程碑为光子的弹性。我们已经完成了将支持所有重要的运营商,包括通过洗牌,哈希聚合和散列连接。这意味着光子可以处理非常大的输入通过溢出中间状态到外部存储,当内存压力。我们在2-5X范围基准测试加速砖运行时没有光子。
给你一种感觉的溢出是如何工作的,以及它是如何从砖是不同的比你可能知道今天,我想介绍溢散列连接算法。
一个散列连接可以计算加入合适的平等条件的结果。它通过构建哈希索引一个连接输入,然后探索索引与其他连接的输入。
我们将讨论如何构建调查阶段被修改以支持溢出。在构建阶段,这是一个固定数量的分区前期,并将每个构建行分配给一个分区,桶散列索引结构指向条目在这些分区。
内存压力下的想法是,我们可以释放内存,一个分区,立即降低优雅比东西撒了一地。在构建阶段,建立行属于泄漏立即溢出到磁盘分区。我们继续,直到建立输入被消耗。现在我们已经建立了一个部分的内存,和部分溢散列索引。
我们现在继续探测阶段,我们使用其他加入输入的行。探针行匹配内存常驻分区被承认为结果。探测器相匹配的行了分区也洒了。对于每个泄漏分区,我们有一组构建行和一组探测器的行。
我们消耗探头输入后,我们可以扔掉内存分区,因为我们已经加入并承认所有探测器可以匹配的行。所以接下来,我们选择一个溢出的分区、重复连接过程使用了构建和探针加入行作为输入。这意味着我们读了构建行,分区,根据需要和泄漏分区之前一样。我们应用该方案递归直到所有泄漏分区已被处理。
理智的看待这个问题,让我们来比较一下行为的光子,光子和砖。对于大型连接、火花使用分类合并连接,光子喜欢散列连接。
与分类合并连接,我们需要缓冲连接输入和排序。并行运行,因此可能增加内存压力。完全避免溢出,输入需要装入内存。如果我们有泄漏,排序算法需要将整个输入。
对比,我们只是讨论,散列连接。首先,我们只需要缓冲一个输入,希望小到一个哈希表。如果我们有,我们可以这样做,一次分区,在场景完全降低最多,但并不是所有构建数据符合内存。最后,我们使用技巧,比如扭转构建调查网站当递归地处理溢出的分区,加速加入。
在同一静脉硬化,我想给你一个了解我们的测试工具包,极大地帮助我们。我们有几个目标,测试。显然我们想要找到错误,但我们也想把微妙的火花,光子之间的行为差异,以确保完整的兼容性。我们还测试极端发现系统的限制,我们可以防范。
除了通常的单元测试和集成测试,我们发现模糊测试是非常有效的。我们构建工具来生成随机数据,把随机的查询系统,以及代码插装随机触发错误路径,以确保优雅的复苏异常情况。
我们也可以模拟内存压力,通过随机要求运营商泄漏。我们也使用铿锵声/ LLVM工具链,有一些巧妙的工具如地址和洗手液未定义行为,甚至可以结合模糊方法。
接下来我将总结我们致力于增加功能覆盖率。今天,光子支持最常见的数据类型操作符,和内置的功能。例如,我们可以运行过滤器,项目洗牌,加入总联盟等标量数据整数,字符串,小数,等等。
内置函数,你可以预期的比较,算术,投下,条件,以及常见的日期和字符串函数支持。我们正在积极努力增加对数组和地图数据类型的支持。和我们计划调查排序和窗口函数,以及udf在不太遥远的未来。当然,有一个长尾的内置函数,我们将继续蚕食。
在过去的两个季度,我们翻了一番下来努力支持更多的日期和时间戳函数,因为,意料之中的是,他们经常发生在真正的工作负载。我很高兴地报告,到目前为止,我们取得了95%的覆盖率,希望我们很快就会达到100%。
如果你还没有和我一样兴奋,这里有一些微基准测试。这个图表显示了几个常见的微基准测试日期功能,砖运行时相比,有或没有光子。酒吧显示多少次光子速度比砖没有光子。我们看到了加速效果会相当可观。举个例子,有一个离群值高达37倍加速,但是很多功能至少5 - 10倍。其中有通常的嫌疑人,日期的函数提取部分像月,一天,像树干日期和其他常见功能。这些加速通过仔细的工程和优化一般情况下喜欢UTC时区,这是默认时区。
另一个主要领域的发展已经添加支持嵌套类型,即结构体、数组,和地图,我们发现很受欢迎在我们的客户基础。今天的状态是,结构是完全支持,包括读和写。和数组和地图在积极开发。基本投影阵列和地图,以及常见的函数是在实验室里工作,我们将继续与一长串的内置函数在这些类型。
让我们看看数字这一特性。和之前一样,这张图表显示了不同的内置函数,光子加速实现这一次集中在嵌套类型。最常见的功能是,GetStruckField光子比非光子超过40倍。我也高兴看到方便StringSplit函数,其中最大的改进。这些操作是更自然的实现在矢量化引擎像光子一样,但是也有细致的工程和优化这些数字背后的常见使用模式。
到目前为止,我们主要关注的是读操作,但光子照耀的另一个领域是写操作,特别是光子可以加快写三角洲和拼花表。它是有意义的。δ使用柱状数据格式,光子作为柱状查询引擎,他们是一个不错的选择。和典型的用加速我们看到,当然同意。相对加速甚至会增加更大的表。
这种想法写入数据后,我们还增加了光子支持删除、更新和合并命令。它们不仅受益于写作能力,但核心业务,加入和聚合等诉讼权利也在加速。典型的加速效果我们见过好几次的范围,端到端。
最后但并非最不重要,积极开发的另一个领域的火花社区,以及光子,正朝着符合行为标准的SQL函数,就像失败的查询溢出。我们的目标是为SQL用户提供熟悉的语义。
这样总结了不同覆盖地区今天光子的存在。这是今天我们工作的总结,并在不久的将来。
如您所料,一个新兴的项目,我们将添加更多的覆盖每一个版本。所以一定要经常检查回来。
,我要把它交给格雷格。

格雷格Rahn:谢谢亚历克斯。令人惊奇的看到有多少光子报道团队已经建立。鉴于这一切伟大的报道,我可以想象,接下来是在每个人的心中,“今天我如何尝试光子?“我们潜水吧。
今年6月,光子将在砖上,两个地区的产品。首先,在砖的SQL。这是最简单的方法尝试光子使用SQL。你可以提供一个砖SQL的端点,使用SQL原生Redash接口,或连接表,或者权力BI,甚至你最喜欢自带食物工具通过ODBC或JDBC。砖SQL AWS和Azure是可用的。
如前所述,在光子还不支持某些窗口操作。所以要注意。
预览光子的另一种方法是在工作区中SQL数据工程,或ETL工作负载。可以通过配置与光子使集群。只是有一个小滑块或复选框,在UI中切换。我将向您展示一个屏幕截图的下一张幻灯片。然后你可以运行您的SQL或数据帧代码,在笔记本或一个JAR文件。光子在工作区中可用在AWS上开始,然后Azure GCP在未来将被添加。
需要注意的两个关键领域,还不支持在光子的数据工程工作负载定义udf和流媒体业务。
现在,让我向你展示集群的光子切换工作区。
在创建集群UI,你可以看到,这里就这一个切换按钮,砖下运行时版本。当你切换,运行时版本,支持光子将上市,然后你可以选择合适的一个。
现在你可能想知道如果你给光子试图通过这些方法之一,“我怎么知道我的查询工作实际上是使用光子?“那么让我来告诉你怎么做。
让我们先从一个基本的查询简单计算总数和平均出行距离的供应商。在左边,你可以看到文本表示查询计划的火花。好好注意的运营商名称。在右边,你可以看到这个计划从光子相同的查询。现在一个敏锐的眼睛会注意到两件事。在光子有更多的业务计划,实际上,许多人开始“光子”这个词。这回到我前面提到的关于火花结合操作或融合的区别在舞台CodeGen,光子和保持清洁和谨慎的每个操作之间的界限。再一次,这样做的原因是光子的详细指标。
对于你们中那些更视觉动物,像我一样,你可以看看执行DAG的火花UI。像文本计划,您会注意到,光子光子从单词开始操作。但在这里,他们是不同颜色也不同于火花操作。黄色表示光子操作,和蓝色表示火花。当您单击并扩展它们,你可以看到丰富的指标,我们一直谈论。这是再一次,可能会更容易理解,性能问题或挑战,因为你有访问这些详细指标。
SQL的那些更形象,也更有可能使用砖SQL的用户界面,你可以找到一个稍微不同的表示从查询历史部分的计划。在砖SQL的用户界面,在左侧导航,点击历史。去找你的查询历史列表。在这个例子中,发现顶部。当你点击它时,这个查询详细信息框,右边将出现。然后你将不得不点击执行细节。然后在底部,你会看到一个光子的任务时间。
只是放大,我将向您展示,这是为这个查询任务细节。注意到98%的这个查询的任务时间是花在光子,这意味着基本上,光子惊人的报道了这个查询和大多数的执行是在光子。在这里,在光子数越高,越好。
现在,我已经向您展示了如何尝试光子,查询和阅读计划,我猜,接下来你在想的是,“只是光子有多快?“让我们看看。
我想分享一个客户和你的旅程。这个客户想使用砖来支持大量的SQL分析师。我们和他们一起工作对砖SQL的端点进行并发测试。大约一年前,他们开始了他们的旅程,并做了一些测试并发工作负载。那时,平均查询响应时间,只是在8秒。光子和砖工程团队的努力取得进步来提高这一数字。到2020年底,客户重新运行并发工作负载测试,并减少了21%的平均查询响应时间。他们非常高兴看到这种进步。但在现实中,他们稍高的期望,我们在砖。
就在本月,我们给了他们一个新的构建尝试,最新,最光子比特的工作量。他们看见一个额外降低29%与比特和查询平均响应时间。这意味着从最初的时机早在2020年6月,减少44%。
不用说,光子的铁杆粉丝,因为他们现在能够推出他们所有的SQL和BI服务用户,直接在砖上,而不需要任何数据,或依赖任何其他系统。
所以它不会是一个有趣的表现说话如果我未能给你义务TPC-DS性能图表。所以在这里。在这张图表中,我绘制查询加速光子带来99 DS查询3结核病比例因子。正如你所看到的,有一个范围从轻微的加速效果,在高端超过8倍。但大多数人属于用范围。这通常是我们所看到的大部分的工作负载。这种DS负载的平均查询加速2.5倍。
但也许比这更有趣的是,电源测试工作负载加速,所花费的时间运行这些查询端到端快3.7倍。这意味着通过使用光子这个工作负载运行,云基础设施成本就是27%的会是什么,如果我们不使用光子。
这真的说明光子带来的速度和效率。再一次,我们刚刚开始。他们说,你应该高调结束。所以,我总结一下今天的光子说话。
在这次演讲中,我们向您介绍了光子和砖建筑的动机。我们讨论了最近的进展,以及在光子接下来会发生什么。我们强调了一些性能结果从客户的角度来看,以及我们实验室的结果。我们还向您展示了如何把一些细节的光子,并深入查看查询执行计划,和理解底层光子操作。
所以最后,这里有一些相关的会谈,你可以了解更多关于光子在砖上。BOB低频彩
当然,回来在6月到www.neidfyre.com/try,你可以测试运行光子为自己,和经验它能带来惊人的性能对于SQL工作负载。
与此同时,我要感谢你出席这个演讲。现在,我们要带一些听众的提问。再次感谢。