数据库SQL查询的基本速度:Photon Under the Hood

格雷格·拉恩:大家好，欢迎来到今天的演讲，数据库SQL查询的极速:引擎盖下的光子。我叫Greg Rahn，是Databricks公司的产品经理。稍后，Alex Behm将加入我的行列，他是Databricks公司光子项目的技术主管。
在今天的会议中，我们将向您介绍Photon，讨论Photon的最新发展，向您展示项目的下一步，然后我们将总结这一切。
让我们从快速介绍光子开始。但首先，让我与您分享一些有趣的工作负载趋势，这些趋势是从Databricks的大量客户身上观察到的。
首先，企业发展得很快，但总体而言，数据发展得更快。这通常表现为团队花更少的时间正确地建模数据，这经常导致更差的性能。两个具体的例子包括在列上没有定义NOT NULL约束，以及惰性数据类型选择。一切都选择字符串是很容易的，但这确实消除了更具体和优化类型的好处。
观察到的另一个趋势是数据生命周期模式的出现，我可以这样总结。首先，登陆原始数据和我们所说的青铜区。然后，清理和增加数据，将其移动到银色区域或一致性区域。最后，将报表表和聚合等数据发布到Gold区域或Model data区域。
这给我们带来了一个问题，“我们能在数据湖上同时拥有敏捷性和性能吗?”在Databricks，我们相信这是可能的，但这需要一些新的东西。
当这些趋势发生在Databricks工作负载上时，我们也有一个非常常见的请求，SQL是Databricks上的一等公民。这是正确的。Databricks客户提出的最大的一个问题是，除了SQL支持之外，它的强度如何。
而Databricks通常在组织中开始用于ETL或数据准备和机器学习等用例。显然，将所有数据放在一个地方的便利性对SQL角色极具吸引力。然而，那些SQL角色不仅仅是想要拥有SQL作为一等公民，也就是SQL的语言方面。他们也习惯了查询的快速返回。正是基于这一要求，Photon背后的想法诞生了。丰富而快速的SQL，就在数据湖上。
为了进一步阐明SQL作为一级公民对我们Databricks的意义，它意味着SQL的语法和行为。这就是为什么我们在Spark SQL方面付出了巨大的努力，使其符合ANSI SQL标准。它还意味着性能。这就是Photon的用武之地。最后，一个熟悉SQL分析人员角色的本机工作空间直接构建到平台中。bob体育客户端下载有了这些，我们来看看Photon。
Photon是一个全新的，100%兼容Apache Spark的查询引擎，旨在提高速度和灵活性。它从头开始构建，在现代云硬件上提供最快的性能，适用于所有数据用例，包括数据工程、数据科学、数据分析和机器学习。
现在让我们双击Photon的高级细节。下面就是构建下一代查询引擎所需要的东西。Photon的架构是为了在真实世界的数据应用程序上获得最快的性能，而不仅仅是流行的基准测试或合成工作负载，它是用c++编写的，以提供最高水平的性能。它有自己的自定义内存管理器，以避免JVM瓶颈。它实现了最新的数据处理技术，包括向量化，在数据、指令和内存级别提供并行性，突破了我们可以从现代云硬件中提取的性能极限。
Photon与Spark SQL和Spark DataFrame api完全兼容，这意味着它可以与您现有的代码一起工作。所以绝对没有厂商锁定。它对最终用户也是完全透明的，所以不需要涉及或调用任何新的东西，它只是开箱即用。
我们希望使用Photon来帮助优化所有数据用例和工作负载。今天，它支持SQL和DataFrame工作负载，我们正在寻找添加流和数据科学工作负载，以及用例。
现在您可能想知道，“为什么要构建一个新的查询引擎呢?”让我来告诉你为什么。
以下是Databricks运行时每个版本的标准化性能图表，可以追溯到2016年的2.1。您可以清楚地看到，性能随着时间的推移一直在增加，但增量相对较小。请注意，2021年8.0版本的DBR性能大约比2016年2.1版本快三倍。但它花了5年时间才达到3倍的性能。
现在，进入Photon。Photon比DBR 8.0版本快两倍，因此比2.1版本快六倍。我们才刚刚开始。这就是为什么我对Photon如此兴奋。现在，希望我让你们对Photon的性能感到兴奋。
那么让我们来深入了解一下Photon是如何与Databricks Lakehouse平台配合使用的。bob体育客户端下载这张幻灯片的目的是阐明Photon的位置，特别是哪些部分不受Photon的影响。因此，让我们从查看查询的生命周期开始。
首先，客户端向Spark Driver提交一个查询。与往常一样，使用Catalyst对该查询进行解析、分析、计划和优化。
然后，我们对物理计划进行传递，以确定哪些部分可以在Photon中运行。我们可能会对Photon的计划做一些小的修改。例如，将排序合并连接更改为散列连接。但总体而言，该计划的结构，包括联合秩序将保持不变。
然后，查询计划被分解为分布执行的原子单元，称为Tasks。每个任务都在线程和工作节点中运行，然后对数据的特定分区进行操作。光子引擎就是在这个层次上工作的。你可以把它看作是用原生引擎实现取代Sparks Whole-Stage CodeGen。Photon库被加载到JVM中，Spark和Photon通过JNI进行通信。所以在高层次上，这就是光子如何无缝集成到Spark运行时在Databricks。
现在让我们来接触光子的关键特征。以下是用户在运行Photon时应该注意的要点。首先，它对用户是完全透明的，并完全集成到Spark中。您的代码将正常工作。但是，使用Photon工作得更快。在Photon中还不支持操作的情况下，它简单地退回到Spark运行时。Photon与Spark的内存管理器集成，用于在混合计划中协调溢出。Spark和Photon都被配置为使用堆外内存，并在内存压力下相互协调。
Photon使用本机代码。为什么是本地代码?高性能Java应用程序通常使用堆外内存和不安全操作。如果是这样的话，为什么不使用c++呢? c++可以避免JVM垃圾收集和JIT问题。Photon在计划中做了小的改变，就像我提到的，将排序合并连接转换为散列连接。
现在，Photon只支持散列连接，因为一般来说，它的性能更好。不像Whole-Stage CodeGen，计划操作符可以融合或组合在一起，Photon保留了操作符边界，因此可以在每个操作符的基础上提供非常丰富的度量，使其更容易理解资源消耗和瓶颈，从而打击了Photon的关键方面。
现在我要把它交给Alex，他是Photon的技术主管，他会和你讨论更多的Photon的好处。亚历克斯，交给你。

