本文主要是介绍物联网架构之CDH详解，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！
💝💝💝欢迎来到我的博客，很高兴能够在这里和您见面！希望您在这里可以感受到一份轻松愉快的氛围，不仅可以获得有趣的内容和知识，也可以畅所欲言、分享您的想法和见解。
推荐:Linux运维老纪的首页,持续学习,不断总结,共同进步,活到老学到老
导航剑指大厂系列:全面总结 运维核心技术:系统基础、数据库、网路技术、系统安全、自动化运维、容器技术、监控工具、脚本编程、云服务等。
常用运维工具系列:常用的运维开发工具, zabbix、nagios、docker、k8s、puppet、ansible等
数据库系列:详细总结了常用数据库 mysql、Redis、MongoDB、oracle 技术点,以及工作中遇到的 mysql 问题等
懒人运维系列:总结好用的命令,解放双手不香吗?能用一个命令完成绝不用两个操作
数据结构与算法系列:总结数据结构和算法,不同类型针对性训练,提升编程思维,剑指大厂
非常期待和您一起在这个小小的网络世界里共同探索、学习和成长。💝💝💝 ✨✨ 欢迎订阅本专栏 ✨✨
一、CDH概览
CDH（Cloudera Distribution Including Apache Hadoop)是由Cloudera公司提供的一个集成了Apache Hadoop以及相关生态系统的发行版本。CDH是一个大数据平台，简化和加速了大数据处理分析的部署和管理。CDH提供Hadoop的核心元素-可伸缩存储和分布式计算-以及基于web的用户界面和重要的企业功能。CDH是Apache许可的开放源码，是唯一提供统一批处理、交互式SQL和交互式搜索以及基于角色的访问控制的Hadoop解决方案。
Hadoop是一种分布式系统基础架构，是大数据处理和数据存储的主要技术之一。它具有高效可靠、弹性伸缩等特点，包括三个核心组件：HDFS、MapReduce 和 YARN，在大数据处理、数据挖掘、机器学习等领域得到了广泛的应用。
二、Hadoop的特点：
优点
1、支持超大文件。HDFS存储的文件可以支持TB和PB级别的数据。
2、检测和快速应对硬件故障。数据备份机制，NameNode通过心跳机制检测DataNode是否还存在。
3、高扩展性。可建构在廉价机上，实现线性（横向）扩展，当集群增加新节点之后，NameNode也可以感知，将数据分发和备份到相应的节点上。
4、成熟的生态圈。借助开源的力量，围绕Hadoop衍生的一些小工具
缺点：
1、不能做到低延迟。高数据吞吐量做了优化，牺牲了获取数据的延迟。
2、不适合大量的小文件存储。
3、文件修改效率低。HDFS适合一次写入，多次读取的场景。
Hadoop 的核心架构包括三个组件：
1. HDFS：HDFS 是 Hadoop 的分布式文件系统，能够将大文件划分为多个块并存储在多个节点上，实现数据的备份和容错，具有高度容错性和高吞吐量等特点，适合在廉价的机器上部署；
2. MapReduce：MapReduce 是一种分布式编程模型，能够将大规模数据进行并行处理，适用于大规模数据分析和处理；
3. 3. YARN：YARN 是 Hadoop 的资源管理器，可以动态地分配资源和管理任务，提高计算集群的利用率和效率
三、CDH特性
灵活性：存储任何类型的数据并使用各种不同的计算框架进行操作，包括批处理、交互式SQL、免费文本搜索、机器学习和统计计算。
集成：能够快速集成和运行一个完整的Hadoop平台，适用于各种不同的硬件和软件。
安全：处理和控制敏感数据。
扩展性：能够部署多种应用，并扩展和扩充它们以满足你的需求。 高可用性：可以放心地用于关键的商业任务。
兼容性：兼容现有的基础设施和资源
四、CDH功能
CDH是一个强大的商业版数据中心管理工具，提供了以下功能：
1.提供了各种能够快速稳定运行的数据计算框架，如Spark；
2.使用Apache Impala做为对HDFS、HBase的高性能SQL查询引擎；
3.使用Hive数据仓库工具帮助用户分析数据；
4.提供CM安装HBase分布式列式NoSQL数据库；
5.包含原生的Hadoop搜索引擎以及Cloudera Navigator Optimizer去对Hadoop上的计算任务进行一个可视化的协调优化，提高运行效率；
6.提供的各种软件能让用户在一个可视化的UI界面中方便地管理、配置和监控Hadoop以及其它所有相关组件，并有一定的容错容灾处理；
7.提供了基于角色的访问控制安全管理。
五、CDH和原生Hadoop区别
原生Hadoop的问题
1.版本管理过于混乱
2.部署过程较为繁琐,升级难度较大
3.兼容性差
4.安全性低
CDH优点
1. 提供基于web的用户界面，操作方便
2、集成的组件丰富，支持大多数Hadoop组件，包括HDFS、MapReduce、Hive、Pig、 Hbase、Zookeeper、Sqoop
3、搭建容易，运维比原生hadoop方便。简化了大数据平台的安装和使用难度
4、版本划分清晰、更新速度快、文档清晰、支持多种安装方式、支持Kerberos安全认证等
六、CDH 组件
CDH组件见下图
CDH作为一套开源的大数据处理平台，包含了许多不同的组件，每个组件都有各自的功能和特点。下面大概介绍下各个组件的功能和用途。
七、Hadoop HDFS
Hadoop HDFS（Hadoop Distributed File System）是CDH中的一个核心组件，它是一个可扩展的分布式文件系统，用于存储大规模的数据文件。HDFS通过将文件切分为多个块，并将这些块分布在不同的计算节点上，实现了高可用性和高性能的文件存储。
八、Hadoop YARN
Hadoop YARN（Yet Another Resource Negotiator）是CDH中的另一个核心组件，它是一个资源管理器，负责对集群中的计算资源进行统一管理和调度。YARN可以根据应用程序的需求，动态分配计算资源，实现任务的高效执行。
九、Hadoop MapReduce
Hadoop MapReduce 是CDH中用于分布式计算的编程模型和框架，它将大规模的数据切分为多个小任务，并在集群中的计算节点上并行执行这些任务。MapReduce可以实现大规模数据的处理和分析，支持复杂的数据转换和计算操作。
十、HBase
HBase是CDH的一个分布式数据库，它基于Hadoop HDFS存储数据，并提高性能的随机读写能力。HBase适用于需要快速访问和查询大规模数据的场景，如日志分析、推荐系统等
十一、Hive
Hive是CDH中的一个数据仓库工具，它提供了类似于SQL的查询语言（HiveSQL），它可以将结构化的数据映射到中hdoop的文件，并支持高性能的数据查询和分析。Hive可以方便地进行数据的ETL(Extract、Transform、Load）操作，适用于数据分析和报表生成等任务
十二、Impala
Impala是CDH中的一个交互式查询引擎，它可以直接访问存储在Hadoop HDFS和HBase中的数据，并提供类似于SQL的查询语言。Impala通过在内存中执行查询操作，实现了低延迟的数据查询和分析，适用于实时数据处理和探索性数据分析等场景。
十三、Sqoop
Sqoop是CDH中的数据导入导出工具，它可以将关系型数据库（如Mysql、Oracle等）中的数据导入到Hadoop集群中的HDFS或HBase中，也可以将Hadoop集群中的数据导出到关系型数据库中。Sqoop支持自动化的数据传输和转换，方便进行数据的迁移和集成。
十四、Flume
Flume是CDH中的一个日志收集和传输工具，它可以实时地将分布在不同计算节点上的日志数据收集到中央存储（如HDFS）中。Flume支持灵活的数据流管道配置，可以根据需求进行数据过滤、转换和路由操作，适用于大规模分布式系统的日志管理。
十五、ZooKeeper
ZooKeeper是CDH中的一个分布式协调服务，它可以实现分布式系统中的数据一致性和协同操作。ZooKeeper提供了高可用性和高性能的数据存储和访问接口，可以用于分布式锁、配置管理、命名服务等场景。
十六、Spark
Spark是一个Apache项目，它被标榜为“快如闪电的集群计算”。它拥有一个繁荣的开源社区，并且是目前最活跃的Apache项目。最早Spark是UC Berkeley AMP lab所开源的类Hadoop MapReduce的通用的并行计算框架。是一种基于内存的分布式并行计算框架，不同于MapReduce的是——Job中间输出结果可以保存在内存中，从而不再需要读写HDFS，因此Spark能更好地适用于数据挖掘与机器学习等需要迭代的MapReduce的算法。Spark提供了一个更快、更通用的数据处理平台。和Hadoop相比，Spark可以让你的程序在内存中运行时速度提升100倍，或者在磁盘上运行时速度提升10倍
十七、Pig(ad-hoc脚本）
由yahoo开源，设计动机是提供一种基于MapReduce的ad-hoc(计算在query时发生)数据分析工具。Pig定义了一种数据流语言—Pig Latin，它是MapReduce编程的复杂性的抽象,Pig平台包括运行环境和用于分析Hadoop数据集的脚本语言(Pig Latin)。其编译器将Pig Latin翻译成MapReduce程序序列将脚本转换为MapReduce任务在Hadoop上执行。通常用于进行离线分析。
十八、Oozie
Oozie是CDH中的一个工作流调度和协调工具，它可以将多个Hadoop任务组织成一个工作流，并按照指定的时间和依赖关系进行调度执行。Oozie支持复杂的任务依赖关系和条件触发，可以实现数据处理和分析的自动化流程控制。
十九、CM(Cloudera Manager)
CDH分为Cloudera Manager管理平台（CM）和CDH parcel（parcel包含各种组件的安装包），需要先安装CM，再安装parcel
CM(Cloudera Manager)提供了一个管理和监控Hadoop等大数据服务的web界面，能让我们方便安装大数据生态圈的大部分服务。
二十、核心组件CM
CM（Cloudera Manager），管理CDH端到端的应用。CM通过对CDH集群的各部分提供精细的可视化和控制，建立了企业级部署的标准，增强了操作人员的能力以提升性能、提升服务质量、提高合规性、降低管理成本,其具有以下功能：
1、 管理：对集群进行管理，例如添加、删除节点等操作。
2、 监控：监控集群的健康情况，对设置的各种指标和系统的具体运行情况进行全面的监控。
3、 诊断：对集群出现的各种问题进行诊断，并且给出建议和解决方案。
4、 集成：多组件可以进行版本兼容间的整合。
其核心是管理服务器Cloudera Manager Server，该服务器承载管理控制台的Web服务器和应用程序逻辑，并负责安装软件，配置，启动和停止服务，以及管理上的服务运行群集。
Cloudera Manager Server与以下几个组件一起工作:
Agent(代理）：安装在每台主机上。该代理负责启动和停止的过程，拆包配置，触发装置和监控主机。
Management Service：由一组执行各种监控，警报和报告功能角色的服务。
Database：存储配置和监视信息。通常情况下，多个逻辑数据库在一个或多个数据库服务器上运行。
Cloudera Repository：软件由Cloudera 管理分布存储库。
Clients：是用于与服务器进行交互的接口。
Admin Console ：基于Web的用户界面与管理员管理集群和Cloudera管理。
API ：与开发人员创建自定义的Cloudera Manager应用程序的API。
二十一、CM功能
1. 状态管理
Cloudera Manager Server维护了集群的各种状态。状态可以分为两类：模块和运行时，两者存储于Cloudera Manager Server的数据库中。
模块中包含集群、主机、服务、配置。运行时包含进程、命令。
2. 配置管理
CM在多个层面定义了配置，如：
服务层面：可定义整个服务实例层面的配置，如HDFS服务的默认副本因子。
角色组层面：可定义某个角色组的配置，如DataNode的处理线程数量，可根据DataNodes的不同分组进行不同的配置。
角色层面：可覆盖从角色组层面继承的配置。这种配置需要谨慎使用，因为会造成角色组中的配置分歧。如因为排错需求临时启用某个角色实例的DEBUG日志。
主机层面：根据监控、软件管理、资源管理的不同有不同的配置。
CM自身也有很多与管理操作相关的配置
3. 进程管理
非CM管理的集群使用脚本进行角色进程的启动，但在CM管理的集群中这类脚本不起作用。
CM管理的集群中，只能使用CM进行角色进程的启停。CM使用开源的进程管理工具名为supervisord，其会启动进程、重定向日志、通知进程失 败、为进程设置正确的用户ID等等。CM支持自动重启一个崩溃的进程。 如果一个进程在启动后频繁崩溃，还会被打上非健康标记。
停止CMS和CM代理不会使正在运行的进程被中止。
4. 软件包管理
CM支持两种软件分发格式:packages和parcels。
packages是一种二进制分发格式，包含编译的代码和元数据如包 述、版本、依赖项。包管理系统评估此元数据以允许包搜索、执行升级、确保包的所有依赖关系得到满足。CM使用本地操作系统支持的包管理程序。
parcel也是一种二进制分发格式，包含CM需要使用的附加元数据。其与package的区别有:可安装同一个parcel的多个版本，并激活其中一个; parcel可安装到任何路径;通过parcel安装，CM会自动下载并激活和每 个节点操作系统版本匹配的parcel包，解决某些操作系统版本不一致问题。
5. 主机管理
CM 供了多种功能以管理Hadoop集群的主机。第一次运行CM管理员控制台时，可搜索主机并添加到集群，一旦选中了主机就可以为其分配CDH 角色。CM会在主机上自动部署作为集群托管节点的所有软件:JDK，CM 代理，CDH，Impala，Solr等等。
服务部署并运行后，管理员控制台中的“Hosts”区域显示集群中托管 主机的总体状态。 供的信息包括主机上的CDH版本、主机所属的集群、 运行在主机上的角色的数量。Cloudera管理服务中的主机监控角色执行 健康检查并收集主机的统计信息，以允许你监控主机的健康和性能。
6. 资源管理
CM允许使用两种资源管理方式:
静态资源池:使用Linux cgroups在多个服务间静态地进行资源隔离，如 HBase、Impala、YARN分别使用一定百分比的资源。静态资源池默认不启 用。
动态资源池:用于某些服务内部的资源管理，如YARN的各种资源调度器; Impala也可对不同池中的查询动态分配资源。
7. 用户管理
访问CM通过用户账户进行控制。用户账户标识如何对用户进行身份验证，并确定授予用户的权限。
CM 供了多种用户认证机制。可以配置CM使用CM数据库认证用户，或使用某种外部认证服务。外部认证服务可以是LDAP服务器，或者指定的其 他服务。CM还支持使用安全断言标记语言(SAML)来实现单点登录。
8. 安全管理
认证:认证是指用户或服务证明其有访问某种系统资源的权限。Cloudera集群支持操作系统账号认证、LDAP、Kerberos等认证方式。LDAP和Kerberos并不是互斥的，很多时候可以一起使用。
授权:授权关注谁可以存取或控制指定的资源或服务。CDH目前支持以 下几种权限控制:传统的POSIX形式的目录和文件权限控制;HDFS扩展 的ACL细粒度权限控制;HBase可对用户和组设置各种操作的ACL;使用Apache Sentry进行基于角色的权限控制。
加密:集群不同层面存储和传输的数据支持不同的加密方式。
9. 管理服务
Cloudera Management Service实现了多种管理特性，包括活动监控、主机监控、服务监控、事件服务、告警发布、报表管理等。
二十二、CDH版本
目前官网上有cdh6版本和cdh5版本
Cdh6版本
地址：
Cdh5版本
地址：
https://docs.cloudera.com/documentation/enterprise/release-notes/topics/cdh_vd_cdh_download.html
CDH6相对于CDH5是一次各个组件的大版本升级，新增了很多功能，同时各个组件也修复了大量已知的问题和安全漏洞。比如HDFS的纠删码用于冷数据降低存储成本又保证了数据的可用性，NameNode和YARN的联邦解决大规模集群的性能瓶颈问题，YARN引入GPU支持等。长远来看，从Hadoop2升级到Hadoop3或者从CDH5升级到CDH6是必须的，Cloudera的开发重心也转移到Hadoop3或CDH6上，而CDH5则主要以维护和修复bug为主。
下面是CDH5最新版本和CDH6最新版本的各个组件的支持情况
CDH6要求和支持的版本
在企业数据中心中，Cloudera Manager 和 CDH 与多个产品（如 Apache Accumulo、Apache Impala、Hue、Cloudera Search 和 Cloudera Navigator）进行交互。必须考虑 Cloudera Manager 和 CDH 不同发行版本之间的兼容性，尤其是在执行安装/升级过程时。
下面是CDH6的要求和支持的版本信息
硬件要求
Cloudera 管理器
Cloudera Manager服务器存储要求
| 组件 | 存储 | 笔记 |
| 分区托管 /usr | 1 GB | |
| 分区托管 /var | 5 GB 至 1 TB | 根据管理的节点数进行扩展。见下表。 |
| 分区托管 /opt | 最低 15 GB | 使用量随着下载的包裹数量的增加而增长。 |
| Cloudera Manager 数据库服务器 | 5 GB | 如果 Cloudera Manager 数据库与 Service Monitor 和 Host Monitor 共享，则需要更多的存储空间来 满足这些组件的要求。 |
基于主机的Cloudera Manager服务器要求
在较小的集群上，Cloudera Manager 服务器和数据库可以共享一个主机。在较大的集群上，它们必须在单独的专用集群上运行主机
| 集群主机数 | 数据库主机配置 | 堆大小 | 逻辑处理器 | Cloudera Manager 服务器 /var 目录 |
| 非常小 （≤10） | 共享 | 2 GB | 4 | 5 千兆字节 |
| 小 （≤20） | 共享 | 4 GB | 6 | 最低 20 GB |
| 中 （≤200） | 专用 | 8 GB | 6 | 最低 200 GB |
| 大 （≤500） | 专用 | 10 GB | 8 | 最低 500 GB |
| 超大 （>500） | 专用 | 16GB | 16 | 最低 1 TB |
具有HDFS、YARN或Impala的集群
对于具有辅助角色的唯一服务是 HDFS、YARN 或 Impala 的集群，请使用此表中的建议。
| 受监控实体数 | 主机数量 | 所需的 Java 堆大小 | 建议的非 Java 堆大小 |
| 0-2,000 | 0-100 | 1 GB | 6 GB |
| 2,000-4,000 | 100-200 | 1.5 GB | 6 GB |
| 4,000-8,000 | 200-400 | 1.5 GB | 12 GB |
| 8,000-16,000 | 400-800 | 2.5 GB | 12 GB |
| 16,000-20,000 | 800-1,000 | 3.5 GB | 12 GB |
使用HBase，Solr、Kafka或Kudu的集群
在群集中部署 HBase、Solr、Kafka 或 Kudu 等服务时，请使用这些建议。这些服务通常具有大量受监视的实体。
| 受监控实体数 | 主机数量 | 所需的 Java 堆大小 | 建议的非 Java 堆大小 |
| 0-30,000 | 0-100 | 2 GB | 12 GB |
| 30,000-60,000 | 100-200 | 3 GB | 12 GB |
| 60,000-120,000 | 200-400 | 3.5 GB | 12 GB |
| 120,000-240,000 | 400-800 | 8 GB | 20 GB |
主监视器
服务监视器可能是资源最密集的服务，需要特别注意。服务监视器要求基于受监视的数量实体。若要查看受监视实体的数量可以打开 Cloudera Manager 管理控制台，然后单击 Cloudera Management >集群 服务，查找 Cloudera Management Service Monitored Entities 图表，在此图标中查看。确保至少有 25 GB 的磁盘空间可用于 Host Monitor、Service Monitor、Reports Manager 和 Events Server 数据库。
| 主机数量 | 受监控实体数 | 堆大小 | 非 Java 堆大小 |
| 0-200 | <6k | 1 GB | 2 GB |
| 200-800 | 6k-24k | 2 GB | 6 GB |
| 800-1000 | 24k-30k | 3 GB | 6 GB |
报表管理器
报告管理器定期从 NameNode 获取 fsimage。它读取 fsimage 并为其创建一个 Lucene 索引。为了提高索引性能，Cloudera 建议置备尽可能强大的主机，并将 SSD 磁盘专用于报告管理器。
| 组件 | Java 堆 | 中央处理器 | 磁盘 | |
| 报表管理器 | FSimage大小的3-4倍。 | 最小：8核，推荐：16 核（32 核，启用超线程 | 1个专用磁盘，其大小至少是 fsImage 的 20 倍。Cloudera 强烈建议使用 SSD 磁盘。 | |
代理主机
| 元件 | 存储 | 笔记 |
| 分区托管 /opt | 最低 15 GB | 随着新宗地下载到群集主机，使用量也会增加。 |
| /var/log | 每个角色 2 GB | 主机上运行的每个角色至少需要 2 GB 的磁盘空间。 |
事件服务器
| CPU | RAM | 存储 |
| 1 核 | 256M | 5 GB 用于事件数据库,事件服务器索引目录为 20 GB。此目录的位置由事件服务器索引目录事件服务器配置设置 |
警报发布者
| CPU | RAM | 存储 |
| 1 核 | 1G | 至少 1 个磁盘用于日志文件 |
Cloudera 导航器
| 元件 | Java 堆/内存 | CPU | 磁盘 |
| Navigator 审核服务器 | 最低：2-3 GB 的 Java 堆使用“审计服务器的 Java 堆大小（以字节为单位）”配置属性配置此值。 | 最低：1 核 | Navigator Audit Server 使用的数据库必须能够容纳数百 GB（或每 数千万行 天）。数据库大小可能达到 TB。理想情况下，数据库不应与其他服务共享，因为审计插入率可能会使数据库服务器不堪重负，从而使使用同一数据库的其他服务减少 响应。 |
| Navigator 元数据服务器 | 最低：10 GB 的 Java 堆推荐：20 GB Java 堆 | 最低：1 核 | 最低：50 GB推荐：100-200 GB注意：元数据服务器存储的数据会无限增长，除非您运行清除功能。如果您尚未将清除功能设置为按计划的时间间隔运行，建议 运行清除功能以回收磁盘空间并控制数据增长（以及相应的内存要求）。 |
Cloudera 数据科学工作台
| 硬件组件 | 要求 | 笔记 |
| CPU | 16+ CPU （vCPU） 核心 | 每个会话至少分配 1 个 CPU 内核。1 个 CPU 内核通常足以满足轻量级工作负载的需求。 |
| Memory | 32 GB 内存 | 作为一般准则，Cloudera 建议 RAM 在 60GB 到 256GB 之间的节点，分配少于 2 GB 的 RAM 可能会导致许多应用程序出现内存不足错误。 |
| 磁盘 | 根卷：100 GB应用程序块设备或挂载点（仅限主主机）：1 TBDocker 镜像块设备：1 TB | 强烈建议将 SSD 用于应用程序数据存储 |
CDH
Flume
| 组件 | Java Heap | CPU | 磁盘 |
| Flume | 最低：1 GB最大 4 GBJava 堆大小应大于最大通道容量使用 Java Heap Size of Agent （Bytes Flume） 配置属性设置此值。 | 使用以下公式计算内核数：（源数 + 汇数 ） / 2 | 建议将多个磁盘用于文件通道，无论是 JBOD 设置还是 RAID10（由于可靠性更高，首选）。 |
HDFS
| 组件 | Memory | CPU | 磁盘 |
| J JournalNode节点 | 11GB（默认）使用 JournalNode 的 Java 堆大小（以字节为单位）HDFS 配置属性设置此值。 | 最少 1 个核心 | 11个专用磁盘 |
| NameNode | 最小值：1 GB（用于概念验证部署）每增加 1000000 个blocks，再增加1GB快照和加密可能会增加所需的堆内存。使用 NameNode 的 Java 堆大小（以字节为单位）HDFS 配置属性设置此值。 | 至少 4 个专用内核;对于较大的群集，可能需要更多 | 至少 2 个用于元数据的专用磁盘1 个用于日志文件的专用磁盘（此磁盘可能与操作系统共享。最大磁盘数：4 |
| DataNode | 最低：4 GB增加内存以获得更高的副本数或每个 DataNode 的更多块数。使用 DataNode 的 Java 堆大小（以字节为单位）HDFS 配置属性设置此值。 | 最小值：4 个内核。为高度活跃的集群添加更多核心。 | 最小值：4最大值：24Cloudera 不支持大于 8 TB 的驱动器。 |
HBase
| 组件 | Java Heap | CPU | 磁盘 |
| Master | 100-10,000 个区域：4 GB10,000 个或更多区域，具有 200 个或更多区域服务器：8 GB10,000 个或更多区域，具有 300 个或更多区域服务器：12 GB使用 HBase Master 的 Java 堆大小（以字节为单位）HBase 配置属性设置此值。 | 至少 4 个专用内核。您可以为更大的集群添加更多内核，在使用复制时或批量加载时。 | 1 1个用于本地日志的磁盘，可以与操作系统和/或其他 Hadoop 日志共享 |
| Region Server | 最低：8 GB中等规模生产：16 GB大于 16 GB 的堆需要特殊的垃圾回收优化。使用 HBase RegionServer 的 Java 堆大小（以字节为单位）HBase 配置属性设置此值。 | 最少：4 个专用内核 | 每个 HDFS DataNode 有 4 个或更多心轴1 个磁盘用于本地日志（此磁盘可以与操作系统和/或其他 Hadoop 日志共享） |
| Thrift服务器 | 11GB - 4 GB使用 HBase Thrift Server 的 Java 堆大小（以字节为单位）HBase 配置属性设置此值。 | 至少 2 个专用内核。 | 1 个本地日志磁盘，可以与操作系统和其他 Hadoop 日志共享。 |
Hive
| 组件 | Java 堆 | CPU | 磁盘 | |
| HiveServer 2 | 单连接 | 44GB | 至少 4 个专用内核 | 最少 1 个磁盘以下情况需要此磁盘：HiveServer2 日志文件stdout和输出文件stderr配置文件操作日志存储在目录下，可配置operation_logs_dir目录下的本地映射任务可能创建的任何临时文件/tmp |
| 2-10 个连接 | 4 4-6 GB | |||
| 1 11-20个连接 | 6-12 GB | |||
| 21-40个连接 | 1 12-16 GB | |||
| 40-80个连 | 1 16-24 GB | |||
| 使用 HiveServer2 的 Java 堆大小（以字节为单位）Hive 配置属性设置此值。 | ||||
| Hive元存储 | 单连接 | 4 4GB | 至少 4 个专用内核 | 最少 1 个磁盘此磁盘是必需的，以便 Hive 元存储可以存储以下项目：日志配置文件如果数据库服务器也托管在同一节点上，则用于存储元数据的后端数据库 |
| 2-10 个连接 | 4 4-10GB | |||
| 1 11-20个连接 | 10-12 GB | |||
| 21-40个连接 | 1 12-16 GB | |||
| 40-80个连接 | 1 16-24 GB | |||
| Beeline CLI | 最低：2 GB |
Spark Executor 节点上的Hive
| 元件 | Memory | CPU | 磁盘 |
| Hive-on-Spark | 最低：16 GB建议：32 GB（用于较大的数据大小）单个执行程序堆不应大于 16 GB，因此可以有更多 RAM 的计算机可以使用多个执行程序。 | 最小：4 核建议：8 个内核，用于更大的数据大小 | 磁盘空间要求由 Spark 溢出的暂存空间要求驱动。 |
HSM KMS
| 元件 | Memory | CPU | 磁盘 |
| Navigator HSM KMS | 16 GB 内存 | 最低配置：2 GHz 64 位四核 | 40 GB，使用中等到高性能驱动器。 |
HUE
| 元件 | Memory | CPU | 磁盘 |
| hue 服务器 | 最低：4 GB最大 10 GB如果集群使用 Hue 负载平衡器，请添加额外的内存 | 最低要求：运行 Django 的 1 个核心当 Hue 配置为高可用性时，请添加其他内核 | 最小值：数据库为 10 GB，根据群集大小和工作负载按比例增长。当 Hue 配置为高可用性时，需要添加临时空间 |
Impala
Impala 的大小调整要求可能会因使用 Impala 的工作负载的大小和类型而有很大差异
| 元件 | 本机内存 | JVM 堆 | CPU | 磁盘 |
| Impala 守护进程 | 使用 Impala Daemon Memory Limit 配置属性设置此值。最低：32 GB推荐：128 GB | 使用 Impala 守护程序的 Java 堆大小（以字节为单位）配置属性来设置此值 协调员 Impala Daemons。最低：4 GB推荐：8 GB | 最小值：4推荐：16 个以上CPU指令集：AVX2 | 最小：1 个磁盘推荐：8 个以上 |
| Catalog服务器 | 使用目录服务器的 Java 堆大小（以字节为单位）配置属性设置此值。最低：4 GB推荐：8 GB | 最小值：4推荐：16 个以上CPU指令集：AVX2 | 最低和推荐：1 个磁盘 |
Kafka
Kafka 需要相当少量的资源，尤其是在进行一些配置调整时。默认情况下，Kafka 可以在低至 1 个内核和 1GB 内存上运行，并具有存储 根据数据保留要求进行扩展。
CPU 很少成为瓶颈，因为 Kafka 的 I/O 量很大，但具有足够线程的中等大小的 CPU 对于处理并发连接和后台仍然很重要 任务。
组网要求：千兆以太网或 10 千兆以太网。避免跨多个数据中心的集群。
| 元件 | 内存/Java 堆 | CPU | 磁盘 |
| Broker | RAM： 64 GB推荐的 Java 堆：4 GB使用 Broker Kafka 的 Java 堆大小配置属性设置此值。。 | 1 12- 24 核 | 1 HDD 用于操作系统1 个用于 Zookeeper dataLogDir 的硬盘10- HDD，使用 Raid 10，用于 Kafka 数据 |
| MirrorMaker | 1 1GB 堆使用 MirrorMaker Kafka 的 Java 堆大小配置属性设置此值。 | 每 3-4 个流 1 个CPU | MirrorMaker 实例上不需要磁盘空间。目标代理应具有足够的磁盘空间来存储要复制的主题。 |
Key Trustee Server
| 元件 | Memory | CPU | 磁盘 |
| Key Trustee Server | 8GB | 1 1GHz 64 位四核 | 20GB，使用中等到高性能驱动器 |
Key Trustee KMS
| 元件 | Memory | CPU | 磁盘 |
| Key Trustee KMS | 16 GB | 2GHz 64 位四核 | 40 GB，使用中等到高性能驱动器 |
Kudu
| 元件 | Memory | CPU | 磁盘 |
| Tablet Server | 最低：4 GB推荐：10 GB可能需要额外的硬件，具体取决于群集中运行的工作负载。 | kudu 目前需要支SSSE3 和 SSE4.2 指令集的 CPU。如果要在 VM 中运行 Kudu，请启用 SSE4.2 直通以将 SSE4.2 支持传递到 VM 中。 | 1 1个磁盘用于预写日志 （WAL）。使用 SSD 驱动器可以提高性能。 |
| Master | 最低：256 MB推荐：1 GB | 1 1个磁盘 |
Oozie
| 元件 | Java 堆 | CPU | 磁盘 |
| Oozie | 最小值：1 GB（这是 Cloudera Manager 设置的默认值）。这对于少于 10 个同时进行的工作流来说已经足够了，无需分叉。如果发现垃圾回收过多或内存不足错误，请将堆大小增加到 4 GB（对于中型生产群集）或 8 GB（对于大型生产） 集群。使用 Oozie 服务器的 Java 堆大小（以字节为单位）Oozie 配置属性设置此值。 | 无需资源 | 无需资源 |
其他调整：
对于具有许多协调器且使用复杂工作流运行的工作负载（日志中显示已达到最大并发性警告，并且 Oozie 命令显示大型队列）：admin -queuedump
· 将属性的值增加到 50。oozie.service.CallableQueueService.callable.concurrency
· 将属性的值增加到 200。oozie.service.CallableQueueService.threads
不要将 Derby 数据库用作 Oozie 的后端数据库。
Search
| 元件 | Java 堆 | CPU | 磁盘 |
| Solr | 小型工作负载或评估：16 GB较小的生产环境：32 GB较大的生产环境：对于大多数集群来说，96 GB 就足够了。使用 Solr 服务器的 Java 堆大小（以字节为单位）Solr 配置属性设置此值。 | 最小值：4建议：16 个用于生产工作负载 | 没有要求。Solr 使用 HDFS 进行存储。 |
Sentry
| 元件 | Java 堆 | CPU | 磁盘 |
| Sentry Server | 最低：576 MB建议：Hive 数据库中每百万个对象（服务器、数据库、表、分区、列、URI 和视图）2.5 GB使用 Sentry 服务器的 Java 堆大小（以字节为单位）Sentry 配置属性设置此值。 | 最小值：4 |
Spark
| 元件 | Java 堆 | CPU | 磁盘 |
| Spark History Server | 最低：512 MB使用 History Server 的 Java 堆大小（以字节为单位）Spark 配置属性设置此值。 | 1重要：Cloudera 建议您根据特定的集群使用情况调整 Spark History Server 的 CPU 和内存数量 | 至少 1 个磁盘用于日志文件。 |
YARN
| 元件 | Java 堆 | CPU | 其他建议 |
| Job History Server | 最低：1 GB内存中每保留 100000 个任务，内存增加 1.6GB。使用 JobHistory Server 的 Java 堆大小（以字节为单位）YARN 配置属性设置此值。 | 最低：1 核 | 将属性设置为二进制（使用此设置，历史记录文件的加载速度将提高约 2-3 倍）。在 CDH 中可用 仅限 5.5.0 或更高版本。mapreduce.jobhistory.jhist.format |
| NodeManager | 最低：1 GB。为以下条件配置额外的堆内存：大量容器Spark或MapReduce中的大随机播放大小使用 NodeManager 的 Java 堆大小（以字节为单位）YARN 配置属性设置此值。 | 最小：8-16 个内核推荐：32-64 核 | 磁盘：最小：8 个磁盘建议：12 个或更多磁盘联网：最低要求：双 1Gbps 或更快推荐：单/双 10 Gbps 或更快 |
| 资源管理器 | 最低：6 GB为以下条件配置额外的堆内存：更多的任务更大的集群大小保留的已完成应用程序数（使用属性配置。yarn.resourcemanager.max-completed-applications调度程序配置使用 ResourceManager 的 Java 堆大小（以字节为单位）YARN 配置属性设置此值。 | 最低：1 核 | |
| 其他设置 | 将 ApplicationMaster 内存 YARN 配置属性设置为 512 MB将“容器内存最小 YARN”配置属性设置为 1 GB。 |
ZooKeeper
| 元件 | Java 堆 | CPU | 磁盘 |
| ZooKeeper 服务器 | 最低：1 GB在监视 10,000 - 100,000 个临时 znode 并使用 1,000 个或更多客户端时增加堆大小。使用 ZooKeeper 服务器的 Java 堆大小（以字节为单位）ZooKeeper 配置属性设置此值。 | 最小：4 核 | ZooKeeper 并非设计为低延迟服务，并且不会从 SSD 驱动器的使用中受益。ZooKeeper 访问模式 – 仅追加写入和顺序读取 – 在设计时考虑到了旋转盘。因此，Cloudera 建议使用 HDD 驱动器。 |
操作系统要求
CDH 和 Cloudera Manager 支持的操作系统
CDH 为与 RHEL 兼容的 SLES 和 Ubuntu 操作系统的特定版本提供 64 位软件包。
数据库要求
目前支持的数据库有Mysql，MariaDB，PostgreSQL，Oracle，支持的各个数据库版本信息和对应的CDH版本信息如下:
Java要求
仅支持 64 位 JDK。Cloudera Manager 6 和 CDH 6 不支持 JDK 7。
不支持在不同 JDK 版本的同一集群中运行 CDH 节点。所有群集主机必须使用相同的 JDK 更新级别。
注意
JDK 8u271、JDK 8u281 和 JDK 8u291 可能会由于 JDK-8245417 和 JDK-8256818 而导致套接字泄漏问题。请注意 JDK 的构建版本，因为一些后续构建被固定为 在JDK-8256818中进行了描述。
解决办法：考虑使用较新版本的 JDK（如 8u282）或已修复问题的 JDK 内部版本。
不支持 JDK 8u40、8u45 和 8u60，因为 JDK 问题会影响 CDH 功能：JDK 8u40 和 8u45 受 JDK-807715影响，这会影响 HTTP 身份验证 对于某些 Web UI。JDK 8u60 与 AWS 开发工具包不兼容，并导致 DistCP 出现问题。
Hue 中的Oozie 工作流图形显示无法与 低于 8U40 的JDK版本 一起正常工作 。
重要：
对于在使用 Kerberos 的集群上运行的 JDK 8u241 及更高版本，必须通过设置 来禁用引用。sun.security.krb5.disableReferrals=true
例如，使用 OpenJDK 1.8.0u242：
1. 使用文本编辑器打开。/usr/lib/jvm/java-1.8.0-openjdk-1.8.0.242.b08-0.el7_7.x86_64/jre/lib/security/java.security
2. 添加（它可以位于文件的底部）。sun.security.krb5.disableReferrals=true
3. 在具有受影响的 JDK 版本的每个节点上添加此属性。
4. 使用 JDK 重新启动应用程序，以使更改生效。
网络和安全要求
CDH 和 Cloudera Manager 支持的传输层安全版本
指示的传输层安全性 （TLS） 版本支持以下组件：
| 组件 | 角色 | 名称 | 端口 | 版本 |
| Cloudera Manager | Cloudera Manager Server | 7182 | TLS 1.2 | |
| Cloudera Manager | Cloudera Manager Server | 7183 | TLS 1.2 | |
| Flume | 9099 | TLS 1.2 | ||
| Flume | Avro 源/接收器 | TLS 1.2 | ||
| Flume | Flume HTTP 源/接收器 | TLS 1.2 | ||
| HBase | Master | HBase Master Web UI Port | 60010 | TLS 1.2 |
| HDFS | NameNode | Secure NameNode Web UI Port | 50470 | TLS 1.2 |
| HDFS | Secondary NameNode | Secure Secondary NameNode Web UI Port | 50495 | TLS 1.2 |
| HDFS | HttpFS | REST Port | 14000 | TLS 1.1, TLS 1.2 |
| Hive | HiveServer2 | HiveServer2 Port | 10000 | TLS 1.2 |
| Hue | Hue Server | Hue HTTP Port | 8888 | TLS 1.2 |
| Impala | Impala Daemon | Impala Daemon Beeswax Port | 21000 | TLS 1.0, TLS 1.1, TLS 1.2 |
| 建议客户端使用支持的最高版本 TLS 1.2。 | ||||
| Impala | Impala Daemon | Impala Daemon HiveServer2 Port | 21050 | TLS 1.0, TLS 1.1, TLS 1.2 |
| 建议客户端使用支持的最高版本 TLS 1.2。 | ||||
| Impala | Impala Daemon | Impala Daemon 后端 Port | 22000 | TLS 1.0, TLS 1.1, TLS 1.2 |
| 建议客户端使用支持的最高版本 TLS 1.2。 | ||||
| Impala | Impala StateStore | StateStore 服务端口 | 24000 | TLS 1.0, TLS 1.1, TLS 1.2 |
| 建议客户端使用支持的最高版本 TLS 1.2。 | ||||
| Impala | Impala Daemon | Impala Daemon HTTP 服务器端口 | 25000 | TLS 1.0, TLS 1.1, TLS 1.2 |
| 建议客户端使用支持的最高版本 TLS 1.2。 | ||||
| Impala | Impala StateStore | StateStore HTTP 服务器端口 | 25010 | TLS 1.0, TLS 1.1, TLS 1.2 |
| 建议客户端使用支持的最高版本 TLS 1.2。 | ||||
| Impala | Impala 目录服务器 | Catalog Server HTTP Server Port | 25020 | TLS 1.0, TLS 1.1, TLS 1.2 |
| 建议客户端使用支持的最高版本 TLS 1.2。 | ||||
| Impala | Impala 目录服务器 | Catalog Server Service Port | 26000 | TLS 1.0, TLS 1.1, TLS 1.2 |
| 建议客户端使用支持的最高版本 TLS 1.2。 | ||||
| Oozie | Oozie Server | Oozie HTTPS Port | 11443 | TLS 1.1, TLS 1.2 |
| Solr | Solr Server | Solr HTTP Port | 8983 | TLS 1.1, TLS 1.2 |
| Solr | Solr Server | Solr HTTPS Port | 8985 | TLS 1.1, TLS 1.2 |
| Spark | History Server | 18080 | TLS 1.2 | |
| YARN | ResourceManager | ResourceManager Web Application HTTP Port | 8090 | TLS 1.2 |
| YARN | JobHistory Server | MRv1 JobHistory Web Application HTTP Port | 19890 | TLS 1.2 |
CDH和ClouderaManager网络和安全要求
Cloudera Manager 部署中的主机必须满足以下网络和安全要求：
网络协议支持：CDH 需要 IPv4。不支持 IPv6，必须禁用
多宿主支持
熵：静态数据加密需要足够的熵来确保随机性。
群集主机必须具有正常工作的网络名称解析系统和格式正确的文件。所有群集主机都必须已正确配置 通过 DNS 进行正向和反向主机解析。文件必须：1.包含有关所有主机的主机名和 IP 地址的一致信息2.不包含大写主机名3.不包含重复的 IP 地址
群集主机不得在配置 DNS 中或配置 DNS 时使用别名。格式正确的文件（/etc/hosts/etc/hosts）应该 类似于以下示例：
127.0.0.1 localhost.localdomain localhost
192.168.1.1 http://cluster-01.example.com cluster-01
192.168.1.2 http://cluster-02.example.com cluster-02
192.168.1.3 http://cluster-03.example.com cluster-03
· 必须禁用或配置防火墙，以允许访问 Cloudera Manager、CDH 和相关服务使用的端口。
· 对于 RHEL 和 CentOS，每个主机上的文件必须包含正确的主机名。/etc/sysconfig/network
Cloudera Manager 和 CDH 使用多个用户帐户和组来完成其任务
Cloudera Manager、CDH 和托管服务创建并使用以下帐户和 组：
| 用户和组 | |||
| 组件（版本） | Unix 用户ID | 组 | 功能 |
| Cloudera Manager (所有版本) | cloudera-scm | cloudera-scm | Cloudera Manager 管理集群运行 ，Cloudera Manager Server、监控角色和其他 Cloudera Server 进程 作为 cloudera-scm。需要命名文件名为 keytab的 文件，因为 name 在 Cloudera Manager 中是硬编码的。cmf.keytab |
| Apache Accumulo | accumulo | accumulo | Accumulo 进程以该用户身份运行 |
| Apache Flume | flume | flume | 以用户身份写入 HDFS 的接收器必须具有写入权限。 |
| Apache HBase | hbase | hbase | Master 和 RegionServer 进程以该用户身份运行。 |
| HDFS | hdfs | hdfs, hadoop | NameNode 和 DataNodes 以该用户身份运行，HDFS 根目录以及用于编辑日志的目录 应该归它所有 |
| Apache Hive | hive | hive | HiveServer2 进程和 Hive 元存储进程以该用户身份运行。必须定义用户才能进行 Hive 访问其元存储数据库（例如 MySQL 或 Postgres），但它可以是任何标识符，并且不对应于 Unix uid。这是在 hive-site.xml 中。 |
| Apache HCatalog | hive | hive | 用于对 Hive 功能的 REST 访问，以用户身份运行 |
| HttpFS | httpfs | httpfs | HttpFS 服务以该用户身份运行 |
| Hue | hue | hue | Hue 服务以该用户身份运行。 |
| Hue 负载均衡 | apache | apache | Hue 负载平衡器依赖于使用用户的 apache2 软件包 名字。Cloudera Manager 不使用此用户 ID 运行进程 |
| Impala | impala | impala, hive | Impala 服务以该用户身份运行 |
| Apache Kafka | kafka | kafka | Kafka 代理和镜像制造商以该用户身份运行。 |
| Java KeyStore KMS | kms | kms | Java KeyStore KMS 服务以该用户身份运行。 |
| Key Trustee KMS | kms | kms | Key Trustee KMS 服务以该用户身份运行。 |
| Key Trustee Server | keytrustee | keytrustee | Key Trustee Server 服务以该用户身份运行。 |
| Kudu | kudu | kudu | Kudu 服务以该用户身份运行。 |
| MapReduce | mapred | mapred, hadoop | 如果没有 Kerberos，JobTracker 和任务将以该用户身份运行。LinuxTaskController 二进制文件归此用户所有，用于 Kerberos。 |
| Apache Oozie | oozie | oozie | Oozie 服务以该用户身份运行。 |
| Parquet | ~ | ~ | 没有特殊用户 |
| Apache Pig | ~ | ~ | 没有特殊用户 |
| Cloudera Search | solr | solr | Solr 进程以该用户身份运行。 |
| Apache Spark | spark | spark | Spark History Server 进程以该用户身份运行。 |
| Apache Sentry | sentry | sentry | Sentry 服务以该用户身份运行。 |
| Apache Sqoop | sqoop | sqoop | 此用户仅适用于 Sqoop1 元存储，不建议使用该配置选项。 |
| YARN | yarn | yarn, hadoop | 如果没有 Kerberos，所有 YARN 服务和应用程序都以该用户身份运行。LinuxContainerExecutor 二进制文件归 Kerberos 的此用户。 |
| Apache ZooKeeper | zookeeper | zookeeper | ZooKeeper 进程以该用户身份运行。它是不可配置的。 |
静态数据加密要求
加密由多个组件组成，每个组件都有自己的要求。
静态数据加密保护可以在 Hadoop 中的多个级别应用：
1.操作系统文件系统级别
2.网络级
3.HDFS 级别（保护静态数据和传输中的数据）
Entropy要求
加密操作需要熵来确保随机性。
可以通过运行以下命令来检查 Linux 系统上的可用熵：
cat /proc/sys/kernel/random/entropy_avail
输出显示当前可用的熵。多次检查熵以确定系统上熵池的状态。如果熵始终较低（500 或更少），您必须通过安装和启动服务来增加它。在 RHEL 6 兼容上运行以下命令：
对于 RHEL 7，请运行以下命令：
确保运行 Key Trustee Server、Key Trustee KMS 和 Navigator Encrypt 的主机具有足够的熵来执行加密操作。
Cloudera Manager 要求
使用 Cloudera Manager 安装和管理 Key Trustee Server 需要 Cloudera Manager 5.4.0 及更高版本。Key Trustee Server 不需要 Cloudera Navigator Audit Server 或 元数据服务器。
umask 要求
Key Trustee Server 安装需要缺省值。
网络要求
对于新的 Key Trustee Server 安装（5.4.0 及更高版本），Key Trustee Server 需要以下 TCP 端口 为入站流量开放：
11371：客户端通过 HTTPS 连接到此端口。
11381 （PostgreSQL）被动密钥受托人服务器连接到此端口以进行数据库复制。
TLS证书要求
为确保网络流量安全，Cloudera 建议获取特定于密钥受托人服务器主机名的传输层安全性 （TLS） 证书。要获取 证书，则为 Key Trustee Server 主机的完全限定域名 （FQDN） 生成证书签名请求 （CSR）。CSR 必须由受信任的证书颁发机构 （CA） 签名。 在 CA 验证和签署证书后，密钥受托人服务器 TLS 配置需
http://1.CA签名的证书
2.用于生成原始 CSR 的私钥
3.中间证书/链文件（由 CA 提供）
Cloudera 建议不要使用自签名证书。如果使用自签名证书，则必须在注册时使用该参数 Navigator 使用密钥受托人服务器进行加密。这将跳过 TLS 主机名验证，可能会出现某些网络级攻击。
浏览器要求
Cloudera Manager、Cloudera Navigator 和 Hue 在两个最新的LTS（long term support） 或 ESR（扩展支持版本）浏览器上受支持。Cookie 和 JavaScript 必须 启用。
重要：要查看 Hue Web UI 中的所有图标，使用 IE 和 HTTPS 的用户必须添加负载平衡器。
· Chrome： 63 、
· Firefox： 59
· Safari（仅限 Mac）
· Internet Explorer： 11
· Microsoft Edge： 41
这篇关于物联网架构之CDH详解的文章就介绍到这儿，希望我们推荐的文章对编程师们有所帮助！
