REST接口访问常用组件原生界面（yarn, mr, hive）应用场景业务开发过程中，经常使用rest接口访问yarn，mr原生界面信息进行管理。hive同时提供webhcat接口进行交互。关键点交互过程使用kerberos认证，http访问场景下也叫做spnego认证同组件原生界面交互时需要跟服务端做ssl以最简单的GET请求为例分别获取Yarn, MapReduce, hive相关信息确定访问的请求ip以及端口参考如下连接了解如获取直连组件原生界面的方法：cid:link_0比如//Yarn访问resource manager String url1 = "https://xxx.xx.x.xxx:26001/ws/v1/sscheduler/resourcepools/list"; //Mapreduce访问job history server String url = "https://xxx.xx.x.xxx:26014:26014/ws/v1/history/mapreduce/jobs"; //Hive使用webHcat接口查询库 String url = "https://xxx.xx.x.xxx:21055/templeton/v1/ddl/database";查询结果Yarn:MR:Hive:FAQ问题1：运行时遇到问题 问题原因：ssl没做参考样例代码片段配置证书

使用的是hive用户组下的用户，在manager网页中把能给的权限都给了，还是提示 Permissin denied

有没有从HIVE导出到MySQL对应的模板文件XML和JSON文件提供啊，不知道要填哪些参数。

1.集群互信6.5.1.3和6.5.1.7集群是否可以配置互信？2.配置互信后不更新客户端有什么影响？3.通过A集群spark访问B集群habse，是否只需要配置A集群域就可以B集群不需要动？ B集群域名不改是否需要重新安装客户端？及key文件4.ntp默认的时间一致，ntp IP不一致是否有影响？

kafka报错这个是什么引起的？对业务有影响没？

Manager经典案例集锦一：ssh、su命令执行卡顿导致OMS异常问题现象：主备频繁倒换，oms偶发登陆不上，FI页面打不开查看oms状态floatip异常，主备频繁倒换查看主备oms节点：du -sh /var/log/btmp 有2个多G，执行su - omm命令都很卡问题根因/var/log/btmp 文件比较大，导致执行命令很卡，导致oms浮动ip异常造成/var/log/btmp 文件比较大可能原因祥见(linux_work32挖矿病毒处置方法.docx)解决方法清理 /var/log/btmp 文件

Manager全部案例集合见维护宝典：https://support.huawei.com/hedex/hdx.do?docid=EDOC1100222546&lang=zh&idPath=22658044|22662728|22666212|22396131（FusionInsight HD&MRS租户面集群故障案例（6.5.X-8.X）->维护故障类->Manager->常见故障）Manager经典案例、总结、重大问题见下表：经典案例分类序号案例（点击标签查看详情）出现频次环境类常见故障1-1ssh、su命令执行卡顿导致OMS异常：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★★1-2网络慢导致Manager页面访问失败：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★1-3/etc/ntp.conf文件权限不对导致ntp异常：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★★1-4节点健康状态为Bad（故障）：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★★★1-5postgresql.conf配置文件有误导致gaussdb异常：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★★1-6Manager页面上报所有节点ntp服务告警：维护类故障（6.5.X-8.X）>Manager>常见故障>监控告警常见故障★★★　1-7 OS定时任务进程异常导致节点互信异常：维护类故障（6.5.X-8.X）>Manager>常见故障>环境类常见故障★★★OS类常见故障2-1 配置的ntp外部时钟源可以ping通，但是ntp服务不能同步时间：维护类故障（6.5.X-8.X）>Manager>常见故障>OS类常见故障★★★★　2-2系统时间倒退导致NodeAgent无法启动：维护类故障（6.5.X-8.X）>Manager>常见故障>OS类常见故障★★　2-3安装OMS时配置失败：维护类故障（6.5.X-8.X）>Manager>常见故障>OS类常见故障★★★★　2-4suse12.2 pam-systemd导致su、sudo、ssh卡顿问题：维护类故障（6.5.X-8.X）>Manager>常见故障>OS类常见故障★★　节点类常见故障3-1节点上下电导致NodeAgent启动失败：维护类故障（6.5.X-8.X）>Manager>常见故障>节点类常见故障>节点上下电导致NodeAgent启动失败★★★★3-2Ntp启动失败导致NodeAgent故障：维护类故障（6.5.X-8.X）>Manager>常见故障>节点类常见故障>Ntp启动失败导致NodeAgent故障★★★3-3修改了/etc/sysconfig/ntpd文件里的内容导致节点故障：维护类故障（6.5.X-8.X）>Manager>常见故障>节点类常见故障>修改了/etc/sysconfig/ntpd文件里的内容导致节点故障★★★3-4某个节点所有实例均失败， nodeagent不断在重启：维护类故障（6.5.X-8.X）>Manager>常见故障>节点类常见故障>某个节点所有实例均失败， nodeagent不断在重启★★★

