如题，我们想验证下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

   问题分析客户程序跑一段时间后，连续报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分钟间隔的数据 结果如下：