深入理解Hbase--简介

╰+哭是因爲堅強的太久メ 2023-02-19 03:27 40阅读 0赞

## 一、介绍HBase ##

> [Apache][] HBase™ is the [Hadoop][] database, a distributed, scalable, big data store.
> 
> HBase is a type of "NoSQL" database.

Apache HBase 是 Hadoop 数据库，一个分布式、可伸缩的**大数据存储**。

HBase是依赖Hadoop的。为什么HBase能存储海量的数据？**因为HBase是在HDFS的基础之上构建的，HDFS是分布式文件系统**。

## 二、为什么要用HBase ##

比如说分布式搜索引擎「Elasticsearch」、分布式文件系统「HDFS」、分布式消息队列「Kafka」、缓存数据库「Redis」，这些 **能够处理数据的中间件(系统)，这些中间件基本都会有持久化的功能**。为什么？如果某一个时刻挂了，那**还在内存但还没处理完的数据**不就凉了？

Redis有AOF和RDB、Elasticsearch会把数据写到translog然后结合FileSystemCache将数据刷到磁盘中、Kafka本身就是将数据顺序写到磁盘....

这些中间件会实现持久化（像HDFS和MySQL我们本身就用来存储数据的），为什么我们还要用HBase呢？

*  MySQL？MySQL数据库我们是算用得最多了的吧？但众所周知，MySQL是**单机**的。MySQL能存储多少数据，取决于那台服务器的硬盘大小。以现在互联网的数据量，很多时候MySQL是没法存储那么多数据的。
    
     *  比如我这边有个系统，一天就能产生1TB的数据，这数据是不可能存MySQL的。（如此大的量数据，我们现在的做法是先写到Kafka，然后落到Hive中）
 *  Kafka？Kafka我们主要用来处理消息的（解耦异步削峰）。数据到Kafka，Kafka会将数据持久化到硬盘中，并且Kafka是分布式的（很方便的扩展），理论上Kafka可以存储很大的数据。但是Kafka的数据我们**不会「单独」取出来**。持久化了的数据，最常见的用法就是重新设置offset，做「回溯」操作
 *  Redis？Redis是缓存数据库，所有的读写都在内存中，速度贼快。AOF/RDB存储的数据都会加载到内存中，Redis不适合存大量的数据（因为内存太贵了！）。
 *  Elasticsearch？Elasticsearch是一个分布式的搜索引擎，主要用于检索。理论上Elasticsearch也是可以存储海量的数据（毕竟分布式），我们也可以将数据用『索引』来取出来，似乎已经是非常完美的中间件了。
    
     *  但是如果我们的数据**没有经常「检索」的需求**，其实不必放到Elasticsearch，数据写入Elasticsearch需要分词，无疑会浪费资源。
 *  HDFS？显然HDFS是可以存储海量的数据的，它就是为海量数据而生的。它也有明显的缺点：不支持随机修改，查询效率低，对小文件支持不友好。

文中的开头已经说了，HBase是基于HDFS分布式文件系统去构建的。换句话说，HBase的数据其实也是存储在HDFS上的。那肯定有好奇宝宝就会问：**HDFS和HBase有啥区别阿**？

HDFS是文件系统，而HBase是数据库，其实也没啥可比性。「**你可以把HBase当做是MySQL，把HDFS当做是硬盘。HBase只是一个NoSQL数据库，把数据存在HDFS上**」。

> 数据库是一个以某种**有组织的方式存储的数据集合**。

扯了这么多，那我们为啥要用HBase呢？HBase在HDFS之上提供了**高并发的随机写和支持实时查询**，这是HDFS不具备的。

如果仅仅看上面的”对比“，我们可以发现HBase可以以**低成本**来**存储海量**的数据并且支持高并发随机写和实时查询。

但HBase还有一个特点就是：**存储数据的”结构“可以地非常灵活**

## 三、入门HBase ##

