企业官网建设流程全解析

1. 为什么在离线环境里手动搭建 CDH 6.3.0 依然值得花时间

大数据平台搭建这件事，做过的人都知道，最省事的路径永远是找一套打包好的发行版，点几下鼠标等它自己跑完。但现实里，很多生产环境压根连不上外网，机房里的机器只有内网互通，连个公网 DNS 都没有。这时候你要部署一套 CDH 6.3.0 集群，就只能靠本地源手动来。

CDH 6.3.0 这个版本在大数据圈子里地位比较特殊。它是 Cloudera 合并 Hortonworks 之后推出的一个相对成熟的版本，底层对应的是 Hadoop 3.0 生态，Spark 2.4、Hive 2.1.1、HBase 2.1、Impala 3.2 这些组件都在里面。很多存量项目至今还跑在这个版本上，尤其是那些对稳定性要求高、不愿意频繁升级的团队。所以即便现在新版本层出不穷，CDH 6.3.0 的部署需求依然存在，而且不小。

手动搭建的核心难点不在于安装本身，而在于本地源的制作和依赖关系的梳理。Cloudera 官方提供的 parcel 包和 rpm 包加起来有好几个 G，如果直接拷贝到每台机器上逐个安装，光是依赖冲突就能让你折腾一整天。正确的做法是在内网搭一个统一的本地源，让所有节点通过 HTTP 或者本地 yum 源来获取安装包。这样既能保证版本一致性，又能大幅减少重复下载和依赖解析的时间。

这篇文章适合两类人看：一类是刚接触大数据平台运维、需要独立完成集群部署的工程师；另一类是在离线环境里被 CDH 安装折磨过、想找一套可复现方案的老手。我会从整体设计思路讲起，把本地源制作、依赖梳理、安装配置、问题排查这几个环节拆开揉碎，尽量把每一步背后的逻辑都说清楚。你照着做，大概率能少踩不少坑。

2. 整体方案设计与核心思路拆解

2.1 为什么选择本地源而不是逐台拷贝安装

先说说为什么非要搞本地源。假设你有 10 台机器要装 CDH，每台机器都需要 cloudera-manager-daemons、cloudera-manager-agent、jdk、mysql-connector 这些基础包，再加上 Hadoop 生态的 parcel 包。如果逐台拷贝，你需要保证每台机器上的包版本完全一致，否则就会出现 Agent 连不上 Server、parcel 分发失败等各种诡异问题。而且一旦某个包在传输过程中损坏，排查起来非常费劲。

本地源的好处在于统一入口、统一版本、统一校验。你只需要在一台机器上把所有的 rpm 包和 parcel 包整理好，通过 HTTP 服务暴露出去，其他节点通过 yum 或者 Cloudera Manager 的 parcel 分发机制来获取。这样版本一致性由源来保证，你不需要在每台机器上重复校验。更重要的是，后续如果要在集群里加节点，新节点直接指向同一个源就行，不用再折腾一遍包的分发。

从网络流量角度看，本地源也更有优势。假设你有 20 台机器，每台都要下载 3GB 的 parcel 包，如果走公网就是 60GB 的流量，走内网本地源的话，第一次下载之后后续节点可以直接从内网缓存获取，速度快而且不占公网带宽。对于完全离线的环境，本地源几乎是唯一可行的方案。

2.2 CDH 6.3.0 的组件构成与依赖关系

CDH 6.3.0 的安装包主要分三部分：Cloudera Manager 的 rpm 包、CDH 的 parcel 包、第三方依赖包。Cloudera Manager 是整个集群的管理平台，它本身由 Server 和 Agent 两个核心组件构成。Server 负责 UI、数据库、配置管理，Agent 部署在每台受管节点上，负责执行 Server 下发的指令。

