华为云用户手册

原因分析 使用客户端命令，打印NoNodeException异常。 Error while executing topic command : org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /brokers/ids [2017-09-17 16:35:28,520] ERROR org.I0Itec.zkclient.exception.ZkNoNodeException: org.apache.zookeeper.KeeperException$NoNodeException: KeeperErrorCode = NoNode for /brokers/ids at org.I0Itec.zkclient.exception.ZkException.create(ZkException.java:47) at org.I0Itec.zkclient.ZkClient.retryUntilConnected(ZkClient.java:995) at org.I0Itec.zkclient.ZkClient.getChildren(ZkClient.java:675) at org.I0Itec.zkclient.ZkClient.getChildren(ZkClient.java:671) at kafka.utils.ZkUtils.getChildren(ZkUtils.scala:541) at kafka.utils.ZkUtils.getSortedBrokerList(ZkUtils.scala:176) at kafka.admin.AdminUtils$.createTopic(AdminUtils.scala:235) at kafka.admin.TopicCommand$.createTopic(TopicCommand.scala:105) at kafka.admin.TopicCommand$.main(TopicCommand.scala:60) at kafka.admin.TopicCommand.main(TopicCommand.scala) 通过Manager查看Kafka服务是否处于正常状态。 检查客户端命令中ZooKeeper地址是否正确，访问ZooKeeper上所存放的Kafka信息，其路径（Znode）应该加上/kafka，发现配置中缺少/kafka： [root@10-10-144-2 client]# kafka-topics.sh --create --replication-factor 1 --partitions 2 --topic test --zookeeper 192.168.234.231:2181

解决办法 配置自定义配置“allow.everyone.if.no.acl.found”参数为“true”，重启Kafka服务。 采用具有权限用户登录。 例如： kinit test_user 或者赋予用户相关权限。 需要使用Kafka管理员用户（属于kafkaadmin组）操作。 例如： kafka-acls.sh --authorizer-properties zookeeper.connect=10.5.144.2:2181/kafka --topic topic_acl --producer --add --allow-principal User:test [root@10-10-144-2 client]# kafka-acls.sh --authorizer-properties zookeeper.connect=8.5.144.2:2181/kafka --list --topic topic_acl Current ACLs for resource `Topic:topic_acl`: User:test_user has Allow permission for operations: Describe from hosts: * User:test_user has Allow permission for operations: Write from hosts: * User:test has Allow permission for operations: Describe from hosts: * User:test has Allow permission for operations: Write from hosts: * 用户加入Kafka组或者Kafkaadmin组。

处理步骤 以root用户登录Master2节点。 执行find / -name 'mapred-site.xml'命令获取mapred-site.xml文件所在位置。 HiveServer对应路径为“/opt/Bigdata/集群版本/1_13_HiveServer/etc/mapred-site.xml”。 WebHCat对应路径为“/opt/Bigdata/集群版本/1_13_WebHCat/etc/mapred-site.xml”。 确认mapred-site.xml文件是否有异常，该案例中该配置文件内容为空导致解析失败。 修复mapred-site.xml文件，将Master1节点上对应目录下的配置文件用scp命令拷贝到Master2节点对应目录替换原文件。 执行chown omm:wheel mapred-site.xml命令更改所属组和用户。 在Manager界面重启故障的HiveServer和WebHCat进程，恢复正常。

处理步骤 登录Zookeeper客户端所在节点。 cd 客户端安装目录 source bigdata_env kinit 组件业务用户（未开启Kerberos认证集群跳过此步骤） 执行以下命令修改文件。 vim 客户端安装目录/zookeeper/conf/zoo.cfg 调大文件中参数“tickTime”，“syncLimit”的值。 例如调整“tickTime”为“3000”， “syncLimit”为“7”。 保存文件。