听过HBase的同学可能都听过「列式存储」这个词。我最开始的时候觉得HBase很难理解，就因为它这个「列式存储」我一直理解不了它为什么是「列式」的。

在网上也有很多的博客去讲解什么是「列式」存储，它们会举我们现有的数据库，比如MySQL。存储的结构我们很容易看懂，就是一行一行数据嘛。

![format_png][]

转换成所谓的列式存储是什么样的呢？

![format_png 1][]

可以很简单的发现，无非就是把**每列抽出来，然后关联上Id**。这个叫列式存储吗？**我在这打个问号**。

转换后的数据**从我的角度来看**，数据还是一行一行的。

这样做有什么好处吗？很明显以前我们一行记录多个属性(列)，有部分的列是空缺的，但是我们还是需要空间去存储。现在把这些列全部拆开，有什么我们就存什么，这样**空间就能被我们充分利用**。

这种形式的数据更像什么？明显是`Key-Value`嘛。那我们该怎么理解HBase所谓的列式存储和`Key-Value`结构呢？

### 3.1 HBase的数据模型 ###

在看HBase数据模型的时候，其实最好还是不要用「关系型数据库」的知识去理解它。

> In HBase, data is stored in tables, which have rows and columns. This is a terminology overlap withrelational databases (RDBMSs), **but this is not a helpful analogy**.

HBase里边也有表、行和列的概念。

*  表没什么好说的，就是一张表
 *  一行数据由**一个行键**和**一个或多个相关的列以及它的值**所组成

好了，现在比较抽象了。在HBase里边，定位一行数据会有一个唯一的值，这个叫做行键(**RowKey**)。而在HBase的列不是我们在关系型数据库所想象中的列。

HBase的列（**Column**）都得归属到列族（**Column Family**）中。在HBase中用列修饰符（**Column Qualifier**）来标识每个列。

**在HBase里边，先有列族，后有列**。

什么是列族？可以简单理解为：列的属性**类别**

什么是列修饰符？**先有列族后有列，在列族下用列修饰符来标识一列**。

还很抽象是不是？来画个图：

![format_png 2][]

我们再放点具体的值去看看，就更加容易看懂了：

![format_png 3][]

这张表我们有两个列族，分别是`UserInfo`和`OrderInfo`。在UserInfo下有两个列，分别是`UserInfo:name`和`UserInfo:age`，在`OrderInfo`下有两个列，分别是`OrderInfo:orderId`和`OrderInfo:money`。

`UserInfo:name`的值为：三歪。`UserInfo:age`的值为24。`OrderInfo:orderId`的值为23333。`OrderInfo:money`的值为30。这些数据的主键(RowKey)为1

上面的那个图看起来可能不太好懂，我们再画一个我们比较熟悉的：

![format_png 4][]

HBase表的每一行中，列的组成都是**灵活**的，**行与行之间的列不需要相同**。如图下：

![format_png 5][]

![format_png 6][]

换句话说：**一个列族下可以任意添加列，不受任何限制**

数据写到HBase的时候都会被记录一个**时间戳**，这个时间戳被我们当做一个**版本**。比如说，我们**修改或者删除**某一条的时候，本质上是往里边**新增**一条数据，记录的版本加一了而已。

比如现在我们有一条记录：

![format_png 7][]

现在要把这条记录的值改为40，实际上就是多添加一条记录，在读的时候按照时间戳**读最新**的记录。在外界「看起来」就是把这条记录改了。

![format_png 8][]

### 3.2 HBase 的Key-Value ###

HBase本质上其实就是`Key-Value`的数据库，上一次我们学`Key-Value`数据库还是Redis呢。那在HBase里边，Key是什么？Value是什么？

我们看一下下面的HBase`Key-Value`结构图：

![format_png 9][]

Key由RowKey(行键)+ColumnFamily（列族）+Column Qualifier（列修饰符）+TimeStamp（时间戳--版本）+KeyType（类型）组成，而Value就是实际上的值。

