SQL on Hadoop 技术分析(二)

森哥大作,接上一篇:SQL on Hadoop技术分析(一)

SQL on Hadoop 技术分析(二)

本篇继续分析SQL on Hadoop的相关技术,本次分析的重点是查询优化器(技术上的名词叫SQL Parser),在SQL on Hadoop技术中有着非常重要的地位,一次查询SQL下来,SQL Parser分析SQL词法,语法,最终生成执行计划,下发给各个节点执行,SQL的执行的过程快慢,跟生成的执行计划的好坏,有直接的关系,下面以目前业界SQL onHadoop 使用的比较多的组件Impala、HAWQ,Spark SQL来介绍下它们的查询优化器技术。

Impala:

SQL支持度:

支持SQL92中的大部分select语句, 以及SQL2003标准中的分析函数。 不支持DELETE和UPDATE, 但是支持批量装载数据(insert into select, LOADDATA) 和批量删除数据(drop partition)。除此之外, 用户也可直接操作HDFS文件实现数据装载和清理。

查询执行:

impalad分为frontend和backend两个层次, frontend用java实现(通过JNI嵌入impalad), 负责查询计划生成, 而backend用C++实现, 负责查询执行。Impala的查询流程如下图所示

frontend生成查询计划分为两个阶段:(1)生成单机查询计划,单机执行计划与关系数据库执行计划相同,所用查询优化方法也类似。(2)生成分布式查询计划。根据单机执行计划, 生成真正可执行的分布式执行计划,降低数据移动, 尽量把数据和计算放在一起。

下面以一个三表join的例子生成的执行计划来说明下Impala组件的在SQL执行过程中的相关的性能优化的技术点。

上图是SQL查询例子, 该SQL的目标是在三表join的基础上算聚集, 并按照聚集列排序取topN。 impala的查询优化器支持代价模型: 利用表和分区的cardinality,每列的distinct值个数等统计数据, impala可估算执行计划代价, 并生成较优的执行计划。上图左边是frontend查询优化器生成的单机查询计划, 与传统关系数据库不同, 单机查询计划不能直接执行, 必须转换成如图右半部分所示的分布式查询计划。该分布式查询计划共分成6个segment(图中彩色无边框圆角矩形),每个segment是可以被单台服务器独立执行的计划子树。

impala支持两种分布式join方式, 表广播和哈希重分布:表广播方式保持一个表的数据不动,将另一个表广播到所有相关节点(图中t3); 哈希重分布的原理是根据join字段哈希值重新分布两张表数据(譬如图中t1和t2)。分布式计划中的聚集函数分拆为两个阶段执行。第一步针对本地数据进行分组聚合(Pre-AGG)以降低数据量, 并进行数据重分步, 第二步, 进一步汇总之前的聚集结果(mergeAgg)计算出最终结果。与聚集函数类似, topN也是分为两个阶段执行, (1)本地排序取topN,以降低数据量; (2)merge sort得到最终topN结果。

Backend从frontend接收plan segment并执行, 执行性能非常关键,impala采取的查询性能优化措施有:

1) 向量执行。 一次getNext处理一批记录, 多个操作符可以做pipeline。

2)LLVM编译执行, CPU密集型查询效率提升几倍以上,具体看执行的SQL查询场景。

3)IO本地化。 利用HDFS short-circuit local read功能,实现本地文件读取

4)Parquet列存,充分利用列式存储的优势。

HAWQ:

HAWQ支持Apache Hadoop原生HDFS的SQL大规模并行引擎(MPP SQL) ,跟Impala组件类似,也是一种采用类似MPP DB技术实现的。HAWQ是基于GreenplumMPP数据库技术实现的,同样采用了Greenplum数据库的SQL查询优化器,下面以运行于HAWQ 解析器中的SQL查询分析HAWQ的查询机制,如下图所示:

HAWQ数据库层会对SQL查询加以解析并最终作用于HDFS,一旦查询请求出现,我们会对它进行解析并生成解析树,接下来发生的情况 非常特殊。HAWQ获取生成的解析树并从通用目录服务中获取元数据。HAWQ会根据底层Hadoop集群的运行状态获取成本模型,这套模型了解存储资源性能、掌握各项数据的访问成本以及数据的专有排列方式。根据上述信息,它会发送一套资源模型,并以此为指导生成查询执行规划,如下图所示:

SQL查询进入能与HDFS顺利交互的并行优化器,整个流程展示了一项重大内容,基于成本模型(Cost Model)的优化方案。之后生成的查询计划如下图所示:

接下来HAWQ的主节点Master下发执行计划给Query Executor执行,查询执行器利用HDFS NameNode将工作内容传递至HAWQ数据库的使用空间之中,如下图所示:

HAWQ的秘密在于这套数据库层实际是一条动态传输途径,其中结合了Greenplum作为并行关系类数据库(主要作为PostgreSQL的替代方案)所准备的多项不同技术,如下图所示:

动态传输途径算是一套专为查询请求打造的工作调度机制(与Hadoop中的NameNode及JobTracker有所区别),其作用是以最优方式对查询进行安排及部署。在Hadoop NameNode所引导的恰当数据块中加以执行之后,这些查询会返回至NameNode处,查询结果则被提交给发出SQL查询的软件。这种动态传输途径使HAWQ在性能上获得了极其可观的优势,它所带来的SQL查询处理速度能够达到Hive等同样支持HDFS方案的十倍甚至六百倍。另外,如此规模的性能提升也成功将Hadoop从原本的批处理式系统转化为交互式系统。

