HBase存储架构详解

HBase

需积分: 31 15 浏览量更新于2023-06-14 评论 2 收藏 1.04MB DOC 举报

身份认证购VIP最低享 7 折!

领优惠券(最高得80元）

资源详情

资源评论

资源推荐

HBase 存储架构

英文原文：

 最隐秘的问题之一就是它的数据是如何存储的。虽然大多数用户都不会因为这个问题向你抱怨，但

是如果你想学习哪些高级的配置选项并了解它们的意思，你可能就需要来了解一下这个存储问题了。“怎样

才能把  调整到最适合我需求的状态？”你可能对于这样一系列类似的问题非常感兴趣。那么你就需要

绕过这些问题来学习  的基础知识。另一个支持你学习这些基础知识的理由是有时候各种各样你想不

到的灾难需要你恢复整个 。

我首先学习了  中控制各种不同文件的独立的类，然后根据我对整个  存储系统的理解在脑海

中构建  架构的图像。但是我发现想要在头脑中构建出一幅连贯的  架构图片很困难，于是我

就把它画了出来。

你可能注意到了这不是一个  图或者调用图。这个图混合了类和他们管理控制的文件，将注意力集中到

了本文要讨论的主题上。后面我将会讨论这张图所涉及到的细节，包括一些配置文件项是如何影响底层的文

件存储系统的。

好，我们现在来分析这张图里面到底包含了什么。首先  操控两种基本类型的文件，一种用于存储

 的 ，另一种用于存储具体的数据。这两种文件主要由  !"# 来管理，但是在有的情况

下  会跳过  !"#，直接操作这两种文件。你可能注意到了，这些文件都被存储在

$%" 上面，并且每个文件包含了多个数据块。配置文件中就有一个选项用来调整系统控制数据的大小。

我们后面会详细讨论这个问题。

接下来看一下数据的大致流程。假设你需要通过某个特定的 &' 查询一行记录，首先 (! 端会连接

)*+,，通过 )*，(! 能获知哪个 "# 管理 --.+ !。接着 (!

访问管理 --.的 "#，进而获知哪个 "# 管理/.表。这两个信息 (! 只会获取一次并

缓存起来。在后续的操作中 (! 会直接访问管理/.表的 "#，并获取 ! 分布的信息。一

旦 (! 获取了这一行的位置信息，比如这一行属于哪个 !，(! 将会缓存这个信息并直接访问

 !"#。久而久之 (! 缓存的信息渐渐增多，即使不访问/.表也能知道去访问哪个

 !"#。

注意：当  启动的时候  负责分配 ! 给  !"#，这其中当然也包括

--.表和/.表的 !。

接下来  !"#+ +

++++

打开这个+ +

!+ +

++++

并创建一个+ +

 !+ +

++++

对象。当+ +

 !+ +

++++

打开以后，它给每个+ +

+ +

++++

的每个+ +

(!%'+ +

++++

创建一个+ +

"+ +

++++

实例。每个+ +

"+ +

++++

实例拥有一个或者多个+ +

"%+ +

++++

实例+ +。+ +

"%+ +

++++

对+ +

%+ +

++++

做了轻量级的包装。除了+ +

"+ +

++++

实例以外，每个+ +

 !+ +

++++

还拥有一个+ +

"+ +

++++

实+ +

例和一个



实例。现在我们就可以看看这些实例是如何在一起工作的，遵循什么样的规则以及这些规则

的例外。

保留住

0

现在看一下数据是怎样被写到实际的存储中去的。(! 发起了一个 .102请求给

 !"#， !"# 会将请求匹配到某个具体的  ! 上面。紧接着的操作时决定是

否写 +。是否写 + 由 (! 传递的一个标志决定，你可以设置这个标志：

0.1!2。+ 文件是一个标准的 3+"4!%（现在还在讨论是否

应该把文件格式改成一个更适合  的格式）。在文件中存储了 &'，这些 &' 包含了和实际

数据对应的序列号，用途是当 !"# 崩溃以后能将 + 中的数据同步到永久存储中去。做完

这一步以后，0 数据会被保存到 " 中，同时会检查 " 是否已经满了，如果已经满了，

则会触发一个 %++$* 的请求。 !"# 有一个独立的线程来处理 %++$* 的请求，

它负责将数据写成 % 文件并存到 $%" 上。它也会存储最后写入的数据序列号，这样就可以知道哪些

数据已经存入了永久存储的 $%" 中。现在让我们来看看这些存储文件。

存储文件

 在 $%" 上面的所有文件有一个可配置的根目录，默认根目录是。通过使用 3 的

$%" 工具就可以看到这些文件夹的结构。

在根目录下面你可以看到一个 文件夹，这里面存了所有由  管理的 + 文件。在 目录

下的每个文件夹对应一个  !"#，每个  !"# 下面的每个  文件对应一个

!。

有时候你会发现一些 35 文件（在大多数情况下你可能看不到这个文件），这个文件在一种异常

情况下会被产生。这个异常情况就是  对  文件的访问情况产生了怀疑，它会产生一种称作“+

6的结果。有时候  会发现某个  文件没人管了，就是说任何一个  !"# 都不

会管理这个  文件（有可能是原来管理这个文件的  !"# 挂了）， 会负责分割这个

 文件（按照它们归属的 !），并把那些 &' 写到一个叫做 35 的文件中，并按

照它们归属的 ! 直接将文件放到各自的 ! 文件夹下面。各个  ! 会从这个文件中读取数

据并将它们写入到 " 中去，并开始将数据 %++$*。然后就可以把这个 35 文

件删除了。

注意：有时候你可能会发现另一个叫做 353 的文件，这是由于  做了重复分割 

文件的操作并发现 35 已经存在了。这时候就需要和  !"# 以及  协商到底

发生了什么，以及是否可以把 3 的文件删掉了。从我目前遇到的情况来看，3 文件都是空的并且可以被

安全删除的。

 的每个 . 在根目录下面用一个文件夹来存储，文件夹的名字就是 . 的名字。在 . 文件

夹下面每个 ! 也用一个文件夹来存储，但是文件夹的名字并不是 ! 的名字，而是 ! 的名

字通过 7!*!+ 计算所得到的字符串。这样做的原因是 ! 的名字里面可能包含了不能在

$%" 里面作为路径名的字符。在每个 ! 文件夹下面每个 (!%' 也有自己的文件夹，在每

个 (!%' 文件夹下面就是一个个 % 文件了。所以整个文件夹结构看起来应该是这个样子的：

8!98!33!!98!:'985!9

在每个 ! 文件夹下面你会发现一个!!: 文件，这个文件用来存储这个 ! 的 +

$。通过这些 +$ 我们可以重建被破坏的/.表，关于!!: 的应用你可以参考

"/; 和 "/<=;。

有一件事情前面一直没有提到，那就是 ! 的分割。当一个 ! 的数据文件不断增长并超过一个最

大值的时候（你可以配置这个最大值 !>5?），这个 ! 会被切分成两个。这

个过程完成的非常快，因为原始的数据文件并不会被改变，系统只是简单的创建两个 :! 文件指向

原始的数据文件。每个 :! 文件管理原始文件一半的数据。 :! 文件名字是一个 @$，它使

用被参考的 ! 的名字的  作为前缀。例如：

;<AB;<C=CAACBBBBBB。 :! 文件只含有非常少量的信息，这些信息包括被分割

的原始 ! 的 &' 以及这个文件管理前半段还是后半段。 使用 :% 3 类来访问

:! 文件并从原始数据文件中读取数据。前面的架构图只并没有画出这个类，因为它只是临时使用

的。只有当系统做 (! 的时候原始数据文件才会被分割成两个独立的文件并放到相应的 !

目录下面，同时原始数据文件和那些 :! 文件也会被清除。

前面 3 出来的文件结构也证实了这个过程，在每个 . 的目录下面你可以看到一个叫做

!3 的目录。这个文件夹是一个数据交换区，用于存放  和 + ! 过程中生成

的临时数据。

%

现在我们将深入  存储架构的核心，探讨  具体的数据存储文件的结构。StoreFile 以 HFile 格

式保存在 HDFS 上。% 就是这个数据存储文件的结构（ '!+ ! 就是靠它扬名立万的）。创建

% 这样一个文件结构的目的只有一个：快速高效的存储  的数据。% 是基于 3+.%

剩余11页未读，继续阅读

ly450772556

粉丝: 0
资源: 4

会员权益专享

HBase存储架构详解

评论0

会员权益专享

最新资源

HBase存储架构详解

评论0

HBase架构图

详解HBase架构原理

详解Hadoop核心架构HDFS+MapReduce+Hbase+Hive

Storm流计算项目：1号店电商实时数据分析系统-11.基于HBase的Dao基类和实现类开发一.pptx

HBase集群架构与节点角色详解

HBase读写操作详解

HBase数据模型详解与实际案例分析

HBase 2.0集群部署详解

HBase数据存储结构解析

hbase分布式存储架构

简述HBase系统架构的组成及其作用。

hbase存储表与excel表有什么区别

hbase寻址机制详解

HBase的架构和组件以及运行原理

hbase建表参数详解

2.HBase的架构是什么？各个组件的作用是什么？

HDFS在Hbase系统架构中的作用是什么

阿里云大规模结构化云存储hbase架构解析

HBase的分布式架构中有哪些组件？分别完成什么功能？

简述HBase系统架构的客户端，Zookeeper服务器，Master主服务器，Region服务器的作用

会员权益专享

最新资源