hive全部案例集合见维护宝典：https://support.huawei.com/hedex/hdx.do?docid=EDOC1100222546&lang=zh&idPath=22658044|22662728|22666212|22396131（FusionInsight HD&MRS租户面集群故障案例（6.5.X-8.X）->维护故障类->hive->常见故障）hive经典案例、总结、重大问题见下表：经典案例分类序号案例出现频次sql优化1.1Hive sql写法问题导致结果异常合集（一）★★1.2Hive sql写法问题导致结果异常合集（二）★★1.3Hive sql写法问题导致运行慢问题合集（一）★★★★1.4Hive sql写法问题导致运行慢问题合集（二）★★★★1.5Hive sql写法问题导致运行慢问题合集（三）★★★★服务异常2.1Hiveserver启动成功，但页面显示状态故障★★2.2Metastore启动故障，报failed to initizlize master key★★2.3Metastore启动故障，报user hive does not belong to hive★★★★

Flink全部案例集合见维护宝典：https://support.huawei.com/hedex/hdx.do?docid=EDOC1100222546&lang=zh&idPath=22658044|22662728|22666212|22396131  （FusionInsight HD&MRS租户面集群故障案例（6.5.X-8.X）->维护故障类->Flink->常见故障）经典案例分类序号案例出现频次现网经典案例1.1关于table.exec.state.ttl参数的生效机制★★客户端安装常见问题2.1Flink客户端配置方法(维护宝典：维护类故障（维护类故障（6.5.X-8.X）>Flink>FAQ>下载并配置Flink客户端)★★★★★2.2升级后任务提交失败，报zk节点权限不足(维护宝典：维护类故障（6.5.X-8.X）>Flink>任务提交常见故障>FusionInsight HD大版本从6.5.1升级到8.x版本后任务提交失败)★★★★★2.3开启ssl后，正确的提交方式（维护宝典：维护类故障（6.5.X-8.X）>Flink>任务提交常见故障>创建Flink集群时执行yarn-session.sh命令失败）★★★★★ 