Spark SQL

SparkSQL是Spark组件中的一部分,Spark SQL的查询优化器项目叫Spark Catalyst,在Spark SQL担任的角色是优化器,Spark SQL在2015年sigmod上发了一篇论文。论文中对查询优化器做了比较详细的介绍,先看下SparkSQL与Spark交互的架构图,如下图所示:

在论文中看到查询优化器中介绍的各个角色,分别为Parser、Analyzer、Optimizer、Planner

同样,在论文中已经提及到了这些角色的作用, 其中parser负责把用户输入的SQL语句进行解释,转变为Unresolved Logical Plan。Unresolved Logical Plan中会包含SQL语句中出现的变量名和表名,这些词素暂时来讲都会被标记为unresolved,即“不知道是否存在这个表”或“不知道表中是否有这个字段”。这个时候轮到Analyzer登场,它利用Catalog提供的信息, 对所有这些unresolved的词素进行resolve,并在resolve失败时抛出错误。结束后便得到了Analyzed Logical Plan。接下来轮到Optimizer, 它使用rule-based的优化规则对传入的Analyzed Logical Plan进行优化,得到一个OptimizedLogical Plan。最终Optimized Logical Plan传入到Planner, 生成物理执行计划,得到Physical Plan。具体流程入如下图所示:

同样Spark SQL采用的性能优化措施还有数据的存储格式(比如Parquet格式,还有华为研发并开源的CarbonData数据格式),Codegen等技术,另外最新的Spark2.0版本对Catalyst有进一步优化提升,具体可以看Spark2.0的官网上的介绍。

总结:

本文主要介绍了几种常用的SQL onHadoop组件的查询优化器的相关技术,其它组件如Apache Drill等等也同样有自己的查询优化器,这些技术未来将会变得越来越成熟,越来越方便用户的使用,相应的,用户将会变得更加容易,更加方便的从自己的大数据中挖掘出有价值的商业信息。

原文发布于微信公众号 - 大数据和云计算技术(jiezhu2007)

原文发表时间:2016-07-18

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏文渊之博

数据仓库中如何使用索引

数据仓库的索引是个棘手的问题。如果索引太多,数据插入很快但是查询响应就会很慢。如果太多索引,数据导入就很慢并且数据存储空间更大,但是查询响应更快。数据库中索引的...

1847
来自专栏james大数据架构

几十条业务线日志系统如何收集处理?

  在互联网迅猛发展的今天 各大厂发挥十八般武艺的收集用户的各种信息,甚至包括点击的位置,我们也经常发现自己刚搜完一个东西,再打开网页时每个小广告都会出现与之相...

26310
来自专栏数据和云

【云和恩墨大讲堂】玩转AWR裸数据(下)

讲师简介: ? 罗海雄 云和恩墨性能优化总监 ITPUB论坛数据库管理版版主,2012 ITPUB全国SQL大赛冠军得主,他还是资深的架构师和性能优化专家,对 ...

2663
来自专栏ml

flume介绍与原理(一)

1 .背景   flume是由cloudera软件公司产出的可分布式日志收集系统,后与2009年被捐赠了apache软件基金会,为hadoop相关组件之一。尤其...

37215
来自专栏杨建荣的学习笔记

使用shell来定制dbms_sqltune(r7笔记第39天)

在sql调优中使用dbms_sqltune是一个很高效的工具,如果说awr发现了性能问题sql,addm可以给出调优建议,sql monitor能够监控性能问...

3124
来自专栏华仔的技术笔记

iOS应用架构谈 网络层设计方案

网络层在一个App中也是一个不可缺少的部分,工程师们在网络层能够发挥的空间也比较大。另外,苹果对网络请求部分已经做了很好的封装,业界的AFNetworking也...

3259
来自专栏HappenLee的技术杂谈

大数据小视角1:从行存储到RCFile

数据的布局结构深刻的影响着数据处理的效率与性能,在底层的存储系统之中如何组织数据。如何对数据进行布局会直接影响数据查询引擎的设计与实现,并且也影响着存储空间的利...

862
来自专栏cloudskyme

hbase实战——(1.1 nosql介绍)

什么是nosql NoSQL(NoSQL = Not Only SQL),意思是不仅仅是SQL的扩展,一般指的是非关系型的数据库。 随着互联网web2.0网站的...

3398
来自专栏欧阳大哥的轮子

深入iOS系统底层之指令集介绍

说到指令集以及CPU架构体系,大家就会想到计算机专业课程里面的计算机体系结构的方面的内容。既然课程中已经有了的内容我就不想那么枯燥的去复述一遍,而是先看一个类的...

521
来自专栏CSDN技术头条

分析型数据仓库中读写分离的实现

和以 MySQL 为代表的传统事务型数据库相比,数据仓库有一个很大的特点,就是主要面向批量写和查询进行优化,可以不支持更新、事务这些高级特性。一些商用的数据仓库...

1959

扫码关注云+社区