1. 为什么还要手动搭一套本地源的大数据平台

离线环境里搞大数据平台，最让人头疼的从来不是装软件本身，而是装到一半发现某个包下不下来。我经历过好几次客户现场完全断网的情况，机房连外网出口都没有，所有依赖必须提前准备好。这种场景下，用本地源来搭建一套完整的大数据平台就是刚需，而 CDH 6.3.0 作为一套成熟稳定的发行版，至今仍有大量企业在生产环境中使用。

这篇文章要聊的，就是怎么从零开始，用本地源手动把 CDH 6.3.0 完整搭起来。所谓“本地源”，就是把所有安装包提前下载到内网某台机器上，配置成 HTTP 或 YUM 源，让集群里所有节点都从这个内网地址拉取依赖。整个过程不依赖任何外部网络，适合完全隔离的机房环境。

适合谁看？如果你手头有几台内网服务器，需要部署一套大数据平台做离线分析、日志处理或者数据仓库，又没法直接连外网，那这套流程你可以直接参考。如果你只是想了解一下 CDH 的架构和组件关系，文章里的原理拆解部分也能帮你理清思路。我会把每一步的操作意图、参数选择理由、踩过的坑都讲清楚，尽量让你少走弯路。

2. 搭建前的整体规划与核心思路

2.1 为什么选本地源而不是在线源

在线源搭建 CDH 当然更省事，yum install直接拉包就行。但实际项目里，尤其是金融、政务、制造这类行业的内网环境，服务器根本不允许访问外网。有些机房即使有代理，带宽也小得可怜，几十个节点同时拉包能把出口堵死。本地源的好处很明显：下载一次，全集群复用；速度是内网千兆甚至万兆，装起来飞快；版本完全可控，不会因为上游源更新导致依赖冲突。

另一个现实问题是，CDH 6.3.0 对应的 Cloudera 官方仓库已经归档，在线源地址随时可能失效。把包提前下载到本地，相当于给自己留了一份永久可用的安装介质。我个人的习惯是，每接手一个新环境，第一件事就是把所有依赖包完整下载到本地 NAS 或者某台管理节点上，后面无论重装多少次都不慌。

2.2 集群角色分配与最小规模建议

CDH 集群的角色大致分三类：管理节点（Cloudera Manager Server + 数据库）、主节点（NameNode、ResourceManager、Hive Metastore 等）、工作节点（DataNode、NodeManager 等）。最小规模的实验环境，三台机器就能跑起来：一台管理节点，一台主节点，一台工作节点。如果资源紧张，管理和主节点可以合并到一台，但生产环境不建议这么做。

我这次演示用的是三台虚拟机，配置如下：

内存低于 8G 的机器跑 Cloudera Manager 会非常卡，这是硬性门槛。磁盘方面，系统盘和数据盘最好分开，数据盘做 RAID 或者多块盘做 JBOD，后面配 HDFS 的时候能直接指定数据目录。

2.3 操作系统与基础环境要求

CDH 6.3.0 官方支持的操作系统包括 RHEL/CentOS 7.x、Ubuntu 16.04/18.04 等。我习惯用 CentOS 7.9，稳定且资料多。安装系统时注意几点：关闭 SELinux，否则后面各种权限问题会让你怀疑人生；防火墙要么关掉，要么提前放行所有需要的端口；主机名必须规范设置，不能用 localhost，因为 Cloudera Manager 靠主机名识别节点。

基础环境还包括：配置好静态 IP、设置 hosts 文件让所有节点能互相解析、关闭透明大页（THP）、调整 swappiness 参数。这些操作看起来琐碎，但每一项没做好都可能导致后面集群启动失败。我见过最典型的问题是 THP 没关，导致 HDFS 写入性能极差，排查了半天才发现是内核参数的问题。

3. 本地源的制作与配置细节

3.1 需要准备哪些安装包

CDH 6.3.0 的安装包分几大类：Cloudera Manager Server 的 RPM 包、Cloudera Manager Agent 的 RPM 包、CDH 的 Parcel 包（这是核心，包含 Hadoop、Hive、Spark 等所有组件）、以及 Cloudera Manager 依赖的数据库驱动和第三方库。

具体来说，你需要从归档地址下载以下内容：

• cloudera-manager-server-6.3.0 的 RPM
• cloudera-manager-daemons-6.3.0 的 RPM
• cloudera-manager-agent-6.3.0 的 RPM
• CDH-6.3.0-1.cdh6.3.0.p0.1279813-el7.parcel
• CDH-6.3.0-1.cdh6.3.0.p0.1279813-el7.parcel.sha
• manifest.json

