Hbase spilt（1）

最新推荐文章于 2024-09-01 21:08:00 发布
最新推荐文章于 2024-09-01 21:08:00 发布
阅读量146 收藏
点赞数
文章标签： 大数据 ui
1、split
当在创建表的时候，Hbase默认的分配一个region，所有的读写请求都会访问同一个regionServer的同一个region中，这个时候就达不到负载均衡的效果了，集群中的其他regionServer就可能会 处于比较空闲的状态。解决这个问题可以用split，在创建table的时候就配置好，生成多个region。

在table初始化的时候如果不配置的话，Hbase是不知道如何去split region的，因为Hbase不知道应该那个row key可以作为split的开始点。如果我们可以大概预测到row key的分布，我们可以使用split来帮助提前split region。不过如果我们预测得不准确的话，还是可能导致某个region过热，被集中访问，不过还好我们还有auto-split。最好的办法就是首先预测split的切分点，然后后面让auto-split来处理后面的负载均衡。

Hbase自带了两种split的算法，分别是HexStringSplit 和UniformSplit 。如果我们的row key是十六进制的字符串作为前缀的，就比较适合用HexStringSplit，作为pre-split的算法。例如，我们使用 HexHash(prefix)作为row key的前缀，其中Hexhash为最终得到十六进制字符串的hash算法。我们也可以用我们自己的split算法。

2、创建spilt表
  1. hbase(main):018:0> create 'mytab','cf1',{SPLITS=>['10','20','30','40','50','60','70','80','90','100']}
  2. 0 row(s) in 1.1810 seconds
