企业官网建设流程全解析

前两年我们内部这套大数据集群还保持着典型的“计算贴近存储”混部部署，DataNode 和 NodeManager 装在同一批物理机上，任务调度时优先走本地数据，看起来没毛病，可真到了大促前要扩容，问题一个接一个：扩容的节点要跑数据均衡，快的几个小时，慢的跨天；大促结束后想缩容，又得小心翼翼，生怕挪走计算节点后整个机架没人管数据。

后来我们做了一个决定，把集群逐步切换到存算分离架构，同时把日常运维交给一套自动化平台接管。今天这篇就是从那场改造里沉淀出来的东西。全文围绕存算分离的落地路径、自动化运维平台的设计、弹性伸缩和故障自愈的具体实现来展开，也会把那些真正踩过的坑拿出来说清楚。适合正在做大数据集群建设、考虑存算分离改造，或者在选型运维自动化工具的团队参考，尤其是那些已经被“扩容慢、缩容难、巡检靠人肉”折磨过的朋友。

1. 存算分离落地前，先算清三笔成本账

1.1 数据本地性的权重正在快速下降

过去我们不敢轻易把计算和存储分开，核心原因是“数据本地性”。MapReduce 年代，任务从本机磁盘读数据块，IO 成本最低。DataNode 和 NodeManager 混布，就是为了让任务尽量落在数据所在节点上，减少跨机架网络传输。

但现在集群里的主力框架早就是 Spark、Flink 这些家伙了。它们的计算模式是内存迭代 + 分布式 shuffle，shuffle 本身就需要在节点之间搬数据，本地性只影响“读取源数据”那一段，而且越来越多的做法是先做列式裁剪、谓词下推，从远端读小体量数据也很快。更关键的是，业务方对集群资源的需求越来越“脉冲式”：白天 BI 人员跑临时分析，晚上离线任务集中打，高峰期和低谷期的资源需求差好几倍。混部模式下，存储数据跟计算节点绑死，扩缩容就是一场数据搬迁工程，机器加进去也用不上劲。

存算分离把这个死结解开了：存储层保留 HDFS 或对象存储，计算层变成按需拉起的一批批无状态节点。计算组用完就缩，存储节点不动，数据永远在原地等下一个任务。这个模式对“资源弹性”的收益是实打实的，但也有代价，代价就是网络 IO 预算必须提前规划好。

1.2 网络带宽和副本预算，不能拍脑袋

存算分离之后，任何计算任务读远端数据都走网络。我们改造初期犯过一个错，以为把核心交换机从千兆换成万兆就万事大吉，结果第一个月就出现任务跑批变慢的投诉。

后来我总结了一个非常朴素的估算方法。假设某个计算组要读 10TB 的源数据去做每日例行处理，业务上要求 30 分钟内完成数据读取阶段，那么最小带宽就是：

10TB × 8（转成比特）÷ 1800 秒 ≈ 44.5Gbps

这是理论值。实际网络还有 TCP 开销、重传损耗、并发争抢，你得按理论值的 1.5 到 2 倍去规划，也就是 70Gbps 以上的骨干带宽，才敢在高峰期从容调度任务。我们当时还把计算节点的网卡从 10Gbps 升到了 25Gbps，机架交换机做了堆叠，才算把瓶颈彻底让出来。

副本数也要重新算。传统混部部署下，靠多个副本去匹配本地性，存储成本被默认接受了。存算分离后，副本的职责回归到“保证数据可靠性”本身，如果不涉及跨地域容灾，把默认三副本压到两副本，省下的磁盘非常可观。但要注意，副本降级的前提是机架感知、离线备份、误删保护这些兜底机制全部到位，否则省下的钱会变成运维事故的赔偿金。

1.3 运维平台的设计原点，跟着变了

混部时代，运维平台只要管好“一个节点 = 一堆固定角色”。部署完就长期不动，巡检看磁盘、CPU、内存，出问题重启或换机器。

存算分离之后，计算节点成了“临时公民”。今天在，明天可能就被回收。运维平台必须围绕“实例生命周期”做设计，核心是三个能力：快速注册新节点、按业务标签调度角色、在节点生命周期结束时干净地摘除。存储节点反而变成了更需谨慎对待的资产，它们的角色是永久的，配置变更和版本升级要更加保守。

