Catalyst 优化逻辑执行计划规则

简介:

Optimizer

本文分析Catalyst Optimize部分实现的对逻辑执行计划(LogicalPlan)的处理规则


Optimizer处理的是LogicalPlan对象。

Optimizer的batches如下:
object Optimizer extends RuleExecutor[LogicalPlan] {
  val batches =
    Batch("ConstantFolding", Once,
      ConstantFolding, // 可静态分析的常量表达式
      BooleanSimplification, // 布尔表达式提前短路
      SimplifyFilters, // 简化过滤操作(false, true, null)
      SimplifyCasts) :: // 简化转换(对象所属类已经是Cast目标类)
    Batch("Filter Pushdown", Once,
      CombineFilters, // 相邻(上下级)Filter操作合并
      PushPredicateThroughProject, // 映射操作中的Filter谓词下推
      PushPredicateThroughInnerJoin) :: Nil // inner join操作谓词下推
}

这是4.1号最新的Catalyst  Optimizer的代码。


ConstantFolding 

把可以静态分析出结果的表达式替换成Literal表达式。

object ConstantFolding extends Rule[LogicalPlan] {
  def apply(plan: LogicalPlan): LogicalPlan = plan transform {
    case q: LogicalPlan => q transformExpressionsDown {
      // Skip redundant folding of literals.
      case l: Literal => l
      case e if e.foldable => Literal(e.apply(null), e.dataType)
    }
  }
}

Literal能处理的类型包括Int, Long, Double, Float, Byte,Short, String, Boolean, null。这些类型分别对应的是Catalyst框架的DataType,包括IntegerType, LongType, DoubleType,FloatType, ByteType, ShortType, StringType, BooleanType, NullType。

普通的Literal是不可变的,还有一个可变的MutalLiteral类,有update方法可以改变里面的value。


BooleanSimplification 

提前短路可以短路的布尔表达式

object BooleanSimplification extends Rule[LogicalPlan] {
  def apply(plan: LogicalPlan): LogicalPlan = plan transform {
    case q: LogicalPlan => q transformExpressionsUp {
      case and @ And(left, right) =>
        (left, right) match {
          case (Literal(true, BooleanType), r) => r
          case (l, Literal(true, BooleanType)) => l
          case (Literal(false, BooleanType), _) => Literal(false)
          case (_, Literal(false, BooleanType)) => Literal(false)
          case (_, _) => and
        }

      case or @ Or(left, right) =>
        (left, right) match {
          case (Literal(true, BooleanType), _) => Literal(true)
          case (_, Literal(true, BooleanType)) => Literal(true)
          case (Literal(false, BooleanType), r) => r
          case (l, Literal(false, BooleanType)) => l
          case (_, _) => or
        }
    }
  }
}

SimplifyFilters 

提前处理可以被判断的过滤操作

object SimplifyFilters extends Rule[LogicalPlan] {
  def apply(plan: LogicalPlan): LogicalPlan = plan transform {
    case Filter(Literal(true, BooleanType), child) =>
      child
    case Filter(Literal(null, _), child) =>
      LocalRelation(child.output)
    case Filter(Literal(false, BooleanType), child) =>
      LocalRelation(child.output)
  }
}

SimplifyCasts 

把已经是目标类的Cast表达式替换掉

object SimplifyCasts extends Rule[LogicalPlan] {
  def apply(plan: LogicalPlan): LogicalPlan = plan transformAllExpressions {
    case Cast(e, dataType) if e.dataType == dataType => e
  }
}

CombineFilters 

相邻都是过滤操作的话,把两个过滤操作合起来。相邻指的是上下两级。

object CombineFilters extends Rule[LogicalPlan] {
  def apply(plan: LogicalPlan): LogicalPlan = plan transform {
    case ff @ Filter(fc, nf @ Filter(nc, grandChild)) => Filter(And(nc, fc), grandChild)
  }
}

PushPredicateThroughProject 

把Project操作中的过滤操作下推。这一步里顺带做了别名转换的操作(认为开销不大的前提下)。

