HBase优化之路-合理的使用编码压缩

简介: 为什么要讨论HBase编码压缩 编码+压缩能够成倍的减少数据的磁盘占用空间,节省可观的存储费用 编码+压缩通常情况下可以提高系统吞吐率,让系统可以做更多的功 默认建表不启用编码或者压缩,对初学者不友好 了解HBase编码 举个栗子,我们有一张物流表叫"express",记录物流订单的流转详情。

为什么要讨论HBase编码压缩

  • 编码+压缩能够成倍的减少数据的磁盘占用空间,节省可观的存储费用
  • 编码+压缩通常情况下可以提高系统吞吐率,让系统可以做更多的功
  • 默认建表不启用编码或者压缩,对初学者不友好

了解HBase编码

举个栗子,我们有一张物流表叫"express",记录物流订单的流转详情。如下面表格:rowkey包含两个部分,用#号分割,左边是物流订单号,右边是物流信息的更新时间点。表包含两个列,一个物流状态,一个是物流描述信息

rowkey 状态列 描述信息列
10324224#2019-04-21 10:51 已发货 包裹正在等待揽收
10324224#2019-04-21 19:46 已揽件 [嘉兴市]平湖南桥的xxx已揽收
10324224#2019-04-21 19:46 运输中 [嘉兴市]快件已从平湖南桥出发,准备发往嘉兴中转部
10324224#2019-04-21 20:41 运输中 [嘉兴市]快件已到达嘉兴中转部
10324224#2019-04-21 20:42 运输中 [嘉兴市]快件已从达嘉兴中转部出发,准备发往杭州中转部
10324224#2019-04-21 22:50 运输中 [嘉兴市]快件已到达杭州中转部
... ... ...

我们对Rowkey进行编码得到如下

rowkey rowkey 前缀长度 状态列 详情列
10324224#2019-04-21 10:51 0 已发货 包裹正在等待揽收
19:46 20 已揽件 [嘉兴市]平湖南桥的xxx已揽收
19:46 20 运输中 [嘉兴市]快件已从平湖南桥出发,准备发往嘉兴中转部
20:41 20 运输中 [嘉兴市]快件已到达嘉兴中转部
20:42 20 运输中 [嘉兴市]快件已从达嘉兴中转部出发,准备发往杭州中转部
22:50 20 运输中 [嘉兴市]快件已到达杭州中转部
... ... ... ...

可以看到,除了第一行存储了完整的rowkey以外,其它行与首行进行了Diff,只保存了不相同的部分。除了rowkey编码以为,HBase还可以对版本号,更新类型等进行编码。HBase目前提供的可靠的编码包括“Prefix,Diff,Fast Diff, Index Encoding(阿里巴巴HBase团队研发的优化随机读场景的编码)”,更多关于编码的参考Compression and Data Block Encoding In HBase以及HBase数据压缩编码探索

了解HBase压缩

HBase压缩的对象是一行中的值,不包括rowkey、版本等。由于HBase的元数据中没有数据类型,因此HBase的压缩算法都是面向通用压缩场景,一般会有4-10倍的压缩率,下面表格介绍了各种压缩算法在不同场景下的收益

image

HBase还有其它的压缩算法如“Snappy,GZIP”。更多关于压缩的参考Compression and Data Block Encoding In HBase以及HBase数据压缩编码探索

如何选择HBase编码压缩

不同的场景下优化的侧重不同,选择的难度也不同。

  • 读少写多,大存储量场景

该场景通常是存储一些比较冷的数据,对请求的响应要求不高,对存储成本敏感。在存储介质上通常选择便宜的HDD、高效云盘。这些介质相比于SSD在IO吞吐和IOPS方面都要弱很多。这里我们选择高压缩比的压缩算法“ZSTD、GZIP”,编码选择Diff。比如“Diff+ZSTD”组合,不仅节省存储成本,同时会减少写入和Compaction对IO的压力(因为写入磁盘的数据量减少了),提升写吞吐量

注:压缩不是万金油,有时候数据写入前就压缩了,或者压缩率不理想,这时候设置压缩反而浪费了CPU,弄巧成拙。因此我们需要运行时数据来判断压缩比,进入HBase的Web UI,找到表‘t1’的详情页:

image

我们把Table Schema部分展开,看一下当前表的编码(DATA_BLOCK_ENCODING)和压缩(COMPRESSION)配置

image

然后我们继续向下看Table Regions,看到表‘t1’有两个分区分布在两台Region Server节点上。我们选择一个Region Server点进入

image

选择第一个Region Server进入

image

在Region Server的详情中,我们找到Regions部分,然后选择Storefile Metrics标签,下面是该Region Server上各个分区的文件详情。我们找到‘t1’表的分区,如上图红色框的哪一行,可以看到文件未编码压缩前是305MB,编码压缩后是49MB,压缩比是 1 :6.2

  • 读请求较多场景

该场景一般偏向在线,请求多且对延迟有一定要求。读的优化相比写要更复杂,这个和场景关联性很强,所以我们可以有一些策略和预判,但是还是需要实际的数据来指导优化,具体问题具体分析。总的来讲,读存在一个缓存“BlockCache”,缓存的命中率严重影响读的性能。默认的情况下BlockCache中的数据是可以保持“编码”,但是数据从磁盘读出后被解压存储在BlockCache,在2.0版本中新增了Compressed Block Cache(全表维度),使得Block Cache中的数据也可以处于压缩状态。

