Cloudera官方文档整理

要评估集群的硬件和资源分配，需要分析要在集群上运行的工作负载类型，以及将用于运行这些工作负载的CDH组件。您还应该考虑要存储和处理的数据的大小、工作负载的频率、需要运行的并发作业的数量以及应用程序所需的速度。
在创建集群的体系结构时，需要在集群中的主机之间分配Cloudera Manager和CDH角色，以最大限度地利用资源。Cloudera提供了一些关于如何将角色分配给集群主机的指南。请参阅建议的群集主机和角色分布。将多个角色分配给主机时，将主机上每个角色的总资源需求（内存、CPU、磁盘）相加，以确定所需的硬件。
有关工作负载如何影响大小决定的信息，请参阅以下博客文章：如何：为新的Hadoop集群选择正确的硬件。
注意：所有关于核数量的建议都是指逻辑核，而不是物理核。

HDFS硬件要求：
NameNode堆内存：为每个额外的1000000块，快照和加密添加额外的1 GB可以增加所需的堆内存。
DataNode堆内存：增加内存以获得更高的副本计数或每个数据节点更高的块数。当增加内存时，Cloudera建议在数据节点上每100万个副本（超过400万个）增加1 GB的内存。例如，500万个副本需要5 GB的内存。最大可接受大小取决于平均块大小的大小。DN的可伸缩性限制主要是每个DN的副本数的函数，而不是存储的总字节数。也就是说，如果机器或机架发生故障，拥有超密集的DNs将影响恢复时间。Cloudera不支持每个数据节点超过100 TB。您可以使用12 x 8 TB主轴或24 x 4TB主轴。Cloudera不支持大于8 TB的驱动器。
警告：在直接连接的物理磁盘以外的存储平台上运行CDH可能会提供次优性能。Cloudera Enterprise和大多数Hadoop平台都经过优化，通过将工作分布到可以利用数据本地性和快速本地I/O的集群上来提供高性能。有关使用非本地存储的更多信息，请参阅Cloudera Enterprise存储设备接受标准指南。

调整NameNode堆内存大小：
每个工作负载都有一个唯一的字节分布配置文件。一些工作负载可以使用默认的JVM设置来收集堆内存和垃圾，但其他工作负载则需要调整。如果动态堆设置导致瓶颈，本主题将提供有关调整NameNode JVM大小的指导。
所有Hadoop进程都在Java虚拟机（JVM）上运行。JVM的数量取决于您的部署模式：
1.本地（或独立）模式-没有守护进程，所有内容都在一个JVM上运行。
2.伪分布式模式-每个守护进程（例如NameNode守护进程）在单个主机上运行在自己的JVM上。
3.分布式模式-每个守护进程在其自己的JVM上跨主机集群运行。
遗留NameNode配置是一个活动（和主）NameNode（用于整个命名空间）和一个辅助NameNode（用于检查点）（但不用于故障转移）。建议的高可用性配置将辅助NameNode替换为可防止单点故障的备用NameNode。每个NameNode都使用自己的JVM。

HADOOP_heap size为所有HADOOP项目服务器（如HDFS、YARN和MapReduce）设置JVM堆大小。HADOOP_HEAPSIZE是作为最大内存（Xmx）参数传递给JVM的整数。例如：
HADOOP_HEAPSIZE=1024
HADOOP_NAMENODE_OPTS特定于NAMENODE并设置所有必须指定的JVM标志。HADOOP_NAMENODE_OPTS覆盖NAMENODE的HADOOP_HEAPSIZE Xmx值。例如：
HADOOP_NAMENODE_OPTS=-Xms1024m-Xmx1024m-XX:+UseParNewGC-XX:+UseConcMarkSweepGC-XX:cmsinitiatiatingocultincyfraction=70-XX:+CMSParallelRemarkEnabled-XX:+PrintTenuringDistribution-XX:OnOutOfMemoryError={ {AGENT_COMMON_DIR}}/killparent.sh
HADOOP_NAMENODE_OPTS和HADOOP_HEAPSIZE都存储在/etc/HADOOP/conf/HADOOP-env.sh中。

