hbase

时间:2024-09-22 16:29:50编辑:流行君

HBase是什么?为什么要使用HBase?

HBase在产品中还包含了Jetty,在HBase启动时采用嵌入式的方式来启动Jetty,因此可以通过web界面对HBase进行管理和查看当前运行的一些状态,非常轻巧。为什么采用HBase?HBase 不同于一般的关系数据库,它是一个适合于非结构化数据存储的数据库.所谓非结构化数据存储就是说HBase是基于列的而不是基于行的模式,这样方面读写你的大数据内容。HBase是介于Map Entry(key & value)和DB Row之间的一种数据存储方式。就点有点类似于现在流行的Memcache,但不仅仅是简单的一个key对应一个 value,你很可能需要存储多个属性的数据结构,但没有传统数据库表中那么多的关联关系,这就是所谓的松散数据。简单来说,你在HBase中的表创建的可以看做是一张很大的表,而这个表的属性可以根据需求去动态增加,在HBase中没有表与表之间关联查询。你只需要 告诉你的数据存储到Hbase的那个column families 就可以了,不需要指定它的具体类型:char,varchar,int,tinyint,text等等。但是你需要注意HBase中不包含事务此类的功 能。Apache HBase 和Google Bigtable 有非常相似的地方,一个数据行拥有一个可选择的键和任意数量的列。表是疏松的存储的,因此用户可以给行定义各种不同的列,对于这样的功能在大项目中非常实用,可以简化设计和升级的成本。


Hbase读写原理