parcel 包是 CDH 的核心，里面包含了 Hadoop、Hive、Spark、HBase、Impala、ZooKeeper 等所有组件的二进制文件。CDH 6.3.0 的 parcel 包大概在 2.5GB 左右，解压后会有 5GB 以上的空间占用。parcel 包的特点是一次分发、多节点共享，Cloudera Manager 会把 parcel 包分发到所有节点的指定目录下，然后通过软链接的方式激活。

第三方依赖包主要包括 JDK、MySQL Connector、Python 相关库等。CDH 6.3.0 官方推荐使用 JDK 8，具体版本是 1.8.0_181 以上。MySQL 用来存储 Cloudera Manager 的元数据以及 Hive、Hue、Oozie 等组件的元数据。这些依赖包如果版本不对，安装过程中会直接报错，所以必须提前准备好。

2.3 离线环境下的网络与主机规划

在动手之前，先把主机规划做清楚。假设我们有一个 5 节点的集群，其中一台作为 Cloudera Manager Server 兼 NameNode，另外四台作为 DataNode 和 NodeManager。所有机器都在同一个内网网段，主机名和 IP 的映射关系提前写进/etc/hosts。

主机名规划有个小技巧：不要用默认的 localhost 或者随机生成的名字，最好用有意义的命名规则，比如cdh-master、cdh-worker01到cdh-worker04。这样后续在 Cloudera Manager 里看节点状态时一目了然。IP 地址建议用静态分配，避免 DHCP 导致 IP 变化后 Agent 失联。

网络方面，需要确保以下几点：所有节点之间可以互相 ping 通；Cloudera Manager Server 的 7180 端口可以被所有节点访问；本地源的 HTTP 端口（比如 80 或者 8080）可以被所有节点访问；MySQL 的 3306 端口只在 Server 节点本地访问即可。如果内网有防火墙，这些端口需要提前放行。

注意：主机名一旦确定，后续不要随意修改。Cloudera Manager 会把主机名和 Agent 的 UUID 绑定，改主机名会导致 Agent 需要重新注册，严重的话需要重装 Agent。

3. 本地源制作与依赖包准备实操

3.1 下载与整理 Cloudera Manager rpm 包

Cloudera Manager 的 rpm 包可以从官方归档地址获取，但离线环境下你需要提前在有网的机器上下载好，然后拷贝到内网。需要下载的包包括：cloudera-manager-daemons-6.3.0-*.rpm、cloudera-manager-agent-6.3.0-*.rpm、cloudera-manager-server-6.3.0-*.rpm，以及可选的cloudera-manager-server-db-2-6.3.0-*.rpm（如果你打算用内置的 PostgreSQL 而不是外部 MySQL）。

下载完成后，把这些 rpm 包统一放到一个目录下，比如/opt/cloudera-local-repo/cm/。然后在这个目录下执行createrepo .命令生成 repodata。如果你的系统没有 createrepo，需要先安装createrepo包，这个包在系统安装镜像里就有，可以通过yum install createrepo安装。

生成 repodata 之后，这个目录就可以作为一个 yum 源来使用了。你可以在/etc/yum.repos.d/下创建一个cloudera-manager.repo文件，内容如下：

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

这里gpgcheck=0是为了简化流程，生产环境建议配置 GPG 校验。baseurl指向的是本地源的 HTTP 地址，后面我们会用 Nginx 或者 Apache 把这个目录暴露出去。

3.2 制作 CDH parcel 包的本地分发源

parcel 包的处理方式和 rpm 包不太一样。parcel 包本身是一个 tar.gz 格式的压缩包，Cloudera Manager 在分发时会校验它的 SHA1 哈希值。所以你需要同时准备好三个文件：CDH-6.3.0-1.cdh6.3.0.p0.1279813-el7.parcel、CDH-6.3.0-1.cdh6.3.0.p0.1279813-el7.parcel.sha1、manifest.json。

这三个文件放到一个目录下，比如/opt/cloudera-local-repo/parcels/。然后修改manifest.json文件，把里面的 parcel 下载地址改成你的本地源地址。这一步很关键，如果不改，Cloudera Manager 会尝试从公网下载，离线环境下就会失败。