3、查看元数据
  1. hbase(main):022:0* scan '.META.'
  2. ROW COLUMN+CELL
  3.  hivetest,,1441805677008.42b9d2fff35c183 column=info:regioninfo, timestamp=1441805677121, value={NAME => 'hivetest,,1441805677008.42b9d2fff35c18393058668f77e
  4.  93058668f77e7b86e. 7b86e.', STARTKEY => '', ENDKEY => '', ENCODED => 42b9d2fff35c18393058668f77e7b86e,}
  5.  hivetest,,1441805677008.42b9d2fff35c183 column=info:server, timestamp=1441810207113, value=slave3:60020
  6.  93058668f77e7b86e.
  7.  hivetest,,1441805677008.42b9d2fff35c183 column=info:serverstartcode, timestamp=1441810207113, value=1441810138459
  8.  93058668f77e7b86e.
  9.  mytab,,1441819038526.7b1b646f3237bf7237 column=info:server, timestamp=1441819040882, value=slave1:60020
  10.  381a454729ee5d.
  11.  mytab,,1441819038526.7b1b646f3237bf7237 column=info:serverstartcode, timestamp=1441819040882, value=1441810262755
  12.  381a454729ee5d.
  13.  mytab,,1441819566171.b640abdb82a91acb98 column=info:regioninfo, timestamp=1441819540261, value={NAME => 'mytab,,1441819566171.b640abdb82a91acb98844d109ad03b
  14.  844d109ad03ba7. a7.', STARTKEY => '', ENDKEY => '10', ENCODED => b640abdb82a91acb98844d109ad03ba7,}
  15.  mytab,,1441819566171.b640abdb82a91acb98 column=info:server, timestamp=1441819568635, value=slave1:60020
  16.  844d109ad03ba7.
  17.  mytab,,1441819566171.b640abdb82a91acb98 column=info:serverstartcode, timestamp=1441819568635, value=1441810262755
  18.  844d109ad03ba7.
  19.  mytab,10,1441819566171.9c6d2a8e69c5aea3 column=info:regioninfo, timestamp=1441819540261, value={NAME => 'mytab,10,1441819566171.9c6d2a8e69c5aea308b79debf82c
  20.  08b79debf82cc910. c910.', STARTKEY => '10', ENDKEY => '100', ENCODED => 9c6d2a8e69c5aea308b79debf82cc910,}
  21.  mytab,10,1441819566171.9c6d2a8e69c5aea3 column=info:server, timestamp=1441819560693, value=slave2:60020
  22.  08b79debf82cc910.
  23.  mytab,10,1441819566171.9c6d2a8e69c5aea3 column=info:serverstartcode, timestamp=1441819560693, value=1441810254954
  24.  08b79debf82cc910.
  25.  mytab,100,1441819566172.accd15db4e78d03 column=info:regioninfo, timestamp=1441819540261, value={NAME => 'mytab,100,1441819566172.accd15db4e78d03c8a53cd6b1e1
  26.  c8a53cd6b1e17f185. 7f185.', STARTKEY => '100', ENDKEY => '20', ENCODED => accd15db4e78d03c8a53cd6b1e17f185,}
  27.  mytab,100,1441819566172.accd15db4e78d03 column=info:server, timestamp=1441819540642, value=slave3:60020
  28.  c8a53cd6b1e17f185.
  29.  mytab,100,1441819566172.accd15db4e78d03 column=info:serverstartcode, timestamp=1441819540642, value=1441810138459
  30.  c8a53cd6b1e17f185.
  31.  mytab,20,1441819566172.f81699b3cefb992f column=info:regioninfo, timestamp=1441819540261, value={NAME => 'mytab,20,1441819566172.f81699b3cefb992fa5c8e5a0fd1f
  32.  a5c8e5a0fd1f133b. 133b.', STARTKEY => '20', ENDKEY => '30', ENCODED => f81699b3cefb992fa5c8e5a0fd1f133b,}
  33.  mytab,20,1441819566172.f81699b3cefb992f column=info:server, timestamp=1441819560897, value=slave2:60020
  34.  a5c8e5a0fd1f133b.
  35.  mytab,20,1441819566172.f81699b3cefb992f column=info:serverstartcode, timestamp=1441819560897, value=1441810254954
  36.  a5c8e5a0fd1f133b.
  37.  mytab,30,1441819566172.97e21ce593d16c77 column=info:regioninfo, timestamp=1441819540261, value={NAME => 'mytab,30,1441819566172.97e21ce593d16c77d35c253c447c
  38.  d35c253c447c176d. 176d.', STARTKEY => '30', ENDKEY => '40', ENCODED => 97e21ce593d16c77d35c253c447c176d,}
  39.  mytab,30,1441819566172.97e21ce593d16c77 column=info:server, timestamp=1441819568737, value=slave1:60020
  40.  d35c253c447c176d.
  41.  mytab,30,1441819566172.97e21ce593d16c77 column=info:serverstartcode, timestamp=1441819568737, value=1441810262755
  42.  d35c253c447c176d.
  43.  mytab,40,1441819566172.c17b2121db16f1f8 column=info:regioninfo, timestamp=1441819540261, value={NAME => 'mytab,40,1441819566172.c17b2121db16f1f8938077016bfc
  44.  938077016bfc524d. 524d.', STARTKEY => '40', ENDKEY => '50', ENCODED => c17b2121db16f1f8938077016bfc524d,}
  45.  mytab,40,1441819566172.c17b2121db16f1f8 column=info:server, timestamp=1441819560776, value=slave2:60020
  46.  938077016bfc524d.
  47.  mytab,40,1441819566172.c17b2121db16f1f8 column=info:serverstartcode, timestamp=1441819560776, value=1441810254954
  48.  938077016bfc524d.
  49.  mytab,50,1441819566172.4c6f25b2a4469ba6 column=info:regioninfo, timestamp=1441819540261, value={NAME => 'mytab,50,1441819566172.4c6f25b2a4469ba63be2a28e9f79
  50.  3be2a28e9f79681d. 681d.', STARTKEY => '50', ENDKEY => '60', ENCODED => 4c6f25b2a4469ba63be2a28e9f79681d,}
  51.  mytab,50,1441819566172.4c6f25b2a4469ba6 column=info:server, timestamp=1441819568670, value=slave1:60020
  52.  3be2a28e9f79681d.
  53.  mytab,50,1441819566172.4c6f25b2a4469ba6 column=info:serverstartcode, timestamp=1441819568670, value=1441810262755
  54.  3be2a28e9f79681d.
  55.  mytab,60,1441819566172.cf803d46bd2fd225 column=info:regioninfo, timestamp=1441819540261, value={NAME => 'mytab,60,1441819566172.cf803d46bd2fd225cce52d2aad18
  56.  cce52d2aad18314a. 314a.', STARTKEY => '60', ENDKEY => '70', ENCODED => cf803d46bd2fd225cce52d2aad18314a,}
  57.  mytab,60,1441819566172.cf803d46bd2fd225 column=info:server, timestamp=1441819540671, value=slave3:60020
  58.  cce52d2aad18314a.
  59.  mytab,60,1441819566172.cf803d46bd2fd225 column=info:serverstartcode, timestamp=1441819540671, value=1441810138459
  60.  cce52d2aad18314a.
  61.  mytab,70,1441819566172.58be7af75c6d124a column=info:regioninfo, timestamp=1441819540261, value={NAME => 'mytab,70,1441819566172.58be7af75c6d124aad1a8385f741
  62.  ad1a8385f7410224. 0224.', STARTKEY => '70', ENDKEY => '80', ENCODED => 58be7af75c6d124aad1a8385f7410224,}
  63.  mytab,70,1441819566172.58be7af75c6d124a column=info:server, timestamp=1441819540765, value=slave3:60020
  64.  ad1a8385f7410224.
  65.  mytab,70,1441819566172.58be7af75c6d124a column=info:serverstartcode, timestamp=1441819540765, value=1441810138459
  66.  ad1a8385f7410224.
  67.  mytab,80,1441819566173.fc2ed8a43e2eaf02 column=info:regioninfo, timestamp=1441819540261, value={NAME => 'mytab,80,1441819566173.fc2ed8a43e2eaf02238d7e1bc398
  68.  238d7e1bc398cc30. cc30.', STARTKEY => '80', ENDKEY => '90', ENCODED => fc2ed8a43e2eaf02238d7e1bc398cc30,}
  69.  mytab,80,1441819566173.fc2ed8a43e2eaf02 column=info:server, timestamp=1441819560794, value=slave2:60020
  70.  238d7e1bc398cc30.
  71.  mytab,80,1441819566173.fc2ed8a43e2eaf02 column=info:serverstartcode, timestamp=1441819560794, value=1441810254954
  72.  238d7e1bc398cc30.
  73.  mytab,90,1441819566173.76ce4f3cde98abd2 column=info:regioninfo, timestamp=1441819540261, value={NAME => 'mytab,90,1441819566173.76ce4f3cde98abd2e7679b099489
  74.  e7679b099489d582. d582.', STARTKEY => '90', ENDKEY => '', ENCODED => 76ce4f3cde98abd2e7679b099489d582,}
  75.  mytab,90,1441819566173.76ce4f3cde98abd2 column=info:server, timestamp=1441819568801, value=slave1:60020
  76.  e7679b099489d582.
  77.  mytab,90,1441819566173.76ce4f3cde98abd2 column=info:serverstartcode, timestamp=1441819568801, value=1441810262755
  78.  e7679b099489d582.
  79.  test,,1441718128275.edca99f7a3a627594f2 column=info:regioninfo, timestamp=1441718128579, value={NAME => 'test,,1441718128275.edca99f7a3a627594f2ab1af7e7cb1a
  80.  ab1af7e7cb1ad. d.', STARTKEY => '', ENDKEY => '', ENCODED => edca99f7a3a627594f2ab1af7e7cb1ad,}
  81.  test,,1441718128275.edca99f7a3a627594f2 column=info:server, timestamp=1441810207198, value=slave3:60020
  82.  ab1af7e7cb1ad.
  83.  test,,1441718128275.edca99f7a3a627594f2 column=info:serverstartcode, timestamp=1441810207198, value=1441810138459
  84.  ab1af7e7cb1ad.
  85. 14 row(s) in 0.3110 seconds
4、使用UI查看表的大致情况

可以看到表mytab有11个在线的region。

这里有起始start key和end key的位置。

插入key/value，以此来分布数据，达到负载的效果。


来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/12219480/viewspace-1797589/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/12219480/viewspace-1797589/

crj2951
关注
  • 0
    点赞
  • 踩
  • 0
    收藏
    觉得还不错? 一键收藏
  • 0
    评论
HBase Split分析
dcswin的博客
08-27 5473
本人结合HBase的源代码，对HBase的Split流程做了整体的分析，并结合实际的操作列出了一些注意的点，望能给对HBase感兴趣的人提供一定的帮助。
Hbase Split 解析
Kuzury
07-04 3803
HBase Split是hbase根据一定的触发条件和一定的分裂策略将HBase的一个region进行分裂成两个子region并对父region进行清除处理的过程。Region是HBase中一个非常核心的组织单元，所有的region组成了整个HBase集群，如下面的HBase的体系结构所示：在HBase中，split其实是进行sharding的一种技术手段，通过HBase的split条件和split
HBase原理 | HBase Split与Compaction
lovelife110的博客
06-07 338
StoreFile Compaction 由于 memstore每次刷写都会生成一个新的 HFile，且同一个字段的不同版本（timestamp）和不同类型（Put/Delete）有可能会分布在不同的 HFile 中，因此查询时需要遍历所有的 HFile。 为了减少 HFile 的个数，以及清理掉过期和删除的数据，会进行 StoreFile Compaction。 Compaction 分为两种，分别是 Minor Compaction 和 Major Compaction。 ...
HBase region split 过程
sysocc的博客
05-19 782
由于写请求是由regionserver处理的，它们会存储在被称作memstore的内存存储系统中。一旦memstore填满，它的内容就会被写到磁盘上，作为额外的存储文件。这个事件被称为memstore的flush。随着存储文件的累积，regionserver将把它们compact成更少，更大的文件。每次flush或compact完成后，该region内存储的数据量就发生了变化。regionserver咨询region split策略，以确定该region是否增长过大，或者是否应该因另一个特定split po
hbase split
数据之美的博客
10-31 1170
hbase split 因为已经进行了预分区，在参数配置时，我们将hbase.hregion.max.filesize调整至了30G(32212254720),但是在测试中发现，还是会在表或者是region不到30G发生了split,日志中可见发生split信息。又碰到一个和major compaction差不多，设置了相应参数却不能唯一控制situation的参数。相关资料整理如下： Hba...
HBase数据的导入和预分区
qq_43502858的博客
07-07 1338
文章目录HBase数据的导入和预分区HBase数据导入1.准备数据2.使用ImportTsv将csv文件直接导入HBase中步骤1：在Hbase中创建一张表ns1:in_table步骤2：将data.csv导入到ns1:in01中步骤3：查看ns1:in01中的数据3.使用Completebulkload导入数据1.将原始的数据文件生成HFile存储在HDFS上2.将生成HFile中的数据导入HB...
【Hbase】知识总结
Aut1sm的博客
03-08 985
Hbase的简介 Hbase的来源 1、数据量越来越大，传统的关系型数据库，不能满足存储和查询功能的需求。而hive虽然能够满足存储的要求，但是hive的本质也是利用底层的mr，所以读写速度不快，而且hive不能满足非结构化，半结构化的存储，hive主要的作用是分析和统计，hive用于存储是毫无意义的。 2、起源于Google在2006发表的一篇论文《bigtable》，是对bigtable的开...
Hbase 相关概念
qzqanzc的博客
12-03 256
HRegionServer HRegionServer 内部管理了一系列的HRegion 对象，每个HRegion对应了 table 中的一个region，HRegion中由多哦个HStore组成，每个HStore对应 了table中的一个column family，可以看出每个columnfamily 其实就是一个集中的 存储单元，因此最好将具备共同IO特性的column放在一个
Hbase基础
修行的博客
07-01 510
大数据第23天-Hbase ​ Hadoop Database，是一个高可靠性、高性能、面向列、可伸缩、实时读写的分布式数据库 ​ 利用Hadoop HDFS作为其文件存储系统,利用Hadoop MapReduce来处理HBase中的海量数据,利用Zookeeper作为其分布式协同服务 ​ 主要用来存储非结构化和半结构化的松散数据 一、HBASE数据模型 Row Key Time ...
hbase split操作
那又怎样？的博客
11-07 4373
转载来自：https://zhuanlan.zhihu.com/p/39648692 HBase - 解析split操作 split操作：意义 HBase数据写入首先会写入缓存，缓存写满会执行一次flush操作，每次flush都会生成一个HFile文件。随着HFile的增多，文件的读取效率势必会降低，HBase采用compact机制不断的对这些文件进行合并，将小文件合并成大文件。然而，对HBa...
Hbase split的过程以及解发条件
weixin_30593261的博客
09-10 202
一、Split触发条件 1、 有任一一个Hfile的大小超过默认值10G时，都会进行split 2、 达到这个值不在拆分，默认为int_max，不进行拆分 3、compaction时，如果compact的store的大小超过了，则进行split 4、flush之前会检测区域中HStoreFile数目是否超过hba...
HBase 1.1.2 split 策略
程序员成长软技能
11-01 1985
背景：今天用ycsb做HBase的性能测试，region大小配置的是10G，单总是在10G前自动split，所以跟着日志查看代码，发现每次flush时候都会调用IncreasingToUpperBoundRegionSplitPolicy类中的shouldSplit方法，方法内容如下：
软考攻略/超详细/系统集成项目管理工程师/基础知识分享06
weixin_46095822的博客
08-29 1124
软考攻略/超详细/系统集成项目管理工程师/基础知识分享06
大数据技术概述
weixin_51591328的博客
08-28 1499
知识点 其他
视频结构化从入门到精通——认识视频结构化
swpucwf的博客
08-28 1840
非结构化数据指的是未经处理、以原始形式存在的数据。这类数据是直接采集、记录的，包含了音频、视频等多维信息，且没有任何标签、注释或分类来表示其中的内容。非结构化数据需要进一步处理和解析，才能提取出有用的信息。定义：计算机（程序）无法直接理解，无法对其进行查询、比对、分类、计算等操作。
窥一斑而知全豹
xuexiaogang的专栏
08-29 1791
由于经济形势的不好，我看参展商少了一点。可能不少都是为了生计而挣扎。2023年1月明叔主持的栏目有一期特别节目《数据库诸神之战》，请来了OB、TiDB、TDSQL和TDEngine的掌门人来讨论数据库的未来，那时候结论是3年后国内健康运营的数据库公司不超过30家。目前已经快过去2年了。现在日子的确越来越难过了。现实可能和预测差不多。
自然语言处理系列五十》文本分类算法》SVM支持向量机算法原理
最新发布
weixin_52610848的博客
09-01 736
【配套新书教材】《自然语言处理原理与实战》（人工智能科学与技术丛书）【陈敬雷编著】【清华大学出版社】新书特色：本书从自然语言处理基础开始，逐步深入各种NLP热点前沿技术，使用了Java和Python两门语言精心编排了大量代码实例，契合公司实际工作场景技能，侧重实战。
hbase l1 l2区别
05-27
1. BlockCache（L1缓存）：BlockCache是HBase的数据块缓存，它缓存了磁盘上的HFile中的数据块，可以大大减少磁盘IO的开销。当用户查询数据时，HBase首先会在BlockCache中查找数据，如果找到了，就直接返回数据；如果...
评论
添加红包

请填写红包祝福语或标题

个

红包个数最小为10个

元

红包金额最低5元

当前余额3.43元 前往充值 >
需支付：10.00元
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明：

1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载，可以购买VIP、付费专栏及课程。

余额充值