问题分析      根据regionserver运行日志发现RS与zk之间的session连接超时达到172s，正常情况下，regionserver与zookeeper之间的心跳连接超时时间为90s，如果超过90s，zookeeper没有收到regionserver的心跳连接，zookeeper会认为zookeeper发生了异常，会将regionserver重启，与客户确认发现客户环境将regionserver的GC内存配置为64G，导致每次GC时间特别久；修改HBase服务端参数zookeeper.session.timeout和zk 服务端 的maxSessionTimeout增大到15min，观察几天没有出现regionserve重启问题。问题解决参考   调小GC配置为31G。增大HBase服务端参数zookeeper.session.timeout和zk 服务端参数maxSessionTimeout。

问题分析查看发生异常重启regionserver运行日志(/var/log/Bigdata/hbase/rs/hbase-omm-regionserver-xxx.log)查找重启的原因，发现是写WALs超过5min触发了regionserver的重启保护机制。查看该regionserver运行日志的slow sync cost的时间，发现耗时都非常长,slow sync cost耗时长一般都是由于dn的性能慢（写磁盘慢或者网络慢导致）。使用grep "write data to disk" hadoop-omm-datanode-DSJ-FS-FI-0620.2020-09-24_08-23-56.\[1\].log| grep "2020-09-24 04:5"命令查看对应时刻是否有写磁盘慢的打印。使用grep "Slow flushOrSync" hadoop-omm-datanode-DSJ-FS-FI-0620.2020-09-24_08-23-56.\[1\].log| grep "2020-09-24 04:5"命令查看对应时刻是否有磁盘刷盘慢的打印。FlushOrsync耗时长意味着存在慢盘或者磁盘坏道较多的盘。需要进一步排查磁盘。问题解决参考      慢盘或者磁盘坏道导致写wal卡住，更换磁盘。

问题分析检查RegionServer运行日志(/var/log/BigData/hbase/rs/hbase-omm-regionserver-xxx.log)，其中报错该节点与HMaster节点的时间差大于30s；具体报错如下:Master rejected startup because clock is out of sync| org.apache.hadoop.hbase.regionserver.HRegionServer.reportForDutyorg.apache.hadoop.hbase.ClockOutOfSyncException:org.apache.hadoop.hbase.ClockOutOfSyncException:Server hdfs02,21302,xxxx has been rejectd;Reported time is too far out of sync with master.Time difference of 88759ms >max allowed of 30000ms检查异常重启regionserver节点的NTP服务状态，NTP一直是初始化的状态；检查/etc/ntp.conf文件配置异常，与其他节点不一致，从正常其他regionserver节点拷贝/etc/ntp.conf文件到本节点后重启NTP服务后，NTP状态恢复正常；等时间同步后重启实例，恢复正常。问题解决参考       NTP服务异常导致RegionServer节点时间与HMaster节点时间差超过30s，从而导致RegionServer重启，恢复NTP服务，重启RegionServer实例。

问题分析查看regionserver运行日志(/var/log/Bigdata/hbase/rs/hbase-omm-regionserver-xxx.log)，发现regionserver重启时间在11.49；查看该异常节点的nodeagent日志(/var/log/Bigdata/nodeagent/agentlog/agent.log)，11:49分之前健康检查多次超时；查看异常节点的hbase 实例检查日志（/var/log/Bigdata/hbase/rs/checkServiceDetail.log），大部分检查都没打印出success，说明实例检查时间超时，上一次健康检查时间过长，本次健康检查删除上一次健康检查pid文件；查看hbase.log（（/var/log/Bigdata/hbase/rs/hbase.log），健康检查时间超过了4分钟和5分钟，超过了nodeagent调用的超时脚本；问题根因在于 regionserver处理健康检查请求超过了4分钟，分析regionserver的GC日志(/var/log/Bigdata/hbase/rs/regionserver-omm-xxx-pidxxx-gc.log.x.current)，使用的是g1算法；gc 日志证明内存使用达到40G，regionserver处理时延时较高，占用内存的原因为，tagramzone表列未合并，导致查询性能下降handler被使用完。问题解决参考           Tagamzone表列未合并，如果没有开启异步合并，那就会进行同步合并，开启了，但是如果创建表的参数不对，也会不合并也会有问题，该问题为未开启异步合并导致查询处理性能下降 handler被使用完，需业务侧进行整改。具体需要如下2步骤配合使用，如下所示：服务端修改如下tagram.tagzone.dynamitag.async.compact为true代码中进行如下设置：

