FusionInsight HD 6513升级 FusionInsight HD 6517版本，是否支持部分组件在线升级，其他组件离线升级？

线下HD 6517版本集群，业务客户端到集群之前的端口22禁用对使用上有没有影响？

线下HD 6517版本 ，扩容hbase是否可以只扩容一台？

habse 每次写入提交的条数多少条合适？为什么？

下载客户端，执行hbase shell后报 insuffcient permissions

【问题现象】客户测业务发现使用PrefixFilter前缀过滤查询条件时，查询时间达到50多秒。【问题分析】首先了解到客户的rowkey设计为活动编号后两位|活动编号|用户openid|回馈编号，其中用户openid有两种数据，1、客户编号（18位表名为数字），2、openid28位字符。客户侧测试发现以13分区开头的 28位openid为rowkey前缀查询时会花费50多s，但是以18位客户换号查询却很快。经过分析，客户在hbase shell里面查询时，查询慢的前缀每次会连接多个regionserver，通过打开客户端debug日志，发现在连接19region分区时从09:42:20，一直到09:43:15才结束，这个过程耗费了55s左右。通过查看13和19分区的region大小，发现19分区数据有1.9G左右，数据量比较大。scan扫描规则说明：1) 查询一个region不为空，会扫描到下一个region。2) 扫描到下一个region时，碰到比28位短的，会触发开源单，会继续扫描。3) region为空会继续继续扫描。4) 直到扫描到一个28位的后缀，并且没有匹配到数据的时候扫描会结束。流程具体说明：scan流程中结束scan的标志位为moreResults = false，那么就要求 isFilterDone与result.empty都为true的时候，moreResults才会被置为false，其中isFilterDone表示查询的region是否完成了Filter操作，result.empty表示该region查询结果是否为空。例如：在查询13Region的时候，由于匹配到数据了，那么result.isEmpty=false,isFilterDone=true，则moreResults = true表示还有更多数据，所以会继续扫描到下一个14Region。扫描14Region时，由于数据都是15位，所以触发了开源单 https://issues.apache.org/jira/browse/HBASE-14397单中的现象，由于length​​【解决方案】使用setRowPrefixFilter与setStartRow来代替PrefixFilter，RowPrefixFilter会自动精确计算endrow，会让查询在starrow与endrow的范围内进行查询。效率会有较大提升。 复制【机制说明】prefixFilter原理：当prefixFilter比rowkey短的情况下，以PrefixFilter(“333”)为例，需要返回的是rowkey以“333”为前缀的数据。实际的扫描流程如图所示：碰到rowkey=111的行时，发现111比前缀333小，因此直接跳过111这一行去扫下一行，返回状态码NEXT_ROW；下一个Cell的rowkey=222，仍然比前缀333小，因此继续扫下一行，返回状态NEXT_ROW；下一个Cell的rowkey=333，前缀和333匹配，返回column=f:ddd这个cell个用户，返回状态码为INCLUDE；下一个Cell的rowkey仍为333，前缀和333匹配，返回column=f:eee这个cell给用户，返回状态码为INCLUDE；下一个Cell的rowkey为444，前缀比333大，不再继续扫描数据。RowPrefixFilter原理:RowprefixFilter在使用时，设置了startrow，那么在源码中会自动计算一个精确的字典序的endrow，结果就是prefixFilter在查询时只扫描了startrow和endrow这一区间内的数据，会大大降低查询时间。

HBase全部案例集合见维护宝典：https://support.huawei.com/hedex/hdx.do?docid=EDOC1100222546&lang=zh&idPath=22658044|22662728|22666212|22396131（FusionInsight HD&MRS租户面集群故障案例（6.5.X-8.X）->维护故障类->hbase->常见故障）HBase日志说明：cid:link_16HBase经典案例、总结、重大问题见下表：经典案例分类序号案例(点击标题查看详情)出现频次读写异常1-1dn进程处于tl或者D状态导致regionserver查询超时报错★★★★★1-2应用进程多用户认证或者频繁认证导致业务读写异常★★★★☆1-3Regionserver端Region too Busy导致读写异常★★★1-4业务侧直接内存过小导致读写报错★★★1-5 sssd服务异常导致HBase查询业务失败★★★★1-6本地副本损坏导致读写报错（HBase开源bug）★★★1-7应用端full gc导致查询报错★★1-8 hbase put与scan 超时报错operationTimeout1-9 读写数据业务侧报IOExceptions to xxx regionserver读写慢2-1应用端或者服务端存在DNS导致读写慢★★★★2-2HBase connection非单例模式导致读数据慢★★★2-3服务端网络或者慢盘引起wal写入慢，导致HBase写入慢 ★★★★★2-4应用端网络异常导致应用写数据耗时较长★★★2-5Regionserver gc参数未按照最优生效导致性能较差★★★2-6连接池设置较小导致应用读写慢★★★2-7 应用使用Filter触发全表扫描导致查询慢★★★2-8业务频繁调用count，导致HBase 读写慢★★★2-9 spark任务写入hbase慢hbase服务不可用3-1zookeeper频繁Full GC导致hbase服务不可用★★★★3-2meta表或者namespace表所在节点regionserver重启导致hbase服务不可用★★★★3-3ldap负载过高导致hbase检查报服务不可用★★3-4健康检查脚本执行错误（Nodeagent   gc、OS内存不足、无法分配线程等）报服务不可用★★★运行中异常自动重启4-1磁盘慢或者磁盘坏道导致regionserver写wal超过300s，触发重启★★★★★4-2regionserver与hmaster节点时间差超过30s，导致regionserver异常重启★★★4-3hbase表配置ZSTD压缩算法触发jdk   bug，regionserver异常重启★★★4-4ARM jdk bug导致regionserver异常重启★★4-5节点上配置了DNS导致regionserver异常重启★★★4-6内存配置不合理导致regionserver jvm pause   超过90s导致rs异常重启★★★4-7健康检查脚本执行错误（Nodeagent   gc、OS内存不足、无法分配线程等）认为regionserver不正常导致regionserver异常重启★★★4-8 传输大文件导致HMaster健康检查超时重启4-9 NullPointerException导致RegionServer重启4-10 协处理器jar包未放置正确位置，导致RegionServer重启4-11 ZooKeeper实例Full GC导致RegionServer异常重启人为重启出现异常5-1Region上线慢导致HBase启动超时★★★5-2/hbase/MasterProcWALs目录下文件过多导致HBase启动失败★★5-3RS启动失败，报Distribute keytab failed5-4jdk bug 30~32G   导致regionserver或者Hmaster启动异常★★★5-5WAL日志分裂异常导致HBase启动超时★★★5-6 启动集群后region上线很慢hbase mr6-1region 状态异常导致bulkload导数据报Wrong   number of partitions in keyset★★★6-2bulkload AM FULL   GC导致MapReduce执行慢★★HBase gc7-1 业务读写热点造成regionserver 频发gc★★★★★7-2频繁调用Getclusterstatus接口导致Hmaster   FULL GC★★★7-3Phoenix内存泄露导致regionserver频繁FULL   GC★★★7-4 业务侧数据读取设置不合理导致RegionSever Full GC注：论坛帖子部分案例图片上传异常，案例分帖子和博客两种方式发布。