不同列族分别存在不同的文件夹里。 与MySQL比较 首先Hbase是依赖于HDFS和zookeeper的。 Zookeeper分担了Hmaster的一部分功能,客户端进行DML语句的时候,都是先跟ZK交互。 RegionServer管理了很多的Region(表),RegionServer里面的WAL(HLog)是预写入日志,功能是防止内存中的数据没有来的及落盘时丢失。在Region里面管理的Store管理的是列族,Store里面有Mem Store(内存),Flush之后,删除内存中的数据,同时写入文件StoreFile Hfile,Hfile 其实是在DataNode里面的。 Hbase的读比写慢。 Hbase命名空间下有一张元数据表meta表和namespace表。meta表里面保存了要操作的表所在的位置等元数据。 (1)首先客户端向zk请求元数据表所在的RegionServer,zk返回给客户端meta表所在的regionServer。 (2)然后客户端再去对应的RegionServer查找meta表,找到真正要操作的表所在的regionServer,同时把meta表的信息缓存下来,加快后续的查询。 (3)然后客户端再向目标表所在的RegionServer发送put请求。先把数据写到Hlog里面,再写到内存MemStore,数据会在内存排序,然后向客户端发送ack,到这里对于客户端来说写数据已经结束了。再等到MemStore的刷写时机后,将数据刷写到Hfile. 注:meta表所在的位置信息保存在zk的meta-region-server节点上,客户端首先就是在这个节点上差询meta表所在的RegionServer。meta表里面的信息就是表与其对应的RegionServer的信息 这个stu表可能不止一条,因为stu表可能数据量大了之后根据RowKey进行了切分,并且可能会在不同的机器上。 不同的列族是在不同的文件夹。 MemStore刷写时机: 全局的MemStore的容量,默认是堆内存的40%。这个容量值会触发flush操作,所有的MemStore都要刷写,flush操作会阻塞读写操作。 会刷写并阻塞到到MemStore大小降到它的最大容量的95% WAL日志的刷写时机: 可以设置日志的大小和数量,当达到一定数量,刷写到HDFS (1)从zk找meta表所在的RegionServer (2)从上述RegionServer里的meta表里找目标表所在的RegionServer,同时把meta表缓存,加速后面的查询。 (3)向目标表所在的RegionServer发送get请求。可以从block Cache,MemStore还有StoreFile里面查,具体从哪查根据时间戳,查时间戳大的,具体就都查然后merge取最新。 RegionServer里面有block Cache可以缓存磁盘的数据,加速查询。如果block Cache里面有,就将缓存和MemStore的数据merge然后取最新时间戳,没有就是把磁盘读的和MemStore里面的合并。所以hbase大多数读要走磁盘,所以读很慢。 每次刷写会生成新的Hfile,Hfile很小并且数量多的时候会影响查询的速度。所以要进行合并。合并分为minor Compaction和major Compaction minor Compaction将临近的若干较小的Hfile合并成一个较大的Hfile,不会清理过期和删除的数据,major Compaction会将一个Store里面的所有Hfile合并成一个大的Hfile,并且会清理掉过期和删除的数据。 数据的读写可以不依赖Hmaster,只需要指定zookeeper,但是Hmaster负责region调度的元数据 但是DDL语言是要有Hmaster的 Flush和major Compact (1)flush在同一个内存中清除过期或删除(删除标记也是一行数据)的数据,但是如果数据不同的版本分布在不同的memStroe,就不能清除。删除的标记在flush之后不会被删,但在后面的major compaction会把删除标记删除掉。 (2)major compaction 会清除过期或删除的数据。 默认情况下,每个Table起初只有一个Region,随着数据的不断写入,Region会自动拆分,两个子Region开始都会在一个Regionserver里面,但是出于负载均衡的考虑,Hmaster有可能会将某个Region传给其他的RegionServer。 Split的时机: (1)当一个Region中的某个Store下的StoreFile的总大小查过某个值,由参数hbase.hregion.max.filesize设定(默认10g),该Region就会按照RowKey进行拆分。 (2)在新版本中这个值是Min(R^2*"hbase.hregion.memStore.flush.size(128M)","hbase.hregion.max.filesize"),R是当前RegionServer中属于该Table的Region个数。分region是按照RowKey切分的。这会导致数据倾斜,就是因为切分的阈值在变化,导致切分之后的region数据量不均匀,导致热点的问题。所以在建表的时候要做预分区,就是用RowKey规划好多少个region,不让hbase自己的切分逻辑切分。 官方建议只用一个列族,防止不同的列族之间数据不均匀,单一列族数据量增多,导致全局的flush,数据量小的列族也要flush,这样会形成很多小的storeFile。 delete操作: (1)设置RowKey:打的删除标记是deleteFamily,删除多个版本 (2)设置RowKey+Family:打的标记是deleteFamily,删除多个版本 (3)设置RowKey+family+column:有addColumn()和addColumns().addColumn是删除最新的版本或者删除指定时间戳的版本,删除标记是delete标记。addColumns是删除所有的版本或者删除指定时间戳或之前的版本,删除标记是deleteColumn Delete的操作其实也是put操作,put的是删除的标记。 在Hbase中HMaster负责监控HRegionServer的生命周期,均衡RegionServer的负载,如果HMaster挂掉了,那个整个Hbase集群将处于不健康的状态,并且此时的工作状态不会维持太久。所以Hbase支持对HMaster的高可用配置。 在Hbase的conf目录下新建backup-masters文件,vim加入备份Master,比如slave01,slave02.在把文件分发到各个slave里,然后再启动hbase 就能实现HMaster的高可用了。 每一个region维护着StartRow和EndRow,如果加入的数据符合某个region维护的RowKey范围,则该数据交给这个region维护。那么依照这个原则,我们可以将数据所要投放的分区提前大致的规划好,以提高Hbase性能。 (1)手动设定预分区 手动设置RowKey分了5个region (2)生成16进制序列预分区 (3)按照文件中设置的规则预分区 创建split.txt 然后执行 这里如果文件里面给的分区键不是按照顺序的,hbase会先帮我们把键排序,然后按照键来分区。 (4)使用JavaAPI预分区 admin的创建表的方法有多个重载,可以只传表的描述,也可以加入分区的信息。admin.createTable 规划分区要考虑未来数据量和机器的规模。虽然提前做了分区,但是最后如果分区大于了10G,还是会触发split。假设一台机器有100G磁盘,那么预分区尽量大于10个,这样就能避免预分区之后又触发了大于10G的split。 (1)希望数据能够尽量均匀的分配在多个分区里面(散列性)。 (2)唯一性 (3)长度原则(生产环境70到100位) 常见的设计方案: (1)生产随机数、hash、散列值 (2)字符串反转 (3)字符串拼接 电信项目: 一次通话的记录:13112341233->18998768771 2018-12-12 12:12:21 568 假设分300个区 分区键怎么设计: (299个键) 000| 001| ... 298| RowKey的前面一般会拼上000_,001_,...,298_ 这样做的好处是,根据前三位就能知道哪个分区。 (1)我们希望手机号尽量分布在不同的分区,但是相同的手机号数据集中在同一个分区,这样方便查询某个用户的通话信息。000_13112341233 (2)因为每个人通话的需求不同,也希望把同一个人的通话记录也分布在不同的分区里面。000_13112341233_2019-12-12 哈希取余:[(13112341234^201912).hash]%299 假设要查询某用户2019年2月的通话记录,可以用13112341234 201902做startRowkey,13112341234 201903做endRowKey 微博。 1、需求 (1)微博内容的浏览 (2)用户社交:关注用户,取关用户 (3)拉取关注人的微博用户 2、设计表 (1)微博内容表Content 行键:用户id+时间戳 (2)用户关系表 因为正常情况一个用户的粉丝和关注都不多,可以用一行存储关注和粉丝的情况。 行键:用户id (3)初始化页面的表(显示关注的人的最近三条微博)

上一篇:夹娃娃机器

下一篇:没有了