问题分析客户程序跑一段时间后，连续报java.net.SocketTimeoutException: callTimeout=60000, callDuration=68908: Call to  xxx  failed on local exception: org.apache.hadoop.hbase.exceptions.ConnectionClosingException: Connection to xxx is closing. 使用hbase hbck查看表状态OK查看hbase服务端regionserver日志没有任何异常，无法定位到根因查看客户端/etc/hosts文件ip映射与dns等都正常。将客户端日志级别和服务端对应报错的regionserver日志级别修改为trace级别。等待问题复现。复现后发现服务端有如下异常打印，此打印说明业务再运行过程中用户发生了改变，由cdm_user变成了saxppopt用户。cdm_user没有对应的hbase用户权限，从而导致认证异常。    问题解决参考          在hbase服务级别core-site.xml文件中自定义hadoop.proxyuser.sxappopt.hosts=*,hadoop.proxyuser. sxappopt.groups=*两个参数，保存后重启hbase，修改这两个参数后可能会引起其他的一些组件之间的认证问题。

    问题分析1. 查看spark任务日志，发现业务日志一直报181174节点连接超时，入库慢的业务只写入一张表。2. 源生页面看region分配很不均匀，开启balance，手动将报错节点上写入的表region move到其他节点，region移走后反馈写速率正常。3. 客户反馈又有其他的任务入库慢，任务会写入多张表，报错节点还是181174，手动重启报错regionserver节点后，写入速率增大。4. 任务跑两三个小时后又会出现写入慢，regionserver实例重启后会报其他节点，但是所有任务报错的节点都是同一个。5. 分析报错节点的regionserver日志（hbase-omm-regionserver-<hostname>.log）和对报错节点打jstack，日志中大量打印responseTooSlow，queuetime时间特别长，jsatck中600个handler，只有一两个是runnable，剩余的全部在等待行锁。    6.  查看第一个报错节点regionserver活跃handler的历史监控发现11/3 10点左右handler数开始持续上涨，直到重启后才降下去。    7. 排查11/3 10点左右启的任务，发现两个实时任务一直在运行，将这两个实时任务重启后，一直报错的regionserver节点handler数下降，写入慢的两个任务写入速率也恢复正常。    8. 根据报错的regionserver运行日志排查发现最开始报错的表名为d02_p_index:SYS0028_CGT_INTEGRAL_REWARD_INDEX_1对应业务为D02_realtime_largest_A01_v1.0.1_JY_SYS0028，排查业务代码后发现代码中调用了checkandput方法；         问题解决参考             二次开发调用接口不规范导致，checkandput方法如果对同一行数据多次进行更新时需要等待上一次更新操作完成之后才能继续操作，建议直接使用put方法。

问题分析：业务侧写入数据慢，服务端日志无responseTooSlow和slow sync打印；打印业务侧jstack日志，通过jstack确定，都是在等待链接；问题解决参考     客户端连接不够，客户端hbase-site.xml配置文件中修改hbase.client.pool.size 默认为1，修改值最好和应用并发数设置一样。