FusionInsight HD 默认使用的鉴权方式为SimpleAclAuthorizer 鉴权原理如下图：鉴权的顺序是按照: 用户-用户组-角色的顺序进行鉴权，假设在鉴权过程中，用户和用户组没有权限但是角色有权限，那么在kafka的鉴权过程中会出现“用户鉴权失败-用户组鉴权失败-角色鉴权成功”这样的流程举例如下：（1）其中user为kafka用户，roles为kafka用户所包含的角色，User group为kafka用户在的用户组。（2）当roles中包含了对应topic的读、写权限后可以正常向对应的topic发送接收数据。并且通过kafka后台命令能够看到topic对应的权限信息。例如：角色（roles） lcrole加入了Topic：test的读写权限，则在后台客户端通过kafka的权限命令能够显示lcrole的所有权限。当权限授予用户user后，便具备了test的读写功能。（3）当user再次加入其它user group组后，相当于user拥有了一个Role：usergroup的角色，在后续生产消费的鉴权过程中Role：usergroup也会参与到topic的鉴权中。例如：在添加用户（user）：lckafka，在用户组中加入了创建的用户者组（Usergroup）test2。这样用户具备了用户组test2，和角色lcrole，其中test2不具备topic：test的读写功能。如下图：这样在发送数据过程中会同时出现以下两种情况：用户lckafka因角色lcrole具备topic：test的读写权限，可以正常生产数据。如下图：用户组test2，不具备topic：test的读写权限，会频繁报鉴权拒绝的日志。（4） 如果集群中存在大量用户和topic出现以上叙述的情况，kafka集群的调度线程会忙于处理鉴权失败的过程。正常生产消费的请求会无法及时处理，从而导致kafka集群整体的读写性能下降。排查方法：排查kafka的kafka-authorizer.log（/var/log/Bigdata/kafka/broker/kafka-authorizer.log）日志的打印数量和日志中的打印频率，如果通过tail –f 查看到的日志刷新频率非常高（每秒上百条）。解决方案：(1) 建议使用后台用户鉴权，使用kafka-acl.sh 命令直接为用户名赋权(2) 如果用户已经使用后台用户鉴权的方式，仍然在日志中存在大量的错误鉴权信息，此时，可以用如下命令排查错误的鉴权信息的用户名和topic对应关系：在broker所在节点的/var/log/Bigdata/kafka/broker目录下执行如下命令:zgrep "Denied" ./kafka-authorizer.* | awk '{print $10" "$19" "$23}' | sort | uniq -c | sort -n结果如下：1表示被拒绝的用户或者角色。2.表示哪个被拒绝的客户端ip。 3.表示没有权限的topic或者group组等。（3）建议业务整改，使用“单业务，单用户”，删除无用的用户的数量

推荐学习顺序：请知：编号顺序相同的可并行学习；知识图谱：课程链接：组件名称组件介绍链接Manager华为FusionInsight HD是一个分布式数据处理系统，对外提供大容量的数据存储、查询和分析能力基础知识安装教程运维知识HBaseHBase是一个开源的非关系型分布式数据库（NoSQL），它参考了谷歌的BigTable建模，实现的编程语言为 Java。它是Apache软件基金会的Hadoop项目的一部分，运行于HDFS文件系统之上，为 Hadoop 提供类似于BigTable 规模的服务。基础串讲+运维知识最佳实践KafkaKafka是由Apache软件基金会开发的一个开源流处理平台，由Scala和Java编写。 该项目的目标是为处理实时数据提供一个统一、高吞吐、低延迟的平台。基础串讲+运维知识最佳实践HiveHive 是一个架构在 Hadoop 之上的数据仓库基础工具，它可以处理结构化和半结构化数据，它使得查询和分析存储在 Hadoop 上的数据变得非常方便基础串讲+运维知识最佳实践SparkApache Spark 是一种用于大数据工作负载的分布式开源处理系统。它使用内存中缓存和优化的查询执行方式，可针对任何规模的数据进行快速分析查询。基础串讲+运维知识最佳实践FlinkApache Flink 是一个框架和分布式处理引擎，用于在无边界和有边界数据流上进行有状态的计算。Flink 能在所有常见集群环境中运行，并能以内存速度和任意规模进行计算。基础串讲+运维知识最佳实践

