西安网站建设网络推广,怎么制作图片视频,免费广告设计制作app,在线做印章网站经过AstBuilder的处理#xff0c;得到了Unresolved LogicalPlan。该逻辑算子树中未被解析的有UnresolvedRelation和UnresolvedAttribute两种对象。Analyzer所起到的主要作用就是将这两种节点或表达式解析成有类型的#xff08;Typed#xff09;对象。在此过程中#xff0c;… 经过AstBuilder的处理得到了Unresolved LogicalPlan。该逻辑算子树中未被解析的有UnresolvedRelation和UnresolvedAttribute两种对象。Analyzer所起到的主要作用就是将这两种节点或表达式解析成有类型的Typed对象。在此过程中需要用到Catalog的相关信息。 因为继承自RuleExecutor类所以Analyzer执行过程会调用其父类RuleExecutor中实现的run方法主要的不同之处是Analyzer中重新定义了一系列规则即RuleExecutor类中的成员变量batches如下图所示。 在Spark 2.1版本中Analyzer默认定义了6个Batch共有34条内置的规则外加额外实现的扩展规则上图中extendedResolutionRules。在分析Analyzed LogicalPlan生成过程之前先对这些Batch进行简单的介绍读者可结合代码阅读。 NoteAnalyzer中用到的规则比较多因篇幅所限不方便一一展开分析。本小节对这些规则仅做概述性的分析从宏观层面介绍规则所起到的主要作用旨在把握规则体系的轮廓后续章节在具体的查询分析时会对其中常用的重要规则进行讲解。 1Batch Substitution 顾名思义Substitution含义是替换因此这个Batch对节点的作用类似于替换操作。目前在Substitution这个Batch中定义了4条规则分别是CTESubstitution、WindowsSubstitution、EliminateUnions和 SubstituteUnresolvedOrdinals。
CTESubstitutionCTE对应的是With语句在SQL中主要用于子查询模块化因此CTESubstitution规则也就是用来处理With语句的。在遍历逻辑算子树的过程中当匹配到With(childrelations)节点时将子LogicalPlan替换成解析后的CTE。由于CTE的存在SparkSqlParser对SQL语句从左向右解析后会产生多个LogicalPlan。这条规则的作用是将多个LogicalPlan合并成一个LogicalPlan。WindowsSubstitution对当前的逻辑算子树进行查找当匹配到WithWindowDefinition(windowDefinitionschild)表达式时将其子节点中未解析的窗口函数表达式Unresolved-WindowExpression转换成窗口函数表达式WindowExpression。EliminateUnions在Union算子节点只有一个子节点时Union操作实际上并没有起到作用这种情况下需要消除该Union节点。该规则在遍历逻辑算子树过程中匹配到Union(children)且children的数目只有1个时将Union(children)替换为children.head节点。SubstituteUnresolvedOrdinalsSpark从2.0版本开始在“Order By”和“Group By”语句中开始支持用常数来表示列的下标。例如假设某行数据包括A、B、C 3列那么1对应A列2对应B列3对应C列此时“Group By 12”等价于“Group By AB”语句。而在2.0版本之前这种写法会直接被当作常数而忽略。新版本中这种特性通过配置参数“spark.sql.orderByOrdinal”和“spark.sql.groupByOrdinal”进行设置默认都为true表示该特性开启。SubstituteUnresolvedOrdinals这条规则的作用就是根据这两个配置参数将下标替换成UnresolvedOrdinal表达式以映射到对应的列。
2Batch Resolution 该Batch中包含了Analyzer中最多同时也最常用的解析规则如下表所示。表中规则从上到下的顺序也是规则被RuleExecutor执行的顺序。 根据表可知Resolution中加入了25条分析规则以及一个extendedResolutionRules扩展规则列表用来支持Analyzer子类在扩展规则列表中添加新的分析规则。整体上来讲表中的这些规则涉及了常见的数据源、数据类型、数据转换和处理操作等。根据规则名称很容易看出这些规则都针对特定的算子节点例如ResolveUpCast规则用于DataType向DataType的数据类型转换。考虑到后续具体查询分析中会涉及这些规则因此这里不展开分析。
3Batch Nondeterministic⇒PullOutNondeterministic 该Batch中仅包含PullOutNondeterministic这一条规则主要用来将LogicalPlan中非Project或非Filter算子的nondeterministic不确定的表达式提取出来然后将这些表达式放在内层的Project算子中或最终的Project算子中。
4Batch UDF⇒HandleNullInputsForUDF 对于UDF这个规则Batch主要用来对用户自定义函数进行一些特别的处理该Batch在Spark2.1版本中仅有HandleNullInputsForUDF这一条规则。HandleNullInputsForUDF规则用来处理输入数据为Null的情形其主要思想是从上至下进行表达式的遍历transform ExpressionsUp当匹配到ScalaUDF类型的表达式时会创建If表达式来进行Null值的检查。 5Batch FixNullability⇒FixNullability 该Batch中仅包含FixNullability这一条规则用来统一设定LogicalPlan中表达式的nullable属性。在DataFrame或Dataset等编程接口中用户代码对于某些列AttribtueReference可能会改变其nullability属性导致后续的判断逻辑如isNull过滤等中出现异常结果。在FixNullability规则中对解析后的LogicalPlan执行transform Expressions操作如果某列来自于其子节点则其nullability值根据子节点对应的输出信息进行设置。 6Batch Cleanup⇒CleanupAliases 该Batch中仅包含CleanupAliases这一条规则用来删除LogicalPlan中无用的别名信息。一般情况下逻辑算子树中仅Project、Aggregate或Window算子的最高一层表达式分别对应project list、aggregate expressions和window expressions才需要别名。CleanupAliases通过trimAliases方法对表达式执行中的别名进行删除。 以上内容介绍的是Spark 2.1版本Analyzer中内置的分析规则整体情况在不同版本的演化中这些规则也会有所变化读者可自行分析。现在回到之前案例查询中生成的Unresolved LogicalPlan中。接下来的内容将会重点探讨Analyzer对该逻辑算子树进行分析的详细流程。 在QueryExecution类中可以看到触发Analyzer执行的是execute方法即RuleExecutor中的execute方法该方法会循环地调用规则对逻辑算子树进行分析。
val analyzed: LogicalPlan analyzer.execute(logical)对于上图中的Unresolved LogicalPlanAnalyzer中首先匹配的是ResolveRelations规则。执行过程如下图所示这也是Analyzed LogicalPlan生成的第1步。
object ResolveRelations extends Rule[LogicalPlan] {private def lookupTableFromCatalog(u: UnresolvedRelation): LogicalPlan {try {catalog.lookupRelation(u.tableIdentifier, u.alias)} catch {case _: NoSuchTableException u.failAnalysis(s Table or view not found: ${u.tableName})}}def apply(paln: LogicalPlan): LogicalPlan plan resolveOperators {case i InsertIntoTable(u: UnresolvedRelation, parts, child, _, _)if child.resolved i.copy(table EliminateSubqueryAliases(lookupTableFromCatelog(u)))case u: UnresolvedRelation val table u.tableIdentifierif(table.database.isDefined conf.runSQLonFile !catalog.isTemporaryTable(table) (!catalog.databaseExists(table.database.get) || !catalog.tableExists(table))) {u} else {lookupTableFromCatalog(u)}}
}从上述ResolveRelations的实现中可以看到当遍历逻辑算子树的过程中匹配到UnresolvedRelation节点时对于本例会直接调用lookupTableFromCatalog方法从SessionCatalog中查表。实际上该表在案例SQL查询的上一步中就已经创建好并以LogicalPlan类型存储在InMemoryCatalog中因此lookupTableFromCatalog方法直接根据其表名即可得到分析后的LogicalPlan。 需要注意的是在Catalog查表后Relation节点上会插入一个别名节点。此外Relation中列后面的数字表示下标注意其数据类型age和id都默认设定为Long类型(“L”字符)。 接下来进入第2步执行ResolveReferences规则得到的逻辑算子树如下图所示。可以看到其他节点都不发生变化主要是Filter节点中的age信息从Unresolved状态变成了Analyzed状态表示Unresolved状态的前缀字符单引号已经被去掉。 在ResolveReferences规则中与本例相关的匹配逻辑如以下代码所示。当碰到UnresolvedAttribute时会调用LogicalPlan中定义的resolveChildren方法对该表达式进行分析。需要注意的是resolveChildren并不能确保一次分析成功在分析对应表达式时需要根据该表达式所处LogicalPlan节点的子节点输出信息进行判断。在对Filter表达式中的age属性进行分析时因为Filter的子节点Relation已经处于resolved状态因此可以成功而在对Project中的表达式name属性进行分析时因为Project的子节点Filter此时仍然处于unresolved状态注虽然age列完成了分析但是整个Filter节点中还有“18”这个Literal常数表达式未被分析因此解析操作无法成功留待下一轮规则调用时再进行解析。
object ResolveReferences extends Rule[LogicalPlan] {def apply(plan: LogicalPlan): LogicalPlan plan resolveOperators {case q: LogicalPlan q transformExpressionsUp {case u UnresolvedAttribute(nameParts) val result withPosition(u) {q.resolveChildren(nameParts, resolver).getOrElse(u) }resultcase UnresolvedExtractValue(child, fieldExpr) if child.resolved ExtractValue(child, fieldExpr, resolver)}}
}完成第2步之后会调用TypeCoercion规则集中的ImplicitTypeCasts规则对表达式中的数据类型进行隐式转换这是Analyzed LogicalPlan生成的第3步如下图所示。因为在Relation中age列的数据类型为Long而Filter中的数值“18”在Unresolved LogicalPlan中生成的类型为IntegerType所以需要将“18”这个常数转换为Long类型。 上述分析转换过程如上图所示可以看到常数表达式“18”换为“cast(18 as bigint)”表达式注在Spark SQL类型系统中BigInt对应Java中的Long类型。ImplicitTypeCasts规则对于案例的逻辑算子树的处理过程如以下代码所示。对于BinaryOperator表达式该规则会调用findTightestCommonTypeOfTwo找到对于左右表达式节点来讲最佳的共同数据类型。经过该规则的解析操作可以看到上图中Filter节点已经变为Analyzed状态节点字符前缀单引号已经被去掉。
object ImplicitTypeCasts extends Rule[LogicalPlan] {def apply(plan: LogicalPlan): LogicalPlan plan resolvedExpressions {case b BinaryOperator(left, right) if left.dataType ! right.dataType findTightestCommonTypeOfTwo(left.dataType, right.dataType).map { commonType if(b.inputType.acceptsType(commonType)) {val newLeft if(left.dataType commonType) left else Cast(left, commonType)val newRight if(right.dataType commonType) right else Cast(right, commonType)b.withNewChildren(Seq(newLeft, newRight))} else {b}}.getOrElse(b)}
}经过上述3个规则的解析之后剩下的规则对逻辑算子树不起作用。此时逻辑算子树中仍然存在Project节点未被解析接下来会进行下一轮规则的应用。第4步也是最后一步再次执行ResolveReferences规则。 如下图所示经过上一步Filter节点已经处于resolved状态因此逻辑算子树中的Project节点能够完成解析。Project节点的“name”被解析为“name#2”其中“2”表示name在所有列中的下标。 至此Analyzed LogicalPlan就完全生成了。从上述步骤可以看出逻辑算子树的解析是一个不断的迭代过程。实际上用户可以通过参数spark.sql.optimizer.maxIterations设定RuleExecutor迭代的轮数默认配置为50轮对于某些嵌套较深的特殊SQL可以适当地增加轮数