修改完成后，同样用 HTTP 服务把这个目录暴露出去。Cloudera Manager 在分发 parcel 时，会先读取manifest.json，然后根据里面的地址去下载 parcel 包。你可以在 Cloudera Manager 的 parcel 配置页面里，把 parcel 分发地址设置成你的本地源地址，比如http://cdh-master/parcels/。

实操心得：parcel 包的 SHA1 文件内容必须和 parcel 包的实际 SHA1 值一致，否则 Cloudera Manager 会报校验失败。你可以用sha1sum命令手动校验一下，确保文件没有在传输过程中损坏。

3.3 第三方依赖包的收集与版本确认

第三方依赖包这块最容易出问题。JDK 建议直接用 Cloudera 官方推荐的oracle-j2sdk1.8，这个包在 Cloudera 的 rpm 源里就有，版本是 1.8.0_181。如果你用系统自带的 OpenJDK，可能会遇到一些兼容性问题，尤其是 Impala 和 HBase 对 JDK 版本比较敏感。

MySQL 的版本建议用 5.7，不要用 8.0。CDH 6.3.0 的元数据表结构对 MySQL 8.0 的支持不够完善，用 8.0 可能会在初始化 Schema 时报错。MySQL Connector 用 5.1.47 版本，这个版本在 CDH 6.3.0 里经过充分测试，兼容性最好。

除了这些，还需要准备python-lxml、python-psycopg2、python-setuptools等 Python 相关包。这些包在系统安装镜像里都有，可以通过yum install直接安装。如果你的环境完全离线，需要提前把这些包下载好，放到本地源里。

3.4 用 HTTP 服务暴露本地源并验证连通性

本地源制作完成后，需要用一个 HTTP 服务把它暴露出去。Nginx 和 Apache 都可以，我个人习惯用 Nginx，配置简单、性能好。安装完 Nginx 后，在/etc/nginx/conf.d/下创建一个cloudera-repo.conf，内容如下：

server { listen 80; server_name cdh-master; root /opt/cloudera-local-repo; autoindex on; location / { try_files $uri $uri/ =404; } }

配置完成后重启 Nginx，然后在浏览器里访问http://cdh-master/cm/和http://cdh-master/parcels/，看看能不能看到文件列表。如果能看到，说明本地源已经正常工作了。

接下来在所有节点上验证 yum 源是否可用。在每台机器上执行yum repolist，看看能不能列出cloudera-manager这个源。如果列不出来，检查一下/etc/yum.repos.d/下的配置文件是否正确，以及网络是否连通。可以用curl http://cdh-master/cm/测试一下 HTTP 连通性。

注意：如果内网有 DNS 服务，建议把cdh-master这个主机名解析到对应的 IP。如果没有 DNS，就在每台机器的/etc/hosts里加上映射关系。不要依赖 NetBIOS 或者 mDNS，这些在服务器环境里不可靠。

4. Cloudera Manager 与 CDH 集群安装全流程

4.1 MySQL 数据库初始化与元数据配置

Cloudera Manager 和 CDH 的很多组件都需要数据库来存储元数据。我们统一用一台 MySQL 实例来承载，建议部署在 Cloudera Manager Server 所在的节点上，或者单独找一台机器。MySQL 安装完成后，需要创建几个数据库和用户。

具体来说，需要创建以下数据库：scm（Cloudera Manager Server 的元数据库）、amon（Activity Monitor）、rman（Report Manager）、hue（Hue）、hive（Hive Metastore）、oozie（Oozie）、sentry（Sentry）。每个数据库对应一个用户，密码自己设定，但要注意密码里不要包含特殊字符，否则在配置文件里需要转义。

