CDH6官方文档中文系列(1)---适用于裸机部署的Cloudera Enterprise参考架构

适用于裸机部署的Cloudera Enterprise参考架构

最近在学习cdh6的官方文档，网上也比较难找到中文的文档。
其实官方英文文档的阅读难度其实并不是很高，所以在这里在学习官方文档的过程中，把它翻译成中文，在翻译的过程中加深学习了解，并分享出来和大家一起学习。
中文内容是本人的渣渣英文水平结合有道词典，谷歌翻译的结果，文中部分词语可能翻译的并不准确，希望大家多多提出意见，共同进步。
cdh6的官方中文文档系列长期更新，最后目标整理成gitbook，同大家交流学习。
最后，如果你觉得本文对你有用，希望点个赞给作者一点鼓励哈。

与其感慨路难行不如马上上路，诸位道友，共同学习，加油！-------天南第一剑修

官方文档

概要

一个组织对大数据解决方案的要求很简单:在同一个平台保证数据的有效原始性获取和组合任意数量或类型的数据，只要有必要，以最快的速度向所有用户提供技术支持。

Cloudera，一家企业数据管理公司，介绍了企业数据中心(EDH)的概念:一个存储和处理所有数据的中央系统。EDH具有灵活性，可以运行各种企业工作负载(例如，批处理、交互式SQL、企业搜索和高级分析)，同时满足企业需求，如与现有系统的集成、健壮的安全性、治理、数据保护和管理。EDH是新兴的企业数据管理中心。EDH构建于Cloudera Enterprise之上，后者由包括Apache Hadoop (CDH)在内的开源Cloudera发行版组成，后者是一套管理软件和企业级支持。

当组织接受hadoop支持的大数据部署时，它们也需要企业级的安全性、管理工具和技术支持——所有这些都是Cloudera企业版的一部分。

Cloudera参考架构文档举例说明了集群配置和认证的合作伙伴产品。RAs并不是官方支持声明的替代品，相反，它们是辅助部署和分级选项的指南。有关RA中受支持的配置的语句是信息性的，应该与最新的文档进行交叉引用。

本文档是在物理机器部署Cloudera企业的高级设计和最佳实践指南。

基础设施

系统架构最佳实践

本节描述Cloudera的建议和适用于Hadoop集群系统架构的最佳实践。

Java

Cloudera Manager和CDH被证明可以在Oracle JDK上运行。OpenJDK也支Cloudera Manager和CDH 5.16及更高版本5.x版本。有关更多信息，请参见升级JDK。

Cloudera通过Cloudera管理器库发布了一个兼容的Oracle JDK版本。客户也可以免费安装由Oracle发布的兼容版本的Oracle JDK。

请参考CDH和Cloudera Manager支持的JDK版本列表。

最佳服务器配置

Cloudera建议在生产中部署三到四种机器类型:

• 主节点。运行Hadoop主守护进程:NameNode、备用NameNode、Yarn资源管理器和History服务器、HBase主守护进程、Sentry服务器和Impala状态存储服务器和目录服务器。主节点也是Zookeeper和JournalNodes安装的位置。守护进程通常可以共享一个服务器池。根据集群的大小，可以在专用服务器上运行每个角色。Kudu主服务器也应该部署在主节点上。
• 工作节点。运行HDFS DataNode、YARN NodeManager、HBase RegionServer、Impala impalad、Search worker守护进程和Kudu Tablet服务。
• 实施节点。运行Cloudera Manager和Cloudera Management Services。
  它还可以托管一个MySQL(或其他受支持的)数据库实例，Cloudera Manager、Hive、Sentry和其他hadoop相关的项目都使用这个数据库实例。
• 边缘节点。包含所有面向客户端的配置和服务，包括用于HDFS、YARN、Impala、Hive和HBase的网关配置。边缘节点也是Hue、Oozie、HiveServer2和Impala HAProxy的好位置。HiveServer2和Impala 的HAProxy作为外部应用程序(如商业智能(BI)工具)的网关。

有关更多信息，请参考推荐的集群主机和角色分布

注意:边缘节点和实用节点可以在更小的集群中组合

部署拓扑图

下图描述了部署在几个机架(机架1、机架2、……机架n)上的集群。

每个主机与两个机架顶部(TOR)交换机联网，这些交换机依次连接到一个脊柱交换机集合，然后连接到企业网络。这种部署模型允许每个主机最大吞吐量和最小延迟，同时鼓励可伸缩性。网络拓扑的细节将在后续的设置中描述。

物理组件列表

下表描述了推荐部署EDH集群的物理组件。

组件	配置	描述	数量
Physical servers	双槽、8-14核每槽 大于2GHZ 最小128G内存	容纳各种集群组件的主机。	基于集群设计
NICs	10 Gbps以太网网卡优先。	为集群提供数据网络服务。	每个服务器至少有一个，不过可以绑定两个NICs以获得额外的吞吐量。
Internal HDDs	操作系统和日志推荐使用500gbHDD或SSD;数据磁盘使用HDD(大小随数据量需求而变化)	这确保了服务器重置和包含集群数据的服务的连续性。	每个物理服务器有6-24个磁盘。
Ethernet ToR/leaf switches	最少10 Gbps的交换机具有足够的端口密度来容纳集群。这些需要足够的端口来创建一个真实的spine-leaf拓扑，提供大于1:4的ISL带宽(最好是1:1)。	尽管大多数企业都有成熟的数据网络实践，但是考虑为Hadoop集群构建专用的数据网络。	每个机架至少两个。
Ethernet spine switches	最少10 Gbps的交换机具有足够的端口密度，以适应传入的ISL链接，并确保通过脊柱所需的吞吐量(用于机架间通信)	与ToR开关相同的注意事项。	取决于机架的数量。

网络说明

专用网络硬件

Hadoop可以消耗所有可用的网络带宽。由于这个原因，Cloudera建议将Hadoop放置在一个单独的物理网络中，使用自己的核心交换机。

开关每个机架

Hadoop支持机架局部性的概念，并利用网络拓扑最小化网络拥塞。理想情况下，一个机架中的节点应该连接到单个物理开关。两个顶部机架(TOR)开关可用于高可用性。每个机架开关(即TOR开关)连接到一个具有更大背板的核心开关。Cloudera建议在服务器和TOR交换机之间建立10 GbE(或更快)连接。TOR到核心交换机(在一个HA配置中有两个交换机)的上行带宽常常会在某种程度上被超额使用。

上行的过载

多大的过载是合适的取决于工作负载。Cloudera的建议是，总访问端口带宽和上行带宽之间的比例应尽可能接近1:1。这对于沉重的ETL工作负载和向reducers发送大量数据的MapReduce作业尤其重要。

对于平衡的工作负载来说，高达4:1的过载通常是可以接受的，但是需要网络监控来确保上行带宽不是Hadoop的瓶颈。下表提供了一些例子作为参考:

接入端口带宽(使用中)	上行端口带宽(绑定)	比率
48 x 1 GbE = 48 Gbit/s	4 x 10 GbE = 40 Gbit/s	1.2:1
24 x 10 GbE = 240 Gbit/s	2 x 40 Gig CFP = 80 Gbit/s	3:1
48 x 10 GbE = 480 Gbit/s	4 x 40 Gig CFP = 160 Gbit/s	3:1

