华为云用户手册

处理步骤 确认分隔符、表字段的格式无问题，在sqoop语句中添加--columns绑定对应字段。 sqoop export --connect jdbc:mysql://数据库IP地址:端口号/数据库名 --username 数据库用户名 --password 密码 --table 表名 --columns 列字段（多个列用英文逗号分开） -export-dir 导出地址 --fields-terminated-by 分隔符 --input-null-string '\\N' --input-null-non-string '\\N' -m 1 命令中如果携带认证密码信息可能存在安全风险，在执行命令前建议关闭系统的history命令记录功能，避免信息泄露。 样例： sqoop export --connect jdbc:mysql://192.168.0.6:3306/lidengpeng --username root --password 用户密码 --table hkatg_agr_prod_city_summ --columns year,city_name,city_code,prod_code,prod_name,prod_type,sown_area,area_unit,yield_wegt,yield_unit,total_wegt,total_wegt_unit,data_sorc_code,etl_time -export-dir hdfs://hacluster/user/hive/warehouse/dm_agr_prod_city_summ02 --fields-terminated-by ',' --input-null-string '\\N' --input-null-non-string '\\N' -m 1

处理总结 将sqoop的lib下htrace-core-3.1.0-incubating.jar和hbase的lib下的metrics-core-2.2.0.jar，复制到“/opt/Bigdata/ MRS _1.9.2/install/ FusionInsight -Hadoop-2.8.3/hadoop/share/hadoop/common/lib/”下。 修改jar包的文件权限为777和omm:ficommon。 所有节点均采取以上操作，重新运行sqoop任务即可。

处理步骤 进入Sqoop的安装目录下查找文件。 进入Sqoop节点的“/opt/Bigdata/MRS_1.9.2/install/FusionInsight-Sqoop-1.99.7/FusionInsight-Sqoop-1.99.7/server/lib”目录下，进行grep查找。 进入Yarn WebUI界面，查看运行的任务的报错具体信息。 将java.class.path复制出来，搜索htrace-core。 复制jar包到如下位置。 cp /opt/Bigdata/MRS_1.9.2/install/FusionInsight-Sqoop-1.99.7/FusionInsight-Sqoop-1.99.7/server/lib/htrace-core-3.1.0-incubating.jar /opt/Bigdata/MRS_1.9.2/install/FusionInsight-Hadoop-2.8.3/hadoop/share/hadoop/common/lib/ 修改权限。 chmod 777 htrace-core-3.1.0-incubating.jar （真实复制的jar包） chown omm:ficommon htrace-core-3.1.0-incubating.jar （真实复制的jar包） 查看hosts文件，对其他所有节点进行同样的复制jar包操作。 重新运行sqoop任务，产生报错如下： 去HBase的安装目录下查找文件。 进入HBase的lib目录下，进行grep查找。 继续复制jar包。 cp /opt/Bigdata/MRS_1.9.2/install/FusionInsight-HBase-1.3.1/hbase/lib/metrics-core-2.2.0.jar /opt/Bigdata/MRS_1.9.2/install/FusionInsight-Hadoop-2.8.3/hadoop/share/hadoop/common/lib/ 修改文件权限。 chmod 777 metrics-core-2.2.0.jar （真实复制的jar包） chown omm:ficommon metrics-core-2.2.0.jar（真实复制的jar包） 查看hosts文件，对其他所有节点进行同样的复制jar包操作。 继续运行sqoop任务，成功。

处理步骤 在集群上安装客户端，查看客户端“sqoop/lib”目录下是否有MySQL驱动包。 在客户端目录下加载环境变量。 source bigdata_env 执行Kerberos用户认证。 如果集群已启用Kerberos认证，执行以下命令认证具有操作权限的用户，否则跳过此步骤。 kinit MRS集群用户 连接数据库。命令中如果携带认证密码信息可能存在安全风险，在执行命令前建议关闭系统的history命令记录功能，避免信息泄露。 sqoop list-databases --connect jdbc:mysql://数据库IP地址:3306/ --username 数据库登录用户名 --password 密码 上图所示则代表sqoop连接MySQL成功。

