💝💝💝欢迎来到我的博客,很高兴能够在这里和您见面!希望您在这里可以感受到一份轻松愉快的氛围,不仅可以获得有趣的内容和知识,也可以畅所欲言、分享您的想法和见解。
推荐: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