如题，我们想验证下HBase的性能，请问用哪种工具比较好？

问题分析分析HMaster运行日志(/var/log/Bigdata/hbase/hm/hbase-omm-hmaster-xxx.log)以及.out(/var/log/Bigdata/hbase/hm/hbase-omm-hmaster-xxx.out)的日志，未见明显异常，说明不是运行时内部错误引起；查看操作系统日志(/var/log/osinfo/statistics/dmesg_xxx.txt)，不是系统kill掉； 查看该节点的nodeagent(/var/log/Bigdata/nodeagent/agentlog/agent.log)日志，发现检查脚本执行超时，被nodeagent判定为非健康状态； CPU内存运行状态正常；查看nodeagent和controller的心跳信息，发现中间三分钟心跳中断，nodeagent本身出问题导致脚本执行超时；  6. nodeagent依赖底层磁盘性能，查看对应时刻，底层磁盘性能确实存在冲高；7. 排查客户业务，发现和客户操作有关，传输大文件导致。问题解决参考        客户业务侧传输文件过大，分割文件避免传出大文件

问题分析1. 该异常一般是由于写入过快导致hbase服务端memstore超过了memstore block的阈值。 具体源码如下：          2. 问题一般有三种可能原因：1)、首选需要确认服务端GC参数是否配置过小导致数据在写入的时候很快达到memstoreSize超过阈值。如果是，需要调大GC参数，一般regionserver GC参数调整为为31G.2）、如果排除GC原因，可能为region存在热点，导致所有请求都集中到了某几个regionserver上，导致该regionserver压力过大，写入速度过快从而报regionTooBusy。            3)、Region为均匀的，但是客户端业务写入速度过快导致regionserver的memstore增长速度快于flush的速度，数据在memstore中进行挤压，导致了该异常。问题解决参考GC参数配置过小的话，需要将GC参数调大。如果是region存在热点，需要将rowkey重新设计或者进行预分区，从而将数据散列。如果是客户端写入速度过快导致，可适当调小客户端的并发或者每个batch的数据量，或者适当调大flush和compaction的速度。

