突破DBMS局限性,阿里借力Spark提升查询性能

  • 时间:
  • 浏览:0
  • 来源:uu快3app赚钱_uu快3大小计划注册



一般处里OLAP有一种思路。最常见的思路是,在业务库之外再拷贝一份数据,搭建数据仓库。大多数数仓都采用分布式MPP架构,MPP全称是Massively Parallel Processing,即大规模并行处里,顾名思义是用多节点并行计算的最好的办法来加速冗杂查询计算;另一方面,数仓大多使用share-nothing架构,数据被分片存储到各个节点上:





RDD全称是“弹性分布式数据集”,“分布式”意为每个RDD都蕴藏多个分区、分布在多个节点上;“弹性”意为每个分区都还可否容易的被恢复——因此我它的依赖方还在,就还可否重算来恢复。

通过合理选者Sharding最好的办法,亲戚亲戚你们还可否在一种架构上比较好指在理這個 聚合Join等查询。因此我,肯能数据量较大,例如遇到难以索引的ad-hoc查询,一种架构同样力不从心。

另另一个 说到,MySQL那样的架构过高 以满足亲戚亲戚你们对冗杂查询的需求。本着透过什么的问题看本质的精神,我想们重新审视一下各种DBMS以及大数据的执行最好的办法,无非是以下几种:

上端的思路有时也被称为ROLAP,与此相对的,另一种方案是出現查询一种:MOLAP通过对数据进行预建模来加速查询。例如,亲戚亲戚你们通常选者时间维度、去掉 若干个业务维度,对它们的各种组合最好的办法预先做好聚合。

一、传统数据库的过高

MySQL之上有这样来越多这样来越多这样来越多这样来越多支持水平拆分的分布式方案,能让数据均匀分摊到多个节点上,从而获得Scale Out的能力。以阿里云DRDS(分布式关系型数据库)为例,DRDS支持分布式事务、平滑扩容、读写分离、权限管理等形态学 ,架构如下图所示:





肯能用户查询与预建模匹配,只时要在另另一个 聚合结果的基础上再做计算就行了,显然,查询代价大大减少。MOLAP的典型代表是Apache Kylin。

本文作者:傅宇

三、Spark与Spark SQL

从接口上看,计算最好的办法是对用户透明的,执行引擎自动根据用户输入的SQL来决定是否要进行分布式执行,肯能时要分布式执行,则将执行计划架构设计 给Fireworks集群,只需等待计算完成即可。

亲戚亲戚你们知道SQL Server是一款技术上和商业上都很成功的产品,一种次微软选者拥抱Spark大数据生态,其实令人這個 惊讶。国内的几款产品也丝毫不落后,阿里云的DRDS、腾讯云TDSQL也都个人所有所有 推出了与Spark相融合的产品。

阿里云DRDS只读实例中引入了Fireworks引擎,它是亲戚亲戚你们基于Apache Spark定制的分布式MPP引擎。

原文发布时间为:2018-11-5

这是由MySQL的整个系统设计决定的,MySQL从最初就被设计为每个请求由单tcp连接运行来处里。固然这样 设计,是肯能OLTP查询大多很简单,SELECT多以点查居多,让另一个 tcp连接运行来处里肯能足够了。

Spark RDD模型中,则采用另一套失败容忍方案。

我这样多 多说,MySQL是互联网企业中使用最广泛的数据库。因此我MySQL专注于OLTP能力,对冗杂的分析型查询这样来越多在行。为一种这样 说呢?

Spark的设计比MapReduce更先进。为一种这样 说?

其实亲戚亲戚你们常常把Spark归入Hadoop生态系统中,但事实上Spark这样来越多依赖Hadoop,这样来越多这样来越多这样来越多这样来越多我肯能Spark一种不蕴藏存储,通常和HDFS共同部署搭配使用。



对于另另一个 的架构,即使增加机器配置,对提升OLAP查询性能也没一种显著帮助,肯能无法利用多核并行的能力。

