/** Spark
SQL源代码分析系列文章
*/

前面讲到了Spark SQL In-Memory Columnar Storage的存储结构是基于列存储的。

那么基于以上存储结构,我们查询cache在jvm内的数据又是怎样查询的,本文将揭示查询In-Memory Data的方式。

一、引子

本例使用hive console里查询cache后的src表。
select value from src

当我们将src表cache到了内存后,再次查询src,能够通过analyzed运行计划来观察内部调用。

即parse后,会形成InMemoryRelation结点,最后运行物理计划时,会调用InMemoryColumnarTableScan这个结点的方法。

例如以下:

scala> val exe = executePlan(sql("select value from src").queryExecution.analyzed)
14/09/26 10:30:26 INFO parse.ParseDriver: Parsing command: select value from src
14/09/26 10:30:26 INFO parse.ParseDriver: Parse Completed
exe: org.apache.spark.sql.hive.test.TestHive.QueryExecution =
== Parsed Logical Plan ==
Project [value#5]
InMemoryRelation [key#4,value#5], false, 1000, (HiveTableScan [key#4,value#5], (MetastoreRelation default, src, None), None) == Analyzed Logical Plan ==
Project [value#5]
InMemoryRelation [key#4,value#5], false, 1000, (HiveTableScan [key#4,value#5], (MetastoreRelation default, src, None), None) == Optimized Logical Plan ==
Project [value#5]
InMemoryRelation [key#4,value#5], false, 1000, (HiveTableScan [key#4,value#5], (MetastoreRelation default, src, None), None) == Physical Plan ==
InMemoryColumnarTableScan [value#5], (InMemoryRelation [key#4,value#5], false, 1000, (HiveTableScan [key#4,value#5], (MetastoreRelation default, src, None), None)) //查询内存中表的入口 Code Generation: false
== RDD ==

二、InMemoryColumnarTableScan

InMemoryColumnarTableScan是Catalyst里的一个叶子结点,包括了要查询的attributes,和InMemoryRelation(封装了我们缓存的In-Columnar Storage数据结构)。
运行叶子节点,出发execute方法对内存数据进行查询。
1、查询时,调用InMemoryRelation,对其封装的内存数据结构的每一个分区进行操作。
2、获取要请求的attributes,如上,查询请求的是src表的value属性。
3、依据目的查询表达式,来获取在相应存储结构中,请求列的index索引。
4、通过ColumnAccessor来对每一个buffer进行訪问,获取相应查询数据,并封装为Row对象返回。

private[sql] case class InMemoryColumnarTableScan(
    attributes: Seq[Attribute],
    relation: InMemoryRelation)
  extends LeafNode {   override def output: Seq[Attribute] = attributes   override def execute() = {
    relation.cachedColumnBuffers.mapPartitions { iterator =>
      // Find the ordinals of the requested columns.  If none are requested, use the first.
      val requestedColumns = if (attributes.isEmpty) {
        Seq(0)
      } else {
        attributes.map(a => relation.output.indexWhere(_.exprId == a.exprId)) //依据表达式exprId找出相应列的ByteBuffer的索引
      }       iterator
        .map(batch => requestedColumns.map(batch(_)).map(ColumnAccessor(_)))//依据索引取得相应请求列的ByteBuffer,并封装为ColumnAccessor。
        .flatMap { columnAccessors =>
          val nextRow = new GenericMutableRow(columnAccessors.length) //Row的长度
          new Iterator[Row] {
            override def next() = {
              var i = 0
              while (i < nextRow.length) {
                columnAccessors(i).extractTo(nextRow, i) //依据相应index和长度,从byterbuffer里取得值,封装到row里
                i += 1
              }
              nextRow
            }             override def hasNext = columnAccessors.head.hasNext
          }
        }
    }
  }
}

查询请求的列,例如以下:

scala> exe.optimizedPlan
res93: org.apache.spark.sql.catalyst.plans.logical.LogicalPlan =
Project [value#5]
InMemoryRelation [key#4,value#5], false, 1000, (HiveTableScan [key#4,value#5], (MetastoreRelation default, src, None), None) scala> val relation = exe.optimizedPlan(1)
relation: org.apache.spark.sql.catalyst.plans.logical.LogicalPlan =
InMemoryRelation [key#4,value#5], false, 1000, (HiveTableScan [key#4,value#5], (MetastoreRelation default, src, None), None) scala> val request_relation = exe.executedPlan
request_relation: org.apache.spark.sql.execution.SparkPlan =
InMemoryColumnarTableScan [value#5], (InMemoryRelation [key#4,value#5], false, 1000, (HiveTableScan [key#4,value#5], (MetastoreRelation default, src, None), None)) scala> request_relation.output //请求的列,我们请求的仅仅有value列
res95: Seq[org.apache.spark.sql.catalyst.expressions.Attribute] = ArrayBuffer(value#5) scala> relation.output //默认保存在relation中的全部列
res96: Seq[org.apache.spark.sql.catalyst.expressions.Attribute] = ArrayBuffer(key#4, value#5) scala> val attributes = request_relation.output
attributes: Seq[org.apache.spark.sql.catalyst.expressions.Attribute] = ArrayBuffer(value#5)
整个流程非常简洁,关键步骤是第三步。依据ExprId来查找到,请求列的索引
attributes.map(a => relation.output.indexWhere(_.exprId == a.exprId))
//依据exprId找出相应ID
scala> val attr_index = attributes.map(a => relation.output.indexWhere(_.exprId == a.exprId))
attr_index: Seq[Int] = ArrayBuffer(1) //找到请求的列value的索引是1, 我们查询就从Index为1的bytebuffer中,请求数据 scala> relation.output.foreach(e=>println(e.exprId))
ExprId(4) //相应<span style="font-family: Arial, Helvetica, sans-serif;">[key#4,value#5]</span>
ExprId(5) scala> request_relation.output.foreach(e=>println(e.exprId))
ExprId(5)

三、ColumnAccessor

ColumnAccessor相应每一种类型,类图例如以下:

最后返回一个新的迭代器:

          new Iterator[Row] {
override def next() = {
var i = 0
while (i < nextRow.length) { //请求列的长度
columnAccessors(i).extractTo(nextRow, i)//调用columnType.setField(row, ordinal, extractSingle(buffer))解析buffer
i += 1
}
nextRow//返回解析后的row
} override def hasNext = columnAccessors.head.hasNext
}

四、总结

Spark SQL In-Memory Columnar Storage的查询相对来说还是比較简单的,其查询思想主要和存储的数据结构有关。

即存储时,按每列放到一个bytebuffer,形成一个bytebuffer数组。

查询时,依据请求列的exprId查找到上述数组的索引,然后使用ColumnAccessor对buffer中字段进行解析,最后封装为Row对象,返回。

——EOF——

原创文章,转载请注明出自:http://blog.csdn.net/oopsoom/article/details/39577419

Spark SQL 源代码分析之 In-Memory Columnar Storage 之 in-memory query的更多相关文章

  1. Spark SQL 源代码分析系列

    从决定写Spark SQL文章的源代码分析,到现在一个月的时间,一个又一个几乎相同的结束很快,在这里也做了一个综合指数,方便阅读,下面是读取顺序 :) 第一章 Spark SQL源代码分析之核心流程 ...

  2. Spark SQL源代码分析之核心流程

    /** Spark SQL源代码分析系列文章*/ 自从去年Spark Submit 2013 Michael Armbrust分享了他的Catalyst,到至今1年多了,Spark SQL的贡献者从几 ...

  3. Spark SQL 源代码分析之Physical Plan 到 RDD的详细实现

    /** Spark SQL源代码分析系列文章*/ 接上一篇文章Spark SQL Catalyst源代码分析之Physical Plan.本文将介绍Physical Plan的toRDD的详细实现细节 ...

  4. Spark SQL概念学习系列之Spark SQL 架构分析(四)

    Spark SQL 与传统 DBMS 的查询优化器 + 执行器的架构较为类似,只不过其执行器是在分布式环境中实现,并采用的 Spark 作为执行引擎. Spark SQL 的查询优化是Catalyst ...

  5. Spark Core源代码分析: Spark任务运行模型

    DAGScheduler 面向stage的调度层,为job生成以stage组成的DAG,提交TaskSet给TaskScheduler运行. 每个Stage内,都是独立的tasks,他们共同运行同一个 ...

  6. Spark Core源代码分析: RDD基础

    RDD RDD初始參数:上下文和一组依赖 abstract class RDD[T: ClassTag]( @transient private var sc: SparkContext, @tran ...

  7. Spark Core源代码分析: Spark任务模型

    概述 一个Spark的Job分为多个stage,最后一个stage会包含一个或多个ResultTask,前面的stages会包含一个或多个ShuffleMapTasks. ResultTask运行并将 ...

  8. Spark SQL Catalyst源代码分析之TreeNode Library

    /** Spark SQL源代码分析系列文章*/ 前几篇文章介绍了Spark SQL的Catalyst的核心执行流程.SqlParser,和Analyzer,本来打算直接写Optimizer的,可是发 ...

  9. Spark SQL Catalyst源代码分析Optimizer

    /** Spark SQL源代码分析系列*/ 前几篇文章介绍了Spark SQL的Catalyst的核心运行流程.SqlParser,和Analyzer 以及核心类库TreeNode,本文将具体解说S ...

随机推荐

  1. QT VS检测内存泄漏

    测试程序:http://download.csdn.net/detail/ajaxhe/4085447 vld-2.2.3: http://vld.codeplex.com/releases/view ...

  2. PencilDraw: 用简化的C语言画图!

    最近做的一个东西,不过功能还不是太完善,而且界面极丑.慢慢改进吧. 点这里打开!

  3. 雪佛兰Suburban_百度百科

    雪佛兰Suburban_百度百科 雪佛兰Suburban

  4. Android中通过进程注入技术改动广播接收器的优先级

    前言 这个周末又没有吊事,在家研究了怎样通过进程的注入技术改动广播接收器的优先级.关于这个应用场景是非常多的.并且也非常重要.所以就非常急的去fixed了. Android中的四大组件中有一个广播:B ...

  5. Oracle执行计划——处理一种并行hint不生效的情况

    刚刚在itpub上看到有人在问并行hint不生效的一个问题.我做了实验也出现一样的问题,如下: 原因在这是小表,在联合时走索引了,加上full的hint,就可以启动并行的执行计划. 当然也可以采用pa ...

  6. Xcode插件(一)-规范注释生成器VVDocumenter

    原文来自:http://blog.csdn.net/hitwhylz/article/details/27813315 分享几个常用的Xcode插件. 第一个, 规范注释生成器VVDocumenter ...

  7. linux 下搭建 ftp

    最近为了方便目标板与PC机上LINUX之间的通讯,就在LINUX搭建了FTP,工作不难,写个总结.主要经过以下几个步骤: 1.检查是否安装了vsftpd服务器 可以用rpm -q vsftpd命令来查 ...

  8. XCode 6 出现 no identity found: Command /usr/bin/codesign failed with exit code 1 解决方法汇总

    1, 解决办法,进入开发者账号重建一个 Provisioning Profiles(或配套证书) 文件,把证书添加正确就可以了 (应该是最有效的) 2, 将p12文件重新安装下 3, 在 iPhone ...

  9. ELK 之二:ElasticSearch 和Logstash高级使用

    一:文档 官方文档地址:1.x版本和2.x版本 https://www.elastic.co/guide/en/elasticsearch/guide/index.html 硬件要求: 1.内存,官方 ...

  10. net core开发环境准备

    net core开发环境准备 1.1  安装sdk和运行时 浏览器打开网址https://www.microsoft.com/net/download, 到.Net Core下载页面. 根据操作系统, ...