SparkSQL – 有必要坐下来聊聊Join

Join背景介绍

Join是数据库查询永远绕不开的话题,传统查询SQL技术总体可以分为简单操作(过滤操作-where、排序操作-limit等),聚合操作-groupBy等以及Join操作等。其中Join操作是其中最复杂、代价最大的操作类型,也是OLAP场景中使用相对较多的操作。因此很有必要聊聊这个话题。

另外,从业务层面来讲,用户在数仓建设的时候也会涉及Join使用的问题。通常情况下,数据仓库中的表一般会分为”低层次表”和“高层次表”。

所谓”低层次表”,就是数据源导入数仓之后直接生成的表,单表列值较少,一般可以明显归为维度表或者事实表,表和表之间大多存在外健依赖,所以查询起来会遇到大量Join运算,查询效率相对比较差。而“高层次表”是在”低层次表”的基础上加工转换而来,通常做法是使用SQL语句将需要Join的表预先进行合并形成“宽表”,在宽表上的查询因为不需要执行大量Join因而效率相对较高,...

继续阅读

SparkSQL – 从0到1认识Catalyst

最近想来,大数据相关技术与传统型数据库技术很多都是相互融合、互相借鉴的。传统型数据库强势在于其久经考验的SQL优化器经验,弱势在于分布式领域的高可用性、容错性、扩展性等,假以时日,让其经过一定的改造,比如引入Paxos、raft等,强化自己在分布式领域的能力,相信一定会在大数据系统中占有一席之地。相反,大数据相关技术优势在于其天生的扩展性、可用性、容错性等,但其SQL优化器经验却基本全部来自于传统型数据库,当然,针对列式存储大数据SQL优化器会有一定的优化策略。
本文主要介绍SparkSQL的优化器系统Catalyst,上文讲到其设计思路基本都来自于传统型数据库,而且和大多数当前的大数据SQL处理引擎设计基本相同(Impala、Presto、Hive(Calcite)等),因此通过本文的学习也可以基本了解所有其他SQL处理引擎的工作原理。
SQL优化器核心执行策略主要分为两个大的方向:基于规则...

继续阅读

SparkSQL-从DataFrame说起

写在文章之前

本着更好地理解大数据生态圈的本意以及工作的需要,前段时间熟悉了SQL查询引擎SparkSQL、Hadoop文件格式Parquet/CarbonData、大数据基准测试标准TPCDS/TPCH等相关知识,后续将会陆续整理出相关的内容;所有分享内容都是参考相关资料完成,文中很多细节都是在阅读相关资料时的所感所悟,只希望能够及时记录下来,以免遗忘!另外,不可避免会有一些纰漏,还忘客官能够批判性阅读,讨论交流!当然,HBase相关博客还会继续更新;


SparkSQL 历史回顾

对SparkSQL了解的童鞋或多或少听说过Shark,不错,Shark就是SparkSQL的前身。2011的时候,Hive可以说是SQL On Hadoop的唯一选择,负责将SQL解析成MR任务运行在大数据上,实现交互式查询、报表等功能。就在那个时候,Spark社区的小伙伴就意识到可以使用Spark作为执行引擎替换H...

继续阅读

学习从来不是一件简单地事情,然

之所以忽然提笔,是因为这段时间正好在业余时间系统地学习Spark,整个学习思路让我想起了大学期间学习《模拟电子电路》这门课的一些方法,个人觉得可以作为一个学习模板来和大家一起交流分享本文只谈如何系统高效地学习一项技能或者一门课程,抱有突击学习目的的请绕道)。

无论是学习Spark技术还是学习《模拟电子电路》课程,总结起来,大体都经历了这么几个阶段

