6.1 集群规划与部署

6.1 集群规划与部署

本节摘要：集群规划回答三个问题：要多大（容量估算）、角色怎么摆（布局）、怎么上线（部署与验收）。本节给出从业务数据量倒推机器配置的估算方法、主从角色分布的布局原则、上线前的检查清单，以及几类"上线后才发作"的典型规划错误。

从业务量倒推容量

规划不是从机器开始，是从数据开始。假设业务每天新增 2 TB 原始数据、保留三年、副本因子 3、还要留 30% 余量给中间结果与临时文件：

原始存量 = 2TB × 365 × 3 ≈ 2.2 PB
× 副本因子3     → 6.6 PB
× 余量1.3       → 约 8.6 PB 有效容量需求
​

再算节点数。单台 12 块 8TB 盘的 DataNode 提供约 96 TB 裸容量，考虑文件系统与坏盘预留实际可用约 85 TB，则 DataNode 数 ≈ 8600 TB / 85 ≈ 100 台。接着验证账本：三年后文件数若达 5 亿（平均文件 13MB——已经偏小，提醒摄入侧要合并），NameNode 元数据约 (5e8 + 7.5e8) × 150B ≈ 19 GB，一台 64 GB 内存的 NameNode 机器可覆盖但需配 HA。

CPU 与内存按角色算。DataNode/NodeManager 同机（计算存储融合，本地性的前提）：每 TB 磁盘配 1–2 GB 容器内存是行业经验值，96 TB 盘配 128–256 GB 内存、双路 CPU 共 48–64 vCore。NameNode 独占：内存按账本 +4 GB 堆余量，64 GB 起。ResourceManager 独占：调度是单线程热点，高主频强于多核，32 GB 内存足够。HBase RegionServer 若部署（5.3 节共置原则），每节点再留 32–48 GB 堆外内存并打节点标签（4.3 节）。

💡 规划的第一性检查：算出的"磁盘 : 内存 : CPU"比例是否符合你的负载画像。IO 密集（日志分析）堆盘；计算密集（特征工程）堆核；HBase 在线则内存优先。同一配比打天下是预算浪费的开始。

角色布局：四类机器、三个原则

主控机 ×2      NameNode主备 + JournalNode之一        64GB 内存
资源机 ×2      ResourceManager主备 + 作业历史         32GB 高主频
工控机 ×N      DataNode + NodeManager（+RegionServer）128-256GB
协调机 ×3-5    ZooKeeper + JournalNode               轻量但要求低延迟盘
​

三条布局原则。主控与数据分离：NameNode/RM 绝不与重负载任务同机——一次夜批把主控机 CPU 打满，心跳处理延迟，全集群误判下线（2.1 节副本风暴的另一种成因）。JournalNode 与 ZooKeeper 共 3 或 5 台、跨机架分布：法定人数容忍 1 或 2 台故障，放同一机架等于白配。网络比磁盘重要：每台工控机至少 2 × 10GbE（一份数据一份管理），机架上联要按"峰值 Shuffle 流量 = 节点数 × 单节点网卡 × 0.3"预估，上联不足时 3.3 节的拉取阶段会先撞墙。

部署：从裸机到验收

大规模集群用 Ambari 或 Cloudera Manager 等管理平台装（向导式装、配、起），小集群手工部署的流程与 1.3 节伪分布式同构，多了三件事：hosts 分发（所有节点写全集群主机名映射）、SSH 免密拓扑（管理机到全节点 + 主控机间互信）、配置分层（core/hdfs/yarn/site 一套全局配置分发到所有节点，用 rsync 或管理平台下发）。

上线后按检查清单验收：

hdfs dfsadmin -report | grep -A3 "Live"
# Live datanodes (100)          ← 全部注册成功

hdfs fsck / -files -blocks      # 根目录整体体检
# Status: HEALTHY  Total blocks: 0

yarn node -list
# Total Nodes: 100
# 每台可用内存与vCore符合规划值

# 机架感知验证：抽样文件的副本应跨机架
hdfs fsck /data/sample.txt -files -locations -racks
# 每块应显示两个机架路径

# 2.2节实验重做一遍：上传300MB文件 验证三副本拓扑
# 3.3节实验重做一遍：跑一个pi估值作业 验证容器分配与本地性
​

四类典型规划错误

错误都在上线后才发作，因此提前列出来。其一，账本没算：小文件摄入管道直接上量，两年后 NameNode 堆内存告警、启动恢复三小时——2.4 节的账要提前算。其二，机架感知缺失：所有节点默认同架，三副本挤在一起，某次机架断电丢数，才发现容错从未存在。其三，网络倒挂：机架上联 10GbE 却给每节点配 25GbE 网卡，Shuffle 一开上联打满，全集群读写抖动。其四，主控共置：图省事把 RM 装在某台重负载 NodeManager 上，夜批时段调度心跳积压，任务分配延迟肉眼可见。四类错误的共同点是验收时都"看起来正常"——容量、拓扑、峰值、隔离，都要用主动检查（本节的命令与第 2 章 fsck 实验）去验证，而不是等故障暴露。

本节要点回顾

• 容量三步倒推：业务量 × 副本 × 余量 → 磁盘总量 → 节点数；同时验算账本内存；
• 比例匹配负载画像：每 TB 磁盘配 1–2 GB 容器内存，IO/计算/内存密集各有侧重；
• 四类机器三个原则：主控分离、法定组件跨机架、网络按 Shuffle 峰值预估；
• 验收主动化：注册数、机架分布、本地性、容器规格逐项用命令验证；
• 四类规划错误（账本、机架、网络、共置）上线时无症状，必须提前设防。

规划立住后，下一节建立日常的观察哨：监控指标体系与调优方法。