好久没更新博客了,之前学了一些R语言和机器学习的内容,做了一些笔记,之后也会放到博客上面来给大家共享。一个月前就打算更新Spark Sql的内容了,因为一些别的事情耽误了,今天就简单写点,Spark1.2马上就要出来了,不知道变动会不会很大,据说添加了很多的新功能呢,期待中...

首先声明一下这个版本的代码是1.1的,之前讲的都是1.0的。

Spark支持两种模式,一种是在spark里面直接写sql,可以通过sql来查询对象,类似.net的LINQ一样,另外一种支持hive的HQL。不管是哪种方式,下面提到的步骤都会有,不同的是具体的执行过程。下面就说一下这个过程。

Sql解析成LogicPlan

使用Idea的快捷键Ctrl + Shift + N打开SQLQuerySuite文件,进行调试吧。

  def sql(sqlText: String): SchemaRDD = {
    if (dialect == "sql") {
      new SchemaRDD(this, parseSql(sqlText))
    } else {
      sys.error(s"Unsupported SQL dialect: $dialect")
    }
  }

从这里可以看出来,第一步是解析sql,最后把它转换成一个SchemaRDD。点击进入parseSql函数,发现解析Sql的过程在SqlParser这个类里面。
在SqlParser的apply方法里面,我们可以看到else语句里面的这段代码。

      //对input进行解析,符合query的模式的就返回Success
      phrase(query)(new lexical.Scanner(input)) match {
        case Success(r, x) => r
        case x => sys.error(x.toString)
      }

这里我们主要关注query就可以。

  protected lazy val query: Parser[LogicalPlan] = (
    select * (
        UNION ~ ALL ^^^ { (q1: LogicalPlan, q2: LogicalPlan) => Union(q1, q2) } |
        INTERSECT ^^^ { (q1: LogicalPlan, q2: LogicalPlan) => Intersect(q1, q2) } |
        EXCEPT ^^^ { (q1: LogicalPlan, q2: LogicalPlan) => Except(q1, q2)} |
        UNION ~ opt(DISTINCT) ^^^ { (q1: LogicalPlan, q2: LogicalPlan) => Distinct(Union(q1, q2)) }
      )
    | insert | cache
  )

这里面有很多看不懂的操作符,请到下面这个网址里面去学习。这里可以看出来它目前支持的sql语句只是select和insert。

http://www.scala-lang.org/api/2.10.4/index.html#scala.util.parsing.combinator.Parsers$Parser

我们继续查看select。

  // ~>只保留右边的模式 opt可选的 ~按顺序合成 <~只保留左边的
  protected lazy val select: Parser[LogicalPlan] =
    SELECT ~> opt(DISTINCT) ~ projections ~
    opt(from) ~ opt(filter) ~
    opt(grouping) ~
    opt(having) ~
    opt(orderBy) ~
    opt(limit) <~ opt(";") ^^ {
      case d ~ p ~ r ~ f ~ g ~ h ~ o ~ l  =>
        val base = r.getOrElse(NoRelation)
        val withFilter = f.map(f => Filter(f, base)).getOrElse(base)
        val withProjection =
          g.map {g =>
            Aggregate(assignAliases(g), assignAliases(p), withFilter)
          }.getOrElse(Project(assignAliases(p), withFilter))
        val withDistinct = d.map(_ => Distinct(withProjection)).getOrElse(withProjection)
        val withHaving = h.map(h => Filter(h, withDistinct)).getOrElse(withDistinct)
        val withOrder = o.map(o => Sort(o, withHaving)).getOrElse(withHaving)
        val withLimit = l.map { l => Limit(l, withOrder) }.getOrElse(withOrder)
        withLimit
  }

可以看得出来它对sql的解析是和我们常用的sql写法是一致的,这里面再深入下去还有递归,并不是看起来那么好理解。这里就不继续讲下去了,在解析hive的时候我会重点讲一下,我认为目前大家使用得更多是仍然是来源于hive的数据集,毕竟hive那么稳定。

到这里我们可以知道第一步是通过Parser把sql解析成一个LogicPlan。

LogicPlan到RDD的转换过程