1.初识(10%:系统地过一遍整个内容,《模电》就是大体听一遍老师的课程,Spark就到处看看相关的资料,在测试环境写一点测试代码。这个过程不需要特别仔细,也不需要多么深入的理解,只需要有个基本的概念了解即可。通常初识阶段是没有办法建立起知识的体系结构的。

2.搭建知识体系(20%:初步了解基本概念之后,需要再过一遍所有内容,这次同样不需要关注细节,但是需要重点关注章节体系以及章节核心点

  • 这门课程有哪些章节,比如Spark整体可以划分为Spar...

继续阅读

HBase原理-数据读取流程解析

和写流程相比,HBase读数据是一个更加复杂的操作流程,这主要基于两个方面的原因:其一是因为整个HBase存储引擎基于LSM-Like树实现,因此一次范围查询可能会涉及多个分片、多块缓存甚至多个数据存储文件;其二是因为HBase中更新操作以及删除操作实现都很简单,更新操作并没有更新原有数据,而是使用时间戳属性实现了多版本。删除操作也并没有真正删除原有数据,只是插入了一条打上"deleted"标签的数据,而真正的数据删除发生在系统异步执行Major_Compact的时候。很显然,这种实现套路大大简化了数据更新、删除流程,但是对于数据读取来说却意味着套上了层层枷锁,读取过程需要根据版本进行过滤,同时对已经标记删除的数据也要进行过滤。

总之,把这么复杂的事情讲明白并不是一件简单的事情,为了更加条理化地分析整个查询过程,接下来笔者会用两篇文章来讲解整个过程,首篇文章主要会从框架的角度粗粒度地分析sc...

继续阅读

HBase最佳实践-写性能优化策略

上一篇文章主要介绍了HBase读性能优化的基本套路,本篇文章来说道说道如何诊断HBase写数据的异常问题以及优化写性能。和读相比,HBase写数据流程倒是显得很简单:数据先顺序写入HLog,再写入对应的缓存Memstore,当Memstore中数据大小达到一定阈值(128M)之后,系统会异步将Memstore中数据flush到HDFS形成小文件。

HBase数据写入通常会遇到两类问题,一类是写性能较差,另一类是数据根本写不进去。这两类问题的切入点也不尽相同,如下图所示

70

写性能优化切入点

1. 是否需要写WAL?WAL是否需要同步写入?

优化原理:数据写入流程可以理解为一次顺序写WAL+一次写缓存,通常情况下写缓存延迟很低,因此提升写性能就只能从WAL入手。WAL机制一方面是为了确保数据即使写入缓存丢失也可以恢复,另一方面是为了集群之间异步复制。默认WAL机制开启且使用同步机制写入WAL。首先考虑...

继续阅读

HBase最佳实践-读性能优化策略

任何系统都会有各种各样的问题,有些是系统本身设计问题,有些却是使用姿势问题。HBase也一样,在真实生产线上大家或多或少都会遇到很多问题,有些是HBase还需要完善的,有些是我们确实对它了解太少。总结起来,大家遇到的主要问题无非是Full GC异常导致宕机问题、RIT问题、写吞吐量太低以及读延迟较大。

Full GC问题之前在一些文章里面已经讲过它的来龙去脉,主要的解决方案目前主要有两方面需要注意,一方面需要查看GC日志确认是哪种Full GC,根据Full GC类型对JVM参数进行调优,另一方面需要确认是否开启了BucketCache的offheap模式,建议使用LRUBlockCache的童鞋尽快转移到BucketCache来。当然我们还是很期待官方2.0.0版本发布的更多offheap模块。

RIT问题,我相信更多是因为我们对其不了解,具体原理可以戳这里,解决方案目前有两个,优先是使用官...

继续阅读

HBase原理-RegionServer宕机数据恢复

HBase采用类LSM的架构体系,数据写入并没有直接写入数据文件,而是会先写入缓存(Memstore),在满足一定条件下缓存数据再会异步刷新到硬盘。为了防止数据写入缓存之后不会因为RegionServer进程发生异常导致数据丢失,在写入缓存之前会首先将数据顺序写入HLog中。如果不幸一旦发生RegionServer宕机或者其他异常,这种设计可以从HLog中进行日志回放进行数据补救,保证数据不丢失。HBase故障恢复的最大看点就在于如何通过HLog回放补救丢失数据。

HLog简介

为了更好的理解HBase故障恢复原理,需要对HLog有简单的认识。HLog的整个生命历程可以使用下面一张图来表示

h1

1. HLog构建:详见另一篇博文HBase-数据写入流程解析》中相关章节,此处再将HLog的结构示意图拿出来

h2

上图可以看出,一个HLog由RegionServer上所有Region的日志数据构成,日志数...

继续阅读

HBase最佳实践-多租户机制简析

背景介绍

在HBase1.1.0发布之前,HBase同一集群上的用户、表都是平等的,没有优劣之分。这种'大同'社会看起来完美,实际上有很多问题。最棘手的主要有这么两个,其一是某些业务较其他业务重要,需要在资源有限的情况下优先保证核心重要业务的正常运行,其二是有些业务在某些场景下会时常'抽风',QPS常常居高不下,严重消耗系统资源,导致其他业务无法正常运转。这实际上是典型的多租户问题,社区针对这个问题提出了相应的应对措施,主要有如下三点

(1)资源限制,主要针对用户、namespace以及表的QPS和请求大小进行限制,详见HBase-1159(2)资源调度,主要针对任务进行优先级调度,通常会优先调度实时交互而且小的任务,而批量操作任务或者长时间操作任务(大scan)优先级相对较低,详见HBase-1099(3)资源隔离,将不同表通过物理隔离的方式分布到不同的RegionServer上,详见...

继续阅读

HBase运维实践-聊聊RIT的那点事

相信长时间运维HBase集群的童鞋肯定都会对RIT(Region-In-Transition,很多参考资料误解为Region-In-Transaction,需要注意)有一种咬牙切齿的痛恨感,一旦Region处于长时间的RIT就会有些不知所措,至少以前的我就是这样过来的。正所谓“恐惧来源于未知”,不知所措意味着我们对RIT知之甚少,然而“凡事都有因果,万事皆有源头”,处于RIT状态的Region只是肉眼看到的一个结果,为什么会处于RIT状态才是问题探索的根本,也是解决问题的关键。本文就基于hbase 0.98.9版本对RIT的工作机制以及实现原理进行普及性的介绍,同时在此基础上通过真实案例讲解如何正确合理地处理处于RIT状态的Region。一方面希望大家能够更好的了解RIT机制,另一方面希望通过本文的学习之后可以不再’惧怕’RIT,正确认识处于RIT状态的Region。

Region-In-Trasition机制...

继续阅读