1. 程式人生 > 其它 >Spark原始碼系列(九)Spark SQL初體驗之解析過程詳解

Spark原始碼系列(九)Spark SQL初體驗之解析過程詳解

好久沒更新部落格了,之前學了一些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 iteration = 1
      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 += 1
        //超過了規定的迭代次數就要退出的
        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("Combine Limits", FixedPoint(100),
      CombineLimits) ::
    Batch("ConstantFolding", FixedPoint(100),
      //替換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("Filter Pushdown", FixedPoint(100),
      //遞迴合併相鄰的兩個過濾條件
      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方法。