HBase原理 – 分布式系统中snapshot是怎么玩的?

snapshot(快照)基础原理

snapshot是很多存储系统和数据库系统都支持的功能。一个snapshot是一个全部文件系统、或者某个目录在某一时刻的镜像。实现数据文件镜像最简单粗暴的方式是加锁拷贝(之所以需要加锁,是因为镜像得到的数据必须是某一时刻完全一致的数据),拷贝的这段时间不允许对原数据进行任何形式的更新删除,仅提供只读操作,拷贝完成之后再释放锁。这种方式涉及数据的实际拷贝,数据量大的情况下必然会花费大量时间,长时间的加锁拷贝必然导致客户端长时间不能更新删除,这是生产线上不能容忍的。

snapshot机制并不会拷贝数据,可以理解为它是原数据的一份指针。在HBase这种LSM类型系统结构下是比较容易理解的,我们知道HBase数据文件一旦落到磁盘之后就不再允许更新删除等原地修改操作,如果想更新删除的话可以追加写入新文件(HBase中根本没有更新接口,删除命令也是追加写入)。这种机制下实...

继续阅读

HBase原理 – 所有Region切分的细节都在这里了

Region自动切分是HBase能够拥有良好扩张性的最重要因素之一,也必然是所有分布式系统追求无限扩展性的一副良药。HBase系统中Region自动切分是如何实现的?这里面涉及很多知识点,比如Region切分的触发条件是什么?Region切分的切分点在哪里?如何切分才能最大的保证Region的可用性?如何做好切分过程中的异常处理?切分过程中要不要将数据移动?等等,这篇文章将会对这些细节进行基本的说明,一方面可以让大家对HBase中Region自动切分有更加深入的理解,另一方面如果想实现类似的功能也可以参考HBase的实现方案。

Region切分触发策略

在最新稳定版(1.2.6)中,HBase已经有多达6种切分触发策略。当然,每种触发策略都有各自的适用场景,用户可以根据业务在表级别选择不同的切分触发策略。常见的切分策略如下图

1

  • ConstantSizeRegionSplitPolicy:0.94...

继续阅读

数据库事务系列-MySQL跨行事务模型

说来和MySQL倒是有缘,毕业的第一份工作就被分配到了RDS团队,主要负责把MySQL弄到云上做成数据库服务。虽说整天和MySQL打交道,但说实话那段时间并没有很深入的理解MySQL内核,做的事情基本都是围绕着MySQL做管控系统,比较上层。好在周边都是MySQL内核神级人物,在他们的熏陶下多多少少对MySQL的一些基本知识有一些零碎的记录和模糊的认识,这些基础对于今天整理理解MySQL跨行事务模型非常重要。更重要的,有很多不解的地方也可以向大神请教。

MySQL事务模型在网上也有很多的介绍,在写这篇文章之前本人也翻看了很多资料作为参考,以期让自己理解的更加深入全面。看了大多数介绍文章之后发现部分文章并不完整,比如有的只介绍了几种隔离级别下MySQL的表现,并没有从技术角度进行解读。有的文章说的倒很全面,但缺乏些许条理,读起来并不容易理解。这也是笔者希望能够带给大家一点不一样的东西,从技术角...

继续阅读

数据库事务系列-HBase行级事务模型

HBase是BigTable的开源实现,事务模型也与BigTable一脉相承 - 仅支持行级别的事务。虽然Jeff Dean大神在接受采访时公开承认目前在技术领域最后悔的事情就是没有在BigTable中加入跨行事务模型,以至于之后很多团队都在BigTable之上重复造各种各样的分布式事务轮子。这点笔者是认同的,现在确实有很多团队在HBase之上造了很多轮子(Tephra | Trafodian | Omid),试想如果这个工作做在了BigTable里面,这些团队的人是不是可以做更多其他有意义的事情了~ 所幸的是之后Google又发布了一篇介绍分布式事务模型的的paper - Percolator,现在很多团队都参考该论文实现分布式事务,包括TiDB、Omid等,也算是一种弥补吧。

虽说HBase目前只支持行级事务,但行级事务也是事务!麻雀虽小,肝脏具全。这篇文章一起看看HBase行级事务所满...

继续阅读

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

从这篇文章开始,笔者将会在接下来很长时间里整理记录一个相对独立的知识领域-数据库事务,之所以忽然有这个想法,说来也是一种机缘巧合。本来是单纯计划写写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...

继续阅读