Flink的table.exec.state.ttl参数说明：Flink SQL 新手有可能犯的错误，其中之一就是忘记设置空闲状态保留时间导致状态爆 炸。列举两个场景：➢ FlinkSQL 的 regular join（inner、left、right），左右表的数据都会一直保存在 状态里，不会清理！要么设置 TTL，要么使用 FlinkSQL 的 interval join。➢ 使用 Top-N 语法进行去重，重复数据的出现一般都位于特定区间内（例如一小时 或一天内），过了这段时间之后，对应的状态就不再需要了。Flink SQL 可以指定空闲状态(即未更新的状态)被保留的最小时间，当状态中某个 key 对应的状态未更新的时间达到阈值时，该条状态被自动清理：基于811版本测试，测试SQL的代码如下： EnvironmentSettings.Builder builder = EnvironmentSettings.newInstance();         builder.inStreamingMode();         builder.useBlinkPlanner();         EnvironmentSettings settings = builder.build();         StreamExecutionEnvironment env = StreamExecutionEnvironment.getExecutionEnvironment(); //        env.setStreamTimeCharacteristic(TimeCharacteristic.EventTime);          StreamTableEnvironment tableEnv = StreamTableEnvironment.create(env, settings);          env.enableCheckpointing(6000L);       env.setStateBackend(new RocksDBStateBackend("hdfs:///xxxx));//启用hdfs状态后端       env.getCheckpointConfig().setCheckpointingMode(CheckpointingMode.EXACTLY_ONCE);       env.getCheckpointConfig().setCheckpointTimeout(600000L);       env.getCheckpointConfig().setMaxConcurrentCheckpoints(1);       env.getCheckpointConfig().setFailOnCheckpointingErrors(false);       env.getCheckpointConfig().enableExternalizedCheckpoints(CheckpointConfig.ExternalizedCheckpointCleanup.RETAIN_ON_CANCELLATION);          Configuration configuration = tableEnv.getConfig().getConfiguration();         configuration.setString("table.exec.state.ttl","10000");          String sqlTable_1 =                 "CREATE TABLE source1 (\n" +                 "  name varchar(10),\n" +                 "  vaa varchar(10),\n" +                 "  ts AS PROCTIME()\n" +                 ") WITH (\n" +                 "  'connector' = 'kafka',\n" +                 "  'topic' = 'user_source1',\n" +                 "  'properties.bootstrap.servers' = 'kafka:21005',\n" +                 "  'properties.group.id' = 'testGroup',\n" +                 "  'scan.startup.mode' = 'latest-offset',\n" +                 "  'format' = 'csv'\n" +                 ")";          String SqlTable_2 = "" +                 "CREATE TABLE source2 (\n" +                 "  name varchar(10),\n" +                 "  vaa varchar(10),\n" +                 "  ts AS PROCTIME()\n" +                 ") WITH (\n" +                 "  'connector' = 'kafka',\n" +                 "  'topic' = 'user_source2',\n" +                 "  'properties.bootstrap.servers' = 'kafka:21005',\n" +                 "  'properties.group.id' = 'testGroup',\n" +                 "  'scan.startup.mode' = 'latest-offset',\n" +                 "  'format' = 'csv'\n" +                 ")";          String inputTable="create table p (\n" +                 "  name1 varchar(10),\n" +                 "  name2 varchar(10),\n" +                 "  vaa1 varchar(10),\n" +                 "  vaa2 varchar(10)\n" +                 ") with ('connector' = 'print')";          String sql = "insert into\n" +                 "  p\n" +                 "select\n" +                 "  source1.name,\n" +                 "  source2.name,\n" +                 "  source1.vaa,\n" +                 "  source2.vaa\n" +                 "FROM\n" +                 "  source1\n" +                 "  join source2 on source1.name = source2.name";          //创建表1         tableEnv.executeSql(sqlTable_1);         //创建表2         tableEnv.executeSql(SqlTable_2);         //创建输出表         tableEnv.executeSql(inputTable);         //执行结果         tableEnv.executeSql(sql); 执行sql的代码片段如下：在这个用例中我们使用的TTL时间参数为10s失效。当同时输入：topic:user_source1 的数据 zs,aaa   topic:user_source2的数据zs,bbb 结果如下：但是输入：topic:user_source1 的数据ls,aaa 间隔大于10s后输入 topic:user_source2的数据ls,bbb未出现结果：从测试结果来看：（1）常规联接是最通用的联接类型，其中任何新记录或对联接任一侧的更改都是可见的，并且会影响整个联接结果。例如左边有一条新记录，当product id 相等时，它会与右边所有以前和以后的记录合并。SELECT * FROM OrdersINNER JOIN ProductON Orders.productId = Product.id对于流式查询，常规连接的语法是最灵活的，并且允许任何类型的更新（插入、更新、删除）输入表。但是，此操作具有重要的操作含义：它需要将连接输入的两侧永远保持在 Flink 状态。因此，计算查询结果所需的状态可能会无限增长，具体取决于所有输入表和中间连接结果的不同输入行的数量。（2）如果设置了TTL的时间后，过了TTL时间后，之前的状态数据会被删除。

GaussDB 8009集群如果各个节点NTP都配置为第三方服务器ntp会有什么影响？（正常是OMS配置第三方NTP,节点向OMS同步时钟）

【直播主题】华为云FusionInsight 8.2.0 MRS新版本特性能力解读&最佳实践【回看链接】cid:link_1【直播介绍】本期直播将由华为云MRS首席架构师Sailing老师与资深工程师Haoxi老师带大家一起玩转MRS新版本，详细解读全链路实时数据湖、高性能智能化交互式引擎等新方案、新能力。调研问卷：cid:link_0

