您好，Kafka并没有奇数个部署的要求，Zookeeper有。客户提到的资源浪费及选举的问题是Zookeeper的业务场景。Zookeeper主要用于做分布式协调锁，内部依赖的是ZAB协议。ZAB协议简单理解为在执行选举或写操作时，需要得到半数以上（不是半数及以上，必须大于1半）的返回才算成功。基于此协议，如果部署3个节点，那么每次请求（选举、写操作）需要2个节点返回即可，最大容灾能力为1个节点（3节点Zookeeper最多可宕机1个节点仍可提供服务），而4个节点Zookeeper集群需要3个节点返回成功才可，因此4节点Zookeeper集群最大容灾能力也是1节点，在考虑到多节点 节点间的网络通信开销，ZooKeeper奇数个部署的性能要优于偶数个。Kafka的选举对ZooKeeper有依赖（锁机制），但kafka并不需要和ZooKeeper部署在一起，kafka的部署有自己单独的业务规划条件。

您好，全部的FI各部件部署规划及调优可参考FusionInsight对应版本的性能调优指导手册及服务组件规划指导，最新版本性能调优手册获取路径 ：https://support.huawei.com/enterprise/zh/cloud-computing/mapreduce-service-pid-22396131针对您的问题，简单回答如下：1 HDFS Namenode GC参数：文件系统对象 和 堆内存之间的对应呈线性关系比例。可以简单通过10,000,000 文件系统对象对应6G 堆内存，Newsize 设置为堆内存的1/12 的策略进行处理。文件数量(1文件对应1block)文件系统对象数量（filesystem objects=files+blocks）参考值5,000,00010,000,000-Xms6G -Xmx6G -XX:NewSize=512M -XX:MaxNewSize=512M10,000,00020,000,000-Xms12G -Xmx12G -XX:NewSize=1G -XX:MaxNewSize=1G25,000,00050,000,000-Xms32G -Xmx32G -XX:NewSize=3G -XX:MaxNewSize=3G50,000,000100,000,000-Xms64G -Xmx64G -XX:NewSize=6G -XX:MaxNewSize=6G100,000,000200,000,000-Xms96G -Xmx96G -XX:NewSize=9G -XX:MaxNewSize=9G150,000,000300,000,000-Xms164G -Xmx164G -XX:NewSize=12G -XX:MaxNewSize=12G2 HDFS DataNode GC参数：DataNode内存占用和文件的关系为：内存=块个数 * 1K。建议配置实际内存为2~3倍左右。每个DataNode副本数量参考值2,000,000-Xms6G -Xmx6G -XX:NewSize=512M -XX:MaxNewSize=512M5,000,000-Xms12G -Xmx12G -XX:NewSize=1G -XX:MaxNewSize=1G3 MetaStore内存：按照经验，每25个节点，给MetaStore规划2GB的内存，MetaStore内存=节点数/25*2GB，默认是2GB，建议不要小于2G，500节点建议配置500/25*2=50GB4 Spark2x GC：服务端Jobhistory GC配法：历史任务数10000和Jobhistory内存的对应关系：-Xms30G -Xmx30G -XX:NewSize=1G -XX:MaxNewSize=2GYarn上资源配法：如下两个参数需按需调整，建议调整为整个节点资源的75%~90%yarn.nodemanager.resource.cpu-vcoresyarn.nodemanager.resource.memory-mb    客户端任务配法：针对数据量，shuffle数据量等计算逻辑，调整driver及executor内存及cpu。

学习了，点赞！