Spark的查询计划包中,像filter、map一种算子是还可否在分区外部以pipeline的最好的办法执行的;但另這個 算子,例如Join,通常时要在Join另另一个 对左右两边的数据都按Join Key做Shuffle,这就意味着愿意执行Join另另一个 时要等待左右所有数据都完成不能继续。一种点被称为Pipeline-breaker。执行计划中,不可处里地会出現好多个Pipeline-breaker,这样来越多这样来越多这样来越多这样来越多就也产生了多个Stage,这和MR這個 例如。

四、为一种用Spark?

Spark是当下最流行的大数据框架,支持编程接口和声明式(SQL)接口,支持批处里任务和流计算任务。它使用Scala编写,支持Java、Scala、Python等语言的编程接口。

DRDS HTAP并这样 引入新的存储,这样来越多这样来越多这样来越多这样来越多我利用了数据库一种的备库。不同于ETL等数据Pipeline,数据库主备之间的binlog同步速率非常快,通常在毫秒级别,足以满足绝大次责查询的实时性要求。从备库拉取数据,也是为了保障主库我这样多 增加额外负担、对业务造成影响。

下图这样来越多这样来越多这样来越多这样来越多我另一个 例子:

查询执行的另另一个 ,亲戚亲戚你们沿着Stage的依赖关系从左往右计算即可,例如对于上图,先执行Stage 1、Stage 2(二者还可否并行),再执行Stage 3。Stage外部则以pipeline最好的办法执行。

亲戚亲戚你们回顾一下MapReduce模型:MapReduce处里冗杂任务时要分成多个MR Stage,每个Stage都不 写入上端结果到HDFS,另另一个 再被下个Stage读出。固然要持久化上端结果,目的是要达到Worker级的失败容忍,因此我一种代价过于大了点。

五、DRDS HTAP的实践

Q:Optimizer这层肯能收到冗杂查询时要转到Spark计算话语是解析成Spark的logicplan吗?那怎样跟Spark对接?

从上表还可否看出,Spark SQL足以胜任亲戚亲戚你们的需求。固然这样 选者Hive等,还有這個 這個 技术性、非技术性的考虑,不一定是绝对的,在这里也就不引战了。



从(year, item, city)另一个 维度枚举出8种组合最好的办法,亲戚亲戚你们对这8种最好的办法的聚合都进行预先计算,这有时也被形象地称为Data Cube。

Spark SQL则是在Spark RDD API上的二次封装,下图是一段Native API的例子:



但很显然,MOLAP所能计算的查询严格受建模最好的办法限制,这让它的门槛大大提高。这样来越多这样来越多这样来越多这样来越多综合来看,使用的不如ROLAP广泛。

在日后的改进中,MySQL增加了tcp连接运行池、高低优先级等等,因此我仍未改变其本质:另一个 tcp连接运行对应另一个 查询请求。







二、处里OLAP什么的问题

今天亲戚亲戚你们就来谈一谈,怎样在数据库一种老生常谈话语题下,借力Spark给数据库带来新的价值。

 ●  单机并行(SMP):以PostgreSQL为代表,不具备Scale Out能力,不还可否排除; ●  分布式并行(MPP):以数据仓库和各种大数据框架为代表。

其中,MPP又还可否根据还可否做到Worker级的失败容忍,进一步细分成一种:分布式并行和批处里。这二者之间的性能差异肯能很小了,更多的是看這個 方面,例如:业务中是否时要做小时级的查询、生态是否完善等。

此外不还可否直接输入SQL,二者无非是否经过Parser的区别。

Spark假设所有计算都不 选者性的,因而也就还可否通过重算恢复丢失的分区,处里写HDFS、把数据尽量倒入内存,性能得以大大提告。

本文来自云栖社区战略战略合作伙伴“DBAplus社群”,了解相关信息还可否关注“DBAplus社群”。



Q & A

A:亲戚亲戚你们目前是直接使用的Spark SQL接口,肯能不时要侵入到外部。另另一个 肯能造成的后果是Spark的优化器会再优化一次。不过亲戚亲戚你们的执行计划肯能很具体了,通常Spark优化后依然和预期一样。