好,下面我们回到刚才的代码,接着我们应该看SchemaRDD。

  override def compute(split: Partition, context: TaskContext): Iterator[Row] =
    firstParent[Row].compute(split, context).map(_.copy())

  override def getPartitions: Array[Partition] = firstParent[Row].partitions

  override protected def getDependencies: Seq[Dependency[_]] =
    List(new OneToOneDependency(queryExecution.toRdd))

SchemaRDD是一个RDD的话,那么它最重要的3个属性:compute函数,分区,依赖全在这里面,其它的函数我们就不看了。

挺奇怪的是,我们new出来的RDD,怎么会有依赖呢,这个queryExecution是啥,点击进去看看吧,代码跳转到SchemaRDD继承的SchemaRDDLike里面。

lazy val queryExecution = sqlContext.executePlan(baseLogicalPlan)

protected[sql] def executePlan(plan: LogicalPlan): this.QueryExecution =    new this.QueryExecution { val logical = plan }

把这两段很短的代码都放一起了,executePlan方法就是new了一个QueryExecution出来,那我们继续看看QueryExecution这个类吧。

    lazy val analyzed = ExtractPythonUdfs(analyzer(logical))
    lazy val optimizedPlan = optimizer(analyzed)
    lazy val sparkPlan = {
      SparkPlan.currentContext.set(self)
      planner(optimizedPlan).next()
    }
    // 在需要的时候加入Shuffle操作    lazy val executedPlan: SparkPlan = prepareForExecution(sparkPlan)
    lazy val toRdd: RDD[Row] = executedPlan.execute()

从这里可以看出来LogicPlan是经过了5个步骤的转换,要被analyzer和optimizer的处理,然后转换成SparkPlan,在执行之前还要被prepareForExecution处理一下,最后调用execute方法转成RDD.

下面我们分步讲这些个东东到底是干啥了。

首先我们看看Anayzer,它是继承自RuleExecutor的,这里插句题外话,Spark sql的作者Michael Armbrust在2013年的Spark Submit上介绍Catalyst的时候,就说到要从整体地去优化一个sql的执行是很困难的,所有设计成这种基于一个一个小规则的这种优化方式,既简单又方便维护。

好,我们接下来看看RuleExecutor的apply方法。

  def apply(plan: TreeType): TreeType = {
    var curPlan = plan
    //规则还分批次的,分批对plan进行处理
    batches.foreach { batch =>
      val batchStartPlan = curPlan

      var lastPlan = curPlan
      var continue = true

      // Run until fix point (or the max number of iterations as specified in the strategy.
      while (continue) {
        //用batch种的小规则从左到右挨个对plan进行处理
        curPlan = batch.rules.foldLeft(curPlan) {
          case (plan, rule) =>
            val result = rule(plan)
            result
        }
        iteration +=
        //超过了规定的迭代次数就要退出的
        if (iteration > batch.strategy.maxIterations) {
              continue = false
        }
        //经过处理成功的plan是会发生改变的,如果和上一次处理接触的plan一样,这说明已经没有优化空间了,可以结束,这个就是前面提到的Fixed point
        if (curPlan.fastEquals(lastPlan)) {
          continue = false
        }
        lastPlan = curPlan
      }
    }

    curPlan
  }

看完了RuleExecutor,我们继续看Analyzer,下面我只贴出来batches这块的代码,剩下的要自己去看了哦。

  val batches: Seq[Batch] = Seq(
    //碰到继承自MultiInstanceRelations接口的LogicPlan时,发现id以后重复的,就强制要求它们生成一个新的全局唯一的id
    //涉及到InMemoryRelation、LogicRegion、ParquetRelation、SparkLogicPlan
    Batch("MultiInstanceRelations", Once,
      NewRelationInstances),
    //如果大小写不敏感就把属性都变成小写
    Batch("CaseInsensitiveAttributeReferences", Once,
      (if (caseSensitive) Nil else LowercaseAttributeReferences :: Nil) : _*),
    //这个牛逼啊,居然想迭代100次的。
    Batch("Resolution", fixedPoint,
      //解析从子节点的操作生成的属性,一般是别名引起的,比如a.id
      ResolveReferences ::
      //通过catalog解析表名
      ResolveRelations ::
      //在select语言里,order by的属性往往在前面没写,查询的时候也需要把这些字段查出来,排序完毕之后再删除
      ResolveSortReferences ::
      //前面讲过了
      NewRelationInstances ::
      //清除被误认为别名的属性,比如sum(score) as a,其实它应该是sum(score)才对
      //它被解析的时候解析成Project(Seq(Alias(g: Generator, _)),直接返回Generator就可以了
      ImplicitGenerate ::
      //处理语句中的*,比如select *, count(*)
      StarExpansion ::
      //解析函数
      ResolveFunctions ::
      //解析全局的聚合函数,比如select sum(score) from table
      GlobalAggregates ::
      //解析having子句后面的聚合过滤条件,比如having sum(score) > 400
      UnresolvedHavingClauseAttributes ::
      //typeCoercionRules是hive的类型转换规则
      typeCoercionRules :_*),
    //检查所有节点的属性是否都已经处理完毕了,如果还有没解析出来的属性,这里就会报错!
    Batch("Check Analysis", Once,
      CheckResolution),
    //清除多余的操作符,现在是Subquery和LowerCaseSchema,
    //第一个是子查询,第二个HiveContext查询树里面把子节点全部转换成小写
    Batch("AnalysisOperators", fixedPoint,
      EliminateAnalysisOperators)
  )