优势:
1 缓存一般的命中在20%~80%较常见,因此一定有相当量的请求要走磁盘IO,那么编码压缩有助于减少这部分IO的开销
2 编码和压缩都可以使得Block Cache缓存更多的数据,从而提高命中率。但具体的提升效果也和场景相关,随机读场景的提升就不如顺序读多的场景
3 由于缓存命中提高,缓存淘汰相应减少,有利于GC

劣势:
1 编码压缩增加了CPU的开销,在CPU资源吃紧的情况下会影响读写响应时间

总结,通常情况下建议编码压缩都打开,使用DIFF+ZSTD组合作为默认配置可以满足绝大部分场景。通过HBase WebUI以及监控观察压缩比,CPU负载,IO负载,缓存命中率,读写请求响应等指标来判断是否需要进一步调整编码压缩配置。

如何修改编码压缩

编码压缩是column family级别的,我们可以通过shell来在线修改

alter 't1', {NAME => 'info', DATA_BLOCK_ENCODING => 'DIFF', COMPRESSION => 'ZSTD'}

注:修改表的编码压缩后并不是立即生效的,需要执行一次Major Compaction刷一遍数据文件,新生成文件才是新的编码压缩格式。

相关实践学习
云数据库HBase版使用教程
  相关的阿里云产品:云数据库 HBase 版 面向大数据领域的一站式NoSQL服务,100%兼容开源HBase并深度扩展,支持海量数据下的实时存储、高并发吞吐、轻SQL分析、全文检索、时序时空查询等能力,是风控、推荐、广告、物联网、车联网、Feeds流、数据大屏等场景首选数据库,是为淘宝、支付宝、菜鸟等众多阿里核心业务提供关键支撑的数据库。 了解产品详情: https://cn.aliyun.com/product/hbase   ------------------------------------------------------------------------- 阿里云数据库体验:数据库上云实战 开发者云会免费提供一台带自建MySQL的源数据库 ECS 实例和一台目标数据库 RDS实例。跟着指引,您可以一步步实现将ECS自建数据库迁移到目标数据库RDS。 点击下方链接,领取免费ECS&RDS资源,30分钟完成数据库上云实战!https://developer.aliyun.com/adc/scenario/51eefbd1894e42f6bb9acacadd3f9121?spm=a2c6h.13788135.J_3257954370.9.4ba85f24utseFl
目录
相关文章
|
2月前
|
机器学习/深度学习 分布式计算 Hadoop
一种HBase表数据迁移方法的优化
一种HBase表数据迁移方法的优化
32 0
|
10月前
|
存储 SQL 消息中间件
Kylin 在贝壳的性能挑战和 HBase 优化实践(2)
Kylin 在贝壳的性能挑战和 HBase 优化实践
Kylin 在贝壳的性能挑战和 HBase 优化实践(2)
|
10月前
|
SQL 分布式计算 监控
Kylin 在贝壳的性能挑战和 HBase 优化实践(1)
Kylin 在贝壳的性能挑战和 HBase 优化实践
Kylin 在贝壳的性能挑战和 HBase 优化实践(1)
|
缓存 安全 Java
HBase 优化_3 | 学习笔记
快速学习 HBase 优化_3
127 0
|
存储 缓存 分布式数据库
HBase 优化_2 | 学习笔记
快速学习 HBase 优化_2
94 0
|
存储 负载均衡 分布式数据库
HBase 优化_1 | 学习笔记
快速学习 HBase 优化_1
98 0
|
存储 监控 物联网
解密 云HBase时序引擎OpenTSDB 优化技术
逝者如斯夫,不舍昼夜。                                                       —— 孔子 时间如流水,一去不复返。自古不乏对时间流逝的感慨,而现代已经有很多技术记录流逝的过去。
2253 0
解密 云HBase时序引擎OpenTSDB 优化技术
|
存储 Hbase 分布式数据库
面向海量数据的极致成本优化-云HBase的一体化冷热分离
随着业务的持续发展,业务数据库存储量会持续增长。通常数据量过亿时,就需要考虑选择扩展能力更好的NOSQL数据库如HBase,足够满足大多数业务的存储需求。然而,对于大量存储瓶颈类业务,存储成本依然是系统设计中需要关注的重中之重,本文介绍了一种全新的冷热分离一体化方案,0改造成本实现业务冷热分离
5113 0
面向海量数据的极致成本优化-云HBase的一体化冷热分离
|
Java Hbase
如何降低90%Java垃圾回收时间?以阿里HBase的GC优化实践为例
GC一直是Java应用中讨论的一个热门话题,尤其在像HBase这样的大型在线存储系统中,大堆下(百GB)的GC停顿延迟产生的在线实时影响,成为内核和应用开发者的一大痛点。
9390 0
GC优化利器 - HBase2.0全链路offheap
gc问题会带来访问毛刺,回顾一下读写链路,然后看看全链路offheap怎么减少gc停顿、减低p999延迟的。
1937 0