文末有礼丨2024年哔哩哔哩技术精选技术干货

哔哩哔哩技术精彩回顾（点击标题查看）

👇 👇 👇

01 

机房断网故障，是对多活架构的有效性、可容灾性、预案的可执行性的综合考验，需要持续常态化演练来保障。本文基于一次断网故障，从DCDN架构及多活治理的视角，分析问题和治理优化措施。

02 

评论是B站生态的重要组成部分，不仅是用户互动的核心场所，也是平台运营和用户粘性的关键因素之一，所以评论服务的稳定性至关重要。评论系统的回源流量强依赖 TiDB，如果 TiDB 无法支撑突发大流量查询，将导致评论服务不可用。因此基于公司自研的 NoSQL 存储 Taishan 设计了一套高可用的容灾架构，并且提升评论索引的查询性能，解决了双存储的数据一致性、降级成功率等问题，做到业务无感的自动降级。

03 

在当今数字娱乐时代，弹幕、送礼等互动消息已经成为直播平台不可或缺的元素。如何把这些互动消息实时通知到终端，长连消息系统应运而生。随着直播平台的壮大，如何支持千万用户同时在线，以及性能优化和稳定性保障措施。

04 

标签系统是内容管理和用户分析的核心技术基础设施。B站标签系统始于2021年,旨在解决业务侧频繁的adhoc查询问题。2022年中期面临性能瓶颈、规范缺失、重复建设等挑战,促使重新启动系统建设。

新版系统采用三层架构(标签生产、人群圈选、人群应用),通过引入Iceberg支持多存算引擎、自定义分shard模式读写Clickhouse、基于DAG的人群计算等技术方案,显著提升了系统性能和稳定性。系统实现了99.9%的人群圈选成功率,千万级数据10秒内完成圈选,在线服务可用性达到99.999%。

目前系统已支持30+业务场景,累计3000+标签和10w+人群规模。未来将继续在实时标签生成、灵活指标定义、效果回收等方向持续优化,打造更强大的标签系统。

05 

B站监控1.0基于Promtheus方案，落地统一监控平台。但随着B站业务迅猛发展，指标数据级也迎来了爆炸式增长，不仅给现有监控系统的稳定带来冲击，也无法满足公司层面可观测稳定性建设目标。我们基于采集存储分离，存算分离，单元化容灾等设计思路，完成了监控2.0架构落地。本文介绍了监控2.0整体架构，各个模块的实现细节和查询优化相关工作。

06 

在传统的大数据元数据管理系统中，以 HiveMetaStore 为核心的架构存在诸多问题和挑战。B 站率先引入 Apache Gravitino，构建了元数据的中心化管理组件 OneMeta，成功解决了传统大数据管理中的多种痛点：统一了元数据视图，优化了跨源数据的使用成本，提升了数据使用的安全性，降低了数据存储和任务维护的成本。尤其在HDFS文件治理和AI数据管理方面，我们基于Gravitino 中的 FileSet 概念和 GVFS 虚拟文件系统，极大地提高了管理效率并减少了存储成本。

07 

排行榜在直播业务体系中有着至关重要的作用，榜单在一定意义上是连接主播、平台以及用户的纽带。新功能迭代、活动上新、多样性玩法等方方面面，都可能会有将榜单作为依赖组件的需要。所以有一个基础能力通用、接入灵活、操作方便的榜单系统对直播业务来说是非常重要的。

08 

云原生时代下， Kubernetes已成为容器技术的事实标准, 但多种原因导致有状态的应用容器化一度成为了容器技术圈子的禁忌话题， 本文基于Elasticsearch/Clickhouse在B站生产环境的容器化/K8s编排能力落地， 将阐述为何我们需要进行容器化/on k8s， 容器化中遭遇的挑战以及解决方案， 落地的技术细节以及收益。

09 

随着业务规模的扩张和需求的快速迭代，生产环境中系统故障难以避免。为实现故障的快速发现、响应、定界、定位、止损和恢复，本文探讨了围绕故障全生命周期的应急响应中心建设实践。故障管理涵盖发现、处理、恢复、复盘和改进各环节，旨在全面提升故障处理效率，保障系统稳定运行。

10 

随着近些年来B站业务迅速发展，业务对于基础设施的稳定性和可持续性要求也在不断提高。综合权衡B站的各种需求后，为了进一步优化上层业务布局，支撑业务整体的异地多活，有效提升资源利用率和运营稳定性，B站开启了历时18个月，跨越长三角多个地区，涉及数万台服务器和交换机设备的大规模搬迁。数据中心搬迁是技术能力和组织管理能力的有机整合，对数据中心搬迁过程中遭遇到的各种工作与困难加以思考和总结后，我们整理成此文，希望能给到大家帮助。

11 

本文详细探讨了哔哩哔哩客服坐席调度系统的演进，特别是在线客服和工单客服的调度策略。随着客户需求的增加，尤其是在大型活动期间，客服系统面临着突发的高流量和复杂的客户问题。为了提高服务效率和客户满意度，系统引入了多种调度策略，包括均衡分配、熟客优先和虚拟排队等。