创建完数据库后，还需要调整 MySQL 的一些参数。比如max_connections建议调到 1000 以上，innodb_buffer_pool_size根据机器内存调整，一般建议设置为物理内存的 50% 到 70%。另外，MySQL 的默认字符集建议改成utf8，避免中文乱码问题。

CREATE DATABASE scm DEFAULT CHARACTER SET utf8; CREATE DATABASE amon DEFAULT CHARACTER SET utf8; CREATE DATABASE rman DEFAULT CHARACTER SET utf8; CREATE DATABASE hue DEFAULT CHARACTER SET utf8; CREATE DATABASE hive DEFAULT CHARACTER SET utf8; CREATE DATABASE oozie DEFAULT CHARACTER SET utf8; CREATE DATABASE sentry DEFAULT CHARACTER SET utf8; GRANT ALL ON scm.* TO 'scm'@'%' IDENTIFIED BY 'password'; GRANT ALL ON amon.* TO 'amon'@'%' IDENTIFIED BY 'password'; -- 其他数据库类似 FLUSH PRIVILEGES;

4.2 Cloudera Manager Server 与 Agent 的安装配置

在 Server 节点上，通过 yum 安装cloudera-manager-server和cloudera-manager-daemons。安装完成后，需要把 MySQL Connector 的 jar 包拷贝到/usr/share/java/目录下，并重命名为mysql-connector-java.jar。然后执行scm_prepare_database.sh脚本来初始化 Cloudera Manager 的数据库。

这个脚本的用法是：/opt/cloudera/cm/schema/scm_prepare_database.sh mysql scm scm password。执行成功后，会在 MySQL 里创建必要的表结构。如果报错，检查一下 MySQL 的连接信息是否正确，以及 Connector 的 jar 包是否放对了位置。

接下来启动 Cloudera Manager Server：systemctl start cloudera-scm-server。启动过程大概需要一到两分钟，可以通过tail -f /var/log/cloudera-scm-server/cloudera-scm-server.log查看日志。当日志里出现Started Jetty server时，说明 Server 已经启动成功。

然后在所有 Agent 节点上安装cloudera-manager-agent和cloudera-manager-daemons。安装完成后，修改/etc/cloudera-scm-agent/config.ini文件，把server_host改成 Server 节点的主机名。然后启动 Agent：systemctl start cloudera-scm-agent。

实操心得：Agent 启动后会自动向 Server 注册。如果 Server 的 UI 里看不到节点，检查一下 Agent 的日志/var/log/cloudera-scm-agent/cloudera-scm-agent.log，常见问题是主机名解析失败或者 7180 端口不通。

4.3 通过 Web UI 完成集群安装与 parcel 分发

Cloudera Manager Server 启动后，在浏览器里访问http://cdh-master:7180，默认用户名和密码都是admin。登录后会进入安装向导，按照提示一步步操作即可。

第一步是接受许可协议，然后选择 Cloudera Manager 的版本。第二步是选择主机，输入所有 Agent 节点的主机名或者 IP 范围，Cloudera Manager 会自动扫描并列出可用的节点。第三步是选择 parcel 包，这里要选择我们之前准备好的 CDH 6.3.0 parcel，并确保分发地址指向本地源。

parcel 分发过程可能需要几分钟到十几分钟，取决于内网带宽和节点数量。分发完成后，Cloudera Manager 会自动解压并激活 parcel。如果分发失败，检查一下manifest.json里的地址是否正确，以及 HTTP 服务是否正常。

第四步是检查主机环境，Cloudera Manager 会对每台节点进行一系列检查，包括 JDK 版本、Python 版本、网络连通性、时钟同步等。如果有检查项不通过，需要根据提示修复。常见的问题包括：JDK 版本不对、/etc/hosts配置错误、时钟不同步、透明大页未关闭等。

4.4 集群服务分配与启动顺序建议