object PushPredicateThroughProject extends Rule[LogicalPlan] {
  def apply(plan: LogicalPlan): LogicalPlan = plan transform {
    case filter @ Filter(condition, project @ Project(fields, grandChild)) =>
      val sourceAliases = fields.collect { case a @ Alias(c, _) =>
        (a.toAttribute: Attribute) -> c
      }.toMap // 把fields中的别名属性都取出来
      project.copy(child = filter.copy( // 生成新的Filter操作
        replaceAlias(condition, sourceAliases), // condition中有别名的替换掉
        grandChild))
  }

  def replaceAlias(condition: Expression, sourceAliases: Map[Attribute, Expression]): Expression = {
    condition transform {
      case a: AttributeReference => sourceAliases.getOrElse(a, a)
    }
  }
}

PushPredicateThroughInnerJoin 

先找到Filter操作,若Filter操作里面是一次inner join,那么先把Filter条件和inner join条件先全部取出来,

然后把只涉及到左侧或右侧的过滤操作下推到join外部,把剩下来不能下推的条件放到join操作的condition里。

object PushPredicateThroughInnerJoin extends Rule[LogicalPlan] with PredicateHelper {
  def apply(plan: LogicalPlan): LogicalPlan = plan transform {
    case f @ Filter(filterCondition, Join(left, right, Inner, joinCondition)) =>
      // 这一步是把过滤条件和join条件里的condition都提取出来
      val allConditions = splitConjunctivePredicates(filterCondition) ++
        joinCondition.map(splitConjunctivePredicates).getOrElse(Nil)
      
      // 把参考属性都属于右侧输出属性的condition挑选到rightCondition里
      val (rightConditions, leftOrJoinConditions) =
        allConditions.partition(_.references subsetOf right.outputSet)
      // 同理,把剩余condition里面,参考属性都属于左侧输出属性的condition挑选到
      // leftCondition里,剩余的就属于joinCondition
      val (leftConditions, joinConditions) =
        leftOrJoinConditions.partition(_.references subsetOf left.outputSet)

      // 生成新的left和right:先把condition里的操作用AND折叠起来,然后将该折叠后的表达式和原始的left/right logical plan合起来生成新的Filter操作,即新的Fil      // ter logical plan
      // 这样就做到了把过滤条件中的谓词下推到了left/right里,即本次inner join的“外部”
      val newLeft = leftConditions.reduceLeftOption(And).map(Filter(_, left)).getOrElse(left)
      val newRight = rightConditions.reduceLeftOption(And).map(Filter(_, right)).getOrElse(right)
      Join(newLeft, newRight, Inner, joinConditions.reduceLeftOption(And))
  }
}

以下帮助理解上面这段代码。

Join操作(LogicalPlan的Binary)

case class Join(
  left: LogicalPlan,
  right: LogicalPlan,
  joinType: JoinType,
  condition: Option[Expression]) extends BinaryNode {

  def references = condition.map(_.references).getOrElse(Set.empty)
  def output = left.output ++ right.output
}

Filter操作(LogicalPlan的Unary)

case class Filter(condition: Expression, child: LogicalPlan) extends UnaryNode {
  def output = child.output
  def references = condition.references
}

reduceLeftOption逻辑是这样的:

def reduceLeftOption[B >: A](op: (B, A) => B): Option[B] =
    if (isEmpty) None else Some(reduceLeft(op))

reduceLeft(op)的结果是op( op( ... op(x_1, x_2) ...,x_{n-1}), x_n)


谓词助手这个trait,负责把And操作里的condition分离开,返回表达式Seq

trait PredicateHelper {
  def splitConjunctivePredicates(condition: Expression): Seq[Expression] = condition match {
    case And(cond1, cond2) => splitConjunctivePredicates(cond1) ++ splitConjunctivePredicates(cond2)
    case other => other :: Nil
  }
}


Example

case class Person(name:String, age: Int)

case classNum(v1: Int, v2: Int)


case one

SELECT  people.age, num.v1,  num.v2

FROM

    people

    JOIN  num

    ON   people.age > 20  and  num.v1> 0

WHERE  num.v2< 50


== QueryPlan ==