可以看得出来Analyzer是把Unresolved的LogicPlan解析成resolved的,解析里面的表名、字段、函数、别名什么的。

我们接着看Optimizer, 从单词上看它是用来做优化的,但是从代码上来看它更多的是为了过滤我们写的一些垃圾语句,并没有做什么实际的优化。

object Optimizer extends RuleExecutor[LogicalPlan] {
  val batches =
      //递归合并相邻的两个limit
    Batch(),
      CombineLimits) ::
    Batch(),
      //替换null值
      NullPropagation,
      //替换一些简单的常量表达式,比如 1 in (1,2) 直接返回一个true就可以了
      ConstantFolding,
      //简化like语句,避免全表扫描,目前支持'%demo%', '%demo','demo*','demo'
      LikeSimplification,
      //简化过滤条件,比如true and score > 0 直接替换成score > 0
      BooleanSimplification,
      //简化filter,比如where 1=1 或者where 1=2,前者直接去掉这个过滤,后者这个查询就没必要做了
      SimplifyFilters,
      //简化转换,比如两个比较字段的数据类型是一样的,就不需要转换了
      SimplifyCasts,
      //简化大小写转换,比如Upper(Upper('a'))转为认为是Upper('a')
      SimplifyCaseConversionExpressions) ::
    Batch(),
      //递归合并相邻的两个过滤条件
      CombineFilters,
      //把从表达式里面的过滤替换成,先做过滤再取表达式,并且掉过滤里面的别名属性
      //典型的例子 select * from (select a,b from table) where a=1
      //替换成select * from (select a,b from table where a=1)
      PushPredicateThroughProject,
      //把join的on条件中可以在原表当中做过滤的先做过滤
      //比如select a,b from x join y on x.id = y.id and x.a >0 and y.b >0
      //这个语句可以改写为 select a,b from x where x.a > 0 join (select * from y where y.b >0) on x.id = y.id
      PushPredicateThroughJoin,
      //去掉一些用不上的列
      ColumnPruning) :: Nil
}

真是用心良苦啊,看来我们写sql的时候还是要注意一点的,你看人家花多大的功夫来优化我们的烂sql。。。要是我肯定不优化。。。写得烂就慢去吧!

