大数据平台的SQL查询引擎有哪些(一)

本文涉及的产品
云原生大数据计算服务 MaxCompute,5000CU*H 100GB 3个月
云原生大数据计算服务MaxCompute,500CU*H 100GB 3个月
云解析 DNS,旗舰版 1个月
简介: 大数据平台的SQL查询引擎有哪些

前言


大数据平台中Hadoop的分布式文件系统(HDFS)之上形成了一种极具特色的技术群体,那就是SQL查询引擎。这就包括了Hive、Impala、Presto、Spark SQL等;在分布式数据库HBase也具有Impala、phoenix这样的SQL外观,可以通过SQL与HBase交互;另外分布式关系模型数据库(NewSQL),例如:cockroachdb的sql layer、TiDB的tidb模块等在自身架构体系中不仅是查询引擎,也是SQL插入、更新和删除的SQL执行引擎。


作为海量数据计算存储平台,特别容易提出的一个概念就是NoSQL,可是从上面的发展看,不像No SQL么,感觉像是:这个世界没法NoSQL,以前我有篇文章,深入分析了关系模型的真正价值。


我把这篇文章中的一小段摘录出来,回顾一下关系模型是什么:


关系型模型之父Edgar F. Codd,在1970年发表了《大型共享数据库数据的关系模型》 原始的关系模型:


(1)结构(structure)


(2)完整性(integrity)


(3)操作(manipulation)


原始理论具体到实现再翻译成我们好理解的描述:


结构:就是我们经常要先对数据库预先定义的表名和字段(名称、类型)


完整性:就是表的主键不能为空,表与表之间的主/外键关联必须保证是完整的,外键一定是能找到主键的。


操作:那就是SQL表达式啦,SQL的子查询就是典型的闭包(Closure),可以形成嵌套表达式。


文章链接:

HDFS/HBase技术报告·分布式数据库设计架构的全面解析https://blog.csdn.net/u011457868/article/details/115896789?spm=1001.2014.3001.5502

https://blog.csdn.net/u011457868/article/details/115896789?spm=1001.2014.3001.5502


因此SQL只是关系模型的一种具体实现。我们只是在大数据领域需要替换关系型数据库的存储逻辑,使得数据库更分布式化,更容易实现存储架构的扩展。因为这是单机存储与计算到了天花板后,必须横向扩展的硬需求,但这也并不是说关系模型过时了!


实际上Hadoo的HDFS、HBase提供的Java接口也好,Spark提供的Java、Scala、Python接口也好,这都需要使用者至少懂一门编程语言才行,Python虽然易学易懂,但也只限于Spark的原生支持,而且Python好歹也是个面向对象编程语言正规军,至少也得让使用者明白什么是面向对象吧?那对于科学家、科研人员、数据分析师、数据运维工程师,学生,基本都是大数据的主要使用者,编程接口的方式对于他们就极为不友好了。这时候再看SQL,老少皆宜,不分阶层,大家好,才是真的好!对吧。


SQL查询引擎架构 Hive-ON-Hadoop


在SQL-ON-Hadoop架构中,Hive依然是成熟度最高SQL引擎,有些文章也把它叫做数仓工具,总之Hive已经从SQL解释器发展成为独立性很高的SQL引擎层,仍依赖Hadoop HDFS存储层,但摆脱了执行层Mapreduce计算引擎的束缚,形成可替换的计算引擎层,可以将MapReduce引擎替换成Tez、Spark。


为什么要替换MapReduce呢?就是因为MapReduce对数据写进写出的方式太过生硬,直接用磁盘作为计算中间过程的数据存储,导致分布式并行处理的性能很差。并行计算在磁盘上进行,其实也是一把双刃剑,不能一味地认为Mapreduce性能差,对于超大规模数据量的批处理,内存是放不下的,所有基于内存模型的并行处理引擎,都会因为内存不够,将需要处理的数据吐到磁盘上,这反而加重了I/O的吞吐,导致不佳的性能。但是在足够的内存条件下,中小数据量的批处理上,基于内存的计算引擎会非常快地给出结果,所以这是必然趋势。


Tez的性能比起MR很快,我在实际环境中也测试过,不仅是内存计算带来的性能提升,它在执行数据处理前比MR引擎有自动的优化策略,以后会成为Hive的默认执行引擎,Hive 执行引擎也可以替换成Spark,即Hive-on-Spark。但是我认为在新项目中直接就是Spark-SQL就够了,没必要再搞个Hive,因为底层都是Spark。Hive-on-Spark的主要目标是那些已经部署实施的Hive系统,通过Spark对Mr的替换,极大提升查询分析速度。


如下图所示:Hive依赖Hadoop,左边是Hive SQL查询过程,右边是Hadooop协作过程。


4839f8accbcaae9e9fea506ca4d154da.jpg


