【CDH大数据环境搭建文档】

1. CDH版本大数据组件
   CDH是Apache Hadoop和相关项目中最完整、最稳定的、经过测试和最流行的发行版。Cloudera Manager是用于管理CDH集群的B/S应用程序。
   1.1.优点
   统一化的可视化界面 自动部署和配置，大数据各类组件(hadoop、hive、hue、kudu、impala、zookeeper等)安装、调优极其便捷 零停机维护（免费版本不具有弹性升级）
   多用户管理（权限控制）
   稳定性极好（部分优化措施都已经调整好）
   
   1.2.缺点

• server和agent需要占用额外的内存和cpu(server占用内存为2G，agent占用内存1G，总共cpu为0.5核)
• 对linux常用命令需要了解颇深 对hadoop的apache版本有一定的安装经验和调优经验

2.ClouderaManager介绍
Cloudera Manager是用于管理CDH群集的B/S应用程序。Cloudera Manager通过对CDH集群的每个部分提供细粒度的可视性和控制来设置企业部署的标准，使运营商能够提高性能，提高服务质量，提高合规性并降低管理成本。
使用Cloudera Manager，可以轻松部署和集中操作完整的CDH堆栈和其他托管服务（Hadoop、Spark、Kudu、Impala）。其特点：应用程序的安装过程自动化，将部署时间从几周缩短到几分钟; 并提供运行主机和服务的集群范围的实时监控视图; 提供单个中央控制台，以在整个群集中实施配置更改; 并集成了全套的报告和诊断工具，可帮助优化性能和利用率。
3.ClouderaManager应用场景
适用于节点在5个以上、或各类大数据服务超过5个的集群，小公司用到的服务较少时，为了节省服务器等资源，不需要部署cm。
适用于所有的专业大数据公司，这类企业的硬件资源一般都比较充足。
适用于运维人员，因为该平台安装好以后，维护工作相对来将就轻松许多，例如：使用apache版本的运维人员，对某一个组件进行调优，需要消耗半天的时间进行调整，效率极低；再比如安装1000个节点，需要手动部署，工作量可想而知。
适用于对于大数据组件版本不需要经常变动的公司，例如：有些公司就是喜欢钻研新技术，然后喜欢新版本，但是由于cm的免费版本不支持弹性升级，所以不建议喜欢新技术的公司用。收费版本除外。

补充：
cm在国内用户量很大，戴尔、一号店等知名公司都在使用
cm在主流的大数据平台框架中，用户量比例很高

4.ClouderaManager架构
1.Server：Cloudera Manager的核心是Cloudera Manager Server。提供了统一的UI和API方便用户和集群上的CDH以及其它服务进行交互，能够安装配置CDH和其相关的服务软件，启动停止服务，维护集群中各个节点服务器以及上面运行的进程。
2.Agent：安装在每台主机上的代理服务。它负责启动和停止进程，解压缩配置，触发安装和监控主机
3.Management Service：执行各种监控、报警和报告功能的一组角色的服务
4.Database：CM自身使用的数据库，存储配置和监控信息
5.Cloudera Repository：云端存储库，提供可供Cloudera Manager分配的软件
6.Client：用于与服务器进行交互的接口，包含Admin Console和API
(1)Admin Console：管理员可视化控制台
(2)API：开发人员使用API可以创建自定义的Cloudera Manager应用程序