所以你看，存算分离看似是架构层的决定，实际上把所有压力都转移到了自动化运维平台上。平台是上承业务调度、下接物理资源的关键层，这层做不好，架构再先进也跑不出效果。

2. 自动化运维平台的整体架构与组件选型

2.1 四层架构，职责边界先划清楚

我们最终搭出来的平台，从下往上分四层：资源接入层、执行控制层、状态编排层、观测决策层。

资源接入层负责纳管物理机或云主机，包括主机初始化、Agent 安装、IP 登记、硬件健康检查。这一层最脏最累，却最容易被人忽视。

执行控制层面向具体动作，比如批量执行 Shell、下发配置、启动进程。这一层要尽量屏蔽不同厂商硬件的差异，统一成同一种操作原语。

状态编排层是平台的大脑，管理实例状态机：创建中、健康检查中、运行中、缩容中、已摘除。它决定什么时候该扩容、什么时候该回收，并保证每一步操作之间是幂等的。

观测决策层则是监控、告警、审计和数据可视化，它给编排层提供“判断依据”，也给运维同学提供快速定位问题的入口。

这四层在逻辑上必须独立，实际落地时物理部署可以合并，但代码和权限不能搅在一起。曾经有个平台把“状态判断”逻辑直接写进了执行脚本里，结果脚本一改，所有自动化行为全乱套，这就是架构不清晰的教训。

2.2 工具全家桶的对比：为什么我们没买现成的

做选型时我们认真比过一轮市面上常见的运维自动化工具体系，也考虑过是不是买一个商业化平台更省事。但最后结论是：大数据集群里既有 HDFS/YARN 这种有状态组件，又有 K8s 上跑的无状态业务，定制化程度太高，平台必须能同时兼容“包管理式操作”和“面向终态的编排”，要么深度定制，要么自研核心编排器。

下面这个表格不完全代表工具优劣，只是我们在自己场景里的感受，供参考：

我们的经验是，不需要硬把一个商业化平台里的所有模块都用上。能跑得稳的自动化运维平台都是“攒”出来的，把最适合具体集群的碎片拼在一起，再用一个核心编排器把它们串成整体。

2.3 用“标签 + 实例”的数据模型，替代“IP + 角色”

平台刚设计时，我们走了一段弯路。第一版数据库表结构非常简单，就是几台机器、对应跑什么角色。结果存算分离之后，计算节点经常被拆了重建，角色也会在不同机器间漂移，这种模型直接失灵。

后来改成以“实例”为核心的数据模型。每个实例有全局唯一 ID，然后用标签描述它的属性：属于哪个业务线、哪个集群、哪个计算组、当前生命周期状态。IP 只是这个实例的一个普通字段，不是主键。这样设计之后，无论节点怎么漂移、角色怎么切换，平台都能稳定追踪对象。

实例的生命周期状态机也是后来慢慢补出来的。刚开始我们只区分“运行中”和“停止”，结果在自动扩缩容时频繁出现状态不一致。最后定下来六个状态：创建中、健康检查中、运行中、缩容等待、已摘除、异常。每个状态之间的切换都需要在编排器里显式定义，操作记录全部进入审计日志。状态机是这类平台最容易偷懒的地方，一旦偷懒，后面每个流程都会出奇怪的并发问题。

3. 自动化运维里最容易翻车的三个环节

3.1 弹性扩容触发“启动风暴”，新节点把自己打死

第一次自动扩容事故，发生在凌晨三点。当时离线跑批任务积压，平台检测到后自动拉起 20 个新计算节点。结果 20 个节点同时注册到 YARN ResourceManager，同时开始向 NameNode 拿元数据，又同时从 HDFS 拉取热数据。

NameNode RPC 延迟瞬间飙到几千毫秒，任务全部卡住。平台里的健康检查脚本发现进程异常，直接判定“节点启动失败”，于是重新拉起新节点替换，形成了恶性循环：越不健康越重启，越重启负载越高。

根因很清楚，就是“没有限流，没有批次意识”。