### 一、业务背景 xx银行的手机银行将埋点日志实采集到，传回服务端存入了HBase集群原始表。现在需要检查原始表日志信息完整性，字段是否缺失，是否有异常数据。结果用于反馈给前端开发，检查日志抓取业务是否有问题。 #### 1.1 数据类型及数据量 **原始日志包含:** 打开日志 点击日志 页面加载日志 **HBase****字段：** 含13个必填字段, 其一为[behaviour](https://www.baidu.com/link?url=t_AlPPVDYRKzDDS4d4iamNpy8OJojY2pq9njDqT1TdWtHfru8kBC-XG44clh3LerNRO-4D_03QtT5TCUb-EUOsSwzPvtMiU4j0pnlqH6g4a&wd;=&eqid=9b58d2770001fdfa000000065d70c53c)字段，为json，不同日志类型字段数量不同。 **HBase****数据量及region****数目:** 目前有17个HBase节点,单日数据量700G，TTL 为3天，Major_compaction触发间隔为7天，保守估计要存储7T数据（10天） #### 1.2 业务查询类型—范围查询 查询十分钟内所有日志数据 #### 1.3 平台选型 支持MRS-302版本和651版本，其他版本需要根据实际情况修改配置。 ### 二、 现状及诉求 #### 2.1 现状 当前rowkey设计： (一位随机数0~9) | (时间戳精确到天)|uuid 例: 0|20190905|uuid 1. 每天的数据量700G，保守估计要存储7T数据，数据量很大，所以rowkey高位使用一位随机数0~9细分的还不够，很容易出现时间相近的数据依然存在同一region的情况。数据检索的时候负载会集中在个别的RegionServer上，造成热点问题，查询效率太低。 2. 时间戳精确到天不能满足查询十分钟范围的数据 #### 2.2 诉求 需要重新设计Rowkey, 优化查询方案 ### 三、优化方案 #### 3.1 rowkey设计 ##### **3.1.1** rowkey高位散列字段与region： 估计要存储7T数据（10天） ，按每个region 5G 计算， 需要1400个region。每个RegionServer建议管理20-200活跃region，目前有17个HBase节点，分1400个region完全够用，在建表时就预分Region,例如: 1: -xxx ~ 1001 2: 1001 ~ 1002 3: 1002 ~ 1003 … 1400： 2399 ~ +xxx 那么插入数据时就可以使用1000~2399四位随机数作为rowkey的高位，尽可能的把数据均匀分布在每个Region中，以实现负载均衡率。 ##### 3.1.2 rowkey中间时间字段 因为查询需要细化到分、秒，设计为yyyyMMddHHmmss ##### 3.1.3 rowkey尾部uuid 使用32位uuid，用于区别出同一时刻的大量数据 综上：重新设计后的Rowkey规则： (四位随机数1001~2399) -yyyyMMddHHmmss-uuid 例: 1988-20190912152344-uuid #### 3.2 查询设计 扫描数据时，使用基于spark on hbase 调用scan 接口，底层会根据region数进行并发查询，提升效率 ### 四、样例代码 #### 4.1 代码说明 ##### 4.2.1 com.huawei.bigdata.spark.examples.TableCreationJava：创建HBase表 ``` 1. 本demo默认使用表名“RowkeyCase”。 2. 因开发环境限制，本demo预分只200 region 。 请根据自己情况修改。 ``` ##### 4.2.2 com.huawei.bigdata.spark.examples.option2. ProduceData：生成测试数据 ``` 1. 测试数据共50W条，每条0.12KB，共58.6M。 2. 每条数据Rowkey:(本样例200region) 三位随机数100~299) -yyyyMMddHHmmss-uuid,数据共7个字段。 请根据自己情况在启动命令中配置输出文件路径和数据量。 ``` ##### 4.2.3 com.huawei.bigdata.spark.examples.option2.TableInputData：读取HDFS上文件中的测试数据，插入HBaseb表（方法一） ``` 1. puts.size每次数据量建议为2M，本案例设置为20000条。 请根据自己情况酌情修改。 ``` ##### 4.2.4 com.huawei.bigdata.spark.examples.option3.TableInputData：读取HDFS上文件中的测试数据，插入HBaseb表（方法二） ``` 方法一、方法二效率差不多，方法二使用spark saveAsNewAPIHadoopDataset算子，代码更简洁。 ``` ##### 4.2.5 com.huawei.bigdata.spark.examples.option2.TableOutputDataJava：查询数据 ``` 基于spark on hbase 调用scan 接口查询 1. 请根据自己情况酌情修代码中起始region、region数量、表名 2. 请根据自己的业务需要对RDD中的数据进行map、filter等处理 ``` #### 4.2 代码获取 代码获取见附件 ### 五、运行步骤及结果 #### 5.1 准备工作 ##### 1. 修改spark-defaults.conf中的配置: - spark.kryoserializer.buffer.max 调大到 1024MB； - spark.yarn.security.credentials.hbase.enabled修改为true - spark.hbase.obtainToken.enabled 修改为true - spark.inputFormat.cache.enabled修改为false ##### 2. 使用idea代码打包生成SparkHBaseRowkeyCase.jar,上传服务器某路径如/opt/xhk/目录下  ##### 3. 认证使用的user.keytab 和 krb5.conf，上传服务器某路径如/opt/xhk/目录下  #### 5.2 创建表 1. Kinit认证后，source配置环境变量。 2. 进入spark2x客户端 3. 执行如下命令 ``` bin/spark-submit --class com.huawei.bigdata.spark.examples.TableCreationJava --master yarn --deploy-mode client /opt/xhk/SparkHBaseRowkeyCase.jar wxb /opt/xhk ``` - TableCreationJava ：运行创建表类 - /opt/xhk/SparkHBaseRowkeyCase.jar：类所在jar包 - wxb：user.keytab 和 krb5.conf对应的用户名 - /opt/xhk：user.keytab 和 krb5.conf所在路径 结果如下：  #### 5.3 插入数据 ##### 5.3.1 生成数据 执行命令： ``` java -cp /opt/xhk/SparkHBaseRowkeyCase.jar com.huawei.bigdata.spark.examples.option2.ProduceData /opt/xhk/test0925.txt 500000 ``` - ProduceData ：数据生成类 - /opt/xhk/SparkHBaseRowkeyCase.jar：类所在jar包 - /opt/xhk/test0925.txt：测试数据输出文件,名字可自定义 - 500000：50W条数据，因虚拟机内存不足，大家可以设置500W以上数据 ##### 5.3.2 上传HDFS 执行命令： ``` hdfs dfs -mkdir -p /user/xhk cd /opt/xhk mv test0925.txt test09251440.txt hdfs dfs -put test09251440.txt /user/xhk/ ``` ##### 5.3.3 插入表 执行命令： ``` bin/spark-submit --executor-cores 2 --num-executors 10 --executor-memory 4G --driver-memory 2G --conf spark.default.parallelism=1000 --class com.huawei.bigdata.spark.examples.option2.TableInputData --master yarn --deploy-mode client /opt/xhk/SparkHBaseRowkeyCase.jar wxb /opt/xhk /user/xhk/test09251440.txt ``` - executor-cores ：用于设置Spark作业总共要用多少个Executor进程来执行 - num-executors：用于设置每个Executor进程的CPU core数量 - executor-memory：用于设置每个Executor进程的内存 - driver-memory：用于设置Driver进程的内存 - conf spark.default.parallelism：用于设置每个stage的默认task数量 - option2.TableInputData：运行插入数据类(方式一) - /opt/xhk/SparkHBaseRowkeyCase.jar：类所在jar包 - wxb：user.keytab 和 krb5.conf对应的用户名 - /opt/xhk：user.keytab 和 krb5.conf所在路径 结果如下：  #### 5.3.4 查询数据 执行命令： ``` bin/spark-submit --executor-cores 2 --num-executors 20 --executor-memory 2G --driver-memory 5G --conf spark.default.parallelism=1000 --class com.huawei.bigdata.spark.examples.option2.TableOutputDataJava --master yarn --deploy-mode client /opt/xhk/SparkHBaseRowkeyCase.jar wxb /opt/xhk 20201222113639 20201222113647 ``` - executor-cores ：用于设置Spark作业总共要用多少个Executor进程来执行 - num-executors：用于设置每个Executor进程的CPU core数量 - executor-memory：用于设置每个Executor进程的内存 - driver-memory：用于设置Driver进程的内存 - conf spark.default.parallelism：用于设置每个stage的默认task数量。 - TableOutputDataJava：运行查询数据类 - /opt/xhk/SparkHBaseRowkeyCase.jar：类所在jar包 - wxb：user.keytab 和 krb5.conf对应的用户名 - /opt/xhk：user.keytab 和 krb5.conf所在路径 - 20201222113639：查询起始时间yyyyMMddHHmmss - 20201222113647：查询结束时间yyyyMMddHHmmss，数据量大时可以选择10分钟间隔的数据 结果如下： 