原因分析 服务端配置错误，监测端口启动失败，例如服务端Avro Source配置了错误的IP，或者已经被占用了的端口。 查看Flume运行日志： 2016-08-31 17:28:42,092 | ERROR | [lifecycleSupervisor-1-9] | Unable to start EventDrivenSourceRunner: { source:Avro source avro_source: { bindAddress: 10.120.205.7, port: 21154 } } - Exception follows. | org.apache.flume.lifecycle.LifecycleSupervisor$MonitorRunnable.run(LifecycleSupervisor.java:253) java.lang.RuntimeException: org.jboss.netty.channel.ChannelException: Failed to bind to: /192.168.205.7:21154 若采用了加密传输，证书或密码错误。 2016-08-31 17:15:59,593 | ERROR | [conf-file-poller-0] | Source avro_source has been removed due to an error during configuration | org.apache.flume.node.AbstractConfigurationProvider.loadSources(AbstractConfigurationProvider.java:388) org.apache.flume.FlumeException: Avro source configured with invalid keystore: /opt/Bigdata/MRS_XXX/install/FusionInsight-Flume-1.9.0/flume/conf/flume_sChat.jks 客户端与服务端通信异常。 PING 192.168.85.55 (10.120.85.55) 56(84) bytes of data. From 192.168.85.50 icmp_seq=1 Destination Host Unreachable From 192.168.85.50 icmp_seq=2 Destination Host Unreachable From 192.168.85.50 icmp_seq=3 Destination Host Unreachable From 192.168.85.50 icmp_seq=4 Destination Host Unreachable

解决方案 DBservice服务不可用请参考ALM-27001 DBService服务不可用。 HDFS服务不可用请参考ALM-14000 HDFS服务不可用。 ZooKeeper服务不可用请参考ALM-13000 ZooKeeper服务不可用。 LDAP/KrbServer服务不可用请参考ALM-25000 LdapServer服务不可用/ALM-25500 KrbServer服务不可用。 MetaStore实例不可用请参考ALM-16004 Hive服务不可用。

问题背景与现象 新建Kafka集群，部署Broker节点数为2，使用Kafka客户端可以正常生产，但是无法正常消费。Consumer消费数据失败，提示GROUP_COORDINATOR_NOT_AVAILABLE，关键日志如下： 2018-05-12 10:58:42,561 | INFO | [kafka-request-handler-3] | [GroupCoordinator 2]: Preparing to restabilize group DemoConsumer with old generation 118 | kafka.coordinator.GroupCoordinator (Logging.scala:68) 2018-05-12 10:59:13,562 | INFO | [executor-Heartbeat] | [GroupCoordinator 2]: Preparing to restabilize group DemoConsumer with old generation 119 | kafka.coordinator.GroupCoordinator (Logging.scala:68)

原因分析 DataNode节点内写block磁盘时，有两种策略“轮询”和“优先写剩余磁盘空间多的磁盘”，默认是“轮询”。 参数说明：dfs.datanode.fsdataset.volume.choosing.policy 可选值： 轮询：org.apache.hadoop.hdfs.server.datanode.fsdataset.RoundRobinVolumeChoosingPolicy 优先写剩余空间多的磁盘： org.apache.hadoop.hdfs.server.datanode.fsdataset.AvailableSpaceVolumeChoosingPolicy

问题背景与现象 单个节点内DataNode的各磁盘使用率不均匀。 例如： 189-39-235-71:~ # df -h Filesystem Size Used Avail Use% Mounted on /dev/xvda 360G 92G 250G 28% / /dev/xvdb 700G 900G 200G 78% /srv/BigData/hadoop/data1 /dev/xvdc 700G 900G 200G 78% /srv/BigData/hadoop/data2 /dev/xvdd 700G 900G 200G 78% /srv/BigData/hadoop/data3 /dev/xvde 700G 900G 200G 78% /srv/BigData/hadoop/data4 /dev/xvdf 10G 900G 890G 2% /srv/BigData/hadoop/data5 189-39-235-71:~ #

解决办法 将DataNode选择磁盘策略的参数dfs.datanode.fsdataset.volume.choosing.policy的值改为：org.apache.hadoop.hdfs.server.datanode.fsdataset.AvailableSpaceVolumeChoosingPolicy，保存并重启受影响的服务或实例。 让DataNode根据磁盘剩余空间大小，优先选择磁盘剩余空间多的节点存储数据副本。 针对新写入到本DataNode的数据会优先写磁盘剩余空间多的磁盘。 部分磁盘使用率较高，依赖业务逐渐删除在HDFS中的数据（老化数据）来逐渐降低。