Alex Behm:谢谢Greg。现在我们已经分享了Photon是什么，它背后的动机，以及它给Databricks平台带来的价值，让我们深入研究Photon的最新发展。bob体育客户端下载我们的开发集中在三个方面:生产准备、查询覆盖和性能。
我们一直在努力让Photon更有弹性，通过在内存压力下溢出中间状态，以及使用不同的测试策略，尝试错误，当然，观察和改进Photon在实际工作负载下的表现。
如你所知，Photon是从头开始开发的，因此还没有对所有SQL操作的本地支持。实现了最常见的操作符、数据类型和内置函数，我们还在继续扩大覆盖范围，因此更多的查询可以享受光子的速度。
性能总是最重要的，而且很有趣，但也存在过度优化的问题。因此，我们试着不要因为优先考虑常见的使用模式而过于得意忘形。
在我们继续深入之前，先警告一下，在接下来的幻灯片中，我将分享几个性能数据，这些数据集中在受控设置下的特定操作上。这些微基准测试不一定反映真实世界的端到端性能。例如，为了测量内置函数的性能，我们尝试在基准测试期间消除扫描和I/O时间。
我们最近在Photon的弹性方面取得了一个重要的里程碑。我们已经完成了对所有重要操作符的溢出支持，包括传递Shuffle，哈希聚合和哈希连接。这意味着在内存压力下，Photon可以通过将中间状态溢出到外部存储来处理非常大的输入。我们已经在没有Photon的Databricks Runtime中测试了2-5倍的加速范围。
为了让您了解溢出是如何工作的，以及它与您今天从Databricks了解的有何不同，我想向您介绍哈希连接的溢出算法。
哈希连接可以计算具有合适相等条件的连接的结果。它的工作原理是在一个连接输入上构建哈希索引，然后用另一个连接输入探测该索引。
我们将讨论如何修改建筑探测阶段以支持溢出。在构建阶段，即预先有固定数量的分区，并将每个构建行分配给其中一个分区，哈希索引的桶结构指向这些分区中的条目。
其思想是，在内存压力下，我们可以一次释放一个分区的内存，从而比立即溢出所有内容更优雅地降级。在构建阶段，属于溢出分区的构建行也会立即溢出到磁盘。我们一直这样做，直到构建输入被消耗掉。我们现在已经构建了一个部分在内存中，部分溢出的哈希索引。
现在我们进入探测阶段，在该阶段使用其他连接输入的行。与内存驻留分区匹配的探测行将被承认为结果。与溢出分区匹配的探测行也会溢出。对于每个溢出分区，我们有一组构建行和一组探测行。
在使用了探测输入之后，我们可以丢弃内存中的分区，因为我们已经连接并承认了所有可以匹配的探测行。因此，接下来，我们将选择一个溢出的分区，并使用溢出的构建行和探测行作为连接的输入，重复连接过程。这意味着我们读取溢出的构建行，对它们进行分区，并像以前一样根据需要溢出分区。我们递归地应用该方案，直到处理完所有溢出的分区。
为了更好地看待这个问题，让我们比较一下Photon和没有Photon的Databricks的行为。对于大型连接，Spark使用排序合并连接，而Photon更喜欢散列连接。
使用sort-merge连接，我们需要缓冲两个连接输入并对它们进行排序。排序是并行运行的，因此会增加内存压力。为了避免完全溢出，两个输入都需要适合内存。如果我们必须溢出，排序算法需要溢出它的全部输入。
将其与我们刚刚讨论的哈希连接进行对比。首先，我们只需要缓冲一个输入，希望是较小的输入到哈希表中。如果我们必须溢出，我们可以这样做，每次分区，在大多数(但不是所有)构建数据适合内存的情况下优雅地降级。最后，我们使用一些技巧，例如在递归处理溢出分区时反转构建探测站点，以加速连接。
本着同样的原则，我想让您了解一下我们的测试工具包，它极大地帮助了我们。我们有几个测试目标。显然，我们想找到bug，但我们也想消除Spark和Photon之间的细微行为差异，以确保完全兼容。我们还测试极端值，以发现我们可以防范的系统限制。
除了通常的单元和集成测试，我们发现模糊测试非常有效。我们已经构建了生成随机数据的工具，并向系统抛出随机查询，以及随机触发错误路径的代码工具，以确保从异常情况中优雅地恢复。
我们还可以通过随机要求操作员溢出来模拟内存压力。我们还使用Clang/LLVM工具链，其中有一些整洁的工具，如地址和未定义的行为消毒器，甚至可以与模糊方法相结合。
接下来，我将总结我们为增加功能覆盖率所做的工作。如今，Photon支持最常见的数据类型操作符和内置函数。例如，我们可以在整数、字符串、小数等标量数据上运行过滤器、项目shuffle、连接聚合联合。
就内置函数而言，您可以期望支持基本的比较、算术、类型转换、条件函数以及常用的日期和字符串函数。我们正在积极地增加对数组和映射数据类型的支持。我们计划在不久的将来研究排序和窗口函数，以及udf。当然，还有一长串内置功能，我们将继续对其进行研究。
在过去的两个季度中，我们加倍努力支持更多的日期和时间戳函数，因为它们在实际工作负载中非常频繁。我很高兴地告诉大家，到目前为止，我们已经实现了95%的覆盖率，希望很快就能达到100%。
如果你还没有像我一样兴奋，这里有一些微基准测试。这个图表显示了几个常用日期函数的微基准测试，比较了Databricks运行时使用和不使用Photon的情况。条形图表示Photon比没有Photon的Databricks快多少倍。我们可以看到加速是相当可观的。例如，有一个异常值具有惊人的37倍加速，但许多函数至少要快5-10倍。其中有一些常见的问题，比如提取日期部分的函数，比如月、日，以及其他常见的函数，比如日期主干。这些加速是通过精心设计和优化常见情况来实现的，如UTC时区，这是默认时区。
开发的另一个主要领域是增加对嵌套类型的支持，即Struct、Array和Map，我们发现这些类型在我们的客户群中非常受欢迎。目前的状态是完全支持Struct，包括读和写。Array和Map正在积极开发中。像投影数组和映射这样的基础知识，以及常见的函数都在实验室中工作。我们将继续讨论这些类型的内置函数的长列表。
让我们来看看这个功能的数据。和以前一样，这个图表显示了不同内置函数的Photon加速，这次主要集中在嵌套类型上。其中最常见的函数是GetStruckField，其中Photon比非Photon快40多倍。我也很高兴看到方便的StringSplit函数，它是改进最大的函数之一。其中一些操作在像Photon这样的矢量化引擎中实现更自然，但在这些数字背后也有仔细的工程和优化常见的使用模式。
到目前为止，我们主要关注的是读操作，但Photon的另一个亮点是写操作，特别是Photon可以加速写入Delta和Parquet表。这很有道理。Delta使用柱状数据格式，Photon使用柱状查询引擎，两者都很适合。我们所看到的典型的2-4倍加速，当然同意。对于更宽的表，相对加速甚至会增加。
按照写数据的思路，我们还添加了Photon对删除、更新和合并命令的支持。它们不仅受益于写入能力，而且处理权限的核心操作(如连接和聚合)也得到了加速。我们看到的典型加速范围是2-3倍，端到端。
最后但并非最不重要的是，Spark社区和Photon都在积极开发的另一个领域是朝着SQL函数的标准一致性行为发展，比如在溢出时查询失败。我们的目标是为SQL用户提供熟悉的语义。
以上就是目前Photon的不同覆盖范围。这里是我们今天和不久的将来工作的一个总结。
正如您可能对一个新兴项目所期望的那样，我们将在每个版本中添加更多的覆盖范围。所以一定要经常查看。
接下来，我要把话筒交给格雷格。