问题分析：    1.  RegionServer日志（hbase-omm-regionserver-<hostname>.log）分析，WAL文件2020-09-01 10:16:39,144开始Rolled，新创建WAL文件                  由于WAL文件写入存在卡顿，导致Cache flush failed失败，从而导致业务侧写入阻塞            在2020-09-01 10:23:03  进行了pipeline Recovery ，pipeline更新后文件写入成功。   从下面日志上可以看到，在10:23:03时候，块blk_2622458507_1548723541写入异常，并且提示11.58.8.11节点处于Bad状态，紧接着RS更新了pipeline，新的pipeline由11.58.20.19->11.58.8.11->11.58.8.13变为11.58.20.19->11.58.8.23->11.58.8.13，并且块名称也变更为blk_2622458507_1548733441（还是之前的块，仅时间戳发生了变化）      随即NameNode 日志（/var/log/Bigdata/hdfs/nn/hadoop-omm-namenode-<hostname>.log）pipeline提示更新成功        2020-09-01 10:23:03,623 | INFO  | IPC Server handler 5 on 25000 | updatePipeline(blk_2622458507_1548723541, newGS=1548733441, newLength=10743814, newNodes=[11.58.20.19:2500 9, 11.58.20.23:25009, 11.58.8.13:25009], client=DFSClient_NONMAPREDUCE_-90155922_1) | FSNamesystem.java:6379        2020-09-01 10:23:03,624 | INFO  | IPC Server handler 5 on 25000 | updatePipeline(blk_2622458507_1548723541 => blk_2622458507_1548733441) success | FSNamesystem.java:6398   最终BLOCK文件在2020-09-01 10:24:45写入成功。        2020-09-01 10:23:03,626 | INFO  | IPC Server handler 18 on 25000 | BLOCK* fsync: /hbase/WALs/wn19usddndb1155,21302,1557575941378/wn19usddndb1155%2C21302%2C1557575941378.default.1598926599118 for DFSClient_NONMAPREDUCE_-90155922_1 with length: 10753603 | FSNamesystem.java:3946       2020-09-01 10:24:45,075 | INFO  | IPC Server handler 50 on 25000 | DIR* completeFile: /hbase/WALs/wn19usddndb1155,21302,1557575941378/wn19usddndb1155%2C21302%2C1557575941378.default.1598926599118 is closed by DFSClient_NONMAPREDUCE_-90155922_1 with last block BP-2086675285-11.36.158.198-1442389176542:blk_2622458507_1548733441 of size 127580481 | FSNamesystem.java:3452    2. HDFS侧日志分析，2020-09-01 10:16:39 NameNode接收到写文件的请求并提供pipeline。        2020-09-01 10:16:39,121 | INFO  | IPC Server handler 46 on 25000 | BLOCK* allocate blk_2622458507_1548723541{UCState=UNDER_CONSTRUCTION, truncateBlock=null, primaryNodeIndex=-1, replicas=[ReplicaUC[[DISK]DS-dc550f75-443d-4179-9a62-1bce7e12cf36:NORMAL:11.58.20.19:25009|RBW], ReplicaUC[[DISK]DS-b05c90ca-acee-4196-b04c-b359f3f37013:NORMAL:11.58.8.11:25009|RBW], ReplicaUC[[DISK]DS-e3366ac3-7c7c-412e-b01c-2d767a21774b:NORMAL:11.58.8.13:25009|RBW]]}, replicas=11.58.20.19:25009, 11.58.8.11:25009, 11.58.8.13:25009 for /hbase/WALs/wn19usddndb1155,21302,1557575941378/wn19usddndb1155%2C21302%2C1557575941378.default.1598926599118 | FSNamesystem.java:3554       11.58.20.19  DataNode日志分析,存在Slow BlockReceiver write packet to mirror（DataNode以Packet作为数据传输单位）       2020-09-01 10:17:15,149 | WARN  | DataXceiver for client DFSClient_NONMAPREDUCE_-90155922_1 at /11.58.20.19:50620 [Receiving block BP-2086675285-11.36.158.198-1442389176542:blk_2622458507_1548723541] | Slow BlockReceiver write packet to mirror 11.58.8.11:25009 for block BP-2086675285-11.36.158.198-1442389176542:blk_2622458507_1548723541 took 2204ms (threshold=300ms) | BlockReceiver.java:587           在10:23:03,569的时候，11.58.20.19和11.58.8.11连接中断       2020-09-01 10:23:03,569 | WARN  | PacketResponder: BP-2086675285-11.36.158.198-1442389176542:blk_2622458507_1548723541, type=HAS_DOWNSTREAM_IN_PIPELINE, downstreams=2:[11.58.8.11:25009, 11.58.8.13:25009] | IOException in BlockReceiver.run():  | BlockReceiver.java:1411        java.io.IOException: Connection reset by peer           通过以上RegionServer和DataNode节点日志分析，可以看出在2020-09-01 10:16:39到2020-09-01 10:23:03期间，数据写WAL时，HDFS数据同步链路出现了中断（同时导致Memstore Flush阻塞），最终导致了大量请求超时        进一步分析节点断链的原因，统计DataNode的日志可以看到其中Slow BlockReceiver write packet出现的频繁较高， 因此集群节点间数据传输延迟甚至闪断的可能性非常大   问题解决参考 单节点网络故障导致datanode同步数据失败，从而导致写wal慢，整改网络。