对比上面的例子，其实很好理解，因为我们修改一条数据其实上是在原来的基础上增加一个版本的，那我们要**准确定位**一条数据，那就得（RowKey+Column+时间戳）。

KeyType是什么？我们上面只说了「修改」的情况，你们有没有想过，如果要删除一条数据怎么做？实际上也是增加一条记录，只不过我们在KeyType里边设置为“Delete”就可以了。

### 3.3 HBase架构 ###

扯了这么一大堆，已经说了HBase的数据模型和Key-Value了，我们还有一个问题：「为什么经常会有人说HBase是列式存储呢？」

其实HBase更多的是「**列族存储**」，要谈列族存储，就得先了解了解HBase的架构是怎么样的。

我们先来看看HBase的架构图：

![format_png 10][]

1、**Client**客户端，它提供了访问HBase的接口，并且维护了对应的cache来加速HBase的访问。

2、**Zookeeper**存储HBase的元数据（meta表），无论是读还是写数据，都是去Zookeeper里边拿到meta元数据**告诉给客户端去哪台机器读写数据**

3、**HRegionServer**它是处理客户端的读写请求，负责与HDFS底层交互，是真正干活的节点。

总结大致的流程就是：client请求到Zookeeper，然后Zookeeper返回HRegionServer地址给client，client得到Zookeeper返回的地址去请求HRegionServer，HRegionServer读写数据后返回给client。

![format_png 11][]

### 3.4 HRegionServer内部 ###

我们来看下面的图：

![format_png 12][]

前面也提到了，HBase可以存储海量的数据，HBase是分布式的。所以我们可以断定：**HBase一张表的数据会分到多台机器上的**。那HBase是怎么切割一张表的数据的呢？用的就是**RowKey**来切分，其实就是表的**横向**切割。

![format_png 13][]

说白了就是一个**HRegion**上，存储HBase表的一部分数据。

![format_png 14][]

HRegion下面有**Store**，那Store是什么呢？我们前面也说过，一个HBase表首先要定义**列族**，然后列是在列族之下的，列可以随意添加。

**一个列族的数据是存储**在一起的，所以一个列族的数据是存储在一个Store里边的。

看到这里，其实我们可以认为HBase是基于列族存储的（毕竟物理存储，一个列族是存储到同一个Store里的）

![format_png 15][]

Store里边有啥？有`Mem Store、Store File、HFile`，我们再来看看里边都代表啥含义。

![format_png 16][]

HBase在写数据的时候，会先写到`Mem Store`，当`MemStore`超过一定阈值，就会将内存中的数据刷写到硬盘上，形成**StoreFile**，而`StoreFile`底层是以`HFile`的格式保存，`HFile`是HBase中`KeyValue`数据的存储格式。

所以说：`Mem Store`我们可以理解为内存 buffer，`HFile`是HBase实际存储的数据格式，而`StoreFile`只是HBase里的一个名字。

回到HRegionServer上，我们还漏了一块，就是`HLog`。

![format_png 17][]

这里其实特别好理解了，我们写数据的时候是先写到内存的，为了防止机器宕机，内存的数据没刷到磁盘中就挂了。我们在写`Mem store`的时候还会写一份`HLog`。

这个`HLog`是顺序写到磁盘的，所以速度还是挺快的（是不是有似曾相似的感觉）...

稍微总结一把：

*  HRegionServer是真正干活的机器（用于与hdfs交互），我们HBase表用RowKey来横向切分表
 *  HRegion里边会有多个Store，每个Store其实就是一个列族的数据（所以我们可以说HBase是基于列族存储的）
 *  Store里边有Men Store和StoreFile(HFile)，其实就是先走一层内存，然后再刷到磁盘的结构

### 3.5 被遗忘的HMaster ###

我们在上面的图会看到有个**Hmaster**，它在HBase的架构中承担一种什么样的角色呢？**读写请求都没经过Hmaster呀**。

