大数据平台多集群管理与统一纳管架构设计

企业大数据平台发展到一定规模后，几乎都会面临一个现实问题：多个集群并存，各自为政。早期为不同业务线搭建的 Hadoop 集群、后来采购的云上 EMR 集群、新上线的 GPU 训练集群，三套系统之间没有统一的资源视图、没有统一的权限管理、没有统一的运维入口。数据工程师要登录三个不同的 YARN ResourceManager 查看队列使用率，运维人员要在三个不同的监控大盘之间切换排查问题，管理员要分别维护三套用户权限体系。

本文设计一个统一纳管架构，覆盖异构集群的资源调度、统一认证、运维监控和 AI 负载管理四个层面，并讨论在 GPU/CPU 异构算力调度场景下的具体实践。

多集群并存的成因与痛点

多集群并存不是技术决策失误，而是业务发展的自然结果。典型的演进路径是：初始阶段一个集群跑所有业务；业务增长后按部门拆分为多个集群；上云后部分集群迁移到云上，部分保留在本地；AI 基建启动后又新建了 GPU 集群。每个阶段的决策都是合理的，但累积下来就形成了异构多集群的格局。

这种格局的核心痛点有四个。资源利用率低——A 集群的 CPU 资源空闲，B 集群的任务在排队等待资源，但两个集群之间无法互借。运维效率低——每个集群有独立的监控、告警、日志系统，故障排查需要在多个系统间跳转。权限管理割裂——同一个用户在不同集群上有不同的账号和权限，人员离职后需要逐个集群清理权限。成本不透明——无法看到跨集群的总体资源使用成本和 ROI。

EasyMR 大数据底座在设计上就考虑了多集群统一管理的场景，支持对多套 Hadoop、Spark、Flink 集群进行统一纳管，提供跨集群的资源视图和运维操作入口，降低了多集群环境的管理复杂度。

统一纳管架构设计

控制平面

统一纳管架构的核心是控制平面（Control Plane）。控制平面不直接运行数据任务，而是提供统一的管理接口和调度决策。

控制平面的第一个组件是集群注册中心。每个被纳管的集群需要向注册中心注册基本信息：集群类型（Hadoop、K8s、云 EMR）、版本、网络地址、资源容量、当前负载。注册中心维护一份实时更新的集群清单，供其他组件查询。

控制平面的第二个组件是统一认证服务。用 LDAP 或 Keycloak 作为身份源，为每个用户生成跨集群统一的身份凭证。用户登录控制平面后，控制平面根据用户的角色和策略，自动在目标集群上创建临时 Token 或代理账号。用户不需要知道目标集群的认证细节，控制平面屏蔽了底层差异。

控制平面的第三个组件是全局调度器。全局调度器不替代集群内部的 YARN Scheduler 或 K8s Scheduler，而是在集群层面做任务路由。当用户提交一个任务时，全局调度器根据任务的资源需求、数据位置、队列配额和集群负载，决定把任务发送到哪个集群执行。这种两级调度的模式——全局调度器决定集群，集群调度器决定节点——在保持各集群自治的同时实现了全局优化。

数据平面

数据平面负责跨集群的数据访问和任务执行。

跨集群数据访问有两种模式。联邦查询模式通过 Trino 或 Presto 的 Catalog 机制，让用户用一条 SQL 查询多个集群上的数据，不需要手动做数据搬迁。这种方式的延迟较高，适合即席查询和数据分析场景。数据同步模式通过数据管道把数据从源集群同步到目标集群，适合需要低延迟访问的生产场景。

EasyMR 在数据平面层提供了统一的任务提交和管理能力，用户可以通过单一入口向不同集群提交 Spark、Flink 或 Hive 任务，不需要切换不同的客户端和配置文件。

GPU/CPU 异构算力调度

AI 负载的引入让多集群管理增加了新维度：GPU 资源和 CPU 资源的统一调度。

异构资源建模