日志存储路径：HBase相关日志的默认存储路径为“/var/log/Bigdata/hbase/角色名”。HMaster：“/var/log/Bigdata/hbase/hm”（运行日志），“/var/log/Bigdata/audit/hbase/hm”（审计日志）。RegionServer：“/var/log/Bigdata/hbase/rs”（运行日志），“/var/log/Bigdata/audit/hbase/rs”（审计日志）。ThriftServer：“/var/log/Bigdata/hbase/ts”（运行日志），“/var/log/Bigdata/audit/hbase/ts”（审计日志）。日志归档规则：HBase的日志启动了自动压缩归档功能，缺省情况下，当日志大小超过30MB的时候（此日志文件大小可进行配置，详情请参见“配置日志级别与文件大小”），会自动压缩，压缩后的日志文件名规则为：：“<原有日志名>-<yyyy-mm-dd_hh-mm-ss>.[编号].log.zip”。最多保留最近的20个压缩文件，压缩文件保留个数可以在FusionInsight Manager界面中配置。运行日志说明：1. HMaster日志：hbase-omm-matser-<hostname>.logmaster运行日志，记录master实例启动和运行信息、region迁移的详细和regionserver的宕机日志信息。hbase-omm-matser-<hostname>.outmaster运行环境信息日志，启动时如果加载的JVM参数异常会在日志中打印。matser-omm-<DATE>-<PID>-gc.logmaster GC日志。checkServiceDetail.log服务和实例的健康检查结果日志。hbase.log健康检查脚本以及部分告警检查脚本执行产生的详细日志。stop.logmaster进程停止操作记录日志。hbase-audit-master.logmaster审计日志，记录表的创建、删除、disable操作。2. regionserver日志：hbase-omm-regionserver-<hostname>.logregionserver运行日志，记录regionserver实例启动和运行的信息，region的flush、compaction、split、open、close操作记录，WAL日志的落盘情况、responseTooSlow详细信息等。hbase-omm-regionserver-<hostname>.outregionserver运行环境信息日志，启动时如果加载的JVM参数异常会在日志中打印。regionserver-omm-<DATE>-<PID>-gc.logregionserver GC日志。checkServiceDetail.logregionsever实例的健康检查结果日志hbase.log健康检查脚本以及部分告警检查脚本执行所产生的日志。stop.logregionserver进程停止操作记录日志。hbase-audit-regionserver.logregionserver审计日志。