![format_png 18][]

那HMaster在HBase里承担什么样的角色呢？？

> `HMaster` is the implementation of the Master Server. The Master server is responsible for monitoring all RegionServer instances in the cluster, and is the interface for all metadata changes.

HMaster会处理 HRegion 的分配或转移。如果我们HRegion的数据量太大的话，HMaster会对拆分后的Region**重新分配RegionServer**。（如果发现失效的HRegion，也会将失效的HRegion分配到正常的HRegionServer中）

HMaster会处理元数据的变更和监控RegionServer的状态。

## 四、RowKey的设计 ##

到这里，我们已经知道RowKey是什么了。不难理解的是，我们肯定是要保证RowKey是**唯一**的，毕竟它是行键，有了它我们才可以唯一标识一条数据的。

在HBase里边提供了三种的查询方式：

1.  全局扫描
2.  根据一个RowKey进行查询
3.  根据RowKey过滤的**范围**查询

### 4.1 根据一个RowKey查询 ###

首先我们要知道的是RowKey是会按**字典序**排序的，我们HBase表会用RowKey来横向切分表。

无论是读和写我们都是用RowKey去定位到HRegion，然后找到HRegionServer。这里有一个很关键的问题：**那我怎么知道这个RowKey是在这个HRegion上的**？

HRegion上有两个很重要的属性：`start-key`和`end-key`。

我们在定位HRegionServer的时候，实际上就是定位我们这个RowKey在不在这个HRegion的`start-key`和`end-key`范围之内，如果在，说明我们就找到了。

这个时候会带来一个问题：由于我们的RowKey是以字典序排序的，如果我们对RowKey没有做任何处理，那就有可能存在**热点数据**的问题。

举个例子，现在我们的RowKey如下：

java3y111
    java3y222
    java3y333
    java3y444
    java3y555
    aaa
    bbb
    java3y777
    java3y666
    java3y...

`Java3yxxx`开头的RowKey很多，而其他的RowKey很少。如果我们有多个`HRegion`的话，那么存储`Java3yxxx`的HRegion的数据量是最大的，而分配给其他的HRegion数量是很少的。

关键是我们的查询也几乎都是以`java3yxxx`的数据去查，这会导致某部分数据会集中在某台HRegionServer上存储以及查询，而其他的HRegionServer却很空闲。

如果是这种情况，我们要做的是什么？对**RowKey散列**就好了，那分配到HRegion的时候就比较均匀，少了热点的问题。

> HBase优化手册：
> 
> 建表申请时的预分区设置，对于经常使用HBase的小伙伴来说,HBase管理平台里申请HBase表流程必然不陌生了。
> 
> '**给定split的RowKey组例如:aaaaa,bbbbb,ccccc;或给定例如:startKey=00000000,endKey=xxxxxxxx,regionsNum=x**'
> 
> **第一种方式**:
> 
> > 是自己指定RowKey的分割点来划分region个数.比如有一组数据RowKey为\[1,2,3,4,5,6,7\],此时给定split RowKey是3,6,那么就会划分为\[1,3),\[3,6),\[6,7)的三个初始region了.如果对于RowKey的组成及数据分布非常清楚的话,可以使用这种方式精确预分区.
> 
> **第二种方式** :
> 
> > 如果只是知道RowKey的组成大致的范围,可以选用这种方式让集群来均衡预分区,设定始末的RowKey,以及根据数据量给定大致的region数,一般建议region数最多不要超过集群的rs节点数,过多region数不但不能增加表访问性能,反而会增加master节点压力.如果给定始末RowKey范围与实际偏差较大的话,还是比较容易产生数据热点问题.
> 
> **最后:生成RowKey时,尽量进行加盐或者哈希的处理,这样很大程度上可以缓解数据热点问题.**

### 4.2根据RowKey范围查询 ###

上面的情况是针对通过RowKey单个查询的业务的，如果我们是根据RowKey范围查询的，那没必要上面那样做。

HBase将RowKey设计为字典序排序，如果不做限制，那很可能类似的RowKey存储在同一个HRegion中。那我正好有这个场景上的业务，那我查询的时候不是快多了吗？**在同一个HRegion就可以拿到我想要的数据了**。

举个例子：我们会间隔几秒就采集直播间热度，将这份数据写到HBase中，然后业务方经常要把主播的一段时间内的热度给查询出来。

我设计好的RowKey，将该主播的一段时间内的热度都写到同一个HRegion上，拉取的时候只要访问一个HRegionServer就可以得到全部我想要的数据了，那查询的速度就快很多。

## 最后 ##

最后三歪再来带着大家回顾一下这篇文章写了什么：

1.  HBase是一个NoSQL数据库，一般我们用它来存储海量的数据（因为它基于HDFS分布式文件系统上构建的）
2.  HBase的一行记录由一个RowKey和一个或多个的列以及它的值所组成。先有列族后有列，列可以随意添加。
3.  HBase的增删改记录都有「版本」，默认以时间戳的方式实现。
4.  RowKey的设计如果没有特殊的业务性，最好设计为散列的，这样避免热点数据分布在同一个HRegionServer中。
5.  HBase的读写都经过Zookeeper去拉取meta数据，定位到对应的HRegion，然后找到HRegionServer

参考资料：

*  [https://blog.csdn.net/bitcarmanlee/article/details/78979836][https_blog.csdn.net_bitcarmanlee_article_details_78979836]
 *  [https://hbase.apache.org/book.html\#arch.overview][https_hbase.apache.org_book.html_arch.overview]
 *  [https://zhuanlan.zhihu.com/p/54184168][https_zhuanlan.zhihu.com_p_54184168]
 *  [硬核干货长文！Hbase来了解一下不？][Hbase]
 *  [https://www.jianshu.com/p/569106a3008f][https_www.jianshu.com_p_569106a3008f]
 *  [趣谈Hbase架构][Hbase 1]
 *  [https://www.cnblogs.com/BIG-BOSS-ZC/p/11807304.html][https_www.cnblogs.com_BIG-BOSS-ZC_p_11807304.html]
 *  [一条数据的HBase之旅，简明HBase入门教程-开篇][HBase_HBase_-]
 *  [https://chenhy.com/post/hbase-quickstart/][https_chenhy.com_post_hbase-quickstart]
 *  [https://www.cnblogs.com/zmoumou/p/10292676.html][https_www.cnblogs.com_zmoumou_p_10292676.html]
 *  [https://www.cnblogs.com/duanxz/p/3154487.html][https_www.cnblogs.com_duanxz_p_3154487.html]
 *  [https://www.jianshu.com/p/4e412f48e820][https_www.jianshu.com_p_4e412f48e820]
 *  [HBase 基本入门篇][HBase]
 *  [什么是列式存储？][Link 1]

[Apache]: https://www.apache.org/
[Hadoop]: https://hadoop.apache.org/
[format_png]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxseTFnZjNtMXg4aDlrajMwdjgwZGMwdGcuanBn?x-oss-process=image/format,png
[format_png 1]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxseTFnZjNtNjR5cWo0ajMwa3Ewa2t0OXMuanBn?x-oss-process=image/format,png
[format_png 2]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxseTFnZjNxMHNlOXN2ajMwcmYwOWVteHYuanBn?x-oss-process=image/format,png
[format_png 3]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxseTFnZjNxNXV6OHViajMwcTgwOG53ZjguanBn?x-oss-process=image/format,png
[format_png 4]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZjR6Zmg0MWFpajMwbzcwZHV0OXguanBn?x-oss-process=image/format,png
[format_png 5]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZjYzdXNyaXd6ajMwcXkwOG1uMTYuanBn?x-oss-process=image/format,png
[format_png 6]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZjY0b2NhNW9yajMweDAwNXU3NGsuanBn?x-oss-process=image/format,png
[format_png 7]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZjY1eGUzc2V0ajMwamUwNzJteGsuanBn?x-oss-process=image/format,png
[format_png 8]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZmE5ejF3YW85ajMwbGowYm0wdGwuanBn?x-oss-process=image/format,png
[format_png 9]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZjdiMmtzczNpajMwejIwZnNxNncuanBn?x-oss-process=image/format,png
[format_png 10]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZmFhdDMzcjAzajMwd3EwZmZ0YzIuanBn?x-oss-process=image/format,png
[format_png 11]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZmFlaWMyZjhiajMwZXEwZGdnbWQuanBn?x-oss-process=image/format,png
[format_png 12]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZmFldmgyem1majMwZTMwN3E3NG4uanBn?x-oss-process=image/format,png
[format_png 13]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZmFmcWFtc3NuajMwdGUwaGs0MDEuanBn?x-oss-process=image/format,png
[format_png 14]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZmFoY3ZnNHdvajMwZmkwODA3NGIuanBn?x-oss-process=image/format,png
[format_png 15]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZmFoZG5rNm00ajMwaGowOTdteGguanBn?x-oss-process=image/format,png
[format_png 16]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZmFoaDJuaHY1ajMwZWwwOTBkZnguanBn?x-oss-process=image/format,png
[format_png 17]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZmFqMnFwczM2ajMwZTQwN21qcnYuanBn?x-oss-process=image/format,png
[format_png 18]: https://imgconvert.csdnimg.cn/aHR0cHM6Ly90dmExLnNpbmFpbWcuY24vbGFyZ2UvMDA3UzhaSWxneTFnZmFqOHQ5Z3k0ajMxZXkwbmV3dm8uanBn?x-oss-process=image/format,png
[https_blog.csdn.net_bitcarmanlee_article_details_78979836]: https://blog.csdn.net/bitcarmanlee/article/details/78979836
[https_hbase.apache.org_book.html_arch.overview]: https://hbase.apache.org/book.html#arch.overview
[https_zhuanlan.zhihu.com_p_54184168]: https://zhuanlan.zhihu.com/p/54184168
[Hbase]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247485390&idx=1&sn=3d2ee4b5e0b94d8a88368e98aae24284&chksm=ebd746cfdca0cfd9ce76725501a4e6e384cd11aa2f2e769475d34c513382ad623df71548c68a&token=1120664639&lang=zh_CN#%23%23rd
[https_www.jianshu.com_p_569106a3008f]: https://www.jianshu.com/p/569106a3008f
[Hbase 1]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247485451&idx=1&sn=370a6d8508b8501c3d0aafdfd2857a44&chksm=ebd7490adca0c01ca051b3ac7746f975a75894308f2d0ecf042a016711209e18c6df20233fa0&token=2078489135&lang=zh_CN#%23%23rd
[https_www.cnblogs.com_BIG-BOSS-ZC_p_11807304.html]: https://www.cnblogs.com/BIG-BOSS-ZC/p/11807304.html
[HBase_HBase_-]: https://mp.weixin.qq.com/s?__biz=MzI4Njk3NjU1OQ==&mid=2247483742&idx=1&sn=73dba4a18542362a9aea620f6371df11&chksm=ebd5fe1edca27708c741d842ab13ecde888bbd66ddce16389f62c71b336d7ee5b8834f323aa5&scene=21#wechat_redirect
[https_chenhy.com_post_hbase-quickstart]: https://chenhy.com/post/hbase-quickstart/
[https_www.cnblogs.com_zmoumou_p_10292676.html]: https://www.cnblogs.com/zmoumou/p/10292676.html
[https_www.cnblogs.com_duanxz_p_3154487.html]: https://www.cnblogs.com/duanxz/p/3154487.html
[https_www.jianshu.com_p_4e412f48e820]: https://www.jianshu.com/p/4e412f48e820
[HBase]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247486131&idx=2&sn=1967c4e722cf832b342d4b8a1871adc3&chksm=ebd74bb2dca0c2a410c9a20c14501491d84cab7367e1bd06d90a0118a3f6d7b6e4ebe4b1652d&token=711412693&lang=zh_CN#rd
[Link 1]: https://mp.weixin.qq.com/s?__biz=MzI4Njg5MDA5NA==&mid=2247485401&idx=1&sn=7db59bcaaa5782cdf3f529b0e33523ef&chksm=ebd746d8dca0cfce6c9b32c70061fc1157701d1b4c528f1fa89cdda260cbdff77f7e56045139&token=1120664639&lang=zh_CN#%23%23rd

发表评论取消回复

表情：

评论列表（有 0 条评论，40人围观）

还没有评论，来说两句吧...

相关阅读

相关深入理解Hbase--简介

一、介绍HBase > [Apache][] HBase™ is the [Hadoop][] database, a distributed, scalable, bi

╰+哭是因爲堅強的太久メ/ 2023年02月19日 03:27/ 0 赞/ 41 阅读

相关深入理解HBase Memstore

关注我，回复"资料"，获取大数据资料 MemStore是HBase非常重要的组成部分，深入理解MemStore的运行机制、工作原理、相关配置，对HBase集群管理以及性能调优

男娘i/ 2022年10月18日 04:53/ 0 赞/ 268 阅读

相关深入理解 HBase Compaction 机制

HBase有很多话题可以聊，包括读写路径上涉及到的一些数据结构，性能优化以及优化读写做的一些设计等。今天要探讨的Compaction机制就是HBase架构上做的一个重要优化，其

ゞ浴缸里的玫瑰/ 2022年09月09日 00:28/ 0 赞/ 297 阅读

相关深入理解HBase Indexer

1. 简介 HBase Indexer全名为Lily Hbase Indexer，是NGDATA公司为了将lily子系统里面相关HBase数据存储到Solr而开发的一个软

川长思鸟来/ 2022年08月22日 05:53/ 0 赞/ 392 阅读

相关深入理解HBase的系统架构

HBase的构成 Regions HBase的HMaster ZooKeeper HBase各组成部分之间的合作 HBase的第一次读写

妖狐艹你老母/ 2022年06月14日 01:19/ 0 赞/ 350 阅读

相关 HBase简介

各位小伙伴们，又到了每周分享java&大数据技术的时间，这一次我给大家分享的是hbase技术。那么hbase到底是一个什么样的技术，他又能拿来干嘛用的呢？接下来就让我们一起来学

ゝ一世哀愁。/ 2022年06月01日 12:41/ 0 赞/ 275 阅读

相关深入理解HBase的系统架构

原文链接：https://blog.csdn.net/Yaokai\_AssultMaster/article/details/72877127\hbase%E7%9A%

Myth丶恋晨/ 2022年05月27日 04:19/ 0 赞/ 321 阅读

相关 Hbase简介

一、HBaes介绍 1.1、HBase的起源 HBase的原型是Google的BigTable论文，受到了该论文思想的启发，目前作为Hadoop的子项目来开发维护，

Bertha 。/ 2022年05月21日 03:35/ 0 赞/ 314 阅读

相关 HBase学习 - 深入理解（3）

目录： 1. HBase与Schema设计 1. Schema 创建 2. column families的数量： 3. Rowke

谁践踏了优雅/ 2022年03月07日 02:11/ 0 赞/ 337 阅读

相关深入理解HBase Memstore

MemStore是HBase非常重要的组成部分，深入理解MemStore的运行机制、工作原理、相关配置，对HBase集群管理以及性能调优有非常重要的帮助。 HBase

ゞ浴缸里的玫瑰/ 2021年12月10日 09:05/ 0 赞/ 301 阅读