hbase表存储位置(hbase元数据存储在哪里)

这帖最后由非鱼在2015-4-29 12:23编辑

方案1:HBase自己的大型对象存储方案

由于HBase的所有基本数据都以Bytes数组存储，因此对于非结构化数据的大对象，可以简单地将其转换为Bytes数组存储在HBase中。 另一方面，由于HBase是按列存储的数据库，因此在大表中，大对象数据可以单独存储在HBase表的单个列family中，以免大对象影响其他结构化数据的读取性能

这个方案的优势是：

优点之一：很容易实现。 充分利用HBase自身的特点，逐列保存，将大对象数据单独作为一个列族保存。 不需要引入额外的代码或功能。

优点：数据管理方便。 将大对象数据的管理完全交给HBase自身的结构与其他数据一样，以StoreFile形式存储在Region中，根据HBase对Region的管理方式统一进行迁移、合并、删除等操作。

优势三：保证一致性。 继续HBase自身的强一致性和管理方式，保证其大对象数据的一致性。

这个方案的缺点显然也是：

缺陷一：无法避免冲刺和复制，写入性能差。 如上所述，HBase受大对象的影响，写入时容易频繁启动Split和Compaction，Split对写入操作的阻止和Compaction对集群I/O的占用会直接影响写入性能Compaction操作缓慢会导致Flush延迟，并阻止客户端更新。

缺陷二：不稳定的延迟。 由于Split和Compaction的影响，Flush进程延迟，MemStore增加，客户端插入被锁定。 一方面该延迟难以满足实时系统的低延迟要求，另一方面不稳定的延迟可能引起超时异常，引起不必要的重试。

基于方案HDFS的HBase大对象存储方案

由于大型对象数据的容量太大，Split和Compaction频繁启动，阻止客户端写入，因此如果将大型对象数据排除在HBase本身的写入过程之外，则可以将HBase Split和Compaction与

由于HBase本身依赖于分布式文件系统HDFS，因此如果直接将大型对象数据存储在HDFS中，并将结构化数据和大型对象文件索引存储在HBase中，则可以将容量小的结构化数据和大型对象的文件索引存储在Split和Compaction触发器大幅减少，确保HBase大型对象存储的写入性能得到提高。

在HDFS中保存大对象的形式也主要分为两种：

方案a将各大对象的数据作为一个文件直接保存在HDFS中，HBase保存各大对象的文件地址即可。

QQ截图20150428203430.png(135.26kb，下载次数： 8) )。

2015-4-28上传20:49

这个方案的优点是实现起来比较简单。 客户端可以直接利用HDFS的API接口实现数据的put，大型对象数据以最简单的方式避免了HBase的flush机制。 但是，其主要缺点是生成了大量的小文件，大量的小文件在一定程度上影响了HDFS的整体性能。

方案b是将多个大对象数据存储在一个序列文件中。

2.png(116.57kb，下载次数： 7)。

2015-4-28上传20:49

在a方案中，将单个大对象数据作为单个文件写入HDFS会产生大量小文件，给Namenode带来巨大负担，因此业界很快就会使用HDFS自己的文件格式SequenceFile 将多个大对象数据存储在一个Sequence File中，HBase存储结构化数据和Sequence File的文件链接目标及其偏移。

序列文件是Hadoop为存储二进制格式的关键值对而设计的平面文件(平面文件)。 现在有几个人根据这个文件提出来

HDFS中小型文件存储解决方案的基本思想是将小文件合并为一个大文件，并对这些小文件的位置信息进行索引。 但是，这类解决方案还包括另一种Hadoop文件格式--MapFile文件。 SequenceRle文件并不保证保存的key-value数据是按照key的顺序保存的。

该方案的优点是：易于实现，直接使用HDFS的序列文件的API接口； 同时，避免了a方案中出现大量小文件的问题。 这个方案的主要缺点是不能保证一致性。 其主要原因是，当HBase成功写入包含结构化和大对象数据的SequenceFile文件的链接目标后，Sequencenie本身由于某些外部因素导致写入失败，导致该SequenceFile无法成功生成

综合a、b两种方案，总结了将大对象数据直接写入HDFS方案的优缺点，

它的好处是：

优点1，的实现比较简单。 总体实现方案只基于h

优势二:让大对象数据回避了 HBase的Split和Compaction机制,确实可以提升其写性能。

但是其缺陷也很明显:

缺陷一:需要客户端编写额外的代码。客户端在原本的HBase插入程序的基础上需要引入HDFS的文件插入接口,获取其HDFS文件链接并写入HBase中,在编程方面并不是特别友好。

缺陷二:大对象数据管理的困难。对于已经不再被引用的大对象数据和过时的大对象数据,由于其存在于HDFS上,若无其他人工干预将没有办法清理这些超时文件,长此以往将严重影响整个集群的性能。

方案3：基于列族(ColumnFamily,CF)定制的HBase自身方案

由于大对象的影响,在写入时HBase将频繁Compaction从而占用过高的集群j/0,导致其写性能降低的,而把大对象数据绕过HBase直接写成HDFS文件格式不方便管理,那我们接下来可能考虑的方向是在HBase机制内怎样才能回避掉 Region 的 Split 和 Compaction 阶段。

而其中的一个方向就是对存储大对象数据的ColumnFamily定制其Compaction机制,让其在插入过程中不执行Compaction操作HBase有多个参数来控制其Compaction的触发,其中一个比较关键的参数如下:

hbase.hstore.compaction.min ,这个参数的作用是控制最小MinorCompaction的文件个数。当一个Region中StoreFile的数量超过这个值时会幵始检查是否需要Compaction,同时该参数也是指可以被Compaction的最小文件个数,如果选取的文件数目小于它,则不会做Compaction。

所以,若仅针对存储大对象数据的CloumnFamily设置该Compaction参数,将其值调大,如计算机的无限大值(Long.MAX_VALUE),那么该CloumnFamily在写入过程中将不会有机会触发Minor Compaction,从而集群不会被大对象数据引发的频繁Compaction影响I/O性能,从而能在一定程度上提高写入性能而又不影响HBase对大对象数据的管理。

而该方案对于存储结构化数据的Column Family并不干扰,其存储结构化数据的ColumnFamily依然按照HBase的Compaction机制进行其MinorCompation。

此方案的优势在于:

优势一:实现方便。仅需要针对存储大对象数据的ColumnFamily设置其compaction参数即可。

优势二:数据管理方便。仍然将大对象数据存储在HBase自己的数据格式中,其大对象数据的管理依然交由HBase自身机制完成,利于数据的管理维护。

优势三:回避了 Minor Compaction对于写入性能的影响。单独禁用存储大对象的Column Family,减少因大对象频繁触发Compaction对于集群丨/〇性能的影响,提高其写入性能。

而其缺陷在于:

缺陷一:未解决Split带来的影响。该方案仅仅将大对象数据的Compaction机制给省略掉了,但是另一个影响写入性能的因素Split并没有在该方案中被考

虑到,由于大对象频繁触发Split引起客户端写入阻塞的影响仍未解决。

缺陷二:大量大对象的StoreFiles影响读性能。由于为大对象数据定制了无compaction机制,所以HBase的Region中会存储着大量的大对象Storefiles,这导致HBase的scan (顺序读多条数据)操作和随机读操作极慢,并且大量的StoreFiles会增加HBase的Block indexes (块索引)在内存中的存储负担,影

响其插入性能。