直播回放https://bbs.huaweicloud.com/live/cloud_live/202012241900.html内容讲解材料请参考附件实操材料课程名称链接HBase通用API使用样例https://bbs.huaweicloud.com/forum/thread-90741-1-1.htmlHBase Rest接口调用样例https://bbs.huaweicloud.com/forum/thread-90746-1-1.htmlHBase thrift接口调用样例https://bbs.huaweicloud.com/forum/thread-90749-1-1.html

问题分析：1.从业务代码分析，耗时主要耗在建立连接上。2.第一次创建connection，缓存本身就不包含token，所以属于正常现象。DEBUG org.apache.hadoop.hbase.security.token.AuthenticationTokenSelector - No matching token found3.不过分析日志，在一分钟内出现多次No matching token found,说明connection是每次都重新创建的，业务日志显示创建连接耗时30s+。4. 产品文档对HBase的开发规范中有对共享链接的描述问题解决参考     修改样例代码，保证共享Configuration实例，从而保证HConnection单例更多源码分析请参考 https://bbs.huaweicloud.com/blogs/233090

       在实际应用中，需要存储大大小小的数据，比如图像数据、文档。小于10MB的数据一般都可以存储在HBase上，对于小于100KB的数据，HBase的读写性能是最优的。如果存放在HBase的数据大于100KB甚至到10MB大小时，插入同样个数的数据文件，但是总的数据量会很大，会导致频繁的compaction和split，占用很多CPU，磁盘IO频率很高，性能严重下降。通过将MOB（Medium-sized Objects）数据（即100KB到10MB大小的数据）直接以HFile的格式存储在文件系统上（例如HDFS文件系统），通过expiredMobFileCleaner和Sweeper工具集中管理这些文件，然后把这些文件的地址信息及大小信息作为value存储在普通HBase的store上。这样就可以大大降低HBase的compation和split频率，提升性能。HBase当前默认开启MOB功能，相关配置项如表1所示。如果需要使用MOB功能，用户需要在创建表或者修改表属性时在指定的列族上指定使用mob方式存储数据       为了开启HBase MOB功能，用户需要在创建表或者修改表属性时在指定的列族上指定使用mob方式存储数据。使用代码声明使用mob存储的方式：HColumnDescriptor hcd = new HColumnDescriptor("f"); hcd.setMobEnabled(true);使用shell声明使用mob的方式，MOB_THRESHOLD单位是字节：hbase(main):009:0> create 't3',{NAME => 'd', MOB_THRESHOLD => '102400', IS_MOB => 'true'} 0 row(s) in 0.3450 seconds => Hbase::Table - t3 hbase(main):010:0> describe 't3' Table t3 is ENABLED t3 COLUMN FAMILIES DESCRIPTION {NAME => 'd', MOB_THRESHOLD => '102400', VERSIONS => '1', KEEP_DELETED_CELLS => 'FALSE', DATA_BLOCK_ENCODING => 'NONE',  TTL => 'FOREVER', MIN_VERSIONS => '0', REPLICATION_SCOPE => '0', BLOOMFILTER => 'ROW', IN_MEMORY => 'false', IS_MOB => 'true', COMPRESSION => 'NONE', BLOCKCACHE => 'true', BLOCKSIZE => '65536'} 1 row(s) in 0.0170 seconds参数入口：在MRS Manager系统中，选择“集群 > 待操作集群的名称 > 服务 > HBase > 配置”，单击“全部配置”。在搜索框中输入参数名称。表1 参数描述参数描述默认值hbase.mob.file.cache.size缓存打开文件句柄的个数。如果该值设置的比较大，cache可以缓存更多的文件句柄，从而降低打开关闭文件的频率。但是如果该值设置过大会导致打开的文件句柄数过多。默认值是：“1000”。此参数在服务端ResionServer上配置。1000hbase.mob.cache.evict.periodmob cache回收缓存的mob文件的周期，默认是3600s。3600hbase.mob.cache.evict.remain.ratiomob cache回收之后保留的文件个数占cache容量个数的比例，当缓存的文件个数超过hbase.mob.file.cache.size设置的值之后会触发mob cache回收。0.5hbase.master.mob.ttl.cleaner.periodExpiredMobFileCleanerChore的执行周期，以秒为单位。默认值是一天(86400秒)。说明： 如果生存时间值过期了，即文件从创建起已经超过了24小时，则MOB文件将会被过期mob文件清理工具删除。86400

