有两种历史悠久的优化技术可以使查询在数据系统中更快地运行：以更快的速度处理数据，或者简单地通过跳过不相关的数据来处理较少的数据。这篇博客文章介绍了动态文件修剪（DFP），这是一种新的数据跳过技术，它可以通过对Delta Lake中表上的非分区列进行选择性连接来显著改进查询，现在Databricks运行时默认启用了该功能。"在我们使用TPC-DS数据和带有动态文件修剪的查询的实验中，我们观察到查询性能提高了8倍，36个查询的速度提高了2倍或更大。动态文件修剪的好处数据工程师经常为大型Delta-Lake表选择一种分区策略，允许访问这些表的查询和作业跳过大量的数据，从而大大加快查询执行时间。当查询在分区键列上包含显式文本谓词时，可以在查询编译时进行分区修剪，也可以在运行时通过动态分区修剪进行分区修剪。Delta Lake on Databricks性能调整除了在分区粒度上消除数据外，Databricks上的Delta Lake在可能的情况下动态地跳过不必要的文件。这是可以实现的，因为Delta Lake会自动收集有关Delta Lake管理的数据文件的元数据，因此可以跳过数据，而无需访问数据文件。在动态文件修剪之前，只有当查询在谓词中包含文本值时才会进行文件修剪，但现在这对文本过滤器和连接过滤器都有效。这意味着动态文件修剪现在允许星型模式查询利用文件粒度上的数据跳过。每个分区每个文件（仅限数据块上的Delta Lake）静态（基于过滤器）分区修剪文件修剪动态（基于联接）动态分区修剪动态文件修剪（新！）动态文件修剪是如何工作的？在深入了解动态文件修剪如何工作之前，让我们简要介绍一下文件修剪如何使用文本谓词。示例1–静态文件修剪为了简单起见，让我们考虑从TPC-DS模式派生的以下查询，以解释文件修剪如何减少扫描操作的大小。--问题1选择总和（ss_数量）来自商店销售部其中ss_item_sk IN（40，41，42）Delta Lake为每个文件存储每个列的最小值和最大值。因此，可以完全跳过过滤值（40、41、42）超出ss_item_sk列的最小-最大范围的文件。我们可以通过使用数据聚类技术（如Z-排序）来减少每个文件的值范围的长度。这对于动态文件修剪非常有吸引力，因为每个文件的范围越小，跳过效果越好。因此，我们按照ss_item_sk列对store_sales表进行了Z-order。在查询Q1中，谓词下推发生，因此文件修剪作为扫描运算符的一部分作为元数据操作进行，但后面还有一个过滤器操作，以删除任何剩余的不匹配行。当筛选器包含文本谓词时，查询编译器可以在查询计划中嵌入这些文本值。然而，当谓词被指定为连接的一部分时，正如大多数数据仓库查询（例如，星型模式连接）中常见的那样，需要一种不同的方法。在这种情况下，事实表上的联接过滤器在查询编译时是未知的。示例2–不带DFP的星型模式联接下面是一个具有典型星型模式联接的查询示例。--问题2选择总和（ss_数量）来自商店销售部JOIN item ON ss_item_sk=i_item_sk其中i_item_id='aaaaaaaa-icaaaaaa'查询Q2返回与Q1相同的结果，但是它指定维度表（item）上的谓词，而不是事实表（store_sales）上的谓词。这意味着，对store_sales行的筛选通常作为JOIN操作的一部分来完成，因为ss_item_sk的值直到在item表上执行扫描和筛选操作之后才知道。下面是第2季度的逻辑查询执行计划。正如您在第二季度的查询计划中所看到的，只有48K行符合联接条件，但是必须从store_nusales表中读取超过86亿条记录。这意味着，如果有一种方法可以将JOIN过滤器下推到store_sales的扫描中，那么查询运行时以及扫描的数据量可以大大减少。示例3–使用动态文件修剪的星型模式连接如果我们使用Q2并启用动态文件修剪，我们可以看到一个动态过滤器是从join的构建端创建的，并传递到store_sales的扫描操作中。下面的逻辑计划图代表了这种优化。将动态文件修剪应用于store峎u sales的扫描操作的结果是，扫描的行数从86亿行减少到6600万行。虽然改进是显著的，但是我们仍然读取了比需要更多的数据，因为DFP是在文件粒度而不是行上操作的。我们可以观察到动态文件修剪的影响，方法是查看Spark UI中的DAG（下面的代码片段），并扩展stoređsales表的扫描操作。特别是，在该查询中使用动态文件修剪可以消除99%以上的输入数据，从而将查询运行时间从10秒提高到1秒以下。没有动态文件修剪使用动态文件修剪启用动态文件修剪DFP在Databricks Runtime 6.1及更高版本中自动启用，并在查询满足以下条件时应用：正在连接的内部表（探针侧）采用Delta-Lake格式连接类型为内部或左半连接策略是广播散列连接内部表中的文件数大于的值spark.databricks.optimizer.deltaTableFilesThresholdDFP可由以下配置参数控制：spark.databricks.optimizer.dynamicFilePrunning（默认值为true）是使优化器能够下推DFP筛选器的主标志。spark.databricks.optimizer.deltaTableSizeThreshold（默认值为10GB）此参数表示触发动态文件修剪所需的联接探测端增量表的最小大小（以字节为单位）。spark.databricks.optimizer.deltaTableFilesThreshold（默认值为1000）此参数表示在联接的探测端上触发动态文件修剪所需的增量表的文件数。注：在本文报道的实验中，我们设置了spark.databricks.optimizer.deltaTableFilesThreshold设置为100以触发DFP，因为store_sales表中的文件少于1000个TPC-DS的实验与结果为了了解动态文件修剪对SQL工作负载的影响，我们比较了1TB数据集中未分区模式下TPC-DS查询的性能。我们使用Z-Ordering将连接的事实表聚集在date和item键列上。DFP在几乎每个查询中都提供了良好的性能。在103个查询中，我们观察到36个查询的加速速度超过2倍，单个查询的最大加速速度约为8倍。下面的图表通过显示前10个改进最快的查询，突出显示了DFP的影响。许多TPC-DS查询使用一个日期维度表和一个事实表（或多个事实表）之间的典型星型模式连接来过滤日期范围，这使得展示DFP的影响成为一项巨大的工作量。上面图表中显示的数据解释了为什么DFP对这组查询如此有效—它们现在能够减少大量的数据读取。每个查询在事实表上都有一个联接过滤器，将时间段限制在30到90天之间（事实表存储5年的数据）。DFP对于这种工作负载非常有吸引力，因为有些查询可能访问多达三个事实表。动态文件修剪入门动态文件修剪（DFP）是Databricks运行时默认启用的一项新功能，可以显著提高Delta-Lake上许多查询的性能。当在非分区表上运行联接查询时，DFP尤其有效。DFP提供的更好的性能通常与数据的聚类有关，因此，用户可以考虑使用Z-排序来最大化DFP的好处。要利用这些最新的性能优化，请立即注册Databricks帐户！免费试用Databricks。今天就开始吧