# 公安户籍系统数据库迁移（使用BulkLoad 向 HBase 中批量导入数据） ## 一、背景介绍 ### 1. 概述 我们经常面临向 HBase 中导入大量数据的情景。 往HBase 中批量加载数据的方式有很多种，最直接方式是调用HBase 的API用put方法插入数据；另外一种是用MapReduce的方式从hdfs上加载数据，调用TableOutputFormat 类在reduce中直接生成put对象写入HBase（这种方式可以看作多线程的调用hbase API方式）；但是这两种方式效率都不是很高，因为HBase会频繁的进行flush、compact、split操作，需要消耗较大的 CPU 和网络资源，并且region Server压力也比较大。 BulkLoad 方式调用MapReduce的job直接将数据输出成HBase table内部的存储格式的文件HFile，然后将生成的StoreFiles 加载到集群的相应节点。这种方式无需进行flush、compact、split等过程，不占用region资源，不会产生巨量的写入 I/O，所以需要较少的 CPU 和网络资源。在首次数据加载时，能极大的提高写入效率，并降低对Region Server节点的写入压力。 ### 2. BulkLoad导入流程 BulkLoad涉及两个过程： 1. Transform阶段：使用MapReduce将HDFS上的数据生成成HBase的底层Hfile数据。 2. Load阶段：根据生成的目标HFile，利用HBase提供的BulkLoad工具将HFile Load到HBase的region中。 ### 3. bulkload和put适合的场景： - bulkload适合的场景： - 大量数据一次性加载到HBase。 - 对数据加载到HBase可靠性要求不高，不需要生成WAL文件。 - 使用put加载大量数据到HBase速度变慢，且查询速度变慢时。 - 加载到HBase新生成的单个HFile文件大小接近HDFS block大小。 - put适合的场景： - 每次加载到单个Region的数据大小小于HDFS block大小的一半。 - 数据需要实时加载。 - 加载数据过程不会造成用户查询速度急剧下降。 ### 4. Bulkload批量导入数据shell操作步骤： 1. 将数据导入到HDFS中 2. 建表并创建导入模板文件 3. 执行命令，生成HFile文件 4. 执行命令将HFile导入HBase ## 二、示例 ### 1. 场景描述 陕西省西安市2018年全市户籍总人口905.68万人，公安系统现在需要把这些人口信息从原来的数据存储库迁移至HBase中。 ### 2. 原始数据 原始数据person_information.txt文件中人口信息按行分别为： 身份证号，姓名，出生年月，性别，户籍所在区县 610122000000001001,陈精业,19940524,男,蓝田县 610102000000001002,王军林,19870402,男,新城区 610111000000001003,田心亚,19681103,女,灞桥区 610125000000001004,王朝辉,19970608,男,鄠邑区 610112000000001005,冯诗雨,19900801,女,未央区 610112000000001006,黄秋野,19990505,男,未央区 610122000000001007,彭云超,20011205,男,蓝田县 610116000000001008,尤丽雯,19981123,女,长安区 610104000000001009,龚小刚,20050817,男,莲湖区 610124000000001010,兰春元,19870609,女,周至县 610115000000001011,王苏涛,19881107,男,临潼区 610114000000001012,周东来,19761028,男,阎良区 610103000000001013,邱维坚,19770929,男,碑林区 610116000000001014,卓鹏宇,19730726,男,长安区 610104000000001015,尤丽雯,19690317,女,莲湖区 610102000000001016,张雪红,19820109,女,新城区 610104000000001017,赵静静,19660527,女,莲湖区 610124000000001018,曹笑天,19980616,女,周至县 610112000000001019,李晓萍,19851114,女,未央区 610115000000001020,牛红艺,19930520,女,临潼区 ### 3. shell操作步骤 #### 1.将数据导入到HDFS中 HBase不管理数据提取这部分过程。 通常需要导入的外部数据都是存储在其它的关系型数据库或一些文本文件中，我们需要将数据提取出来并放置于 HDFS 中。也借助 ETL工具可以解决大多数关系型数据库向 HDFS 迁移数据的问题。 例如，我们可以在一个表上运行mysqldump（mysql数据库中备份工具，用于将MySQL服务器中的数据库以标准的sql语言的方式导出保存到文件中。）并将结果文件上传到HDFS。 执行命令： - 在HDFS上创建一个目录例如/user/testBulkload ``` hdfs dfs -mkdir /testBulkload ``` - 把linux本地/opt目录下person_information.txt文件传到HDFS上/testBulkload目录下 ``` hdfs dfs -put /opt/person_information.txt /user/testBulkload ``` - 可使用下面命令查看一下 ``` hdfs dfs -cat /user/testBulkload/person_information.txt ``` 结果展示：  #### 2.建表并自定义导入模板文件 建表： 需要根据导入数据，设计好HBase数据表的表名、rowkey、列族、列，考虑好row key分配在创建表时进行预分割。 根据源数据和业务设计表，在hbase shell下执行命令： - person_information_table:表名 - NAME => 'base'：列族名称。 - COMPRESSION：压缩方式 - DATA_BLOCK_ENCODING：编码算法 - SPLITS：预分region ``` create  'person_information_table', {NAME => 'base',COMPRESSION => 'SNAPPY',  DATA_BLOCK_ENCODING => 'FAST_DIFF'},SPLITS => ['1','2','3','4','5','6','7','8'] ``` #### 3. 执行如下命令，生成HFile文件 命令模板： ``` hbase com.huawei.hadoop.hbase.tools.bulkload.IndexImportData -Dimport.skip.bad.lines=true -Dimport.separator= -Dimport.bad.lines.output= -Dimport.hfile.output= ``` - -Dimport.separator：分隔符。例如，-Dimport.separator=',' - -Dimport.skip.bad.lines：指定值为false，表示遇到不适用的行则停止执行。指定值为true，表示遇到不适用的数据行则跳过该行继续执行，如果没有在configuration.xml中定义不适用行，该参数不需要添加。 - -Dimport.bad.lines.output=：指的是不适用的数据行输出路径，如果没有在configuration.xml中定义不适用行，该参数不需要添加。 - -Dimport.hfile.output= /path/for/output>：指的是执行结果输出路径。 - configuration xmlfile>：指向configuration配置文件,本样例可将附件中configuration_index.xml放置在/opt目录。 - tablename>：指的是要操作的表名。 - inputdir>：指的是要批量上传的数据目录。 - com.huawei.hadoop.hbase.tools.bulkload.IndexImportData：导入时创建二级索引使用IndexImportData；如果不创建二级索引，使用ImportData 根据场景业务执行命令： ``` hbase com.huawei.hadoop.hbase.tools.bulkload.ImportData -Dimport.separator=',' -Dimport.hfile.output=/user/testBulkload/hfile /opt/configuration_index.xml person_information_table /user/testBulkload/person_information.txt ``` 结果展示： base列族数据生成hfile  #### 4.执行如下命令将HFile导入HBase 执行命令： - /testBulkload/hfile ：hfile在HDFS上的位置 - person_information_table ： hbase表名 ``` hbase org.apache.hadoop.hbase.mapreduce.LoadIncrementalHFiles /user/testBulkload/hfile person_information_table ``` 结果展示： 表中部分数据： 

