美文网首页spark||flink||scala
六、HBase写入流程

六、HBase写入流程

作者: loukey_j | 来源:发表于2020-01-13 13:54 被阅读0次

    1、HBase写入流程

    HBase服务端没有提供update,delete接口,HBase中对数据的更新、删除操作都认为是写入操作,更新操作会写入一个最小版本数据,删除操作写写入一条标记为deleted的KV数据

    1.1、写入流程三个阶段概况

    1)客户端处理阶段:客户端将用户请求进行预处理,并根据集群元数据定位写入数据所在的RegionServer,将请求发送给RS

    2)Region写入阶段:RS收到请求之后解析数据,首先把数据写入WAL,再写入对应Region对应的MemStore

    3)MemStore Flush阶段:当Region中MemStore容量达到一定阈值之后,系统异步执行flush操作,将内存写入文件,形成HFile

    1.2、用户写入请求在完成写入MemStore之后就会返回成功。MemStore Flush是一个异步执行的过程。

    1.3、客户端处理阶段步骤详解:

    1)客户端可以设置批量提交,如果设置了批量提交(autoflush=false)客户端会先将数据写入本地缓冲区等达到一定阈值之后才会提交。否则put请求直接会提交给服务端进行处理。

    2)RS寻址,在提交之前HBase会在元数据表hbase:meta中根据rowkey找到她们归属的RS

    2.1)客户端根据写入的表和rowkey在元数据中查找,如果能够查找出该rowkey所在的RS及Region,就直接发送写入请求

    2.2)如果客户端没有找到rowkey信息,需要首先到zk上找到hbase:meta表所在的RS,向那RS发送查询请求获取元数据,然后在元数据中查找rowkey所在的RS,并将元数据缓存在本地,以备下次使用。

    3)客户端发送远程RPC请求给RS,将数据写入目标Region的MemStore中

    1.4、Region写入阶段步骤详解:

    1)获取行锁,HBase中使用行锁保证对同一行数据的更新是互斥操作,用以保证更新的原子性,要么成功要么失败

    2)更新所有待写入keyValue的时间戳为当前系统时间

    3)对一次写入同一个Region的一个或多个KeyValue构建一条WALEdit记录,这样做的目的是保证Region级别事务的写入原子性

    4)把WALEdit写入HLog,HLog是存储在HDFS上需要sync操作把HLog真正落地到HDFS,在这一部暂时不用执行sync,HBase使用了disruptor实现了高效的生产者消费者队列,来异步实现WAL的追加写入操纵

    5)写入WAL之后再将数据写入MemStore

    6)释放行锁

    7)sync WAL:将HLog真正sync到HDFS,如果sync失败,执行回滚操作将MemStore数据移除

    8)结束写事务。更新对外可见,更新生效

    1.5、MemStore Flush阶段详解:

    1.5.1、触发flush条件

    1.5.1.1、MemStore级别限制,当Rgion中任意一个MemStore大小达到阈值(hbase.hrgion.memstore.flush.size)默认128M

    1.5.1.2、Region级别限制:当Region所有MemStore的大小达到了上限(hbase.hregion.memstore.block.multiplier * hbase.hrgion.memstore.flush.size)超过memstore大小的倍数达到该值则阻塞所有写入请求进行flush,自我保护默认是2.

    1.5.1.3、RegionServer级别限制:当RS中MemStore的总大小超过低水位阈值hbase.regionserver.global.memstore.size.lower.limit * hbase.reagionserver.global.memstore.size RS则开始强制执行flush,按Region中MemStore大小从大到小进行flush,直到总MemStore大小下降到低水位。

    1.5.1.4、当一个RegionServer中HLog数量达到一定上限(hbase.regionserver.maxlogs),系统选择最早的HLog对应的Rgion进行Flush

    1.5.1.5、HBase定期Flush,默认是1小时确保MemStore不会长时间没有持久化。为了避免同一时间所有都进行flush,定期的flush操作有一定时间的随机延迟

    1.5.1.6、手动flush,用户可以通过flush 'tablename'或者 flush 'regionname'对一个表或者Region进行flush

    1.5.2、flush执行步骤

    1.5.2.1、prepare阶段

    遍历当前region下的MemStore做一个快照,然后新一个ConcurrentSkipListMap接受新的数据请求。此阶段需要通过锁来阻塞写请求,结束后释放锁,此过程持锁时间很短

    1.5.2.2、flush阶段

    对快照数据按照特定格式生成HFile持久化为临时文件放在.tmp目录下。这个过程涉及到磁盘IO操作,相对比较耗时

    1.5.2.3、commit阶段

    把临时文件移动到指定的CF目录下。再清空快照数据。

    1.5.3、MemStore Flush对业务的影响

    1.5.3.1、大部分MemStore Flush操作都不会对业务读写产生太大影响,

    1.5.3.2、Region Server级别呆滞的flush,会对用户请求产生较大影响,会阻塞落在该RS上的写入操作。

    1.6、HLog写入模型

    1.6.1、HLog持久化级别

    SKIP_WAL:只写缓存,不写HLog,不可取

    ASYNC_WAL:异步写入HLog

    SYNC_WAL:同步写入日志文件,数据只是被写入文件系统缓存中并没有真正落盘。默认是此级别

    FSYNC_WAL:同步将数据写入日志文件并强制落盘,这是最严格的写入级别,保证数据不丢失,性能相对较差

    USER_DEFAULT:如果用户没有指定持久化级别,默认HBase使用SYN_WAL等级持久化数据put.setDurability(Durability.SYNC_WAL);

    1.6.2、HLog写入模型

    1、HLog写入需要经过3个阶段:手写将数据写入本地缓存,然后将本地缓存写入文件系统,最后执行syn操作同步到磁盘

    2、HBase使用LMAX Disruptor框架实现了无锁有界队列操作,写入模型如下图

    2、BulkLoad 流程

    2.1、BulkLoad使用场景:用户数据位于HDFS中,业务需要定期将这部分海量数据导入HBase系统.

    2.2、核心流程分两步

    2.2.1、HFile生成阶段:运行一个MapReduce任务,map需要自己实现,将HDFS文件中的数据读取出来组装一个复合KV,其中Key是rowkey,Value可以是KeyValue对象、Put对象甚至Delete对象;reduce由HBase负责,他会根据表信息配置一个全局有序的partitioner,将partitioner文件上传到HDFS集群,设置reduce task个数为目标表的Region个数。为每个Region生成一个对应的HFile文件

    2.2.2、HFile导入阶段:HFile主备就绪后,将HFile加载到在线集群。

    2.3、Bulkload遇到的一些常见问题

    2.3.1、设置正确的权限

    2.3.1、BulkLoad操作过程涉及到的用户:

    第一步,通过MapReduce任务生成HFile。假设这个过程使用的HDFS账号为:u_mapreduce.

    第二步,将HFile加载到HBase集群,假设这个步骤使用的账号为:u_load。

    一般地:HBase集群由一个专门的账号用来管理HBase数据,该账号拥有HBase集群的所有表的最高权限,

    同时可以读写HBase root目录下的所有文件,假设这个账号为:hbase_srv

    2.3.2、权限设置

    2.3.2.1、通过MapReduce任务生成HFile,HFile文件的owner为u_mapreduce。

    2.3.2.2、u_load需要HFile文件以及目录的读、写权限。写的权限是因为在HFile跨越多个Region时,需要对HFile进行split操作。

    另外u_load账号需要HBase表的Create权限

    2.3.2.3、hbase_srv账号把HFile文件从用户的数据目录rename到HBase的数据目录,所以hbase_sHrv需要有用户数据目录及HFile的读取

    权限,但事实上仅读取权限还不够,应为加载到HBase数据目录的HFile目录的owner仍为u_mapreduce。一旦执行完compaction操作

    之后,这些文件无法挪动到archive目录,导致文件越来越多。这个问题在HBase 2.x 上修复。

    2.3.2、影响Locality

    如果生成HFile都在的HDFS集群和HBase所在HDFS集群时同一个,则MapReduce生成HFile,能够保证HFile与目标Region落在同一个机器上。这样就保证了Locality。由hbase.bulkload.locality.sensitive.enabled的参数控制整个逻辑,默认是true.所以默认保证locality的。

    如果用户MapReduce在A集群上生成HFile,通过distcp拷贝到集群B.这样BulkLoad到HBase集群数据是没法保证Locality的。需要跑完BulkLoad之后再手动执行major compact,来提升loaclity。

    2.3.3、BulkLoad数据复制

    在1.3之前版本中,BulkLoad到HBase集群的数据并不会复制到备集群,这样可能无意识的导致备集群比主集群少了很多数据。在HBase1.3版本之后开始支持BulkLoad数据复制。需要开启开关:hbase.replicatition.bulkload.enabled=true。

    相关文章

      网友评论

        本文标题:六、HBase写入流程

        本文链接:https://www.haomeiwen.com/subject/psggactx.html