操作场景Flume采集文件内容导入到habse前提条件·         已创建启用Kerberos认证的流集群。·         已在日志生成节点安装Flume客户端，请参见安装Flume客户端。·         已配置网络，使日志生成节点与流集群互通。操作步骤(1)  从HBase客户端拷贝配置文件hbase-site.xml到Flume Client的配置目录 " /opt/FlumeClient/fusioninsight-flume-1.6.0/conf" 下。通常可以在分析集群Master节点HBase客户端安装目录如“/opt/client/HBase/hbase/conf/”下找到hbase-site.xml文件。(2)  从MRS集群下载用户的认证凭据。①在MRS Manager，单击“系统设置”。 ②在“权限配置”区域，单击“用户管理”。 ③在用户列表中选择需要的用户，单击后面的“更多”下载用户凭据。 ④解压下载的用户凭据文件，获取krb5.conf和user.keytab文件。(3) 将上一步获得的krb5.conf和user.keytab拷贝到Flume Client所在节点的配置目录 " /opt/FlumeClient/fusioninsight-flume-1.X.X/conf" 下。（4）修改配置文件jaas.conf，        ① 将/opt/Bigdata/MRS_x.x.x/1_x_Flume/etc/" 的jaas.conf文件拷贝到/opt/FlumeClient/fusioninsight-flume-1.X.XS/conf下②  修改jaas.conf文件中的参数principal 与keyTabPrincipal: 可以kinit 用户名进行认证查看参数keyTab: 定义的用户认证文件完整路径即步骤(1)中保存user.keytab认证文件的目录 (5) 修改配置文件flume-env.sh，文件所在目录 /opt/FlumeClient/fusioninsight-flume-1.6.0/conf。在 “-XX:+UseCMSCompactAtFullCollection”后面，增加以下内容：-Djava.security.krb5.conf=/opt/FlumeClient/fusioninsight-flume-1.6.0/conf /krb5.conf -Djava.security.auth.login.config=/opt/FlumeClient/fusioninsight-flume-1.6.0/conf /jaas.conf -Dzookeeper.request.timeout=120000 krb5.conf与jaas.conf根据实际情况，修改配置文件路径，然后保存并退出配置文件。（6）假设Flume客户端安装路径为“/opt/FlumeClient”，执行以下命令，重启Flume客户端：cd /opt/FlumeClient/fusioninsight-flume-1.6.0/bin./flume-manage.sh restart （7）执行以下命令，修改Flume客户端配置文件“properties.properties”。vi Flume客户端安装目录/fusioninsight-flume-1.6.0/conf/properties.properties将以下内容保存到文件中：client.sources = r1  client.sinks   = k1    client.channels   = c1  #   Describe/configure the sourceclient.sources.r1.type   = spooldir #实时读取本地目录client.sources.r1.spoolDir   = /tmp/data/client.sources.r1.trackerDir   = /tmp/data/tracker/client.sources.r1.fileSuffix   = .COMPLETEDclient.sources.r1.deletePolicy=   neverclient.sources.r1.fileHeader   = true client.sources.r1.channels   = c1  client.sources.r1.batchSize   = 100#   Use a channel which buffers events in memoryclient.channels.c1.type   = memory  client.channels.c1.capacity   = 10000client.channels.c1.transactionCapacity   = 100 client.sinks.k1.type   = hbase#表名client.sinks.k1.table   = movie#列组client.sinks.k1.columnFamily   = analyse#通配符(数据格式为        1001,猫,9   )client.sinks.k1.serializer.regex   =(.*),(.*),(.*)client.sinks.k1.serializer   = org.apache.flume.sink.hbase.RegexHbaseEventSerializerclient.sinks.k1.channel   = c1 #列client.sinks.k1.serializer.colNames   = ROW_KEY,movie_name,rating# 索引为0，即ROW_KEY(ROW_KEY是特殊字符)client.sinks.k1.serializer.rowKeyIndex   = 0client.sinks.k1.kerberosPrincipal   = 用户名client.sinks.k1.kerberosKeytab=/opt/FlumeClient/fusioninsight-flume-1.6.0/conf/user.keytab  client.sinks.k1.kerberosPrincipal   用户名client.sinks.k1.kerberosKeytab    user.keytab文件路径指定（8）添加数据         创建测试数据         vim /tmp/data/test1.txt1001,tom,31002,jerry,51003,jack,4 （9）创建hbase表hbase(main):001:0> create 'movie','analyse' 

