专栏名称: 哔哩哔哩技术

提供B站相关技术的介绍和讲解

B站大数据集群管理平台BMR的实践与创新

哔哩哔哩技术 · 公众号 · · 2024-10-29 12:00

正文

导读随着 B 站业务的快速发展，大数据的规模和复杂度也突飞猛进。为应对这一挑战，B 站一站式大数据集群管理平台（BMR），在千呼万唤中孕育而生。BMR 平台包含集群管理、元仓建设、智能运维等核心模块，这些功能很好的承接了业务场景的需求，显著提升了变更效率，保障了系统安全变更，优化了运维流程。本次分享将详细介绍 BMR 平台的各个模块功能及其在实际应用中取得的成效。

今天的介绍会围绕下面 6 点展开：

1. 背景介绍

2. 集群管理

3. 元仓管理

4. 智能运维

5. 定制化 Manager

6. 未来展望

分享嘉宾｜刘明刚 bilibili 资深工程师

出品社区｜DataFun

背景介绍

1. BMR 的诞生

B 站于 2021 年推出了一站式大数据集群管理平台（BMR）。当时业务发展迅猛，随之而来的是大数据规模和业务复杂度的不断增加，传统的 CI/CD 平台已经无法满足快速增长的需求。为了解决这一问题，我们开发了自己的大数据基础组件管理系统。经过三年的发展，目前 BMR 管理着超过 50 个服务组件、拥有上万台机器、EB 级别的存储和百万核的计算资源。

2. BMR 发展阶段

最初的 BMR 扮演着救火队员的角色，解决紧急的问题和需求。随着发展，BMR 变得像战斗机一样，边加油边战斗，保障我们的大数据服务组件能够持续稳定运行。BMR 的发展主要经历了四个阶段。

第一阶段，首先聚焦于环境标准化、服务配置的标准化，解决野蛮成长过程中非标生产留下的债务，例如环境配置混乱、日志目录、安装包管理不规范等问题；其次，BMR 的另一职责就是满足核心组件的快速迭代发布需求。

第二阶段，开始建设元仓、沉淀业务元、故障等数据，打通服务间的数据互通；同时提示组件的覆盖面，由核心组件逐步扩展至更多服务组件，逐渐实现了全面覆盖；在此过程中，也伴随着一些机房迁移、在线离线混部、潮汐混部等场景化的建设

第三阶段，为了顺应整个公司的发展，拥抱云原生，BMR 扩展了容器化管理的能力，满足 Spark、Flink 等服务逐渐向 K8S 迁移的需求；另外，元仓数据也开始逐渐被应用，如容量管理和 SLO，任务诊断工作等，基于元仓数据，我们还实现了一些智能运维的能力，旨在提升效率，解放双手。

现阶段，也就是第四阶段，智能运维平台进一步升级，在之前的故障自愈的基础上，又开发了故障预测的功能，比如热点机器、磁盘性能下降等；另外，还结合大模型开发了智能问答系统，使运维效率得到了大幅提升；针对不同的需求，我们使用定制的 Manager 来管理，使服务更稳定更精细化。

3. BMR 产品蓝图

以集群管理为核心，再加上元仓、智能运维模块以及定制化 Manager，这四大模块围绕着成本、稳定、效率三个目标，逐步建设成为一站式的大数据管理平台，实现了发布、问题排查、资源管理、降本增效等一系列能力。

集群管理

接下来将重点介绍集群管理部分。

集群管理是 BMR 的基础功能。每天有超过 50 次变更，涉及的机器数量高达上万台，正是借助于 BMR 的集群管理实现高效、稳定的变更。

BMR 提供了集群、服务、配置、安装包管理等基本能力，以满足大数据基础组件的最基本诉求。

BMR 也提供了节点上下线、服务扩容缩容、服务重启，升级等这些日常操作，除此之外，我们还提供很多高级核心能力

