HBase原理-迟到的‘数据读取流程’部分细节

笔者去年年底分享了一篇关于HBase中数据读取(scan)逻辑的文章(戳这里),主要介绍了scan的基本流程以及实现框架,看官反应甚是强烈。文章最后还挖了一个不大不小的坑,承诺后期会就部分细节进行深入分析,然而因为部分原因这个坑一直没填上。HBase-Scan的细节其实并不好讲,涉及太多代码层面的底层逻辑,大部分童鞋应该都不会太过关心。虽说如此,挖了的坑,含着泪也要填上,当然为了把坑填好,笔者将会使出洪荒之力将这些核心细节通过各种辅助化方式(示例、图解等)进行解读,方便读者理解。注:笔者能力有限、水平一般,如有不对还望指教。

简单地回顾一下scan的整个流程,如下图所示


55

上图是一个简单的示意图,用户如果对整个流程比较感兴趣,可以阅读之前的文章,本文将会关注于隐藏在这个示意图中的核心细节。这里笔者挑出了其中五个比较重要的问题来说明,这些问题都是本人之前或早或晚比较困惑的问题,拿出来与大家分享。...

继续阅读

HBase最佳实践-用好你的操作系统

终于又切回HBase模式了,之前一段时间因为工作的原因了解接触了一段时间大数据生态的很多其他组件(诸如Parquet、Carbondata、Hive、SparkSQL、TPC-DS/TPC-H等),虽然只是走马观花,但也受益良多。对视野、思维模式都有极其重要的作用,至少,扩展了大数据领域的对话圈。这里也斗胆建议朋友能在深入研究一门学问的同时博览周边学问,相信必然会大有裨益。

来说正题,操作系统这个话题其实很早就想拿出来和大家分享,拖到现在一方面是因为对其中各种理论理解并不十分透彻,怕讲不好;另一方面是这个问题好像一直以来都很少有人关注,这里算是给这个话题开个头。其实这几个参数前前后后看过好些次,但却一直没有吃透,前段时间趁着休假又把这些理论翻出来过了一遍,有了进一步的理解,这里权当整理梳理。下图是HBase官方文档上对操作系统环境的几点配置要求


a1

先不着急解释每个配置的具体含义,在这之前需要重...

继续阅读

BigData-‘基于代价优化’究竟是怎么一回事?

还记得笔者在上篇文章无意中挖的一个坑么?如若不知,强烈建议看官先行阅读前面两文-SparkSQL – 有必要坐下来聊聊Joi》和BigData – Join中竟然也有谓词下推!》。第一篇文章主要分析了大数据领域Join的三种基础算法以及各自的适用场景,第二篇文章在第一篇的基础上进一步深入,讨论了Join基础算法的一种优化方案 - Runtime Filter,文章最后还引申地聊了聊谓词下推技术。同时,在第二篇文章开头,笔者引出了两个问题,SQL执行引擎如何知晓参与Join的两波数据集大小?衡量两波数据集大小的是物理大小还是纪录多少抑或两者都有?这关系到SQL解析器如何正确选择Join算法的问题。好了,这些就是这篇文章要为大家带来的议题-基于代价优化(Cost-Based Optimization,简称CBO)。

CBO基本原理

提到CBO,就不得不提起一位’老熟人’ - 基于规则优化(...

继续阅读

BigData – Join中竟然也有谓词下推!?

作者:何李夫、范欣欣

上文简要介绍了Join在大数据领域中的使用背景以及常用的几种算法-broadcast hash join 、shuffle hash join以及sort merge join等,对每一种算法的核心应用场景也做了相关介绍,这里再重点说明一番:大表与小表进行join会使用broadcast hash join,一旦小表稍微大点不再适合广播分发就会选择shuffle hash join,最后,两张大表的话无疑选择sort merge join。

好了,问题来了,说是这么一说,但到底选择哪种算法归根结底是SQL执行引擎干的事情,按照上文逻辑,SQL执行引擎肯定要知道参与Join的两表大小,才能选择最优的算法喽!那么斗胆问一句怎么知道两表大小?衡量两表大小的是物理大小还是纪录多少抑或两者都有?其实这是另一门学问-基于代价优化(Cost BaseOptimization,简称CB...

继续阅读

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。首先考虑...

继续阅读