HBase meta元数据恢复案例参考博文：  https://bbs.huaweicloud.com/blogs/210218

背景在Hbase使用过程中，使用的Hbase集群经常会因为某些原因需要数据迁移。大多数情况下，可以跟用户协商用离线的方式进行迁移，迁移离线数据的方式就比较容易了，将整个Hbase的data存储目录进行搬迁就行，但是当集群数据量比较多的时候，文件拷贝的时间很长，对客户的业务影响时间也比较长，往往在客户给的时间窗口无法完成，本文给出一种迁移思路，可以利用Hbase自身的功能，对集群进行迁移，减少集群业务中断时间。简介大家都知道Hbase有snapshot快照的功能，利用快照可以记录某个时间点表的数据将其保存快照，在需要的时候可以将表数据恢复到打快照时间时的样子。我们利用Hbase的snapshot可以导出某个时间点的全量数据。因为用户的业务还在不停的写入表中，除了迁移快照时间点之前的全量数据，我们还需要将快照时间点后源源不断的增量数据也迁移走，这里如果能采用双写的方式，将数据写入两个集群就好了，但是用户的业务不会这样做，如果这样做还得保证双写的事务一致性。于是可以利用Hbase的replication功能，replication功能本身就是保留了源集群的WAL日志记录，去回放写入到目的集群，这样一来用户业务端->原始集群->目的集群便是个串形的数据流，且由Hbase来保证数据的正确性。所以这个迁移的方法就是利用snapshot迁移全量数据，利用replication迁移增量数据。迁移步骤上图给出了迁移的整个时间线流程，主要有这么5个时间点。T0： 配置好老集群A集群到新集群B的Replication关系，Replication的数据由A集群同步到集群B，将表设置成同步，从此刻开始新写入A集群表的数据会保留在WAL日志中；T1： 生成该时间点的全量数据，通过创建快照，以及导出快照数据的方式将该时间点的数据导出到新集群B；T2： 新集群B将T1时刻的快照数据导入，此时新集群B中会由快照创建出表，此时老集群A集群上设置的Replication的关系会自动开始将T0时刻保留的WAL日志回放至新集群B的表中，开始增量数据同步。T3： 由于从T0-T3之间的操作会花费一段时间，此时会积累很多WAL日志文件，需要一定的时间来同步至新集群，这里需要去监控一下数据同步情况，等老集群WAL被逐渐消费完，此时可以将老集群的写业务停止一下并准备将读写业务全部切到新集群B。T4： T3-T4之间应该是个很短的时间，整个迁移也只有这个时间点会有一定中断，此时是让用户将业务完全切到新集群B，至此迁移完成。操作涉及的命令1.设置集群A和集群B的peer关系在源集群Hbase shell中, 设定peeradd_peer 'peer_name','ClusterB:2181:/Hbase'2.在集群A的表中设置replication属性假设目标表名为Student，先获取Family=f进入Hbase shell中，alter 'Student',{NAME => 'f',REPLICATION_SCOPE => '1'}3.给集群A的表创建快照在Hbase shell中snapshot 'Student','Student_table_snapshot'4.在A集群中导出快照Hbase org.apache.hadoop.Hbase.snapshot.ExportSnapshot -snapshot Student_table_snapshot -copy-to /snapshot-backup/Student5.将快照数据放置到集群B的对应的目录下上面命令会导出2个目录，一个是快照元数据，一个是原始数据将元数据放到/Hbase/.Hbase-snapshot中，将原始数据放到/Hbase/archive目录中由于Hbase的archive目录会有个定时清理，这里可以提前将集群B的master的Hbase.master.cleaner.interval值设置大点，避免拷贝过程中发生碰巧发生了数据清理。如果集群B中没有对应的目录，可以提前创建hdfs dfs -mkdir -p /Hbase/.Hbase-snapshothdfs dfs -mkdir -p /Hbase/archive/data/default/移动导出的snapshot文件到snapshot目录hdfs dfs -mv /snapshot-backup/Student/.Hbase-snapshot/Student_table_snapshot /Hbase/.Hbase-snapshot/hdfs dfs -mv /snapshot-backup/Student/archive/data/default/Student /Hbase/archive/data/default/6.在新集群B中恢复表的快照进入Hbase shellrestore_snapshot 'Student_table_snapshot'恢复完成后，记得将集群B的hmaster中Hbase.master.cleaner.interval的值调整回来。