一、 Kafka request日志打开和关闭方式打开：集群 -> Kafka -> 配置 -> 全部配置 -> kafka.request.log.level配置改为DEBUG后保存。2. 关闭：集群 -> Kafka -> 配置 -> 全部配置 -> kafka.request.log.level配置改为INFO后保存。保存后不用重启Kafka实例，一般建议开5到10分钟。二、 Kafka request分析Kafka request原理 Kafka请求处理模型如下图所示：Kafka server端启动一个Acceptor线程，负责监听socket新的连接请求、注册OP_ACCEPT事件。Acceptor将监听到的新连接以轮询方式发送给ProcessorProcessor注册OP_READ事件，把接收到的请求放到request队列KafkaRequestHandler从Request队列中获取请求交给kafkaApi处理KakfaApi通过其handle()方法执行响应的处理逻辑KakfaApi处理完后将Response放回到Request对应的Processor的ResponseQueue中。processor从response队列中取出待发送的response发送给客户端。Request请求监控指标Request类中request处理流程如下图所示：如上图所示，流程可分为六个阶段：请求被processor放入Request队列等待处理：此过程处理速度与num.io.threads配置有关。IO线程在本地节点处理：处理速度与本节点CPU、IO有关。IO线程在远端节点处理：处理速度与远端节点CPU、IO有关，也与节点间的网络有关。限流等待：与限流设置有关。Response请求放在response队列中等待返回：此过程处理速度与num.network.threads配置有关。Response请求被发送给客户端：处理速度与服务端和客户端的网络有关。以上六个阶段对应的request日志中的指标信息是：requestQueueTime: 请求在request队列中等待时间，此过程耗时多可增大num.io.threads来缓解。localTime: 请求在本节点处理耗时，此过程耗时多可检查节点上的CPU和IO使用率是否高及IO线程数配置是否过小。remoteTime: 请求在其他节点处理耗时，此过程耗时多需检查节点间的网络是否有延迟、对端节点的CPU和IO使用率是否高。throttleTime: 限流的时间。responseQueueTime: 请求在response队列中等待时间此过程耗时多可增大num.network.threads来缓解。sendTime: processor从response队列中获取处理结果并发送给客户端的时间，此过程耗时多说明服务端与客户端网络存在较大延迟。除了上述指标外，request日志中还涉及以下指标：totalTime：请求处理总时间。securityProtocol: 请求的协议类型。principal:User: 请求的用户。clientId：生产和消费如果不设置clientId，Kafka会自动生成clientid，命名为producer-X和consumer-X，副本数据同步的clientId为broker-X-fetcher-X。apiKey：表示所调用的请求。生产和消费问题排查常看的请求有生产请求PRODUCE，消费请求FETCH，元数据请求METADATA，提交offset请求OFFSET_COMMIT。生产请求request日志说明生产请求示例：2020-12-07 11:14:52,861 | DEBUG | [data-plane-kafka-network-thread-1-ListenerName(PLAINTEXT)-PLAINTEXT-5] | Completed request:RequestHeader(apiKey=PRODUCE, apiVersion=5, clientId=producer-1, correlationId=14) -- {acks=1,timeout=30000,numPartitions=1},response:{responses=[{topic=test,partition_responses=[{partition=1,error_code=0,base_offset=4032196,log_append_time=-1,log_start_offset=0}]}],throttle_time_ms=0} from connection 100.112.22.201:21005-10.144.116.89:53748-1;totalTime:0.525,requestQueueTime:0.059,localTime:0.385,remoteTime:0.0,throttleTime:0.074,responseQueueTime:0.036,sendTime:0.056,securityProtocol:PLAINTEXT,principal:User:Default#Principal,listener:PLAINTEXT | kafka.request.logger (RequestChannel.scala:209)生产请求查找关键字：apiKey=PRODUCE、topic=topicName和生产端IP。无论生产端发送数据是否成功，request日志中都有相应的日志信息。Responses信息中的error_code如果为0表示生产段发送数据成功，error_code如果为非0值表示生产端发送数据失败，例如error_code为10，表示生产端发送数据的大小大于服务端设置的消息最大值。三、消费请求request日志说明消费请求示例：2020-12-07 17:41:42,143 | DEBUG | [data-plane-kafka-network-thread-1-ListenerName(PLAINTEXT)-PLAINTEXT-3] | Completed request:RequestHeader(apiKey=FETCH, apiVersion=7, clientId=consumer-1, correlationId=7) -- {replica_id=-1,max_wait_time=500,min_bytes=1,max_bytes=52428800,isolation_level=0,session_id=0,epoch=0,topics=[{topic=test,partitions=[{partition=1,fetch_offset=1500,log_start_offset=-1,max_bytes=1048576},{partition=3,fetch_offset=0,log_start_offset=-1,max_bytes=1048576}]}],forgetten_topics_data=[]},response:{throttle_time_ms=0,error_code=0,session_id=758584167,responses=[{topic=test,partition_responses=[{partition_header={partition=1,error_code=0,high_watermark=5884956,last_stable_offset=-1,log_start_offset=0,aborted_transactions=null},record_set=org.apache.kafka.common.record.FileRecords@40f12818},{partition_header={partition=3,error_code=0,high_watermark=0,last_stable_offset=-1,log_start_offset=0,aborted_transactions=null},record_set=[]}]}]} from connection 100.112.22.201:21005-10.144.116.89:57910-3;totalTime:499.237,requestQueueTime:0.09,localTime:0.549,remoteTime:0.0,throttleTime:0.276,responseQueueTime:0.033,sendTime:498.585,securityProtocol:PLAINTEXT,principal:User:Default#Principal,listener:PLAINTEXT | kafka.request.logger (RequestChannel.scala:209)消费请求查找关键字：apiKey=FETCH、clientId和消费端IP，topic=topicName也可作为查找的依据，但是topics中的内容有时为空，可能查找不到。topics中的内容为空是因为其内容已被缓存在session链路两侧。无论消费是否成功，request日志中都有相应的日志信息。Responses信息中的error_code如果为0表示消费成功，error_code如果为非0值表示消费失败，例如error_code为3，表示服务端没有这个topic partition。

