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下查询不到对应的表信息【截图信息】【日志信息】（可选，上传日志内容或者附件）

【功能模块】hbase、hetuEngine【操作步骤&问题现象】1、在hbase中创建namespace："testschema"，然后在该namespace下创建表"rk_p"2、但是在hetuEngine中对应的schema下查询不到对应的表信息hetuEngine和hbase使用的是同一用户登录【截图信息】【日志信息】（可选，上传日志内容或者附件）

>摘要：HBase 是一个面向列的 NoSQL 数据库。本文分享自华为云社区[《HBase 架构：HBase 数据模型 & HBase 读/写机制》](https://bbs.huaweicloud.com/blogs/301024?utm_source=zhihu&utm_medium=bbs-ex&utm_campaign=other&utm_content=content)，作者： Donglian Lin 。 # HBase 架构：HBase 数据模型 众所周知，HBase 是一个面向列的 NoSQL 数据库。虽然它看起来类似于包含行和列的关系数据库，但它不是关系数据库。关系数据库是面向行的，而 HBase 是面向列的。那么，让我们首先了解面向列和面向行的数据库之间的区别： 面向行与面向列的数据库： - 面向行的数据库以行的顺序存储表记录。而面向列的数据库 将表记录存储在一系列列中，即列中的条目存储在磁盘上的连续位置。 为了更好地理解它，让我们举个例子并考虑下表。  如果此表存储在面向行的数据库中。它将存储如下所示的记录： **1 ,保罗沃克,美国, 231 ,加拉多,** **2, Vin Diesel ,巴西, 520 , Mustang** 如上所示，在面向行的数据库中，数据是基于行或元组存储的。 虽然面向列的数据库将此数据存储为： **1 , 2 , Paul Walker , Vin Diesel , 美国,巴西, 231 , 520 , Gallardo , Mustang** 在面向列的数据库中，所有列值都存储在一起，就像第一列值将存储在一起，然后第二列值将一起存储，其他列中的数据以类似方式存储。 - 当数据量非常大时，比如 PB 级或 EB 级，我们使用面向列的方法，因为单列的数据存储在一起，可以更快地访问。 - 虽然面向行的方法相对有效地处理较少数量的行和列，但面向行的数据库存储数据是一种结构化格式。 - 当我们需要处理和分析大量半结构化或非结构化数据时，我们使用面向列的方法。例如处理**在线分析处理的**应用程序，如数据挖掘、数据仓库、包括分析在内的应用程序等。 - 而**在线事务处理**（例如处理结构化数据并需要事务属性（ACID 属性）的银行和金融领域）使用面向行的方法。 HBase 表具有以下组件，如下图所示：  - **表格**：数据以表格格式存储在 HBase 中。但这里的表格是面向列的格式。 - **行键**：行键用于搜索记录，使搜索速度更快。你会很想知道怎么做吗？我将在本博客的架构部分进行解释。 - **列族**：各种列组合在一个列族中。这些列族存储在一起，这使得搜索过程更快，因为可以在一次查找中一起访问属于同一列族的数据。 - **列限定符**：每列的名称称为其列限定符。 - **单元格**：数据存储在单元格中。数据被转储到由行键和列限定符专门标识的单元格中。 - **时间戳**：时间戳是日期和时间的组合。无论何时存储数据，它都会与其时间戳一起存储。这使得搜索特定版本的数据变得容易。 用更简单易懂的方式，我们可以说 HBase 包括： - 一组表 - 每个表都有列族和行 - 行键在 HBase 中充当主键。 - 对 HBase 表的任何访问都使用此主键 - HBase 中存在的每个列限定符表示与驻留在单元格中的对象相对应的属性。 现在您了解了 HBase 数据模型，让我们看看这个数据模型如何符合 HBase 架构并使其适用于大存储和更快的处理。 # HBase 架构：HBase 架构的组件 HBase 具有三个主要组件，即**HMaster Server、HBase Region Server、Regions**和**Zookeeper**。 下图解释了 HBase 架构的层次结构。我们将单独讨论它们中的每一个。  现在在进入 HMaster 之前，我们将了解 Region，因为所有这些 Server（HMaster、Region Server、Zookeeper）都是用来协调和管理 Region 并在 Region 内部执行各种操作的。因此，您很想知道什么是区域以及它们为何如此重要？ # HBase 架构：区域 一个区域包含分配给该区域的开始键和结束键之间的所有行。HBase 表可以划分为多个区域，将一个列族的所有列存储在一个区域中。每个区域都包含按排序顺序的行。 许多区域被分配给一个**Region Server**，它负责处理、管理、执行对该组区域的读取和写入操作。 所以，以更简单的方式结束： - 一个表可以分为多个区域。区域是存储在开始键和结束键之间的数据的有序行范围。 - 一个 Region 的默认大小为 256MB，可以根据需要进行配置。 - 区域服务器为客户端提供一组区域。 - 一个区域服务器可以为客户端提供大约 1000 个区域。 现在从层次结构的顶部开始，我首先想向您解释 HMaster Server，它的作用类似于HDFS 中的 NameNode 。然后，在层次结构中向下移动，我将带您了解 ZooKeeper 和 Region Server。 # HBase 架构：HMaster 如下图所示，您可以看到 HMaster 处理驻留在 DataNode 上的 Region Server 集合。让我们了解 HMaster 是如何做到这一点的。  - HBase HMaster 执行 DDL 操作（创建和删除表）并将区域分配给区域服务器，如上图所示。 - 它协调和管理 Region Server（类似于 NameNode 在 HDFS 中管理 DataNode）。 - 它在启动时将区域分配给区域服务器，并在恢复和负载平衡期间将区域重新分配给区域服务器。 - 它监视集群中所有 Region Server 的实例（在 Zookeeper 的帮助下），并在任何 Region Server 关闭时执行恢复活动。 - 它提供了一个用于创建、删除和更新表的接口。 HBase 有一个庞大的分布式环境，仅靠 HMaster 不足以管理所有内容。那么，你会想知道是什么帮助 HMaster 管理这个巨大的环境？这就是 ZooKeeper 出现的地方。在了解了 HMaster 如何管理 HBase 环境后，我们将了解 Zookeeper 如何帮助 HMaster 管理环境。 # HBase 架构：ZooKeeper – 协调器 下图解释了 ZooKeeper 的协调机制。  - Zookeeper 就像 HBase 分布式环境中的协调器。它有助于通过会话进行通信来维护集群内的服务器状态。 - 每个 Region Server 和 HMaster Server 都会定期向 Zookeeper 发送连续的心跳，并检查哪个服务器是活动的和可用的，如上图所示。它还提供服务器故障通知，以便可以执行恢复措施。 - 从上图可以看出，有一个不活动的服务器，它作为活动服务器的备份。如果活动服务器出现故障，它就会派上用场。 - 活动的 HMaster 向 Zookeeper 发送心跳，而非活动的 HMaster 侦听活动 HMaster 发送的通知。如果活动 HMaster 未能发送心跳，则会话将被删除，非活动 HMaster 变为活动状态。 - 而如果 Region Server 无法发送心跳，则会话将过期并通知所有侦听器。然后 HMaster 执行适当的恢复操作，我们将在本博客稍后讨论。 - Zookeeper 还维护 .META Server 的路径，这有助于任何客户端搜索任何区域。Client首先必须与.META Server核对某个区域所属的Region Server，并获取该Region Server的路径。 说到.META Server，我先给大家解释一下什么是.META Server？因此，您可以轻松地将 ZooKeeper 和 .META Server 的工作联系在一起。稍后，当我在此博客中向您解释 HBase 搜索机制时，我将解释这两者如何协同工作。 # HBase 架构： 元表  - META 表是一个特殊的 HBase 目录表。它维护了 HBase 存储系统中所有区域服务器的列表，如上图所示。 - 从图中可以看到，.META文件以键和值的形式维护表。Key 代表区域的起始键和它的 id，而值包含区域服务器的路径。 正如我在向您解释 Region 时已经讨论过的 Region Server 及其功能，因此现在我们正在向下移动层次结构，我将专注于 Region Server 的组件及其功能。稍后我将讨论搜索、阅读、写作的机制，并了解所有这些组件如何协同工作。 # HBase 架构： Region Server 的组件 下图显示了区域服务器的组件。现在，我将分别讨论它们。  区域服务器维护在HDFS顶部运行的各种区域。区域服务器的组件是： - WAL： 从上图中可以得出结论，Write Ahead Log (WAL) 是附加到分布式环境中每个 Region Server 的文件。WAL 存储尚未持久化或提交到永久存储的新数据。它用于恢复数据集失败的情况。 - Block Cache：从上图可以清楚的看到Block Cache位于Region Server的顶部。它将经常读取的数据存储在内存中。如果 BlockCache 中的数据最近最少使用，则该数据将从 BlockCache 中删除。 - MemStore：是写缓存。在将所有传入数据提交到磁盘或永久内存之前，它会存储所有传入数据。一个区域中的每个列族都有一个 MemStore。正如您在图像中看到的，一个区域有多个 MemStore，因为每个区域包含多个列族。数据在提交到磁盘之前按字典顺序排序。 - HFile：从上图可以看出HFile是存储在HDFS上的。因此，它将实际单元存储在磁盘上。当 MemStore 的大小超过时，MemStore 将数据提交到 HFile。 现在我们知道了 HBase 架构的主要和次要组件，我将在此解释机制和他们的协作努力。不管是读还是写，首先我们要搜索从哪里读或者从哪里写一个文件。所以，让我们了解这个搜索过程，因为这是使 HBase 非常流行的机制之一。 # HBase 架构： 搜索如何在 HBase 中初始化？ 如您所知，Zookeeper 存储 META 表位置。每当客户端向 HBase 发出读取或写入请求时，就会发生以下操作： 1. 客户端从 ZooKeeper 检索 META 表的位置。 2. 客户端然后从 META 表中请求相应行键的 Region Server 的位置来访问它。客户端将此信息与 META 表的位置一起缓存。 3. 然后它将通过从相应的 Region Server 请求来获取行位置。 对于将来的引用，客户端使用其缓存来检索 META 表的位置和先前读取的行键的区域服务器。然后客户端将不会引用 META 表，直到并且除非由于区域移动或移动而导致未命中。然后它将再次请求 META 服务器并更新缓存。 与每次一样，客户端不会浪费时间从 META 服务器检索 Region Server 的位置，因此，这节省了时间并使搜索过程更快。现在，让我告诉您如何在 HBase 中进行写入。其中涉及哪些组件以及它们如何参与？ # HBase 架构： HBase 写机制 下图解释了 HBase 中的写入机制。  写入机制依次经过以下过程（参考上图）： 步骤1：每当客户端有写请求时，客户端将数据写入WAL（Write Ahead Log）。 - 然后将编辑附加到 WAL 文件的末尾。 - 该 WAL 文件保存在每个 Region Server 中，Region Server 使用它来恢复未提交到磁盘的数据。 第 2 步：将数据写入 WAL 后，将其复制到 MemStore。 第 3 步：一旦数据放入 MemStore，客户端就会收到确认。 第 4 步：当 MemStore 达到阈值时，它将数据转储或提交到 HFile。 现在让我们深入了解一下 MemStore 在写作过程中的贡献以及它的功能是什么？ # HBase 写机制- MemStore - MemStore 总是按照字典顺序（按字典方式）将存储在其中的数据更新为已排序的 KeyValue。每个列族有一个 MemStore，因此每个列族的更新以排序的方式存储。 - 当 MemStore 达到阈值时，它会以排序的方式将所有数据转储到一个新的 HFile 中。此 HFile 存储在 HDFS 中。HBase 为每个列族包含多个 HFile。 - 随着时间的推移，HFile 的数量随着 MemStore 转储数据而增长。 - MemStore 还保存了最后写入的序列号，因此 Master Server 和 MemStore 都知道到目前为止提交了什么以及从哪里开始。当区域启动时，读取最后一个序列号，并从该编号开始新的编辑。 正如我多次讨论过的，HFile 是 HBase 架构中的主要持久存储。最后，所有的数据都提交到 HFile 中，HFile 是 HBase 的永久存储。因此，让我们看看 HFile 的属性，它可以在读写时更快地进行搜索。 # HBase 架构： HBase 写入机制- HFile - 写入按顺序放置在磁盘上。因此，磁盘读写头的运动非常少。这使得写入和搜索机制非常快。 - 每当打开 HFile 时，HFile 索引就会加载到内存中。这有助于在单次查找中查找记录。 - 预告片是一个指向 HFile 的元块的指针。它写在提交文件的末尾。它包含有关时间戳和布隆过滤器的信息。 - 布隆过滤器有助于搜索键值对，它会跳过不包含所需行键的文件。时间戳还有助于搜索文件的版本，它有助于跳过数据。 在了解写入机制和各种组件在使写入和搜索更快方面的作用之后。我将向您解释读取机制在 HBase 架构中是如何工作的？然后我们将转向提高 HBase 性能的机制，如压缩、区域拆分和恢复。 # HBase 架构： 读取机制 正如我们在搜索机制中所讨论的，如果客户端的缓存中没有它，客户端首先从 .META 服务器中检索区域服务器的位置。然后它按顺序执行以下步骤： - 为了读取数据，扫描器首先在块缓存中查找行单元。这里存储了所有最近读取的键值对。 - 如果 Scanner 未能找到所需的结果，它会移动到 MemStore，因为我们知道这是写缓存内存。在那里，它搜索最近写入的文件，这些文件尚未转储到 HFile 中。 - 最后，它将使用布隆过滤器和块缓存从 HFile 加载数据。 到目前为止，我已经讨论了 HBase 的搜索、读写机制。现在我们来看看 HBase 机制，它使 HBase 中的搜索、读取和写入变得快速。首先，我们将了解Compaction，这是其中一种机制。 # HBase 架构： 压缩  **HBase** 结合 HFiles 以减少存储并减少读取所需的磁盘寻道次数。这个过程称为**压缩**。Compaction 从一个区域中选择一些 HFile 并将它们组合起来。如上图所示，有两种类型的压缩。 1. 次要压缩：HBase 自动选择较小的 HFile 并将它们重新提交到较大的 HFile，如上图所示。这称为轻微压实。它执行合并排序以将较小的 HFile 提交到较大的 HFile。这有助于优化存储空间。 2. Major Compaction： 如上图所示，在Major compaction中，HBase将一个区域的较小的HFiles合并并重新提交到一个新的HFile。在这个过程中，相同的列族被放置在新的 HFile 中。它会在此过程中删除已删除和过期的单元格。它提高了读取性能。 但在此过程中，输入输出磁盘和网络流量可能会变得拥挤。这称为**写放大**。因此，它通常安排在低峰值负载时间。 现在我将讨论的另一个性能优化过程是 Region Split。这对于负载平衡非常重要。 # HBase 架构： 区域拆分 下图说明了 Region Split 机制。  每当一个区域变大时，它就会被分成两个子区域，如上图所示。每个区域正好代表父区域的一半。然后将此拆分报告给 HMaster。这由同一个 Region Server 处理，直到 HMaster 将它们分配给新的 Region Server 以进行负载平衡。 接下来，最后但并非最不重要的一点是，我将向您解释 HBase 如何在发生故障后恢复数据。我们知道故障恢复是 HBase 的一个非常重要的特性，因此让我们了解 HBase 如何在故障后恢复数据。 # HBase 架构：HBase 崩溃和数据恢复 - 每当 Region Server 出现故障时，ZooKeeper 都会通知 HMaster 故障。 - 然后 HMaster 将崩溃的 Region Server 的区域分发并分配给许多活动的 Region Server。为了恢复出现故障的 Region Server 的 MemStore 的数据，HMaster 将 WAL 分发给所有 Region Server。 - 每个 Region Server 重新执行 WAL 来为那个失败的 region 的列族构建 MemStore。 - 数据按时间顺序（按时间顺序）写入 WAL。因此，重新执行该 WAL 意味着进行所有在 MemStore 文件中所做和存储的更改。 - 所以，在所有的 Region Servers 执行完 WAL 之后，所有列族的 MemStore 数据都被恢复了。 我希望这篇博客能帮助您了解 HBase 数据模型和 HBase 架构。希望你喜欢它。

【功能模块】MRS Hbase shell 进行count查询时有的表能查询成功，有的查询失败，如图。网络应该不存在问题，Hbase其他命令都可以执行。截图如下：请专家帮看下怎么解决呢？

前言Hadoop生态圈的技术繁多。HDFS一直用来保存底层数据，地位牢固。Hbase作为一款Nosql也是Hadoop生态圈的核心组件，它海量的存储能力，优秀的随机读写能力，能够处理一些HDFS不足的地方。Clickhouse是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。能够使用SQL查询实时生成分析数据报告。它同样拥有优秀的数据存储能力。Apache Kudu是Cloudera Manager公司16年发布的新型分布式存储系统，结合CDH和Impala使用可以同时解决随机读写和sql化数据分析的问题。分别弥补HDFS静态存储和Hbase Nosql的不足。既然可选的技术路线有这么多，本文将从安装部署、架构组成、基本操作等方面横向对比一下Hbase、Kudu和Clickhouse。另外这里还引入了几个大厂的实践作为例子予以参考。安装部署方式对比具体的安装步骤不过多赘述，这里只简要比较安装过程中需要依赖的外部组件。Habse 安装依赖HDFS作为底层存储插件 依赖Zookeeper作为元数据存储插件。Kudu 安装依赖Impala作为辅助分析插件 依赖CDH集群作为管理插件，但是不是必选的，也可以单独安装。ClickHouse 安装依赖Zookeeper作为元数据存储插件和Log Service以及表的 catalog service组成架构对比。Hbase架构Kudu架构Clickhouse架构综上所示，Hbase和Kudu都是类似于Master-slave的架构而Clickhouse不存在Master结构，Clickhouse的每台Server的地位都是等价的，是multi-master模式。不过Hbase和Clickhouse额外增加了一个Zookeeper作为辅助的元数据存储或者是log server等，而Kudu的元数据是Master管理的，为了避免server频繁从Master读取元数据，server会从Master获取一份元数据到本地，但是会有元数据丢失的风险。基本操作对比数据读写操作Hbase读流程Hbase写流程KuduClickhouseClickhouse是个分析型数据库。这种场景下，数据一般是不变的，因此Clickhouse对update、delete的支持是比较弱的，实际上并不支持标准的update、delete操作。Clickhouse通过alter方式实现更新、删除，它把update、delete操作叫做mutation(突变)。标准SQL的更新、删除操作是同步的，即客户端要等服务端反回执行结果（通常是int值）；而Clickhouse的update、delete是通过异步方式实现的，当执行update语句时，服务端立即反回，但是实际上此时数据还没变，而是排队等着。Mutation具体过程首先，使用where条件找到需要修改的分区；然后，重建每个分区，用新的分区替换旧的，分区一旦被替换，就不可回退；对于每个分区，可以认为是原子性的；但对于整个mutation，如果涉及多个分区，则不是原子性的。更新功能不支持更新有关主键或分区键的列；更新操作没有原子性，即在更新过程中select结果很可能是一部分变了，一部分没变，从上边的具体过程就可以知道；更新是按提交的顺序执行的；更新一旦提交，不能撤销，即使重启Clickhouse服务，也会继续按照system.mutations的顺序继续执行；已完成更新的条目不会立即删除，保留条目的数量由finished_mutations_to_keep存储引擎参数确定。超过数据量时旧的条目会被删除；更新可能会卡住，比如update intvalue='abc’这种类型错误的更新语句执行不过去，那么会一直卡在这里，此时，可以使用KILL MUTATION来取消。综上所示，Hbase随机读写，但是Hbase的update操作不是真的update，它的实际操作是insert一条新的数据，打上不同的timestamp，而老的数据会在有效期之后自动删除。而Clickhouse干脆就不支持update和delete。数据查询操作Hbase：不支持标准sql，需要集成Phoenix插件。Hbase自身有Scan操作，但是不建议执行，一般会全量扫描导致集群崩溃。Kudu：与Impala集成实现查询。Clickhouse：自身有优良的查询性能。HBase在滴滴出行的应用场景和最佳实践HBase在滴滴主要存放了以下四种数据类型：统计结果、报表类数据：主要是运营、运力情况、收入等结果，通常需要配合Phoenix进行SQL查询。数据量较小，对查询的灵活性要求高，延迟要求一般。原始事实类数据：如订单、司机乘客的GPS轨迹、日志等，主要用作在线和离线的数据供给。数据量大，对一致性和可用性要求高，延迟敏感，实时写入，单点或批量查询。中间结果数据：指模型训练所需要的数据等。数据量大，可用性和一致性要求一般，对批量查询时的吞吐量要求高。线上系统的备份数据：用户把原始数据存在了其他关系数据库或文件服务，把HBase作为一个异地容灾的方案。订单事件近期订单的查询会落在Redis，超过一定时间范围，或者当Redis不可用时，查询会落在HBase上。业务方的需求如下：在线查询订单生命周期的各个状态，包括status、event_type、order_detail等信息。主要的查询来自于客服系统；在线历史订单详情查询。上层会有Redis来存储近期的订单，当Redis不可用或者查询范围超出Redis，查询会直接落到HBase；离线对订单的状态进行分析•写入满足每秒10K的事件，读取满足每秒1K的事件，数据要求在5s内可用。按照这些要求，我们对Rowkey做出了下面的设计，都是很典型的scan场景。订单状态表Rowkey：reverse(order_id) + (MAX_LONG - TS)Columns：该订单各种状态。订单历史表Rowkey：reverse(passenger_id | driver_id) + (MAX_LONG - TS)Columns：用户在时间范围内的订单及其他信息。司机乘客轨迹举几个使用场景上的例子：用户查看历史订单时，地图上显示所经过的路线；发生司乘纠纷，客服调用订单轨迹复现场景；地图部门用户分析道路拥堵情况。用户们提出的需求：满足App用户或者后端分析人员的实时或准实时轨迹坐标查询；满足离线大规模的轨迹分析；满足给出一个指定的地理范围，取出范围内所有用户的轨迹或范围内出现过的用户。其中，关于第三个需求，地理位置查询，我们知道MongoDB对于这种地理索引有源生的支持，但是在滴滴这种量级的情况下可能会发生存储瓶颈，HBase存储和扩展性上没有压力但是没有内置类似MongoDB地理位置索引的功能，没有就需要我们自己实现。通过调研，了解到关于地理索引有一套比较通用的GeohHash算法 。把GeoHash和其他一些需要被索引的维度拼装成Rowkey，真实的GPS点为Value，在这个基础上封装成客户端，并且在客户端内部对查询逻辑和查询策略做出速度上的大幅优化，这样就把HBase变成了一个MongoDB一样支持地理位置索引的数据库。如果查询范围非常大（比如进行省级别的分析），还额外提供了MR的获取数据的入口。两种查询场景的Rowkey设计如下：单个用户按订单或时间段查询：reverse(user_id) + (Integer.MAX_LONG-TS/1000)；给定范围内的轨迹查询：reverse(geohash) + ts/1000 + user_id。ETAETA是指每次选好起始和目的地后，提示出的预估时间和价格。提示的预估到达时间和价格，最初版本是离线方式运行，后来改版通过HBase实现实时效果，把HBase当成一个KeyValue缓存，带来了减少训练时间、可多城市并行、减少人工干预的好处。整个ETA的过程如下：模型训练通过Spark Job，每30分钟对各个城市训练一次；模型训练第一阶段，在5分钟内，按照设定条件从HBase读取所有城市数据；模型训练第二阶段在25分钟内完成ETA的计算；HBase中的数据每隔一段时间会持久化至HDFS中，供新模型测试和新的特征提取。Rowkey：salting+cited+type0+type1+type2+TS Column：order, feature监控工具 DCM用于监控Hadoop集群的资源使用（Namenode，Yarn container使用等），关系数据库在时间维度过程以后会产生各种性能问题，同时我们又希望可以通过SQL做一些分析查询，所以使用Phoenix，使用采集程序定时录入数据，生产成报表，存入HBase，可以在秒级别返回查询结果，最后在前端做展示：-     小结     -在滴滴推广和实践HBase的工作中，我们认为至关重要的两点是帮助用户做出良好的表结构设计和资源的控制。有了这两个前提之后，后续出现问题的概率会大大降低。良好的表结构设计需要用户对HBase的实现有一个清晰的认识，大多数业务用户把更多精力放在了业务逻辑上，对架构实现知之甚少，这就需要平台管理者去不断帮助和引导，有了好的开端和成功案例后，通过这些用户再去向其他的业务方推广。资源隔离控制则帮助我们有效减少集群的数量，降低运维成本，让平台管理者从多集群无止尽的管理工作中解放出来，将更多精力投入到组件社区跟进和平台管理系统的研发工作中，使业务和平台都进入一个良性循环，提升用户的使用体验，更好地支持公司业务的发展。网易考拉基于KUDU构建实时流量数仓实践Kudu不但提供了行级的插入、更新、删除API，同时也提供了接近Parquet性能的批量扫描操作。使用同一份存储，既可以进行随机读写，也可以满足数据分析的要求。实时流/业务数据写入可以使用Spark Streaming 提供的KafkaUtils.createDirectStream方法来创建一个对应topic的Dstream。这种方法topic的offset将完全由我们自己控制：private val stream = KafkaUtils.createDirectStream[String, String]( ssc, PreferConsistent, Subscribe[String, String](topics, kafkaParams) )写入Kudu分以下几个步骤：获取kafka offset创建KuduContext定义写入Kudu表的schema按照解析逻辑解析流量日志并构建DataFrame将df插入Kudu并提交offsetval offsetRanges = rdd.asInstanceOf[HasOffsetRanges].offsetRanges val spark = SparkSession.builder.config(rdd.sparkContext.getConf).getOrCreate() val kuduContext = new KuduContext(kuduMaster, spark.sparkContext) val flowDf = spark.createDataFrame(rdd.map(r => { processFlowLine(r.value) }).filter(row => if (row.get(0) == null) false else true), schema) kuduContext.upsertRows(flowDf, "impala::kaola_kudu_internal.dwd_kl_flw_app_rt") stream.asInstanceOf[CanCommitOffsets].commitAsync(offsetRanges)写入性能测试Kudu写入表: haitao_dev_log.dwd_kl_flw_app_rt，分片: 240个，Spark Streaming调度间隔: 15s。可以发现75%的任务都在1s完成，有少数任务跑的较慢但整体在2s都跑完了，这里需要注意一种极端情况，由于Spark的默认配置并发数是1，如果有一个进程迟迟没有跑完(一般是数据分布不均)那么后面的任务将会排队，直到最初的任务跑完才会去调度下一个任务。这样会造成资源浪费，多个空闲的executor会一直等待最后一个executor，流量日志不要求顺序插入，因此我们可以加大任务的并发数。具体参数设置：spark.streaming.concurrentJobs = N小结目前实时写入Kudu的流量日志在每日数十亿条，写入量在TB级，而且已有实时流量拆解等业务依赖Kudu的底层流量数据，接下来将会有更多的业务线迁移至Kudu以满足不同维度下的分析需求。携程ClickHouse日志分析实践结合携程的日志分析场景，日志进入ES前已经格式化成JSON，同一类日志有统一的Schema，符合ClickHouse Table的模式；日志查询的时候，一般按照某一维度统计数量、总量、均值等，符合ClickHouse面向列式存储的使用场景。偶尔有少量的场景需要对字符串进行模糊查询，也是先经过一些条件过滤掉大量数据后，再对少量数据进行模糊匹配，ClickHouse也能很好的胜任。另外我们发现90%以上的日志没有使用ES的全文索引特性，因此我们决定尝试用ClickHouse来处理日志。消费数据到ClickHouse我们使用gohangout消费数据到ClickHouse，关于数据写入的几点建议：采用轮询的方式写ClickHouse集群的所有服务器，保证数据基本均匀分布。大批次低频率的写入，减少parts数量，减少服务器merge，避免Too many parts异常。通过两个阈值控制数据的写入量和频次，超过10w记录写一次或者30s写一次。写本地表，不要写分布式表，因为分布式表接收到数据后会将数据拆分成多个parts，并转发数据到其它服务器，会引起服务器间网络流量增加、服务器merge的工作量增加，导致写入速度变慢，并且增加了Too many parts的可能性。建表时考虑partition的设置，之前遇到过有人将partition设置为timestamp，导致插入数据一直报Too many parts的异常。我们一般按天分partition。主键和索引的设置、数据的乱序等也会导致写入变慢。数据展示我们调研了像Supperset、Metabase、Grafana等几个工具，最终还是决定采用在Kibana3上开发支持ClickHouse实现图表展示。主要原因是Kibana3这种强大的数据过滤功能，很多系统都不具备，另外也考虑到迁移到其他系统成本较高，用户短期内难以适应。查询优化Kibana中的Table Panel用于显示日志的明细数据，一般查询最近1小时所有字段的数据，最终只展示前500条记录。这种场景对于ClickHouse来说非常不友好。针对这个问题，我们将table Panel的查询分两次进行：第一次查询单位时间间隔的数据量，根据最终显示的数据量计算出合理查询的时间范围；第二次根据修正后的时间范围，结合Table Panel中配置的默认显示的Column查询明细数据。经过这些优化，查询的时间可以缩短到原来的1/60，查询的列可以减少50%，最终查询数据量减少到原来的1/120；ClickHouse提供了多种近似计算的方法，用于提供相对较高准确性的同时减少计算量；使用MATERIALIZED VIEW或者MATERIALIZED COLUMN将计算量放在平常完成，也能有效降低查询的数据量和计算量。ClickHouse 基本运维总体来说ClickHouse的运维比ES简单，主要包括以下几个方面的工作：新日志的接入、性能优化；过期日志的清理，我们通过一个定时任务每天删除过期日志的partition；ClickHouse的监控，使用ClickHouse-exporter+VictoriaMetrics+Grafana的实现；数据迁移，通过ClickHouse分布式表的特性我们一般不搬迁历史数据，只要将新的数据接入新集群，然后通过分布式表跨集群查询。随着时间的推移，历史数据会被清理下线，当老集群数据全部下线后，新老集群的迁移就完成了。确实需要迁移数据时，采用ClickHouse_copier或者复制数据的方式实现。常见问题处理：慢查询，通过kill query终止慢查询的执行，并通过前面提到的优化方案进行优化Too many parts异常：Too many parts异常是由于写入的part过多part的merge速度跟不上产生的速度，导致part过多的原因主要包括几个方面：设置不合理小批量、高频次写ClickHouse•写的是ClickHouse的分布式表ClickHouse设置的merge线程数太少了无法启动：之前遇到过ClickHouse无法启动的问题，主要包括两个方面：- 文件系统损坏，通过修复文件系统可以解决- 某一个表的数据异常导致ClickHouse加载失败，可以删除异常数据后启动，也可以把异常的文件搬到detached目录，等ClickHouse起来后再attach文件恢复数据将日志从ES迁移到ClickHouse可以节省更多的服务器资源，总体运维成本更低，而且提升了查询速度，特别是当用户在紧急排障的时候，这种查询速度的成倍提升，对用户的使用体验有明显的改善。但是ClickHouse毕竟不是ES，在很多业务场景中ES仍然不可替代；ClickHouse也不仅只能处理日志，进一步深入研究ClickHouse，让ClickHouse在更多领域发挥更大的价值，是我们一直努力的方向。总结这里简单总结一下三者的特点。首先说一下Hbase与Kudu，可以说是Kudu师承Hbase，架构是类似的master-slave结构。Hbase的物理模型是master和regionserver，regionserver存储的是region，region里边很有很多store，一个store对应一个列簇，一个store中有一个memstore和多个storefile，store的底层是hfile，hfile是hadoop的二进制文件，其中HFile和HLog是Hbase两大文件存储格式，HFile用于存储数据，HLog保证可以写入到HFile中。Kudu的物理模型是master和tserver，其中table根据hash和range分区，分为多个tablet存储到tserver中，tablet分为leader和follower，leader负责写请求，follower负责读请求，总结来说，一个ts可以服务多个tablet，一个tablet可以被多个ts服务（基于tablet的分区，最低为2个分区）。而Clickhouse的特点在于它号称最快的查询性能，虽然也能存储数据，但并不是他的强项，而且Clickhouse还不能update/delete数据。最后从下面几个维度来对比一下Hbase、Kudu和Clickhouse。所以Hbase更适合非结构化的数据存储；在既要求随机读写又要求实时更新的场景，Kudu+Impala可以很好的胜任，当然再结合CDH就更好了，瓶颈并不在Kudu，而在Impala的Apache部署。如果只要求静态数据的极速查询能力，Clickhouse则更好。文章转载自数据仓库与Python大数据公众号 https://mp.weixin.qq.com/s/BJvEbVFc6d-lzh9E2N4SIg   免责声明：转载文章版权归原作者所有。如涉及作品内容、版权等问题，请及时联系文章编辑！

MRS 3.1.1版本的集群中关于HBase的数据老化问题，已知TTL支持到列族，当前想知道是否支持到列？

适配hbase过程中，通过jdbc读取hbase映射的hive表报错报错信息在附件异常信息.txt中，网上查阅资料说需要修改集群的配置但是尝试后并无效果，阻塞了hbase的适配。

我们现在客户端用的是python去连， 参考的是这个样例https://github.com/huaweicloud/huaweicloud-mrs-example/tree/mrs-1.8/src/hbase-examples/hbase-python-example但是每次transport.open()的时候， 服务端都会报这个错误2021-09-01 16:02:35,082 | ERROR | thrift-worker-24 | SASL negotiation failure | org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:307)javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)]    at com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:199)    at org.apache.thrift.transport.TSaslTransport$SaslParticipant.evaluateChallengeOrResponse(TSaslTransport.java:536)    at org.apache.thrift.transport.TSaslTransport.open(TSaslTransport.java:277)    at org.apache.thrift.transport.TSaslServerTransport.open(TSaslServerTransport.java:42)    at org.apache.thrift.transport.TSaslServerTransport$Factory.getTransport(TSaslServerTransport.java:217)    at org.apache.hadoop.hbase.thrift.TBoundedThreadPoolServer$ClientConnnection.run(TBoundedThreadPoolServer.java:287)    at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)    at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)    at java.lang.Thread.run(Thread.java:748)Caused by: GSSException: Failure unspecified at GSS-API level (Mechanism level: Checksum failed)    at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:858)    at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:342)    at sun.security.jgss.GSSContextImpl.acceptSecContext(GSSContextImpl.java:285)    at com.sun.security.sasl.gsskerb.GssKrb5Server.evaluateResponse(GssKrb5Server.java:167)    ... 8 moreCaused by: KrbException: Checksum failed    at sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Aes256CtsHmacSha1EType.java:102)    at sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Aes256CtsHmacSha1EType.java:94)    at sun.security.krb5.EncryptedData.decrypt(EncryptedData.java:175)    at sun.security.krb5.KrbApReq.authenticate(KrbApReq.java:281)    at sun.security.krb5.KrbApReq.<init>(KrbApReq.java:149)    at sun.security.jgss.krb5.InitSecContextToken.<init>(InitSecContextToken.java:140)    at sun.security.jgss.krb5.Krb5Context.acceptSecContext(Krb5Context.java:831)    ... 11 moreCaused by: java.security.GeneralSecurityException: Checksum failed    at sun.security.krb5.internal.crypto.dk.AesDkCrypto.decryptCTS(AesDkCrypto.java:451)    at sun.security.krb5.internal.crypto.dk.AesDkCrypto.decrypt(AesDkCrypto.java:272)    at sun.security.krb5.internal.crypto.Aes256.decrypt(Aes256.java:76)    at sun.security.krb5.internal.crypto.Aes256CtsHmacSha1EType.decrypt(Aes256CtsHmacSha1EType.java:100)    ... 17 more请哪位专家帮忙分析一下，可能是什么原因