现在我们的扩容策略改成了“小步快跑 + 全局熔断”：每次扩容最多先尝试拉起 5 个节点，等这 5 个节点都通过了健康检查并正常上报心跳，再拉下一批。每拉一批之前，编排器会去查询 NameNode 的 RPC 平均延迟，如果延迟超过了阈值，就暂停扩容并进入冷却时间。冷却时间默认 15 分钟，期间不允许再触发任何扩容动作。

这个改动之后，扩容速度虽然慢了，但再也没有因为扩容把原有集群打挂。真正的大促场景里，我们也会提前预置一部分计算节点，而不是全依赖实时弹性，两条腿走路更稳。

3.2 元数据和配置漂移，让线上跑出“幽灵任务”

存算分离之后，计算节点的生命周期短了，元数据一致性问题反倒比传统架构更突出。

自动化缩容时，我们最初的执行序列很简单：停掉节点上的 NodeManager 进程，然后销毁机器。就这么两步，出了好几次诡异问题。因为 NodeManager 进程被 kill 掉后，YARN 的 ResourceManager 那边还留着它的注册信息，RM 一直尝试往这台已经消失的节点上调度任务，任务反复失败、反复重试，也就是我们遇到的“幽灵任务”。

这个问题的正确解法是“优雅下线”：先摘掉节点上的调度流量，让它不再接收新任务；然后等待存量任务跑完或主动迁移到其他节点；接着再到 ResourceManager 注销这个节点；最后才能销毁实例。每一步都由编排器发指令，而不是直接杀进程。

同样的原则也适用于 HDFS 的 DataNode 下线。传统做法是直接对 DataNode 执行下线命令，让数据块自己迁移走。在存算分离环境里，这种操作必须配合机架感知和网络限速，否则几百 TB 数据同时迁移，很容易把核心交换机打满，拖垮同一时间在跑的所有计算任务。

3.3 自动“自愈”变成“自杀”，判断条件太单一

自愈功能听起来很美好：进程挂了自动拉起来，节点坏了自动替换。但判断条件如果太粗糙，自愈就会变成事故放大器。

我们早期写过一套自愈逻辑：Agent 每 30 秒上报一次心跳，如果连续三次没收到心跳，平台就把这个节点标记为异常，然后自动重启节点进程。有一次底层交换机做例行维护，出现了一次短时间的网络抖动，几台计算节点的 Agent 心跳全部丢失，平台同时把它们全部重启了。

重启期间，这些节点上原本正常跑着的任务全部中断，后续依赖数据全被阻塞，本来只是网络抖动一下，结果半个集群挂了。

后来我们改成了多层确认：心跳丢失只是第一层信号；编排器会再通过另一条网路查询节点的硬件 IPMI 状态，确认机器是不是真的活着；同时让健康检查接口去探测节点上运行的 Spark/Flink 任务是否真的无响应。只有多路信号都确认异常，才会启动故障替换动作。而且每次替换前有一个 120 秒的观察期，给瞬时故障留出恢复窗口，窗口内指标恢复，就取消这次操作。

这套机制的背后就一句话：自动化平台宁可“慢一点判断”，也不要“快一点误杀”。误杀的代价远大于等待几分钟的代价。

4. 资源调度与弹性伸缩的实操细节

4.1 伸缩指标不能只看 CPU，队列积压才是真信号

存算分离的弹性伸缩，最重要的就是定准“伸缩指标”。很多人第一反应是 CPU 使用率超过 80% 就扩容，低于 20% 就缩容。这套规则在纯在线服务场景勉强能用，但在跑批为主的大数据场景，CPU 指标非常滞后。

离线计算任务对资源的需求是阶段性的：某个任务可能在等待资源，CPU 根本没用满；真正体现压力的指标是任务队列长度、平均等待调度时间、以及 YARN 的 pending 容器数量。

我们最终给平台配置了多指标组合判断。主指标是“任务队列积压数”：当积压的离线任务超过 N 个，且持续 5 分钟以上，触发扩容；辅指标包括计算节点的平均 CPU、算力集群的入网流量、以及 NameNode RPC 延迟作为熔断指标。缩容侧同样不能看单点 CPU，而是看整个计算组在最近 30 分钟内的任务完成量与资源使用率。如果资源使用率持续低于 30%，才允许缩容，且每次缩容最多只缩 25%，避免一下缩太多，下一波流量突然来临时又紧急扩容。