同时也对工单系统的调度也做了详细的技术分析。

12 

在B站的世界里，详情页至关重要！它承载着数亿次的日均播放流量。但此前 UGC、OGV、PUGV 详情页各自为政。本文将带你了解如何打造通用详情页，解决多业务形态不统一、迭代方式混乱、稳定性难保障及新人上手难等问题。通过创新的框架设计，分为业务、组件、框架三层，还引入依赖注入和 scope 等技术手段，并在开发、测试、线上阶段实施策略确保速度与质量稳定，快来一探究竟吧！

13 

随着B站用户数量的迅速增长和业务的不断扩展，数据中心的规模和复杂性也在不断增加。早期采用传统的PXE装机方案逐渐暴露出灵活性不足和效率低下的问题，难以满足新交付装机、重装机、机房搬迁、CDN服务器装机等各类复杂场景以及业务的多样化需求。本文详细介绍B站装机系统的演进过程，以新交付装机和复杂网络装机两个装机场景为例，重点探讨如何构建一个能够满足多样化需求的装机系统，以及在装机实践中面临的挑战和提出的解决方案。

14 

技术领域内，由变更导致的故障占比一直居高不下，如何管控好变更是提升业务稳定性的核心路径。变更管控平台是一个为公司内技术线各类变更提供統一接入、管控和分析的一体化平台。平台通过对变更动作、变更对象和变更范围等基本交更要素进行标准化定义，建设通用的变更管控技术框架，实现变更可观测、可感知、可干预，确保在变更日益分散、高频的技术环境下，对实际变更内容、变更过程能够进行统一收敛、实时计算、风险识别和异常干预，实现对变更的数字化管理和统一防控。

15

Index大模型团队自研大模型的全栈技术基建，包含LLM基座预训练、对齐、多模态，并注入更多B站独有的社区知识，推出Index系列大模型。我们于2024年6月首次开源Index系列模型中的轻量版本: Index-1.9B系列，是业内同尺寸性能SOTA的端侧模型，多语言理解能力优秀。开源内容非常丰富，从基础模型、角色扮演、长文本，到中间的模型检查点、优化器状态，均开放给社区研究和使用。同时，我们更透明的讨论数据清洗细节、训练调优细节，分享我们的训练经验。模型受到社区欢迎，累积下载3w+次，为开源社区贡献了B站力量。

16 

随着大语言模型（LLMs）的出现，其在软硬件基础设施、算法及数据等多方面的挑战和困难也逐步显现。本文从AI-Infra角度出发，分析LLMs在算力、存储、通信等方面上硬件资源的挑战和瓶颈，量化LLMs所需的硬件资源，包括模型参数量、模型算力需求、模型显存占用、模型通信需求。最后，讨论LLMs训练集群扩展性估算，包括阿姆达尔定律的应用和集群性能评估指标。通过上述分析，为LLMs的硬件选型和性能优化提供了理论指导和实践参考。

17 

本文描述了哔哩哔哩直播业务面对高实时性要求和复杂的排查链路时，如何打造一个高效的跨端实时排障系统。文章详细阐述了通过数据采集、处理到可视化的全过程，并特别介绍了引入trace_id实现全链路追踪的关键技术。不仅优化了开播异常断流等关键业务问题，还显著提高了跨部门协作效率，将异常定位的平均时间从2小时大幅缩短至5分钟。

18 

抓包并进行分析是一种非常高效的 debug 方法，但是想要成为熟手老司机需要大量积累和练习。本文根据实例展示了具体的分析过程以及验证方法，并串起相关知识点，希望能给到大家帮助。

19 

B站自研的1.9B长文本大模型，这一“小精灵”能够一次性处理超过3.5万字的文档。在多项长文本评测任务中，该模型在相近规模及同期开源的模型中表现尤为突出。凭借极小的模型体积和算力开销（仅约为GPT-4的2%），成功实现了卓越的长文本处理能力。如下图所示，我们的1.9B模型的得分甚至远超7B规模的模型。

^{Index-1.9B-32K与GPT-4、Qwen2等模型长文本能力对比}

20 

游戏账号登录系统，作为游戏发行业务最重要的前台应用之一，长久以来需要在效率、质量、成本，多个要素之间取得平衡。

通过结合对于业务的深度思考，灵活的运用重构知识，本文记录了如何降低应用架构的复杂度，提升迭代效率和质量的过程。

希望对读者有所启发。

-End-

以上就是2024年【哔哩哔哩技术】年度精选干货！

有没有哪篇在技术道路上给了你新启发？或者有任何建议&意见、未来想看到的内容，都欢迎留言告诉我们。

转发本文至朋友圈并留言，即可参与下方抽奖⬇️

小编将抽取5位幸运的小伙伴从初龙年小电视鼠标垫键盘垫

抽奖截止时间：1月10日12:00

如果喜欢本期内容的话，欢迎点个“在看”吧！