Greg Rahn:谢谢你，Alex。Photon团队已经建立了这么多的覆盖范围，真是令人惊讶。有了这么多的报道，我可以想象，每个人脑子里的下一件事是，“我今天怎么能试用Photon ?”让我们深入研究一下。
今年6月，Photon将在Databricks上提供，包括产品的两个方面。首先，在Databricks SQL中。这是使用SQL尝试Photon的最简单方法。您只需提供Databricks SQL端点，并使用SQL本机Redash接口，或通过ODBC或JDBC连接Tableau或Power BI，甚至您最喜欢的BYO工具。Databricks SQL在AWS和Azure上都可用。
如前所述，某些窗口操作在Photon中还不支持。所以要注意这一点。
另一种预览Photon的方法是在SQL数据工程(或ETL工作负载)的工作区中。这可以通过配置一个启用Photon的集群来实现。UI中只有一个小滑块，或者复选框来切换它。下一张幻灯片我会给你们看它的屏幕截图。然后就可以在Notebook中或JAR文件中运行SQL或数据帧代码。工作空间中的Photon将在AWS上可用，然后Azure和GCP将在未来添加。
需要注意的是，目前Photon还不支持数据工程工作负载的两个关键领域是自定义udf和流操作。
现在，让我向你展示工作空间中集群的Photon切换。
在Create Clusters UI中，你可以看到这里有一个切换按钮，在Databricks Runtime版本下。当你切换到ON时，支持Photon的运行时版本会被列出，然后你可以选择合适的版本。
现在你可能想知道如果你通过这些方式之一给Photon尝试，“我怎么知道我的查询作业实际上在使用Photon?”我来演示一下。
让我们从一个基本的查询开始，根据供应商简单地计算总和平均旅行距离。在左侧，您可以看到Spark中查询计划的文本表示形式。请注意操作人员的名称。在右边，你可以看到Photon中相同查询的计划。敏锐的人会注意到两件事。在光子计划中还有更多的操作，其中许多实际上都是以光子这个词开始的。这又回到了我之前提到的Spark组合操作或在Whole-Stage CodeGen中融合它们之间的区别，而Photon在每个操作之间保持干净和谨慎的边界。同样，这样做的原因是Photon的详细级别指标。
对于那些更倾向于视觉的人，比如我，你可以看看Spark UI中的执行DAG。像文本计划一样，你会注意到Photon操作以单词Photon开始。但在这里，它们也被颜色编码以区别于Spark操作。黄色表示光子操作，蓝色表示火花。当您单击并展开它们时，您可以看到我们一直在谈论的丰富指标。这也更容易理解性能问题或挑战所在，因为你可以访问这些详细的关卡指标。
对于那些更熟悉SQL角色，更可能使用Databricks SQL UI的人来说，您可以从查询历史部分中找到稍微不同的计划表示。因此，在Databricks SQL UI中，在左侧导航栏上单击History。从历史记录列表中找到您的查询。在本例中，在顶部查找。当您单击它时，右侧的Query Details框将会显示出来。然后单击“执行详细信息”。然后在底部，你会在Photon中看到Task time。
放大来看，这里是这个查询的任务细节。请注意，这个查询的任务时间有98%是在Photon中完成的，这意味着基本上，Photon对这个查询有惊人的覆盖，大部分的执行都是在Photon中完成的。这里，Photon中的数字越高越好。
现在我已经向您展示了如何尝试Photon，并阅读了查询计划，我猜，您脑海中的下一件事是，“Photon有多快?”我们来看看。
我想和你们分享一位顾客的经历。该客户希望使用Databricks来支持大量的SQL分析人员。因此，我们与他们一起针对Databricks SQL端点进行并发测试。大约在一年前，他们开始了他们的旅程，并使用并发工作负载进行了一些测试。在那个时候，平均查询响应时间不到8秒。Photon和Databricks工程团队努力工作，以提高这一数字。到2020年底，客户重新运行他们的并发工作负载测试，发现平均查询响应时间减少了21%。他们非常高兴看到这一进展。但实际上，他们的期望略高，我们Databricks的人也是如此。
所以就在这个月，我们给了他们一个新的构建来尝试，最新的，最好的光子位为他们的工作负载。他们发现，这些比特和平均查询响应时间又减少了29%。这意味着从最初的2020年6月开始，减少了44%。
不用说，他们是光子的忠实粉丝，因为现在他们可以直接在Databricks上为所有SQL和BI用户推出服务，而无需移动任何数据，或依赖任何其他系统。
因此，如果我不能向你们展示必须的TPC-DS性能图表，这将不是一个有趣的性能演讲。这就是它。在这个图表中，我已经绘制了Photon为3TB比例因子的99 DS查询带来的查询加速。正如你所看到的，有一个范围，从温和的加速，到刚刚超过8倍的高端。但大多数都在2-4倍范围内。这通常是我们在大多数工作负载中看到的情况。这个DS工作负载的平均查询速度是2.5倍。
但也许比这更有趣的是，电源测试工作负载加速，从头到尾运行所有这些查询所需的时间快了3.7倍。这意味着如果使用Photon来运行这个工作负载，云基础设施的成本将只有不使用Photon的27%。
这真的说明了Photon带来的速度和效率。再说一次，我们才刚刚开始。所以他们说，你应该总是在一个高调的结尾。所以，让我总结一下今天的光子演讲。
在这次演讲中，我们向您介绍了Photon以及Databricks构建它的动机。我们讨论了最近的发展，以及Photon的下一步。我们从客户的角度和我们的实验室结果强调了一些性能结果。我们还向您展示了如何使用Photon的一些细节，并通过查看查询执行计划和理解底层Photon操作来深入挖掘。
最后，这里有一些相关的演讲，在那里你可以学到更多关于Photon on Databricks的知识。BOB低频彩
当然，你也可以在6月份回到www.neidfyre.com/try，在那里你可以亲自测试Photon，并体验它为SQL工作负载带来的惊人性能。
最后，我要感谢你们来参加这次演讲。现在我们来回答观众的问题。再次感谢。