监视堆内存使用情况:
您可以通过多种方式监视堆内存使用情况：
1.Cloudera Manager：查看NameNode图表以了解堆内存使用情况。如果需要从头开始构建图表，请运行：
select jvm_max_memory_mb，jvm_heap_used_mb where roleType=“NameNode”
2.NameNode Web UI：向下滚动到摘要并查找“Heap Memory used”
3.命令行：生成堆转储。

文件和块:
在HDFS中，数据和元数据是分离的。数据文件被分割成块文件，这些块文件存储在集群中的数据节点上并进行复制。文件系统命名空间树和相关的元数据存储在NameNode上。
命名空间对象是指向数据节点上的块文件的文件索引节点和块。这些命名空间对象作为文件系统映像（fsimage）存储在NameNode的内存中，并在本地持久化。元数据的更新将写入编辑日志。当NameNode启动或执行检查点时，将应用编辑，清除日志，并创建新的fsimage。

重要提示：NameNode将整个名称空间映像保存在内存中。在自己的JVM上，Secondary NameNode在创建映像检查点时也会这样做。
平均而言，每个文件占用1.5个存储块。也就是说，平均文件被分成两个块文件，一个占用分配的整个块大小，另一个占用一半大小。在NameNode上，这个相同的平均文件需要三个命名空间对象-----即一个文件inode和两个块。

磁盘空间与命名空间：
CDH默认块大小（dfs.block size）设置为128 MB。NameNode上的每个名称空间对象大约占用150个字节。
在数据节点上，数据文件是根据实际数据长度消耗的磁盘空间来测量的，而不一定是整个块大小。例如，192 MB的文件占用192 MB的磁盘空间，而不是块大小的整数倍。使用默认的128 MB块大小，将192 MB的文件拆分为两个块文件，一个128 MB文件和一个64 MB文件。在NameNode上，命名空间对象是通过文件和块的数量来度量的。同一个192MB的文件由三个命名空间对象（1个文件inode+2个块）表示，并占用大约450字节的内存。
与生成多个块的小文件相比，分割成较少块的大文件通常消耗更少的内存。一个128MB的数据文件由NameNode上的两个名称空间对象（1个文件inode+1个块）表示，并占用大约300字节的内存。相比之下，128个1 MB的文件由256个命名空间对象（128个文件索引节点+128个块）表示，大约占用38400字节。因此，对于内存管理和数据局部性优化，最佳分割大小是块大小的整数倍。
默认情况下，Cloudera管理器为每100万个块分配的最大堆空间为1gb（但决不能小于1gb）。实际需要多少内存取决于工作负载，特别是每个命名空间中生成的文件、目录和块的数量。如果所有文件都按块大小分割，则可以为每百万个文件分配1 GB。但考虑到每个文件1.5个块（2个块对象）的历史平均值，更保守的估计是每一百万个块有1 GB的内存。

重要提示：Cloudera建议每百万个块中有1gb的NameNode堆空间，以考虑命名空间对象、必要的记帐数据结构和远程过程调用（RPC）工作负载。实际上，堆需求可能小于这个保守的估计。

复制
默认的块复制因子（dfs.replication）是3。复制影响磁盘空间，但不影响内存消耗。复制更改每个块所需的存储量，但不更改块的数量。如果DataNode上的一个块文件（由NameNode上的一个块表示）被复制三次，则块文件的数量将增加三倍，而不是表示它们的块的数量。
关闭复制后，一个192 MB的文件将占用192 MB的磁盘空间和大约450字节的内存。如果您有一百万个这样的文件，或者192 TB的数据，那么您需要192 TB的磁盘空间，并且在不考虑RPC工作负载的情况下，需要450 MB的内存：（100万个索引节点+200万个块）*150字节。打开默认复制后，需要576 TB的磁盘空间：（192 TB*3），但内存使用量保持不变，为450 MB。当您考虑记帐和rpc，并遵循每一百万个块1 GB堆内存的建议时，对于这种情况，更安全的估计是2 GB内存（有或没有复制）。

