我正在研究催化剂优化器的各个阶段，但我对前三个阶段在实践中的工作方式有些怀疑。
在第一阶段（分析阶段），优化器将创建查询的逻辑计划。但是这里的列未解析，因此需要为此使用目录对象。
疑问：你知道这个目录对象是如何工作的，所以请解决这个问题，例如，如果我们对 hive 表执行查询，优化器会连接到 hdfs 中的 hivetable 以解析列？
在第二阶段（逻辑优化），优化器将标准规则应用于逻辑计划，如常量折叠、谓词下推和项目修剪。
疑问：我试图找到示例以更好地了解 spark 在此阶段的真正作用，常量折叠、谓词下推和项目修剪如何帮助优化查询，但我没有找到具体的内容关于这个。
在第三阶段（物理规划），Spark 使用与 Spark 执行引擎匹配的物理运算符，获取逻辑规划并生成一个或多个物理规划。
疑问：这部分“使用与spark执行引擎匹配的物理算子”你理解吗？
【问题讨论】：
标签： sql apache-spark optimization apache-spark-sql
你知道这个目录对象是如何工作的，所以请解决这个问题，例如，如果我们对 hive 表执行查询，优化器会连接到 hdfs 中的 hivetables 以解析列？
这里没有单一的答案。基本目录是SessionCatalog，它仅作为实际ExternalCatalog 的代理。 Spark 提供了两种开箱即用的ExternalCatalog 实现：InMemoryCatalog 和HiveExternalCatalog，它们分别对应于标准SQLContext 和HiveContext。显然前者可以访问 Hive 元存储，否则应该没有数据访问。
在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 的某种组合。
【讨论】：