Question

我已经通过数据框编写器saveAsTable api创建了一个存储桶的内部配置单元表。

df.repartition(numBuckets, somecol)
              .write()
              .format("parquet")
              .bucketBy(numBuckets,col1)
              .sortBy(col1)
              .saveAsTable(hiveTableName);

现在，我通过spark sql触发2个选择查询，一个查询在buckted列上，另一个在non bucketed列上，但是执行时间没有任何区别。

查询是：从t1选择*，其中col1 ='123'[t1由col1存储桶] 从t1选择*，其中col2 ='123'[col2不是存储区列] 我的问题是

如何确定在查询执行期间正在执行全表扫描还是正在对相关表进行部分表扫描？
我可以从DAG或实际计划中获取任何信息吗？我都看过，但没什么区别这是我在身体计划中看到的

==身体计划== *（1）项目[col1＃0，col2＃1，col3＃2，col4＃3，col5＃4，col6＃5，col7＃6，col8＃7，col9＃8，col10＃9，col11＃10， col12＃11] +-*（1）过滤器（isnotnull（col2＃1）&&（col2＃1 = 123）） +-*（1）FileScan Parquet default.uk_geocrosswalk [col1＃0，col2＃1，col3＃2，col4＃3，col5＃4，col6＃5，col7＃6，col8＃7，col9＃8，LSOA_MSOA_WEIGHT＃ 9，col11＃10，col12＃11]批处理：true，格式：Parquet，位置：InMemoryFileIndex [hdfs：//url/a.parquet，PartitionFilters：[]，PushedFilters：[IsNotNull（col2），EqualTo（col2,123））]，ReadSchema：结构
在物理计划中，为什么要进行文件扫描？因为该表已作为配置单元表创建，所以它不应该执行HiveTableScan吗？
在使用sparksql时是否可以使用某些配置参数来优化查询？
我每次在spark sql中第一次运行查询时都需要花费相当长的时间。有没有一种方法可以在执行查询之前预热执行程序？

Answer 1

实木复合地板是柱状的。根据我的经验，实木复合地板非常快。柱状方面可以很好地解释相同的性能-无论是否为键，数据格式在物理上都是柱状。

这是一个Hive表，但使用Parquet和Bucketing，Hive / Impala无法访问。由于是实木复合地板，因此不适合使用Hive Table Scan。一个Hive表可以具有多种物理格式，包括文本，Parquet和ORC。

您可以看到以下过滤： PartitionFilters：[]，PushedFilters：[IsNotNull（col2），EqualTo（col2,123）]，

没有这样的预热。您可以缓存内容，但是我已经测试并看到了测试，在缓存Parquet表方面并没有太大区别，但这取决于测试。

Hive内部表和SparkSql中的存储桶

1 个答案: