2、Hbase数据持久化

最新推荐文章于 2023-06-01 19:28:03 发布

weixin_33923148

最新推荐文章于 2023-06-01 19:28:03 发布

阅读量1k

点赞数

文章标签：大数据数据库运维

原文链接：https://my.oschina.net/liufukin/blog/796506

版权

2019独角兽企业重金招聘Python工程师标准>>>

一：海量数据存储问题

在大数据存储领域，海量的数据需要存储，而单机存储能力又极为有限，不可能单机能够存储的下，怎么破？目前的框架无一例外地使用了“分而治之”思想，只是具体怎么分的区别而已。

1、hdfs

将一个很大的文件分为一个个split（128M）分片存储到不同的datanode上，通过nameNode来记录存储位置。

2、kafka

将一个主题（topic）分为多个partition，均匀存储到不同的broker中，来提高写入和读取速度。只是它的“分”是通过（msg的hash % partition数量）来确定这条数据属于哪个partition。注意：partition数可以大于broker数量，这样一个broker就会管理多个分区。

3、redis

redis的sharding模式集群，通过consistency hash算法将每个redis实例的hash值打到consistency hash 环中，然后同样通过Msg的hash值对应到hash环的位置，就能够知道它是属于哪个redis节点。

问题1：为什么redis不采用kafka那种（msg的hash % partition数量）来确定数据属于哪个redis节点？在redis节点动态改变：上线或者下线时，会导致整个redis集群无法工作。因为相同的数据"aaaaaa".hashCode() % redis数量前后不一致。这样就导致之前放进去的数据，现在无法命中，也就是取不出来。这就会导致redis集群雪崩问题。

问题2：那为什么Kafka不会有这样的问题呢？因为kafka存到partition的数据，在partition中都会有一个唯一的offset，client是通过offset来获取获取这条数据，而不是像redis这样，去取数据前，先"aaaaaa".hashCode() % redis看看数据在那个redis节点。

二：那么Hbase是如何存储单表数据的？

按照rowKey字典顺序进行水平切割

Table中的所有行都按照row key的字典序排列。
Table 在行的方向上分割为多个Hregion。类似于mysql表“水平切分”
region按大小分割的(默认10G)，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。
Hregion是Hbase中分布式存储和负载均衡的最小单元。最小单元就表示不同的Hregion可以分布在不同的HRegion server上。但一个Hregion是不会拆分到多个server上的。
HRegion虽然是负载均衡的最小单元，但并不是物理存储的最小单元。事实上，HRegion由一个或者多个Store组成，每个store保存一个column family。每个Strore又由一个memStore和0至多个StoreFile组成。

问题：既然数据按照rowKey进行排序，如果一个组成rowKey前缀身份非常大，这样会形成数据倾斜，该怎么处理？前缀加随机数或者rowKey做md5。