在HBase使用过程中，使用的HBase集群经常会因为某些原因需要数据迁移。大多数情况下，可以跟用户协商用离线的方式进行迁移，迁移离线数据的方式就比较容易了，将整个hbase的data存储目录进行搬迁就行，但是当集群数据量比较多的时候，文件拷贝的时间很长，对客户的业务影响时间也比较长，往往在客户给的时间窗口无法完成，本文给出一种迁移思路，可以利用HBase自身的功能，对集群进行迁移，减少集群业务中断时间。原文地址   https://bbs.huaweicloud.com/blogs/199399

详细介绍了kudu的设计初衷及与hbase的比较原文地址   https://bbs.huaweicloud.com/blogs/198695

在HBase 1.x中，经常会遇到元数据不一致的情况，这个时候使用HBCK的命令，可以快速修复元数据，让集群恢复正常。另外HBase数据迁移时，大家经常使用到一种迁移方式是：拷贝HBase的数据目录/hbase/data/default到新的集群，然后在新集群执行HBCK的命令让元数据重建，这种拷贝数据目录然后恢复元数据的方式是一种快速直接的手段。HBase升级到2.X版本之后，hbase hbck中的一些修复命令已经不再支持，包括，所以在HBase遇到集群故障，无法通过HBCK快速把元数据修复，通过HBase数据目录迁移的方式也就使用不了。在HBase 2.X的客户端执行hbase hbck时，常用的fixMeta命令已经不再支持。原文地址：https://bbs.huaweicloud.com/blogs/199075