### XX银行文件数据存储业务场景（Phoenix高效批量插入） #### 一、背景 生产场景是之一是：每分钟一个文件，一个文件65431条数据。后期业务的数据量还会成2-3倍增加（因为性能不能满足后期业务，目前没有把表往phoenix进行迁移）。 ##### 1.1 业务主要诉求 通过java读取文件的数据,处理后调用fiber（fiber引擎为phoenix）的接口进行数据入库，实现高效批量数据插入。期望phoenix入库性能能达到30w/每分钟每张表。 ##### 1.2 支持版本 支持MRS-302版本,其他版本需要适配 #### 二、调优过程 因为目前测试是单线程并且只是单次的数据、数据量不大，且根据测试结果我们可以采取以下优化方式: 1. 表加盐 2. 客户端并发 3. 关闭autocommit，由自己的代码控制每次提交的条数，试试每500~1000条commit一次。 4. 对比测试本地索引和全局索引 #### 三、调优总结 java调用fiber（fiber引擎为phoenix）的接口进行数据入库实现高效批量数据插入。 通过两次对比测试可以得出以下调优方式： 1. 根据数据量，多次调整表的盐值，达到最优效果 2. 根据数据量，多次调整线程数量，达到最优效果 3. 根据数据大小，调整每次commit提交的数据条数，达到最优效果 4. 使用本地索引插入性能更好 #### 四、样例代码及操作步骤 1. 将附件样例代码导入idea工程。 2. 将Fiber客户端下的fiber.xml拷贝到/home/Fiber/fiber.xml下 3. idea对工程打包，并将jar包上传到hbase客户端lib目录下 4. 将工程lib目录下依赖的jar包也上传 hbase客户端lib目录下 5. 将hbase客户端lib目录下phoenix-core-5.0.0-HBase-2.0-hw-ei-302002.jar拷贝到lib目录下的jdbc目录。 6. 运行如下指令 在hbase客户端下进入jdbc操作窗口： ``` bin/sqlline.py ``` (删除已存在表，若不存在可选操作）： ``` drop table PRODUCT_PHOENIX; ``` 创建表： ``` create table PRODUCT_PHOENIX (rowkey VARCHAR PRIMARY KEY,time VARCHAR(14),type INTEGER,service INTEGER,flag INTEGER,sal_id INTEGER,station_id INTEGER,error DOUBLE) SALT_BUCKETS=6; ``` 说明：6是盐值 创建本地索引表： ``` Create local INDEX INDEX_PRODUCT_PHOENIX ON PRODUCT_PHOENIX(time,type,service,flag,sal_id,station_id) INCLUDE(error); ``` (创建全局索引表，与本地索引二选一）： ``` Create INDEX INDEX_PRODUCT_PHOENIX ON PRODUCT_PHOENIX(time,type,service,flag,sal_id,station_id) INCLUDE(error); ``` 7. 在hbase 客户端下执行命令写入数据 ``` hbase com.huawei.fiber.example.runner.Worker ```  8. 结果查询 ``` select count(*) from PRODUCT_PHOENIX; ``` 

