CDH 6.3.2 集群部署实战：从零到一构建企业级大数据平台

1. 企业级大数据平台部署前的关键考量

第一次接触CDH集群部署时，我完全低估了生产环境与测试环境的差异。记得有次凌晨三点还在处理因为透明大页配置不当导致的集群性能问题，这种教训让我深刻认识到前期准备的重要性。企业级部署不是简单的软件安装，而是需要从硬件选型到系统调优的全方位规划。

服务器配置需要根据业务规模合理设计。以我们这次部署为例，3台物理机构成的最小集群配置如下：

• 计算节点：双路Xeon Gold 6230（20核/40线程）×2 | 256GB DDR4 | 2×800GB SSD（RAID1）+6×4TB HDD（RAID5）
• 网络配置：万兆光纤网卡×2（bonding模式4）
• 存储规划：/opt目录挂载SSD用于系统盘，/data目录使用HDD阵列存放HDFS数据

操作系统环境需要特别注意内核版本兼容性。实测发现CentOS 7.6（内核3.10.0-957）与CDH 6.3.2的适配性最佳，新版本内核反而可能引发KSM（Kernel Samepage Merging）冲突。建议在装机时就做好以下配置：

# 禁用不必要的内核模块 echo "install firewire /bin/false" >> /etc/modprobe.d/blacklist.conf echo "blacklist mei" >> /etc/modprobe.d/blacklist.conf

2. 生产环境系统调优实战指南

2.1 网络与安全基础配置

集群节点间的通信效率直接影响HDFS和YARN性能。我们采用双网卡绑定模式增强容错能力，配置过程比标准文档复杂得多：

# 创建bonding接口 nmcli con add type bond con-name bond0 ifname bond0 mode 802.3ad # 添加从属接口 nmcli con add type bond-slave ifname eth0 master bond0 nmcli con add type bond-slave ifname eth1 master bond0 # 设置MTU值 nmcli con mod bond0 802-3-ethernet.mtu 9000

安全策略需要平衡防护与性能。除了常规的防火墙关闭，更要关注SELinux的彻底禁用——部分Hadoop组件在Enforcing模式下会出现诡异的权限问题。必须检查两个关键文件：

# 确认/etc/sysconfig/selinux内容 SELINUX=disabled SELINUXTYPE=targeted # 检查/boot/grub2/grub.cfg中是否有selinux=0参数

2.2 内存与存储优化技巧

透明大页（THP）是Hadoop集群的"隐形杀手"。某次性能测试中，关闭THP后MapReduce作业速度提升了37%。永久生效的配置方法如下：

# 创建systemd服务单元 cat > /etc/systemd/system/disable-thp.service <<EOF [Unit] Description=Disable Transparent Huge Pages [Service] Type=simple ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled && echo never > /sys/kernel/mm/transparent_hugepage/defrag" [Install] WantedBy=multi-user.target EOF systemctl daemon-reload systemctl enable --now disable-thp

交换分区配置需要特别注意swappiness值的动态调整。我们发现设置为1（而非文档推荐的10）能更好避免GC停顿：

# 动态生效 sysctl vm.swappiness=1 # 持久化配置 echo "vm.swappiness=1" >> /etc/sysctl.conf

3. 离线环境下的CDH部署秘籍

3.1 私有Yum源搭建的隐藏陷阱

在内网部署时，Apache httpd服务对.parcel文件的处理有个坑——默认会添加错误的Content-Encoding头。除了修改mime类型，还需要调整httpd的压缩配置：

# 在/etc/httpd/conf.d/compression.conf中添加 SetEnvIfNoCase Request_URI \.parcel$ no-gzip dont-vary

createrepo命令的--update参数能极大提升仓库维护效率。当需要追加新RPM包时，使用以下命令可以避免重建整个元数据库：

createrepo --update /var/www/html/cdh6.3.2/CM6.3.1/

3.2 Parcel分发优化方案

Parcel文件的校验过程经常成为安装流程的瓶颈。通过预生成hash文件可以节省50%以上的部署时间：

# 手动生成校验文件 sha1sum CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel | awk '{print $1}' > CDH-6.3.2-1.cdh6.3.2.p0.1605554-el7.parcel.sha

对于大规模集群，建议配置Parcel的本地缓存服务器。我们在每个机架部署一个Nginx缓存节点，使分发速度提升3倍：

# Nginx配置片段 proxy_cache_path /data/parcel_cache levels=1:2 keys_zone=parcel:10m inactive=30d use_temp_path=off; server { location /cdh6.3.2 { proxy_cache parcel; proxy_pass http://源服务器IP; } }

4. CM集群配置的黄金法则

4.1 数据库连接的最佳实践

MySQL连接池配置不当会导致CM Server频繁崩溃。经过多次压测，我们总结出这些关键参数：

# /etc/cloudera-scm-server/db.properties追加 com.cloudera.cmf.db.connections.max=50 com.cloudera.cmf.db.connections.min=5 com.cloudera.cmf.db.connection.timeout=30000

JDBC驱动放置位置有讲究。不仅需要放在/usr/share/java，还要确保软链接命名正确：

ln -sf /usr/share/java/mysql-connector-java.jar /usr/share/java/mysql.jar

4.2 服务角色分配的平衡艺术

角色分配不是简单的均匀分布，而要考虑硬件特性。我们的经验配置方案：

• 主节点：运行HDFS NameNode、YARN ResourceManager、ZooKeeper等控制面服务
• 计算节点：部署NodeManager、DataNode同时预留30%资源给Impala
• 边缘节点：运行Hue、Oozie等对外服务

关键配置项常被忽略：

<!-- yarn-site.xml 优化 --> <property> <name>yarn.nodemanager.resource.cpu-vcores</name> <value>物理核心数×0.7</value> </property> <property> <name>yarn.nodemanager.resource.memory-mb</name> <value>总内存×0.8</value> </property>

5. 避坑指南：那些官方文档没告诉你的

时钟同步问题可能引发HBase region分裂异常。Chrony配置需要增加关键参数：

# /etc/chrony.conf 追加 makestep 1.0 3 local stratum 10

文件描述符限制不能只改limits.conf。系统服务需要单独配置，比如ZooKeeper必须增加：

# /etc/systemd/system/zookeeper.service.d/limits.conf [Service] LimitNOFILE=65536

最隐蔽的坑是内核参数fs.aio-max-nr的限制。当Kudu服务报错"Failed to open thread pool"时，需要调整：

echo "fs.aio-max-nr=1048576" >> /etc/sysctl.conf