hbase中为何不能向表中插入数据_Hbase学习笔记【1】

最新推荐文章于 2024-06-29 10:18:02 发布

weixin_39932939

最新推荐文章于 2024-06-29 10:18:02 发布

阅读量371

点赞数

文章标签： hbase中为何不能向表中插入数据

Hbase简介 Hbase是实时性数据库，Hbase数据存在HDFS上，少量的数据存在内存中。 Hbase是开源的非关系型分布式数据库NoSQL，运行在HDFS文件系统之上。 特性： 高可靠，高并发读写，面向列，可伸缩。关系型数据库都是行存储，写入一次性完成，保持数据完整性；容易产生冗余数据； Hbase是列存储的；读取过程不会产生冗余数据，适合对数据完整性要求不高的大数据领域 Hbase应用场景： 互联网搜索引擎数据存储；海量数据写入；消息中心；内容服务系统；大表复杂&多维度索引；大批量数据读取；

Hbase数据模型：

行键rowkey 表的主键

时间戳version，每一个时间戳背后代表一个版本

列族column family，可细分出多个子列，子列称为column quanlifier

数据查询定位顺序：

{rowkey => {family => {qualifier => {version => value}}}} a:cf1:bar:1368394583:7

Hbase一张表由一个或多个Hregion组成，Hregion相对于一个区，由多个分区组成一张表；

Region按大小分割的，每个表一开始只有一个region，随着数据不断插入表，region不断增大，当增大到一个阀值的时候，Hregion就会等分会两个新的Hregion。当table中的行不断增多，就会有越来越多的Hregion。每一个Region会被分到一个Region Server机器上，所以一张表会被分区到不同机器节点上存储；Region Server负责用户的IO请求一个region只属于一个regionserver，类似节点；regionserver上有很多region存储着；

Hbase是行锁定的

• 表 -> HTable

• 按RowKey范围分的Region-> HRegion ->Region Servers

• HRegion按列族(Column Family) ->多个HStore

• HStore -> memstore(128M) + HFiles(均为有序的KV)

• HFiles -> HDFS

HRegionServer：进程，内部管理了一系列的HRegion对象

HRegion是Hbase中分布式存储和负载均衡的最小单元。HRegion虽然是分布式存储的最小单元，但并不是存储的最小单元。

Hbase物理模型

• Client

– 访问Hbase的接口，并维护Cache加速Region Server的访问

• Master

– 负载均衡，分配Region到RegionServer

• Region Server

– 维护Region，负责Region的IO请求

• Zookeeper

– 保证集群中只有一个Master

– 存储所有Region的入口(ROOT)地址

– 实时监控Region Server的上下线信息，并通知Master

Hmaster(主)有四个功能：

1.负载均衡：管理和分配HRegion

2.DDL：增删改->table，cf，namespace

3.类似namenode，管理一些元数据，table的结构

4.ACL权限控制

HRegionServer(从)：

1.管理和存放本地的HRegion

2.读写HDFS，提供IO操作

3.本地化：HRegion的数据尽量和数据所属的DataNode在一块，但是这个本地化不能够满足；

Hbase的容错性：

ZooKeeper协调集群所有节点的共享信息，在HMaster和HRegionServer连接到ZooKeeper后创建Ephemeral节点，并使用Heartbeat机制维持这个节点的存活状态，如果某个Ephemeral节点实效，则HMaster会收到通知，并做相应的处理。

