B站基于Apache DolphinScheduler的一站式大数据集群管理平台（BMR）初窥

一、背景

大数据服务是数据平台建设的基座，随着B站业务的快速发展，其大数据的规模和复杂度也突飞猛进，技术的追求也同样不会有止境。

B站一站式大数据集群管理平台(BMR)，在千呼万唤中孕育而生。本文简单介绍BMR的由来、面临的主要矛盾以及如何在变化中求得生存与发展。

下图是截至2024年6月初，统计到B站大数据的服务规模：

大数据所需承载的业务种类愈加繁多，为更好地满足业务场景的诉求，同时提升稳定性要求，我们大数据集群管理平台的建设，经历了以下主要几个阶段：

阶段一(求生存)

1. 聚焦系统环境标准化、服务配置标准化，清扫野蛮成长过程中非标生产留下的债务(层出不穷的奇怪问题)。
2. 快速和花样地迭代姿势，满足业务高速发展诉求。将各服务的安装包、配置纳入版本管理，服务状态有效透出，完成状态管理和分享。同时打通在线业务的门禁管理，快速迭代过程中不失稳定性考量。

(标准化工作嵌入迭代发布、配置发布、灰度发布中，同时支持常用的新增节点、快速部署、节点上下线等能力。管理上支持机器分组、打标、自定义流程、异构配置管理等)

阶段二(追温饱)

1. 建设元仓，打通服务间数据互通，实现问题的快速诊断。
2. 场景化建设，如：机房迁移所需的大批量、持续性项目，故障自愈能力等。
3. 提升覆盖面，边缘场景或非高频变更场景。如：Yarn队列管理、Lable变更、主从切换、HDFS数据迁移、HMS元数据管理等。

阶段三(奔小康)

1. 拥抱云原生，拓展容器化管理能力。更好利用在业务内和业务间的资源，实现降本增效。服务混部、潮汐退避 火力全开，追求更高的利用率的同时降低IT成本支出。
2. 建设容量管理，完善服务的异常预警、风险预测、故障自愈，进一步完善集群自动化运维体系，进一步追赶业务对大数据赋能的预期。

阶段四(共富裕)

1. 强化可观测能力，数据更接近业务视角，自上而下清晰对齐、指引方向。
2. 化被动为主动，从异常监控到故障自愈，再从故障自愈走向故障预测。
3. 极致追求服务质量，度量服务质量、死磕服务质量。

二、面临的挑战

接下来，我将在大数据平台化过程中遇到的典型问题和解决思路分享如下。

2.1、节点一致性问题

在元数据未闭环联动的情况下，一致性无法得到保障。B站的大数据集群当前仍以物理机为主，正在逐步容器化的阶段。大数据服务组件繁多，叠加多版本、混合部署、部分容器化等诸多因素，让元数据一致性的保障工作更加复杂。在完全平台之前，还存在脚本甚至人工操作，状态的变更无法有效闭环。节点遗漏和信息错误的情况时有发生，轻则服务器未有效利用，重则集群服务存在多个版本，留下稳定性隐患甚至直接影响业务生产。

不断完善覆盖面和使用场景的同时，一些重要的且短时间未实现数据闭环的场景，BMR在‘智能运维’模块的‘巡检’能力，去兜底去发现未知原因产生的脏数据或不一致的问题，让风险尽早被发现、被干预、被解决。

2.2、标准规范的制定和实施

集群标准，需要结合历史和当前情况来制定，并非设计而来。且实施过程，需要考虑兼容、迁移的能力和资源、实施周期等因素。过程中要根据集群支持的业务特点、环境、版本进行划分，如：实时集群、离线集群(2.8版本和3.2版本)等， 线上存在多个生产集群。在前期组件服务的部署规范和配置文件的标准化不足，存在同一集群内同一组件在不同节点部署环境都存在差异情况。在平衡标准化和差异化的过程中，‘小步快跑’地进行标准化的制定、试运行、修正、公示，技术项的标准最终固化到平台功能中。

2.3、规模化的管理

当“量变引发质变”和“不必过度设计”遇到“业务飞速发展”时，及时调整管理策略满足业务发展需求，极具挑战。

大数据玩的就是数据，硬盘少不了。当前我们的大数据集群磁盘数量在十万量级。每天磁盘正常故障超10块， BMR在‘智能运维’模块集成了‘硬盘故障自愈’的能力，打通各个平台的数据和流程，实现业务无感式的换盘。还有操作系统层面的内核管理与升级，在面临节点数量多、需要无感/无故障的管理，都会对平台提出更高的要求。

而且在机房资源紧张的情况下，会涉及集群迁移甚至机房迁移的工作。如何不停机实现迁移，BMR上也都做了适配。

2.4、提升迭代效率

单纯提效不难，难的是在复杂场景中保证稳定的前提下。

生产不能停，迭代要继续，规模同时要满足发展需要。BMR在建设迭代能力的同时，通过元数据的管理监测资源容量。本着尽可能地避免问题、尽早地暴露问题的原则，集群资源做了分层、隔离以保安全，迭代过程也必备了‘灰度’、‘快速回滚’、‘异常探测’以便快速发现和快速解决问题。

同时多集群、多组件、多角色的‘变更冲突’需要加以限制，变更信息的‘透明化’和‘快速回滚’利于故障快速诊断与恢复。跨团队协作中，复用在线业务平台的通知与协同能力，实现消息的精确触达和快速应急响应。

2.5、削峰填谷

降本增效大背景的今天，资源有效利用也不是新话题。大数据业务和在线业务有着天然的资源错峰潜质，BMR当然不会放过。我们已在2023年实现大数据业务与在线业务的资源潮汐退避，大数据业务白天出让资源给在线业务使用，在线业务夜间归还的同时也出让冗余的资源给到大数据，实现‘削峰填谷’和‘资源共赢’。

三、平台实践

秉着先解放双手再系统闭环然后贴进业务的思路，BMR(大数据管理平台)逐步拆招解招。

系统整体架构如下图所示，BMR主要由集群大盘、集群管理、组件管理、变更管控和资源管理功能模块构成。

底层复用公司的‘Job任务’平台，使用 DolphinScheduler 做逻辑调度。 业务数据和逻辑集中在‘元数据’、‘配置中心’、‘主机管理’和‘发布服务’四大模块中，对用户由‘集群大盘’、‘集群管理’、‘组件管理’、‘变更管控’和‘资源管理’来呈现。

产品层本着‘一站式’的思想， 在操作集群管理时， 用户只需选择发布的组件、对应的主机节点， 及发布策略， 即可快捷完成变更操作。把复杂的逻辑和后端留给BMR，让用户只关心他需要关心的。