环境检查通过后，进入服务分配环节。Cloudera Manager 会推荐一套服务组合，包括 HDFS、YARN、ZooKeeper、Hive、Hue、Oozie、Spark、HBase 等。你可以根据实际需求选择，但建议第一次安装时先选核心服务，后续再通过 Cloudera Manager 添加其他服务。

服务分配时要注意角色的分布。NameNode 和 ResourceManager 建议放在不同的节点上，避免单点压力过大。ZooKeeper 建议部署三个节点，保证高可用。Hive Metastore 和 Hue 可以放在 Server 节点上，也可以单独找一台机器。

启动顺序也有讲究。建议先启动 ZooKeeper，再启动 HDFS，然后是 YARN，最后是 Hive、Hue 这些上层服务。Cloudera Manager 会自动处理依赖关系，但你手动启动时要注意这个顺序。如果某个服务启动失败，先看它的日志，再检查依赖的服务是否已经正常运行。

5. 常见问题排查与避坑经验实录

5.1 Agent 无法注册到 Server 的排查思路

Agent 注册失败是最常见的问题之一。表现是 Cloudera Manager 的 UI 里看不到节点，或者节点显示为“未知”状态。排查思路如下：首先检查 Agent 的日志，看有没有明显的报错信息。常见的原因包括：server_host配置错误、7180 端口不通、主机名解析失败、Agent 的 UUID 冲突。

如果日志里显示Connection refused，说明 Agent 连不上 Server 的 7180 端口。可以在 Agent 节点上执行telnet cdh-master 7180测试连通性。如果不通，检查 Server 节点的防火墙设置，以及 Cloudera Manager Server 是否真的在监听 7180 端口。

如果日志里显示Hostname resolution failed，说明主机名解析有问题。检查/etc/hosts文件，确保所有节点的主机名和 IP 映射都正确。另外，/etc/sysconfig/network里的HOSTNAME也要和实际主机名一致。

避坑技巧：如果 Agent 之前注册过，后来重新安装了 Server，可能会出现 UUID 冲突。这时候需要删除 Agent 节点上的/var/lib/cloudera-scm-agent/cm_guid文件，然后重启 Agent，让它重新生成 UUID 并注册。

5.2 parcel 分发失败与校验错误的处理

parcel 分发失败通常有几个原因：本地源地址配置错误、parcel 包损坏、SHA1 校验不通过、磁盘空间不足。排查时先看 Cloudera Manager 的 parcel 页面，里面会有详细的错误信息。

如果是 SHA1 校验失败，重新生成一下.sha1文件，确保内容和 parcel 包的实际 SHA1 值一致。可以用sha1sum CDH-6.3.0-*.parcel命令获取实际值，然后写入.sha1文件。注意.sha1文件里只需要哈希值，不要包含文件名。

如果是磁盘空间不足，检查/opt/cloudera/parcels/目录所在分区的剩余空间。CDH 6.3.0 的 parcel 解压后大概需要 5GB 以上的空间，加上分发过程中的临时文件，建议预留 10GB 以上。

5.3 数据库连接超时与元数据初始化失败

数据库连接问题通常出现在 Cloudera Manager Server 启动或者 Hive Metastore 初始化阶段。表现是服务启动失败，日志里显示Communications link failure或者Access denied。

首先检查 MySQL 服务是否正常运行，以及用户名密码是否正确。可以在 Server 节点上用mysql -u scm -p -h localhost测试连接。如果连接不上，检查 MySQL 的bind-address配置，确保它监听在正确的 IP 上。

如果是Access denied，说明用户名或密码不对，或者该用户没有远程访问权限。检查 MySQL 的user表，确保对应用户的host字段是%或者具体的 IP 地址。如果是Communications link failure，可能是 MySQL 的max_connections太小，或者网络不通。

实操心得：Hive Metastore 初始化时，如果 MySQL 的字符集不是utf8，可能会报Specified key was too long错误。这时候需要修改 MySQL 的字符集配置，然后重新创建数据库。

5.4 时钟同步与透明大页等系统级调优