重要的是:

超额认购比例不超过4:1。例如，如果TOR使用20 x 10 GbE端口，那么上行链路至少应该是50 Gbps。不同的交换机有特定带宽的专用上行端口(通常为40 Gbps或100 Gbps)，因此需要进行仔细的规划，以选择正确的开关类型。

冗余网络交换机

在完全网格配置中拥有冗余的核心交换机将允许集群在核心交换机故障时继续运行。冗余的TOR开关将防止整个机架的处理和存储能力的损失，在TOR开关故障的情况下。在机架丢失的情况下，只要主节点分布在多个机架上，仍然可以维护一般的集群可用性。

可访问性

Cloudera企业集群的可访问性由网络配置定义，并取决于安全需求和工作负载。通常，有直接访问集群的边缘/客户端节点。用户通过客户端应用程序访问这些边缘节点，与集群和驻留在其中的数据进行交互。这些边缘节点可以运行一个web应用程序，用于实时处理工作负载、BI工具，或者只是用于提交或与HDFS交互的Hadoop命令行客户机。

Cloudera建议只允许通过边缘节点访问Cloudera企业集群。可以在提供的主机的安全组中配置此配置。本文档的其余部分详细描述了各种选项。

互联网连接

不需要在Internet之间或直接网络之外的服务之间进行大量数据传输的集群和HDFS仍然可能需要访问诸如用于更新的软件存储库或其他低容量外部数据源等服务。

如果完全断开集群与Internet的连接，就会阻塞对软件更新的访问，从而增加维护的难度。

集群管理

Cloudera强烈建议使用Cloudera Manager (CM)安装CDH。在通过CM安装CDH的过程中，可以选择使用包或本地包进行安装。包裹是二进制的分发格式。包裹提供了许多好处，包括一致性、灵活的安装位置、不需要sudo的安装、减少升级停机时间、滚动升级和容易降级。Cloudera建议使用包裹，但也支持使用包。

集群Sizing最佳实践

(对于Sizing这个词，总是找不到合适的翻译，希望道友可以提点建议)

每个工作节点通常有几个物理磁盘，用于Hadoop的原始存储。这个数字将用于计算每个集群的可用存储总量。此外，下面列出的计算假定为YARN临时存储分配了10%的磁盘空间。Cloudera建议将10-25%的原始磁盘空间分配给临时存储，这是一个通用的指导原则。这可以在Cloudera Manager中更改，并且应该在分析生产工作负载之后进行调整。例如，向reducers发送少量数据的MapReduce作业允许将这个数字百分比向下调整

下表包含包含17个工作节点的集群的示例计算。每个服务器有12个3 TB的驱动器可供Hadoop使用。下表列出了基于工作节点数量的可用Hadoop存储:

默认的复制因子

Raw Storage	612 TB
HDFS存储(可配置)	550.8 TB
HDFS唯一存储(默认复制因子)	183.6 TB
MapReduce中间存储(可配置)	61.2 TB

纠删码 RS-6-3

Raw Storage	612 TB
HDFS存储(可配置)	550.8 TB
HDFS唯一存储(EC RS-6-3 – 1.5x overhead)	367.2 TB
MapReduce中间存储(可配置)	61.2 TB

纠删码 RS-10-4

Raw Storage	612 TB
HDFS存储(可配置)	550.8 TB
HDFS唯一存储(EC RS-10-4 – 1.4x overhead)	393.4 TB
MapReduce中间存储(可配置)	61.2 TB

注意:

HDFS惟一存储将根据存储在EC目录中的数据量和选择的RS策略而有所不同。上面的表只是不同策略如何影响HDFS惟一存储的示例。

压缩原始数据可以有效地增加HDFS的存储容量。

虽然Cloudera Manager提供了一些工具，比如利用Linux Cgroups的静态资源池，允许多个组件共享硬件，但是在大容量生产集群中，为Solr、HBase和Kafka等角色分配专用主机是有益的。

集群硬件选择最佳实践

本节将对不同的硬件组件选择将如何影响Hadoop集群的性能进行概述。

有关具体工作负载的详细实践，请参阅硬件需求指南。

磁盘的数量

传统上，Hadoop被认为是一个大型I/O平台。虽然有许多新的工作负载在Cloudera集群上运行，它们可能不像传统的MapReduce应用程序那样受I/O限制，但在架构Cloudera集群时考虑I/O性能仍然很有用。

与CPU的核心数量和RAM的密度不同，从一个机械磁盘(主轴)读取数据的速度在过去10年没有太大的变化。为了应对硬盘读写操作的有限性能，Hadoop并行地从多个硬盘进行读写操作。每个节点每增加一个额外的主轴，都会提高集群的总体读/写速度。

注意:SSD已经极大地改变了持久存储性能的前景，但是每GB机械磁盘的价格仍然明显低于SSD存储。随着ssd成本的下降以及诸如Intel的Optane™之类的技术进入市场，工作负载可能会重新回到CPU限制的状态。大多数Cloudera客户仍在部署将数据存储在旋转硬盘上的集群。

额外的主轴还可能带来集群中更多的网络流量。在大多数情况下，节点之间的网络流量通常受到写入或从节点读取数据的速度的限制。因此，通常遵循的规律是，随着主轴数的增加，对网络速度的要求也随之提高。

一般来说，一个节点的主轴数越多，每TB的成本就越低。但是，一个节点上存储的数据量越大，如果该节点宕机，重新复制的时间就越长。Hadoop集群被设计成具有多个节点。一般来说，拥有更多的平均节点比拥有更少的超级节点要好。这与数据保护以及增加MapReduce和Spark等分布式计算引擎的并行性有很大关系。

如果CDH集群利写不利读，可以选择大磁盘少节点方案，充分发挥hdfs的存储优势。

如果CDH集群用来分析使用，选择小磁盘多节点方案。大磁盘少节点的方案在磁盘发生故障时需要更多的数据恢复时间，不适于分析集群使用

最后，每个节点的驱动器数量将影响为节点配置的YARN容器的数量。YARN配置和性能调优是一个复杂的主题，但对于I/O限制的应用程序，每个主机的物理驱动器数量可能是决定每个节点配置的容器槽数量的限制因素。

Kafka集群通常在专用服务器上运行，这些服务器不运行HDFS数据节点或处理组件(如YARN和Impala)。因为Kafka是一个基于消息的系统，所以快速存储和网络I/O对性能至关重要。尽管Kafka确实将消息持久化到磁盘，但通常不需要将Kafka主题日志的全部内容无限期地存储在Kafka集群上。Kafka代理应该为日志数据目录配置专用的旋转硬盘。使用ssd而不是旋转磁盘并没有显示出可以为Kafka提供显著的性能改进。

Kafka驱动器还应该配置为RAID 10，因为Kafka节点上的单个驱动器的丢失将导致节点中断。

磁盘布局

对于**主节点**，建议采用以下布局:

• 2个磁盘(容量至少500GB)*[RAID 1]*用于操作系统和日志
• 4个磁盘(每个>= 1TB)*[RAID 10]*用于数据库数据(参见注释)
• 2 x磁盘(容量至少为1tb)*[RAID 1]*为NameNode元数据提供
• 1 x 磁盘(>= 1TB)[JBOD/RAID 0] for ZooKeeper (见注释)
  • Zookeeper的磁盘必须是HDD，而不是SSD
