在企业级大数据环境中，出于对数据安全性的极高要求或内网物理隔离的限制，在 CentOS 系统上离线部署 Cloudera 平台是一项极具挑战性但又必须掌握的核心技能，成功的离线部署并非简单的软件安装，而是一个系统工程，其核心上文归纳在于：必须构建完美的本地软件源生态，并严格确保操作系统环境与 Cloudera 组件的深度兼容性，只有通过标准化的依赖管理、精准的时间同步以及严谨的数据库配置，才能在无外网连接的环境下搭建出稳定、高效的大数据集群。
系统环境初始化与依赖治理
离线部署的第一步并非立即安装软件，而是对 CentOS 系统进行深度的环境“净化”与标准化,这是后续所有步骤能够顺利进行的基石。
操作系统版本的选择至关重要，对于 Cloudera CDH 6.x 版本，推荐使用 CentOS 7.6 或 7.9，这些版本经过了大量的生产环境验证，兼容性最佳，在安装前，必须彻底关闭 SELinux 和防火墙，虽然这在安全上看似妥协，但在大数据集群内部通信中，防火墙往往会阻断各组件间的心跳检测和数据传输，导致莫名其妙的节点宕机，需要确保主节点与所有从节点之间的 SSH 免密登录配置无误，这是 Cloudera Manager 进行自动化分发和管控的前提。
Java 环境的配置是重中之重，Cloudera 对 JDK 的版本有严格要求，通常推荐使用 Oracle JDK 1.8，在离线环境下，需要提前下载 JDK 的 RPM 包或二进制包，并配置好 JAVA_HOME 环境变量，这里的专业建议是，不要仅仅依赖系统自带的 OpenJDK，在生产环境中，Oracle JDK 的稳定性和性能表现往往更优。
时间同步（NTP）是集群健康的隐形杀手，在离线环境中，必须搭建或指定内网的时间同步服务器，如果各节点间时间偏差超过一定阈值（通常是几十秒），会导致 HDFS 的 NameNode 无法启动，或者 Kerberos 认证直接失败，在部署初期，就必须强制所有节点开启 NTP 服务并校准时间。
构建高可用的本地离线软件源
这是整个离线部署过程中最核心、技术含量最高的环节，Cloudera 的安装主要依赖两类资源：Cloudera Manager 的 RPM 包和 CDH 组件的 Parcel 包。
对于 RPM 包，我们需要在有外网的环境中下载完整的 Cloudera Manager 安装包及其所有依赖，由于 CentOS 的 yum 机制会自动解决依赖关系，但在离线环境下，必须将所有依赖包（如 httpd, postgresql, python 等基础库）提前下载并打包，专业的做法是使用 yumutils 工具的 yumdownloader resolve 命令递归下载所有依赖 RPM，然后使用 createrepo 命令在本地生成元数据，将生成的软件源放置在内网的 HTTP 服务器（如 Nginx 或 Apache）上，并修改所有节点的 /etc/yum.repos.d/ 配置文件,使其指向该内网地址。
对于 CDH 组件的 Parcel 包，策略略有不同，Parcel 是 Cloudera 特有的分发格式，包含了特定版本的 Hadoop、Hive、Spark 等服务，我们需要下载对应版本的 Parcel 包、SHA 校验文件以及 manifest.json 文件，将这些文件同样放置在内网 HTTP 服务的特定目录下，在 Cloudera Manager 的安装向导中,系统会自动扫描该目录。
这里有一个容易被忽视的专业细节：务必校验 Parcel 包的 SHA256 签名，在离线传输过程中，大文件极易出现字节损坏，如果校验失败，Cloudera Manager 会拒绝分发该包，导致安装停滞，本地源搭建完成后，必须进行模拟下载测试，确保文件的完整性和 HTTP 服务的可用性。
数据库配置与核心组件部署
Cloudera Manager 和部分大数据服务（如 Hive Metastore, Activity Monitor, Reports Manager）依赖于外部关系型数据库来存储元数据，在离线环境下，通常选择 MySQL 或 PostgreSQL 作为数据库服务。
在主节点安装数据库服务器，并提前下载好 JDBC 驱动包，安装完成后，需要创建 Cloudera Manager 所需的数据库实例和用户，并授予相应的权限，一个常见的误区是忽略了数据库字符集的设置，必须将字符集设置为 utf8,否则在存储中文注释或特定数据时会出现乱码。
接下来是安装 Cloudera Manager Server 和 Agent，在配置好本地软件源后，直接使用 yum install clouderamanagerserver 和 yum install clouderamanageragent 即可完成安装，关键在于配置文件的修改：Agent 的配置文件 /etc/clouderascmagent/config.ini 中，必须将 server_host 指向主节点的实际 IP 地址，确保 Agent 能与 Server 建立心跳连接。
在 Server 端，需要执行 /opt/cloudera/cm/schema/scm_prepare_database.sh 脚本，该脚本会自动初始化数据库表结构并测试连接，这一步如果报错，通常是因为 JDBC 驱动未放置在正确的目录（通常是 /usr/share/java/）下,或者是数据库防火墙未开放端口。
集群安装流程中的关键节点控制
完成上述准备工作后，即可启动 Cloudera Manager Server 服务（systemctl start clouderascmserver），并通过浏览器访问其 Web 界面（默认端口 7180），接下来的安装向导虽然图形化,但每一步都暗藏玄机。
在“选择主机”阶段，Manager 会通过 Agent 列出所有候选节点，如果某些节点未显示，首先检查 Agent 进程是否启动，其次检查主节点到从节点的 9000 端口是否互通。
在“选择发行版”阶段，系统会提示找不到 Parcel，此时需要手动修改 Parcel 存储库的 URL，将其指向我们之前搭建的内网 HTTP 地址，而不是默认的 archive.cloudera.com 地址,这是离线安装中最关键的转折点。
在“安装 Parcel”阶段，系统会下载、分发和解压，由于是内网传输，速度通常很快，但如果遇到“校验和错误”或“解压失败”，通常是因为之前的 SHA 文件缺失或传输中断，此时需要清理 /opt/cloudera/parcels/ 目录下的缓存文件,重新下载。
在服务配置阶段，对于初次离线部署，建议选择“核心”服务集（HDFS, YARN, Zookeeper, Hive），避免一次性安装过多复杂服务导致排查困难，在 HDFS 配置中，要根据物理机内存大小合理调整 NameNode 的堆内存,防止因内存溢出导致主节点崩溃。
相关问答模块
Q1：在离线安装 Cloudera 时，Parcel 包下载一直卡在 99% 或校验失败怎么办？
A1：这是一个非常典型的问题，通常是因为 Parcel 包在传输过程中损坏，或者对应的 SHA1/SHA256 校验文件未正确放置，解决方法是：首先检查 /opt/cloudera/parcels/ 目录下是否有损坏的 .tmp 或 .parcel 文件并将其删除；确认在本地 HTTP 源目录下，与 Parcel 包同名的 .sha1 或 .sha 文件是否存在且内容正确；在 Cloudera Manager 界面点击“重新下载”,系统会重新校验并解压。
Q2：为什么 Agent 成功安装并启动了，但在 Cloudera Manager 界面上却显示“已丢失”？
A2：这通常是网络或配置问题，检查 Agent 配置文件 /etc/clouderascmagent/config.ini 中的 server_host 是否为主节点的 IP，而不是主机名（DNS 未解析），检查主节点的 7180 端口（Web UI）和从节点到主节点的 9000 端口（Agent 心跳）是否被防火墙拦截，查看从节点 /var/log/clouderascmagent/clouderascmagent.log 日志文件，具体的报错信息会直接指向问题根源，常见的原因包括时间偏差过大或 Python 版本不兼容。
您在离线部署 Cloudera 的过程中，是否遇到过因依赖包缺失而导致的连环报错？欢迎在评论区分享您的排错经验,我们一起探讨更高效的解决方案。