处理步骤 使用root用户登录Impala所在节点，执行如下命令，确认当前系统上安装的Python版本： python --version 执行命令yum install make，查看yum是否可用。 如果yum install报如下错误，说明yum设置有问题，执行3。 如果没有报错，执行4。 执行命令cat /etc/yum.repos.d/EulerOS-base.repo，查看yum源和系统版本信息不匹配是否匹配，如果不匹配则修改，如下所示： 修改前： 修改后： 执行如下命令，查看yum源上python2开头的软件。 yum list python2* 执行如下命令，安装Python2。 yum install python2 因为当前系统上已安装Python3，所有直接安装Python2会有上面的冲突提示。 可以选择--allowerasing或--skip-broken安装，例如： yum install python2 --skip-broken 安装完成后，会自动将Python版本修改为Python2，如下所示： 如果Python2安装成功，但是显示的Python版本不对，需要执行以下命令手动给“/usr/bin/python2”创建软链接“/usr/bin/python”。 ln -s /usr/bin/python2 /usr/bin/python 验证Impala客户端是否可用。

问题现象 新建了集群，在创建表时，报错如下： [Cloudera]ImpalaJDBCDriver ERROR processing query/statement. Error Code: 0, SQL state: TStatus(statusCode:ERROR_STATUS, sqlState:HY000, errorMessage:AnalysisException: Table property 'kudu.master_addresses' is required when the impalad startup flag -kudu_master_hosts is not used.”

原因分析 MapReduce任务提交时会将相关配置文件、jar包和-files参数后添加的文件都上传至HDFS的临时目录，方便Container启动后获取相应的文件。系统通过配置项“yarn.app.mapreduce.am.staging-dir”决定具体存放位置，默认值是“/tmp/hadoop-yarn/staging”。 正常运行的MapReduce任务会在Job结束以后就清理这些临时文件，但是当Job对应的Yarn任务异常退出时，这些临时文件不会被清理，长时间积攒导致该临时目录下的文件数量越来越多，占用存储空间越来越多。

处理步骤 使用MRS集群自带的Hive for Spark包： hive-beeline-1.2.1.spark_2.2.1-mrs-x.x.x.jar hive-cli-1.2.1.spark_2.2.1-mrs-x.x.x.jar hive-common-1.2.1.spark_2.2.1-mrs-x.x.x.jar hive-exec-1.2.1.spark_2.2.1-mrs-x.x.x.jar hive-jdbc-1.2.1.spark_2.2.1-mrs-x.x.x.jar hive-metastore-1.2.1.spark_2.2.1-mrs-x.x.x.jar 华为云Maven库请参考指导通过开源镜像站获取样例工程。

原因分析 HDFS写文件的预约机制：无论文件是10 MB还是1 GB，开始写的每个块都会被预约128 MB。如果需要写入一个10 MB的文件，HDFS会预约一个块来写，当文件写完后，这个块只占实际大小10 MB，释放多余预约的118 MB空间。如果需要写入一个1 GB的文件，HDFS还是会预约一个块来写，这个块写完后再开启下一个块，文件写完后，实际占用1 GB磁盘，释放多余预约的空间。 该异常通常是因为业务写文件的并发量太高，预约写Block的磁盘空间不足，导致写文件失败。

解决办法 登录HDFS的WebUI页面，进入DataNode的JMX页面。 在HDFS原生界面，选择Datanodes页面。 找到对应的DataNode节点，单击Http Address地址进入DataNode详情。 将url的“datanode.html”改为“jmx”就能获取到DataNode的JMX信息。 搜索“XceiverCount”指标，当该指标的值*Block块的大小超过DataNode磁盘的容量，就说明预约写Block的磁盘空间不足。 发生该问题，通常有以下两种方法来解决： 方法一：降低业务的并发度。 方法二：减少业务写文件的数目，将多个文件合并成一个文件来写。

问题背景与现象 用户运行作业时写文件到HDFS，偶现写文件失败的情况。 操作日志如下： 105 | INFO | IPC Server handler 23 on 25000 | IPC Server handler 23 on 25000, call org.apache.hadoop.hdfs.protocol.ClientProtocol.addBlock from 192.168.1.96:47728 Call#1461167 Retry#0 | Server.java:2278 java.io.IOException: File /hive/warehouse/000000_0.835bf64f-4103 could only be replicated to 0 nodes instead of minReplication (=1). There are 3 datanode(s) running and 3 node(s) are excluded in this operation.

原因分析 问题1：可能原因是 MapReduce服务 异常。 问题2：可能原因如下： Spark的JobHistory服务异常。 日志太大，NodeManager在做日志汇聚的时候出现超时。 HDFS存放日志目录权限异常（默认/tmp/logs/用户名/logs）。 日志已被清理（spark的JobHistory默认存放7天的eventLog，配置项为spark.history.fs.cleaner.maxAge；MapReduce默认存放15天的任务日志，配置项为mapreduce.jobhistory.max-age-ms）。 如果Yarn页面上也找不到，可能是被Yarn清理了（默认存放10000个历史任务，配置项为yarn.resourcemanager.max-completed-applications）。

处理步骤 问题1：确认MapReduce服务是否正常，如果异常，尝试重启服务。如果还是不能恢复，需要查看后台JobhistoryServer日志。 问题2：依次排查可能的情况： 查看Spark的JobHistory是否运行正常； 通过查看yarn的app详情页面，确认日志文件是否过大，如果日志汇聚失败，页面的“Log Aggregation Status:”应该显示为失败或者超时； 查看对应目录权限是否异常； 查看目录下是否有对应的appid文件（Spark的eventlog存放目录：MRS 3.x及以后版本的目录是hdfs://hacluster/spark2xJobHistory2x，MRS 3.x以前版本的目录是hdfs://hacluster/sparkJobHistory，任务运行日志存放目录是hdfs://hacluster/tmp/logs/用户名/logs）; 查看appid和当前作业的id是否超过历史记录最大值。

处理步骤 问题1： 重新kinit一个用户并修改相应的配置参数。 问题2： 查看hadoop相关的配置项是否正确，查看spark的conf目录下的core-site.xml，hdfs-site.xml，yarn-site.xml，mapred-site.xml等配置文件是否存在问题。 问题3： 重新复制一个user.keytab，例如： cp user.keytab user2.keytab spark-submit --master yarn --files user.keytab --keytab user2.keytab ......

原因分析 当使用load导入数据到Hive表的时候，属于需要跨文件系统的情况（例如原数据在HDFS上，而Hive表数据存放在OBS上），并且文件长度大于阈值（默认32 MB），则会触发使用distcp的MapReduce任务来执行数据迁移操作。这个MapReduce任务配置直接从Spark任务配置里面提取，但是Spark任务的net.topology.node.switch.mapping.impl配置项不是hadoop的默认值，需要使用Spark的jar包，因此MapReduce会报类找不到。

原因分析 查询Core节点有大量文件的目录，发现大部分都是类似“blockmgr-033707b6-fbbb-45b4-8e3a-128c9bcfa4bf”的目录，里面存放了计算过程中产生的shuffle临时文件。 因为JD BCS erver启动了Spark的动态资源分配功能，已经将shuffle托管给NodeManager，NodeManager只会按照APP的运行周期来管理这些文件，并不会关注单个executor所在的container是否存在。因此，只有在APP结束的时候才会清理这些临时文件。任务运行时间较长时导致临时文件过多占用了大量磁盘空间。

原因分析 Spark运行的时候会将临时产生的shuffle文件放在executor的临时目录中，方便后面获取。 而当某个executor异常退出时，NodeManager会把这个executor所在的container临时目录删除，随后其他executor再来申请这个executor的shuffle结果就会报文件找不到。 因此，遇到这样的问题需要确认是否executor异常退出，可以根据spark任务页面的executors便签页查看是否有dead状态的executor，查看各个dead状态的executor日志，确认异常退出的原因（其中可能有部分executor退出原因就是因为shuffle文件找不到，需要找到最早异常退出的executor）。 常见的异常退出： executor发生OOM executor运行时出现多个task任务失败 executor所在节点被清理

处理步骤 重启集群sssd进程。 以root用户执行service sssd restart命令重启sssd服务，执行ps -ef | grep sssd命令，查看sssd进程是否正常。 正常状态为存在/usr/sbin/sssd进程和三个子进程/usr/libexec/sssd/sssd_be、/usr/libexec/sssd/sssd_nss、/usr/libexec/sssd/sssd_pam。

问题现象 创建表过程： CREATE TABLE wlg_test001 (start_time STRING,value INT); 报错: Error: org.apache.spark.sql.AnalysisException: org.apache.hadoop.hive.ql.metadata.HiveException: MetaException(message:Failed to grant permission on HDFSjava.lang.reflect.UndeclaredThrowableException); (state=,code=0)

原因分析 查看MetaStore日志。 查看HDFS日志。 权限对比（test001为异常用户创建表，test002为正常用户创建表）。 drop表时报类似下面的错。 dataplan_modela_csbch2; Error: Error while compiling statement: FAILED: SemanticException Unable to fetch table dataplan_modela_csbch2. java.security.AccessControlException: Permission denied: user= CS B_csb_3f8_x48ssrbt, access=READ, inode="/user/hive/warehouse/hive_csb_csb_3f8_x48ssrbt_5lbi2edu.db/dataplan_modela_csbch2":spark:hive:drwx------ 根因分析。 创建集群时创建的默认用户使用了相同的uid，造成用户错乱。在大量创建用户的场景下，触发了该问题，导致在创建表时偶现Hive用户没有权限。

处理步骤 以root用户分别登录Master节点。 打开文件“/opt/knox/bin/gateway.sh”，查找APP_MEM_OPTS，并设置该参数的值为：“-Xms3072m -Xmx4096m”。 登录Manager页面，在主机列表页面找到主Master节点的IP地址（即主机名称前带有实心五角星的节点），并登录该节点后台。 执行如下命令重启进程。 su - omm sh /opt/knox/bin/restart-knox.sh

处理步骤 以root用户登录集群主Master节点。 修改“${BIGDATA_HOME}/om-server/om/inst/conf/oms-config.ini”和“${BIGDATA_HOME}/om-server/ OMS /workspace0/conf/oms-config.ini”配置文件，在“ntp_server_ip”参数值前添加“ntp.myhuaweicloud.com,” ... ntp_server_ip=ntp.myhuaweicloud.com,10.127.1.0 ... 以root用户登录集群备Master节点，执行2。 等待约2分钟，在主Master节点执行以下命令观察IP同步成功。 ntpq -np 例如执行后结果如下：

处理步骤 重建索引。 su - omm gsql -p 20051 -U omm -W password -d hivemeta DROP INDEX PCS_STATS_IDX; CREATE INDEX PCS_STATS_IDX ON PART_COL_STATS(DB_NAME, TABLE_NAME, COLUMN_NAME, PARTITION_NAME); CREATE INDEX SDS_N50 ON SDS(CD_ID); 重新查看执行计划，发现语句已经可以索引查询，且5ms执行完成（原来是700ms）。重新执行hive表字段增加，已经可以添加成功。

原因分析 MetaStore客户端连接超时，MRS默认MetaStore客户端和服务端连接的超时时间是600s，在Manager页面调大“hive.metastore.client.socket.timeout”为“3600s”。 出现另一个报错： Error: org.apache.hive.service.cli.HiveSQLException: Error while processing statement: FAILED: Execution Error, return code 1 from org.apache.hadoop.hive.ql.exec.DDLTask. Unable to alter table. java.net.SocketTimeoutException: Read timed out Metastore元数据JDBC连接超时，默认60ms。 调大javax.jdo.option.ConnectionURL中socketTimeout=60000，仍然产生最初的报错： Timeout when executing method: alter_table_with_environment_context;3600556ms exceeds 3600000ms 尝试调大hive.metastore.batch.retrieve.max、hive.metastore.batch.retrieve.table.partition.max、dbservice.database.max.connections等参数均未能解决。 怀疑是 GaussDB 的问题，因为增加字段会遍历每个分区执行getPartitionColumnStatistics和alterPartition。 使用omm用户执行gsql -p 20051 -U omm -W password -d hivemeta登录Hive元数据库。命令中如果携带认证密码信息可能存在安全风险，在执行命令前建议关闭系统的history命令记录功能，避免信息泄露。 执行select * from pg_locks;没有发现锁等待。 执行select * from pg_stat_activity;发现进程执行时间较长。 SELECT 'org.apache.hadoop.hive.metastore.model.MPartitionColumnStatistics'AS NUCLEUS_TYPE,A0.AVG_COL_LEN,A0."COLUMN_NAME",A0.COLUMN_TYPE,A0.DB_NAME,A0.BIG_DECIMAL_HIGH_VALUE,A0.BIG_DECIMAL_LOW_VALUE,A0.DOUBLE_HIGH_VALUE,A0.DOUBLE_LOW_VALUE,A0.LAST_ANALYZED,A0.LONG_HIGH_VALUE,A0.LONG_LOW_VALUE,A0.MAX_COL_LEN,A0.NUM_DISTIN CTS ,A0.NUM_FALSES,A0.NUM_NULLS,A0.NUM_TRUES,A0.PARTITION_NAME,A0."TABLE_NAME",A0.CS_ID,A0.PARTITION_NAMEAS NUCORDER0 FROM PART_COL_STATS A0 WHERE A0."TABLE_NAME" = '$1' ANDA0.DB_NAME = '$2' AND A0.PARTITION_NAME = '$3' AND((((((A0."COLUMN_NAME" = '$4') OR (A0."COLUMN_NAME" ='$5')) OR (A0."COLUMN_NAME" = '$6')) OR (A0."COLUMN_NAME" ='$7')) OR (A0."COLUMN_NAME" = '$8')) OR (A0."COLUMN_NAME" ='$9')) ORDER BY NUCORDER0; 执行gs_guc reload -c log_min_duration_statement=100 -D /srv/BigData/dbdata_service/data/开启SQL录制，发现8中语句执行时长700ms，而且因为有10000+分区，会触发执行10000+次命令。 在SQL前加explain (analyze,verbose,timing,costs,buffers)分析执行计划，发现执行时需要全表扫描。 查看索引，发现不满足最左匹配原则。

问题现象 在MRS Hive的beeline中执行insert into插入语句时系统报以下错误： Mapping run in Tez on Hive transactional table fails when data volume is high with error: "org.apache.hadoop.hive.ql.lockmgr.LockException Reason: Transaction... already aborted, Hive SQL state [42000]."

处理步骤 可以在beeline上设置配置参数进行解决。 设置以下属性以优化性能（建议在集群级别进行更改） 设置hive.auto.convert.sortmerge.join = true 设置hive.optimize.bucketmapjoin = true 设置hive.optimize.bucketmapjoin.sortedmerge = true 更改以下内容以调整Tez的资源。 设置hive.tez.container.size = {与YARN容器相同的大小} 将hive.tez.container.size设置为与YARN容器大小“yarn.scheduler.minimum-allocation-mb”相同或更小的值（例如设置为二分之一或四分之一的值），但不要超过“yarn.scheduler.maximum-allocation-mb”参数值。

原因分析 MRS集群开启了Kerberos认证但是无法提交作业，所以首先检查权限配置问题，检查发现未正确配置“/opt/client/Flink/flink/conf/flink-conf.yaml”中的参数。 图1 flink-conf.yaml配置 修改并刷新配置后，重新提交作业出现作业可以提交但报“log4j:ERROR setFile(null,true) call failed”的错误。 图2 log4j报错 查看log4j发现用户将“log4j.properties”文件改成了“log4g-cli.properties”（“log4j.properties”的名字是固定的不可随意修改）导致报错。 图3 查看log4j 修改后可以正常提交作业。 图4 提交作业正常

处理步骤 判断用户是在集群外还是集群内使用客户端提交作业。 若在集群内使用客户端，切换到omm用户提交作业。 若在集群外使用客户端，则要使用root用户提交作业。 检查“flink-conf.yaml”文件各参数是否配置正确。 对于开启Kerberos认证的集群配置项包括Kerberos的keytab、principal等。 从KDC服务器上下载用户keytab，并将keytab放到Flink客户端所在主机的某个文件夹下(例如/home/flinkuser/keytab)。 在“${FLINK_HOME}/conf/flink-conf.yaml”上配置： keytab路径（注意配置参数前面有空格）： security.kerberos.login.keytab: /home/flinkuser/keytab/uer.keytab principal名(即开发用户名)： security.kerberos.login.principal:flinkuser 重新正确提交作业./flink run /opt/client/Flink/flink/examples/streaming/WordCount.jar，验证是否可以提交作业。 若可以提交作业则说明权限认证没有问题，就可以去检查其他错误，本例中是修改了log4j.properties的名称，还原后可以正常提交作业。 若提交作业失败，请提交工单进行处理。

处理步骤 分别登录主、备Master节点。 执行cd /srv/BigData/命令进入到备份文件所在目录。 执行unlink LocalBackup命令删除LocalBackup软连接。 执行mkdir -p LocalBackup命令创建LocalBackup目录。 执行chown -R omm:wheel LocalBackup命令修改文件所属用户、群组。 执行chmod 700 LocalBackup命令修改文件读写权限。 登录MRS Manager页面重新执行周期备份。

原因分析 查看HiveServer日志，在对应时间点，有如下的报错信息。 图2 HiveServer日志 在如上报错信息中未发现重要信息，但从堆栈中发现metadata字样，怀疑报错是和MetaStore有关。 图3 堆栈中metadata字样 查看MetaStore日志，发现如下报错。 图4 MetaStore日志 查看如上错误的上下文，确定是本次执行SQL的报错，在报错信息里面发现如下内容： Caused by: org.postgresql.util.PSQLException: ERROR: value too long for type character varying(4000) 确认是该条SQL对表的操作，所有列的字节长度超过4000的限制，导致SQL执行失败，需要修改该限制。