pinpoint 单机HBASE数据量过大问题解决

Pinpoint接入业务监控后数据量大涨，平均每周Hbase数据增量25G左右，数据量太大，需要对数据进行定期清理，否则监控可用性降低。

操作步骤
查找出数据大的hbase表

[[email protected] worker]# du -sh hbase/data/default/*

2.2M    hbase/data/default/AgentEvent

348K    hbase/data/default/AgentInfo

2.6M    hbase/data/default/AgentLifeCycle

329M    hbase/data/default/AgentStatV2

34M hbase/data/default/ApiMetaData

44K hbase/data/default/ApplicationIndex

66M hbase/data/default/ApplicationMapStatisticsCallee_Ver2

60M hbase/data/default/ApplicationMapStatisticsCaller_Ver2

16M hbase/data/default/ApplicationMapStatisticsSelf_Ver2

1.1M    hbase/data/default/ApplicationStatAggre

1.1G    hbase/data/default/ApplicationTraceIndex

976K    hbase/data/default/HostApplicationMap_Ver2

15M hbase/data/default/SqlMetaData_Ver2

848K    hbase/data/default/StringMetaData

21G hbase/data/default/TraceV2

24小时产生数据大概20G，发现其中TraceV2及ApplicationTraceIndex数据比较大，设置TTL分别为7Day及14Day

进入hbase修改表ttl

[[email protected] ~]# /usr/local/hbase-1.0.3/bin/hbase shell

2019-08-19 15:43:20,320 WARN  [main] util.NativeCodeLoader: Unable to load native-hadoop library for your platform... using builtin-java classes where applicable

hbase(main):002:0> list

TABLE                                                                                                                                                               

AgentEvent                                                                                                                                                         

AgentInfo                                                                                                                                                          

AgentLifeCycle                                                                                                                                                      

AgentStatV2                                                                                                                                                        

ApiMetaData                                                                                                                                                         

ApplicationIndex                                                                                                                                                    

ApplicationMapStatisticsCallee_Ver2                                                                                                                                

ApplicationMapStatisticsCaller_Ver2                                                                                                                                 

ApplicationMapStatisticsSelf_Ver2                                                                                                                                   

ApplicationStatAggre                                                                                                                                               

ApplicationTraceIndex                                                                                                                                               

HostApplicationMap_Ver2                                                                                                                                             

SqlMetaData_Ver2                                                                                                                                                   

StringMetaData                                                                                                                                                      

TraceV2                                                                                                                                                            

15 row(s) in 0.0100 seconds

=> ["AgentEvent", "AgentInfo", "AgentLifeCycle", "AgentStatV2", "ApiMetaData", "ApplicationIndex", "ApplicationMapStatisticsCallee_Ver2", "ApplicationMapStatisticsCaller_Ver2", "ApplicationMapStatisticsSelf_Ver2", "ApplicationStatAggre", "ApplicationTraceIndex", "HostApplicationMap_Ver2", "SqlMetaData_Ver2", "StringMetaData", "TraceV2"]

hbase(main):004:0> describe ‘TraceV2‘

Table TraceV2 is ENABLED                                                                                                                                            

TraceV2                                                                                                                                                            

COLUMN FAMILIES DESCRIPTION                                                                                                                                         

{NAME => ‘S‘, BLOOMFILTER => ‘ROW‘, VERSIONS => ‘1‘, IN_MEMORY => ‘false‘, KEEP_DELETED_CELLS => ‘FALSE‘, DATA_BLOCK_ENCODING => ‘PREFIX‘, TTL => ‘5184000 SECONDS (

60 DAYS)‘, COMPRESSION => ‘NONE‘, MIN_VERSIONS => ‘0‘, BLOCKCACHE => ‘true‘, BLOCKSIZE => ‘65536‘, REPLICATION_SCOPE => ‘0‘}                                       

1 row(s) in 0.1190 seconds

hbase(main):005:0> disable ‘TraceV2‘

0 row(s) in 4.2190 seconds

hbase(main):006:0> alter ‘TraceV2‘ , {NAME=>‘S‘,TTL=>‘604800‘}

Updating all regions with the new schema...

256/256 regions updated.

Done.

0 row(s) in 1.0980 seconds

hbase(main):009:0> enable ‘TraceV2‘

0 row(s) in 4.2370 seconds

hbase(main):010:0> describe ‘TraceV2‘

Table TraceV2 is ENABLED                                                                                                                                           

TraceV2                                                                                                                                                             

COLUMN FAMILIES DESCRIPTION                                                                                                                                         

{NAME => ‘S‘, BLOOMFILTER => ‘ROW‘, VERSIONS => ‘1‘, IN_MEMORY => ‘false‘, KEEP_DELETED_CELLS => ‘FALSE‘, DATA_BLOCK_ENCODING => ‘PREFIX‘, TTL => ‘604800 SECONDS (7

 DAYS)‘, COMPRESSION => ‘NONE‘, MIN_VERSIONS => ‘0‘, BLOCKCACHE => ‘true‘, BLOCKSIZE => ‘65536‘, REPLICATION_SCOPE => ‘0‘}                                         