为了快速满足不同组件管理变更执行流程的差异性，BMR 还配备了一个流程管理系统，通过可视化编辑，利用其流程 DAG 可视化编辑能力，极大地加快了开发速度。
据 Google SRE 统计，线上 70% 的故障都是由某种变更而触发的。为了保证在 BMR 上发布的稳定性，我们支持了灰度发布、快速回滚、核心配置检查、变更防御、变更过程中的黄金指标检测、日志检查等很多安全变更相关的功能，让我们能够及时发现变更带来的风险并阻断变更过程。
在机房迁移时，需要下线大量机器并进行服务组件迁移，BMR 都是优先下线服务和节点，整个过程中，让变更变得安全可靠。
大数据中存在着大量异构机器，包括不同操作系统、内核、机器配置和生产厂商等。BMR 能够对这些异构环境做到自适应差异化处理。
节点和服务的生命周期管理也是一个挑战，在没有 BMR 之前，节点的状态和健康状况很难得知。在 BMR 中，可以很好地实现对节点状态变化的管理和服务的生命周期管理。
此外，大数据很多服务组件是相互依赖的，我们通过 BMR 实现跨组件的联动。

在近两年开展的降本工作中，BMR 集群管理也起到了关键作用。大数据业务在白天需求相对较少，而晚上需求比较大，在线业务刚好相反，因此我们实行了潮汐部署策略，错峰出行，大数据早上下线机器借出给在线业务使用，晚上在线业务归还机器大数据继续使用。为了很好的支持“早出晚归”，BMR 实现了计算节点的弹性伸缩。由于大数据机器还保留了存储，我们对存储服务 HDFS 和在线业务实现了分级保证，同时保证了 HDFS 和在线服务的稳定性。通过潮汐混部节省了超过 1000 台机器，超过 6 万个核的计算资源。

元仓建设

在集群管理成熟后，我们开始进行了元数据仓库的建设。

1. BMR-元仓建设

元仓实际上是数据的集合，实现了数据的互通，其中包含业务元数据、黄金指标以及故障数据。元仓以数据为基础，其重要性主要体现在：

通过元仓可以实现不同主机、组件和任务之间的数据交互；
利用元仓可以确保元数据的一致性；
由于元仓数据会被永久保存，我们可以随时进行历史数据分析和回放。

2. BMR-元仓应用

上图展示了元仓几个常见应用

首先，通过一些黄金指标，可以清楚地了解当前服务、组件或应用的整体情况。

另外，容量/Quota 管理主要用于降低成本、提高效率，让资源得到更合理的利用。在稳定性方面，容量/Quota 管理也起着重要作用，做好容量预警，有效的避免因容量问题而导致的在线故障。通过容量预估，并根据用户 Quota 制定了准入和隔离策略。

此外，SLO 是元仓的另外一个应用场景，它可以很好地反映出组件或者服务的稳定性。在数据集成产品中的场景，数据是管道式的，数据可能会出现晚到情况，因此，在建立 SLO 的时候，除了考虑成功率和响应时间之外，我们还重点关注了偏离度这个 SLO 指标，能够很好的覆盖管道场景的 SLO 需求。

主机诊断根据元仓中的主机硬件故障、系统问题、异常日志以及监控指标等数据，提供了主机健康度分析，可以方便地查看和分析主机当前的健康状况，提前发现风险并及时解决。同时利用历史健康数据分析不同维度（机型、主机厂商、操作系统版本、内核版本等）的故障率，为我们的机型选型、内核和操作系统选择提供强有力的依据。

任务诊断系统则是为用户提供了任务的自动诊断和优化能力。经过多年的积累，开发了 20 多种诊断类型。根据这些诊断结果，可以获得任务运行的整体概况，也可以针对单个诊断类型的历史数据进行统计分析，同时可以诊断出单个任务的当前的健康状况以及需要优化的地方。这些诊断分析可以帮助我们更好地了解任务的状态，同时反馈出计算引擎的健康和性能状况。

智能运维

接下来要介绍的是智能运维模块。

1. BMR-智能运维

BMR 集群管理的机器超过 1 万台，服务组件超过 50 个，磁盘数量超过 20 万块，规模非常庞大。

同一台机器同时部署了许多不同的组件，例如转码和大数据混部、潮汐部署、大数据内部组件混合部署等，组件之间的相互依赖以及异构的机器和环境这些都让服务的管理极其复杂。

在问题排查过程中，一个任务可能分布在多台甚至上百台机器上，故障发现和处理会出现滞后和困难的情况。这时，智能运维体系的作用就开始显现。