第一阶段:Hive接收UI的SQL查询,进入Driver和Compiler进行SQL解析并生成执行计划。并发送执行计划给Hive执行引擎(Execution engine)。


第二阶段:主要是在Hive执行引擎将执行计划形成阶段DAG,调度进Hadoop。


第三阶段:Hadoop的MR执行引擎中实现Map和Reduce的任务执行,并且将过程产生的临时数据保留在HDFS。


第四阶段:最终计算结果由Hive执行引擎从HDFS中取出,并发送结果到Driver,再由Driver返回结果给UI。


Impala


曾经Google公开了两篇论文,一篇涉及F1支持容错的分布式SQL数据库,另一篇涉及名为Dremel的可扩展的交互式即时查询引擎,在前者的指引下,出现了像PingCAP公司的开源分布式关系数据库TiDB,可以看这篇文章:每日一答:CAP 理论常被解释为“三选二”定律,是否是一种误解?对Spanner/F1容错设计的简描述。在后者的启发下,2012年发布了Hadoop之上的开源、低延迟SQL查询引擎Impala。


Impala有几个特点:


支持HDFS、HBase作为数据源。


复用HiveSQL方言,使用Hive元数据服务,因此Hive表一次定义,Hive、Impala皆可使用。


Impala的查询延迟比Hive+mapreduce要低得多。


Impala架构是无共享模式,因此支持系统级容错性和强大的可扩张性。


Impala也是基于内存的计算引擎,多个处理阶段的中间过程,数据会保存在内存中,2.0版本之后支持大数据量内存与磁盘I/O数据交换。


Impala是以后台服务的形成长期运行,一般推荐Impala服务在HDFS的DataNode节点上运行,保证计算尽量在本地读取数据,减少网络传输。


Impala是C++语言实现,可以充分利用机器内存,单个Impala进程不用像Java程序那样,受限于JVM垃圾回收机制的延迟影响。


Impala具有一项高性能的查询黑科技:底层虚拟机(Low Level Virtual Machine, LLVM)编译查询,可以将查询方法编译成优化的机器码,提高CPU对代码的执行性能。


Impala架构如下图所示:impala后台服务(Impalad)尽量在数据节点上运行(HDFS的Datanode,DD、HBase);每个Impalad包含了查询规划器(Query Planner)、查询规划器(Query Coordinator)和查询执行器(Query Exec Engine)


e06bd461247989d7da185e2117502a63.jpg


第一步查询规划器用于解析由JDBC、ODBC、impala-shell或者Thrift等客户端请求的SQL语句,产生执行计划规划器。


第二步连接到当前客户端的查询规划器将执行计划将不同执行部分分配到各个Impalad中。


第三部各个Impalad将获取到的部分执行计划,并交给查询执行引擎,访问本地HDFS DD或HBase数据,实现大规模并行处理(MPP),完成查询处理后返回结果,由原计划分发点实现汇聚与回应客户端结果。


Impala VS Presto


架构对比


2013年Facebook开源了Presto,支持标准ANSI SQL。Presto的特点特别适合与Impala做一个比较。


首先如果把Impala比喻成一位用情专一的君子,那么Presto就是处处留情的公子。Impala用于查询的主要基础存储系统就是Hadoop HDFS与HBase,我们再看看Presto都设计了多少种存储连接:


Accumulo Connector |基于HDFS的K-V存储


BigQuery Connector  |Google的大数据查询引擎云服务


Cassandra Connector


Druid Connector | 实时分析型数据库


Elasticsearch Connector


Hive Connector


Kafka Connector


Kudu Connector    |基于HDFS的列式快速分析存储系统


Local File Connector


Memory Connector |直接在内存中建立数据表进行操作


MongoDB Connector


MySQL Connector


Oracle Connector


PostgreSQL Connector


Redis Connector


SQL Server Connector


Thrift Connector    |远程过程调用RPC框架


......


但是有一点我感到很不解,Presto都支持那么多存储系统和框架了,而且最早的设计初衷就是为了Hadoop HDFS的高效查询,既然Impala都是直接支持HBase了,为什么Presto不支持HBase呢?有了解情况的朋友还希望给予指点。如下图所示:


aa5d1b15a47623378a80ccc888e3338d.png


其次,Impala更像是一个传统的大规模并行处理(MPP)数仓工具,每个进程都是独立接受客户端请求的,客户端连接到哪个服务,该服务就作为分布式调度者,大家可以看看上篇中的Impala架构图。


但是Presto就是一个标准的主从架构了,客户端要先与主节点打交道,主节点再将SQL解释后的执行计划分配到不同的work节点去执行,并由一个work节点作为结果汇聚返回节点,如下图所示:


94bf423f876f30b12c2530c86be0f159.png


最后,我们再看看Impala和Presto在SQL解释、优化和调度之间的对比。如下图所示:左边是Impala架构,右边是Presto架构。


29f41951e6656aaa8948847e1ec0c3e4.png