5.ClouderaManager功能
5.1信号检测
默认情况下，Agent 每隔 15 秒向 Cloudera Manager Server 发送一次检测信号。但是，为了减少用户延迟，在状态变化时会提高频率。
5.2状态管理
模型状态捕获什么进程应在何处运行以及具有什么配置。
运行时状态是哪些进程正在何处运行以及正在执行哪些命令（例如：重新平衡HDFS或执行备份/灾难恢复计划或集群升级、停止）。
当更新配置（例如Hue Server Web 端口）时，相当于更新了模型状态。但是，如果 Hue 在更新时正在运行，则它仍将使用旧端口。当出现这种不匹配情况时，角色服务会标记为“过时的配置”。要重新同步，需重启角色服务（这会触发重新生成配置和重启进程）。
特殊情况如果要加入一些cloudera manager控制台没有的属性时候，都在高级配置选项里面嵌入。
5.3配置管理
例如使用HDFS，/opt/cloudera/parcels/CDH/lib/hadoop/etc/hadoop目录下仅包含与HDFS Client相关的配置。
而HDFS Server角色实例（例如：NameNode 和 DataNode）会从/var/run/cloudera-scm-agent/process/812-hdfs-NAMENODE、820-hdfs-DATANODE 下的每个进程专用目录获取它们的配置，真正产生作用的是这个。
使用CM进行配置时，大多都是在可视化界面中操作。
5.4主机管理
Cloudera Manager 作为群集中的托管主机身份，可对JDK、Cloudera Manager Agent、CDH、Impala、Solr 等所有软件角色的主机进行管理。
Cloudera Manager 提供添加和删除主机的操作。
Cloudera Management Service Host Monitor 角色执行状况检查并收集主机度量，可以监控主机的运行状况和性能。
5.5进程启停
在Cloudera Manager管理的群集中，只能通过 Cloudera Manager 启动或停止服务。Cloudera Manager 支持自动重启崩溃进程。如果一个角色实例在启动后反复失败，Cloudera Manager 还会用不良状态标记该实例。
特别需要注意的是，停止 Cloudera Manager 和 Cloudera Manager Agent 不会停止群集；所有正在运行的实例都将保持运行。
Agent的一项主要职责是启动和停止进程。当Agent从检测信号检测到新进程时，Agent 会在 /var/run/cloudera-scm-agent 中为进行创建一个目录，并解压缩配置文件。
Agent也会受到监控，属于Cloudera Manager的主机监控的一部分：如果 Agent 停止发送检测信号，主机将被标记为运行状况不良。
5.6监控管理
Activity Monitor： 收集关于MapReduce服务运行的活动的信息。默认情况下不添加此角色。
Host Monitor： 收集有关主机的运行状况和指标信息。
Service Monitor： 从YARN服务中收集关于服务和活动信息的健康和度量信息。
Event Server： 聚合组件的事件并将其用于警报和搜索。
Alert Publisher ： 为特定类型的事件生成和提供警报。
Reports Manager：生成图表报告。