Parcel 包大概 2G 左右，下载需要一点耐心。下载完成后，把 parcel 文件和对应的 .sha 文件、manifest.json 放在同一个目录下。注意 .sha 文件里的哈希值必须和 parcel 文件匹配，后面 Cloudera Manager 会校验，不匹配会直接报错。

3.2 用 HTTP 服务搭建本地源

本地源最简单的实现方式是用 HTTP 服务。在管理节点上装一个 Nginx 或者 Apache，把存放安装包的目录暴露出来就行。我习惯用 Nginx，配置简单，性能也够。

安装 Nginx 后，创建一个目录比如/var/www/html/cm6，把 Cloudera Manager 的 RPM 包放进去，再创建/var/www/html/cdh6放 Parcel 包。Nginx 默认的站点根目录就是/var/www/html，所以访问http://cm-server/cm6/就能看到 RPM 列表，访问http://cm-server/cdh6/就能看到 Parcel 文件。

这里有个细节：Parcel 文件的权限要设置好，确保 Nginx 进程能读取。我一般直接chmod -R 755整个目录，省事。另外，如果内网有 DNS，给管理节点配一个域名，比如cm.internal，后面配置源地址的时候用域名比 IP 更灵活。

3.3 配置 YUM 源指向本地

在每台节点上创建 YUM 源配置文件，指向管理节点的 HTTP 地址。文件放在/etc/yum.repos.d/下，内容大概是这样：

[cloudera-manager] name=Cloudera Manager 6.3.0 baseurl=http://cm-server/cm6/ enabled=1 gpgcheck=0

gpgcheck=0是因为我们自己的包没有签名，关掉校验避免报错。生产环境如果在意安全性，可以自己签名，但内网环境一般没必要。

配置完成后，执行yum clean all和yum makecache，然后yum list | grep cloudera看看能不能列出包。如果能列出，说明 YUM 源配置成功。这一步看着简单，但经常有人忘了在每台节点上都配，结果装 Agent 的时候只有部分节点能成功。

4. 管理节点的安装与数据库准备

4.1 安装 Cloudera Manager Server

在管理节点上执行yum install cloudera-manager-server，这个命令会自动把 daemons 和依赖的 JDK 一起装上。CDH 6.3.0 自带 OpenJDK 8，不需要额外装 Oracle JDK，省了不少事。

安装完成后，先别急着启动服务。Cloudera Manager Server 需要一个数据库来存储元数据，支持 MySQL、PostgreSQL、Oracle。我用 MySQL 5.7，因为资料最多，坑也最少。在管理节点上装好 MySQL，创建scm数据库和scm用户，授予全部权限。

数据库连接需要 JDBC 驱动，MySQL 的驱动包要放到/usr/share/java/目录下，并改名为mysql-connector-java.jar。这个路径是 Cloudera Manager 默认查找的位置，放错了会报找不到驱动。

4.2 初始化 Server 数据库

Cloudera Manager 提供了一个脚本/opt/cloudera/cm/schema/scm_prepare_database.sh，用来初始化数据库。执行方式如下：

/opt/cloudera/cm/schema/scm_prepare_database.sh mysql scm scm password

参数依次是数据库类型、数据库名、用户名、密码。脚本会自动建表、插入初始数据。如果执行过程中报连接错误，先检查 MySQL 是否允许远程连接、防火墙是否放行 3306 端口。我遇到过 MySQL 默认只监听 127.0.0.1 的情况，改一下bind-address就好。

初始化成功后，启动 Cloudera Manager Server：systemctl start cloudera-scm-server。然后tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log看日志，等到出现Started Jetty server字样，说明服务起来了。这个过程大概需要一两分钟，别急着访问 Web 界面。

4.3 安装并配置 Agent

每台节点都要装 Cloudera Manager Agent，包括管理节点自己。yum install cloudera-manager-agent装完后，编辑/etc/cloudera-scm-agent/config.ini，把server_host改成管理节点的主机名。然后启动 Agent 服务。

Agent 的作用是接收 Server 的指令，在本机执行具体的安装和配置操作。Agent 和 Server 之间通过 7182 端口通信，确保这个端口没有被防火墙挡住。所有节点的 Agent 都启动后，在 Server 的 Web 界面里就能看到待加入的主机列表。

5. 集群部署与 Parcel 分发

5.1 通过 Web 界面添加主机