1      HBase基础架构Active HMaster：主要负责表级别的操作、Region状态管理和RegionSerevr宕机处理。Standby HMaster：当主HMaster故障时，备HMaster将取代主用HMaster对外提供服务。故障恢复后，原主用HMaster降为备用。RegionServer：主要负责维护分配给自己的Region，并响应用户的读写请求。Client：与HMaster进行管理类通信，与RegionServer进行数据操作类通信，Client从zk中获取主HMaster的信息。Region：表按照一定的rowkey范围划分的区域。WAL：HBase预写日志，RegionSever异常宕机时通过回放WAL恢复内存中写入的数据。Store：一个ColumnFamily对应一个Store，一个Region至少有一个Store，一个Store包含一个Memstore和多个StoreFile。MemStore：HBase数据写入时先写入MemStore（内存）中，当MemStore达到一定大小会将数据flush至HDFS保存。StoreFile：MemStore中的数据写到文件后就是StoreFile，StoreFile实际存储在HDFS上。依赖服务：ZooKeeper：RegionServer将自己的信息注册到zk中，主HMaster据此感知各个RegionServer的健康状态，zk对HMaster进行升主管理。HDFS：为HBase提供高可靠的文件存储服务，HBase的数据全部存储在HDFS中。2      HBase启动流程图Controller：Manager的控制中心，负责汇聚来自集群中所有节点的信息，统一向管理员展示，以及负责接收来自管理员的操作指令，并且依据操作指令所影响的范围，向集群的所有相关节点同步信息。Agent：Controller从节点，相当于Controller的代理节点，集群中的每个节点都会部署Agent，直接和集群交互，负责节点心跳上报，以及controller层在业务控制过程中下发的任务实施，包括监控数据采集、告警信息采集、执行向导命令和生成配置等。3      MRS页面HBase启动流程3.1      MRS页面发起HBase服务启动或重启命令3.2      启动步骤步骤1 校验请求参数：Controller接收并转发WS的请求，NodeAgent接收并实施controller下发的任务步骤2 启动服务：调用HBase服务适配脚本启动服务步骤3 持久化集群数据 3.3      Controller接收并转发Web Service的请求MRS对社区hbase的脚本进行了封装，使用components.xml记录封装脚本的路径。controller启动时加载配置目录中的components.xml文件，当用户请求启动命令时，controller解析components.xml的start命令，然后controller将该命令分发给每一个NodeAgent，NodeAgent调用相应脚本执行启动命令。components.xml文件内容： 日志所在节点：主oms节点，如下面截图日志路径：/var/log/Bigdata/controller/controller.log日志内容：[pool-3-thread-33] Service start/stop/restart command execution started for Component [name=HBase, componengName=HBase, dispalyName=HBase, componentId=FusionInsight_HD_8.0.2.1_HBase, description=HBase - distributed, versioned, non-relational database.。日志说明：Service start/stop/restart command是整合服务的启停请求， execution 后跟本次具体的操作started 是启动、 stop 停止，restart是重启，对应服务name=HBase。3.4      NodeAgent接收并实施controller下发的任务日志所在节点：HBase服务实例所在节点日志路径：/var/log/Bigdata/nodeagent/agentlog/agent.log日志内容：2021-08-11 09:34:43,528 INFO  [Thread-41] Received Actions from controller. actions:[Action [id=773, type=PROCESS_START, script=null, timeout=0, randomIdentification=1098665817, clusterId=1, serviceId=14, roleName=HMaster, configGroupsList=0, scriptArgs=[], actionArgs keys=[extra_env_vars, CommandOptionType, ProcessInfo] actionArgs values=[Value(str:{"OM_ONLINE_TYPE":"NORMAL","OM_ROLLING_TYPE":"NORMAL"}), Value(str:LIFECYCLE), Value(processInfo:ProcessInfo [processType=SERVICE, startScript=/opt/huawei/Bigdata/FusionInsight_HD_8.0.2.1/install/FusionInsight-HBase-2.2.3/hbase/bin/hbase-daemon-adapter.sh, stopScript=/opt/huawei/Bigdata/FusionInsight_HD_8.0.2.1/install/FusionInsight-HBase-2.2.3/hbase/bin/hbase-daemon-adapter.sh, COMMA_STR=,, startScriptArgs=[start, master], stopScriptArgs=[stop, master], startScriptTimeout=36000000, stopScriptTimeout=36000000, serviceCheckTimeout=30000, serviceCheckTimeoutCount=1, instanceId=61, serviceName=HBase, clusterId=0, componentName=HBase, packName=FusionInsight_HD_8.0.2.1, roleName=HMaster])], metaData={}]] com.huawei.bigdata.om.agent.services.CommandService.addActions(CommandService.java:199)日志说明：Received Actions from controller：接收Controller请求type=PROCESS_START:操作类型启动进程actionArgs values：实例启动时调用的脚本，脚本超时时间等。3.5      调用HBase服务适配脚本启动服务3.5.1        启动regionserver实例RegionServer启动流程：RegionServer日志路径：/var/log/Bigdata/hbase/rs启动异常查看日志：startDetail.log：预启动阶段日志；rolling-restart-prepare.log：滚动重启前检查日志（只有滚动重启出现异常才需要查询看）；hbase-omm-regionserver-$hostname.log：启动后Regionserver运行日志；hbase-omm-regionserver-$hostname.out：启动过程中JVM参数检查日志。RegionServer启动入口日志：Starting regionserver on dggphispre13863STARTING executorService HRegionServer | org.apache.hadoop.hbase.regionserver.HRegionServer.main(HRegionServer.java:3301)Regionsever向主HMaster上报日志：regionserver/dggphispre13863:21302 | reportForDuty to master=dggphispre13864,21300,1628499599587 with port=21302, startcode=1628499573654 | org.apache.hadoop.hbase.regionserver.HRegionServer.reportForDuty(HRegionServer.java:2902)常见异常：RegionServer节点与主HMaster节点时间差超过30s，导致RegionServer启动失败问题现象：RegionServer启动后状态一直为恢复中。日志路径：/var/log/Bigdata/hbase/rs/hbase-omm-regionserver-$hostname.log排查步骤：登录故障实例节点后台，查看RegionServer运行日志，在日志中搜索clock is out of sync关键字。异常日志：2021-07-28 09:26:57,000 | ERROR | regionserver/dggphispre13862:21302 | Master rejected startup because clock is out of sync | org.slf4j.helpers.MarkerIgnoringBase.error(MarkerIgnoringBase.java:159)org.apache.hadoop.hbase.ClockOutOfSyncException: org.apache.hadoop.hbase.ClockOutOfSyncException: Server dggphispre13862,21302,1627435609559 has been rejected; Reported time is too far out of sync with master.  Time difference of 40946ms > max allowed of 30000ms处理方法：检查NTP服务，排查节点时间不同步原因，规避方法手动同步节点时间。3.5.2        启动HMaster实例HMaster启动流程： HBase启动过程中最重要的就是HMaster的初始化阶段，finishActiveMasterInitialization(status)方法中主要完成以下操作：1.MasterFileSystem(conf) 初始化MasterFileSystem，如果是第一次启动，meta表不存在需要创建新目录；2.tableDescriptors.getAll() 从hdfs上加载每一个tableDescriptor，建议启动时不加载(hbase.master.preload.tabledescriptors)；3.createProcedureExecutor() 创建procedureExecutor，从masterProcWal中加载proc；4.assignmentManager.start() 启动Assignment Manager，从zk中获取meta表的状态；5.初始化tableStateManager和依赖zk的一些Trackers（balancer、Normalizer、splitOrMergeTracker、replicationPeerManager、metaLocationSyncer、masterAddressSyncer）；6.如果meta表没上线过，提交一个InitMetaProcedure；7.waitForRegionServers等待rs注册到master(有一个rs注册成功就停止等待)；8.waitForMetaOnline，确保meta已上线；9.TableStateManager加载表状态；10.AM上线offline的region；11.初始化ClusterSchema，如果namespace不存在，创建新的namespace，等待namespace上线；HMaster日志路径：/var/log/Bigdata/hbase/hm启动异常查看日志：hbase-omm-master-$hostname.log：启动后HMaster运行日志；hbase-omm-master -$hostname.out：启动过程中JVM参数检查日志。HMaster启动入口日志：Starting master on dggphispre13864STARTING service HMaster | org.apache.hadoop.hbase.master.HMaster.main(HMaster.java:3103)初次启动新建meta表日志：Creating new hbase:meta table descriptor 'hbase:meta'……Updated hbase:meta table descriptor to hdfs://hacluster/hbase/data/hbase/meta/.tabledesc/.tableinfo.0000000001 | org.apache.hadoop.hbase.util.FSTableDescriptors.tryUpdateMetaTableDescriptor(FSTableDescriptors.java:167)主HMaster注册成功日志：master/dggphispre13864:21300:becomeActiveMaster | Registered as active master=dggphispre13864,21300,1628645694682初次启动主HMaster创建meta表region日志：master/dggphispre13864:21300:becomeActiveMaster | BOOTSTRAP: creating hbase:meta region | org.apache.hadoop.hbase.master.MasterFileSystem.bootstrap(MasterFileSystem.java:398)加载MasterProcWal日志：master/dggphispre13864:21300:becomeActiveMaster | Recover lease on dfs file hdfs://hacluster/hbase/MasterProcWALs/pv2-00000000000000000126.logWAl回放日志：PEWorker-1 | Splitting WALs pid=3, state=RUNNABLE:SERVER_CRASH_SPLIT_META_LOGS, locked=true; ServerCrashProcedure dggphispre13862,21302,1628499570465, splitWal=true, meta=true, isMeta: truePEWorker-1 | hdfs://hacluster/hbase/WALs/dggphispre13862,21302,1628499570465-splitting dir is empty, no logs to split.等待RegionServer上报日志：master/dggphispre13864:21300:becomeActiveMaster | Waiting on regionserver count=0; waited=1506ms, expecting min=1 server(s), max=NO_LIMIT server(s), timeout=30000ms, lastChange=-1506ms |master/dggphispre13864:21300:becomeActiveMaster | Waiting on regionserver count=1; waited=1707ms, expecting min=1 server(s), max=NO_LIMIT server(s), timeout=30000ms, lastChange=0ms |meta表region上线日志：PEWorker-12 | Initialized subprocedures=[{pid=5, ppid=4, state=RUNNABLE; OpenRegionProcedure 1588230740, server=dggphispre13864,21302,1628645665026}] |PEWorker-14 | Finished pid=5, ppid=4, state=SUCCESS; OpenRegionProcedure 1588230740, server=dggphispre13864,21302,1628645665026 in 1.2500secNameSpace表region上线日志PEWorker-17 | Initialized subprocedures=[{pid=7, ppid=3, state=RUNNABLE:REGION_STATE_TRANSITION_GET_ASSIGN_CANDIDATE; TransitRegionStateProcedure table=hbase:namespace, region=b389e94c58639d0dafce0130de447340, ASSIGN}, {pid=8, ppid=3, state=RUNNABLE:REGION_STATE_TRANSITION_GET_ASSIGN_CANDIDATE; TransitRegionStateProcedure table=hbase:rsgroup, region=4c650a01bc6b84b7f851dbb762461338, ASSIGN}] |PEWorker-9 | Finished pid=12, ppid=7, state=SUCCESS; OpenRegionProcedure b389e94c58639d0dafce0130de447340, server=dggphispre13862,21302,1628645667276 in 838msec |用户表region上线日志：PEWorker-9 | Initialized subprocedures=[{pid=6, ppid=2, state=RUNNABLE:REGION_STATE_TRANSITION_GET_ASSIGN_CANDIDATE; TransitRegionStateProcedure table=hbase_sample_table, region=89c5bc58a048edf469d1cdaa59e3cb8e, ASSIGN}] |PEWorker-6 | Finished pid=17, ppid=6, state=SUCCESS; OpenRegionProcedure 89c5bc58a048edf469d1cdaa59e3cb8e, server=dggphispre13864,21302,1628645665026 in 393msec |常见异常：meta表异常导致HBase启动失败问题现象：HBase启动过程中Manager页面报错HMaster RoleInstance validity check failure[2021-07-29 10:03:53]Check validity of roleInstance for HBase#HMaster#10.244.199.137@dggphispre13864.[2021-07-29 10:04:10]RoleInstance validity check failure日志路径：/var/log/Bigdata/hbase/hm/hbase-omm-master-$hostname.log排查步骤：先登录主HMaster实例节点后台，查看HMaster运行日志，在HMaster日志中搜索hbase:meta关键字，找到meta表上线日志打印，根据meta表上线的异常日志打印内容找到meta表被分配的RegionServer节点，再登录对应的RegionServer节点检查RegionServer运行日志，在日志中搜索hbase:meta关键字，查看具体上线失败的原因。异常日志：主HMaster实例运行日志中meta表上线异常日志打印：2021-07-29 11:26:49,439 | INFO  | org.apache.hadoop.hbase.rsgroup.RSGroupInfoManagerImpl$RSGroupStartupWorker-dggphispre13864,21300,1627529093971 | Call exception, tries=14, retries=106, started=108950 ms ago, cancelled=false, msg=org.apache.hadoop.hbase.NotServingRegionException: hbase:meta,,1 is not online on dggphispre13864,21302,1627529064253RegionSever中Meta上线失败的异常日志：2021-07-29 11:27:18,234 | WARN  | RS_CLOSE_META-regionserver/dggphispre13864:21302-0 | Failed to open region hbase:meta,,1.1588230740, will report to master | org.apache.hadoop.hbase.regionserver.handler.AssignRegionHandler.cleanUpAndReportFailure(AssignRegionHandler.java:88)java.io.IOException: java.io.IOException: org.apache.hadoop.hbase.io.hfile.CorruptHFileException: Problem reading HFile Trailer from file hdfs://hacluster/hbase/data/hbase/meta/1588230740/info/e2a4f54c2e5b41f384d067f5d4a22616处理办法：停止HBase服务，offlinemetarepair修复meta表，启动Hbase服务。offlinemetarepair修复meta表步骤：source /opt/hadoopclient/bigdata_envkinit hbaseexport HBASE_CLASSPATH=${HBASE_CLASSPATH}:/opt/hadoopclient/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-302022.jarhbase org.apache.hbase.hbck1.OfflineMetaRepairnamespace表描述信息丢失导致HBase启动异常问题现象：HBase启动过程中Manager页面报错HMaster RoleInstance validity check failure[2021-07-29 10:03:53]Check validity of roleInstance for HBase#HMaster#10.244.199.137@dggphispre13864.[2021-07-29 10:04:10]RoleInstance validity check failure日志路径：/var/log/Bigdata/hbase/hm/hbase-omm-master-$hostname.log排查步骤：先登录主HMaster实例节点后台，查看HMaster运行日志，在HMaster日志中搜索hbase:namespace关键字，找到namespace表上线日志打印，根据namespace表上线日志打印内容找到namespace表被分配的RegionServer节点，再登录对应的RegionServer节点检查RegionServer运行日志，在日志中搜索hbase: namespace关键字，查看具体上线失败的原因。异常日志：2021-07-29 10:07:44,579 | INFO  | PEWorker-2 | Finished pid=46, ppid=14, state=SUCCESS; OpenRegionProcedure 5bfdcf0b05a5ac239e41f398de698ff5, server=dggphispre13864,21302,1627524137057 in 282msec |2021-07-29 10:07:44,579 | WARN  | PEWorker-17 | Failed transition, suspend 256secs pid=14, ppid=3, state=RUNNABLE:REGION_STATE_TRANSITION_GET_ASSIGN_CANDIDATE, locked=true; TransitRegionStateProcedure table=hbase:namespace, region=5bfdcf0b05a5ac239e41f398de698ff5, ASSIGN; rit=OPENING, location=null; waiting on rectified condition fixed by other Procedure or operator intervention | org.apache.hadoop.hbase.master.assignment.TransitRegionStateProcedure.executeFromState(TransitRegionStateProcedure.java:388)org.apache.hadoop.hbase.HBaseIOException: Failed to open region根据HMaster日志中namespace表region上线的regionserver打印，检查对应regionserver的日志：2021-07-29 10:12:00,956 | WARN  | RS_OPEN_PRIORITY_REGION-regionserver/dggphispre13863:21302-1 | Failed to open region hbase:namespace,,1618559757090.5bfdcf0b05a5ac239e41f398de698ff5., will report to master | org.apache.hadoop.hbase.regionserver.handler.AssignRegionHandler.cleanUpAndReportFailure(AssignRegionHandler.java:88)java.io.IOException: Missing table descriptor for hbase:namespace,,1618559757090.5bfdcf0b05a5ac239e41f398de698ff5.2021-07-29 10:12:11,156 | INFO  | hconnection-0x9d86456-shared-pool5-t11 | Unable to get remote Address | org.apache.ranger.authorization.hbase.RangerAuthorizationCoprocessor.getRemoteAddress(RangerAuthorizationCoprocessor.java:214)处理办法：从相同版本集群复制一份namespace表描述文件/hbase/data/hbase/namespace/.tabledesc/.tableinfo.0000000001，重启HBase服务。4      HBase日志收集4.1      Manager页面日志收集运维—>日志—>下载—>服务—>HBase—>主机（不选择默认下载HBase所有实例的日志）—>选择日志下载时间段—>下载日志说明：HMaster：HMaster启停日志、运行日志、GC日志、健康检查日志；HMAudit：HMaster审计日志；RegionServer(RegionServer_*)：RegionServer启停日志、运行日志、GC日志、健康检查日志；RSAudit：RegionServer审计日志；ThriftServer(Thrift1Server): ThriftServer启停日志、运行日志、GC日志、健康检查日志；TSAudit：ThriftServer审计日志；RESTServer: RESTServer启停日志、运行日志、GC日志、健康检查日志；RTAudit：RESTServer审计日志。4.2      实例后台日志收集HBase运行日志：日志路径：/var/log/Bigdata/hbase/<process_name>/               <process_name>包括：hm、rs、rt、ts；hbase-omm-<process_name>-<hostname>.log：实例运行日志；hbase-omm-<process_name>-<hostname>.out：实例启动时JVM参数检查日志；<process_name>-omm--<DATE>-<PID>-gc.log：实例GC日志；checkServiceDetail.log：服务健康检查结果日志；hbase.log：健康检查脚本以及部分告警检查脚本执行日志；sendAlarm.log：告警检查脚本上报告警信息日志；hbase-haCheck.log：HMaster主备状态检测日志；stop.log：实例进程启停操作日志。startDetail.log：预启动阶段日志；rolling-restart-prepare.log：滚动重启前检查日志；HBase安全审计日志: /var/log/Bigdata/audit/hbase/<process_name>/hbase-audit-<process_name>.log；

HBase HBCK运维指南HBase HBCK是HBase运维人员经常会用到的一个HBase运维工具，主要是用于检查HBase region等元数据一致性以及修复的工具。目前HBCK工具有两个版本，本次主要介绍用于HBase 2.x内核版本的HBCK2。后面提到的HBCK都是HBCK2，如果涉及HBCK1会单独说明。两个版本的HBCK工具在设计上已经发生的非常大的变化，在使用方式上也有比较大的差异，两个版本的工具只能使用在对应的内核版本上，无法混用。如何进行检查？HBCK2跟HBCK1比较，最大的变化就是HBCK2的检查是在HMaster上运行的，HBCK1是运行在客户端的。HBCK检查主要包含两部分：HBCK Chore Report和CatalogJanitor Consistency Issues Report 。HBCK Chore Report：主要检查HMaster内存，RegionServer内存，HDFS三个地方的region信息的一致性，包括region是否存在，region的deploy信息是否一致。由于检查的顺序是HMaster内存(meta表)->RS->HDFS，所以如果meta表region信息不存在，该检查是不会检查出来异常。该report默认1小时会刷新一次，刷新周期通过参数hbase.master.hbck.chore.interval，参数值<=0时此功能被禁用。用户也可以手动在hbase shell执行hbck_chore_run来触发。CatalogJanitor Consistency Issues Report：主要检查meta表中的region信息是否完整，是否存在overlpad，hole问题。该report默认300s会刷新一次，刷新周期通过参数hbase.catalogjanitor.interval。用户也可以手动在hbase shell执行catalogjanitor_run来触发。catalogjanitor_switch可以用来开启/关闭此功能。如何查看报告进入HMaster页面，选择HBCK Report页签查看report。由于report是异步生成，执行命令后，可能需要等待一段时间才能看到结果。HBCK2使用说明：HBCK2的工具类文件默认不在HBase客户端的classpath下，需要手动指定才能使用。使用说明以HBase客户端安装目录为/opt/client，使用的jar版本号为hbase-hbck2-2.2.3-hw-ei-xxxxx.jar为例，实际使用时请以当前的环境信息为准。hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar COMMAND ARGS   其中COMMAND和ARGS参考下面的参数说明。关于权限，HBCK2跟HBCK1也有很大的不一样，HBCK2不再要求必须使用用户hbase进行操作，只需要当前用户具备当前操作的权限即可。HBCK2参数(COMMAND)说明：1. setTableState参数说明：设置表的状态。2.x版本开始，HBase的表状态不再记录到zk上，所有表的状态都记录到hbase:meta表的table:state列中(meta表自己除外)。该命令只会将HMaster缓存以及meta表中的状态强制更新为指定状态，不会操作region。支持的表状态：ENABLED，DISABLED，DISABLING，ENABLING。返回值为更新前的状态。使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/ hbase-hbck2-2.2.3-hw-ei-xxxxx.jar  setTableState tableName STATE举例：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar  setTableState testTable DISABLED2. assigns参数说明：assign region，让region重新上线。该命令支持两个可选的参数-o, -i。-o, 指定是否强制覆盖当前的Procedure，不指定的话，会对region的状态进行检查，如果该region有关联的Procedure任务或者region的状态不是CLOSED或OFFLINE，该操作会执行失败；-i, 如果一次需要操作多个region，除了在命令后面指定多个encoded regionname(空格分开)，还可以通过该参数指定一个或多个本地文件，文件内容为encoded regionname(一行一个region)。使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar assigns encodedRegionName1 encodedRegionName2...hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar assigns -i _fileName1 _fileName2...举例：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar assigns de00010733901a05f5a2a3a382e27dd4如果rit的region很多，可以将所有的rit region拷贝到文本文件中。3. bypass参数说明：中止指定的Procedure任务。当一个Procedure任务长时间未结束需要手动停止时，可以使用该命令。执行该操作可能会导致该任务对应的表，region的状态不一致，需要手动修复。如果命令执行成功则返回true，否则返回false。该命令支持可选的参数有：-o, -r, -w。-o, Procedure任务执行时会获取一个IdLock，避免一个任务被多个线程处理。bypass任务时，如果不指定该参数，并且该任务还在运行中，则会导致bypass失败。指定该参数，会强制将任务的bypass标识设置为true。需要注意：如果bypass的Procedure没有父Procedure，也没有子Procedure，则可以直接bypass；如果有父Procedure，则当前Procedure的状态不能为RUNNABLE, WAITTING,WAITTING_TIMEOUT，否则会bypass失败；如果有子Procedure，则参考下面一个参数的说明。-r, 如果指定的Procedure还存在subProcedure，则需要指定该参数，然后会把该任务是所有子任务都先bypass掉，否则指定的Procedure会bypass失败。-w, -o参数中提到的获取IdLock的超时时候，如果没有指定-o的话，会等待获取IdLock直到超过该超时长。默认1ms。使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.1.1.0101-mrs-2.0.jar bypass -r -o PID4. unassigns参数说明：将指定的一个或者多个region下线。该操作会为每一个region创建一个TRSP。该命令支持参数-o，如果不指定该参数，创建TRSP之前，会检查region的状态，需要同时满足三个条件：region状态为OPEN，该表的状态非DISABLED或DISABLING, 该region没有关联的Procedure，否则会执行失败。如果该region已有对应的TRSP，新提交的TRSP任务会等待。创建成功则返回新建TRSP的pid，否则返回-1。该命令只能处理处于OPEN, CLOSING, MERGING, SPLITING状态的region。使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar        unassigns encodedRegionName1 encodedRegionName2...举例：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar unassigns de00010733901a05f5a2a3a382e27dd4 5. setRegionState参数说明：该参数用于强制把meta表中的region状态修改为指定的状态。该参数一般需要配合assigns/unassigns命令使用。因为执行assigns/unassigns命令需要region处于特定的状态，当region状态出现不一致，需要手动干预时，可能需要使用该命令强制将region修改为特定的转改。使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar setRegionState encodedRegionName1 stat支持修改的状态有：OFFLINE, OPENING, OPEN, CLOSING, CLOSED,SPLITTING, SPLIT,FAILED_OPEN, FAILED_CLOSE, MERGING, MERGED, SPLITTING_NEW,MERGING_NEW, ABNORMALLY_CLOSED6.  filesystem参数说明：该参数主要用于修复/hbase目录下的不一致问题，开源版本仅提供了修复损坏的HFile文件，错误的reference，HFileLink文件以及hbase.version文件问题；MRS版本回合了hbck1的部分功能，包括region目录的空洞，重叠，残留的split region目录等问题。该参数支持的选项有：-sidelineCorruptHFiles：检查指定的表(默认全部)是否存在损坏的HFile文件并修复；-fixReferenceFiles：用于检查指定的表(默认全部)是否存在损坏的HFile文件并修复；-fixHFileLinks：用于检查指定的表(默认全部)是否存在异常的Links文件并修复；-fixVersionFile：用于重新生成hbase.version文件；该操作不再要求HBase服务可用；-fix：作用等同于同时指定上面4个参数，该参数为HBCK2开源版本提供的参数，其余参数为MRS特有；-fixHdfsOrphans： 用于检查修复缺失.regioninfo文件的问题。如果该region目录下没有列簇目录或者，无法修复。修复时先从meta表获取该region的数据并重新生成.regioninfo文件，否则从该region下的hfile解析出startkey和endkey并生成.regioninfo文件。如果没有hfile，则删除该region目录，然后需要通过-fixHdfsHoles修复region空洞；-fixHdfsHoles：用于检查和修复region空洞；-fixHdfsOverlaps：用于检查和修复region重叠；-removeParents：如果parent和daughter region同时在线，强制下线parent；-fixSplitParents：如果parent和daugh region部分或者都不在线，需要通过该参数进行修复。如果daughter region的信息没有更新到meta表，则重新将parent region上线，否则尝试将daughter region上线并清理parent region。如果此时Split region的Procedure任务还未结束，默认不执行修复操作。如果Split Procedure任务执行超过一定时间(默认60s)，可以使用-force强制中止该问题。用户还可以使用-timeout修改默认的时间，单位为ms；使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar filesystem -_x t1 t27. replication参数说明：用于检查replication的同步队列里面是否还存在已经移除的peer的数据；如果存在，需要通过-f参数进行删除修复；使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar replication  t18. scheduleRecoveries参数说明：创建一个SCP用来处理指定的ServerName。正常情况下，meta表中记录的region所在的ServerName应该是在线的RegionServer，但是记录的ServerName已经不存在，会导致region一致性的问题，需要通过此命令创建一个SCP来进行恢复。使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar replication -scheduleRecoveries sn1 sn29. fixMeta参数说明：用户修复meta表中存在的region空洞和重叠问题。该操作依赖前面介绍中提到的CatalogJanitor Consistency Issues Report，主要是针对该report中的问题进行修复操作。如果meta表和HDFS目录同时出现空洞，应该先对meta表进行修复；使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar fixMeta10.hbaselistInconsistencies参数说明：使用命令的方式获取前面提到的hbck report。当HMaster的原生页面无法访问时，可以通过此方式来获取report；可以指定参数-run需要重新生成hbck repor。默认返回所有的数据，也可以返回指定表的结果；使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar listInconsistencies -run default:t1 default:t211.reportMissingRegionsInMeta参数说明：检查HDFS和meta表中的region信息，并列出meta表中确实的region信息。需要注意：如果meta表中没有表的state信息，该检查不会对该表进行检查；默认检查所有的表，可以指定一个或者多个namespace或者表，如果是default命名空间下的表，也需要指定命名空间。使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar reportMissingRegionsInMeta namespace1 default:t212.addFsRegionsMissingInMeta参数说明：reportMissingRegionsInMeta只做检查，该参数检查并修复meta表中确实的region信息。必须指定至少一个namespace或者表；修复的region在meta表中的状态为CLOSED，需要手动执行assigns操作让region上线；使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar addFsRegionsMissingInMeta namespace1 default:t213.extraRegionsInMeta参数说明：与reportMissingRegionsInMeta相反，用于检查meta表中多余的region信息。如果需要修复，需要指定参数-fix；使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar extraRegionsInMeta -f namespace1 default:t214.fixRITAssignment参数说明：检查rit超过一定时间的region并尝试修复。该操作只对状态为FAILED_OPEN并且没有关联的TRSP的region有效。执行成功后，会创建一个新的TRSP；使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar fixRITAssignment15.generateMissingTableDescriptorFile参数说明：用于检查修复缺少.tableinfo文件的问题，默认从HMaster的缓存中获取并重新生成.tableinfo文件，如果获取失败，则使用默认的参数生成.tableinfo文件，这样会导致用户设置的参数丢失使用说明：hbase hbck -j /opt/client/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jar generateMissingTableDescriptorFile t1常见问题修复1. disable一个表失败，部分region除以RIT并且表的状态DISABLING。修复方法：bypass掉该表以及region相关的Procedure任务，然后使用setTableState将表的状态置为DISABLED。为了保证region的状态一致，建议重新enable该表后再disalbe一次。2. region处于RIT无法上线。修复方案：bypass掉该region的procedure, 然后根据状态决定使用assigns或者unassigns重新触发TRSP。由于region rit的场景多种多样，实际的修复方案可能需要具体分析。另外，HMaster原生页面的HBCK report里面针对一些异常情况也有修复建议。3. 数据迁移场景下，将表的目录完整拷贝过来后，如何让表上线？允许离线的情况下，先停掉HBase服务，然后使用offlineMetaRepair进行meta表数据的修复，然后启动HBase服务；offlinemetarepair修复meta表步骤：source /opt/hadoopclient/bigdata_envkinit hbaseexport HBASE_CLASSPATH=${HBASE_CLASSPATH}:/opt/hadoopclient/HBase/hbase/tools/hbase-hbck2-2.2.3-hw-ei-xxxxx.jarhbase org.apache.hbase.hbck1.OfflineMetaRepair

1、建表语句：建表语句可以参考下图所示，可以用默认参数建表或者设置某些属性（例如：VERSIONS、TTL），另外建表时候可以预分Region（比如设置SPLITS等）。Create a table with namespace=ns1 and table qualifier=t1  hbase> create 'ns1:t1', {NAME => 'f1', VERSIONS => 5}Create a table with namespace=default and table qualifier=t1  hbase> create 't1', {NAME => 'f1'}, {NAME => 'f2'}, {NAME => 'f3'}  hbase> # The above in shorthand would be the following:  hbase> create 't1', 'f1', 'f2', 'f3'  hbase> create 't1', {NAME => 'f1', VERSIONS => 1, TTL => 2592000, BLOCKCACHE => true}  hbase> create 't1', {NAME => 'f1', CONFIGURATION => {'hbase.hstore.blockingStoreFiles' => '10'}}  hbase> create 't1', {NAME => 'f1', IS_MOB => true, MOB_THRESHOLD => 1000000, MOB_COMPACT_PARTITION_POLICY => 'weekly'}  Table configuration options can be put at the end.Examples:  hbase> create 'ns1:t1', 'f1', SPLITS => ['10', '20', '30', '40']  hbase> create 't1', 'f1', SPLITS => ['10', '20', '30', '40']  hbase> create 't1', 'f1', SPLITS_FILE => 'splits.txt', OWNER => 'johndoe'  hbase> create 't1', {NAME => 'f1', VERSIONS => 5}, METADATA => { 'mykey' => 'myvalue' }  hbase> # Optionally pre-split the table into NUMREGIONS, using  hbase> # SPLITALGO ("HexStringSplit", "UniformSplit" or classname)  hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit'}  hbase> create 't1', 'f1', {NUMREGIONS => 15, SPLITALGO => 'HexStringSplit', REGION_REPLICATION => 2, CONFIGURATION => {'hbase.hregion.scan.loadColumnFamiliesOnDemand' => 'true'}}  hbase> create 't1', {NAME => 'f1', DFS_REPLICATION => 1}You can also keep around a reference to the created table:  hbase> t1 = create 't1', 'f1'2、删表：Here is some help for this command:Drop the named table. Table must first be disabled:  hbase> drop 't1'  hbase> drop 'ns1:t1'  You can sync delete table operation in peer clusters also:  hbase> drop 't1', SYNC_PEER => true  hbase> drop 'ns1:t1', SYNC_PEER => true3、清空表数据：Here is some help for this command:  Disables, drops and recreates the specified table.  hbase> truncate 't1'  You can sync truncate table operation in peer clusters also:  hbase> truncate 't1', SYNC_PEER => true 4、保留分区清空表数据：Here is some help for this command:  Disables, drops and recreates the specified table while still maintaing the previous region boundaries.  hbase> truncate_preserve 't1'  You can sync truncate_preserve table operation in peer clusters also:  hbase> truncate_preserve 't1', SYNC_PEER => true5、Assign/Unassign操作：assign:Here is some help for this command:Assign a region. Use with caution. If region already assigned,this command will do a force reassign. For experts only.Examples:  hbase> assign 'REGIONNAME'  hbase> assign 'ENCODED_REGIONNAME'unassign:Here is some help for this command:Unassign a region. Unassign will close region in current location and thenreopen it again.  Pass 'true' to force the unassignment ('force' will clearall in-memory state in master before the reassign. If results indouble assignment use hbck -fix to resolve. To be used by experts).Use with caution.  For expert use only.  Examples:  hbase> unassign 'REGIONNAME'  hbase> unassign 'REGIONNAME', true  hbase> unassign 'ENCODED_REGIONNAME'  hbase> unassign 'ENCODED_REGIONNAME', true6、split操作：Here is some help for this command:Split entire table or pass a region to split individual region.  With the second parameter, you can specify an explicit split key for the region.  Examples:    split 'tableName'    split 'namespace:tableName'    split 'regionName' # format: 'tableName,startKey,id'    split 'tableName', 'splitKey'    split 'regionName', 'splitKey'7、Merge操作NOTE: You must pass the encoded region name, not the full region name sothis command is a little different from other region operations.  The encodedregion name is the hash suffix on region names: e.g. if the region name wereTestTable,0094429456,1289497600452.527db22f95c8a9e0116f0cc13c680396. thenthe encoded region name portion is 527db22f95c8a9e0116f0cc13c680396Examples:  hbase> merge_region 'ENCODED_REGIONNAME', 'ENCODED_REGIONNAME'  hbase> merge_region 'ENCODED_REGIONNAME', 'ENCODED_REGIONNAME', true8、hbase shell重定向：echo "scan 'hbase:meta'" | hbase shell> out9、查看HFile：hbase org.apache.hadoop.hbase.io.hfile.HFile -v -p -m -f HDSF文件路径10、Bulkload指定：hbase org.apache.hadoop.hbase.mapreduce.ImportTsv -Dimporttsv.bulk.output=/tmp/bulkoutput -Dimporttsv.separator=',' -Dimporttsv.columns=HBASE_ROW_KEY,f:c1,f:c2 testBulkload /tmp/bulkdata hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles </path/for/output> <tablename>11、HBase hbck指令：hbase hbck检查hbase集群是否异常：hbase hbck -details检查并输出详细打印：hbase hbck table1 table2只检查table1、table2表

WALWAL(Write-Ahead-Log)是HBase的RegionServer在处理数据插入和删除的过程中用来记录操作内容的一种日志。大致过程如下图所示，首先客户端启动一个操作来修改数据，每一个修改都封装到KeyValue对象实例中，并通过RPC调用发送到含有匹配Region的HRegionServer。一旦KeyValue到达，它们就会被发送管理相应行的HRegion实例。数据被写到WAL，然后被放入到实际拥有记录的存储文件的MemStore中。同时还会检查MemStore是否满了，如果满了就会被刷写到磁盘中去。Hlog上图表示了3个不同的region，每一个负责一段rowkey的范围。这些region将共享同一个HLog实例，从不同region来的数据写入WAL的顺序是不确定的。HLogKeyWAL使用Hadoop的SequenceFile,它将记录存储为key/values 的数据集。对于WAL，key是一个HLogKey的实例。KeyValue包括row, column family, qualifier, timestamp, value以及Key Type，Key Type可以标识一个“put”或“delete”操作。wal调用链源码分析基本调用过程如下1、首先client端先把put/delete等api操作封装成List<MutationProto>，然后使用protobuf协议使用rpc服务发送到对应的HRegionServer，HRegionServer调用execRegionServerService()方法解析发送过来的protobuf协议二进制包，通过serviceName找到相应的service并调用callMethod方法执行：2、put/delet等“写”操作会使用MultiRowMutationService这个service来作用，在service中将会调用mutateRows()方法去处理List<MutationProto>，真正调用mutateRows()的是MultiRowMutationService的一个实现类MultiRowMutationEndpoint，MultiRowMutationEndpoint类实现了hbase的行事务。从MultiRowMutationEndpoint类文档可以看出其主要作用:3、在HRegion类中mutateRowsWithLocks方法查看有没执行器(RowProcessor)，如果没有则创建一个再调用processRowsWithLocks()方法。processRowsWithLocks方法是整个“写”操作最核心的方法：把写wal,刷wal以及写memstore流程都在这里流转。在这里包括异常处理一共有12步之多。原型如下：在HRegion类中重写。写WAL日志关键步骤如下：3、doWALAppend()这里HRegion会把封装好的WALEdit使用FSHLog的append方法追加到日志文件，但是由于文件本身在内存中有缓存的原因，还需要调用sync刷入磁盘。这里只是把WALEdit数据放到一个LMAX Disrutpor RingBuffer中。这个RingBuffer是一个线程安全的消息队列，在wal中主要用于有效且安全的协调多个生产者一个消费者模型。其中多个生产者就是这个append方法，将会有很多client产生数据都放到这个消息队列中，但是只有一个消费者从这个队列中取数据并调用sync方法把数据从缓存刷到磁盘，这样能保证WAL日志并发写入时日志的全局唯一顺序。在这步中会调用sync()方法，除了isMetaRegion，sync()将根据client设置的持久化等级选择是否调用wal（FSHLog）的sync方法如代码中所示当前sync_wal和fsync_wal采用的是同一策略都是：调用HFLog的sync()方法。sync()是一个阻塞方法，需要等到数据真正的刷到磁盘后，便会唤醒它，然后工作线程返回写入memstore，完成一次“写”操作。Hbase WAL 线程模型源码分析其线程模型主要实现实在FSHLog中，FSHLog是WAL接口的实现类，实现了最关键的apend()和sync()方法，其模型如图所示：这个图主要描述了HRegion中调用append和sync后,hbase的wal线程流转模型。最左边是有多个client提交到HRegion的append和sync操作。当调用append后WALEdit和WALKey会被封装成FSWALEntry类进而再封装成RingBufferTruck类放入一个线程安全的Buffer(LMAX Disruptor RingBuffer)中。当调用sync后会生成一个SyncFuture进而封装成RingBufferTruck类同样放入这个Buffer中，然后工作线程此时会被阻塞等待被notify()唤醒。在最右边会有一个且只有一个线程专门去处理这些RingBufferTruck，如果是FSWALEntry则写入hadoop sequence文件。因为文件缓存的存在，这时候很可能client数据并没有落盘。所以进一步如果是SyncFuture会被批量的放到一个线程池中，异步的批量去刷盘,刷盘成功后唤醒工作线程完成wal。1、工作线程(RingBuffer生成者)调用过程如下：FSHLog的append方法首先会从LAMX Disruptor RingbBuffer中拿到一个序号作为txid(sequence)，然后把WALEdit,WALKey和sequence等构建一个FSALEntry实例entry，并把entry放到ringbuffer中。而entry以truck(RingBufferTruck，ringbuffer实际存储类型)通过sequence和ringbuffer一一对应。如果client设置的持久化等级是USER_DEFAULT，SYNC_WAL或FSYNC_WAL，那么工作线程的HRegion还将调用FSHLog的sync()方法。追踪代码可以分析出Sync()方法会往ringbuffer中放入一个SyncFuture对象，并阻塞等待完成(唤醒)。blockOnSync()方法会阻塞工作线程。2、RingBuffer消费者调用过程如下：在FSHLog中有一个私有内部类RingBufferEventHandler类实现了LAMX Disruptor的EventHandler接口，也即是实现了OnEvent方法的ringbuffer的消费者。Disruptor通过 java.util.concurrent.ExecutorService 提供的线程来触发 Consumer 的事件处理，可以看到hbase的wal中只启了一个线程，从源码注释中也可以看到RingBufferEventHandler在运行中只有单个线程。由于消费者是按照sequence的顺序刷数据，这样就能保证WAL日志并发写入时只有一个线程在真正的写入日志文件的可感知的全局唯一顺序。RingBufferEventHandler类的onEvent()(一个回调方法)是具体处理append和sync的方法。在前面说明过wal使用RingBufferTruck来封装WALEntry和SyncFuture(如下图源码)，在消费线程的实际执行方法onEvent()中就是被ringbuffer通知一个个的从ringbfer取出RingBufferTruck，如果是WALEntry则使用当前HadoopSequence文件writer写入文件（此时很可能写的是文件缓存），如果是SyncFuture则简单的轮询处理放入SyncRunner线程异步去把文件缓存中数据刷到磁盘。相关代码如下：SyncRunner是一个线程，wal实际有一个SyncRunner的线程组，专门负责之前append到文件缓存的刷盘工作。SyncRunner的线程方法（run()）负责具体的刷写文件缓存到磁盘的工作。首先去之前提交的synceFutues中拿到其中sequence最大的SyncFuture实例，并拿到它对应ringbuffer的sequence。再去比对当前最大的sequence，如果发现比当前最大的sequence则去调用releaseSyncFuture()方法释放synceFuture，实际就是notify通知正被阻塞的sync操作，让工作线程可以继续往下继续。SyncRunner的run方法核心调用如下：刷磁盘是很费时的操作，如果每次都同步的去刷client的回应比较快，但是写效率不高，如果异步刷文件缓存，写效率提高但是友好性降低，在考虑了写吞吐率和对client友好回应平衡后，wal选择了后者，积累了一定量(通过ringbuffer的sequence)的缓存再刷磁盘以此提高写效率和吞吐率。这个决策从hbase存储机制最初采用lsm树把随机写转换成顺序写以提高写吞吐率，可以看出是目标一致的。         这样整个wal写入也完成了。  

【功能模块】hbase、hetuEngine问题背景：demo中一个环节是把数据存入hbase中之后，用hetu做一个从hive到hbase的跨源查询，但是目前在hetu中无法查询到hbase中对应namespace下的表信息，更不用说查表中数据注：hetuEngine和hbase使用的是同一用户登录需求：希望能指导一下如何使用hetuEngine去查询hbase中对应表的数据【操作步骤&问题现象】1、在hbase中创建namespace："testschema"，然后在该namespace下创建表"rk_p"2、但是在hetuEngine中对应的schema下查询不到对应的表信息【截图信息】【日志信息】（可选，上传日志内容或者附件）