6.集群资源规划
6.1 业务集群规划思路
一般而言，一个集群上很少只跑一个业务，大多数情况都是多个业务共享集群，实际上就是共享系统软硬件资源。
这里通常涉及两大问题，其一是业务之间资源隔离问题，就是将各个业务在逻辑上隔离开来，互相不受影响，这个问题产生于业务共享场景下一旦某一业务一段时间内流量猛增必然会因为过度消耗系统资源而影响其他业务；其二就是共享情况下如何使得系统资源利用率最高，理想情况下当然希望集群中所有软硬件资源都得到最大程度利用。
因为业务隔离场景是不尽相同的，这里主要针对后者进行讲解：使得集群系统资源最大化利用，那首先要看业务对系统资源的需求情况。经过对线上业务的梳理，通常可将这些业务分为如下几类：
1．硬盘容量敏感型业务：这类业务对读写延迟以及吞吐量都没有很大的要求，唯一的需要就是硬盘容量。比如大多数离线读写分析业务，上层应用一般每隔一段时间批量写入大量数据，然后读取也是定期批量读取大量数据。特点：离线写、离线读，需求硬盘容量
2．带宽敏感型业务：这类业务大多数写入吞吐量很大，但对读取吞吐量没有什么要求。比如日志实时存储业务，上层应用通过kafka将海量日志实时传输过来，要求能够实时写入，而读取场景一般是离线分析或者在业务遇到异常的时候对日志进行检索。特点：在线写、离线读，需求带宽
3．IO敏感型业务：相比前面两类业务来说，IO敏感型业务一般都是较为核心的业务。这类业务对读写延迟要求较高，尤其对于读取延迟通常在100ms以内，部分业务可能要求更高。比如在线消息存储系统、历史订单系统、实时推荐系统等。特点：在（离）线写、在线读，需求内存、高IO介质
4．对于CPU资源，HBase本身就是CPU敏感型系统，主要用于数据块的压缩/解压缩，基本所有业务都对CPU有共同的需求，而单纯的HDFS存储对CPU要求不高
一个集群想要资源利用率最大化，一个思路就是各个业务之间‘扬长避短’，合理搭配，各取所需。实际上就是上述几种类型的业务能够混合分布，建议不要将同一种类型的业务太多分布在同一个集群。因此一个集群理论上资源利用率比较高效的配置为：硬盘敏感型业务 ＋ 带宽敏感型业务 ＋ IO敏感型业务。
另外，集群业务规划的时候除了考虑资源使用率最大化这个问题之外，还需要考虑实际运维的需求。建议将核心业务和非核心业务分布在同一个集群，强烈建议不要将太多核心业务同时分布在同一个集群。这主要有两方面的考虑：
1．一方面是因为核心业务共享资源必然会产生竞争，一旦出现竞争无论哪个核心业务出现问题都不是我们愿意看到的；
2．另一方面在特殊场景下方便运维童鞋进行降级处理，比如类似于淘宝双十一这类大促活动，某个核心业务预期会有很大的流量涌入，为了保证核心业务的平稳，在资源共享的情况下只能牺牲其他非核心业务，在和非核心业务方充分交流沟通的基础上限制这些业务的资源使用，在流量极限的时候甚至可以直接停掉这些非核心业务。试想，如果是很多核心业务共享集群的话，哪个核心业务愿意轻易让路？
6.2真实集群规划

Hadoop 集群实际上就是在一组通过网络连接的物理计算机组成的集群上安装部署Hadoop 相关的软件。所以，Hadoop 集群规划包括两大模块：
(1)物理集群规划
(2)软件集群规划
根据实际业务需求，确定哪些软件运行在哪些物理机上，最终以一个整体来对外提供大数据的相关服务。

6.2.1物理集群规划
Hadoop 物理集群规划主要解决的两个问题：
（1）准备什么样的物理计算机？——机器选型
（2）准备多少台物理计算机？——集群规模
6.2.1.1机器选型
（1）小型机：价格在百万级别以上，成本太高，Hadoop 的初衷是致力于运行在廉价的机器之上，
这违背了 Hadoop 的初衷。所以不推荐使用。
（2）PCServer：综合考虑价格和性能，这是第一选择。
（3）云主机（比如阿里云、腾讯云）：一般创业初期的互联网公司会选用，因为资金不足，
且数据量是逐步增大，可以采用此方式。
（4）普通 PC：稳定性不好，可用于实验环境。
（5）虚拟机：无奈，学习使用。
总结：
(1)企业开发环境物理集群优选 PCServer
(2)学习实验环境物理集群优选虚拟机
6.2.1.2集群规模
影响集群规模的因素：
(1)功能性需求
1)解决数据量的存储问题（集群的硬盘）
数据量包括现有的全量数据、一定时期内的增量数据、数据的副本个数、临时数据、
日志数据、安装包等等。
2) 解决不同级别数据量的计算效率问题（集群的CPU和内存、磁盘IO）
比如对 100GB 数据做简单的查询分析需要 3-5 分钟得到结果。
比如对 100GB 数据做复杂的表连接、计算、排序分析需要 30 分钟左右
比如业务数据的增量导入和数据清洗在 1 小时之内完成。
(2)每台计算机的资源配置（内存、CPU、硬盘、网络）
(3)非功能性需求

1. 可靠性需求
2. 可用性需求
3. 容错性需求
   总结：
   根据实际业务需求的不同，企业物理集群规模大小也各不相同。几台、十几台、几十台、成百上千台的都有。
   目前先部署三个节点的分布式集群。