整个大数据智能运维体系主要包括数据采集、分析、自愈和诊断，为逐步实现这一体系，我们建设了巡检系统、故障自愈系统和智能问答系统。巡检系统主要用于主动发现潜在风险，帮助业务自主诊断；故障自愈平台通过采集主机、业务等数据、结合业务对数据进行实时分析，实现对异常和故障实现自动化智能化的自愈处理；智能问答系统结合大模型技术，直接向用户提供快速反馈。这些系统共同构成了我们的智能运维体系。

2. 巡检平台

巡检平台的主要功能有两个，第一个是主动探查已知风险，比如发现主机硬件、操作系统、核心配置错误以及组件部署不符合预期等场景，这些问题都可以整合到巡检系统中。另一个功能是，当研发或业务部门发现故障时，不确定是否影响到所有机器和任务，就可以利用巡检平台快速创建一个巡检任务，非常方便快速地满足紧急风险快速响应的需求。

下面结合上图中的巡检报告，简要介绍一下巡检平台的能力。其中有几个核心能力，即巡检任务、巡检项和巡检对象。巡检项指的是我们需要检查什么，一个巡检任务可以配置多个巡检项，比如在一个服务中可以将所有与硬件和操作系统相关的巡检都配置上。在巡检任务中，对于即时需求，可以使用即时任务来满足；对于一些需要长期巡检的问题，可以使用周期性任务来进行日常巡检。巡检对象，是指我们需要对哪些主机、集群或组件进行巡检，这些数据是和 BMR 集群管理是打通的。巡检完成后，会生成巡检报告，包括一些告警信息，用户也可以很方便的对巡检结果订阅。

3. 故障自愈

故障自愈，是让故障处理过程实现自动化，从而使处理更加及时、更加智能。另外，还可以通过故障预测提前识别并规避一些风险，变被动为主动。

故障自愈产品能力中，由于大数据业务磁盘总数基数大，故障数也最多，我们先从磁盘的故障自愈开始做。我们对三类磁盘异常进行了故障自愈。第一类是磁盘有明显硬件故障，这类最容易处理，直接暂停该磁盘上的对应业务，报修换盘，磁盘换盘后上线继续使用。第二类是结合业务需求，利用机器学习对磁盘指标数据进行分析和预测，对性能离群且影响到业务的磁盘也做了自愈。第三类是磁盘寿命不足的场景，在大数据 shuffle 过程中，频繁的读写操作会加速磁盘寿命消耗，需要及时更换 shuffle 盘。以往为了避免磁盘寿命耗尽影响到服务，我们根据磁盘寿命剩余多少来判断磁盘是否需要换盘，有时候被换掉的盘实际上还能继续使用一段时间。有了自愈系统之后，我们可以根据磁盘寿命和性能数据综合判断，即使寿命统计数据显示磁盘寿命耗尽，但不影响使用的情况下，我们也可以继续使用，不仅提高了换盘的效率，同时也延长磁盘的使用寿命。

此外，自愈系统慢慢开始覆盖 IO Hang 住、服务进程异常、端口异常、访问异常等越来越多的场景。

自愈处理的流程为，首先根据元仓数据找出故障、根据故障类型分析故障影响的组件，然后根据影响组件的不同采取不同的自愈流程。比如一个磁盘性能下降的机器上部署了 Datanode，我们在自愈的过程会检查 HDFS 副本情况，看是否需要进行下一步处理，如果可以执行磁盘下线处理，我们会对磁盘下线影响的服务进行踢盘操作，完成这些步骤后，再向系统组进行故障报修。故障修复之后，自动将这块磁盘添加到对应的服务中，重新投产使用。

4. 智能问答

为了解决值班压力，我们开发了智能助手，用户通过问答的方式快速查询问题获得帮助。如图所示，我们可以输入一个主机名咨询问主机的健康状态，也可以根据任务名称咨询任务诊断信息。此外，还可以直接发一个调度平台的端链接，自动解析出对应的任务然后开始诊断和反馈。

以上就是对智能运维体系的介绍，从最初的数据采集和分析逐渐演变为自愈系统、智能问答，不仅加速了故障处理流程，还减少了人力资源的投入。以前，仅处理磁盘故障就需要一名员工整天忙于下线、报修和上线，现在有了智能运维体系，就可以避免这种重复且繁琐的工作。

定制化 Manager

接下来介绍定制化 Manager 相关工作。