• 1 x 磁盘 (>= 1TB)*[JBOD/RAID 0]*for Quorum JournalNode

注意:
理想情况下，数据库应该在外部主机上运行，而不是在主节点上运行。

如果客户遇到了fsync延迟和ZooKeeper的其他I/O相关问题，可以将ZooKeeper的dataDir和dataLogDir配置为使用单独的磁盘。很难提前确定这是否有必要;即使是一个很小的集群也会导致大量的Zookeeper活动。

对于**工作节点**，建议采用以下布局:

• 2块在RAID 1(软件或硬件)中磁盘(容量至少500GB)用于操作系统与日志
• 15-24个JBOD模式(如果使用RAID控制器无法进行JBOD透传，则记录为多个单驱动器RAID 0阵列)的SATA磁盘，容量不大于4tb。如果RAID控制器有缓存，使用它写缓存(最好与电池备份);禁用缓存读取。尽可能遵循硬件供应商的最佳实践。
• 要获得更高的性能配置文件，请使用10K RPM SATA或更快的SAS驱动器;
  这些通常具有较低的容量，但是可以通过添加更多的数据节点来抵消容量方面的考虑。

支持SAS磁盘，但通常不能提供足够显著的性能或可靠性好处，以证明额外的成本是合理的。Hadoop被设计成容错的，因此驱动失败很容易被容忍。为了获得一个好的价格点，通常应该使用SATA磁盘。

RAID控制器应该配置为禁用RAID 0数组的任何优化设置。

磁盘的数据密度

今天的硬盘有很多种尺寸。流行的磁盘大小是1-4 TB，尽管更大的磁盘正变得越来越普遍。在选择磁盘大小时，需要考虑以下几点。

• Lower Cost Per TB --一般来说，磁盘越大，每TB的成本就越低，这就降低了TCO。
• 复制风暴–更大的磁盘意味着磁盘故障将产生更大的重新复制风暴，这可能需要更长的时间和网络饱和，同时影响正在运行的工作负载。
• 集群性能–一般来说，驱动大小对集群性能影响不大。例外情况是，当磁盘具有不同的读/写速度时，一种使用情况会凸显这种劣势。MapReduce是为长时间的顺序读写设计的，所以延迟时间通常不那么重要。HBase可能从更快的磁盘中获益，但这取决于各种因素，如HBase访问模式和模式设计;这也意味着需要获取更多的节点。Impala和Cloudera search工作负载也可能受益于更快的磁盘，但对于这些应用程序来说，理想的架构是在内存中维护尽可能多的数据。

Cloudera不支持每个数据节点超过100 TB。你可以使用12x8tb的磁盘或者24x4tb的磁盘。Cloudera不支持大于8tb的驱动器。

**注意:**较大的磁盘提供了增加的容量，但没有增加I/O。具有更大磁盘的集群很容易导致每个工作节点的容量超过100 TB，这导致了上面提到的复制风暴。具有更大磁盘且达到100tb限制的集群最终拥有更少的主轴，从而降低了HDFS的吞吐量。

**警告:**在直接连接的物理磁盘之外的存储平台上运行CDH可能会提供次优性能。Cloudera企业和大多数Hadoop平台都进行了优化，通过跨集群分布工作来提供高性能，集群可以利用数据局部性和快速本地I/O。有关使用非本地存储的更多信息，请参考Cloudera企业存储设备验收标准指南。

内核数量和多线程

除了成本之外，购买更多更好的CPU并没有负面影响，但是必须仔细评估额外CPU功率的ROI。以下是需要考虑的几点:

• 集群的瓶颈–一般来说，CPU资源(及其缺乏)不会对MapReduce和HBase造成瓶颈。瓶颈几乎总是磁盘和/或网络性能。当然也有例外，比如低效的Hive查询。其他计算框架(如Impala、Spark和Cloudera Search)可能是cpu绑定的，这取决于工作负载。
• 额外的核心/线程–在给定的MapReduce作业中，一个任务通常一次使用一个线程。如前所述，每个节点分配的槽的数量可能是节点中驱动器数量的函数。只要在内核(线程)的数量和驱动器的数量上不存在巨大的差异，就没有必要购买额外的内核。此外，对于典型的作业，MapReduce任务将是I/O绑定的，因此任务使用的给定线程在等待I/O响应时将有大量空闲时间。

重要的是:

为操作系统和其他非hadoop使用分配两个vcpu(尽管如果在集群节点上运行其他非hadoop应用程序，比如第三方活动监视/警报工具，这个数量可能需要更高)。运行的服务越多，需要的vcpu就越多;您将需要使用更有能力的主机来满足这些需求。

对于工作节点，运行在2.4-2.5 GHz的中档12-14核心CPU通常会提供良好的成本/性能折衷。对于主节点，一个具有稍微快一点的时钟速度(例如2.6 GHz)的中档8核CPU就足够了。在可能的情况下，应该启用同步多线程实现(例如Intel的超线程)。CPU和内存的BIOS设置应该设置为最大性能模式或等效模式。

有关具体工作负载的详细实践，请参阅硬件需求指南。

内存

更多的内存总是好的，建议在预算允许的情况下购买尽可能多的内存。Impala和Cloudera Search等应用程序通常配置为使用大量堆，支持这两种服务的混合工作负载集群应该具有足够的RAM，以允许所有必需的服务。

有关具体工作负载的详细实践，请参阅硬件需求指南。

重要的是:
为操作系统和其他非hadoop使用分配至少4 GB内存(尽管如果其他非hadoop应用程序在集群节点上运行，比如第三方活动监视/警报工具，这个数量可能需要更高)。运行的服务越多，需要的内存就越多;您将需要使用更有能力的主机来满足这些需求。

考虑到操作系统和非hadoop进程，分配给所有hadoop相关进程(包括HBase之类的进程)的总内存小于节点上的总内存，这对性能至关重要。过度调度系统上的内存会导致Linux内核的内存不足进程杀手被调用，重要的进程被终止。不必要地向Hadoop进程过度分配内存也会损害性能，因为这会导致Java垃圾收集暂停很长时间。

为了获得最佳性能，应该填充给定cpu上可用的所有内存通道。这可能意味着更大数量的较小调暗，但这意味着内存和CPU都在以最佳性能运行。与您的硬件供应商协商，以定义最佳的内存配置布局。

虽然可以容纳128 GB RAM，但这通常会限制分配给YARN和Impala等服务的内存数量，从而降低集群的查询能力。通常建议使用256gb的值，也可以使用更高的值。

供电

Hadoop软件是围绕节点会失败的预期而设计的。冗余热插拔电源对于工作节点来说不是必需的，但是应该用于主节点、实用节点和边缘节点。

操作系统最佳实践

Cloudera目前支持在多个Linux发行版上运行EDH平台。要从Cloudera获得支持，必须使用受支持的操作系统版本。需求和支持的版本指南列出了Cloudera Manager和CDH的每个版本支持的操作系统。

主机名的命名约定