除了HDFS存储信息，HBase还在Zookeeper中存储信息，其中的znode信息： – /hbase/root-region-server ，Root region的位置 – /hbase/table/-ROOT-，根元数据信息 – /hbase/table/.META.，元数据信息 – /hbase/master，当选的Mater – /hbase/backup-masters，备选的Master – /hbase/rs ，Region Server的信息 – /hbase/unassigned，未分配的Region • Master容错： – Zookeeper重新选择一个新的Master • 无Master过程中，数据读取仍照常进行； • 无master过程中，region切分、负载均衡等无法进行 • Region Server容错： – 定时向Zookeeper汇报心跳，如果一旦时间内未出现心跳，Master将该RegionServer上的 Region重新分配到其他RegionServer上，失效服务器上“预写”日志由主服务器进行分割并派送给新的RegionServer • Zookeeper容错： – Zookeeper是一个可靠地服务，一般配置3或5个Zookeeper实例 •客户端往RegionServer端提交数据的时候，会写WAL 日志，只有当WAL日志写成功以后，客户端才会被告诉提交数据成功，如果写WAL失败会告知客户端提交失败 • 数据落地的过程 • 在一个RegionServer上的所有的Region都共享一个 HLog，一次数据的提交是先写WAL，写入成功后，再写memstore。当memstore值到达一定阈值，就会形成一个个StoreFile(理解为HFile格式的封装，本质上还是以HFile的形式存储的) Hbase基本操作： 基本的单行操作：PUT，GET，DELETE • 扫描一段范围的Rowkey: SCAN – 由于Rowkey有序而让Scan变得有效 • GET和SCAN支持各种Filter，将逻辑推给Region Server – 以此为基础可以实现复杂的查询 • 支持一些原子操作：INCREMENT、APPEND、CheckAnd{Put,Delete} • MapReduce • 注：在单行上可以加锁，具备强一致性。这能满足很多应用的需求。 Hbase特殊的表： • -ROOT表和.META.表是两个比较特殊的表 • .META.记录了用户表的 Region信息，.META.可以有多个regoin。 • -ROOT-记录了.META.表的 Region信息，-ROOT-只有一个region，Zookeeper中记录了-ROOT-表的location

在Hbase 0.96之后去掉了-ROOT表，由于原因：

– 三次请求才能直到用户Table真正所在的位置也是性能低下的

– 即使去掉-ROOT- Table，也还可以支持2^17(131072)个Hregion，对于集群来说，存储空间也足够

• 所以目前流程为：

– 从ZooKeeper(/hbase/meta-region-server)中获取hbase:meta的位置( HRegionServer的位置)，缓存该位置信息

– 从HRegionServer中查询用户Table对应请求的RowKey所在的HRegionServer，缓存该位置信息

– 从查询到HRegionServer中读取Row。

Hbase的写入流程—寻址

我们发现客户会缓存这些位置信息，然而第二步它只是缓存当前RowKey对应的HRegion的位置，因而如果下一个要查的RowKey 不在同一个HRegion中，则需要继续查询hbase:meta所在的HRegion，然而随着时间的推移，客户端缓存的位置信息越来越多，以至于不需要再次查找hbase:meta Table的信息，除非某个HRegion因为宕机或Split被移动，此时需要重新查询并且更新缓存。

hbase:meta表存储了所有用户HRegion的位置信息

Hbase的写入流程：

1.当客户端发起一个Put请求时，首先它从hbase:meta表中查出该Put数据最终需要去的 HRegionServer。然后客户端将Put请求发送给相应的HRegionServer，在HRegionServer中它首先会将该Put操作写入WAL日志(Flush到磁盘中)。

2. 写完WAL日志文件后，HRegionServer根据Put中的TableName和RowKey找到对应的 HRegion，并根据Column Family找到对应的HStore，并将Put写入到该HStore的MemStore 中。此时写成功，并返回通知客户端。

注意：Memstore是一个写缓存，每一个Column Family有一个自己的MemStore

HBase中扫瞄的顺序依次是：BlockCache、MemStore、StoreFile(HFile) Hbase的Compaction(合并)和split(划分) 合并主要为： 1.region的合并：尽量把小的region合并到一个大的，理想情况下，每个region的请求量是一样的(不能保证数据量是一样的)； 2.storefile的合并： Minor Compaction： 目的为了保证服务不中断，但是合并不彻底。是指选取一些小的、相邻的StoreFile将他们合并成一个更大的StoreFile，在这个过程中不会处理已经Deleted或Expired的Cell Major Compaction： 目的为了合并更加彻底，但是服务存在中断风险。是指将所有的StoreFile合并成一个StoreFile，这个过程还会清理三类无意义数据：被删除的数据、TTL过期数据、版本号超过设定版本号的数据 Compaction本质： 使用短时间的IO消耗以及带宽消耗换取后续查询的低延迟； compact的速度远远跟不上HFile生成的速度，这样就会使HFile的数量会越来越多，导致读性能急剧下降。为了避免这种情况，在HFile的数量过多的时候会限制写请求的速度。 Split – 当一个Region太大时，将其分裂成两个Region • Split和Major Compaction可以手动或者自动做。

喜欢本文点个在看