问题现象 新建了集群，在创建表时，报错如下： [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.”

解决方案 在select结果乱码时，在beeline中进行如下设置。 set mapreduce.output.fileoutputformat.compress.codec=org.apache.hadoop.io.encryption.arc4.ARC4BlockCodec; set hive.exec.compress.output=true; 使用块解压的方式先将表导入一个新表中。 insert overwrite table tbl_result select * from tbl_source; 再进行查询。 select * from tbl_result;

解决办法 针对MRS 2.x及之前版本，操作如下： 方法1： 关闭Flink SSL通信加密，修改客户端配置文件“conf/flink-conf.yaml”。 security.ssl.internal.enabled: false 方法2： 开启Flink SSL通信加密，security.ssl.internal.enabled保持默认。 正确配置SSL： 配置keystore或truststore文件路径为相对路径时，Flink Client执行命令的目录需要可以直接访问该相对路径。 security.ssl.internal.keystore: ssl/flink.keystore security.ssl.internal.truststore: ssl/flink.truststore 在Flink的CLI yarn-session.sh命令中增加“-t”选项来传输keystore和truststore文件到各个执行节点。 yarn-session.sh -t ssl/ 2 配置keystore或truststore文件路径为绝对路径时，需要在Flink Client以及各个节点的该绝对路径上放置keystore或truststore文件。 security.ssl.internal.keystore: /opt/client/Flink/flink/conf/flink.keystore security.ssl.internal.truststore: /opt/client/Flink/flink/conf/flink.truststore 针对MRS3.x及之后版本，操作如下： 方法1： 关闭Flink SSL通信加密，修改客户端配置文件“conf/flink-conf.yaml”。 security.ssl.enabled: false 方法2： 开启Flink SSL通信加密，security.ssl.enabled 保持默认。 正确配置SSL： 配置keystore或truststore文件路径为相对路径时，Flink Client执行命令的目录需要可以直接访问该相对路径。 security.ssl.keystore: ssl/flink.keystore security.ssl.truststore: ssl/flink.truststore 在Flink的CLI yarn-session.sh命令中增加“-t”选项来传输keystore和truststore文件到各个执行节点。 yarn-session.sh -t ssl/ 2 配置keystore或truststore文件路径为绝对路径时，需要在Flink Client以及各个节点的该绝对路径上放置keystore或truststore文件。 security.ssl.keystore: /opt/client/Flink/flink/conf/flink.keystore security.ssl.truststore: /opt/client/Flink/flink/conf/flink.truststore

问题背景与现象 创建Fllink集群，执行yarn-session.sh命令卡住一段时间后报错： 2018-09-20 22:51:16,842 | WARN | [main] | Unable to get ClusterClient status from Application Client | org.apache.flink.yarn.YarnClusterClient (YarnClusterClient.java:253) org.apache.flink.util.FlinkException: Could not connect to the leading JobManager. Please check that the JobManager is running. at org.apache.flink.client.program.ClusterClient.getJobManagerGateway(ClusterClient.java:861) at org.apache.flink.yarn.YarnClusterClient.getClusterStatus(YarnClusterClient.java:248) at org.apache.flink.yarn.YarnClusterClient.waitForClusterToBeReady(YarnClusterClient.java:516) at org.apache.flink.yarn.cli.FlinkYarnSessionCli.run(FlinkYarnSessionCli.java:717) at org.apache.flink.yarn.cli.FlinkYarnSessionCli$1.call(FlinkYarnSessionCli.java:514) at org.apache.flink.yarn.cli.FlinkYarnSessionCli$1.call(FlinkYarnSessionCli.java:511) at java.security.AccessController.doPrivileged(Native Method) at javax.security.auth.Subject.doAs(Subject.java:422) at org.apache.hadoop.security.UserGroupInformation.doAs(UserGroupInformation.java:1729) at org.apache.flink.runtime.security.HadoopSecurityContext.runSecured(HadoopSecurityContext.java:41) at org.apache.flink.yarn.cli.FlinkYarnSessionCli.main(FlinkYarnSessionCli.java:511) Caused by: org.apache.flink.runtime.leaderretrieval.LeaderRetrievalException: Could not retrieve the leader gateway. at org.apache.flink.runtime.util.LeaderRetrievalUtils.retrieveLeaderGateway(LeaderRetrievalUtils.java:79) at org.apache.flink.client.program.ClusterClient.getJobManagerGateway(ClusterClient.java:856) ... 10 common frames omitted Caused by: java.util.concurrent.TimeoutException: Futures timed out after [10000 milliseconds]

原因分析 出错的集群有两个HiveServer实例，首先查看其中一个HiveServer日志发现里面的报错与客户端中的错误一样均是Error:Invalid OperationHandler，查看另一个HiveServer发现在出错的时间段此实例有如下类似START_UP的打印，说明那段时间进程被停止过，后来又启动成功，提交的任务本来连接的是重启过的HiveServer实例，当这个实例被停止后，任务进程连接到另一个健康的HiveServer上导致报错。 2017-02-15 14:40:11,309 | INFO | main | STARTUP_MSG: /************************************************************ STARTUP_MSG: Starting HiveServer2 STARTUP_MSG: host = XXX-120-85-154/XXX.120.85.154 STARTUP_MSG: args = [] STARTUP_MSG: version = 1.3.0

原因分析 初步分析怀疑是没有完成kerberos认证就去进行业务交互。 深入分析日志发现日志上虽然有打印“com.xxx.bigdata.security.LoginUtil - Login success!!!!!!!!!!!!!!”，但没打印“org.apache.hadoop.security.UserGroupInformation : Login successful...”。 分析代码，发现： /* */ @InterfaceAudience.Public /* */ @InterfaceStability.Evolving /* */ public static synchronized void loginUserFromKeytab(String user, String path) /* */ throws IOException /* */ { /* 958 */ if (!isSecurityEnabled()) { /* 959 */ return; /* */ } ...... 分析“isSecurityEnabled()”，发现是否要发起认证，还需要判断configuration中是否有配置“hadoop.security.authentication”为“kerberos”。 本Hive业务应用确实没有正确设置此配置，所以被认为不需要做kerberos认证。 分析Hive组件的“jdbc-examples”样例工程，不存在类似问题，是因为该工程的classpath路径下，存在core-site.xml配置文件，此配置文件上设置“hadoop.security.authentication”为“kerberos”。

解决办法 属于用户使用不当。对于本业务应用来说，若要解决此问题，可以参考如下几种办法： 方法1： 直接参考Hive组件的“jdbc-examples”样例工程，将core-site.xml配置文件放在classpath路径下。 方法2： 在代码中，显式加载配置文件core-site.xml，例如： ...... conf = new Configuration(); String userdir = System.getProperty("user.dir") + File.separator + "conf" + File.separator; conf.addResource(new Path(userdir + "core-site.xml")); ...... 方法3： 在代码中，设置“hadoop.security.authentication”为“kerberos”，例如： ...... CONF = new Configuration(); CONF.set("hadoop.security.authentication", "kerberos"); ......

原因分析 查看HMaster的运行日志，发现有报大量的如下错误： 2018-03-26 11:10:54,185 | INFO | hadoopc1h3,21300,1522031630949_splitLogManager__ChoreService_1 | total tasks = 1 unassigned = 0 tasks={/hbase/splitWAL/WALs%2Fhadoopc1h1%2C213 02%2C1520214023667-splitting%2Fhadoopc1h1%252C21302%252C1520214023667.default.1520584926990=last_update = 1522033841041 last_version = 34255 cur_worker_name = hadoopc1h3,21302, 1520943011826 status = in_progress incarnation = 3 resubmits = 3 batch = installed = 1 done = 0 error = 0} | org.apache.hadoop.hbase.master.SplitLogManager$TimeoutMonitor.chore (SplitLogManager.java:745) 2018-03-26 11:11:00,185 | INFO | hadoopc1h3,21300,1522031630949_splitLogManager__ChoreService_1 | total tasks = 1 unassigned = 0 tasks={/hbase/splitWAL/WALs%2Fhadoopc1h1%2C213 02%2C1520214023667-splitting%2Fhadoopc1h1%252C21302%252C1520214023667.default.1520584926990=last_update = 1522033841041 last_version = 34255 cur_worker_name = hadoopc1h3,21302, 1520943011826 status = in_progress incarnation = 3 resubmits = 3 batch = installed = 1 done = 0 error = 0} | org.apache.hadoop.hbase.master.SplitLogManager$TimeoutMonitor.chore (SplitLogManager.java:745) 2018-03-26 11:11:06,185 | INFO | hadoopc1h3,21300,1522031630949_splitLogManager__ChoreService_1 | total tasks = 1 unassigned = 0 tasks={/hbase/splitWAL/WALs%2Fhadoopc1h1%2C213 02%2C1520214023667-splitting%2Fhadoopc1h1%252C21302%252C1520214023667.default.1520584926990=last_update = 1522033841041 last_version = 34255 cur_worker_name = hadoopc1h3,21302, 1520943011826 status = in_progress incarnation = 3 resubmits = 3 batch = installed = 1 done = 0 error = 0} | org.apache.hadoop.hbase.master.SplitLogManager$TimeoutMonitor.chore (SplitLogManager.java:745) 2018-03-26 11:11:10,787 | INFO | RpcServer.reader=9,bindAddress=hadoopc1h3,port=21300 | Kerberos principal name is hbase/hadoop.hadoop.com@HADOOP.COM | org.apache.hadoop.hbase .ipc.RpcServer$Connection.readPreamble(RpcServer.java:1532) 2018-03-26 11:11:12,185 | INFO | hadoopc1h3,21300,1522031630949_splitLogManager__ChoreService_1 | total tasks = 1 unassigned = 0 tasks={/hbase/splitWAL/WALs%2Fhadoopc1h1%2C213 02%2C1520214023667-splitting%2Fhadoopc1h1%252C21302%252C1520214023667.default.1520584926990=last_update = 1522033841041 last_version = 34255 cur_worker_name = hadoopc1h3,21302, 1520943011826 status = in_progress incarnation = 3 resubmits = 3 batch = installed = 1 done = 0 error = 0} | org.apache.hadoop.hbase.master.SplitLogManager$TimeoutMonitor.chore (SplitLogManager.java:745) 2018-03-26 11:11:18,185 | INFO | hadoopc1h3,21300,1522031630949_splitLogManager__ChoreService_1 | total tasks = 1 unassigned = 0 tasks={/hbase/splitWAL/WALs%2Fhadoopc1h1%2C213 02%2C1520214023667-splitting%2Fhadoopc1h1%252C21302%252C1520214023667.default.1520584926990=last_update = 1522033841041 last_version = 34255 cur_worker_name = hadoopc1h3,21302, 1520943011826 status = in_progress incarnation = 3 resubmits = 3 batch = installed = 1 done = 0 error = 0} | org.apache.hadoop.hbase.master.SplitLogManager$TimeoutMonitor.chore (SplitLogManager.java:745) 节点上下电，RegionServer的wal分裂失败导致。

解决办法 停止HBase组件。 通过hdfs fsck命令检查/hbase/WALs文件的健康状态。 hdfs fsck /hbase/WALs 输出如下表示文件都正常，如果有异常则需要先处理异常的文件，再执行后面的操作。 The filesystem under path '/hbase/WALs' is HEALTHY 备份/hbase/WALs文件。 hdfs dfs -mv /hbase/WALs /hbase/WALs_old 新建/hbase/WALs目录。 hdfs dfs -mkdir /hbase/WALs 必须保证路径权限是hbase:hadoop。 启动HBase组件。

解决办法 在初始化建立Kafka消费者实例时，设置此配置项“max.partition.fetch.bytes”的值。 例如，参考本例，可以将此配置项设置为“5252880”： ...... // 安全协议类型 props.put(securityProtocol, kafkaProc.getValues(securityProtocol, "SASL_PLAINTEXT")); // 服务名 props.put(saslKerberosServiceName, "kafka"); props.put("max.partition.fetch.bytes","5252880"); ......

原因分析 使用客户端命令，打印NoAuthException异常。 Error while executing topic command org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth for /config/topics org.I0Itec.zkclient.exception.ZkException: org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth for /config/topics at org.I0Itec.zkclient.exception.ZkException.create(ZkException.java:68) at org.I0Itec.zkclient.ZkClient.retryUntilConnected(ZkClient.java:685) at org.I0Itec.zkclient.ZkClient.create(ZkClient.java:304) at org.I0Itec.zkclient.ZkClient.createPersistent(ZkClient.java:213) at kafka.utils.ZkUtils$.createParentPath(ZkUtils.scala:215) at kafka.utils.ZkUtils$.updatePersistentPath(ZkUtils.scala:338) at kafka.admin.AdminUtils$.writeTopicConfig(AdminUtils.scala:247) 通过客户端命令klist查询当前认证用户： [root@10-10-144-2 client]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: test@HADOOP.COM Valid starting Expires Service principal 01/25/17 11:06:48 01/26/17 11:06:45 krbtgt/HADOOP.COM@HADOOP.COM 如上例中当前认证用户为test。 通过命令id查询用户组信息。 [root@10-10-144-2 client]# id test uid=20032(test) gid=10001(hadoop) groups=10001(hadoop),9998(ficommon),10003(kafka)

问题背景与现象 在使用Kafka客户端命令创建Topic时，发现Topic无法被创建。 kafka-topics.sh --create --zookeeper 192.168.234.231:2181/kafka --replication-factor 1 --partitions 2 --topic test 提示错误NoAuthException，KeeperErrorCode = NoAuth for /config/topics。 具体如下： Error while executing topic command org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth for /config/topics org.I0Itec.zkclient.exception.ZkException: org.apache.zookeeper.KeeperException$NoAuthException: KeeperErrorCode = NoAuth for /config/topics at org.I0Itec.zkclient.exception.ZkException.create(ZkException.java:68) at org.I0Itec.zkclient.ZkClient.retryUntilConnected(ZkClient.java:685) at org.I0Itec.zkclient.ZkClient.create(ZkClient.java:304) at org.I0Itec.zkclient.ZkClient.createPersistent(ZkClient.java:213) at kafka.utils.ZkUtils$.createParentPath(ZkUtils.scala:215) at kafka.utils.ZkUtils$.updatePersistentPath(ZkUtils.scala:338) at kafka.admin.AdminUtils$.writeTopicConfig(AdminUtils.scala:247)

原因分析 DataNode的数据接受器不可用。 此时DataNode会有如下日志： 2016-03-17 18:51:44,721 | WARN | org.apache.hadoop.hdfs.server.datanode.DataXceiverServer@5386659f | hadoopc1h2:25009:DataXceiverServer: | DataXceiverServer.java:158 java.io.IOException: Xceiver count 4097 exceeds the limit of concurrent xcievers: 4096 at org.apache.hadoop.hdfs.server.datanode.DataXceiverServer.run(DataXceiverServer.java:140) at java.lang.Thread.run(Thread.java:745) DataNode的磁盘空间不足。 DataNode的心跳有延迟。

问题背景与现象 客户端安装成功，执行客户端命令例如yarn-session.sh时报错，提示如下： [root@host01 bin]# yarn-session.sh 2018-10-25 19:27:01,397 | ERROR | [main] | Error while trying to split key and value in configuration file /opt/flinkclient/Flink/flink/conf/flink-conf.yaml:81: "security.kerberos.login.principal:pippo " | org.apache.flink.configuration.GlobalConfiguration (GlobalConfiguration.java:160) Exception in thread "main" org.apache.flink.configuration.IllegalConfigurationException: Error while parsing YAML configuration file :81: "security.kerberos.login.principal:pippo " at org.apache.flink.configuration.GlobalConfiguration.loadYAMLResource(GlobalConfiguration.java:161) at org.apache.flink.configuration.GlobalConfiguration.loadConfiguration(GlobalConfiguration.java:112) at org.apache.flink.configuration.GlobalConfiguration.loadConfiguration(GlobalConfiguration.java:79) at org.apache.flink.yarn.cli.FlinkYarnSessionCli.main(FlinkYarnSessionCli.java:482)

原因分析 该问题的根因是NFS盘上的根目录权限不足，导致Flink程序启动后无法访问该目录。 MRS的Flink任务是在YARN运行，当集群未启用Kerberos认证时，在YARN上运行任务的用户为yarn_user。用户自定义的配置文件如果在任务启动之后使用，则文件以及文件的父目录（NFS上的文件所在的父目录，非集群节点上的软连接），必须允许yarn_user可以访问，否则程序中无法获取文件内容。当集群为启用Kerberos认证的集群时，则文件的权限必须允许提交程序的用户访问。

处理步骤 使用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客户端是否可用。

解决办法 修改或者添加自定义配置“allow.everyone.if.no.acl.found”参数为“true”，重启Kafka服务。 删除Topic设置的ACL。 例如： kinit test_user 需要使用Kafka管理员用户（属于kafkaadmin组）操作。 例如： kafka-acls.sh --authorizer-properties zookeeper.connect=10.5.144.2:2181/kafka --remove --allow-principal User:test_user --producer --topic topic_acl kafka-acls.sh --authorizer-properties zookeeper.connect=10.5.144.2:2181/kafka --remove --allow-principal User:test_user --consumer --topic topic_acl --group test

问题现象 使用SparkStreaming来消费Kafka中指定Topic的消息时，发现无法从Kafka中获取到数据。提示如下错误： Error getting partition metadata。 Exception in thread "main" org.apache.spark.SparkException: Error getting partition metadata for 'testtopic'. Does the topic exist? org.apache.spark.streaming.kafka.KafkaCluster$$anonfun$checkErrors$1.apply(KafkaCluster.scala:366) org.apache.spark.streaming.kafka.KafkaCluster$$anonfun$checkErrors$1.apply(KafkaCluster.scala:366) scala.util.Either.fold(Either.scala:97) org.apache.spark.streaming.kafka.KafkaCluster$.checkErrors(KafkaCluster.scala:365) org.apache.spark.streaming.kafka.KafkaUtils$.createDirectStream(KafkaUtils.scala:422) com.xxx.bigdata.spark.examples.FemaleInfoCollectionPrint$.main(FemaleInfoCollectionPrint.scala:45) com.xxx.bigdata.spark.examples.FemaleInfoCollectionPrint.main(FemaleInfoCollectionPrint.scala) sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) java.lang.reflect.Method.invoke(Method.java:498) org.apache.spark.deploy.SparkSubmit$.org$apache$spark$deploy$SparkSubmit$$runMain(SparkSubmit.scala:762) org.apache.spark.deploy.SparkSubmit$.doRunMain$1(SparkSubmit.scala:183) org.apache.spark.deploy.SparkSubmit$.submit(SparkSubmit.scala:208) org.apache.spark.deploy.SparkSubmit$.main(SparkSubmit.scala:123) org.apache.spark.deploy.SparkSubmit.main(SparkSubmit.scala)

问题背景与现象 在使用Kafka客户端命令设置Topic ACL权限时，发现Topic无法被设置。 kafka-topics.sh --delete --topic test4 --zookeeper 10.5.144.2:2181/kafka 提示错误ERROR kafka.admin.AdminOperationException: Error while deleting topic test4。 具体如下： Error while executing topic command : Error while deleting topic test4 [2017-01-25 14:00:20,750] ERROR kafka.admin.AdminOperationException: Error while deleting topic test4 at kafka.admin.TopicCommand$$anonfun$deleteTopic$1.apply(TopicCommand.scala:177) at kafka.admin.TopicCommand$$anonfun$deleteTopic$1.apply(TopicCommand.scala:162) at scala.collection.mutable.ResizableArray$class.foreach(ResizableArray.scala:59) at scala.collection.mutable.ArrayBuffer.foreach(ArrayBuffer.scala:47) at kafka.admin.TopicCommand$.deleteTopic(TopicCommand.scala:162) at kafka.admin.TopicCommand$.main(TopicCommand.scala:68) at kafka.admin.TopicCommand.main(TopicCommand.scala) (kafka.admin.TopicCommand$)

原因分析 使用客户端命令，打印AdminOperationException异常。 通过客户端命令klist查询当前认证用户： [root@10-10-144-2 client]# klist Ticket cache: FILE:/tmp/krb5cc_0 Default principal: test@HADOOP.COM Valid starting Expires Service principal 01/25/17 11:06:48 01/26/17 11:06:45 krbtgt/HADOOP.COM@HADOOP.COM 如上例中当前认证用户为test。 通过命令id查询用户组信息 [root@10-10-144-2 client]# id test uid=20032(test) gid=10001(hadoop) groups=10001(hadoop),9998(ficommon),10003(kafka)