浏览器访问http://cm-server:7180，默认用户名和密码都是admin。登录后按照向导添加主机，输入所有节点的主机名，Agent 会自动完成心跳注册。如果某台主机没出现，检查 Agent 日志，通常是网络不通或者主机名解析有问题。

主机添加完成后，Cloudera Manager 会自动检查各节点的环境，包括 JDK 版本、Python 版本、磁盘空间等。如果有检查项不通过，按照提示修复。常见的问题是 Python 版本不对，CDH 6.3.0 需要 Python 2.7，CentOS 7 默认就是 2.7，一般没问题。

5.2 配置 Parcel 源地址

在 Cloudera Manager 界面里，进入“主机”->“Parcel”，点击“配置”按钮，把 Parcel 仓库地址改成http://cm-server/cdh6/。然后点击“检查新 Parcel”，Cloudera Manager 会去这个地址下载 manifest.json，列出可用的 Parcel。

找到 CDH 6.3.0 对应的 Parcel，点击“下载”。下载完成后，点击“分配”，Cloudera Manager 会把 Parcel 分发到所有节点并解压。这个过程比较耗时，取决于内网带宽和节点数量。分发完成后，点击“激活”，CDH 就正式生效了。

注意：Parcel 的下载、分配、激活是三个独立步骤，必须按顺序执行。我见过有人下载完就直接点激活，结果报错说 Parcel 未分配。

5.3 集群角色分配与启动

Parcel 激活后，进入“集群”->“添加服务”，按照向导选择要安装的组件。最小规模建议先装 HDFS、YARN、ZooKeeper、Hive、Spark 这几个核心组件。Cloudera Manager 会根据节点数量和角色分配建议自动推荐布局，你可以手动调整。

角色分配有几个原则：NameNode 和 ResourceManager 尽量分开，避免单点压力过大；DataNode 和 NodeManager 通常放在同一批工作节点上；ZooKeeper 至少三个节点，保证选举正常。如果只有三台机器，ZooKeeper 可以和管理节点、主节点混布，但生产环境建议独立。

启动集群后，Cloudera Manager 会逐个启动服务，并检查健康状态。如果有服务启动失败，点击对应的服务查看日志，通常是配置问题或者端口冲突。第一次启动可能会比较慢，耐心等几分钟。

6. 常见问题与排查技巧实录

6.1 Parcel 分发失败怎么办

Parcel 分发失败最常见的原因是磁盘空间不足。Parcel 解压后大概占 3-4G，加上原来的压缩包，每个节点至少需要 10G 空闲空间。如果空间不够，Cloudera Manager 会在日志里报No space left on device。清理一下/opt/cloudera/parcels目录，或者扩容磁盘。

另一个原因是权限问题。Parcel 目录的属主必须是cloudera-scm，如果之前手动改过权限，可能导致 Agent 无法写入。执行chown -R cloudera-scm:cloudera-scm /opt/cloudera修复。

6.2 Agent 心跳丢失怎么排查

Agent 心跳丢失意味着 Server 联系不上某台节点。先在 Server 上ping一下那台节点的主机名，确认网络通。然后登录那台节点，检查 Agent 服务是否在运行：systemctl status cloudera-scm-agent。如果服务挂了，看/var/log/cloudera-scm-agent/cloudera-scm-agent.log里的报错。

我遇到过一种情况：Agent 配置文件里的server_host写的是 IP，但 Server 端配置的是主机名，导致握手失败。统一用主机名就能解决。还有一种情况是时间不同步，Server 和 Agent 的时间差超过 5 分钟，心跳也会断。配好 NTP 服务，让所有节点时间一致。

6.3 数据库连接超时如何处理

Cloudera Manager Server 启动时如果连不上数据库，日志里会报Connection refused或者Access denied。先确认 MySQL 服务在运行，然后检查用户名密码是否正确。如果密码里有特殊字符，在scm_prepare_database.sh脚本里可能需要转义。

MySQL 8.0 的默认认证插件是caching_sha2_password，Cloudera Manager 6.3.0 自带的 JDBC 驱动可能不支持。解决办法是把scm用户的认证插件改成mysql_native_password：

ALTER USER 'scm'@'%' IDENTIFIED WITH mysql_native_password BY 'password';

改完刷新权限，重启 Server 服务。

6.4 服务启动失败的通用排查思路

任何服务启动失败，第一步都是看日志。Cloudera Manager 的日志分两层：Agent 日志在/var/log/cloudera-scm-agent/，具体服务的日志在/var/log/下对应的目录里，比如 HDFS 的日志在/var/log/hadoop-hdfs/。

