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则认为带宽不足或者带宽占用量大。可定性为网络质量问题。

kafka-root.log 位于broker实例所在节点的路径：/var/log/Bigdata/kafka/broker下，该日志里面会统计每分钟kafka磁盘io的使用率，打印信息如下：可以通过Linux命令批量检查一个或者整个集群的io使用情况。         （1）查询一个broker节点的io使用情况，并且过滤掉0.0x的低磁盘使用率数据。登录到其中一个broker节点的后台目录/var/log/Bigdata/kafka/broker，执行以下命令cat kafka-root.* |   grep "Collect topic partition" | awk -F'is:' '{print $2}' | awk -F',' '{print $1}' | grep –v "0.0"（2） 查询整个集群所有broker节点的io使用情况，并且过滤掉0.0x的低磁盘使用率数据。通过前台将对应时间段的kafka日志全部收集回来在本地全部解压缩后，在根目录下全部查询，zgrep ioUsage ./根目录kafka的目录*/var/log/Bigdata/kafka/broker/kafka-root.* | grep "Collect topic partition" | awk -F'topic info' '{print $1}' | awk '{print $1 " " $2 " " $15}' | grep -v "0.0"例如：如下根目录下kafka的目录名称为n-kafka-* 那么命令为zgrep "ioUsage" ./n-kafka-*/var/log/Bigdata/kafka/broker/kafka-root.* | grep "Collect topic partition" | awk -F'topic info' '{print $1}' | awk '{print $1" "$2 " " $15}' | grep -v "0.0"得出的结果如下：如果以上的结果持续出现0.8~1.0的数值，说明磁盘io在80%~100%之间，磁盘可能存在异常注意：在8.0版本后ioUsage的数据信息被调整为了DEBUG，如果需要该数据需要手动调整broker节点的log4j日志。调整方式如下：1，登录到每个broker节点的/opt/huawei/Bigdata/FusionInsight_Current/*_*_Broker/etc目录下2，打开log4j.properties文件vim log4j.properties3，在最后一行追加log4j.logger.com.huawei.kafka.PartitionStatusMetrics=DEBUG,rootAppender

PR巡检是RAID卡的一个特性，它会周期性的定时巡检磁盘，对数据进行检查校验，以防出错，但是在巡检的时候会导致磁盘读写性能下降。Raid卡缓存写策略，建议使用WB模式，WB：在配置界面中一般体现为“Write Back”等字样。使用此策略后，需要向虚拟磁盘写数据时，会直接写入Cache中，当写入的数据积累到一定程度，RAID卡才将数据刷新到虚拟磁盘，这样不但实现了批量写入，而且提升了数据写入的速度。当控制器Cache收到所有的传输数据后，将给主机返回数据传输完成信号。要使用该策略，要求RAID卡支持数据掉电保护功能，且如果此时超级电容异常，可能导致数据丢失。WT：在配置界面中一般体现为“Write Through”等字样。使用此策略后，RAID卡向虚拟磁盘直接写入数据，不经过Cache。当磁盘子系统接收到所有传输数据后，控制器将给主机返回数据传输完成信号。此策略缺点是写入速度较低。排查方式：针对以上两种场景，均有明显的磁盘IO升高的情况，建议通过3.3章节对kafka-root.log进行检查。如果kafka集群的磁盘部署使用了raid5建议硬件侧关闭PR巡检。开启WB模式

数据压缩是kafka解决空间问题和超大数据问题关键场景，例如：当kafka的磁盘空间不足时，可以使用数据压缩，来节省磁盘空间的使用。当生产端需要向kafka集群发送大量的超大数据（大于1M的数据）时可以通过开启压缩模式来减少传输过程中带来的网络消耗。压缩模式开启有一定的要求，为什么会这样，先看kafka压缩的原理：Kafka服务端使用的topic最终压缩模式（由compression.type决定）为producer。这也就意味着，开启压缩后存在kafka中的数据类型其实本质就是一个压缩包。如下图：     图：客户端与kafka服务端版本一致的存储方式如果客户端与kafka服务端版本不一致会怎样？再看下面的图。                                             图：客户端与kafka服务端版本不一致的存储方式客户端使用的kafka-client-xxxx.jar版本要与服务端的版本不一致时，在kafka的服务端会出现，对数据的“解压缩，再压缩”的过程。这个流程会非常损耗CPU，并且可能会造成kafka的GC超时从而导致kafka集群性能下降。排查方式：如果节点CPU使用率超过80%，或者有kafka的GC时间超过阈值的告警。或者查看异常的broker节点的监控曲线：如果这个节点的GC时间长时间达到了秒级，说明GC不正常。给kafka进程打一个jstack，如果jstack中出现gzip, snappy,lz4,zstd，说明有开启压缩，例如开启了GZIP。解决方案：建议客户升级客户端，保持和服务端一致使用低版本客户端时，禁用压缩

1.SAPHANA对接 2.大数据组件中HDFS、Hive可用通过S3文件系统接口访问S3存储 3.大数据平台支持异构集群部署，在集群中存在不同硬件规格的服务器，允许在CPU类型，内存大小、硬盘数量与容量等方面有差异

FusionInsight HD安全模式下，需要认证，但是有时候需要任务跑在FusionInsight上，写到外部的非认证HBase集群，此时就会出现zk一直无法连接的问题。虽然后面通过去掉zk认证的相关参数，可以对接外部集群，但是对接FusionInsightHD又出现了问题Spark程序大致如下public List read(List list) { Configuration conf; if (isFusion) { JavaSparkContext jsc = new JavaSparkContext(getSparkSession().sparkContext()); conf = HBaseConfiguration.create(jsc.hadoopConfiguration()); try { // 设置zk服务器端认证信息 String krb5Conf = System.getProperty(LoginUtil.JAVA_SECURITY_KRB5_CONF_KEY); String keytab = System.getProperty("spark.yarn.keytab"); String principal = System.getProperty("spark.yarn.principal"); // zk认证和hadoop认证 logger.info("HBaseReader zk principal:{},keytab:{},krb5Conf:{}", new String[]{hadoopPrincipal, keytab, krb5Conf}); LoginUtil.setJaasConf(LoginUtil.ZOOKEEPER_DEFAULT_LOGIN_CONTEXT_NAME, principal, keytab); LoginUtil.setZookeeperServerPrincipal(LoginUtil.ZOOKEEPER_DEFAULT_SERVER_PRINCIPAL); logger.info("HBaseReader hadoop principal:{},keytab:{},krb5Conf:{}", new String[]{principal, keytab, krb5Conf}); LoginUtil.login(principal, keytab, krb5Conf, conf); } catch (Exception e) { logger.error("HBaseReader cannot login", e); throw new RuntimeException("HBaseReader login fail"); } } else { conf = new Configuration(); System.setProperty("zookeeper.sasl.client", "false"); System.clearProperty("java.security.auth.login.config"); System.clearProperty("zookeeper.server.principal"); } conf.set("hbase.zookeeper.quorum", zkServers); conf.set("hbase.zookeeper.property.clientPort", zkPort); conf.set(TableInputFormat.INPUT_TABLE, tableName); conf = addAdditionConfig(conf); JavaPairRDD rdd = new JavaSparkContext(this.getSparkSession().sparkContext()) .newAPIHadoopRDD(conf, TableInputFormat.class, ImmutableBytesWritable.class, Result.class ); JavaRDD rddRow = null; boolean useDefaultConfig = nodeMapping.getMatrix() == null || nodeMapping.getMatrix().length <= 0; if (useDefaultConfig) { rddRow = rdd.mapPartitions(new HBaseResultToRow(rowKeyAlias)); } else { Map> aliasFamilyQualifierMap = new HashMap<>(); for (String[] strings : nodeMapping.getMatrix()) { aliasFamilyQualifierMap.put(strings[2], new Tuple2(strings[0], strings[1])); } rddRow = rdd.mapPartitions(new HBaseResultToRow(aliasFamilyQualifierMap, rowKeyAlias)); } // ..... more }这个就很迷,明明已经 Login success!!!!!!!!!!!!!! 但是HBase访问还是报错2022-10-18 15:55:17,506 | ERROR | [htable-pool2-t1] | SASL authentication failed. The most likely cause is missing or invalid credentials. Consider 'kinit'. | org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$1.run(RpcClientImpl.java:687) javax.security.sasl.SaslException: GSS initiate failed [Caused by GSSException: No valid credentials provided (Mechanism level: Failed to find any Kerberos tgt)] at com.sun.security.sasl.gsskerb.GssKrb5Client.evaluateChallenge(GssKrb5Client.java:211) at org.apache.hadoop.hbase.security.HBaseSaslRpcClient.saslConnect(HBaseSaslRpcClient.java:169) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.setupSaslConnection(RpcClientImpl.java:620) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.access$700(RpcClientImpl.java:165) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:750) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection$2.run(RpcClientImpl.java:747) 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.hadoop.hbase.ipc.RpcClientImpl$Connection.setupIOstreams(RpcClientImpl.java:747) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.writeRequest(RpcClientImpl.java:950) at org.apache.hadoop.hbase.ipc.RpcClientImpl$Connection.tracedWriteRequest(RpcClientImpl.java:914) at org.apache.hadoop.hbase.ipc.RpcClientImpl.call(RpcClientImpl.java:1288) at org.apache.hadoop.hbase.ipc.AbstractRpcClient.callBlockingMethod(AbstractRpcClient.java:227) at org.apache.hadoop.hbase.ipc.AbstractRpcClient$BlockingRpcChannelImplementation.callBlockingMethod(AbstractRpcClient.java:336) at org.apache.hadoop.hbase.protobuf.generated.ClientProtos$ClientService$BlockingStub.scan(ClientProtos.java:35518) at org.apache.hadoop.hbase.client.ScannerCallable.openScanner(ScannerCallable.java:404) at org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:211) at org.apache.hadoop.hbase.client.ScannerCallable.call(ScannerCallable.java:65) at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithoutRetries(RpcRetryingCaller.java:218) at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas$RetryingRPC.call(ScannerCallableWithReplicas.java:398) at org.apache.hadoop.hbase.client.ScannerCallableWithReplicas$RetryingRPC.call(ScannerCallableWithReplicas.java:372) at org.apache.hadoop.hbase.client.RpcRetryingCaller.callWithRetries(RpcRetryingCaller.java:139) at org.apache.hadoop.hbase.client.ResultBoundedCompletionService$QueueingFuture.run(ResultBoundedCompletionService.java:79) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624) at java.lang.Thread.run(Thread.java:748)

什么是OpenStack？OpenStack能做什么？ - 华为 (huawei.com)原文：华为FushionSphere OpenStack简介应该是：FusionSphere OpenStack文中多处有问题。

操作场景Apache Livy 是一个可以通过 REST 接口与 Spark 集群进行交互的服务，它可以提交 Spark 作业或者 Spark 代码片段，同步或者异步的进行结果检索以及 Spark Context 上下文管理。了解更多请访问livy官网http://livy.incubator.apache.org/。本指导旨在介绍，如何在创建集群时添加引导操作，利用shell脚本自动化地在MRS集群master节点安装livy。使用限制在创建集群时使用只在master节点安装livy创建集群时需要赋予集群默认委托MRS_ECS_DEFAULT_AGENCY，赋予集群节点权限从OBS对象桶中下载livy安装包只适用于MRS普通集群，开启kerberos认证的安全集群暂不适用前提条件对MRS集群引导操作功能有一定了解，具体可以参见链接引导操作简介、通过引导操作安装第三方软件、引导操作脚本样例文后所附引导操作脚本bootstrap-livy.sh已上传到OBS桶某路径下，本指导存放脚本的OBS桶路径以"obs://qianyu-xg/"为例。livy安装包已下载，并上传到OBS桶某路径下，附livy安装包官方下载链接livy-download。本指导存放livy安装包的OBS桶路径以"obs://qianyu-xg/pack/"为例，livy安装包名以"apache-livy-0.7.1-incubating-bin.zip"为例操作步骤1、如下图所示，使用自定义购买方式购买MRS集群：2、如下图，在高级配置阶段，点选引导操作添加按钮：3、如下图所示，填写引导操作相关参数，具体参数内容见如下描述描述：名称：该引导操作名称，默认bootstrap_0，可不做修改脚本路径：bootstrap-livy.sh在OBS对象桶上存放的全路径，obs://qianyu-xg/bootstrap-livy.sh参数：bootstrap-livy.sh的脚本入参，第一个为livy安装包存放路径，obs://qianyu-xg/pack/，第二个为livy安装包全名，apache-livy-0.7.1-incubating-bin.zip 执行节点：只选择master节点，active master可以不开启执行时机：组件首次启动后失败操作：继续4、以上操作结束后，点选确定，完成引导操作添加：5、集群创建完成后，使用EIP访问livy web ui，浏览器中输入 http://${manager_eip}:8998/ 访问附：引导脚本bootstrap-livy.sh#!/bin/bash -exBUCKET_PATH=$1ZIP_FILE=$2LIVY_DIR=`basename $ZIP_FILE .zip`DOWNLOAD_DIR=/tmpAPPLICATION_DIR=/home/ommecho "=====================Set env====================="if [ ! -f /opt/Bigdata/client/bigdata_env ] ; then echo "Skip master3" exit 0fisource /opt/Bigdata/client/bigdata_envecho "=====================Download and unpack install package====================="cd $DOWNLOAD_DIRhdfs dfs -get $BUCKET_PATH/$ZIP_FILE ./$ZIP_FILEif [ ! -f ./$ZIP_FILE ] ; then echo "Failed to download $ZIP_FILE" return 1fi echo "Succeeded to download $ZIP_FILE"cd $APPLICATION_DIRunzip -d $APPLICATION_DIR $DOWNLOAD_DIR/$ZIP_FILE echo "=====================Configure livy====================="cd $APPLICATION_DIR/$LIVY_DIRcp conf/livy.conf.template conf/livy.confecho "livy.spark.master = yarn" >> conf/livy.confecho "livy.spark.deploy-mode = cluster" >> conf/livy.confecho "=====================Start livy====================="bin/livy-server start > /home/omm/livy.out

我看了官方的demo代码，在hive to hbase项目代码里，只设置了appName，其余的全部没有设置，是可以自动读取hive-site.xml等配置文件吗？huaweicloud-mrs-example/SparkHivetoHbase.java at mrs-3.0.2 · huaweicloud/huaweicloud-mrs-example (github.com)这是我举例的代码连接这个是代码中读取hive表数据的代码片段 SparkConf conf = new SparkConf().setAppName("SparkHivetoHbase"); JavaSparkContext jsc = new JavaSparkContext(conf); HiveContext sqlContext = new org.apache.spark.sql.hive.HiveContext(jsc); Dataset dataFrame = sqlContext.sql("select name, account from person");如果在代码中需要设置的话我有一个问题，hive默认的元数据服务是DBService，那hive.metastore.uris这一项应该怎么配置

我需要通过虚拟机搭建一个3节点的FI集群，看到简单安装的教程说每个节点需要300G，但是我的硬盘没有这么大，所以我想知道最小安装需要多少空间，每个文件夹存储空间分配。这只是我的测试集群，只用于开发，测试数据可能500M都没有。

HCS810 MapReduce服务扩容DN节点/srv/BigData/hadoop/data2目录后，发现数据不是分布存放到不同目录，而像是同时下发