催化剂优化阶段

Question

我在研究催化剂优化器的各个阶段，但我有些怀疑这三个第一阶段在实践中是如何工作的。

在第一阶段（分析阶段），otimizer将创建查询的逻辑计划。但是这里的列没有解决，所以它需要为此使用一个目录对象。

怀疑：你知道这个目录对象是如何工作的吗？例如，如果我们在hive表上执行查询，优化器连接到hdfs中的hivetables来解析列？

在第二阶段（逻辑优化），otimizer将标准规则应用于逻辑计划，如常量折叠，谓词下推和项目修剪。

怀疑：我试着找例子来更好地理解什么火花确实在这个阶段，不断折叠，谓语pushsdown和项目修剪事情如何帮助优化查询，但林没有找到关于这个没什么混凝土。

在第三阶段（物理计划），spark使用符合Spark执行引擎的物理操作符来计算逻辑计划并生成一个或多个物理计划。

怀疑：您是否理解这部分内容“使用与火花执行引擎匹配的物理操作符”？

Answer 1

你知道这个目录对象是如何工作的吗？例如，如果我们在hive表上执行查询，优化器连接到hdfs中的hivetables来解析列？

这里没有单一的答案。基本目录是SessionCatalog，它仅作为实际ExternalCatalog的代理。 Spark提供了开箱即用的ExternalCatalog的两种不同实现：InMemoryCatalog和HiveExternalCatalog，分别对应于标准SQLContext和HiveContext。显然，前者可能访问Hive Metastore，但应该没有其他数据访问。

在火花2.0+目录可以直接使用SparkSession.catalog例如被查询：

val df = Seq(("a", 1), ("b", 2)).toDF("k", "v") 
// df: org.apache.spark.sql.DataFrame = [k: string, v: int] 

spark.catalog.listTables 
// org.apache.spark.sql.Dataset[org.apache.spark.sql.catalog.Table] = 
// [name: string, database: string ... 3 more fields] 

常量合并

这不是特定于催化剂的任何特定方式。这只是一个standard compilation technique，它的好处应该是显而易见的。这是更好地计算表达式一旦超过这个重复的每一行

谓词下推

谓词对应于SQL查询WHERE条款。如果这些可以直接用于外部系统（like relational database）或用于分区修剪（如在Parquet中），这意味着需要从磁盘传输/加载的数据量减少。

和项目修剪

好处是几乎一样的谓词下推。如果某些列未使用，则下游数据源可能会在读取时丢弃该列。

你使用的物理运算符

DataFrame仅仅是一个高层次的抽象理解这部分内容。内部操作必须转化为RDD的基本操作，通常是mapPartitions的一些组合。