常见问题包括：端口被占用、目录权限不对、配置文件参数错误、依赖服务没启动。比如 Hive Metastore 启动失败，很可能是 MySQL 驱动没放对位置，或者元数据库没初始化。按照日志提示逐个排查，基本都能解决。

7. 实操心得与性能调优建议

7.1 内存分配的经验值

Cloudera Manager 在分配角色时会给出默认的内存配置，但这些默认值偏保守。根据我的经验，NameNode 堆内存设 4G 起步，DataNode 设 2G，ResourceManager 设 4G，NodeManager 根据机器总内存的 80% 来分配。比如 16G 内存的工作节点，NodeManager 可以给 12G，留 4G 给系统和 DataNode。

Hive Metastore 和 HiveServer2 各给 2G 就够了，Spark 的 Executor 内存根据实际任务调整。这些参数在 Cloudera Manager 界面里都能改，改完重启对应服务生效。

7.2 数据盘挂载与 HDFS 目录规划

HDFS 的数据目录不要放在系统盘，一定要挂独立的数据盘。挂载的时候用noatime选项，减少不必要的元数据写入。如果有多个数据盘，每个盘挂一个目录，然后在 HDFS 配置里把这些目录都列上，DataNode 会自动均衡写入。

目录结构建议统一规划，比如/data1/dfs/dn、/data2/dfs/dn，方便管理和扩容。日志目录也单独挂盘，避免日志写满系统盘导致服务崩溃。

7.3 定期备份 Cloudera Manager 数据库

Cloudera Manager 的数据库存着整个集群的配置和元数据，一旦丢失，重建集群的成本极高。我习惯每天用mysqldump备份一次scm数据库，保留最近 7 天的备份。备份文件放到另一台机器的共享目录里，避免和数据库同盘。

恢复的时候，先停掉 Cloudera Manager Server，导入备份的 SQL 文件，再启动服务。集群的配置和之前完全一致，不需要重新配。

7.4 监控与告警配置

Cloudera Manager 自带的监控功能已经够用，但默认的告警阈值偏宽松。建议把关键指标调严一些，比如 HDFS 磁盘使用率超过 75% 就告警，NodeManager 内存使用率超过 85% 告警。告警方式可以配邮件或者企业内部的告警平台。

另外，Cloudera Manager 的 Activity Monitor 和 Service Monitor 会占用一定资源，如果集群规模小，可以考虑关掉，省点内存。但生产环境建议保留，排查问题的时候很有用。

8. 后续扩展与版本升级的注意事项

8.1 增加节点的方式

集群跑起来之后，扩容是很常见的需求。在 Cloudera Manager 界面里，进入“主机”->“添加主机”，输入新节点的主机名，Agent 会自动注册。然后在新节点上分配 DataNode 和 NodeManager 角色，启动服务，HDFS 会自动做数据均衡。

扩容前记得在新节点上配好 YUM 源和 Agent，确保能连上 Server。数据均衡的过程可能比较慢，可以通过hdfs balancer命令手动触发，调整带宽参数加快速度。

8.2 从 CDH 6.3.0 升级的思路

CDH 6.3.0 之后，Cloudera 的发行版策略发生了变化，后续版本不再叫 CDH。如果要从 6.3.0 升级到更高版本，需要先确认目标版本是否支持原地升级。一般来说，小版本升级（比如 6.3.0 到 6.3.2）可以直接通过 Cloudera Manager 操作，大版本升级建议先在新环境验证，再迁移数据。

升级前务必备份数据库和 HDFS 元数据，升级过程中不要断电或者强制重启。升级完成后，逐个服务检查健康状态，确认没问题再开放给业务使用。

8.3 本地源的长期维护

本地源不是搭一次就一劳永逸的。操作系统打补丁、JDK 升级、组件版本更新，都可能需要更新本地源里的包。我建议每季度检查一次本地源的完整性，把不再使用的旧包清理掉，节省磁盘空间。

另外，把本地源的目录做成只读，避免误操作删掉关键文件。如果条件允许，用两台机器做本地源的高可用，一台挂了另一台顶上，保证集群运维不受影响。

这套本地源搭建 CDH 6.3.0 的流程，我在不同环境里反复用过多次，每次都会遇到一些新的小问题，但整体框架是稳定的。最关键的是把本地源做扎实，后面无论装多少节点、重装多少次，都不会再受网络限制。希望这些经验能帮你在内网环境里顺利把集群跑起来。