Spark SQL 源代码分析之 In-Memory Columnar Storage 之 in-memory query

2023-10-11 10:10
文章标签 sql 分析 memory 源代码 database spark query storage columnar

本文主要是介绍Spark SQL 源代码分析之 In-Memory Columnar Storage 之 in-memory query，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

    /** 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] = attributesoverride 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 = 0while (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 = 0while (i < nextRow.length) { //请求列的长度columnAccessors(i).extractTo(nextRow, i)//调用columnType.setField(row, ordinal, extractSingle(buffer))解析bufferi += 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

转载于:https://www.cnblogs.com/bhlsheji/p/4266025.html

这篇关于Spark SQL 源代码分析之 In-Memory Columnar Storage 之 in-memory query的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！


http://www.chinasem.cn/article/187308。

相关文章

MySQL主从同步延迟问题的全面解决方案

MySQL主从同步延迟问题的全面解决方案

《MySQL主从同步延迟问题的全面解决方案》MySQL主从同步延迟是分布式数据库系统中的常见问题,会导致从库读取到过期数据,影响业务一致性,下面我将深入分析延迟原因并提供多层次的解决方案,需要的朋友可... 目录一、同步延迟原因深度分析1.1 主从复制原理回顾1.2 延迟产生的关键环节二、实时监控与诊断方案
阅读更多...
慢sql提前分析预警和动态sql替换-Mybatis-SQL

慢sql提前分析预警和动态sql替换-Mybatis-SQL

《慢sql提前分析预警和动态sql替换-Mybatis-SQL》为防止慢SQL问题而开发的MyBatis组件,该组件能够在开发、测试阶段自动分析SQL语句,并在出现慢SQL问题时通过Ducc配置实现动... 目录背景解决思路开源方案调研设计方案详细设计使用方法1、引入依赖jar包2、配置组件XML3、核心配
阅读更多...
Java NoClassDefFoundError运行时错误分析解决

Java NoClassDefFoundError运行时错误分析解决

《JavaNoClassDefFoundError运行时错误分析解决》在Java开发中,NoClassDefFoundError是一种常见的运行时错误,它通常表明Java虚拟机在尝试加载一个类时未能... 目录前言一、问题分析二、报错原因三、解决思路检查类路径配置检查依赖库检查类文件调试类加载器问题四、常见
阅读更多...
MySQL数据库约束深入详解

MySQL数据库约束深入详解

《MySQL数据库约束深入详解》：本文主要介绍MySQL数据库约束,在MySQL数据库中,约束是用来限制进入表中的数据类型的一种技术,通过使用约束,可以确保数据的准确性、完整性和可靠性,需要的朋友... 目录一、数据库约束的概念二、约束类型三、NOT NULL 非空约束四、DEFAULT 默认值约束五、UN
阅读更多...
MySQL 多表连接操作方法(INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL OUTER JOIN)

MySQL 多表连接操作方法(INNER JOIN、LEFT JOIN、RIGHT JOIN、FULL OUTER JOIN)

《MySQL多表连接操作方法(INNERJOIN、LEFTJOIN、RIGHTJOIN、FULLOUTERJOIN)》多表连接是一种将两个或多个表中的数据组合在一起的SQL操作,通过连接,... 目录一、 什么是多表连接？二、 mysql 支持的连接类型三、 多表连接的语法四、实战示例 数据准备五、连接的性
阅读更多...
MySQL中的分组和多表连接详解

MySQL中的分组和多表连接详解

《MySQL中的分组和多表连接详解》：本文主要介绍MySQL中的分组和多表连接的相关操作,本文通过实例代码给大家介绍的非常详细,感兴趣的朋友一起看看吧... 目录mysql中的分组和多表连接一、MySQL的分组（group javascriptby ）二、多表连接（表连接会产生大量的数据垃圾）MySQL中的
阅读更多...
Python中的Walrus运算符分析示例详解

Python中的Walrus运算符分析示例详解

《Python中的Walrus运算符分析示例详解》Python中的Walrus运算符（:=）是Python3.8引入的一个新特性,允许在表达式中同时赋值和返回值,它的核心作用是减少重复计算,提升代码简... 目录1. 在循环中避免重复计算2. 在条件判断中同时赋值变量3. 在列表推导式或字典推导式中简化逻辑
阅读更多...
MySQL 中的 JSON 查询案例详解

MySQL 中的 JSON 查询案例详解

《MySQL中的JSON查询案例详解》：本文主要介绍MySQL的JSON查询的相关知识,本文给大家介绍的非常详细,对大家的学习或工作具有一定的参考借鉴价值,需要的朋友参考下吧... 目录mysql 的 jsON 路径格式基本结构路径组件详解特殊语法元素实际示例简单路径复杂路径简写操作符注意MySQL 的 J
阅读更多...
Windows 上如果忘记了 MySQL 密码 重置密码的两种方法

Windows 上如果忘记了 MySQL 密码 重置密码的两种方法

《Windows上如果忘记了MySQL密码重置密码的两种方法》：本文主要介绍Windows上如果忘记了MySQL密码重置密码的两种方法,本文通过两种方法结合实例代码给大家介绍的非常详细,感... 目录方法 1：以跳过权限验证模式启动 mysql 并重置密码方法 2：使用 my.ini 文件的临时配置在 Wi
阅读更多...
MySQL重复数据处理的七种高效方法

MySQL重复数据处理的七种高效方法

《MySQL重复数据处理的七种高效方法》你是不是也曾遇到过这样的烦恼：明明系统测试时一切正常,上线后却频频出现重复数据,大批量导数据时,总有那么几条不听话的记录导致整个事务莫名回滚,今天,我就跟大家分... 目录1. 重复数据插入问题分析1.1 问题本质1.2 常见场景图2. 基础解决方案：使用异常捕获3.
阅读更多...

Copyright China编程 23002807@qq.com

沪ICP备2023033072号-2