数据库事务系列-事务模型基础

从这篇文章开始,笔者将会在接下来很长时间里整理记录一个相对独立的知识领域-数据库事务,之所以忽然有这个想法,说来也是一种机缘巧合。本来是单纯计划写写HBas行级事务模型的具体实现的,但是在周末一不小心看了HBasecon2017里面一个talk之后就一发不可收拾了。这个talk的主题是 Transactions In HBase(作者详细介绍了基于HBase实现的3种强一致性分布式事务模型-Tephra | Trafodian | Omid),里面提到了Google的Percolater,刚好这个东东是前些天pingcap团队介绍TiDB时重点提到的一个分布式事务模型(TiDB中的事务模型就是借鉴Percolater实现),就想着好好研究一下这个Percolator,正好也有开源实现可以参考。这两天晚上看着看着,脑子又想起了两件事情,第一件事情是笔者在RDS团队的时候刚好了解记录过MyS...

继续阅读

HBase原理-要弄懂的sequenceId

好记性不如烂笔头,何况我的记性已经无药可救

为什么需要sequenceId?

HBase数据在写入的时候首先追加写入HLog,再写入Memstore,也就是说一份数据会以两种不同的形式存在于两个地方。那两个地方的同一份数据需不需要一种机制将两者关联起来?有的朋友要问为什么需要关联这两者,那笔者这里提出三个相关问题

1.Memstore中的数据flush到HDFS文件中后HLog对应的数据是不是就可以被删除了?不然HLog会无限增长!那问题来了,Memstore中被flush到HDFS的数据,如何映射到HLog中的相关日志数据?

2.HBase中单个HLog都有固定大小,日志文件最大个数也是固定设置的,默认最大HLog文件数量为8。如果日志数量超过这个数量,就必须删除最老的HLog日志。那问题来了,如何知道待删除HLog日志对应的所有数据都已经落盘了?(如果知道哪些数据没有落盘,就可以强制对其执...

继续阅读

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...

继续阅读