说明：如下案例针对 FusionInsight HD C70版本，其中HBase对应开源版本1.0.21、创建索引之前，必须先有表，进入hbase shell创建，示例表名 index_test，包含列簇 cf1 和 cf2 create 'index_test','cf1','cf2' 2、创建索引，客户端ssh登录后执行，不需要进入hbase shell语法：hbase org.apache.hadoop.hbase.index.mapreduce.TableIndexer -Dtablename.to.index=<table_name> -Dtable.columns.index='IDX1=>cf1:[q1->datatype&length];cf2:[q1->datatype&length],[q2->datatype&length],[q3->datatype& lenght]#IDX2=>cf1:[q5->datatype&length]'示例执行如下：hbase org.apache.hadoop.hbase.index.mapreduce.TableIndexer -Dtablename.to.index=index_test -Dtable.columns.index='IDX1=>cf1:[q1->String&100];cf2:[q1->String&20],[q2->String&30],[q3->String&10]#IDX2=>cf1:[q5->String&10]' •IDX1：索引名称•cf1：列族名称。•q1：列名。•datatype：数据类型。数据类型仅支持Int、String、Double、Float类型。•length：值的最大长度。3、查询出索引字段通过HBase 的WEBUI页面查看表定义确认索引信息，如下图，在index_test表之外有一个对应的索引表 index_test_idx表index_test的索引名称通过 METADATA可查看，对应的是其创建时间4、删除索引参考命令如下hbase org.apache.hadoop.hbase.index.mapreduce.TableIndexer -Dtablename.to.index=index_test -Dindexname.to.drop='IDX1#IDX2'执行完毕后，index_test_idx表自动删除，index_test表的METADATA信息自动更新

