我正在研究催化剂优化剂的各个阶段，但我怀疑这三个第一阶段在实践中是如何运作的。
在第一阶段（分析阶段），otimizer将创建查询的逻辑计划。但是这里的列是未解析的，因此需要使用目录对象。
怀疑：您知道这个目录对象是如何工作的吗所以解决这个问题，例如，如果我们在hive表上执行查询，优化器会连接到hdfs中的hivetables来解析列吗？
在第二阶段（逻辑优化）中，otimizer将标准规则应用于逻辑计划，如常量折叠，谓词下推和项目修剪。
怀疑：我试图找到一些例子来更好地理解火花在这个阶段真正做了什么，如何不断折叠，谓词下推和项目修剪有助于优化查询，但我没有找到任何具体内容关于这个。
在第三阶段（物理规划）中，spark采用逻辑计划并使用与Spark执行引擎匹配的物理运算符生成一个或多个物理计划。
怀疑：您是否理解这部分“使用与火花执行引擎相匹配的物理运算符”？
答案 0 :(得分：3)
你知道这个目录对象是如何工作的吗所以解决这个问题，例如，如果我们在hive表上执行查询，优化器会连接到hdfs中的hivetables来解析列吗？
这里没有单一的答案。基本目录为SessionCatalog，仅用作实际ExternalCatalog的代理。 Spark提供了ExternalCatalog即开即用的两种不同实现：InMemoryCatalog和HiveExternalCatalog，分别对应于标准SQLContext和HiveContext。显然，前一个可以访问Hive Metastore，但是否则应该没有数据访问。
在Spark 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]
不断折叠
这不是特定于Catalyst的任何特定方式。它只是一个standard compilation technique，它的好处应该是显而易见的。计算表达式比在每行重复一次
更好谓词下推
谓词对应于SQL查询中的WHERE子句。如果这些可以直接用于外部系统（like relational database）或用于分区修剪（如在Parquet中），这意味着减少了必须从磁盘传输/加载的数据量。
和项目修剪
优点与谓词下推几乎相同。如果未使用某些列，则下游数据源可能会在读取时将其丢弃。
您是否使用物理操作员了解此部分
DataFrame只是一个高级抽象。内部操作必须转换为RDD的基本操作，通常是mapPartitions的一些组合。