接下来,就改看这一句了planner(optimizedPlan).next() 我们先看看SparkPlanner吧。

  protected[sql] class SparkPlanner extends SparkStrategies {
    val sparkContext: SparkContext = self.sparkContext

    val sqlContext: SQLContext = self

    def codegenEnabled = self.codegenEnabled

    def numPartitions = self.numShufflePartitions
    //把LogicPlan转换成实际的操作,具体操作类在org.apache.spark.sql.execution包下面
    val strategies: Seq[Strategy] =
      //把cache、set、expain命令转化为实际的Command
      CommandStrategy(self) ::
      //把limit转换成TakeOrdered操作
      TakeOrdered ::
      //名字有点蛊惑人,就是转换聚合操作
      HashAggregation ::
      //left semi join只显示连接条件成立的时候连接左边的表的信息
      //比如select * from table1 left semi join table2 on(table1.student_no=table2.student_no);
      //它只显示table1中student_no在表二当中的信息,它可以用来替换exist语句
      LeftSemiJoin ::
      //等值连接操作,有些优化的内容,如果表的大小小于spark.sql.autoBroadcastJoinThreshold设置的字节
      //就自动转换为BroadcastHashJoin,即把表缓存,类似hive的map join(顺序是先判断右表再判断右表)。
      //这个参数的默认值是10000
      //另外做内连接的时候还会判断左表右表的大小,shuffle取数据大表不动,从小表拉取数据过来计算
      HashJoin ::
      //在内存里面执行select语句进行过滤,会做缓存
      InMemoryScans ::
      //和parquet相关的操作
      ParquetOperations ::
      //基本的操作
      BasicOperators ::
      //没有条件的连接或者内连接做笛卡尔积
      CartesianProduct ::
      //把NestedLoop连接进行广播连接
      BroadcastNestedLoopJoin :: Nil
      ......
}

这一步是把逻辑计划转换成物理计划,或者说是执行计划了,里面有很多概念是我以前没听过的,网上查了一下才知道,原来数据库的执行计划还有那么多的说法,这一块需要是专门研究数据库的人比较了解了。剩下的两步就是prepareForExecution和execute操作。

prepareForExecution操作是检查物理计划当中的Distribution是否满足Partitioning的要求,如果不满足的话,需要重新弄做分区,添加shuffle操作,这块暂时没咋看懂,以后还需要仔细研究。最后调用SparkPlan的execute方法,这里面稍微讲讲这块的树型结构。

sql解析出来就是一个二叉树的结构,不管是逻辑计划还是物理计划,都是这种结构,所以在代码里面可以看到LogicPlan和SparkPlan的具体实现类都是有继承上面图中的三种类型的节点的。

非LeafNode的SparkPlan的execute方法都会有这么一句child.execute(),因为它需要先执行子节点的execute来返回数据,执行的过程是一个先序遍历。

最后把这个过程也用一个图来表示吧,方便记忆。

(1)通过一个Parser来把sql语句转换成Unresolved LogicPlan,目前有两种Parser,SqlParser和HiveQl。

(2)通过Analyzer把LogicPlan当中的Unresolved的内容给解析成resolved的,这里面包括表名、函数、字段、别名等。

(3)通过Optimizer过滤掉一些垃圾的sql语句。

(4)通过Strategies把逻辑计划转换成可以具体执行的物理计划,具体的类有SparkStrategies和HiveStrategies。

(5)在执行前用prepareForExecution方法先检查一下。

(6)先序遍历,调用执行计划树的execute方法。

岑玉海

转载请注明出处,谢谢!