Cloudera建议使用主机名约定，这样可以方便地识别角色和/或物理连接。这对于在Cloudera管理器中轻松配置机架感知尤为重要。使用项目名称标识符、机架ID、machine类和机器ID，可以很容易地对有关集群的有用信息进行编码。例如:

acme-test-r01m01

这个主机名将代表ACME客户的测试项目，机架#1，主节点#1。

主机名解析

Cloudera建议使用DNS来解析主机名。/etc/hosts的使用很快就变得很麻烦，而且通常是难以诊断问题的根源。/etc/hosts应该只包含127.0.0.1的条目，并且localhost应该是解析到该条目的惟一名称。机器名不能解析为127.0.0.1地址。集群中的所有主机都必须进行正反查找，这样Hadoop才能正常运行。在主机上执行一个简单的测试，以确保正确的DNS解析是执行:

dig <hostname>
dig –x <ip_address_returned_from_hostname_lookup)

For example:

dig themis.apache.org
themis.apache.org.
1758
IN
A
140.211.11.105

dig -x 140.211.11.105
105.11.211.140.in-addr.arpa. 3513 IN

PTR
themis.apache.org.

这是我们应该看到的集群中每个主机的行为。

功能性账户

Cloudera Manager和CDH利用相关守护进程的专用功能帐户。默认情况下，这些帐户是作为本地帐户在集群中的每台机器上创建的，如果它们不存在(本地或来自目录服务，如LDAP)，则需要它们。需求和支持的版本指南包括一个表，显示与每个服务相关联的UNIX用户和组。

注意:Kerberos部署模型(包括与Active Directory的身份集成)在身份验证文档中有详细介绍。

在Cloudera Manager 5.3中，还可以在所有服务共享一个服务帐户的单用户模式下安装集群。此功能是为具有防止使用多个服务帐户的策略需求的客户提供的。
Cloudera不建议使用此功能，除非客户有此要求，因为CDH使用单独的帐户来实适当的安全隔离，因此删除此功能将降低安装的总体安全性。有关单用户模式的其他信息可以在Cloudera安装和升级手册:配置单用户模式中找到。

时间

集群中的所有机器都需要具有相同的时间和日期设置，包括时区。强烈建议使用网络时间协议(NTP)。许多集群服务对时间非常敏感(例如HBase、Kudu、ZooKeeper)，如果所有主机的时间一致，故障排除就会非常容易。执行以下操作将启用NTP守护进程:

(RHEL/CentOS 6) 
service ntpd start 
chkconfig ntpd on 

(RHEL/CentOS 7) 
systemctl start ntpd.service 
systemctl enable ntpd.service

注意:在较新的操作系统上，Chrony可能是首选。

名称服务缓存

建议启用名称服务缓存，特别是对于使用非本地Hadoop功能帐户(如hdfs和yarn用户)的集群。当后者与Kerberos结合使用时，这就变得非常重要。当名称服务查找超时或在高集群利用率期间失败时，可能会出现许多难以诊断的问题。执行以下操作将启用名称服务缓存守护进程(nscd):

(RHEL/CentOS 6)

service nscd start
chkconfig nscd on

(RHEL/CentOS 7)

systemctl start nscd.service
systemctl enable nscd.service

如果您正在运行Red Hat SSSD，则需要修改nscd配置，使其不缓存密码、组或netgroup信息。

SELinux

Cloudera Enterprise(没有Cloudera Navigator)在启用了安全增强的Linux (SELinux)的平台上是受支持的，但是我们建议在Hadoop集群的所有机器上禁用SELinux，直到您启动并运行您的集群。

Linux命令getenforce返回SELinux的状态。

可以通过编辑/etc/sysconfig/ selinux (RHEL/CentOS 6)或/etc/ selinux /config (RHEL/CentOS 7)并设置SELinux =disabled来在RHEL/CentOS上禁用SELinux。此更改必须以root用户身份(或通过适当的sudo访问)完成，并且需要重新启动。

IPv6

Hadoop不支持IPv6。应该删除IPv6配置，停止与IPv6相关的服务。

iptables

Cloudera建议在集群上禁用基于主机的防火墙，至少在集群启动并运行之前是这样。许多难以诊断的问题都是由于不正确/冲突的iptables条目干扰了正常的集群通信造成的。执行以下操作将禁用IPv4和IPv6的iptables:

(RHEL/CentOS 6)

service iptables stop
service ip6tables stop
chkconfig iptables off
chkconfig ip6tables off

(RHEL/CentOS 7)

systemctl stop firewalld.service
systemctl disable firewalld.service

对于那些必须限制使用基于主机的防火墙的访问的人，请参考Cloudera Manager、Cloudera Navigator和CDH 5所使用的端口列表。

启动服务

与任何生产服务器一样，应该删除和/或禁用未使用的服务。CDH不需要的一些默认开启的示例服务有:

• bluetooth
• cups
• iptables
• ip6tables
• postfix

虽然CDH不需要postfix(或其他MTA)，但其他服务可能需要postfix来传递系统生成的通知/警报。

这个清单绝不是详尽无遗的。要查看配置为在系统启动期间启动的服务的列表，请执行以下命令:

(RHEL/CentOS 6)

chkconfig –list | grep on

(RHEL/CentOS 7)

systemctl list-unit-files --type service | grep enabled

进程内存

每个节点上的内存分配给各个Hadoop进程。这种可预测性降低了Hadoop进程无意中耗尽内存并分页到磁盘的可能性，从而导致性能严重下降。有关更多信息，请参见内核和操作系统调优一节。

在操作系统和其他非hadoop使用的节点上，至少应该预留4 GB的内存。如果其他非hadoop应用程序在集群节点上运行，比如第三方活动监视/警报工具，那么这个数量可能需要更高。

Hadoop组件的内存需求和分配将在本文档的其他部分详细讨论。

内核和操作系统调优

Cloudera EDH平台依赖于一个适当调优的底层主机操作系统来获得最佳性能。Cloudera强烈建议设置vm.swappiness和透明的hugepage压缩内核参数。Cloudera管理手册有额外的背景信息和建议设置:在CDH中优化性能。

Entropy

密码操作需要熵来确保随机性。Cloudera安全指南解释了如何检查可用熵，以及如何确保有足够的可用熵:熵需求。

网络参数

集群中每个节点的以太网接口上的收发环缓冲区大小应该进行调整，以确保更高的吞吐率——

运行以下命令检查现有的环形缓冲区大小:

$ ethtool -g eth0
Ring parameters for eth0:
Pre-set maximums:
RX:
4096
RX Mini:  0
RX Jumbo: 0
TX:
4096
Current hardware settings:
RX:
256
RX Mini:  0
RX Jumbo: 0
TX:
256

在检查了预设的最大值和当前硬件设置之后，使用以下命令来调整环形缓冲区的大小:

# ethtool –G  rx 

or

# ethtool –G  tx 

大多数现代的企业级网络适配器都具有一些性能优化特性，例如卸载功能和大分段卸载，这些特性通过在网络接口级别处理这些功能来降低主机CPU上的负载，可以作为性能优化计划的一部分进行探索。在应用标准负载生成器(如Teragen和Terasort性能基准中的Terasuite基准)时，建议使用迭代方法，测试启用特性的效果。性能优化参数不应该不加区别地应用，也不应该没有经过彻底的测试。它们只应基于真正的需要加以应用。

