hbase 删表过程是怎么样的

hbasePeng 回复了问题 • 3 人关注 • 2 个回复 • 574 次浏览 • 2018-07-18 10:14 • 来自相关话题

HBase import时产生得bug

hbasePeng 回复了问题 • 2 人关注 • 1 个回复 • 511 次浏览 • 2018-07-18 10:11 • 来自相关话题

python读写hbase时,无法传递字节组参数

hbasepseudocodes 回复了问题 • 2 人关注 • 2 个回复 • 654 次浏览 • 2018-07-12 21:58 • 来自相关话题

opentsdb启动出现 RegionClient: Unexpected exception from downstream on ,请问有人碰到过

回复

opentsdb时序lvwenyuan 发起了问题 • 1 人关注 • 0 个回复 • 1244 次浏览 • 2018-07-11 10:40 • 来自相关话题

中国HBase技术社区第二届MeetUp ——HBase技术解析及应用实践

hbasehbasegroup 发表了文章 • 0 个评论 • 384 次浏览 • 2018-07-10 22:53 • 来自相关话题

活动内容
HBase—Hadoop Database是一个分布式的、面向列的开源数据库,该技术来源于 Fay Chang 所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。HBase的特点是高可靠性、高性能、面向列、可伸缩的分布式存储系统,如今HBase已经广泛应用于各互联网行业。那么我们如何熟练掌握HBase技术及应用呢?

2018年7月21号,由中国HBase技术社区、DataFun社区主办、贝壳找房联合主办的中国第二届HBase Meetup继续在北京举行,来自阿里、小米、贝壳找房等公司的各位HBase的PMC、committer共聚一堂,为大家分享HBase技术解析及应用实践。

报名链接:

http://www.huodongxing.com/event/4447209379400

直播链接:

http://www.itdks.com/eventlist/detail/2382

主办方:中国HBase技术社区、DataFun社区

联合主办方:贝壳找房

视频支持:IT大咖说

时间:2018.07.21,13:00-18:00

地点:北京海淀区上地开拓路11号福道大厦

议程安排:

时间

议程安排

13:00-14:00

签到

14:00-14:10

主持人开场

14:10-15:00

 

HBase应用实践

——邓钫元 贝壳找房 资深研发工程师

15:20-16:10

 

Procedure V2介绍

——张铎 小米人工智能与云平台 研发工程师

16:30-17:20

 

HBase in Practise: 性能、监控和问题排查

——李钰 阿里巴巴计算平台事业部高级技术专家

17:20-18:00

自由交流时间

嘉宾介绍:

 

 邓钫元 贝壳找房 资深研发工程师

现就职于贝壳找房,主要负责贝壳大数据基础引擎建设。毕业于浙江大学,曾就职于百度商业平台部-风控平台研发,现负责贝壳找房大数据集群及基础引擎建设,专注于hadoop生态组件,热爱开源,为社区贡献多个patch,有丰富的性能调优经验。

分享主题:HBase应用实践

内容概要:待定

 

张铎 小米人工智能与云平台 研发工程师

 

张铎,HBase PMC member,目前在小米人工智能与云平台负责HBase的研发工作。

分享主题:Procedure V2介绍

内容概要:主要介绍一下Procedure V2的设计和结构,以及为什么用Procedure V2能比较容易实现出正确的AssignmentManager。最后介绍一下最近在2.1分支上对一些Procedure实现修正和改进。

李钰 阿里巴巴计算平台事业部高级技术专家

李钰(社区ID:Yu Li),阿里巴巴计算平台事业部高级技术专家,HBase开源社区PMC&committer。开源技术爱好者,主要关注分布式系统设计、大数据基础平台建设等领域。连续4年基于HBase/HDFS设计和开发存储系统应对双十一访问压力,具备丰富的大规模集群生产实战经验

分享主题:HBase in Practise: 性能、监控和问题排查

内容概要:HBase在不同版本(1.x, 2.x, 3.0)中针对不同类型的硬件(以IO为例,HDD/SATA-SSD/PCIe-SSD/Cloud)和场景(single/batch, get/scan)做了(即将做)各种不同的优化,这些优化都有哪些?如何针对自己的生产业务和硬件环境选择和使用合适的版本/功能?

在生产环境可能出现各种问题,而监控系统是发现并解决问题的关键。目前HBase提供了大量的metrics用于监控,其中有哪些是要特别关注的?线上不同类型的问题应该重点查看哪些metrics来定位问题?如何结合metrics和客户端/服务端日志快速定位问题?
 
大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。
 
长按下面的二维码关注HBase技术社区公众号,同时也欢迎长按下面的二维码关注我的公众号










  查看全部
活动内容
HBase—Hadoop Database是一个分布式的、面向列的开源数据库,该技术来源于 Fay Chang 所撰写的Google论文“Bigtable:一个结构化数据的分布式存储系统”。HBase的特点是高可靠性、高性能、面向列、可伸缩的分布式存储系统,如今HBase已经广泛应用于各互联网行业。那么我们如何熟练掌握HBase技术及应用呢?

2018年7月21号,由中国HBase技术社区、DataFun社区主办、贝壳找房联合主办的中国第二届HBase Meetup继续在北京举行,来自阿里、小米、贝壳找房等公司的各位HBase的PMC、committer共聚一堂,为大家分享HBase技术解析及应用实践。

报名链接:

http://www.huodongxing.com/event/4447209379400

直播链接:

http://www.itdks.com/eventlist/detail/2382

主办方:中国HBase技术社区、DataFun社区

联合主办方:贝壳找房

视频支持:IT大咖说

时间:2018.07.21,13:00-18:00

地点:北京海淀区上地开拓路11号福道大厦

议程安排:

时间

议程安排

13:00-14:00

签到

14:00-14:10

主持人开场

14:10-15:00

 

HBase应用实践

——邓钫元 贝壳找房 资深研发工程师

15:20-16:10

 

Procedure V2介绍

——张铎 小米人工智能与云平台 研发工程师

16:30-17:20

 

HBase in Practise: 性能、监控和问题排查

——李钰 阿里巴巴计算平台事业部高级技术专家

17:20-18:00

自由交流时间

嘉宾介绍:

 

 邓钫元 贝壳找房 资深研发工程师

现就职于贝壳找房,主要负责贝壳大数据基础引擎建设。毕业于浙江大学,曾就职于百度商业平台部-风控平台研发,现负责贝壳找房大数据集群及基础引擎建设,专注于hadoop生态组件,热爱开源,为社区贡献多个patch,有丰富的性能调优经验。

分享主题:HBase应用实践

内容概要:待定

 

张铎 小米人工智能与云平台 研发工程师

 

张铎,HBase PMC member,目前在小米人工智能与云平台负责HBase的研发工作。

分享主题:Procedure V2介绍

内容概要:主要介绍一下Procedure V2的设计和结构,以及为什么用Procedure V2能比较容易实现出正确的AssignmentManager。最后介绍一下最近在2.1分支上对一些Procedure实现修正和改进。

李钰 阿里巴巴计算平台事业部高级技术专家

李钰(社区ID:Yu Li),阿里巴巴计算平台事业部高级技术专家,HBase开源社区PMC&committer。开源技术爱好者,主要关注分布式系统设计、大数据基础平台建设等领域。连续4年基于HBase/HDFS设计和开发存储系统应对双十一访问压力,具备丰富的大规模集群生产实战经验

分享主题:HBase in Practise: 性能、监控和问题排查

内容概要:HBase在不同版本(1.x, 2.x, 3.0)中针对不同类型的硬件(以IO为例,HDD/SATA-SSD/PCIe-SSD/Cloud)和场景(single/batch, get/scan)做了(即将做)各种不同的优化,这些优化都有哪些?如何针对自己的生产业务和硬件环境选择和使用合适的版本/功能?

在生产环境可能出现各种问题,而监控系统是发现并解决问题的关键。目前HBase提供了大量的metrics用于监控,其中有哪些是要特别关注的?线上不同类型的问题应该重点查看哪些metrics来定位问题?如何结合metrics和客户端/服务端日志快速定位问题?
 
大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。
 
长按下面的二维码关注HBase技术社区公众号,同时也欢迎长按下面的二维码关注我的公众号

fc3fd0e97b4258aa48118d5f08f61248.jpg


ad245a8c92214126a27a0c651b3663f3.jpg

 

