文档章节

【翻译】Apache Hbase新特性--MOB支持(一)

jeff-qq
 jeff-qq
发布于 2017/10/18 20:58
字数 1937
阅读 801
收藏 2

原文链接:http://blog.cloudera.com/blog/2015/06/inside-apache-hbases-new-support-for-mobs/

HBase MOBs特性的设计背景

Apache HBase is a distributed, scalable, performant, consistent key value database that can store a variety of binary data types. It excels at storing many relatively small values (<10K), and providing low-latency reads and writes.

However, there is a growing demand for storing documents, images, and other moderate objects (MOBs)  in HBase while maintaining low latency for reads and writes. One such use case is a bank that stores signed and scanned customer documents. As another example, transport agencies may want to store  snapshots of traffic and moving cars. These MOBs are generally write-once.

Apache HBase是一个分布式、可扩展,高性能,一致的键值数据库,可以存储多种多样的二进制数据。存储小文件(小于10K)十分出色,读写延迟低。

随之而来,对文档、图片和其他中等大小文件的存储需求日益增长,并且要保持读写低延迟。一个典型的场景就是银行存储客户的签字或扫描的文档。另一个典型的场景,交通部门保存路况或过车快照。中等大小文件通常写入一次。

Unfortunately, performance can degrade in situations where many moderately sized values (100K to 10MB) are stored due to the ever-increasing  I/O pressure created by compactions. Consider the case where 1TB of photos from traffic cameras, each 1MB in size, are stored into HBase daily. Parts of the stored files are compacted multiple times via minor compactions and eventually, data is rewritten by major compactions. Along with accumulation of these MOBs, I/O created by compactions will slow down the compactions, further block memstore flushing, and eventually block updates. A big MOB store will trigger frequent region splits, reducing the availability of the affected regions.

In order to address these drawbacks, Cloudera and Intel engineers have implemented MOB support in an HBase branch (hbase-11339: HBase MOB). This branch will be merged to the master in HBase 1.1 or 1.2, and is already present and supported in CDH 5.4.x, as well. 

不幸的是,存储文件大小在100k到10M之间时,由于压缩导致的持续增长的读写压力,会导致性能下降。想象一下这样的场景,交通摄像头每天产生1TB的照片存到Hbase里,每个文件1MB。一部分文件被多次压缩以达到最小化。数据因为压缩被重复写入。随着中等大小文件数量的积累,压缩产生的读写会使压缩变慢,进一步阻塞memstore刷新,最终阻止更新。大量的MOB存储会触发频繁的region分割,相应region的可用性下降。

为了解决这个问题,Cloudera和Intel的工程师在Hbase的分支实现了对MOB的支持。 (hbase-11339: HBase MOB)。(译者注:这个特性并没有出现在1.1和1.2版本,而是被合入的2.0.0版本)。你可以在CDH 5.4.x中获取。

Operations on MOBs are usually write-intensive, with rare updates or deletes and relatively infrequent reads. MOBs are usually stored together with their metadata. Metadata relating to MOBs may include, for instance, car number, speed, and color. Metadata are very small relative to the MOBs. Metadata are usually accessed for analysis, while MOBs are usually randomly accessed only when they are explicitly requested with row keys.

Users want to read and write the MOBs in HBase with low latency in the same APIs, and want strong consistency, security, snapshot and HBase replication between clusters, and so on. To meet these goals, MOBs were moved out of the main I/O path of HBase and into a new I/O path.

In this post, you will learn about this design approach, and why it was selected.

对MOB的操作通常集中在写入,很少更新或删除,读取不频繁。MOB通常跟元数据一起被存储。元数据相对MOB很小,通常用来统计分析,而MOB一般通过明确的row key来获取。

用户希望在Hbase中用相同的API来读写MOB文件,并且集群之间保持低延迟,强一致、安全、快照和Hbase副本等特性。要达到这一目标,必须将MOB从 HBase主要的读写目录移到新的读写目录。

可行方案分析

There were a few possible approaches to this problem. The first approach we considered was to store MOBs in HBase with a tuned split and compaction policies—a bigger desired MaxFileSize decreases the frequency of region split, and fewer or no compactions can avoid the write amplification penalty. That approach would improve write latency and throughput considerably. However, along with the increasing number of stored files, there would be too many opened readers in a single store, even more than what is allowed by the OS. As a result, a lot of memory would be consumed and read performance would degrade.

解决这个问题有潜在的方法。第一种,优化分割(split)和压缩策略——一个更大的MaxFileSize来降低region分割频率,减少或者不压缩来避免写入恶化。这样会改善写入延迟,吞吐量好得多。但是,随着文件数量的增长,一次存储会打开非常多的reader,甚至超过操作系统的限制。结果就是内存被耗光,性能下降。

Another approach was to use an HBase + HDFS model to store the metadata and MOBs separately. In this model, a single file is linked by an entry in HBase. This is a client solution, and the transaction is controlled by the client—no HBase-side memories are consumed by MOBs. This approach would work for objects larger than 50MB, but for MOBs, many small files lead to inefficient HDFS usage since the default block size in HDFS is 128MB.

For example, let’s say a NameNode has 48GB of memory and each file is 100KB with three replicas. Each file takes more than 300 bytes in memory, so a NameNode with 48GB memory can hold about 160 million files, which would limit us to only storing 16TB MOB files in total.

另外一种方式可以采用HBase+HDFS的方式来分开存储元数据和MOB文件。一个文件对应一个Hbase入口。这是客户端的解决方案,事务在客户端控制。MOB不会消耗Hbase的内存。存储的对象可以超过50MB。但是,大量的小文件使HDFS利用率不高,因为默认的块大小是128M。