6.2.2软件集群规划
涉及到软件选型，及之后的主机规划。
6.2.2.1软件选型
即选择使用什么样的软件？哪个版本？是否稳定？各个软件之间是否兼容？
项目软件选型：
jdk：Jdk1.8
Scala2.11.8
CDH 6.2.1： zookeeper-3.4.5-cdh6.2.1、hadoop-3.0.0-cdh6.2.1，hive-2.1.1-cdh6.2.1、hue-4.3.0-cdh6.2.1
spark-2.4.0-cdh6.2.1
sqoop-1.4.7-cdh6.2.1
Mysql 5.7
kafka_ 2.11-2.2.0
elasticsearch 6.4.0
6.2.2.2主机规划
主机规划即哪台机器上部署哪些软件。

总结：
（1）单节点集群是把所有软件都部署在同一台机器上
（2）分布式集群是按照主机规划把对应的软件部署在对应的机器上

6.3测试集群
目标：部署三个节点的 Hadoop 集群
任务：
（1）安装三台虚拟机——Hadoop 物理集群部署
（2）在虚拟机上安装 Hadoop——Hadoop 软件集群部署

7.CM集群环境准备
7.1.Linux虚拟机环境

7.2 CM前置工具
7.2.1下载包
7.2.1.1 CDH包
下载地址： https://archive.cloudera.com/cdh6/6.2.1/parcels/

只需要下载对应系统下的包即可，我们使用的是Centos7，所以只需要下载后缀为el7的三个包即可。
在资料中已下载好：Home\资料\下载文件\cdh6。

7.2.1.2 CM包
下载地址： https://archive.cloudera.com/cm6/6.2.1/redhat7/yum/RPMS/x86_64/

路径下的六个包都需要下载。
在资料中已下载好：Home\资料\下载文件\cm6。

7.2.1.3 秘钥文件
下载地址： https://archive.cloudera.com/cm6/6.2.1/

在资料中已下载好：Home\资料\下载文件\allkeys.asc。

7.2.2安装依赖包
如果不提前安装这些依赖包，在后面安装CM的时候可能会出现异常。

yum install -y cyrus-sasl-plain cyrus-sasl-gssapi portmap fuse-libs bind-utils libxslt fuse
yum install -y /lib/lsb/init-functions createrepo deltarpm python-deltarpm
yum install -y mod_ssl openssl-devel python-psycopg2 MySQL-python

可以三台虚拟机同时进行安装。

7.2.3安装httpd
只需要在部署本地yum源的机器上安装即可，不用三台全部安装。

yum install httpd
yum install createrepo

7.2.4配置host
7.2.4.1 linux
每一台linux服务器都需要进行配置：

vim /etc/hosts
192.168.52.150 hadoop01
192.168.52.151 hadoop02
192.168.52.152 hadoop03
192.168.52.153 hadoop04

7.2.4.2 windows
打开hosts文件：【C:\Windows\System32\drivers\etc\hosts】
添加一下内容：

192.168.52.150 hadoop01
192.168.52.151 hadoop02
192.168.52.152 hadoop03

7.2.5关闭防火墙
三台都要执行。

查看防火墙状态： 				systemctl status firewalld.service
绿的running表示防火墙开启
执行关闭命令： 				systemctl stop firewalld.service
再次执行查看防火墙命令：		systemctl status firewalld.service
执行开机禁用防火墙自启命令  ： 	systemctl disable firewalld.service

完成

7.2.6关闭selinux
三台都要执行。

#临时生效
setenforce 0

#永久生效
#将SELINUX=enforcing改为SELINUX=disabled
vim /etc/selinux/config

#在配置文件中第一次设置时需要重启服务器
reboot

7.2.7安装httpd服务
因为在实际的生产环境中，很有可能是不能联网的，或者从外网下载的速度较慢。这时我们通过本地的镜像来进行安装，效率会大大提升。
只在第一台服务器执行即可。

#前面已执行过
yum install httpd -y