将下列参数添加到/etc/sysctl.conf以优化各种网络行为。

注意:本文档中提供的性能调优指南意味着要以迭代的方式应用，并进行足够的测试。并非所有指定的参数都适用。这些都是通用的最佳实践，但是细节可能会根据所使用的基础设施和应用程序工作负载模式而有所不同。如有疑问，请参阅与您的设备相关的供应商文档。

禁用TCP时间戳以提高CPU利用率(这是一个可选参数，将取决于您的NIC供应商):

net.ipv4.tcp_timestamps=0

启用TCP sack来提高吞吐量:

net.ipv4.tcp_sack=1

增加处理器输入队列的最大长度:

net.core.netdev_max_backlog=250000

使用setsockopt()增加TCP最大和默认缓冲区大小:

net.core.rmem_max=4194304
net.core.wmem_max=4194304
net.core.rmem_default=4194304
net.core_wmem_default=4194304
net.core.optmem_max=4194304

增加内存阈值以防止丢包:

net.ipv4.tcp_rmem=4096 87380 4194304
net.ipv4.tcp_wmem=4096 65536 4194304

注意:如果您想从命令行运行此命令，请将值放在引号中。

例如:
shell sysctl -w net.ipv4.tcp_rmem=”4096 87380 4194304”

启用TCP的低延迟模式:

net.ipv4.tcp_low_latency=1

设置套接字缓冲区在TCP窗口大小和应用程序缓冲区之间均匀分配:

net.ipv4.tcp_adv_win_scale=1

文件系统

在Linux中，有几种格式化和组织驱动器的选择。也就是说，只有少数选择是Hadoop的最佳选择。

在RHEL/CentOS中，逻辑卷管理器(LVM)不应该用于数据驱动器。它不是最优的，并可能导致将多个驱动器组合到一个逻辑磁盘中，这与Hadoop跨HDFS管理容错的方式完全相反。在操作系统驱动器上保持启用LVM是有益的。系统可管理性的改进可以抵消可能出现的任何性能影响。在操作系统驱动器上使用LVM使管理员能够避免在分区上过度分配空间。空间需求可能会随时间变化，动态增长文件系统的能力比重新构建系统要好。不要使用LVM对逻辑卷进行条带或跨多个物理卷来模拟RAID。

Cloudera建议使用基于区段的文件系统。这包括ext3、ext4和xfs。大多数新的Hadoop集群默认使用ext4文件系统。Red Hat Enterprise Linux 7使用xfs作为其默认文件系统。

重要的：
如果使用Kudu，一定要确保文件系统具备Hole Punching能力。Hole Punching是使用fallocate()系统调用与FALLOC_FL_PUNCH_HOLE对象集。新版本的ext4和xfs支持Hole Punching。ext3不支持Hole Punching，6.4之前的未修补的RHEL不支持该设施。不支持Hole Punching的ext4和xfs的旧版本导致Kudu启动失败，因为Kudu为该功能提供了启动前测试。如果没有Hole Punching支持，使用块管理器是不安全的，因为声明的块将永远不会被释放，并且会消耗更多的磁盘空间。

文件系统创建选项

在创建用于Hadoop数据卷的ext4文件系统时，我们建议将root用户块保留从5%减少到1%(使用-m1选项)，并设置以下选项:

• 每1 MB使用一个inode(较大的文件)
• 最小化超级块备份的数量(sparse_super)
• 启用日志记录(has_journal)
• 为目录树使用b-tree索引(dir_index)
• 使用基于区段的分配(区段)

创建这样的ext4文件系统:

mkfs –t ext4 –m 1 –O sparse_super,dir_index,extent,has_journal /dev/sdb1

创建一个像这样的xfs文件系统：

mkfs –t xfs /dev/sdb1

注意:
在创建xfs文件系统时，不需要特殊的选项。

磁盘挂载选项

HDFS本质上是一个容错文件系统。因此，DataNode机器用于数据的所有驱动器都需要在不使用RAID的情况下挂载。此外，应该使用noatime选项将驱动器挂载到/etc/fstab中(这也意味着nodiratime)。如果是SSD或flash，也可以通过在挂载时指定discard 选项来打开TRIM。

在/etc/fstab中，确保适当的文件系统指定了noatime挂载选项:

/dev/sda1 / ext4 noatime 0 0

为了启用TRIM，编辑/etc/fstab并设置挂载选项丢弃。

/dev/sdb1 /data ext4 noatime,discard 0 0

磁盘挂载命名约定

为了便于管理，建议使用命名模式将DataNode机器上的所有磁盘挂载到DataNode机器上，例如:

/data1
/data2
/data3
/data4
/data5
/data6

集群配置

本节包含关于集群如何配置的信息，包括针对所使用的客户硬件的Cloudera建议，以及针对每个Cloudera EDH服务的一些最佳实践和一般建议。本节并不是对每个配置的详尽描述，而是重点介绍重要的配置和那些已从默认设置更改的配置。

Teragen和Terasort性能基准

teragen和terasort基准测试工具是标准Apache Hadoop发行版的一部分，并包含在Cloudera发行版中。在集群安装或认证过程中，Cloudera建议运行几个teragen和terasort作业，以获得集群的性能基准。其目的并不是为了演示硬件的最大性能，也不是为了与外部发布的结果进行比较，因为针对这一点对集群进行调优可能与实际的客户操作工作负载不一致。,而其目的是通过YARN功能测试运行一个真正的工作负载集群以及获得基线数据,可用于未来的比较,如在评估的性能开销启用加密功能或在评估是否运行工作负载是由I / O性能有限的硬件。运行基准测试可以显示集群性能，还可以通过隔离硬件组件(如磁盘和网络)并使其承受高于正常的负载来识别和帮助诊断硬件或软件配置问题。

teragen作业将生成任意数量的数据，格式化为100字节的随机数据记录，并将结果存储在HDFS中。每个记录都有一个随机的键和值。terasort作业将对teragen生成的数据进行排序，并将输出写入HDFS。

在teragen作业的第一次迭代期间，目标是获得磁盘I/O子系统的性能基线。HDFS复制因子应该从默认值3覆盖并设置为1，以便teragen生成的数据不会复制到其他数据节点。通过网络复制数据可能会由于潜在的网络带宽限制而影响原始磁盘性能。

运行第一个teragen作业之后，应该运行第二个迭代，将HDFS复制因子设置为默认值。这将对网络应用高负载，第一次运行和第二次运行之间的增量可以提供集群中网络瓶颈的指示。

虽然teragen应用程序可以生成任意数量的数据，但标准是1tb。对于更大的集群，运行10 TB甚至100 TB可能很有用，因为与YARN作业的启动开销相比，编写1 TB的时间可以忽略不计。应该运行另一个teragen作业来生成一个数据集，该数据集的RAM大小是整个集群的3倍。这将确保我们没有看到页面缓存效果，并真正执行磁盘I/O子系统。

teragen和terasort作业的mappers 数量应该设置为集群中磁盘的最大数量。这可能会小于可用的YARN vcores总数，因此建议暂时将每个YARN工作节点可用的vcore数降低到磁盘主轴数，以确保工作负载的均匀分配。YARN应用程序管理器将需要一个额外的vcore。