4.2 配额治理和混部问题，比伸缩本身更考验平台

存算分离之后，存储是共享的，计算是弹性的。问题就来了：多个业务团队共享同一套存储和资源池，谁都觉得自己“资源不够用”，谁都想要更高的配额。

自动化运维平台必须具备精细的配额治理能力。计算层面，每个业务线有独立资源分组，平台根据 yaml 配置里的分组上限做准入控制。存储层面，每个业务队列有明确的目录配额和生命周期策略，超过阈值的临时数据会被自动清理或者移入冷存储。

有一个细节特别值得提：在线任务和离线任务混跑在一个存储池里时，两者的 IO 优先级必须不同。我们的做法是在接入层给在线任务打高优先级标签，调度器看到这个标签会自动调整 IO 排队权重。没有这层设计，一次离线跑批就可能把在线查询的时延打到不可接受。

4.3 热数据缓存：存算分离不意味着每次都去读远端

有人以为存算分离就是所有计算数据都从远端 HDFS 实时读取，这是误解。我们跑过一段纯远端读取的测试，效果是网络开销高到离谱，跑批时长比混部时代慢了快 40%。

实际工程里，计算节点仍然会挂载一组本地 SSD 作为缓存层。具体做法是，编排器在拉起计算组时，会同时下发一份“数据预热清单”。平台根据历史任务访问记录，把最近几小时热度最高的数据集提前同步到缓存目录；任务真正开始运行时，大部分命中本地缓存，只有冷数据才走远端读取。

这套“热数据本地化 + 冷数据走远端”的分层策略，既保留了存算分离的弹性，又不牺牲掉跑批性能。而且在缓存失效策略上，我们采用了 LRU 加 TTL 双机制，缓存条目超过一定时间自动淘汰，避免存储占用无限增长。

5. 从零接入平台：迁移路径与可直接参考的配置

5.1 迁移的六步走，每一步都不能跳

如果你也想把现有大数据集群往存算分离改造，同时接入自动化运维平台，我建议严格按下面这个顺序推进。

第一步，盘点存量和依赖。把所有业务任务、数据目录、调度依赖、账号权限全部梳理清楚，形成一个可执行的数据字典。这一步没有捷径，漏掉一个依赖关系，后面就会在线上爆发一次事故。

第二步，搭影子集群。在异构硬件或者虚拟化环境上先搭建一套小规模的存算分离集群，用真实任务做验证，而不是用测试样例。

第三步，双跑对比。将核心业务在旧集群和新平台上各跑一遍，对比数据计算结果是否一致、任务耗时差异多少、资源占用率如何。双跑的时间窗口至少要覆盖跑批的高峰和低谷两个周期，不要只测半天。

第四步，灰度切换。按照业务团队逐个灰度切换，先切非核心团队，再切核心团队。切换窗口放在业务低峰期，并且每个团队切换后观察至少 24 小时。

第五步，保留回滚预案。新平台出了问题，要能在一小时内把任务切回旧集群。所以旧集群在大促周期结束后至少还要保留一个月，让新的自动化平台经受完整业务周期的考验。

第六步，清算旧集群。确认新平台稳定运行超过一个月以后，再着手释放旧集群资源。但即便是清理阶段，也要记得给数据保留快照和备份。

5.2 一个新计算组接入平台的最小配置

我们平台里的计算组配置用 YAML 定义，下面是一个简化但完整可参考的示例。每个新团队接入时，只需要交这样一份类似的文件，编排器就能自动完成所有资源准备和调度策略设定：

compute_group: name: bi-offline zone: cn-east-1 min_instances: 10 max_instances: 50 initial_instances: 15 storage_sets: - name: hdfs-core type: hdfs quota_tb: 30 auto_scaling: enable: true step_up_percent: 20 step_down_percent: 25 cooldown_minutes: 15 metrics: primary: queue_backlog secondary: cpu_usage fuse: namenode_rpc_latency health_check: interval_seconds: 30 observation_seconds: 120 alerts: channels: - webhook: https://alerts.example.com/hook - email: ops@example.com