上篇已经描述过Impala主要是任意连接客户端的Impalad后台服务,接收SQL请求,解析SQL并制定执行计划后,由当前节点在Query Coordinator阶段对执行计划各个部分进行调度分配,再由集群其他Impalad后台服务根据调度进入Query Exec Engine阶段实现并行处理。最终结果还是汇聚到调度节点反馈客户端。


Presto获取用户提交的SQL查询,首先进行SQL语句解析( Parser),接着形成逻辑计划相关对象(Planner)放入线程池,最后由调度器(Scheduler)对逻辑计划生成的SubPlan提交到多个Work节点上执行。


相关实践学习
基于MaxCompute的热门话题分析
本实验围绕社交用户发布的文章做了详尽的分析,通过分析能得到用户群体年龄分布,性别分布,地理位置分布,以及热门话题的热度。
SaaS 模式云数据仓库必修课
本课程由阿里云开发者社区和阿里云大数据团队共同出品,是SaaS模式云原生数据仓库领导者MaxCompute核心课程。本课程由阿里云资深产品和技术专家们从概念到方法,从场景到实践,体系化的将阿里巴巴飞天大数据平台10多年的经过验证的方法与实践深入浅出的讲给开发者们。帮助大数据开发者快速了解并掌握SaaS模式的云原生的数据仓库,助力开发者学习了解先进的技术栈,并能在实际业务中敏捷的进行大数据分析,赋能企业业务。 通过本课程可以了解SaaS模式云原生数据仓库领导者MaxCompute核心功能及典型适用场景,可应用MaxCompute实现数仓搭建,快速进行大数据分析。适合大数据工程师、大数据分析师 大量数据需要处理、存储和管理,需要搭建数据仓库?学它! 没有足够人员和经验来运维大数据平台,不想自建IDC买机器,需要免运维的大数据平台?会SQL就等于会大数据?学它! 想知道大数据用得对不对,想用更少的钱得到持续演进的数仓能力?获得极致弹性的计算资源和更好的性能,以及持续保护数据安全的生产环境?学它! 想要获得灵活的分析能力,快速洞察数据规律特征?想要兼得数据湖的灵活性与数据仓库的成长性?学它! 出品人:阿里云大数据产品及研发团队专家 产品 MaxCompute 官网 https://www.aliyun.com/product/odps 
相关文章
|
1天前
|
SQL 消息中间件 分布式计算
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(一)
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(一)
12 0
|
1天前
|
SQL 大数据
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(二)
大数据-143 - ClickHouse 集群 SQL 超详细实践记录!(二)
13 0
|
1天前
|
SQL 大数据 API
大数据-132 - Flink SQL 基本介绍 与 HelloWorld案例
大数据-132 - Flink SQL 基本介绍 与 HelloWorld案例
10 0
|
1天前
|
SQL 分布式计算 大数据
大数据-97 Spark 集群 SparkSQL 原理详细解析 Broadcast Shuffle SQL解析过程(一)
大数据-97 Spark 集群 SparkSQL 原理详细解析 Broadcast Shuffle SQL解析过程(一)
9 0
|
1天前
|
SQL 分布式计算 算法
大数据-97 Spark 集群 SparkSQL 原理详细解析 Broadcast Shuffle SQL解析过程(二)
大数据-97 Spark 集群 SparkSQL 原理详细解析 Broadcast Shuffle SQL解析过程(二)
11 0
|
1天前
|
SQL 分布式计算 Java
大数据-96 Spark 集群 SparkSQL Scala编写SQL操作SparkSQL的数据源:JSON、CSV、JDBC、Hive
大数据-96 Spark 集群 SparkSQL Scala编写SQL操作SparkSQL的数据源:JSON、CSV、JDBC、Hive
8 0
|
1天前
|
SQL 分布式计算 大数据
大数据-94 Spark 集群 SQL DataFrame & DataSet & RDD 创建与相互转换 SparkSQL
大数据-94 Spark 集群 SQL DataFrame & DataSet & RDD 创建与相互转换 SparkSQL
7 0
|
1天前
|
分布式计算 关系型数据库 MySQL
大数据-88 Spark 集群 案例学习 Spark Scala 案例 SuperWordCount 计算结果数据写入MySQL
大数据-88 Spark 集群 案例学习 Spark Scala 案例 SuperWordCount 计算结果数据写入MySQL
16 3
|
1天前
|
分布式计算 监控 大数据
大数据-148 Apache Kudu 从 Flink 下沉数据到 Kudu
大数据-148 Apache Kudu 从 Flink 下沉数据到 Kudu
11 1
|
2天前
|
消息中间件 缓存 NoSQL
大数据-49 Redis 缓存问题中 穿透、雪崩、击穿、数据不一致、HotKey、BigKey
大数据-49 Redis 缓存问题中 穿透、雪崩、击穿、数据不一致、HotKey、BigKey
11 2