布隆过滤器hbase布隆过滤器hbase
作者:spring 发布时间:2023-10-25 栏目: 常见问题 0浏览
老铁们，大家好，相信还有很多朋友对于布隆过滤器 hbase和布隆过滤器hbase的相关问题不太懂，没关系，今天就由我来为大家分享分享布隆过滤器 hbase以及布隆过滤器hbase的问题，文章篇幅可能偏长，希望可以帮助到大家，下面一起来看看吧！
本文目录
region下所有的hfile默认存放hbase的核心数据结构是hbase通过什么快速判断用户数据不存在HBase是什么呢,都有哪些特点呢region下所有的hfile默认存放HBase是GoogleBigtable的开源实现，是一个sparse,distributed,persistentmulti-dimensionalsortedmap，map的key由rowkey，columnfamily，qualifier，timestamp，type组成，并据此排序。
架构图
Hbase的架构是存算分离的，方便扩展，底层存储使用HDFS，HBase相关组件提供计算功能，部分元数据存储在ZK中。架构图如下：
数据模型
table：表，一个表包含多行数据
row：行，一行数据包含一个唯一标识rowkey、多个column以及对应的值。在HBase中，一张表中所有row都按照rowkey的字典序由小到大排序。
column：列，与关系型数据库中的列不同，HBase中的column由columnfamily（列簇）以及qualifier（列名）两部分组成，两者中间使用":"相连。比如contents:html，其中contents为列簇，ht
ml为列簇下具体的一列。columnfamily在表创建的时候需要指定，不能随意增减。一个columnfamily下可以有任意多个qualifier，也就是HBase中的列可以动态增加，理论上甚至可以扩展到上百万列。timestamp：时间戳，每个cell在写入HBase的时候都会默认分配一个时间戳作为该cell的版本，当然，用户也可以在写入的时候自带时间戳。HBase支持多版本特性，即同一rowkey、column下可以有多个value存在，这些value使用timestamp作为版本号，版本越大，表示数据越新。
cell：单元格，由五元组（row,column,timestamp,type,value）组成的结构，其中type表示Put/Delete这样的操作类型，timestamp代表这个cell的版本。这个结构在数据库中实际是以KV结构存储的，其中（row,column,timestamp,type）是K，value字段对应KV结构的V。在每个HFile文件中，KV按序存储，按照KV中key的字典序进行排序。先比较rowkey，rowkey小的排在前面；如果rowkey相同，再比较column，即columnfamily:qualifier，column小的排在前面；如果column还相同，再比较时间戳timestamp，即版本信息，timestamp大的排在前面（也就是最新的排在前面）。
数据文件的物理存储
HFile在HDFS上按照table、region、columnfamily分目录存储，如下所示：
/hbase/data/default/table-name/region-name/column-family-name/hfile-name
其中default是默认namespace，一个列簇下的所有HFile文件都在同一个列簇目录下，按照文件的新旧程度放置在LSM-tree的不同level，每个level只有一个HFile文件。
Compact
MinorCompact：选取部分尺寸小的、LSM-tree中相邻level的HFile，将它们合并成更大的HFile，但是不清理type为deletes或expiredversions的数据。
MajorCompact：将一个Store中所有的HFile合并成一个HFile，由于只有一个HFile文件，这个文件可能会很大，这也是HFile文件结构中索引是多层结构的原因。这个过程还会完全清理三类无意义数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据。
RegionServer
一个RegionServer由一个（或多个）HLog、一个BlockCache以及多个Region组成。其中，HLog用作WAL；BlockCache可以将block缓存在内存中以提升数据读取性能；Region是HBase中数据表的一个数据分片，一个RegionServer通常会负责多个Region的数据读写，Region可以来自相同或不同表。Region由多个Store组成，一个Store负责一个列簇的数据，比如一个表中有两个列簇，这个表的所有Region就都会包含两个Store。每个Store包含一个MemStore和多个HFile，用户数据写入时会先写HLog，然后将对应列簇数据写入相应的MemStore，一旦MemStore大小超过设定阈值，系统就会将MemStore中的数据落盘形成HFile文件，HFile存放在HDFS上。
这里HLog、MemStore、HFile与LevelDB中对应的相关文件：日志文件、memtable、sstable，格式也有相似之处，先不展开介绍。
ACID
HBase保证单行事务的ACID特性，跨行无法保证。作为该限制的结果之一就是不支持辅助索引，对数据项的更新需要同时对辅助索引进行更新，而这不是原子的。单行事务的保证是通过将单行中涉及的多个column修改编码为一条WAL来完成的，即使跨多个columnfamily也可以。
hbase:meta表
hbase:meta表就是分区表，分区表作用可以参考
狂奔的蜗牛：可扩展性之数据分区
该表存储了Region到RegionServer的映射，用来路由client读写请求、进行负载均衡等操作。该表的所在RS节点存储在ZK上。表结构如下：
Key
Regionkeyoftheformat([table],[regionstartkey],[regionid])
Values
info:regioninfo(serializedHRegionInfoinstanceforthisregion)
info:server(server:portoftheRegionServercontainingthisregion)
info:serverstartcode(start-timeoftheRegionServerprocesscontainingthisregion)
当Region发生split时候，values中会新建两列：info:splitA和info:splitB。这两列代表两个新的子Region，列值同info:regioninfo一样，也是serializedHRegionInfoinstance，在Region完成split后，对应的旧行将被删除。
空的startkey表示HBase一张表的start或者end，hbase:meta表中如果一个Region有空的startkey，那么这个Region是对应表的第一个Region，如果startkey和endkey都为空，那么这个Region是表的唯一Region。
Region的划分使用范围分区策略，按照rowkey划分。
数据写入
客户端将用户的写入请求进行预处理，并根据集群元数据定位写入数据所在的RegionServer，将请求发送给对应的RegionServer。
RegionServer接收到写入请求之后，先写WAL，再写入对应Region列簇的MemStore。
当Region中MemStore容量超过一定阈值，系统会异步执行flush操作，将内存中的数据写入HFile。
数据读取
读取有get和scan两种API，get通常根据给定rowkey查找一行记录，scan通常根据给定的startkey和stopkey查找多行满足条件的记录。技术实现上，get是特殊的scan，scan的条数为1。scan并没有设计为一次RPC请求，因为一次scan操作的扫描结果可能数据量非常大。HBase会根据设置条件将一次大的scan拆分为多个RPC请求，每个RPC请求称为一次next请求，每次只返回规定数量的结果。
1、client根据集群元数据定位查询数据所在的RegionServer，将请求发送给对应的RegionServer。
2、对包含用户查询数据的Region的HFile进行过滤，过滤方法主要有三种：
根据KeyRange过滤：因为HFile中所有KeyValue数据都是有序的，所以如果待检索row范围[startrow，stoprow]与文件起始key范围[firstkey，lastkey]没有交集，就可以过滤掉该HFIle。
根据TimeRange过滤：HFile中元数据有一个关于该File的TimeRange属性[miniTimestamp,maxTimestamp]，如果待检索的TimeRange与该文件时间范围没有交集，就可以过滤掉该HFile；另外，如果该文件所有数据已经过期，也可以过滤淘汰。
根据布隆过滤器进行过滤：根据待检索的rowkey获取对应的BloomBlock并加载到内存（通常情况下，热点BloomBlock常驻内存），使用布隆过滤器中的数据确定待检索rowkey是否一定不存在于该HFile。
3、从剩余HFile中读取待查找key：首先根据HFile中的索引定位目标block，然后看BlockCache中是否存在，不存在则从HDFS中seek读取，之后在block中顺序查找指定key。由于不同HFile文件之间的数据是无序的，因此需要归并排序，实际上MemStore使用MemStoreScanner读取数据，HFile使用StoreFileScanner读取数据，最后KeyValueScanner将使用MemStoreScanner和多个StoreFileScanner来构建最小堆，保证所有数据有序。
hbase的核心数据结构是hbase的核心数据结构为LSM树。
SM树分为内存部分和磁盘部分。
内存部分是一个维护有序数据集合的数据结构。一般来讲，内存数据结构可以选择平衡二叉树、红黑树、跳跃表（SkipList）等维护有序集的数据结构，由于考虑并发性能，HBase选择了表现更优秀的跳跃表。
磁盘部分是由一个个独立的文件组成，每一个文件又是由一个个数据块组成。对于数据存储在磁盘上的数据库系统来说，磁盘寻道以及数据读取都是非常耗时的操作（简称IO耗时）。为了避免不必要的IO耗时，可以在磁盘中存储一些额外的二进制数据，这些数据用来判断对于给定的key是否有可能存储在这个数据块中，这个数据结构称为布隆过滤器（BloomFilter）。
hbase通过什么快速判断用户数据不存在hbase通过BloomFiter快速判断用户数据不存在。根据查询相关公开信息显示，布隆过滤器BloomFilter精确判断数据不存在，如果判断数据存在可能有误差用来优化一些随机读取的场景。
HBase是什么呢,都有哪些特点呢Hbase是一种NoSQL数据库，这意味着它不像传统的RDBMS数据库那样支持SQL作为查询语言。Hbase是一种分布式存储的数据库，技术上来讲，它更像是分布式存储而不是分布式数据库，它缺少很多RDBMS系统的特性，比如列类型，辅助索引，触发器，和高级查询语言等待
那Hbase有什么特性呢？如下：
强读写一致，但是不是“最终一致性”的数据存储，这使得它非常适合高速的计算聚合
自动分片，通过Region分散在集群中，当行数增长的时候，Region也会自动的切分和再分配
自动的故障转移
Hadoop/HDFS集成，和HDFS开箱即用，不用太麻烦的衔接
丰富的“简洁，高效”API，Thrift/RESTAPI，JavaAPI
块缓存，布隆过滤器，可以高效的列查询优化
操作管理，Hbase提供了内置的web界面来操作，还可以监控JMX指标
什么时候用Hbase？
Hbase不适合解决所有的问题：
首先数据库量要足够多，如果有十亿及百亿行数据，那么Hbase是一个很好的选项，如果只有几百万行甚至不到的数据量，RDBMS是一个很好的选择。因为数据量小的话，真正能工作的机器量少，剩余的机器都处于空闲的状态
其次，如果你不需要辅助索引，静态类型的列，事务等特性，一个已经用RDBMS的系统想要切换到Hbase，则需要重新设计系统。
最后，保证硬件资源足够，每个HDFS集群在少于5个节点的时候，都不能表现的很好。因为HDFS默认的复制数量是3，再加上一个NameNode。
Hbase在单机环境也能运行，但是请在开发环境的时候使用。
内部应用
存储业务数据:车辆GPS信息，司机点位信息，用户操作信息，设备访问信息。。。
存储日志数据:架构监控数据（登录日志，中间件访问日志，推送日志，短信邮件发送记录。。。），业务操作日志信息
存储业务附件：UDFS系统存储图像，视频，文档等附件信息
不过在公司使用的
时候，一般不使用原生的HbaseAPI，使用原生的API会导致访问不可监控，影响系统稳定性，以致于版本升级的不可控。HFile
HFile是Hbase在HDFS中存储数据的格式，它包含多层的索引，这样在Hbase检索数据的时候就不用完全的加载整个文件。索引的大小(keys的大小，数据量的大小)影响block的大小，在大数据集的情况下，block的大小设置为每个RegionServer1GB也是常见的。
探讨数据库的数据存储方式，其实就是探讨数据如何在磁盘上进行有效的组织。因为我们通常以如何高效读取和消费数据为目的，而不是数据存储本身。
Hfile生成方式
起初，HFile中并没有任何Block，数据还存在于MemStore中。
Flush发生时，创建HFileWriter，第一个空的DataBlock出现，初始化后的DataBlock中为Header部分预留了空间，Header部分用来存放一个DataBlock的元数据信息。
而后，位于MemStore中的KeyValues被一个个append到位于内存中的第一个DataBlock中：
注：如果配置了DataBlockEncoding，则会在AppendKeyValue的时候进行同步编码，编码后的数据不再是单纯的Ke
yValue模式。DataBlockEncoding是HBase为了降低KeyValue结构性膨胀而提供的内部编码机制。关于本次布隆过滤器 hbase和布隆过滤器hbase的问题分享到这里就结束了，如果解决了您的问题，我们非常高兴。