Cloudera Manager 的环境检查里，时钟同步和透明大页是两个常见的失败项。时钟同步建议用chronyd或者ntpd，确保所有节点的时间偏差在可接受范围内。如果内网没有 NTP 服务器，可以选一台节点作为时间源，其他节点向它同步。

透明大页（THP）建议关闭，因为 Hadoop 生态的很多组件对 THP 比较敏感，开启状态下可能会导致性能下降甚至 OOM。关闭方法是在/etc/rc.local里加上echo never > /sys/kernel/mm/transparent_hugepage/enabled，然后重启或者手动执行一次。

另外，swappiness参数建议调低，比如设置为 1 或者 0，避免系统频繁使用交换分区。文件句柄数也需要调大，建议设置为 65535 以上。这些系统级调优虽然看起来不起眼，但对集群的稳定性和性能影响很大。

# 关闭透明大页 echo never > /sys/kernel/mm/transparent_hugepage/enabled echo never > /sys/kernel/mm/transparent_hugepage/defrag # 调整 swappiness sysctl -w vm.swappiness=1 # 调整文件句柄数 ulimit -n 65535

6. 集群验证与后续扩展建议

6.1 核心服务健康检查与基准测试

集群安装完成后，不要急着上业务，先做一轮健康检查。Cloudera Manager 的首页会显示各个服务的状态，绿色表示正常，黄色表示警告，红色表示异常。如果有红色项，点进去看具体原因。

HDFS 的健康检查可以通过hdfs dfsadmin -report查看 DataNode 的注册情况和磁盘使用率。YARN 可以通过yarn node -list查看 NodeManager 的状态。ZooKeeper 可以通过zkServer.sh status查看每个节点的角色是 Leader 还是 Follower。

基准测试方面，可以用 Hadoop 自带的TestDFSIO测试 HDFS 的读写性能，用TeraGen和TeraSort测试 MapReduce 的性能。这些测试虽然简单，但能帮你快速发现集群的瓶颈，比如磁盘 IO 不足、网络带宽不够等。

6.2 节点扩容与本地源复用技巧

后续如果要扩容，新节点只需要做几件事：配置好主机名和/etc/hosts、安装 Cloudera Manager Agent、指向同一个本地源、启动 Agent 让它自动注册。然后在 Cloudera Manager 的 UI 里把新节点加入集群，分配相应的角色即可。

本地源在扩容时优势明显。新节点不需要重新下载 parcel 包，直接从本地源获取，速度快而且版本一致。如果本地源的 HTTP 服务做了缓存，多节点同时下载时也不会对源服务器造成太大压力。

小技巧：如果集群规模比较大，可以在本地源前面加一层缓存代理，比如用 Squid 或者 Nginx 的 proxy_cache。这样多个节点同时请求同一个 parcel 包时，只需要从源服务器拉取一次，后续请求直接走缓存。

6.3 版本升级与回滚的注意事项

CDH 6.3.0 后续如果有小版本更新，比如 6.3.1 或者 6.3.2，升级时需要注意 parcel 包的兼容性。Cloudera Manager 支持 parcel 的热升级，但升级前一定要备份元数据库和 HDFS 的关键数据。

回滚的话，Cloudera Manager 会保留旧版本的 parcel，你可以通过 UI 切换回旧版本。但要注意，如果元数据已经升级到新版本，回滚时可能需要恢复数据库备份。所以升级前的备份这一步绝对不能省。

我个人在实际操作中的体会是，离线环境搭建 CDH 最耗时的部分不是安装本身，而是前期的包准备和依赖梳理。只要本地源做得好，后面的安装过程其实很顺畅。另外，环境检查阶段的问题一定要耐心解决，不要跳过，否则后面运行时会出各种奇怪的问题。最后再分享一个小技巧：把所有节点的/etc/hosts和 NTP 配置做成一个脚本，新节点直接跑一遍，能省不少事。