实例
示例1：估计使用的NameNode堆内存
Alice、Bob和Carl每个磁盘上都有1gb（1024mb）的数据，但是它们被分成不同大小的文件。Alice和Bob的文件是块大小的积分，需要的内存最少。Carl没有，而是用不必要的命名空间对象填充堆。
Alice: 1 x 1024 MB file
1 file inode
8 blocks (1024 MB / 128 MB)
Total = 9 objects * 150 bytes = 1,350 bytes of heap memory
Bob: 8 x 128 MB files
8 file inodes
8 blocks
Total = 16 objects * 150 bytes = 2,400 bytes of heap memory
Carl: 1,024 x 1 MB files
1,024 file inodes
1,024 blocks
Total = 2,048 objects * 150 bytes = 307,200 bytes of heap memory

示例2：估计所需的NameNode堆内存
在本例中，通过考虑集群的容量来估计内存。值是四舍五入的。两个群集都物理存储4800 TB或大约3600万个块文件（默认块大小）。复制确定有多少命名空间块表示这些块文件。
集群A:200个主机，每个24 TB=4800 TB。
块大小=128 MB，复制=1
群集容量（MB）：200*24000000 MB=480000000 MB（4800 TB）
每个块所需的磁盘空间：每个块128 MB*1=每个块128 MB存储空间
以块为单位的群集容量：480000000 MB/128 MB=36000000块
在容量方面，建议每百万块分配1 GB内存，群集A需要36 GB的最大堆空间。
集群B:200个主机，每个24 TB=4800 TB。
块大小=128 MB，复制=3
群集容量（MB）：200*24000000 MB=480000000 MB（4800 TB）
每个块所需的磁盘空间：每个块128 MB*每个块3=384 MB存储空间
以块为单位的群集容量：480000000 MB/384 MB=12000000个块
在容量上，建议每百万块分配1 GB内存，集群B需要12 GB的最大堆空间。
群集A和群集B都存储相同数量的块文件。但是，在集群A中，每个块文件都是唯一的，并由NameNode上的一个块表示；在集群B中，只有三分之一是唯一的，三分之二是副本。

备份和还原NameNode元数据：
本主题介绍备份和还原NameNode元数据的步骤。
1.备份NameNode元数据
2.还原NameNode元数据

1.备份NameNode元数据
本节介绍如何备份NameNode元数据。
对版本文件进行一次备份。这不需要定期备份，因为它不会改变，但它很重要，因为它包含clusterID和其他细节。
使用以下命令备份NameNode元数据。它自动确定活动的NameNode，检索当前fsimage，并将其放置在定义的backup目录中。
hdfs dfsadmin -fetchImage backup_dir   
启动时，NameNode进程读取fsimage文件并将其提交到内存。如果JournalNodes已启动并正在运行，并且存在编辑文件，则也会应用比fsimage更新的任何编辑。如果JournalNodes不可用，则可能会丢失在此期间传输的任何数据。
2.还原NameNode元数据
本节介绍如何还原NameNode元数据。如果NameNode和secondary NameNode都突然脱机，则可以通过执行以下操作还原NameNode：
1）将新主机添加到Hadoop群集。
2）将NameNode角色添加到主机。确保它与原始NameNode具有相同的主机名。
3）为NameNode name.dir创建目录路径（例如/dfs/nn/current），确保权限设置正确。
4）将版本文件和最新的fsimage文件复制到/dfs/nn/current目录。
5）运行以下命令为fsimage创建md5文件。
md5sum fsimage > fsimage.md5
6）启动NameNode进程。