问题分析HBase客户端scan和写失败，具体报错如下：org.apache.hadoop.hbase.client.RetriesExhaustedWithDetailsException: Failed 110 actions: IOException: 110 times, servers with issues: pdccsbdspapp105,21302,1529524454464查看服务端gc日志确认gc是否正常。如果有full gc，需要确认是否是服务端gc参数配置不合理，如果gc参数配置正常，需要排查业务变化情况。应用端读写都采用线程池策略，当数据量少时，向服务端的并发请求少，数据量大时，并发请求多。应用端出现上述问题时，服务端分为空闲和不空闲两种情况1). 服务端空闲2). 开启hbase.regionserver.wal.durable.sync=true且出现ResponseTooSlow打印如果服务端空闲，需要打印客户端jstack，打印客户端jstack如果发现大部分线程处于ipc等待连接过程。说明客户端连接在等待，此时说明客户端连接不够用，问题在于hbase.client.ipc.pool.size。此参数控制应用端与HMaster和RegionServer的socket连接数，若应用端是多线程并发读写情况，此参数默认值为1，此socket可能不够，需要将该参数调大，一般值为10左右。    java.lang.Thread.State: TIMED_WAITING (on object monitor)    at java.lang.Object.wait(Native Method)    at org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1265)    - locked <0x00000000ef0b1bc8> (a org.apache.hadoop.hbase.ipc.Call)    at org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:224)问题解决参考如果排查到客户端jstack中存在大量的ipc等待线程，对于应用端开说，多线程并发情况下，需要将hbase.ipc.client.pool.size调整为和并发线程数相同，或者降低并发数，如调高每个批次的batch等。如果是业务侧数据量变大导致，需要调小每个批次的batch或者降低并发线程数。如果排查结果为写HLog慢，需要排查HDFS是否为写磁盘或者网络慢导致HBase写入慢。

问题分析 业务侧报错IOEception连接regionserver异常。hbase hbck检查表状态OK；hdfs fsck检查正常无丢块，查看regionserve日志（hbase-omm-regionserver-<hostname>.log）中无其他任何异常，存在大量的HBase checksum verification failed的打印，此打印说明该region的hfile文件存在损坏。查看dn日志（/var/log/Bigdata/hdfs/dn/hadoop-omm-datanode-<hostname>.log）。发现确实存在hfile文件损坏，从而导致dn无法checksum metafile。文件在HDFS上存储时，被切分成多个128MB的块，每个块有3个副本，3个副本分别存储在不同的DATANODE上，HDFS并不能保证每个副本是完好的。HBASE从HDFS的块中读取数据时，考虑到性能的影响，使用HBASE的checksum代替了HDFS的checksum；但是如果HBASE读取的某个块的某个副本是corrupt的（corrupt的原因很多：比如网络的闪断、磁盘的坏道等等），HBASE并不会读取该块的其他副本，最终导致HBASE的查询/合并失败。此问题为C80版本的一个产品问题，在6513版本解决问题解决参考规避方法：将该文件使用hbase用户get下来，然后再put上去，如果还是不行，对该region进行major compaction操作，compaction操作有延时，compaction后就可以正常查询了，compaction的原因为compaction会重写文件，原来在坏道里面的数据被重写到其他地方。永久解决方案：FI升级到6.5.1.3版本。

 问题分析从03:48 rs日志（hbase-omm-regionserver-<hostname>.log）开始大量打印Memstore is above high water mark and block xx ms,此条语句表明，hbase memstore内存使用已经达到hbase.hregion.memstore.flush.size=128M * 4;从03:55开始，rs日志（hbase-omm-regionserver-<hostname>.log）开始大量打印Blocking updates on pdccjbdspsvr702,21302,1544437515989: the global memstore size 8.0 G is >= than blocking 8.0 G size，说明此时所有region的memstore内存总和开销超过配置上限，默认是配置heap的40%，这会导致写入被阻塞，目的是等待flush的线程把内存里的数据flush下去，否则继续允许写入memestore会把内存写爆;从上述日志表明memstore内存持续上升，memstore内存上升一般是由于put请求量长时间维持在较高水平或者写入量增大，或者写入量不变的情况下，memstore内存中的数据没有及时溢写到磁盘，导致内存数据不能及时回收掉，从而引起memstore内存上升而达到rs内存阈值，当时有写入hdfs慢的slow sync，这两点都能导致memstore内存上升，监控表示当时的请求量不是最大峰值的，重点分析slow sync to datanode如下日志表明，从03:50开始，slow sync的时间有超过10秒的，证明当时写入76.49.50.28:25009 datanode慢;查看当时datanode日志（/var/log/Bigdata/hdfs/dn/hadoop-omm-datanode-<hostname>.log），证明写入磁盘慢，同时写入有大量异常，表明存在磁盘坏道;        如下表明写磁盘慢:                如下日志可以证明磁盘存在坏道:        问题解决参考     磁盘问题导致的读写慢，更换磁盘提高HDFS写入性能       