生产性能测试脚本分析使用客户端脚本kafka-producer-perf-test.sh能够测试当前集群的生产的性能基线。如下图：使用方法（以6.5.1版本为例）如下：./kafka-producer-perf-test.sh --topic topicName --num-records 1000000 --record-size 1000 --throughput 20000 --producer.config ../config/producer.properties --print-metrics效果图如下：参数解读：--topic topic名称--num-records 要发送的数据条数--record-size 要发送的单条数据大小--throughput 测试速率显示，建议现网测试的时候如果有生产业务在跑，建议合理设置该值。--producer.config 生产者配置。-print-metrics 打印测试的统计信息。该脚本的测试场景主要用于检测集群的性能基线、检查网络带宽等。注意：在检测性能基线时需要停止业务并且将—throughput 设置为-1。在检测网络带宽时，需要在集群内和集群外的客户端节点分别部署FI的客户端。并对比性能的测试结果。禁止使用该脚本向生产使用的topic中发送数据。消费性能测试脚本分析使用客户端脚本kafka-consumer-perf-test.sh能够测试当前集群的消费的性能基线。使用方法如下：sh kafka-consumer-perf-test.sh --group id1 --topic test --messages 1000 --broker-list kafka业务IP:21007 --consumer.config ../config/consumer.properties –threads 2 --print-metrics--group 为消费用的消费者组，注意一定不要与生产使用的消费者组重复。--topic topic名称--messages 需要消费的消息条数--broker-list broker的业务ip列表–threads 测试使用的消费并行度--print-metrics 是否输出统计信息。该脚本的测试场景主要用于检测集群的性能基线。注意：当使用该脚本测试现网消费性能过程中，groupid需要自己随机指定，禁止使用业务所使用的groupid。在检测网络带宽时，需要在集群内和集群外的客户端节点分别部署FI的客户端。并对比性能的测试结果。注意：如果命令在FusionInsight HD集群内部（例如在主OMS节点部署了kafka客户端）使用以上脚本测试出的性能若不稳定且持续在几M到几十M之间转换并伴随发送超时，则可以认为kafka集群性能异常。如下图如果命令在FusionInsight HD集群外部（非FI集群内部节点）的客户端节点执行性能低于90M但是FI集群内部性能远大于90M，则认为客户端到服务端时间存在带宽问题。

图：client为业务的客户端节点（生产数据、消费数据的节点上图为例，client节点与kafka集群的broker-3节点可能存在网络问题，那么需要用以下的手段进行检测：网络延迟检测：从client节点向broker-3节点发送ping包然后查看前30次的延时，看一下是否有网络抖动，如下命令：ping –s 5000 broker-3IP延时在20ms以内则认为正常。2. 带宽检测：网络延迟没有问题并不代表带宽是正常的，通常带宽的检查方法使用scp命令就能够看出带宽的大小。流程如下：找一个1G左右的压缩文件（不要使用文件夹）执行scp命令，将文件传送到broker-3节点的/tmp目录下，命令如下：scp 文件root@broker-3 ip:/tmp/  执行结果例如如下：如上结果，每秒传送性能在107M左右，如果这个性能低于80M则认为带宽不足或者带宽占用量大。可定性为网络质量问题。