1 row(s) in 0.0160 seconds

hbase(main):002:0> describe ‘TraceV2‘

Table TraceV2 is ENABLED

TraceV2

COLUMN FAMILIES DESCRIPTION

{NAME => ‘S‘, BLOOMFILTER => ‘ROW‘, VERSIONS => ‘1‘, IN_MEMORY => ‘false‘, KEEP_DELETED_CELLS => ‘FALSE‘, DATA_BLOCK_ENCODING => ‘PREFIX‘, TTL => ‘5184000 SECONDS (60 DAYS)‘, COMPRESSION => ‘NONE‘, MIN_VERSIONS => ‘0‘, BLOCKCACHE => ‘true‘, BLOCKSIZE => ‘65536‘, REPLICATION_SCOPE => ‘0‘}

1 row(s) in 0.1000 seconds

设置ApplicationTraceIndex的TTL为 14天

hbase(main):011:0> describe  ‘ApplicationTraceIndex‘

Table ApplicationTraceIndex is ENABLED                                                                                                                              

ApplicationTraceIndex                                                                                                                                              

COLUMN FAMILIES DESCRIPTION                                                                                                                                        

{NAME => ‘I‘, BLOOMFILTER => ‘ROW‘, VERSIONS => ‘1‘, IN_MEMORY => ‘false‘, KEEP_DELETED_CELLS => ‘FALSE‘, DATA_BLOCK_ENCODING => ‘PREFIX‘, TTL => ‘5184000 SECONDS (

60 DAYS)‘, COMPRESSION => ‘NONE‘, MIN_VERSIONS => ‘0‘, BLOCKCACHE => ‘true‘, BLOCKSIZE => ‘65536‘, REPLICATION_SCOPE => ‘0‘}                                       

1 row(s) in 0.0150 seconds

hbase(main):012:0> disable ‘ApplicationTraceIndex‘

0 row(s) in 1.1660 seconds

hbase(main):013:0> alter ‘ApplicationTraceIndex‘ , {NAME=>‘I‘,TTL=>‘1209600‘}

Updating all regions with the new schema...

16/16 regions updated.

Done.

0 row(s) in 1.0550 seconds

hbase(main):014:0> enable ‘ApplicationTraceIndex‘

0 row(s) in 0.3520 seconds

hbase(main):015:0> describe  ‘ApplicationTraceIndex‘

Table ApplicationTraceIndex is ENABLED                                                                                                                              

ApplicationTraceIndex                                                                                                                                              

COLUMN FAMILIES DESCRIPTION                                                                                                                                         

{NAME => ‘I‘, BLOOMFILTER => ‘ROW‘, VERSIONS => ‘1‘, IN_MEMORY => ‘false‘, KEEP_DELETED_CELLS => ‘FALSE‘, DATA_BLOCK_ENCODING => ‘PREFIX‘, TTL => ‘1209600 SECONDS (

14 DAYS)‘, COMPRESSION => ‘NONE‘, MIN_VERSIONS => ‘0‘, BLOCKCACHE => ‘true‘, BLOCKSIZE => ‘65536‘, REPLICATION_SCOPE => ‘0‘}                                       

1 row(s) in 0.0200 seconds

hbase(main):016:0> major_compact  ‘ApplicationTraceIndex‘

0 row(s) in 0.1660 seconds

备注

major_compact的操作目的

合并文件

清除删除、过期、多余版本的数据

提高读写数据的效率

604800 7day

describe ‘TraceV2‘

disable ‘TraceV2‘

alter ‘TraceV2‘ , {NAME=>‘S‘,TTL=>‘604800‘}

enable ‘TraceV2‘

describe ‘TraceV2‘

major_compact ‘TraceV2‘

1209600 14day

describe ‘ApplicationTraceIndex‘

disable ‘ApplicationTraceIndex‘

alter ‘ApplicationTraceIndex‘ , {NAME=>‘I‘,TTL=>‘1209600‘}

enable ‘ApplicationTraceIndex‘

describe ‘ApplicationTraceIndex‘

major_compact ‘ApplicationTraceIndex‘

[[email protected] ~]# du -sh /worker/hbase/data/*

14G /worker/hbase/data/default

348K    /worker/hbase/data/hbase

原文地址：https://www.cnblogs.com/FireLL/p/11612522.html

时间： 2024-10-13 19:29:43

pinpoint 单机HBASE数据量过大问题解决的相关文章

Mysql大数据量问题与解决

今日格言:了解了为什么,问题就解决了一半. Mysql 单表适合的最大数据量是多少? 我们说 Mysql 单表适合存储的最大数据量,自然不是说能够存储的最大数据量,如果是说能够存储的最大量,那么,如果你使用自增 ID,最大就可以存储 2^32 或 2^64 条记录了,这是按自增 ID 的数据类型 int 或 bigint 来计算的:如果你不使用自增 id,且没有 id 最大值的限制,如使用足够长度的随机字符串,那么能够限制单表最大数据量的就只剩磁盘空间了.显然我们不是在讨论这个问题. 影响 My