terasort作业还应该在HDFS复制因子设置为1和默认复制因子的情况下运行。terasort作业硬编码DFS复制因子1，但是可以通过指mapreduce.terasort.output覆盖或显式设置它。复制参数如下所示。

Teragen和Terasort命令示例

Teragen命令生成1 TB的数据，HDFS复制因子设置为1

EXAMPLES_PATH=/opt/cloudera/parcels/CDH/lib/hadoop-mapreduce

yarn jar ${EXAMPLES_PATH}/hadoop-mapreduce-examples.jar \
  teragen -Ddfs.replication=1 -Dmapreduce.job.maps=360 \
  10000000000 TS_input1

上面的命令使用360个映射器生成1 TB的数据，其中HDFS复制因子为1。这个命令适用于具有360个磁盘的集群。

Teragen命令生成1 TB的数据,HDFS默认复制因子数

EXAMPLES_PATH=/opt/cloudera/parcels/CDH/lib/hadoop-mapreduce

yarn jar ${EXAMPLES_PATH}/hadoop-mapreduce-examples.jar \
  teragen -Dmapreduce.job.maps=360 \
  10000000000 TS_input2

上面的命令使用360个映射器，使用默认的HDFS复制因子(通常为3)生成1 TB的数据。这个命令适用于具有360个磁盘的集群。

Terasort命令对数据进行排序，HDFS复制因子设置为1

EXAMPLES_PATH=/opt/cloudera/parcels/CDH/lib/hadoop-mapreduce

yarn jar ${EXAMPLES_PATH}/hadoop-mapreduce-examples.jar \
  terasort -Dmapreduce.terasort.output.replication=1 \
  -Dmapreduce.job.maps=360 \
  TS_input1 TS_output1

上面的命令使用terasort通过360个mappers 对生成的数据进行排序，并将排序后的输出写入复制因子为1的HDFS。这个命令适用于具有360个磁盘的集群。

Terasort命令对数据进行排序，HDFS复制因子设置为3

EXAMPLES_PATH=/opt/cloudera/parcels/CDH/lib/hadoop-mapreduce

yarn jar ${EXAMPLES_PATH}/hadoop-mapreduce-examples.jar \
  terasort -Dmapreduce.job.maps=360 \
  -Dmapreduce.terasort.output.replication=3 \
  TS_input2 TS_output2

上面的命令使用terasort通过360个mappers 对生成的数据进行排序，并将排序后的输出写入复制因子为3的HDFS。这个命令适用于具有360个磁盘的集群。

Teragen和Terasort结果

Command	HDFS Replication	Number of Mappers	Run Time
Teragen for 1 TB data set	1
Teragen for 3x cluster RAM data set	1
Terasort for 1 TB data set	1
Terasort for 3x cluster RAM data set	1
Teragen for 1 TB data set	3
Teragen for 3x cluster RAM data set	3
Terasort for 1 TB data set	3
Terasort for 3x cluster RAM data set	3

集群配置最佳实践

ZooKeeper

ZooKeeper对磁盘延迟非常敏感。虽然它只使用少量的资源，但是让ZooKeeper交换出或者等待磁盘操作可能会导致ZooKeeper节点被它的quorum节点认为是“死”节点。由于这个原因，Cloudera建议不要在工作节点上部署ZooKeeper，因为工作节点上的负载是不可预测的，并且容易出现峰值。在主节点上部署Zookeeper是可以接受的，因为主节点上的负载更加统一和可预测(或者通常情况下，在任何节点上都可以不受限制地访问磁盘)。

HDFS

Java堆大小

NameNode内存应该随着时间的推移而增加，因为HDFS存储了更多的文件和块。Cloudera管理器可以监视和警告内存使用情况。粗略估计，NameNode需要为每100万个文件提供1 GB的内存。在不需要堆大小的情况下，将堆大小设置得过大会导致低效的Java垃圾收集，从而导致难以诊断的不稳定行为。NameNode和备用NameNode堆大小必须始终相同，因此必须一起调整。

NameNode元数据位置

当使用基于quora的高可用性HDFS配置时，JournalNodes将处理元数据写入的存储。NameNode守护进程还需要一个本地位置来存储元数据。Cloudera建议，如果底层磁盘配置为RAID，则只使用一个目录;如果磁盘安装为JBOD，则使用不同磁盘上的两个目录。

块大小

HDFS将文件存储在分布在集群上的块中。块通常连续存储在磁盘上，以提供高的读吞吐量。块大小的选择将影响这些高吞吐量读取将运行多长时间，以及一个文件分布多少个节点。当读取单个文件的多个块时，过低的块大小将在缓慢的磁盘查找中花费更多的时间，过高的块大小将减少并行性。重I/O的数据处理将受益于更大的块大小，而重CPU的数据处理将受益于更小的块大小。

Cloudera Manager提供的默认值是128MB。块大小也可以由HDFS客户端在每个文件的基础上指定。

复制因子

当只有HDFS上的一小部分文件被大量访问时，瓶颈可能出现在少数节点上。增加文件的复制因子，以便在更多节点上复制它们的块，可以缓解这种情况。这是以牺牲集群上的存储容量为代价的。这可以在单个文件上进行设置，也可以在带有-R参数的目录上进行递归设置，方法是使用Hadoop shell命令Hadoop fs -setrep。默认情况下，复制因子是3。

纠删码

纠删码(EC)是3x复制方案的替代方案。有关EC如何工作的详细信息，请参阅数据持久性。

EC重建几乎不需要计算通过英特尔ISA-L编解码器。通过使用以下指令集加快计算速度，可获得性能改进:AES-NI, SSE, AVX, AVX2, and AVX 512。要确定一个节点是否有可用的ISA-L指令集，请检查是否存在以下任何CPU标志。

$ grep flags /proc/cpuinfo
aes
sse
avx
avx2
avx512f
avx512cd

边缘节点和客户端网关具有编解码器支持很重要，以便它们能够进行计算。

纠删码的使用对实现容错所需的节点或机架数量提出了额外的要求:

• 节点级:DataNodes 的数量需要等于或超过数据条宽度。
• 机架级:机架的数量需要等于或超过数据条宽度

例如，为了使RS-10-4策略能够容忍机架失败，您至少需要14个机架(10个机架用于数据块，4个机架用于奇偶校验块);对于主机容错，您至少需要14个节点。

纠删码将观察机架拓扑，但结果块放置策略(BPP)不同于复制。使用EC, BPP会尽可能地将所有块均匀地放置在所有机架上。Cloudera建议机架具有一致的节点数。具有更少的datanode的机架将比具有更多的datanode的机架更忙，填得更快。

**警告:**如果Impala和HBase查询试图访问纠删码数据，将会失败。有关更多信息，请咨询数据持久性。

机架感知

当为跨多个机架的集群配置机架感知时，Hadoop可以优化性能和冗余，Cloudera建议这样做。可以在Cloudera管理器中配置节点的机架分配。

在设置多机架环境时，将每个主节点放在不同的机架上。如果机架出现故障，集群可以继续使用剩余的主机进行操作。

DataNode容错容量