一、原始需求xx公司需要对公司的某些敏感数据进行监控，将监控数据进行计算分组后进行存储，对实时性要求比较高。二、组件选取该需求主要是实时处理，该样例适用于MRS302版本，其他版本需要自行适配。kafka：kafka作为消息队列。Spark：作为计算引擎。HBase：作为数据存储端。三、系统设计1. 在source端使用Kafka作为消息队列，kafka中存储的数据类型很多，大概有30中数据类型了，以标签tagID作为区分。2. 在sink端会根据不同的数据类型，将数据写入到不同的HBase表中，每种数据类型对应着一张HBase表。四、代码实现代码介绍（代码详见附件）   InitParameters类：用于初始化，加载代码中所需要的配置项。   LoginUtil类：登录需要的类。   SparkToHBaseOnBulkLoad类：主类，实现该样例的所有需求。   ProduceData类：用于造数据。   2. 配置文件   application.properties：配置文件，该文件包含了代码所有需要修改的参数，根据实际情况设置该文件并上传到Spark的conf目录下。   3. 修改代码配置五、代码打包并上传1. 在IDEA工具右侧选择Maven,然后进行相应的编译打包。2. 把打好的jar包上传到服务器上。路径可以自己选择。比如：/opt/xhk,新建lib和resources目录，将打好的jar包给lib目录下也拷贝一份。将kafka客户端libs下jar包拷贝到新建的lib下，将代码中的配置文件拷贝到resources目录下。3. 进行source和kinit操作，并进入到Spark客户端conf目录下，拷贝如下文件到该目录。比如：/opt/wxbClient/Spark2x/spark/conf   - hbase-site.xml、hdfs-site.xml、core-site.xml（获取路径，可以从HDFS或者HBase客户端的conf目录下获取。）   - user.keytab、krb5.conf（Manager页面上下载用户的配置文件）   - application.properties.（项目的resources目录下，并修改里面的参数）4. 配置conf目录下jaas.conf和jaas-zk.conf文件。认证需要的配置文件。     jaas.conf 内容参考如下：   Client {   com.sun.security.auth.module.Krb5LoginModule required   useKeyTab=false   useTicketCache=true   debug=false;   };   KafkaClient {   com.sun.security.auth.module.Krb5LoginModule required   useKeyTab=false   useTicketCache=true   debug=false;   };    jaas-zk.conf 内容参考如下   Client {   com.sun.security.auth.module.Krb5LoginModule required   useKeyTab=true   keyTab="./user.keytab"   principal="wxb@HADOOP_ARM_802.COM"   useTicketCache=false   storeKey=true   debug=true;   };   KafkaClient {   com.sun.security.auth.module.Krb5LoginModule required   useKeyTab=true   keyTab="./user.keytab"   principal="wxb@HADOOP_ARM_802.COM"   useTicketCache=false   storeKey=true   debug=true;   };   5. 运行项目      1. 在spark目录下，运行消费者（/opt/wxbclient/Spark2x/spark)执行如下指令：      spark-submit --class com.huawei.bigdata.SparkToHBaseOnBulkLoad --master yarn --deploy-mode client --keytab /opt/xhk/wxb.keytab --principal wxb --files /opt/wxbclient/Spark2x/spark/conf/user.keytab --jars /opt/wxbclient/Spark2x/spark/jars/streamingClient010/spark-streaming-kafka-0-10_2.11-2.4.5-hw-ei-302002.jar,/opt/wxbclient/Spark2x/spark/jars/streamingClient010/kafka-clients-2.4.0-hw-ei-302002.jar /opt/xhk/SparkToHBaseOnBulkLoad-1.0-SNAPSHOT.jar      参数说明：      --class：需要运行的主类。比如该项目需要运行的是SparkToHBaseOnBulkLoad类，路径+名字。      --master：运行的方式，需要提交到yarn上运行。      --deploy-mode：在yarn上有2中运行方式，client和cluster。      --keytab：keytab文件路径，需要长期运行，所以需要把keytab文件携带到yarn上。该文件可以和conf下的user.keytab文件一样，但名字不能一样。      --pricipal：用户名。      --files：认证需要的配置文件。      --jars：项目运行需要的jar包。      最后一个参数为上传的jar包。      2. 启动生产者         java -cp /opt/xhk/lib/*:/opt/xhk/resources/* com.huawei.bigdata.ProduceData 120000         参数说明：         /opt/xhk/lib/*：项目运行需要的jar包。可以直接用kafka目录下的jar包。         /opt/xhk/resources/：项目运行需要的配置文件。可以把resources目录下的文件上传到服务器上。比如：/zwl/resources/目录下。         com.huawei.bigdata.ProduceData ：需要运行的项目主类。         120000：需要生成的数据量。单位：条         运行效果图：                      HDFS上的效果图：     

 问题分析由于业务侧没有日志，所以无法在100+rs中定位到哪台RegionServer可能存在问题。但是通过业务监控反馈主机名为37，38节点的活跃handler数量较其他rs高，怀疑请求处于阻塞状态，可能存在异常。所以优先分析这两个节点。以8:50-9:00为例进行分析：查看38节点rs日志（hbase-omm-regionserver-<hostname>.log）发现如下日志打印：怀疑操作系统资源存在不足情况，排查后发现没有特殊异常。检查nodeagent日志发现DataNode健康检查失败（/var/log/Bigdata/nodeagent/agentlog/agent.log），无法连接到DataNode。查看对应节点的dn日志（/var/log/Bigdata/hdfs/dn/hadoop-omm-datanode-<hostname>.log），发现8:45-9:05没有日志打印，9:05打印Jvmpause ，但dn的gc日志无异常，怀疑dn进程存在异常，查看对应时间的osinfo日志（/var/log/osinfo/statistics/ps.txt），发现该时间点dn进程处于tl状态。再排查37节点dn日志，发现大量jvmpause打印以及对应时间点进程tl状态。同时排查5号两个时间点的dn日志，发现37节点该时间点dn处于tl状态。hbase查询超时失败，是由于部分节点dn进程处于tl状态，导致dn不工作，影响hbase查询。         问题解决参考      去掉jinfo命令采集监控信息，jinfo 命令在监控DataNode 的最大直接内存时使用（651版本已修改为从配置文件中获取）。建议修改监控指标配置后停止该监控项的信息采集，避免jinfo命令调用。     具体操作步骤如下：omm用户登录到节点，备份监控信息的配置文件cd /opt/huawei/Bigdata/adapters/current/HDFS/monitor/controllercp monitor_basic_info.xml /tmp/monitor_basic_info.xml.bak打开文件后删除监控指标dn_memdirectmaxm相关的配置，为1423-1442行内容。备份YARN监控信息的配置文件：cd /opt/huawei/Bigdata/adapters/current/YARN/monitor/controllercp monitor_basic_info.xml /tmp/monitor_basic_info.xml.bak打开文件后删除监控指标dn_memdirectmaxm相关的配置，为1423-1442行内容。重启nodeagent使配置生效：sh /opt/huawei/Bigdata/om-agent/nodeagent/bin/stop-agent.shsh /opt/huawei/Bigdata/om-agent/nodeagent/bin/start-agent.sh执行命令检查是否还有jinfo 调用，观察5分钟左右，没有输出则没有jinfo调用。while true; do ps -ef|grep jinfo |grep proc_datanode; done