oozie堆内存设置建议：
最小：1 GB（这是Cloudera Manager设置的默认值）。这足以满足少于10个同时进行的工作流，而不需要分叉。
如果注意到垃圾收集过多或内存不足错误，请将堆大小增加到4 GB（对于中型生产群集）或8 GB（对于大型生产群集）。
附加调优：
对于使用许多协调器运行的复杂工作流的工作负载（达到最大并发性！警告出现在日志中，oozie admin -queuedump命令显示一个大队列）：
将oozie.service.CallableQueueService.callable.concurrency属性的值增加到50。
将oozie.service.CallableQueueService.threads属性的值增加到200。
不要将Derby数据库用作Oozie的后端数据库。

yarn硬件要求：
1.Job History Server
堆内存：最小：1 GB；对于保存在内存中的每100000个任务，将内存增加1.6 GB。例如：
5个作业@100, 000 mappers + 20,000 reducers=600000需要9.6GB堆的总任务。有关其他调整建议，请参阅“其他建议”列。
CPU：Minimum: 1 core
其他推荐：将mapreduce.jobhistory.jhist.format属性设置为binary（使用此设置，历史文件加载速度将提高大约2-3倍）。仅适用于CDH 5.5.0或更高版本。
将mapreduce.jobhistory.loadedtasks.cache.size属性设置为总加载任务计数。使用左侧Java Heap列中的示例（总共650000个任务），可以将其设置为700000，以留出一些安全空间。这还应防止JobHistoryServer在垃圾收集期间挂起，因为作业计数限制没有任务限制。

2.NodeManager
堆内存：最小：1 GB。
为下列情况配置附加堆内存：
大量容器
Spark或MapReduce中的大型shxmluffle
CPU：最少：8-16核，推荐：32-64核
其他推荐：
磁盘：
最少：8个磁盘
推荐：12个或更多磁盘
网络：
最低：双1Gbps或更快
推荐：单/双10 Gbps或更快s

3.ResourceManager
堆内存：最小：6 GB
为下列情况配置附加堆内存：
更多的jobs
较大的群集大小
保留的已完成应用程序数（使用yarn.resourcemanager.max-completed-applications属性配置）。
调度程序配置
CPU：Minimum: 1 core

4.其他设置
Set the ApplicationMaster Memory YARN configuration property to 512 MB
Set the Container Memory Minimum YARN configuration property to 1 GB.

Cloudera Enterprise 6.0.x支持的操作系统：RHEL/CentOS/OL with RHCK kernel
7.6, 7.5, 7.4, 7.3, 7.2
6.10, 6.9 , 6.8

文件系统要求
支持的文件系统
Hadoop分布式文件系统（HDFS）设计为在操作系统中的底层文件系统上运行。Cloudera建议您使用在受支持的操作系统上测试的以下任一文件系统：
ext3：这是对HDFS测试最多的底层文件系统。
ext4：这个ext3的可伸缩扩展在更新的Linux版本中受支持。
重要提示：Cloudera不支持从ext3到ext4的就地升级。Cloudera建议在将磁盘用作数据目录之前将其格式化为ext4。
XFS：这是RHEL 7中的默认文件系统。
S3:亚马逊简单存储服务

文件访问时间
Linux文件系统保存元数据，记录访问每个文件的时间。这意味着即使读取也会导致对磁盘的写入。为了加快文件读取速度，Cloudera建议您使用/etc/fstab中的noatime mount选项禁用此名为atime的选项：
/dev/sdb1 /data1 ext4 defaults,noatime 0
在不重新启动的情况下应用更改：
mount -o remount /data1

文件系统装载选项
filesystem mount选项有一个sync选项，允许您同步写入。
使用sync filesystem mount选项会降低将数据写入磁盘的服务（如HDFS、YARN、Kafka和Kudu）的性能。在CDH中，大多数写操作已经被复制。因此，同步写入磁盘是不必要的、昂贵的，并且无法显著提高稳定性。
不支持将NFS和NAS选项用作DataNode数据目录装载，即使使用分层存储功能也是如此。

nproc配置
Cloudera Manager会在/etc/security/limits.conf中自动设置nproc配置，但是这个配置可以被/etc/security/limits.d/中的单个文件覆盖。这可能会导致Apache Impala和其他组件出现问题。
确保nproc限制设置得足够高，例如65536或262144。