默认情况下，Cloudera管理器将HDFS datanode失败的卷阈值设置为datanode中一半的数据驱动器。换句话说，如果每个datanode有8个专门用于数据存储的驱动器，那么这个阈值将被设置为4，这意味着HDFS将在第5个驱动器出现故障时将datanode标记为死。这个数字可能需要向上或向下调整，这取决于有关硬盘替换的内部策略，或者因为要评估在正常运行条件下实际在集群上看到的行为。设置过高的值最终会对Hadoop集群产生负面影响。具体来说，对于YARN，有许多驱动器故障的节点上可用的容器总数仍然与没有驱动器故障的节点相同，这意味着数据局部性在前者上的更小，从而导致更多的网络流量和更慢的性能(??)。

重要的是:
短时间内多个驱动器出现故障可能表明机器出现了更大的问题，例如磁盘控制器出现故障。

DataNode Xciever计数

Xcievers是datanode进程中的处理程序，负责发送和接收块数据。一些服务，比如HBase，倾向于使用大量的Xcievers。Cloudera管理器通常配置足够的xciever计数，但是某些工作负载或存储策略(如纠删码)可能需要更高的设置。

平衡

HDFS将尝试在集群中均匀地分布数据，以优化读访问、MapReduce性能和节点利用率。随着时间的推移，由于各种各样的原因，集群可能会失去平衡。Hadoop可以使用平衡器工具在集群中重新平衡数据，从而帮助缓解这种情况。运行平衡器是一个手动过程，可以在Cloudera管理器中执行，也可以从命令行执行。默认情况下，Cloudera Manager在datanode的利用率比整个集群平均利用率高出或低于10%时配置平衡器来重新平衡datanode。可以从Cloudera管理器中查看各个datanode的利用率。

默认情况下，datanode用于重新平衡的最大带宽被设置为10 MB/秒(80 Mbit/秒)。这可以增加，但是重新平衡所使用的网络带宽可能会潜在地影响生产集群应用程序的性能。改变Cloudera Manager中的平衡器带宽设置需要重新启动HDFS服务，但是这个设置也可以在所有节点上立即进行，通过运行以下命令，而不需要进行配置更改:

hdfs dfsadmin -setBalancerBandwidth <bytes_per_second>

该命令必须作为HDFS超级用户运行。这是在不重新启动集群的情况下更改设置的一种方便的方法，但是由于它是动态更改，所以重新启动集群，它就会失效。

重要的是:
Cloudera通常不建议在HBase集群上运行平衡器，因为它会影响regionserver的数据位置，这会降低性能。不幸的是，当HBase和YARN服务进行配置并预计两者都将大量使用时，并没有一个好的方法来确保集群达到最优平衡。

可以将HDFS配置为在每个DataNode上分发写，以平衡DataNode的磁盘卷之间的可用存储。

默认情况下，DataNode仅在循环的基础上将新的块副本写入磁盘卷。您可以配置一个卷选择策略，使DataNode在决定在何处放置新副本时考虑每个卷上的可用空间。

有关更多信息，请参见为datanode配置存储平衡。

YARN

YARN服务管理MapReduce和Spark任务。应用程序在YARN容器中运行，它使用Linux Cgroup进行资源管理和进程隔离。Cloudera安装和升级手册有一节关于YARN调优指导。

Impala

Impala服务是一个分布式的，MPP数据库引擎，用于在大型数据集上进行交互式性能SQL查询。当Impala可以对内存中的数据进行操作时，它的性能最好;因此，Impala通常配置非常大的堆大小。

Impala守护进程必须与HDFS数据节点一起使用HDFS本地读取，这也可以提高性能。

Impala不提供任何内置的负载平衡，因此生产Impala部署应该位于负载平衡器的后面，以获得性能和高可用性。Cloudera Impala产品文档包含配置Impala与负载均衡器的详细信息:通过代理使用Impala获得高可用性。

Cloudera Impala产品文档中还包含一个关于Impala性能调优的部分，在产品部署之前应该对该部分进行检查:调优Impala的性能。

Spark

Cloudera支持Spark在YARN-managed部署上实现更灵活和一致的资源管理方法。在Spark下运行时，提交作业时可以指定执行器(YARN容器)的数量。动态分配在默认情况下是启用的，但是也可以通过设置spark.dynamicAllocation.enabled=false来禁用。如果——num-executor在作业中指定，则将隐式禁用动态分配。有关Spark配置和管理的其他信息，请参阅Cloudera管理手册:管理Spark。

不支持Spark独立模式。

HBase

自动进行Major 合并

默认情况下，每7天发生一次大的压缩。下一个大压缩发生在最后一次大压缩完成后的7天。这意味着主要压缩发生的实际时间可能会影响生产过程，如果希望在特定的非高峰时间(例如，凌晨3点)运行压缩，这就不是理想的情况。Cloudera强烈建议通过将时间间隔设置为0来禁用自动major压缩(HBase .hregion.major. = 0)，然后应该通过cron调用HBase管理工具来运行Major压缩

Search

Cloudera Search，基于Apache Solr，提供了一个分布式搜索引擎服务。搜索引擎通常被期望提供快速、交互式的性能，因此为搜索服务分配足够的RAM是很重要的。

如果其他资源密集型应用程序(如Impala)部署在同一个集群上，那么使用Cloudera Manager中的资源管理工具就非常重要。在某些情况下，最好避免将搜索Search与其他服务一起使用。

Oozie

编写Oozie XML配置文件可能非常繁琐且容易出错。Cloudera建议使用Hue提供的Oozie编辑器来创建、调度和执行工作流。

Kafka

Kafka与Cloudera Manager的默认配置适合于能够快速启动开发，但是在生产环境中部署Cloudera Kafka集群之前，应该对一些设置进行更改。

默认的ZooKeeper Kafka根目录是/，但是Cloudera建议将其改为/ Kafka。这是ZooKeeper中的位置，Kafka集群的znodes存储在这里。只要有一个Kafka集群在使用ZooKeeper服务，就建议使用/ Kafka。如果有多个Kafka集群(例如。dev, test, qa)共享一个ZooKeeper服务，每个Kafka实例都应该有一个唯一的ZooKeeper根(例如。/ kafka-dev, / kafka-test, / kafka-qa)。

Cloudera Manager 默认支持Kafka主题的自动创建。这意味着，如果主题不存在，那么写入该主题的任何数据都将导致该主题的创建。虽然这在原型设计和开发中可能很方便，但不应该在生产中使用它，因为在应用程序配置不当的情况下，它会导致创建任意主题和将数据写入错误的主题，而不会导致错误。

Cloudera Manager 将同步副本(ISR)的默认最小数量设置为1。在生产集群中，通常应将此值至少提高到2，以防止数据丢失。

在生产部署的某些情况下，Kafka最大进程文件描述符设置可能需要增加。这个值可以在Cloudera管理器中监控，如果使用需要比默认64k ulimit更大的值，这个值就会增加。

Kafka的默认数据保留时间对于生产来说通常是可以接受的，但是应该检查用例的适用性。

Flume

