我正在研究催化剂优化器的各个阶段,但我对第一阶段的工作原理有一些疑问。
在第一阶段(分析阶段),otimizer将创建查询的逻辑计划。但是在这里,列是未解析的,因此它需要为此使用一个目录对象。
怀疑:您知道这个目录对象是如何工作的吗?因此可以解决这个问题,例如,如果我们对hive表执行查询,优化器会连接到hdfs中的hivetable来解析列?
在第二阶段(逻辑优化)中,otimizer将标准规则应用于逻辑计划,如常量折叠、谓词推倒和项目剪枝。
怀疑:我试图找一些例子来更好地理解火花在这个阶段到底做了什么,常量折叠、谓词下推和项目剪枝是如何帮助优化查询的,但我没有在具体的方面找到任何具体的东西。
在第三阶段(物理计划)中,spark采用逻辑计划,并使用与火花执行引擎匹配的物理操作符生成一个或多个物理计划。
怀疑:您理解这个部分“使用与火花执行引擎匹配的物理操作符”吗?
发布于 2016-05-12 23:33:42
您知道这个目录对象是如何工作的吗?这样就可以解决这个问题,例如,如果我们对hive表执行查询,优化器就会连接到hdfs中的hivetable来解析列?
这里没有唯一的答案。基本目录是SessionCatalog
,它仅用作实际ExternalCatalog
的代理。Spark提供了ExternalCatalog
开箱即用的两种不同的实现:InMemoryCatalog
和HiveExternalCatalog
,它们分别对应于标准的SQLContext
和HiveContext
。显然,前者可能进入蜂巢转移,但不应该有数据访问,否则。
在星火库中,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]
常折叠
这并不是特定于催化剂的任何特殊方式。它只是一个标准编译技术,它的好处应该是显而易见的。与其对每一行重复此操作,不如计算一次表达式。
谓词下推
谓词对应于SQL查询中的WHERE
子句。如果这些数据可以直接用于外部系统(类似关系数据库)或分区剪枝(如Parquet中),这意味着必须从磁盘传输/加载的数据量减少。
和项目修剪
好处与谓词下推几乎是一样的。如果没有使用某些列,下游数据源可能会在读取时放弃这一点。
你理解这部分使用物理运算符吗?
DataFrame
只是一个高级抽象。内部操作必须转换为RDDs上的基本操作,通常是mapPartitions
的一些组合。
https://stackoverflow.com/questions/37197504
复制相似问题