随着我们的产品不断完善，已具备高效变更和安全变更的能力，在此基础上还要满足一些差异化的需求，我们是通过定制化 Manager 来实现的。目前有 Flink Manager、Kafka Manager 和 Spark Manager。其中，Flink Manager 和 Spark Manager 主要用于任务管理、版本管理和测试管理。而 Kafka Manager 则主要聚焦于 Kafka 集群的管理和 topic 管理。

1. Flink Manger

目前我们已有超过 7000 个 Flink 任务，超过 3000 台主机，有 110+ 任务模版，每周变更次数接近 100 次。

为什么需要任务模版呢？主要是因为我们的数据集成任务、CDC 任务，都是基于 Flink SQL 实现的，我们会预先建立好模版，这样用户在创建数据集成/CDC 任务时就可以基于模版快速创建一个新的 Flink 任务。

我们在任务发布的时候可以分阶段进行灰度变更，以确保安全生产。在灰度变更过程中，会进行一些前置和后置检查，以更好地应对变更风险，避免变更对服务造成影响。

在机房迁移过程中，Flink Manager 也发挥了重要作用，通过对任务批量操作，很方便地实现任务的迁移。另外，节点管理也至关重要，前面提到故障自愈可以对不同的产品进行不同的处理，比如发现故障机器部署了 Flink 服务，故障自愈就会与 Flink Manager 自动打通，对有影响的任务进行迁移，实现故障自愈。

2. Kafka Manager

Kafka Manager 经过几年的积累，逐渐形成了包括集群管理和 topic 管理的工具矩阵。目前，我们使用 Kafka Manager 管理着超过 40 个 Kafka 集群，最大集群包含近 500 台机器，总计超过 2000 台主机，超过 10000 个 topic。

使用 Kafka Manager 可以有效管理集群、主机和 topic。在日常运维中，经常遇到各种突发情况，比如用户的错误使用姿势导致读写流量激增，可能对整个集群或节点上的其它 topic 或用户产生影响，这时就可以利用 topic 的读写限流功能，对特定 topic 进行限流，从而避免单个 topic 影响扩大。另外，在故障维修的时候，或出现数据不均衡的情况时，可能需要进行 partition 的迁移，也可以通过 Kafka Manager 来实现，Kafka Manager 支持机器到机器之间的迁移以及磁盘到磁盘之间的迁移。

3. Spark Manager

Spark Manager 目前还未上线。Flink Manager 主要负责管理实时任务，而 Spark Manager 则负责管理离线任务。离线任务比实时任务更多，每天有超过20 万个 Spark 任务在运行，涉及的主机数量超过 1 万台，因此需要一个平台来很好地管理这些任务。

首先，我们通过 OneClient 对 Spark 统一管理，在我们的 Spark 版本特别多的情况下，进行多版本管理非常麻烦，不同任务可能需要运行在不同的 Spark 版本上，这对 Spark 客户端维护来说是一项很困难的工作。为了简化管理和升级的复杂度，我们使用了 OneClient，我们通过在服务端设置不同任务使用不同的 Spark 版本并且可以快速的回滚。这样整个过程管理起来就会很方便。

Spark 变更过程，同样会采用灰度发布、变更防御等措施来保证安全性。另外，我们意识到测试平台的重要性，尤其是在开发新版本时，需要确保开发的组件经过了单元测试、基准测试、性能测试和数据质量验证，以避免线上出现潜在风险或影响。因此，我们计划建立一个大数据测试平台，涵盖基准测试、性能测试和数据质量验证等多项功能。在变更时，会去关联整个测试平台的测试情况，如果测试未通过，这个版本就不允许继续发布。这就是我们正在打造的 Spark Manager 的情况。

未来展望

最后是对未来工作的一些展望。

首先，大数据测试平台目前还在完善中，对于 Spark、Flink、Kafka、OLAP 等多个服务和组件都会将变更和测试打通。

第二是加强变更管控，增加更多变更防御点，如时间上的防控和核心配置的防控，以及对黄金指标和日志异常的分析，结合多个维度去判断变更的影响，以避免因变更而导致的线上故障或问题。

第三，继续增强容量管理、风险预测和自愈能力，这关系到整个大数据基础设施的稳定性。

最后，我们会探索更多大模型在垂直领域的应用场景，这将有助于解放双手、减少故障，并提升整体的稳定性和效率。

以上就是本次分享的内容，谢谢大家。