时光匆匆，【哔哩哔哩技术】公众号又与大家携手走过了充实的一年。2024年我们共精心打造了99 篇原创技术文章，全方位、多角度地剖析了各类前沿技术与实用业务应用。今天，我们特别挑选出 2024 年度广受好评的 20 篇文章，汇集成这份年度精选干货，邀您一同回顾那些闪耀着智慧光芒的技术瞬间，汲取宝贵的知识养分，激发新的灵感火花！
随着B站业务的飞速发展，数据规模呈指数级增长，计算集群也逐步从单机房扩展到多机房部署模式。多个业务线依托大数据平台驱动核心业务，大数据系统的高效性与稳定性成为公司业务发展的重要基石。如图1，目前在大数据基础架构下，我们主要采用 Spark、Flink、Presto 以及 Hive 作为计算引擎支撑各类复杂业务场景需求，离线计算集群基本每天运行30+万左右的 Spark 作业，包括任务调度平台的 ETL 任务、Kyuubi 提交的 Adhoc 作业等，其作业的 Shuffle 数据规模能够达到30PB以上，同时单个作业的 Shuffle 量最大规模有几百TB。同时 Shuffle 算子作为大数据计算引擎中间数据处理最重要的算子，Shuffle 的稳定性关系着线上大量离线作业的可靠性和性能。因此，对于海量的 Shuffle 中间数据和复杂多变的计算环境来说，保证 Shuffle 数据处理的稳定性对线上作业的稳定性和运行效率尤为重要。
以ChatGPT为代表的生成式AI大火以来，LLM（Large Language Model）已经成为了各个企业的焦点关注对象。随着AI业务的快速发展，当前LLM训练参数已达万亿级别，而要完成如此量级的参数训练，通常需要拥有千卡、甚至万卡级别的GPU资源。然而只有GPU资源是不够的，更需要有一张零丢包、低时延、高吞吐的AI计算网络将各GPU连接在一起为业务提供高稳定的计算训练服务。 B站网络团队基于业务需求和特性出发，并结合业界对于AI网络的落地实践方案，设计并落地了自己的AI计算网络。本文将简单介绍B站网络团队在建设AI计算网络上的一些设计关键因素和选择。
推荐系统的模型，通过学习用户历史行为来达到个性化精准推荐的目的，因此模型训练依赖的样本数据，需要包括用户特征、服务端推荐的视频特征，以及用户在推荐视频上是否有一系列的消费行为。 推荐模型数据流，即为推荐模型提供带特征和优化目标的训练样本，包括两个模块，一是Label Join模块，负责用户行为的采集。二是feature extract模块，从原始日志中抽取特征，并基于用户行为计算模型优化的目标label。 在B站早期的推荐模型数据流架构中，如下图所示，采样两阶段特征补齐设计。Label Join模块除了完成用户行为的采集，还需要查询实时特征，补齐训练样本依赖的部分原始特征数据，一般是秒级更新的实时特征，存储在Redis中。而Feature Extract模块在计算样本之前，补齐另外一部分原始特征数据，一般是批量更新的特征数据，存储在KFC中（B站自研的KV系统）
动画在影视工业中是相当重要的一个领域。尽管当前先进的视频生成模型比如Sora、可灵或智谱清影在生成三次元视频上取得了成功，他们在处理动画视频时却缺乏同样的效果。此外，由于独特的艺术风格、打破物理规则以及夸张的动作，评估动画视频生成结果也是一个巨大的挑战。 在我们的工作中，我们提出了一个专为动漫视频生成设计的综合系统AniSora，包括数据飞轮、可控的生成模型和一个评估基准。在数据飞轮提供了10M以上高质量数据的支持下，生成模型加入了一个时空掩码模块来实现关键的动画制作功能比如图生视频、视频插帧和局部图像引导动画。我们收集了一个包含了948个不同的动画视频的评估基准。基于VBench指标和人工双盲测试都证明了生成视频在人物和动作上的一致性，取得了在动画视频生成领域行业领先的结果。 业务上，我们的视频生成模型赋能了动态漫内容制作，已经有超过10部自有IP作品运用了AI动态漫能力。相比于人工制作需要专业人员和较长工期，AI动态漫实现了低成本、低门槛、高效率的剧集内容制作，并在多个平台突破千万播放。
随着B站用户数量的迅速增长和业务的不断扩展，数据中心的规模和复杂性也在不断增加。为了满足新服务器上架交付、系统安装和服务器初始化配置等新交付装机需求，早期采用了传统的PXE装机方案。然而随着IDC和边缘服务器的规模持续增长，以及业务场景的多样化，传统的装机方案逐渐暴露出灵活性不足和效率低下的问题。 在这种背景下，我们开始探讨如何构建一个能够满足多样化需求的装机系统，以应对大量新交付装机、重装机、机房搬迁、CDN服务器装机等各类复杂场景。本文将详细介绍B站装机系统的演进过程，以新交付装机和复杂网络装机两个装机场景为例，重点探讨我们在装机实践中面临的挑战和提出的解决方案。
在传统的大数据元数据管理系统中，以 HiveMetaStore 为核心的架构存在诸多问题和挑战。随着数据湖大规模应用、AI 数据大量增长、数据安全与数据治理被更加被重视，我们难以基于原有的架构或组件实现一套统一的元数据管理系统，进而解决数据孤岛、统一权限，多维度数据治理等问题。因此，在 B 站 我们引入了 Gravitino，本次分享将介绍 Gravitino 在 b 站的最佳实践。其中包括了统一了多种数据源的元数据视图，统一跨数据源任务的 schema 信息，并且基于其中的 Fileset 概念对非结构化数据进行管理与数据治理，取得了可观的收益。
评论是 B站生态的重要组成部分，涵盖了 UP 主与用户的互动、平台内容的推荐与优化、社区文化建设以及用户情感满足。B站的评论区不仅是用户互动的核心场所，也是平台运营和用户粘性的关键因素之一，尤其是在与弹幕结合的情况下，成为平台的标志性特色。 在社会热点事件发生时，评论区的读写流量会急剧增加，直接影响业务运行，对用户体验、内容创作和社区文化等多个方面产生负面影响，所以评论服务的稳定性至关重要。 评论系统对缓存命中率要求非常高，一旦发生缓存失效，大量请求会直接访问 TiDB，如果 TiDB 出现问题，将导致评论服务不可用。所以评论需要构建一套可靠的容灾系统，并具备自动降级能力，以提升评论服务的整体稳定性。
强化学习（Reinforcement Learning, RL）有两种基础的训练范式：在线强化学习（Online RL）和离线强化学习（Offline RL）。在线强化学习需要让智能体和环境进行交互，利用收集到的数据同步进行训练，但在环境中进行探索的开销很大；离线强化学习不需要和环境交互，直接利用已有的离线数据进行训练，但这种范式训练的智能体会受限于离线数据的质量和覆盖范围。 基于此，研究者提出了离线到在线强化学习（Offline-to-online RL）训练范式，先利用已有的离线数量训练得到离线策略，然后将其应用到在线环境进行少量步数的微调。这种范式相比于前两者，一方面通过收集少量的在线数据，能够突破离线数据的限制，更贴近实际场景；另一方面在线阶段的微调是以离线策略为起点，相比于从零开始的在线强化学习，只需要非常少量的交互就能快速收敛。这一研究领域主要研究两个问题，一个是分布偏移引起的性能下降，就是如果直接将离线策略应用到在线环境进行微调，会在微调初期出现性能的急剧下降；另一个是在线优化效率，由于在线交互的开销很大，需要用尽可能少的交互次数实现尽可能大的性能提升