关于meta表在客户端缓存的问题

hbaseigloo 回复了问题 • 3 人关注 • 1 个回复 • 769 次浏览 • 2018-07-02 14:43 • 来自相关话题

HBase高性能随机查询之道 – HFile原理解析

hbasehbasegroup 发表了文章 • 0 个评论 • 617 次浏览 • 2018-07-02 11:20 • 来自相关话题

在各色数据库系统百花齐放的今天,能让大家铭记的,往往是一个数据库所能带给大家的差异化能力。正如梁宁老师的产品思维课程中所讲到的,这是一个数据库系统所能带给产品使用者的”确定性”。
差异化能力通常需要从数据库底层开始构筑,而数据存储方式显得至关重要,因为它直接关乎数据写入与读取的效率。在一个系统中,这两方面的能力需要进行很好的权衡:如果设计有利于数据的快速写入,可能意味着查询时需要需要花费较大的精力去组织数据,反之,如果写入时花费精力去更好的组织数据,查询就会变的非常轻松。
探讨数据库的数据存储方式,其实就是探讨数据如何在磁盘上进行有效的组织。因为我们通常以如何高效读取和消费数据为目的,而不是数据存储本身。在RDBMS领域,因为键与数据的组织方式的区别,有两种表组织结构最为常见,一种是键与数据联合存储的索引组织表结构,在这种表结构下,查到键值意味着查找到数据;另外一种是键与数据分离存储的堆表结构。在这种表结构下,查找到键以后,只是拿到了数据记录的物理地址,还需要基于该物理地址去查找具体的数据记录。
在大数据分析领域,有几种通用的文件格式,如Parquet, RCFile, ORCFile,CarbonData等等,这些文件大多基于列式的设计结构,来加速通用的分析型查询。但在实时数据库领域,却以各种私有的文件格式最为常见,如Bigtable的SSTable,HBase的HFile,Kudu的DiskRowSets,Cassandra的变种SSTable,MongoDB支持的每一种Storage Engine都是私有的文件格式设计,等等。
本文将详细探讨HBase的HFile设计,第一部分为HFile原理概述,第二部分介绍了一个HFile从无到有的生成过程,最后部分列出了几点与HFile有关的附加信息。
HFile原理概述
最初的HFile格式(HFile V1),参考了Bigtable的SSTable以及Hadoop的TFile(HADOOP-3315)。如下图所示:




HFile在生成之前,数据在内存中已经是按序组织的。存放用户数据的KeyValue,被存储在一个个默认为64kb大小的Data Block中,在Data Index部分存储了每一个Data Block的索引信息{Offset,Size,FirstKey},而Data Index的索引信息{Data Index Offset, Data Block Count}被存储在HFile的Trailer部分。除此以外,在Meta Block部分还存储了Bloom Filter的数据。下图更直观的表达出了HFile V1中的数据组织结构:




这种设计简单、直观。但用过0.90或更老版本的同学,对于这个HFile版本所存在的问题应该深有痛楚:Region Open的时候,需要加载所有的Data Block Index数据,另外,第一次读取时需要加载所有的Bloom Filter数据到内存中。一个HFile中的Bloom Filter的数据大小可达百MB级别,一个RegionServer启动时可能需要加载数GB的Data Block Index数据。这在一个大数据量的集群中,几乎无法忍受。
Data Block Index究竟有多大?
一个Data Block在Data Block Index中的索引信息包含{Offset, Size, FirstKey},BlockOffset使用Long型数字表示,Size使用Int表示即可。假设用户数据RowKey的长度为50bytes,那么,一个64KB的Data Block在Data Block Index中的一条索引数据大小约为62字节。
假设一个RegionServer中有500个Region,每一个Region的数量为10GB(假设这是Data Blocks的总大小),在这个RegionServer上,约有81920000个Data Blocks,此时,Data Block Index所占用的大小为81920000*62bytes,约为4.7GB。
这是HFile V2设计的初衷,HFile V2期望显著降低RegionServer启动时加载HFile的时延,更希望解决一次全量加载数百MB级别的BloomFilter数据带来的时延过大的问题。下图是HFile V2的数据组织结构:




较之HFile V1,我们来看看HFile V2的几点显著变化:
1.分层索引​
无论是Data Block Index还是Bloom Filter,都采用了分层索引的设计。
Data Block的索引,在HFile V2中做多可支持三层索引:最底层的Data Block Index称之为Leaf Index Block,可直接索引到Data Block;中间层称之为Intermediate Index Block,最上层称之为Root Data Index,Root Data index存放在一个称之为”Load-on-open Section“区域,Region Open时会被加载到内存中。基本的索引逻辑为:由Root Data Index索引到Intermediate Block Index,再由Intermediate Block Index索引到Leaf Index Block,最后由Leaf Index Block查找到对应的Data Block。在实际场景中,Intermediate Block Index基本上不会存在,文末部分会通过详细的计算阐述它基本不存在的原因,因此,索引逻辑被简化为:由Root Data Index直接索引到Leaf Index Block,再由Leaf Index Block查找到的对应的Data Block。
2.交叉存放
在”Scanned Block Section“区域,Data Block(存放用户数据KeyValue)、存放Data Block索引的Leaf Index Block(存放Data Block的索引)与Bloom Block(Bloom Filter数据)交叉存在。
3.按需读取
无论是Data Block的索引数据,还是Bloom Filter数据,都被拆成了多个Block,基于这样的设计,无论是索引数据,还是Bloom Filter,都可以按需读取,避免在Region Open阶段或读取阶段一次读入大量的数据,有效降低时延。
从0.98版本开始,社区引入了HFile V3版本,主要是为了支持Tag特性,在HFile V2基础上只做了微量改动。在下文内容中,主要围绕HFile V2的设计展开。
HFile生成流程
在本章节,我们以Flush流程为例,介绍如何一步步生成HFile的流程,来加深大家对于HFile原理的理解。起初,HFile中并没有任何Block,数据还存在于MemStore中。
Flush发生时,创建HFile Writer,第一个空的Data Block出现,初始化后的Data Block中为Header部分预留了空间,Header部分用来存放一个Data Block的元数据信息。
而后,位于MemStore中的KeyValues被一个个append到位于内存中的第一个Data Block中:




注:如果配置了Data Block Encoding,则会在Append KeyValue的时候进行同步编码,编码后的数据不再是单纯的KeyValue模式。Data Block Encoding是HBase为了降低KeyValue结构性膨胀而提供的内部编码机制。上图中所体现出来的KeyValue,只是为了方便大家理解。
当Data Block增长到预设大小(默认64KB)后,一个Data Block被停止写入,该Data Block将经历如下一系列处理流程:
1.如果有配置启用压缩或加密特性,对Data Block的数据按相应的算法进行压缩和加密。




2.在预留的Header区,写入该Data Block的元数据信息,包含{压缩前的大小,压缩后的大小,上一个Block的偏移信息,Checksum元数据信息}等信息,下图是一个Header的完整结构:




3.生成Checksum信息。




4.Data Block以及Checksum信息通过HFile Writer中的输出流写入到HDFS中。
5.为输出的Data Block生成一条索引记录,包含这个Data Block的{起始Key,偏移,大小}信息,这条索引记录被暂时记录到内存的Block Index Chunk中:




注:上图中的firstKey并不一定是这个Data Block的第一个Key,有可能是上一个Data Block的最后一个Key与这一个Data Block的第一个Key之间的一个中间值。具体可参考附录部分的信息。
至此,已经写入了第一个Data Block,并且在Block Index Chunk中记录了关于这个Data Block的一条索引记录。
随着Data Blocks数量的不断增多,Block Index Chunk中的记录数量也在不断变多。当Block Index Chunk达到一定大小以后(默认为128KB),Block Index Chunk也经与Data Block的类似处理流程后输出到HDFS中,形成第一个Leaf Index Block:




此时,已输出的Scanned Block Section部分的构成如下:




正是因为Leaf Index Block与Data Block在Scanned Block Section交叉存在,Leaf Index Block被称之为Inline Block(Bloom Block也属于Inline Block)。在内存中还有一个Root Block Index Chunk用来记录每一个Leaf Index Block的索引信息:




从Root Index到Leaf Data Block再到Data Block的索引关系如下:




我们先假设没有Bloom Filter数据。当MemStore中所有的KeyValues全部写完以后,HFile Writer开始在close方法中处理最后的”收尾”工作:
1.写入最后一个Data Block。
2.写入最后一个Leaf Index Block。
如上属于Scanned Block Section部分的”收尾”工作。
3.如果有MetaData则写入位于Non-Scanned Block Section区域的Meta Blocks,事实上这部分为空。
4.写Root Block Index Chunk部分数据:
如果Root Block Index Chunk超出了预设大小,则输出位于Non-Scanned Block Section区域的Intermediate Index Block数据,以及生成并输出Root Index Block(记录Intermediate Index Block索引)到Load-On-Open Section部分。
如果未超出大小,则直接输出为Load-On-Open Section部分的Root Index Block。
5.写入用来索引Meta Blocks的Meta Index数据(事实上这部分只是写入一个空的Block)。
6.写入FileInfo信息,FileInfo中包含:
Max SequenceID, MajorCompaction标记,TimeRanage信息,最早的Timestamp, Data BlockEncoding类型,BloomFilter配置,最大的Timestamp,KeyValue版本,最后一个RowKey,平均的Key长度,平均Value长度,Key比较器等。
7.写入Bloom Filter元数据与索引数据。
注:前面每一部分信息的写入,都以Block形式写入,都包含Header与Data两部分,Header中的结构也是相同的,只是都有不同的Block Type,在Data部分,每一种类型的Block可以有自己的定义。
8.写入Trailer部分信息, Trailer中包含:
Root Index Block的Offset,FileInfo部分Offset,Data Block Index的层级,Data Block Index数据总大小,第一个Data Block的Offset,最后一个Data Block的Offset,Comparator信息,Root Index Block的Entries数量,加密算法类型,Meta Index Block的Entries数量,整个HFile文件未压缩大小,整个HFile中所包含的KeyValue总个数,压缩算法类型等。
至此,一个完整的HFile已生成。我们可以通过下图再简单回顾一下Root Index Block、Leaf Index Block、Data Block所处的位置以及索引关系:




简单起见,上文中刻意忽略了Bloom Filter部分。Bloom Filter被用来快速判断一条记录是否在一个大的集合中存在,采用了多个Hash函数+位图的设计。写入数据时,一个记录经X个Hash函数运算后,被映射到位图中的X个位置,将位图中的这X个位置写为1。判断一条记录是否存在时,也是通过这个X个Hash函数计算后,获得X个位置,如果位图中的这X个位置都为1,则表明该记录”可能存在”,但如果至少有一个为0,则该记录”一定不存在”。详细信息,大家可以直接参考Wiki,这里不做过多展开。
Bloom Filter包含Bloom元数据(Hash函数类型,Hash函数个数等)与位图数据(BloomData),为了避免每一次读取时加载所有的Bloom Data,HFile V2中将BloomData部分分成了多个小的Bloom Block。BloomData数据也被当成一类Inline Block,与Data Block、Leaf Index Block交叉存在,而关于Bloom Filter的元数据与多个Bloom Block的索引信息,被存放在Load-On-Open Section部分。但需要注意的是,在FileInfo部分,保存了关于BloomFilter配置类型信息,共包含三种类型:不启用,基于Row构建BloomFilter,基于Row+Column构建Bloom Filter。混合了BloomFilter Block以后的HFile构成如下图所示:




