《Hbase原理与实践》阅读笔记(七)

本文是《Hbase原理与实践》阅读笔记,重点介绍了HBase 2.x的Procedure机制,它通过Procedure v2确保分布式任务流的原子性,解决了元数据一致性问题。此外,还探讨了In Memory Compaction功能,该功能通过细粒度的MemStore设计提高写入吞吐和降低延迟。最后,文章提到了HBase社区运作机制和二级索引的概念。
摘要由CSDN通过智能技术生成

本博客内容基本整理自《Hbase原理与实践》一书。仅用于个人学习和积累。

1.HBase 2.x核心技术

HBase 2.x版本是迄今为止改动最大的一个版本,主要包含的核心功能如下:

  • 基于Procedure v2重新设计了HBase的Assignment Manager和核心管理流程。通过Procedure v2,HBase能保证各核心步骤的原子性,从设计上解决了分布式场景下多状态不一致的问题。
  • 实现了In Memory Compaction功能。该功能将MemStore分成若干小数据块,将多个数据块在MemStore内部做Compaction,一方面缓解了写放大的问题,另一方面降低了写路径的GC压力。
  • 存储MOB数据。2.0.0版本之前对大于1MB的数据支持并不友好,因为大value场景下Compaction会加剧写放大问题,同时容易挤占HBase的BucketCache。而新版本通过把大value存储到独立的HFile中来解决这个问题,更好地满足了多样化的存储需求。
  • 读写路径全链路Offheap化。在2.0版本之前,HBase只有读路径上的BucketCache可以存放Offheap,而在2.0版本中,社区实现了从RPC读请求到完成处理,最后到返回数据至客户端的全链路内存的Offheap化,从而进一步控制了GC的影响。
  • 异步化设计。异步的好处是在相同线程数的情况下,提升系统的吞吐量。2.0版本中做了大量的异步化设计,例如提供了异步的客户端,采用Netty实现异步RPC,实现asyncFsWAL等。

1.1.Procedure

在HBase 2.0版本之前,系统存在一个潜在的问题:HBase的元信息分布在ZooKeeper、HBase Meta表以及HDFS文件系统中,而HBase的分布式管理流程并没法保证操作流程的原子性,因此,容易导致这三者之间的不一致。
HBase 2.0引入了Procedure v2的设计。本质上是通过设计一个分布式任务流框架,来保证这个任务流的多个步骤全部成功,或者全部失败,即保证分布式任务流的原子性。

1.1.1.Procedure定义

一个Procedure一般由多个subtask组成,每个subtask是一些执行步骤的集合,这些执行步骤中又会依赖部分Procedure。
Procedure提供的两个接口:execute()和rollback(),其中execute()接口用于实现Procedure的执行逻辑,rollback()接口用于实现Procedure的回滚逻辑。这两个接口的实现需要保证幂等性。

1.1.2.Procedure Yield

Procedure v2框

评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值