#启动httpd服务
systemctl start httpd.service

#进入域名根目录
cd /var/www/html/
#需要创建和官网路径一致的目录，yum安装时才能够正确的找到
mkdir -p cm6/6.2.1/redhat7/yum/RPMS/x86_64/

上传cm6中的文件到目录：/var/www/html/cm6/6.2.1/redhat7/yum/RPMS/x86_64/：

上传allkeys.asc文件到目录：/var/www/html/cm6/6.2.1/：

访问测试：http://hadoop01/cm6/6.2.1/redhat7/yum/RPMS/x86_64/

7.2.8生成repodata目录
只在第一台服务器执行即可。

可以看到在官网的地址中，有一个repodata目录，而我们新搭建的http服务中是没有的。此文件夹是不能直接复制的，需要使用脚本生成出来，是对现有文件结构的描述。如果http中的文件内容有变更，需要删除后重新生成repodata目录，以在web中生效。

cd /var/www/html/cm6/6.2.1/redhat7/yum
createrepo .

访问web链接，确认repodata目录已存在：

7.2.9配置本地yum源
只在第一台服务器执行即可。

cd /etc/yum.repos.d/
vim cloudera-manager.repo
[cloudera-manager]
name=Cloudera Manager
baseurl=http://hadoop01/cm6/6.2.1/redhat7/yum/
gpgcheck=0
enabled=1

yum clean all
yum list | grep cloudera

7.2.10创建cloudera-scm用户
centos7要求必须有，centos6没有要求，每一台服务器都需要执行。

useradd cloudera-scm
passwd cloudera-scm
pwd: test123456
#免密钥登录
echo "cloudera-scm ALL=(root)NOPASSWD:ALL" >> /etc/sudoers
#测试用户
su - cloudera-scm
exit

7.2.11安装mysql服务
安装Mysql后续作为元数据库使用。
只在第一台安装即可。
7.2.11.1下载repo，并安装mysql-server
安装mysql服务

wget -c -i http://dev.mysql.com/get/mysql57-community-release-el7-11.noarch.rpm
yum -y install mysql57-community-release-el7-11.noarch.rpm
yum -y install mysql-community-server

这个步骤需要网络，并根据网速会花些时间，安装完成后会覆盖之前的mariadb。
如果提示-bash: wget: 未找到命令，则先运行：

yum -y install wget

问题描述
The GPG keys listed for the “MySQL 5.7 Community Server” repository are already installed but they are not correct for this package.
Check that the correct key URLs are configured for this repository.
Failing package is: mysql-community-server-5.7.37-1.el7.x86_64
GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-mysql
原因分析：
版本问题 今年2022 明年2023
解决方案：

rpm --import https://repo.mysql.com/RPM-GPG-KEY-mysql-2022

7.2.11.2 mysql设置

启动：
systemctl start mysqld.service
查看运行情况：
systemctl status mysqld.service

7.2.11.3登录mysql
查看mysql密码

grep "password" /var/log/mysqld.log

登录mysql

mysql -uroot -p

7.2.11.4修改密码
取消mysql密码规范限制

set global validate_password_policy=0;
set global validate_password_length=1;

重设密码

alter user 'root'@'localhost' identified by '123456';
flush privileges;

7.2.11.5卸载repo包
此时还有一个问题，因为安装了yum repository，以后每次yum都会自动更新，耗费时间，所以卸载掉：

yum -y remove mysql57-community-release-el7-10.noarch

7.2.11.6安装mysql

create database scm DEFAULT CHARACTER SET utf8;
grant all PRIVILEGES on *.* TO 'root'@'%' IDENTIFIED BY '123456' WITH GRANT OPTION;
grant all PRIVILEGES on *.* TO 'root'@'localhost' IDENTIFIED BY '123456' WITH GRANT OPTION;
grant all PRIVILEGES on *.* TO 'root'@'hadoop01' IDENTIFIED BY '123456' WITH GRANT OPTION;
flush privileges;