Spark源码系列(九)Spark SQL初体验之解析过程详解的更多相关文章

  1. Spark源码系列:RDD repartition、coalesce 对比

    在上一篇文章中 Spark源码系列:DataFrame repartition.coalesce 对比 对DataFrame的repartition.coalesce进行了对比,在这篇文章中,将会对R ...

  2. Spark源码分析之Spark Shell(下)

    继上次的Spark-shell脚本源码分析,还剩下后面半段.由于上次涉及了不少shell的基本内容,因此就把trap和stty放在这篇来讲述. 上篇回顾:Spark源码分析之Spark Shell(上 ...

  3. spark 源码分析之六--Spark RPC剖析之Dispatcher和Inbox、Outbox剖析

    在上篇 spark 源码分析之五 -- Spark内置RPC机制剖析之一创建NettyRPCEnv 中,涉及到了Diapatcher 内容,未做过多的剖析.本篇来剖析一下它的工作原理. Dispatc ...

  4. spark 源码分析之八--Spark RPC剖析之TransportContext和TransportClientFactory剖析

    spark 源码分析之八--Spark RPC剖析之TransportContext和TransportClientFactory剖析 TransportContext 首先官方文档对Transpor ...

  5. 使用 IntelliJ IDEA 导入 Spark源码及编译 Spark 源代码

    1. 准备工作 首先你的系统中需要安装了 JDK 1.6+,并且安装了 Scala.之后下载最新版的 IntelliJ IDEA 后,首先安装(第一次打开会推荐你安装)Scala 插件,相关方法就不多 ...

  6. Spark源码分析之Spark Shell(上)

    终于开始看Spark源码了,先从最常用的spark-shell脚本开始吧.不要觉得一个启动脚本有什么东东,其实里面还是有很多知识点的.另外,从启动脚本入手,是寻找代码入口最简单的方法,很多开源框架,其 ...

  7. spark 源码分析之五 -- Spark内置RPC机制剖析之一创建NettyRpcEnv

    在前面源码剖析介绍中,spark 源码分析之二 -- SparkContext 的初始化过程 中的SparkEnv和 spark 源码分析之四 -- TaskScheduler的创建和启动过程 中的C ...

  8. mybatis源码学习(三):MappedStatement的解析过程

    我们之前介绍过MappedStatement表示的是XML中的一个SQL.类当中的很多字段都是SQL中对应的属性.我们先来了解一下这个类的属性: public final class MappedSt ...

  9. Apache Spark源码走读之11 -- sql的解析与执行

    欢迎转载,转载请注明出处,徽沪一郎. 概要 在即将发布的spark 1.0中有一个新增的功能,即对sql的支持,也就是说可以用sql来对数据进行查询,这对于DBA来说无疑是一大福音,因为以前的知识继续 ...

随机推荐

  1. 使用NHibernate(3)-- 用代码代替配置文件

    1,用代码配置Configure类. 上一篇“让代码跑起来”中,是通过在Web.config配置来实现Configure类的,NHibernate还提供了代码的方式. 把之前的配置都注释掉,然后修改A ...

  2. 2.利用NABCD模型进行竞争性需求分析

    1) N (Need 需求) 在宿舍里,舍友下载了一个比较好玩的游戏,一块好看的电影或者共享一个大体积的文件,而你又不想去重新下载,于是乎:‘’哎,win8怎么共享?‘’,‘’我的网上邻居怎么看不到你 ...

  3. Nginx学习笔记(八) Nginx进程启动分析

    Nginx进程启动分析 worker子进程的执行循环的函数是ngx_worker_process_cycle (src/os/unix/ngx_process_cycle.c). 其中,捕获事件.分发 ...

  4. [外挂8] 自动挂机 SetTimer函数

    >_< : 这里用SetTimer函数自动运行![注意添加在里面的回掉函数函数] UINT SetTimer( HWND hWnd, // 指向窗口句柄 UINT nIDEvent, // ...

  5. 微软MSDN订阅用户已可提前手工下载Windows 10安装包

    在Windows 10发布之夜,当全世界都在翘首以盼Windows 10免费发布推送的到来,MSDN订阅用户可以立马享受一项令人项目的特殊待遇:手工下载Windows 10完整安装包+免费使用的激活密 ...

  6. lucene如何通过docId快速查找field字段以及最近距离等信息?

    http://www.cnblogs.com/LBSer/p/4419052.html 1 问题描述 我们的检索排序服务往往需要结合个性化算法来进行重排序,一般来说分两步:1)进行粗排序,这一过程由检 ...

  7. 酷派大神F2系列使用QPST进行nv备份和恢复,解决无信号问题(附备份文件)

    测试机器: 大神F2联通版 8675_W00 系统COOLUI55     写贴原因: 自己无意间刷错了包,结果手机无信号,进入工程模式怎么设置都没有用.尝试过系统还原(备份过).刷新的ROM.线刷, ...

  8. paip.取当天记录的方法sql跟hql hibernate

    paip.取当天记录的方法sql跟hql hibernate #------两个方法...函数法和日期计算法.. 函数法: DATEDIFF(d,createTime,GETDATE())=0   / ...

  9. MultiTouch————多点触控,伸缩图片,变换图片位置

    前言:当今的手机都支持多点触控功能(可以进行图片伸缩,变换位置),但是我们程序员要怎样结合硬件去实现这个功能呢? 跟随我一起,来学习这个功能 国际惯例:先上DEMO免费下载地址:http://down ...

  10. IOS设计模式的六大设计原则之开放-关闭原则(OCP,Open-Close Principle)

    定义 一个软件实体(如类.模块.函数)应当对扩展开放,对修改关闭. 定义解读 在项目开发的时候,都不能指望需求是确定不变化的,大部分情况下,需求是变化的.那么如何应对需求变化的情况?这就是开放-关闭原 ...