对于Flume代理，使用内存通道、文件通道或Kafka通道。Flume的内存通道在不保证数据持久性的情况下提供了更好的性能。文件通道提供了更高级别的持久性保证，因为数据以文件的形式持久存储在磁盘上。Kafka通道允许您直接从Kafka写到Hadoop而不使用源，直接从Flume源写到Kafka而不需要额外的缓冲，或者作为任何源/接收器组合的可靠且高可用的通道

Kudu

局限性

当前版本的Kudu有一些使用限制:

• Kudu目前没有任何内置的备份和恢复功能。我们鼓励用户根据需要使用Spark或Impala等工具导出或导入表。
• Kudu目前不支持机架识别或滚动重启。
• Kudu目前不支持多行事务。如果操作中途失败，则影响多行的操作将不会回滚。这可以通过利用主键惟一性约束使操作具有幂等性来缓解

Impala的兼容性

CDH(< 5.10)和Cloudera Manager的较低版本使用了Impala的实验性分支，称为IMPALA_KUDU。如果您之前已经安装了IMPALA_KUDU服务，请确保在继续之前将其从集群中删除。安装Kudu1.2X(或更高版本)使用Cloudera Manager 或命令行。

分区指导方针

Kudu支持按范围和哈希分区划分分区表。请注意，范围和哈希分区可以组合使用，以创建更有效的分区策略。也可以利用非覆盖范围分区。

对于大型表(如事实表)，目标是集群中有多少cores，就有多少tablets 。

对于小型表(如维度表)，目标是有足够多的tablets ，每个tablets 至少有1 GB的大小。

更多的细节可以在Apache Kudu指南中找到。

注意:
通常，要注意在当前实现中，tablets 的数量限制了读取的并行性。大大增加tablets 的数量，超过核心的数量，可能会导致收益递减。

安全集成

Cloudera安全指南适用于希望使用数据加密、用户身份验证和授权技术保护集群的系统管理员。

它提供了关于设置各种Hadoop组件以获得最佳安全性的概念性概述和操作信息，包括如何设置网关来限制访问。本指南假设您一般具有Linux和系统管理实践的基本知识。

常见问题

多个数据中心

Cloudera EDH部署仅限于地理区域内的数据中心。不支持跨越大地理区域的单个集群。有关更多信息，请参考附录A:跨越多个数据中心。

操作系统

支持CDH和Cloudera管理器的操作系统的列表可以在这里找到。

存储选项和配置

HDFS数据目录应该使用本地存储，这提供了让计算资源靠近存储而不是通过网络远程读取的所有好处。

Cloudera企业集群的root设备大小应该至少为500gb，以允许存储包和日志。

为了防止数据中心故障，您可以设置一个计划好的distcp操作，将数据持久化到AWS S3(请参阅distcp文档中的示例)，或者利用Cloudera Manager的备份和数据恢复(BDR)功能，将数据备份到另一个正在运行的集群。

关联数据库

Cloudera企业部署需要以下组件的关系数据库:Cloudera Manager、Cloudera Navigator、Hive metastore、Hue、Sentry、Oozie等。在Cloudera企业安装期间需要数据库凭据。

有关更多信息，请参考Cloudera Manager和托管服务数据存储。

注意:
嵌入式PostgreSQL数据库不支持在生产系统中使用。

附录A:跨越多个数据中心

跨多个数据中心跨CDH集群可以提供高可用性服务，并进一步保护数据免受主机、机架和数据中心故障的影响。

在跨多个数据中心跨CDH集群时，我们建议使用以下部署方法。

网络需求

跨多个数据中心部署可能会带来新的挑战。在本地网络上几乎保证的网络吞吐量变得更加有限，而且往往更加昂贵。类似地，跨站点链接也会随着网络流量传播距离的增加而出现更高的、可变的延迟。

请参阅本文档前面的网络规范。部署拓扑保持不变，除了网络核心将跨越多个数据中心并通过WAN链接连接。我们建议10 Gbps的交换机具有足够的端口密度来容纳跨站点链接。强烈建议使用连接每个站点的冗余链接。

站点之间的网络吞吐量取决于每个数据中心有多少个节点。对于平衡的工作负载来说，高达4:1的过载率通常是可以接受的，但是需要网络监控来确保上行带宽不是Hadoop的瓶颈。

站点之间的网络延迟不应超过10ms。

Provisioning

提供的主机在不同的数据中心，每个数据中心有一个专用的子网。通过这种方式，整个集群可以存在于几个子网中，跨站点的安全acl可以更容易地进行管理，从而允许与每个数据中心进行通信。

跨单个地理区域内的三个数据中心进行部署。由于可用性或网络需求，这在您的首选区域内可能不能实现。

注意:跨地理区域的网络延迟往往更高且更难以预测。我们不建议或支持跨地理区域的跨集群。

CDH部署

使用Quorum Journal节点以高可用模式部署HDFS NameNode，每个主节点位于不同的数据中心。例如，如果已将主NameNode部署到弗吉尼亚州的数据中心，则可以将备用NameNode部署到马里兰州或宾夕法尼亚州的数据中心。您应该在每个数据中心放置一个QJN。

尽管HDFS目前只支持两个namenode，但是如果任何一个主机、机架或数据中心出现故障，集群可以继续运行:

• 丢失活动NameNode，备用NameNode接管
• 丢失的备用NameNode，活动仍为活动;将第三个数据中心主服务器升级为新的备用NameNode
• 没有任何NameNode丢失数据中心，还有两个可行的NameNode

以类似的方式部署YARN资源管理器节点。

部署一个位于每个数据中心的三个节点ZooKeeper仲裁。

将边缘节点部署到所有三个数据中心，并配置对所有三个数据中心的客户机应用程序访问。

配置机架识别，每个数据中心一个机架。例如，您的机架id可能是这样的:

• /va-ashburn
• /va-herndon
• /va-sterling

如果使用纠删码，则必须在每个数据中心中具有一致数量的datanode。机架级容差的要求也适用，这意味着需要有多个数据中心，其数据宽度等于或超过RS策略的数据宽度。

注意事项

数据中心之间可能存在与主机网络数据发送相关的数据传输成本，但不限于设置费用、每月收费、人员和维护的持续成本以及硬件更新。

如果在单个数据中心中供应集群节点，则DFS吞吐量将小于此吞吐量。

网络吞吐量和延迟可以根据WAN链接而变化。在部署到生产环境和项目的整个生命周期中，应该对网络吞吐量和延迟进行适用性验证。

参考文献

Cloudera Enterprise

Product Documentation

Hardware Requirements Guide

Requirements and Supported Versions

Security Guide

Cloudera Services & Support

后记

Many individuals from Cloudera contributed to this document, spread across engineering, marketing, professional services, support, etc.

Alan Jackoway, Alex Breshears, Alex Moundalexis, Ben Spivey, David Beech, David Powell, Dwai Lahiri, Hung Pham, Jake Miller, Jeongho Park, Jeremy Beard, Jim Heyssel, Kaufman Ng, Michael Ridley, Morris Hicks, Mubashir Kazia, Rachel Asher, Rick Halihan, Rob Siwicki, Roger Ding, Ronan Stokes, Ryan Fishel, Scott Pace, Sean Busbey, Sean Kane, Todd Grayson, Travis Campbell, Tristan Stevens, Udai Kiran Potluri, Vartika Singh, and Zoltan Kiss.