YARN 传统上不区分 GPU 和 CPU——它只管理 container 的 CPU 和内存配额。从 YARN 3.1 开始，YARN 支持 GPU 资源的声明和调度，但功能比较基础。Kubernetes 的 Device Plugin 机制提供了更灵活的 GPU 资源管理能力，支持 NVIDIA GPU、AMD GPU 甚至 TPU 的声明式管理。

在统一纳管架构中，需要在控制平面建立异构资源模型。每个集群的资源池需要声明它拥有的资源类型和数量：CPU 核数、内存大小、GPU 卡数和型号。全局调度器根据任务的资源类型需求匹配合适的集群。

调度策略

GPU 任务和 CPU 任务的调度策略有本质差异。CPU 任务通常是短时运行的批处理任务，可以随时抢占和重新调度。GPU 任务通常是长时间运行的训练任务，中断成本很高——一个跑了一半的训练任务被抢占，已经消耗的 GPU 时间全部浪费。

推荐的调度策略是分层调度。第一层是集群选择：全局调度器根据 GPU 可用性和网络拓扑选择目标集群。第二层是队列选择：在目标集群内，根据队列的 GPU 配额和当前使用率选择队列。第三层是节点选择：K8s Scheduler 或 YARN 根据节点的 GPU 可用性和亲和性规则选择具体节点。

对于多租户的 GPU 资源，建议设置 GPU 配额上限和借用机制。每个租户有保底的 GPU 配额，空闲时可以被其他租户借用，但借用者在资源提供者需要时必须释放。这种"保底 + 弹性"的模式既保证了关键训练任务的资源可用性，又提高了 GPU 的整体利用率。

AI Pipeline 调度

AI Pipeline 通常包含多个阶段：数据预处理（CPU 密集）、模型训练（GPU 密集）、模型评估（CPU 密集）、模型部署（混合资源）。每个阶段的资源需求不同，运行环境也不同。

在统一纳管架构中，AI Pipeline 的调度需要支持跨集群的阶段编排。数据预处理阶段可以在 CPU 集群上执行，处理完的数据通过高速网络或共享存储传递到 GPU 集群上执行训练阶段。这要求控制平面具备跨集群的 DAG 调度能力和数据传递机制。

一种实现方式是用 Airflow 或 DolphinScheduler 作为 Pipeline 编排层，控制平面作为资源路由层。Pipeline 编排层定义任务依赖关系，每个任务通过控制平面的 API 提交到指定集群。这种方式把编排和调度解耦，两个层面可以独立演进。

运维监控统一化

多集群环境下的运维监控需要解决两个问题：数据聚合和统一视图。

数据聚合层面，每个集群的监控数据（CPU 使用率、内存使用率、队列状态、任务运行情况）需要汇聚到统一的时序数据库中。推荐用 Prometheus 做数据采集，每个集群部署一个 Prometheus 实例，中央 Prometheus 做联邦查询。或者用 Kafka 做监控数据管道，所有集群的监控事件推送到 Kafka，由消费者写入时序数据库。

统一视图层面，需要一个跨集群的监控大盘。大盘应该提供三个层次的视图：集群级视图——每个集群的总体资源使用率和健康状态；队列级视图——每个租户或业务线的资源使用和任务运行情况；任务级视图——单个任务的运行进度和资源消耗。

实施路径

多集群统一纳管是一个渐进式工程。第一步是建立控制平面的集群注册和统一认证，让用户用一套账号访问所有集群。第二步是部署统一的任务提交入口，把客户端配置和集群切换逻辑从用户侧移到平台侧。第三步是建设跨集群的监控大盘，让运维人员在一个界面看到所有集群的状态。第四步是引入全局调度器，实现任务的智能路由。第五步是接入 GPU 集群，建立异构资源的统一管理能力。每一步之间建议留出足够的观察期，因为每一步上线都会改变用户的使用习惯，需要根据反馈调整策略。