Project [age#1:1,v1#2:2,v2#3:3]

CartesianProduct

      Filter(age#1:1 > 20)

          ExistingRdd[name#0,age#1], MappedRDD[4] at map at basicOperators.scala:124

      Filter((v2#3:1 < 50) && (v1#2:0 > 0))

          ExistingRdd [v1#2,v2#3],MappedRDD[10] at map at basicOperators.scala:124

 

分析:where条件 num.v2 < 50 下推到Join里


case two

SELECT people.age,  1+2

FROM

    people

    JOIN  num

    ON   people.name<>’abc’  and  num.v1> 0

WHERE num.v2 < 50

 

== QueryPlan ==

Project [age#1:1,3 AS c1#14]

    CartesianProduct

        Filter NOT(name#0:0 = abc)

            ExistingRdd[name#0,age#1], MappedRDD[4] at map at basicOperators.scala:124

        Filter((v2#3:1 < 50) && (v1#2:0 > 0))

            ExistingRdd[v1#2,v2#3], MappedRDD[10] at map at basicOperators.scala:124

 

分析:1+2 被提前常量折叠,并被取了一个别名



全文完 :)



目录
相关文章
|
7月前
|
缓存 关系型数据库 MySQL
MySQL查询优化:提速查询效率的13大秘籍(合理使用索引合并、优化配置参数、使用分区优化性能、避免不必要的排序和group by操作)(下)
MySQL查询优化:提速查询效率的13大秘籍(合理使用索引合并、优化配置参数、使用分区优化性能、避免不必要的排序和group by操作)(下)
305 0
|
5月前
|
SQL 存储 监控
MSSQL性能调优深度解析:索引策略优化、SQL语句精炼与并发管理技巧
在Microsoft SQL Server(MSSQL)的性能调优领域,索引策略的优化、SQL语句的精炼以及高效的并发管理技巧是提升数据库性能不可或缺的三大方面
|
7月前
|
SQL 分布式计算 算法
当两个表进行Join操作时,如果它们的数据不符合MapJoin规范,您可以尝试以下优化方案
当两个表进行Join操作时,如果它们的数据不符合MapJoin规范,您可以尝试以下优化方案
88 4
|
SQL 存储 算法
PostgreSQL 执行计划,成本公式解说,代价因子校准,自动跟踪SQL执行计划(二)|学习笔记
快速学习PostgreSQL 执行计划,成本公式解说,代价因子校准,自动跟踪SQL执行计划(二)
PostgreSQL 执行计划,成本公式解说,代价因子校准,自动跟踪SQL执行计划(二)|学习笔记
|
SQL 移动开发 关系型数据库
PostgreSQL 执行计划,成本公式解说,代价因子校准,自动跟踪SQL执行计划(三)|学习笔记
快速学习PostgreSQL 执行计划,成本公式解说,代价因子校准,自动跟踪SQL执行计划(三)
PostgreSQL 执行计划,成本公式解说,代价因子校准,自动跟踪SQL执行计划(三)|学习笔记
|
SQL 分布式计算 BI
MaxCompute笛卡尔积逻辑的参数优化&复杂JOIN逻辑优化
这篇文章主要讲一个SQL优化反映的两个优化点。分别是: 一、笛卡尔积逻辑的参数优化。 二、一个复杂JOIN逻辑的优化思路。
2292 2
MaxCompute笛卡尔积逻辑的参数优化&复杂JOIN逻辑优化
|
SQL 分布式计算 Java
扩展_Catalyst 优化器_优化过程 | 学习笔记
快速学习扩展_Catalyst 优化器_优化过程
185 0
扩展_Catalyst 优化器_优化过程 | 学习笔记
|
SQL 大数据 开发者
扩展_Catalyst 优化器_查看计划 | 学习笔记
快速学习扩展_Catalyst 优化器_查看计划
扩展_Catalyst 优化器_查看计划 | 学习笔记
|
SQL XML JSON
PostgreSQL 执行计划,成本公式解说,代价因子校准,自动跟踪SQL执行计划(一)|学习笔记
快速学习PostgreSQL 执行计划,成本公式解说,代价因子校准,自动跟踪SQL执行计划(一)
PostgreSQL 执行计划,成本公式解说,代价因子校准,自动跟踪SQL执行计划(一)|学习笔记
|
SQL 关系型数据库 MySQL
Semi-join使用条件,派生表优化 (3)—mysql基于规则优化(四十六)
Semi-join使用条件,派生表优化 (3)—mysql基于规则优化(四十六)