举个例子,NameNode有48G内存,每个文件100KB,3个副本。每个文件在内存中占用300字节,48G内存可以存大约1.6亿文件,限制了存储的总文件大小仅仅16T。

As an improvement, we could have assembled the small MOB files into bigger ones—that is, a file could have multiple MOB entries–and store the offset and length in the HBase table for fast reading. However, maintaining data consistency and managing deleted MOBs and small MOB files in compactions are difficult. Furthermore, if we were to use this approach, we’d have to consider new security policies, lose atomicity properties of writes, and potentially lose the backup and disaster recovery provided by replication and snapshots.

我们可以许多小的MOB合成一个大文件,一个文件有多个MOB入口,通过存储偏移量(offset)和长度来加快读取。不过维护数据一致性,管理删除的文件和压缩后的小文件十分困难。而且,我们还需要考虑安全策略,失去写数据的原子性,可能会丢失由复制和快照提供的备份和灾难恢复。

HBase MOB 架构设计

In the end, because most of the concerns around storing MOBs in HBase involve the I/O created by compactions, the key was to move MOBs out of management by normal regions to avoid region splits and compactions there.

The HBase MOB design is similar to the HBase + HDFS approach because we store the metadata and MOBs separately. However, the difference lies in a server-side design: memstore caches the MOBs before they are flushed to disk, the MOBs are written into a HFile called “MOB file” in each flush, and each MOB file has multiple entries instead of single file in HDFS for each MOB. This MOB file is stored in a special region. All the read and write can be used by the current HBase APIs.

最后,由于大部分担心来自于压缩带来的IO,最关键的是将MOB移出正常region的管理来避免region分割和压缩。

HBase MOB设计类似于Hbase+HDFS的方式,将元数据和MOB分开存。不同的是服务端的设计。中等大小文件在被刷到磁盘前缓存在memstore里,每次刷新,中等大小文件被写入特殊的HFile文件—“MOB File”。每个中等文件有多个MOB入口,而不像HDFS只有一个入口。MOB file被放在特殊的region。读写都通过现有的Hbase API。

 

未完,见下一篇:https://my.oschina.net/u/234661/blog/1553060

© 著作权归作者所有

jeff-qq
粉丝 2
博文 16
码字总数 15215
作品 0
济南
高级程序员
私信 提问
HBase中存取图片、文档数据(HBase MOB)

Hbase MOB介绍 HBase通常存取小于10K的数据性能很好,如果文件稍大点,比如中等文件的大小,大小在100K<10M之间,由于压缩会带来性能下降,会导致region不可用。 为了解决这个问题,HBase引入...

jeff-qq
2017/10/19
3.3K
0
HBase MOB压缩分区策略介绍

介绍 HBase MOB特性是在HBASE-11339中引入,这一特性改善了对中等大小值的低延迟读写(基于我们的测试结果理想状态是100K到10M),这使得可以更好的存储文本,图片和一些其他的中等对象[1],H...

HBase技术社区
2018/04/20
0
0
HBase实战之MOB使用指南

若要启用MOB功能,需要在每个RegionServer进行配置,并在建表或者修改表时对指定列族启用MOB特性。在HBase尝鲜版中启用MOB功能,需要由admin用户设置定期进程,以重新优化MOB数据的分布。 增...

HBase技术社区
2018/10/08
0
0
期待已久的Apache HBase2.0正式发布

激动 期待已久的HBase 2.0发布啦! 膜拜 拜读stack大神announce email原文,激动人心的时刻: 邮件简述了HBase 2.0.0 有新版Assignment Manager V2,offhead read/write, in-memory compactio...

tins.wzy
2018/05/02
0
0
【翻译】Apache Hbase新特性--MOB支持(二)

接上一篇:https://my.oschina.net/u/234661/blog/1553005 MOB文件读写 Each MOB has a threshold: if the value length of a cell is larger than this threshold, this cell is regarded a......

jeff-qq
2017/10/18
634
0

没有更多内容

加载失败,请刷新页面

加载更多

java通过ServerSocket与Socket实现通信

首先说一下ServerSocket与Socket. 1.ServerSocket ServerSocket是用来监听客户端Socket连接的类,如果没有连接会一直处于等待状态. ServetSocket有三个构造方法: (1) ServerSocket(int port);...

Blueeeeeee
16分钟前
2
0
用 Sphinx 搭建博客时,如何自定义插件?

之前有不少同学看过我的个人博客(http://python-online.cn),也根据我写的教程完成了自己个人站点的搭建。 点此:使用 Python 30分钟 教你快速搭建一个博客 为防有的同学不清楚 Sphinx ,这...

王炳明
昨天
4
0
黑客之道-40本书籍助你快速入门黑客技术免费下载

场景 黑客是一个中文词语,皆源自英文hacker,随着灰鸽子的出现,灰鸽子成为了很多假借黑客名义控制他人电脑的黑客技术,于是出现了“骇客”与"黑客"分家。2012年电影频道节目中心出品的电影...

badaoliumang
昨天
13
0
很遗憾,没有一篇文章能讲清楚线程的生命周期!

(手机横屏看源码更方便) 注:java源码分析部分如无特殊说明均基于 java8 版本。 简介 大家都知道线程是有生命周期,但是彤哥可以认真负责地告诉你网上几乎没有一篇文章讲得是完全正确的。 ...

彤哥读源码
昨天
13
0
jquery--DOM操作基础

本文转载于:专业的前端网站➭jquery--DOM操作基础 元素的访问 元素属性操作 获取:attr(name);$("#my").attr("src"); 设置:attr(name,value);$("#myImg").attr("src","images/1.jpg"); ......

前端老手
昨天
6
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部