附录1 多大的HFile文件才存在Intermiate Index Block
每一个Leaf Index Block大小的计算方法如下(HFileBlockIndex$BlockIndexChunk#getNonRootSize):/**
* @return the size of this chunk if stored in the non-root
* index block format
*/
int getNonRootSize() {
// Number of entries
// Secondary index
// All entries
return Bytes.SIZEOF_INT
+ Bytes.SIZEOF_INT * (blockKeys.size() + 1)
+ curTotalNonRootEntrySize;
}curTotalNonRootEntrySize是在每次写入一个新的Entry的时候累加的:static final int SECONDARY_INDEX_ENTRY_OVERHEAD =
Bytes.SIZEOF_INT + Bytes.SIZEOF_LONG;

void add(byte firstKey, long blockOffset, int onDiskDataSize,
long curTotalNumSubEntries) {
// Record the offset for the secondary index
secondaryIndexOffsetMarks.add(curTotalNonRootEntrySize);
curTotalNonRootEntrySize
+= SECONDARY_INDEX_ENTRY_OVERHEAD
+ firstKey.length;
// ....(略去非相关代码)...
}这样子,可以看出来,每一次新增一个Entry,则累计的值为:
​ 12 + firstKey.length
假设一个Leaf Index Block可以容纳的Data Block的数量为x:
​ 4 + 4 * (x + 1) + x * (12 + firstKey.length)
进一步假设,firstKey.length为50bytes。而一个Leaf Index Block的默认最大大小为128KB:
​ 4 + 4 * (x + 1) + x * (12 + 50) = 128 * 1024
​ x ≈1986
也就是说,在假设firstKey.length为50Bytes时,一个128KB的Leaf Index Block所能容纳的Data Block数量约为1986个。
我们再来看看Root Index Chunk大小的计算方法:/**
* @return the size of this chunk if stored in the root index block format
*/
int getRootSize() {
return curTotalRootSize;
}

void add(byte firstKey, long blockOffset, int onDiskDataSize,
long curTotalNumSubEntries) {
// ......
curTotalRootSize += Bytes.SIZEOF_LONG + Bytes.SIZEOF_INT
+ WritableUtils.getVIntSize(firstKey.length) + firstKey.length;
// ......
}基于firstKey为50 Bytes的假设,每往Root Index Chunk中新增一个Entry(关联一个Leaf Index Block),那么,curTotalRootSize的累加值为:
​ 12 + 1 + 50 = 63
因此,一个128KB的Root Index Chunk可以至少存储2080个Entries,即可存储2080个Leaf Index Block。
这样, 一个Root Index Chunk所关联的Data Blocks的总量应该为:
​ 1986 * 2080 = 4,130,880
而每一个Data Block默认大小为64KB,那么,这个HFile的总大小至少为:
​ 4,130,880 * 64 * 1024 ≈ 252 GB
即,基于每一个Block中的FirstKey为50bytes的假设,一个128KB的Root Index Block可容纳的HFile文件总大小约为252GB。
如果实际的RowKey小于50 Bytes,或者将Data Block的Size调大,一个128KB的Root Index Chunk所关联的HFile文件将会更大。因此,在大多数场景中,Intermediate Index Block并不会存在。
附录2 关于HFile数据查看工具
HBase中提供了一个名为HFilePrettyPrinter的工具,可以以一种直观的方式查看HFile中的数据,关于该工具的帮助信息,可通过如下命令查看:
hbase org.apache.hadoop.hbase.io.hfile.HFile
References
HBase Architecture 101 – Storage
HBASE-3857: Change the HFile Format
HBase Document: Appendix H: HFile format
HADOOP-3315: New Binary file format
SSTable and Log Structured Storage: LevelDB
 
转载自毕杰山“HBase高性能随机查询之道 – HFile原理解析” 查看全部
在各色数据库系统百花齐放的今天,能让大家铭记的,往往是一个数据库所能带给大家的差异化能力。正如梁宁老师的产品思维课程中所讲到的,这是一个数据库系统所能带给产品使用者的”确定性”。
差异化能力通常需要从数据库底层开始构筑,而数据存储方式显得至关重要,因为它直接关乎数据写入与读取的效率。在一个系统中,这两方面的能力需要进行很好的权衡:如果设计有利于数据的快速写入,可能意味着查询时需要需要花费较大的精力去组织数据,反之,如果写入时花费精力去更好的组织数据,查询就会变的非常轻松。
探讨数据库的数据存储方式,其实就是探讨数据如何在磁盘上进行有效的组织。因为我们通常以如何高效读取和消费数据为目的,而不是数据存储本身。在RDBMS领域,因为键与数据的组织方式的区别,有两种表组织结构最为常见,一种是键与数据联合存储的索引组织表结构,在这种表结构下,查到键值意味着查找到数据;另外一种是键与数据分离存储的堆表结构。在这种表结构下,查找到键以后,只是拿到了数据记录的物理地址,还需要基于该物理地址去查找具体的数据记录。
在大数据分析领域,有几种通用的文件格式,如Parquet, RCFile, ORCFile,CarbonData等等,这些文件大多基于列式的设计结构,来加速通用的分析型查询。但在实时数据库领域,却以各种私有的文件格式最为常见,如Bigtable的SSTable,HBase的HFile,Kudu的DiskRowSets,Cassandra的变种SSTable,MongoDB支持的每一种Storage Engine都是私有的文件格式设计,等等。
本文将详细探讨HBase的HFile设计,第一部分为HFile原理概述,第二部分介绍了一个HFile从无到有的生成过程,最后部分列出了几点与HFile有关的附加信息。
HFile原理概述
最初的HFile格式(HFile V1),参考了Bigtable的SSTable以及Hadoop的TFile(HADOOP-3315)。如下图所示:
HFile-V1.jpg

HFile在生成之前,数据在内存中已经是按序组织的。存放用户数据的KeyValue,被存储在一个个默认为64kb大小的Data Block中,在Data Index部分存储了每一个Data Block的索引信息{Offset,Size,FirstKey},而Data Index的索引信息{Data Index Offset, Data Block Count}被存储在HFile的Trailer部分。除此以外,在Meta Block部分还存储了Bloom Filter的数据。下图更直观的表达出了HFile V1中的数据组织结构:
HFileV1-Index.png

这种设计简单、直观。但用过0.90或更老版本的同学,对于这个HFile版本所存在的问题应该深有痛楚:Region Open的时候,需要加载所有的Data Block Index数据,另外,第一次读取时需要加载所有的Bloom Filter数据到内存中。一个HFile中的Bloom Filter的数据大小可达百MB级别,一个RegionServer启动时可能需要加载数GB的Data Block Index数据。这在一个大数据量的集群中,几乎无法忍受。
Data Block Index究竟有多大?
一个Data Block在Data Block Index中的索引信息包含{Offset, Size, FirstKey},BlockOffset使用Long型数字表示,Size使用Int表示即可。假设用户数据RowKey的长度为50bytes,那么,一个64KB的Data Block在Data Block Index中的一条索引数据大小约为62字节。
假设一个RegionServer中有500个Region,每一个Region的数量为10GB(假设这是Data Blocks的总大小),在这个RegionServer上,约有81920000个Data Blocks,此时,Data Block Index所占用的大小为81920000*62bytes,约为4.7GB。

这是HFile V2设计的初衷,HFile V2期望显著降低RegionServer启动时加载HFile的时延,更希望解决一次全量加载数百MB级别的BloomFilter数据带来的时延过大的问题。下图是HFile V2的数据组织结构:
HFileV2.png

较之HFile V1,我们来看看HFile V2的几点显著变化:
1.分层索引​
无论是Data Block Index还是Bloom Filter,都采用了分层索引的设计。
Data Block的索引,在HFile V2中做多可支持三层索引:最底层的Data Block Index称之为Leaf Index Block,可直接索引到Data Block;中间层称之为Intermediate Index Block,最上层称之为Root Data Index,Root Data index存放在一个称之为”Load-on-open Section“区域,Region Open时会被加载到内存中。基本的索引逻辑为:由Root Data Index索引到Intermediate Block Index,再由Intermediate Block Index索引到Leaf Index Block,最后由Leaf Index Block查找到对应的Data Block。在实际场景中,Intermediate Block Index基本上不会存在,文末部分会通过详细的计算阐述它基本不存在的原因,因此,索引逻辑被简化为:由Root Data Index直接索引到Leaf Index Block,再由Leaf Index Block查找到的对应的Data Block。
2.交叉存放
在”Scanned Block Section“区域,Data Block(存放用户数据KeyValue)、存放Data Block索引的Leaf Index Block(存放Data Block的索引)与Bloom Block(Bloom Filter数据)交叉存在。
3.按需读取
无论是Data Block的索引数据,还是Bloom Filter数据,都被拆成了多个Block,基于这样的设计,无论是索引数据,还是Bloom Filter,都可以按需读取,避免在Region Open阶段或读取阶段一次读入大量的数据,有效降低时延。
从0.98版本开始,社区引入了HFile V3版本,主要是为了支持Tag特性,在HFile V2基础上只做了微量改动。在下文内容中,主要围绕HFile V2的设计展开。
HFile生成流程
在本章节,我们以Flush流程为例,介绍如何一步步生成HFile的流程,来加深大家对于HFile原理的理解。起初,HFile中并没有任何Block,数据还存在于MemStore中。
Flush发生时,创建HFile Writer,第一个空的Data Block出现,初始化后的Data Block中为Header部分预留了空间,Header部分用来存放一个Data Block的元数据信息。
而后,位于MemStore中的KeyValues被一个个append到位于内存中的第一个Data Block中:
1.HFileBlock-A_.png

:如果配置了Data Block Encoding,则会在Append KeyValue的时候进行同步编码,编码后的数据不再是单纯的KeyValue模式。Data Block Encoding是HBase为了降低KeyValue结构性膨胀而提供的内部编码机制。上图中所体现出来的KeyValue,只是为了方便大家理解。
当Data Block增长到预设大小(默认64KB)后,一个Data Block被停止写入,该Data Block将经历如下一系列处理流程:
1.如果有配置启用压缩或加密特性,对Data Block的数据按相应的算法进行压缩和加密。
1.HFileBlock-B_.png

2.在预留的Header区,写入该Data Block的元数据信息,包含{压缩前的大小,压缩后的大小,上一个Block的偏移信息,Checksum元数据信息}等信息,下图是一个Header的完整结构:
HFileBlockHeader.png

3.生成Checksum信息。
1.HFileBlock-C_.png

4.Data Block以及Checksum信息通过HFile Writer中的输出流写入到HDFS中。
5.为输出的Data Block生成一条索引记录,包含这个Data Block的{起始Key,偏移,大小}信息,这条索引记录被暂时记录到内存的Block Index Chunk中:
1.HFileBlock-D-AddIndexEntry_.png

:上图中的firstKey并不一定是这个Data Block的第一个Key,有可能是上一个Data Block的最后一个Key与这一个Data Block的第一个Key之间的一个中间值。具体可参考附录部分的信息。
至此,已经写入了第一个Data Block,并且在Block Index Chunk中记录了关于这个Data Block的一条索引记录。
随着Data Blocks数量的不断增多,Block Index Chunk中的记录数量也在不断变多。当Block Index Chunk达到一定大小以后(默认为128KB),Block Index Chunk也经与Data Block的类似处理流程后输出到HDFS中,形成第一个Leaf Index Block
2.BlockIndexChunk-A_.png

此时,已输出的Scanned Block Section部分的构成如下:
2.BlockIndexChunk-B_.png

正是因为Leaf Index Block与Data Block在Scanned Block Section交叉存在,Leaf Index Block被称之为Inline Block(Bloom Block也属于Inline Block)。在内存中还有一个Root Block Index Chunk用来记录每一个Leaf Index Block的索引信息
2.BlockIndexChunk-C_.png

从Root Index到Leaf Data Block再到Data Block的索引关系如下:
3.RootBlockIndex-A_.png

我们先假设没有Bloom Filter数据。当MemStore中所有的KeyValues全部写完以后,HFile Writer开始在close方法中处理最后的”收尾”工作:
1.写入最后一个Data Block。
2.写入最后一个Leaf Index Block。
如上属于Scanned Block Section部分的”收尾”工作。
3.如果有MetaData则写入位于Non-Scanned Block Section区域的Meta Blocks,事实上这部分为空。
4.写Root Block Index Chunk部分数据:
如果Root Block Index Chunk超出了预设大小,则输出位于Non-Scanned Block Section区域的Intermediate Index Block数据,以及生成并输出Root Index Block(记录Intermediate Index Block索引)到Load-On-Open Section部分。
如果未超出大小,则直接输出为Load-On-Open Section部分的Root Index Block。
5.写入用来索引Meta Blocks的Meta Index数据(事实上这部分只是写入一个空的Block)。
6.写入FileInfo信息,FileInfo中包含:
Max SequenceID, MajorCompaction标记,TimeRanage信息,最早的Timestamp, Data BlockEncoding类型,BloomFilter配置,最大的Timestamp,KeyValue版本,最后一个RowKey,平均的Key长度,平均Value长度,Key比较器等。
7.写入Bloom Filter元数据与索引数据。
:前面每一部分信息的写入,都以Block形式写入,都包含Header与Data两部分,Header中的结构也是相同的,只是都有不同的Block Type,在Data部分,每一种类型的Block可以有自己的定义。
8.写入Trailer部分信息, Trailer中包含:
Root Index Block的Offset,FileInfo部分Offset,Data Block Index的层级,Data Block Index数据总大小,第一个Data Block的Offset,最后一个Data Block的Offset,Comparator信息,Root Index Block的Entries数量,加密算法类型,Meta Index Block的Entries数量,整个HFile文件未压缩大小,整个HFile中所包含的KeyValue总个数,压缩算法类型等。
至此,一个完整的HFile已生成。我们可以通过下图再简单回顾一下Root Index Block、Leaf Index Block、Data Block所处的位置以及索引关系:
3.RootBlockIndex-B_.png

简单起见,上文中刻意忽略了Bloom Filter部分。Bloom Filter被用来快速判断一条记录是否在一个大的集合中存在,采用了多个Hash函数+位图的设计。写入数据时,一个记录经X个Hash函数运算后,被映射到位图中的X个位置,将位图中的这X个位置写为1。判断一条记录是否存在时,也是通过这个X个Hash函数计算后,获得X个位置,如果位图中的这X个位置都为1,则表明该记录”可能存在”,但如果至少有一个为0,则该记录”一定不存在”。详细信息,大家可以直接参考Wiki,这里不做过多展开。
Bloom Filter包含Bloom元数据(Hash函数类型,Hash函数个数等)位图数据(BloomData),为了避免每一次读取时加载所有的Bloom Data,HFile V2中将BloomData部分分成了多个小的Bloom Block。BloomData数据也被当成一类Inline Block,与Data Block、Leaf Index Block交叉存在,而关于Bloom Filter的元数据与多个Bloom Block的索引信息,被存放在Load-On-Open Section部分。但需要注意的是,在FileInfo部分,保存了关于BloomFilter配置类型信息,共包含三种类型:不启用,基于Row构建BloomFilter,基于Row+Column构建Bloom Filter。混合了BloomFilter Block以后的HFile构成如下图所示:
4.BloomFilter_.png

附录1 多大的HFile文件才存在Intermiate Index Block
每一个Leaf Index Block大小的计算方法如下(HFileBlockIndex$BlockIndexChunk#getNonRootSize):
/**
* @return the size of this chunk if stored in the non-root
* index block format
*/
int getNonRootSize() {
// Number of entries
// Secondary index
// All entries
return Bytes.SIZEOF_INT
+ Bytes.SIZEOF_INT * (blockKeys.size() + 1)
+ curTotalNonRootEntrySize;
}
curTotalNonRootEntrySize是在每次写入一个新的Entry的时候累加的:
static final int SECONDARY_INDEX_ENTRY_OVERHEAD = 
Bytes.SIZEOF_INT + Bytes.SIZEOF_LONG;

void add(byte firstKey, long blockOffset, int onDiskDataSize,
long curTotalNumSubEntries) {
// Record the offset for the secondary index
secondaryIndexOffsetMarks.add(curTotalNonRootEntrySize);
curTotalNonRootEntrySize
+= SECONDARY_INDEX_ENTRY_OVERHEAD
+ firstKey.length;
// ....(略去非相关代码)...
}
这样子,可以看出来,每一次新增一个Entry,则累计的值为:
​ 12 + firstKey.length
假设一个Leaf Index Block可以容纳的Data Block的数量为x:
​ 4 + 4 * (x + 1) + x * (12 + firstKey.length)
进一步假设,firstKey.length为50bytes。而一个Leaf Index Block的默认最大大小为128KB:
​ 4 + 4 * (x + 1) + x * (12 + 50) = 128 * 1024
​ x ≈1986
也就是说,在假设firstKey.length为50Bytes时,一个128KB的Leaf Index Block所能容纳的Data Block数量约为1986个。
我们再来看看Root Index Chunk大小的计算方法:
/**
* @return the size of this chunk if stored in the root index block format
*/
int getRootSize() {
return curTotalRootSize;
}

void add(byte firstKey, long blockOffset, int onDiskDataSize,
long curTotalNumSubEntries) {
// ......
curTotalRootSize += Bytes.SIZEOF_LONG + Bytes.SIZEOF_INT
+ WritableUtils.getVIntSize(firstKey.length) + firstKey.length;
// ......
}
基于firstKey为50 Bytes的假设,每往Root Index Chunk中新增一个Entry(关联一个Leaf Index Block),那么,curTotalRootSize的累加值为:
​ 12 + 1 + 50 = 63
因此,一个128KB的Root Index Chunk可以至少存储2080个Entries,即可存储2080个Leaf Index Block。
这样, 一个Root Index Chunk所关联的Data Blocks的总量应该为:
​ 1986 * 2080 = 4,130,880
而每一个Data Block默认大小为64KB,那么,这个HFile的总大小至少为:
​ 4,130,880 * 64 * 1024 ≈ 252 GB
即,基于每一个Block中的FirstKey为50bytes的假设,一个128KB的Root Index Block可容纳的HFile文件总大小约为252GB。
如果实际的RowKey小于50 Bytes,或者将Data Block的Size调大,一个128KB的Root Index Chunk所关联的HFile文件将会更大。因此,在大多数场景中,Intermediate Index Block并不会存在。
附录2 关于HFile数据查看工具
HBase中提供了一个名为HFilePrettyPrinter的工具,可以以一种直观的方式查看HFile中的数据,关于该工具的帮助信息,可通过如下命令查看:
hbase org.apache.hadoop.hbase.io.hfile.HFile
References
HBase Architecture 101 – Storage
HBASE-3857: Change the HFile Format
HBase Document: Appendix H: HFile format
HADOOP-3315: New Binary file format
SSTable and Log Structured Storage: LevelDB
 
转载自毕杰山“HBase高性能随机查询之道 – HFile原理解析”

Hbase日志存储——以便利店和无人超市业务为例

hbasehbasegroup 发表了文章 • 0 个评论 • 792 次浏览 • 2018-07-01 21:55 • 来自相关话题

随着去年,马云提出新零售、刘强东提出无界零售等,线上电子商务公司认为线上流量红利已经殆尽,开始纷纷正式转型进入线下。阿里采取入股高鑫零售,腾讯京东联手入股永辉超市以及步步高等,正式开启线下零售大战。

在此背景下,公司正式开启便利店以及无人超市业务,与此同时参与到该项目当中。主要负责人脸进出门业务,对人脸数据进行存储与管理。由于hbase在大量数据写入的时候有很大的优势,因此考虑使用hbase;除此之外,hbase存储的数据可以接入phoenix,来实现数据的分析,因此本案例主要介绍公司便利店以及无人超市等人脸日志存储。






根据上述门店业务,首先需要考虑的是每次一个人刷脸,算法进行人脸识别的时候是多线程多任务进行识别以达到尽快地识别出来,因此会有很多次识别结果,只要其中一次识别结果成功则定义为成功,即可开门。

在此业务场景下,可以想到每个人的一次进门,会有数十条识别数据;当用户量达到一定程度的时候,因此数据量是非常庞大的。而且非常符合hbase的高写入场景,所以非常适合选择hbase作为存储,同时hbase最终存储的结果也可以导出,做分析。

下面主要列举了三点在无人超市和便利店场景下的hbase使用中的关键点。

1.关键点一:hbase的rowkey设计

idx_$num_$Uuid,其中$num=99999999999L-当前时间,$Uuid是随机生成uuid:这样设计的目地是为了能够保证最新的数据是呈现在最上面的。

2.关键点二:hbase的相关表设计

(1)设计基本的人脸采集日志表、识别日志表,用来存储所有的人脸采集日志信息、识别日志信息

(2)设计若干索引表(时间维度、业务维度、用户维度等等),索引表只存储主表的rowkey:这样做的目地是为了在查询的时候先去查询相关索引表,然后再根据索引表获取到的rowkey来获取主表信息,解决hbase不像关系型数据库一样,能够提供表之间的关联上的痛点。

3.关键点三:hbase数据分析

(1)可以将hbase中的数据同步接入phoenix来做分析以及报表处理,供运营决策。

(2)在报表方面可以考虑接入phoenix之后导入到关系型数据库中再接入tableu做报表输出。

(3)除此之外hbase数据在做分析的时候还需要结合hive来对数据进行清洗:因为每一个用户每次进门都有多次识别结果,应该选择当前最近时间段内的最后一条成功的识别结果作为该用户的进门数据,需要使用上hive开窗函数进行聚合处理。

大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。
 
长按下面的二维码关注HBase技术社区公众号,同时也欢迎长按下面的二维码关注我的公众号










  查看全部
随着去年,马云提出新零售、刘强东提出无界零售等,线上电子商务公司认为线上流量红利已经殆尽,开始纷纷正式转型进入线下。阿里采取入股高鑫零售,腾讯京东联手入股永辉超市以及步步高等,正式开启线下零售大战。

在此背景下,公司正式开启便利店以及无人超市业务,与此同时参与到该项目当中。主要负责人脸进出门业务,对人脸数据进行存储与管理。由于hbase在大量数据写入的时候有很大的优势,因此考虑使用hbase;除此之外,hbase存储的数据可以接入phoenix,来实现数据的分析,因此本案例主要介绍公司便利店以及无人超市等人脸日志存储。

微信图片_20180701213858.png


根据上述门店业务,首先需要考虑的是每次一个人刷脸,算法进行人脸识别的时候是多线程多任务进行识别以达到尽快地识别出来,因此会有很多次识别结果,只要其中一次识别结果成功则定义为成功,即可开门。

在此业务场景下,可以想到每个人的一次进门,会有数十条识别数据;当用户量达到一定程度的时候,因此数据量是非常庞大的。而且非常符合hbase的高写入场景,所以非常适合选择hbase作为存储,同时hbase最终存储的结果也可以导出,做分析。

下面主要列举了三点在无人超市和便利店场景下的hbase使用中的关键点。

1.关键点一:hbase的rowkey设计

idx_$num_$Uuid,其中$num=99999999999L-当前时间,$Uuid是随机生成uuid:这样设计的目地是为了能够保证最新的数据是呈现在最上面的。

2.关键点二:hbase的相关表设计

(1)设计基本的人脸采集日志表、识别日志表,用来存储所有的人脸采集日志信息、识别日志信息

(2)设计若干索引表(时间维度、业务维度、用户维度等等),索引表只存储主表的rowkey:这样做的目地是为了在查询的时候先去查询相关索引表,然后再根据索引表获取到的rowkey来获取主表信息,解决hbase不像关系型数据库一样,能够提供表之间的关联上的痛点。

3.关键点三:hbase数据分析

(1)可以将hbase中的数据同步接入phoenix来做分析以及报表处理,供运营决策。

(2)在报表方面可以考虑接入phoenix之后导入到关系型数据库中再接入tableu做报表输出。

(3)除此之外hbase数据在做分析的时候还需要结合hive来对数据进行清洗:因为每一个用户每次进门都有多次识别结果,应该选择当前最近时间段内的最后一条成功的识别结果作为该用户的进门数据,需要使用上hive开窗函数进行聚合处理。

大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。
 
长按下面的二维码关注HBase技术社区公众号,同时也欢迎长按下面的二维码关注我的公众号

微信图片_20180623105555.jpg


qrcode_for_gh_e12b18786730_258_(3).jpg

 

hbase可以存图片吗?

hbasebeyond 回复了问题 • 2 人关注 • 2 个回复 • 3018 次浏览 • 2018-06-27 19:18 • 来自相关话题

HBase表热点

hbasebeyond 回复了问题 • 5 人关注 • 4 个回复 • 795 次浏览 • 2018-06-27 17:55 • 来自相关话题

Hbase 分区能删除吗?如何删呢?

hbasebeyond 回复了问题 • 3 人关注 • 2 个回复 • 437 次浏览 • 2018-06-27 17:31 • 来自相关话题

phoenix 建不上本地索引

Phoenixhbase 回复了问题 • 3 人关注 • 3 个回复 • 754 次浏览 • 2018-06-27 14:22 • 来自相关话题

中国HBase技术社区简介

hbasehbasegroup 发表了文章 • 1 个评论 • 304 次浏览 • 2018-06-25 15:01 • 来自相关话题

  为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,由阿里巴巴、小米、华为、网易、京东、滴滴、知乎等公司的HBase技术研究人员共同发起了组建:中国HBase技术社区(Chinese HBase Technical Community 简称CHTC)。
  且在2018年6月6号,由阿里云主办的中国第一次HBase Meetup在北京望京阿里中心举行,来自阿里、小米、滴滴、360等公司的各位HBase的PMC、committer共聚一堂,共同探讨HBase2.0的技术革新以及HBase在国内各个大型企业内的应用价值,并一起见证HBase技术社区成立仪式的历史时刻。
  中国HBase技术社区,我们非常欢迎对HBase有技术激情的同学一起加入探讨HBase技术,同时诚邀广大HBase技术爱好者加入。大家在工作学习遇到HBase技术问题,可以把问题发布到中国HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术,关注HBase技术社区公众号(微信号:hbasegroup),邀请进社区的讨论群。 查看全部
  为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,由阿里巴巴、小米、华为、网易、京东、滴滴、知乎等公司的HBase技术研究人员共同发起了组建:中国HBase技术社区(Chinese HBase Technical Community 简称CHTC)。
  且在2018年6月6号,由阿里云主办的中国第一次HBase Meetup在北京望京阿里中心举行,来自阿里、小米、滴滴、360等公司的各位HBase的PMC、committer共聚一堂,共同探讨HBase2.0的技术革新以及HBase在国内各个大型企业内的应用价值,并一起见证HBase技术社区成立仪式的历史时刻。
  中国HBase技术社区,我们非常欢迎对HBase有技术激情的同学一起加入探讨HBase技术,同时诚邀广大HBase技术爱好者加入。大家在工作学习遇到HBase技术问题,可以把问题发布到中国HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术,关注HBase技术社区公众号(微信号:hbasegroup),邀请进社区的讨论群。

我们为什么需要HBase?

hbasehbasegroup 发表了文章 • 0 个评论 • 576 次浏览 • 2018-06-23 10:58 • 来自相关话题

我们肯定听说过HBase,但是对于HBase的了解可能仅仅是它是Hadoop生态圈重要的一员,它是大数据技术圈一个很强的开源项目。然后内心os:它很屌,但是我用mysql/oracle。

一门技术的兴起,一个优秀的开源项目的存在肯定是有它所存在的意义,正如大数据一样,正是因为随着时间的发展,随着技术的发展导致我们每天的数据增量达到一个非常庞大的状态,同时在数据之中又能挖掘到很多有用的信息。所以才有了大数据技术的飞速发展。那么,我们为什么需要HBase,什么时候需要HBase呢?

HBase是什么?

HBase(Hadoop
Database) 是一个高可靠性,高性能,可伸缩,面向列的分布式数据库(也许叫做存储系统会更加贴切)。

就跟Hadoop本身也是起源与Google发布的GFS和MapReduce相关的论文一样,HBase是Google BigTable的开源实现。它整体的架构与BigTable很类似。例如:Google BigTableHBase利用GFS作为文件存储系统利用HDFS作为文件存储系统运行MapReduce处理存储的海量数据同样利用Hadoop MapReduce处理海量数据利用Chubby作为协同服务利用Zookeeper作为协同服务

HBase与Hadoop的关系非常紧密,Hadoop的HDFS提供了高可靠性的底层存储支持,Hadoop MapReduce为HBase提供了高性能的计算能力,Zookeeper为HBase提供了稳定性及failover机制的保障。同时其他周边产品诸如Hive可以与HBase相结合使在HBase进行数据统计处理变得简单,Sqoop为HBase提供了方便的RDBMS数据导入功能,使传统数据库的数据向HBase中迁移变得容易,Spark等高性能的内存分布式计算引擎也可能帮助我们更加快速的对HBase中的数据进行处理分析。

大数据的水很深,但是范围适中。初学者都是扎根于Hadoop的生态圈,HBase是必学技能之一

为什么选择HBase?而不是Mysql或者Oracle

当我们开始学习一门技术的时候总是习惯于将它们与已有的技术进行对比。当我们刚接触python的时候会发现它的简洁与效率,当我们刚接触php的时候也会探寻为啥它是最好的语言没有之一。。。

那么HBase经常会和常见的关系型数据库进行对比:

HBase  Mysql or Oracle列式,Nosql数据库行式,关系型数据库只支持byte类型支持多种数据类型支持海量数据存储支持大量数据存储只支持基于rowkey的索引支持每秒百万查询吞吐量每秒数千查询吞吐量事务只支持到row级别完整的事务适合时间序列或者随机查询适合复杂查询,多表关联等数据维护形式单一,更新支持多个版本存在数据增删改查非常方便,直接修改原有数据

其实两者的对比毫无意义,因为两者适用于不同的场景

HBase作为一个NoSQL,不支持完整的事务性,而且仅仅支持基于RowKey的索引,在性能上不如memcached和redis。但是在海量数据,持久化存储方便比内存类型的NoSQL强的多,作为文档型NoSQL在分布式存储上比mongoDB做切分和MapReduce分析也简单方便的多。这一切都源于HBase本身基于Hadoop,可以简单的通过增加廉价节点的方式进行扩展,对于数据本身就可以很好的进行水平切分,同时和HDFS,MapReduce,Spark等结合的很好。不仅可以方便的进行存储同时可以更加方便的对数据进行处理和运算,这才是HBase最核心的特性。这些都是常见的关系型数据库无法比拟的。比其他常见的NoSQL也要强出不少。

当然,HBase并不能解决所有的问题,所以才会有那么多的NoSQL和SQL

HBase典型的应用场景就是不断的插入新的信息。对于持续的大量的插入可以达到每秒百万的吞吐量。对于已有的数据修改的频率是很小的。 Google用自己的BigTable存储互联网上新生成的网页,Facebook的messenger是基于HBase实现的。

举个栗子

在大数据相关的应用之中,假设你要存储用户的地址和喜好。这些当然可以存储到关系型数据库之中,但是假设用户从上海搬到了北京。那么之前上海的地址就要update覆盖掉吗?这种应用场景下,我们需要计算分析用户的整个人生周期的活动记录和喜好,进而推测他的行为,收入,知识层次,信用等等。这些历史行为是不能被丢弃的,所以HBase可以很好的适应这样的场景。

摘自知乎:《HBase为什么火?它适用于哪些业务场景》中向磊的回答。

对于海量小文件存储HBase也是非常适合的。对比于支持文档型数据存储的MongoDB,HBase写优先于随机读,MongoDB的写性能不如读性能。两者虽然都支持MapReduce但是HBase对MapReduce的支持更好,同时HBase本身就支持水平切分,在数据分片上也有很大的优势。同时HBase本身就支持多个版本,对于多版本的数据存储也很方便。Mongo对于复杂查询支持较好,但是我们HBase也有Phoenix。
 
 
大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。
 
长按下面的二维码关注HBase技术社区公众号,同时也欢迎长按下面的二维码关注我的公众号








 
 
 
  查看全部
我们肯定听说过HBase,但是对于HBase的了解可能仅仅是它是Hadoop生态圈重要的一员,它是大数据技术圈一个很强的开源项目。然后内心os:它很屌,但是我用mysql/oracle。

一门技术的兴起,一个优秀的开源项目的存在肯定是有它所存在的意义,正如大数据一样,正是因为随着时间的发展,随着技术的发展导致我们每天的数据增量达到一个非常庞大的状态,同时在数据之中又能挖掘到很多有用的信息。所以才有了大数据技术的飞速发展。那么,我们为什么需要HBase,什么时候需要HBase呢?

HBase是什么?

HBase(Hadoop
Database) 是一个高可靠性,高性能,可伸缩,面向列的分布式数据库(也许叫做存储系统会更加贴切)。

就跟Hadoop本身也是起源与Google发布的GFS和MapReduce相关的论文一样,HBase是Google BigTable的开源实现。它整体的架构与BigTable很类似。例如:Google BigTableHBase利用GFS作为文件存储系统利用HDFS作为文件存储系统运行MapReduce处理存储的海量数据同样利用Hadoop MapReduce处理海量数据利用Chubby作为协同服务利用Zookeeper作为协同服务

HBase与Hadoop的关系非常紧密,Hadoop的HDFS提供了高可靠性的底层存储支持,Hadoop MapReduce为HBase提供了高性能的计算能力,Zookeeper为HBase提供了稳定性及failover机制的保障。同时其他周边产品诸如Hive可以与HBase相结合使在HBase进行数据统计处理变得简单,Sqoop为HBase提供了方便的RDBMS数据导入功能,使传统数据库的数据向HBase中迁移变得容易,Spark等高性能的内存分布式计算引擎也可能帮助我们更加快速的对HBase中的数据进行处理分析。

大数据的水很深,但是范围适中。初学者都是扎根于Hadoop的生态圈,HBase是必学技能之一

为什么选择HBase?而不是Mysql或者Oracle

当我们开始学习一门技术的时候总是习惯于将它们与已有的技术进行对比。当我们刚接触python的时候会发现它的简洁与效率,当我们刚接触php的时候也会探寻为啥它是最好的语言没有之一。。。

那么HBase经常会和常见的关系型数据库进行对比:

HBase  Mysql or Oracle列式,Nosql数据库行式,关系型数据库只支持byte类型支持多种数据类型支持海量数据存储支持大量数据存储只支持基于rowkey的索引支持每秒百万查询吞吐量每秒数千查询吞吐量事务只支持到row级别完整的事务适合时间序列或者随机查询适合复杂查询,多表关联等数据维护形式单一,更新支持多个版本存在数据增删改查非常方便,直接修改原有数据

其实两者的对比毫无意义,因为两者适用于不同的场景

HBase作为一个NoSQL,不支持完整的事务性,而且仅仅支持基于RowKey的索引,在性能上不如memcached和redis。但是在海量数据,持久化存储方便比内存类型的NoSQL强的多,作为文档型NoSQL在分布式存储上比mongoDB做切分和MapReduce分析也简单方便的多。这一切都源于HBase本身基于Hadoop,可以简单的通过增加廉价节点的方式进行扩展,对于数据本身就可以很好的进行水平切分,同时和HDFS,MapReduce,Spark等结合的很好。不仅可以方便的进行存储同时可以更加方便的对数据进行处理和运算,这才是HBase最核心的特性。这些都是常见的关系型数据库无法比拟的。比其他常见的NoSQL也要强出不少。

当然,HBase并不能解决所有的问题,所以才会有那么多的NoSQL和SQL

HBase典型的应用场景就是不断的插入新的信息。对于持续的大量的插入可以达到每秒百万的吞吐量。对于已有的数据修改的频率是很小的。 Google用自己的BigTable存储互联网上新生成的网页,Facebook的messenger是基于HBase实现的。

举个栗子

在大数据相关的应用之中,假设你要存储用户的地址和喜好。这些当然可以存储到关系型数据库之中,但是假设用户从上海搬到了北京。那么之前上海的地址就要update覆盖掉吗?这种应用场景下,我们需要计算分析用户的整个人生周期的活动记录和喜好,进而推测他的行为,收入,知识层次,信用等等。这些历史行为是不能被丢弃的,所以HBase可以很好的适应这样的场景。

摘自知乎:《HBase为什么火?它适用于哪些业务场景》中向磊的回答。

对于海量小文件存储HBase也是非常适合的。对比于支持文档型数据存储的MongoDB,HBase写优先于随机读,MongoDB的写性能不如读性能。两者虽然都支持MapReduce但是HBase对MapReduce的支持更好,同时HBase本身就支持水平切分,在数据分片上也有很大的优势。同时HBase本身就支持多个版本,对于多版本的数据存储也很方便。Mongo对于复杂查询支持较好,但是我们HBase也有Phoenix。
 
 
大家工作学习遇到HBase技术问题,把问题发布到HBase技术社区论坛http://hbase.group,欢迎大家论坛上面提问留言讨论。想了解更多HBase技术关注HBase技术社区公众号(微信号:hbasegroup),非常欢迎大家积极投稿。
 
长按下面的二维码关注HBase技术社区公众号,同时也欢迎长按下面的二维码关注我的公众号
微信图片_20180623105555.jpg

qrcode_for_gh_e12b18786730_258_(3).jpg

 
 
 
 

HBase 有没有对业务影响最小的滚动重启方案?

hbasemartin 回复了问题 • 3 人关注 • 2 个回复 • 733 次浏览 • 2018-06-17 20:09 • 来自相关话题

CDH 安装phoenix之后,server应该怎么提供出去?

PhoenixJepson 回复了问题 • 2 人关注 • 1 个回复 • 518 次浏览 • 2018-06-15 16:09 • 来自相关话题

中国HBase技术社区第一届MeetUp

hbasehbasegroup 发表了文章 • 2 个评论 • 793 次浏览 • 2018-05-31 13:52 • 来自相关话题

6月6日,由中国HBase技术社区组织,阿里云主办的中国第一届HBase Meetup将在北京举行,来自阿里、小米、滴滴、360等公司的各位大神会共同探讨HBase2.0的技术革新,HBase在国内各个大型企业内的应用价值,并一起见证中国HBase技术社区成立仪式的历史时刻。主办方阿里云将在线直播此次meetup,对于不能去现场的小伙伴可以收藏此网址,在6月6号下午14:00观看直播。中国HBase技术社区第一届MeetUp:https://promotion.aliyun.com/n ... .html
 
HBase Meetup亮点
共同见证中国HBase技术社区成立HBase大佬,神秘嘉宾亮相寄语多位HBase committer为您深度解读HBase2.0
名企HBase负责人讲述典型业务应用
 
直播议程安排
2018.06.06
14:00-14:30 | 议程:云数据库HBase2.0产品发布
所在 阿里云HBase高级产品专家
宣布阿里云云数据库HBase2.0版本发布,介绍云数据库HBase2.0版本基于社区版本做的改进以及重点企业级功能介绍。

14:30-15:00 | 议程:HBase2.0研讨圆桌会
HBase Committers&各公司HBase负责人
出席嘉宾(排名不分次序): 陈恒(HBase Committer,蚂蚁金服); 曹龙(阿里云HBase负责人); 胡争(HBase Committer,小米); 罗李(研究员, 滴滴); 李钰(HBase PMC, 阿里); 杨文龙(HBase Committer, 阿里) ; 杨哲(HBase Committer, 小马智行); 沈春辉(HBase PMC, 阿里); 王锋(奇虎360大数据负责人); 姚靖怡(滴滴HBase负责人); 张铎(HBase PMC, 小米); 张洸豪(HBase PMC, 小米)。

15:00-15:10 | 议程:中国HBase技术社区成立及招募仪式
阿里云、滴滴、小米等社区发起者
宣布中国HBase技术社区正式成立,并进行成员招募
15:10-15:40 | 议程:HBase 3.0的发展规划
张铎 HBase PMC 小米HBase负责人
展望HBase3.0的规划及技术革新给业务场景带来的价值

15:40-16:10 | 议程:滴滴HBase应用与实践
姚靖怡 滴滴HBase负责人
讲述HBase在滴滴实际业务中的应用

16:10-17:00 | 议程:当HBase遇上云的思考
封神 阿里云HBase负责人详解阿里云HBase基于社区版本的改进及企业级功能解决的用户痛点
 
中国HBase技术社区招募
为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,由HBase项目负责人Stack授权,阿里云发起,滴滴、小米等公司的HBase技术研究人员共同组建了中国HBase技术社区(CHTC:Chinese HBase Technical Community),旨在成为中国最有影响力的HBase技术社区,社区已经试运行2个月,现正式对广大HBase爱好者开放招募,加入中国HBase用户会,您将获得:
获取HBase最新技术迭代信息以及权威解读参加社区不定期组织的 线下meetup,拓展合作机会与各路技术大牛共同探讨 学习HBase为HBase的发展提出您的 意见,推动技术进步
 
加入中国HBase技术社区
HBase是一个分布式的面向列的开源数据库,是大数据生态圈中非常重要的一环,主要应用在大数据量(PB级)存储及超大规模(千万级QPS)随机读写访问。为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,阿里巴巴、小米、华为、网易、京东、滴滴、知乎等公司的HBase技术研究人员共同发起了组建HBase技术社区。我们非常欢迎对HBase有技术激情的同学一起加入探讨HBase技术,如果你热爱写技术博客,欢迎加入我们,一起坚持创作写出高质量的内容。加入中国HBase技术社区请点击链接:https://mp.weixin.qq.com/s/3XNu-cbDuhy7y6gARjFSzw
 
 
  查看全部
6月6日,由中国HBase技术社区组织,阿里云主办的中国第一届HBase Meetup将在北京举行,来自阿里、小米、滴滴、360等公司的各位大神会共同探讨HBase2.0的技术革新,HBase在国内各个大型企业内的应用价值,并一起见证中国HBase技术社区成立仪式的历史时刻。主办方阿里云将在线直播此次meetup,对于不能去现场的小伙伴可以收藏此网址,在6月6号下午14:00观看直播。中国HBase技术社区第一届MeetUp:https://promotion.aliyun.com/n ... .html
 
HBase Meetup亮点
  • 共同见证中国HBase技术社区成立
  • HBase大佬,神秘嘉宾亮相寄语
  • 多位HBase committer为您深度解读HBase2.0

  • 名企HBase负责人讲述典型业务应用

 
直播议程安排
2018.06.06
14:00-14:30 | 议程:云数据库HBase2.0产品发布

所在 阿里云HBase高级产品专家
宣布阿里云云数据库HBase2.0版本发布,介绍云数据库HBase2.0版本基于社区版本做的改进以及重点企业级功能介绍。

14:30-15:00 | 议程:HBase2.0研讨圆桌会
HBase Committers&各公司HBase负责人
出席嘉宾(排名不分次序): 陈恒(HBase Committer,蚂蚁金服); 曹龙(阿里云HBase负责人); 胡争(HBase Committer,小米); 罗李(研究员, 滴滴); 李钰(HBase PMC, 阿里); 杨文龙(HBase Committer, 阿里) ; 杨哲(HBase Committer, 小马智行); 沈春辉(HBase PMC, 阿里); 王锋(奇虎360大数据负责人); 姚靖怡(滴滴HBase负责人); 张铎(HBase PMC, 小米); 张洸豪(HBase PMC, 小米)。

15:00-15:10 | 议程:中国HBase技术社区成立及招募仪式
阿里云、滴滴、小米等社区发起者

宣布中国HBase技术社区正式成立,并进行成员招募
15:10-15:40 | 议程:HBase 3.0的发展规划
张铎 HBase PMC 小米HBase负责人

展望HBase3.0的规划及技术革新给业务场景带来的价值

15:40-16:10 | 议程:滴滴HBase应用与实践
姚靖怡 滴滴HBase负责人

讲述HBase在滴滴实际业务中的应用

16:10-17:00 | 议程:当HBase遇上云的思考
封神 阿里云HBase负责人详解阿里云HBase基于社区版本的改进及企业级功能解决的用户痛点
 
中国HBase技术社区招募
为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,由HBase项目负责人Stack授权,阿里云发起,滴滴、小米等公司的HBase技术研究人员共同组建了中国HBase技术社区(CHTC:Chinese HBase Technical Community),旨在成为中国最有影响力的HBase技术社区,社区已经试运行2个月,现正式对广大HBase爱好者开放招募,加入中国HBase用户会,您将获得:
  • 获取HBase最新技术迭代信息以及权威解读
  • 参加社区不定期组织的 线下meetup,拓展合作机会
  • 与各路技术大牛共同探讨 学习HBase
  • 为HBase的发展提出您的 意见,推动技术进步

 
加入中国HBase技术社区
HBase是一个分布式的面向列的开源数据库,是大数据生态圈中非常重要的一环,主要应用在大数据量(PB级)存储及超大规模(千万级QPS)随机读写访问。为了让众多HBase相关从业人员及爱好者有一个自由交流HBase相关技术的社区,阿里巴巴、小米、华为、网易、京东、滴滴、知乎等公司的HBase技术研究人员共同发起了组建HBase技术社区。我们非常欢迎对HBase有技术激情的同学一起加入探讨HBase技术,如果你热爱写技术博客,欢迎加入我们,一起坚持创作写出高质量的内容。加入中国HBase技术社区请点击链接:https://mp.weixin.qq.com/s/3XNu-cbDuhy7y6gARjFSzw
 
 
 

Hbase中的数据大家是怎么进行权限控制的?

hbaseguokaiwhu 回复了问题 • 5 人关注 • 4 个回复 • 3141 次浏览 • 2018-05-29 11:41 • 来自相关话题


中国HBase技术社区微信公众号:
hbasegroup

欢迎加入HBase生态+Spark社区钉钉大群