这份配置里最值得玩味的是fuse字段，它代表熔断条件。扩容前如果发现 NameNode RPC 延迟过高，平台不会执行扩容。这就是我们在第 3 章“启动风暴”事故之后总结出的核心经验：伸缩动作必须跟底层系统健康度联动，而不是孤立地看计算资源本身。

5.3 验收清单：平台上线前要打勾的项目

平台上线前，需要有一套明确的验收标准。我根据自己的踩坑经验整理了以下检查项，建议团队直接拿去做转测清单：

• 故障节点自动替换的平均耗时是否小于 30 分钟；
• 缩容过程中存量任务能否全部排空，不会有任务因节点消失而中断；
• 自动扩容出现异常时，熔断机制能否在 5 分钟内生效，防止启动风暴；
• 所有自动化操作是否有审计记录，能否完整回放出操作链路；
• 人工干预通道是否始终存在，也就是一键暂停全部自动伸缩的能力；
• 指标数据的保存周期是否满足故障复盘需求，监控数据至少保留 90 天。

清单里最后一条特别容易被忽略。如果没有长期指标历史，出了事故你都不知道那个时间点集群到底发生了什么。

6. 长期维护与团队协作的几个经验沉淀

6.1 自动化程度不是越高越好，“半自动 + 一键审批”更实用

我们最初的预期是做到“全自动”：平台自己发现问题，自己完成扩容、缩容、故障恢复，人只管看着。跑了一段时间发现，这个目标在企业内部很难真正落地，一方面是业务侧对自动缩容有天然的不信任，另一方面是有些边界情况平台确实判断不了，比如某个业务负责人临时宣布要停一个任务，平台完全不知道。

后来我们调整为“半自动 + 一键审批”模式：平台检测到扩容信号后，先执行准备工作，比如预热缓存、检查网络，然后生成一个变更单推送给运维值班人，值班人一键确认后，平台执行真正的拉起节点动作。缩容和故障替换同理。

这个模式的好处是既保留自动化带来的效率，又给每个敏感操作留了一道闸门。经验是，一开始把自动化权限放开一半，团队成员更容易接受，平台也能在实际运行中积累足够的可信度，之后再把更多动作完全放手。

6.2 配置即代码和变更纪律，比代码开发更考验规范

自动化运维平台真正长期维护下去，靠的不是编码技巧，而是变更纪律。我们平台的所有配置、伸缩策略、节点标签定义全部放在 Git 仓库里，任何改动都走 MR 评审，合入后自动同步到集群。

这个流程看起来繁琐，但几次救过大命。有一次业务方提了一个特殊需求，想临时把一个计算组的 max_instances 调到 80。如果直接在平台上点几下就改了，事后很容易忘记恢复；通过 MR 流程，这个变更留下了记录，也带上了过期时间，7 天后自动回滚，避免了配额长期失控。

再强调一点：所有变更单都必须带上“回归验证”步骤。也就是说，任何一次配置修改，都要明确写出如何验证这个修改被正确应用，以及出了问题如何回滚。没有这一条，配置就是一条没有安全带的变更。

6.3 给正在考虑存算分离的团队几句掏心话

如果你所在的团队还在混部架构里没出过大事故，先不要急着推翻现有架构。存算分离带来的弹性收益，需要规模化之后才能完全体现；如果集群只有三五十台机器，改造的投入产出比并不划算。但如果你已经有上百台节点，每次扩容缩容都快把运维团队拖垮，那这个问题迟早要面对。

平台建设也建议“从痛点出发”。我们不建议一上来就做很多浮夸的模块。优先把故障节点的自动替换、计算组的快速扩容、优雅缩容这三件事做好，就足以覆盖 80% 的日常运维压力。再往上加配额、审计、统一告警、智能预测，都来得及。

至少在我们这里，现在的状态是：凌晨跑批高峰，平台会自动拉起计算节点，任务跑完再自动缩回去；早上一上班，运维人员只需要看一眼值班报告，手动处理那些平台确认不了边缘个案。存算分离加自动化运维，终于把大数据集群运维从“救火队”变成了“巡航模式”。这是我个人认为这套改造最有价值的地方。