POI读写大数据量excel，解决超过几万行而导致内存溢出的问题

1. Excel2003与Excel2007 两个版本的最大行数和列数不同,2003版最大行数是65536行,最大列数是256列,2007版及以后的版本最大行数是1048576行,最大列数是16384列. excel2003是以二进制的方式存储,这种格式不易被其他软件读取使用:而excel2007采用了基于XML的ooxml开放文档标准,ooxml使用XML和ZIP技术结合进行文件存储,XML是一个基于文本的格式,而且ZIP容器支持内容的压缩,所以其一大优势是可以大大减小文件的尺寸. 2. 大批

HBase 高性能获取数据 - 多线程批量式解决办法

在前篇博客里已经讲述了通过一个自定义 HBase Filter来获取数据的办法,在末尾指出此办法的性能是不能满足应用要求的,很显然对于如此成熟的HBase来说,高性能获取数据应该不是问题.下面首先简单介绍了搜索引擎的性能,然后详细说明了HBase与MySQL的性能对比,这里的数据都是经过实际的测试获得的.最后,给出了采用多线程批量从HBase中取数据的方案,此方案经过测试要比通过自定义Filter的方式性能高出很多. Solr和HBase专辑 1.“关于Solr的使用总结的心得体会”(http:

mysql通过sqoop导入到hbase中时数据量为1000w时出现Incorrect key file for table '/tmp/#sql_458_0.MYI'; try to repair it

问题:mysql通过sqoop导入到hbase中时数据量为1000w时出现Incorrect key file for table '/tmp/#sql_458_0.MYI'; try to repair it,数据量为100w等时没该问题分析:出现该问题时因为mysql的临时目录(默认为/tmp)太小解决方法:参考:http://blog.sina.com.cn/s/blog_4c197d420101bdn9.html mysql通过sqoop导入到hbase中时数据量为1000w时出现I

解决WCF大数据量传输，System.Net.Sockets.SocketException: 远程主机强迫关闭了一个现有的连接

开发中所用的数据需要通过WCF进行数据传输,结果就遇到了WCF大量传输问题也就是提示System.Net.Sockets.SocketException: 远程主机强迫关闭了一个现有的连接网上解决方案都是千篇一律互相转发的,并且没有明确的解决方案或者按照,各个博客中的解决方案都没能解决这个问题. 为此我整整浪费了一天时间用来解决这个问题,而且用了最笨的办法一点点的尝试网上所查到的方案.对于精研WCF来说的这可能是一个小问题,但是对于仅仅了解wcf,一知半解的会很困惑.将解决方案贴出来希望能帮

数据量大和高并发解决方法

数据量 >10亿 1 .表设计合理(遵循三范式) 既然说到这里,我们简单介绍下三范式: 2.分表技术(垂直分割.水平分割)3.建立索引 4.读写分离 5mysql配置优化(调整最大并发量,定时对数据碎片整理,和数据备份,这里要用到定时器进行数据备份和碎片整理) 3.页面静态化 4.缓存技术(memcached) 第一范式(1NF) (必须有主键,列不可分) 数据库表中的任何字段都是单一属性的,不可再分 create table aa(id int,NameAge varchar(100))

hadoop job解决大数据量关联时数据倾斜的一种办法

转自:http://www.cnblogs.com/xuxm2007/archive/2011/09/01/2161929.html http://www.geminikwok.com/2011/04/02/hadoop-jobè§£å?³å¤§æ?°æ?®é??å?³è??æ—¶æ?°æ?®å?¾æ??ç??ä¸?ç§?å??æ³?/ 数据倾斜是指,map /reduce程序执行时,reduce节点大部分执行完毕,但是有一个或者几个reduce节点运行很慢,导致整个程序的处理时间很长,这是因为

SQLSERVER 文件组解决大数据量数据存储

如何使用文件组解决大数据量的读写性能差问题,具体操作步骤如下: 在企业管理器中,右键点你的数据库,选属性,选数据文件,新增一个,文件填一下,位置填一下,文件组填一个,比如abc---确定. 然后你可以右键点你数据库里面的表,设计表,再点右键,属性,然后把表文件组和文本文件组改成abc,就把你原来的表从原来的大mdf文件中分解到你的新增文件中了. 再增加文件的话,方法同上,目的就是把主文件(MDF)拆分成多个文件:利用文件组的好处是不改变数据库的数据,能把已有的mdf文件拆分成多个最后,一定要使

Sql server 大数据量插入速度慢或丢失数据解决办法

问题描述:我的设备每秒2000条数据插入数据库,2个设备总共4000条,当在程序里面直接用insert语句插入时,两个设备同时插入大概总共能插入约2800条左右,数据丢失约1200条左右,找了好多解决方法,整理了两种效果比较明显的解决办法: 第一种:使用Sql Server函数: 1.将数据组合成字串,使用函数将数据插入内存表,后将内存表数据复制到要插入的表. 2.组合成的字符换格式:'111|222|333|456,7894,7458|0|1|2014-01-01 12:15:16;1111|