B站直播平台近年来迅猛发展，为了吸引更多观众和优质主播，直播平台通常会推出多样玩法（包括节日活动、任务、榜单、抽奖），以激励用户参与和创造高质量内容，拉动平台营收，丰富直播生态。诸多玩法都存在一个共同的场景：给用户发放奖励。为了满足奖品种类以及发放场景的多样性，我们设计了通用奖励系统，用于支撑各类上层业务。本文将介绍直播奖励系统的技术架构，从需求分析到实现细节，全面解析其背后的技术方案。
直播业务具有实时性强，复杂度高，排查链路长，影响面大等特征，线上问题如果不能立刻排查处理，分分秒秒都在影响用户的观看体验、主播的收入。 但各端的问题可能都只是表象，例如，一个看似简单的画面卡顿问题，可能涉及到编码器配置、网络带宽分配、服务器负载等多个方面，各个团队经常在等待合作方的反馈，一整套流程下来，一个线上问题的定位可能要消耗掉数小时的人力。 我们迫切的需要一套高效的跨端实时排障系统！
PC直播姬中的直播素材之一——投屏源可与安卓或iOS移动端应用（直播姬、粉版）配合使用，将移动端画面投射到PC直播姬中。投屏源最初仅支持无线投屏，即通过局域网 WiFi传输，但这样的链路会受到网络质量影响，而且如果Windows计算机和移动设备不在同一网段或者配置了局域网隔离，那么就无法投屏成功。 无线投屏的这些缺点，使用USB有线投屏即可克服。本文基于Windows平台，介绍计算机与安卓/iOS通过USB交换数据的实现方式。
2023年8月中旬文档画中画特性跟随chrome116版本发布，基于该功能特性，我们于2023年10月中旬启动了B站跨页面播放队列功能的开发与功能灰度，并于2024年6月中旬完成了灰度全量。目前该功能入口位于B站网页端的首页，点击首页右侧对应按钮即可打开跨页面播放队列小窗。队列中的视频为稍后再看列表中的视频，在小窗开启情况下，该列表内容会实时响应B站主场景网页中的添加/移除稍后再看操作。
视频场景分类算法是计算机视觉领域研究的热门内容，并作为复杂任务系统的前置算法，能够应用于我们多媒体实验室多项业务，如内容自适应转码、画质智能修复和视频质量评估（VQA）中。通过针对不同类型的图像自适应抉择不同的模型，从而精准有效提升算法在业务中的实际效果。语言、视觉是人类感知世界最基本的方法，也是人工智能理解世界的两大支柱。多模态是结合了图像、文本、音频等多种数据类型的一种技术方案。该技术不仅提高了模型的泛化能力，还扩展了人工智能技术的应用方向，如图像分类、图像问答、文本图像生成等。本文研究了多模态算法在多媒体系统中进行场景分类的应用，探讨了实施过程中的挑战并给出对应的解决方案。
OLAP场景是大数据应用中非常重要的一环，能够快速、灵活地满足业务各种分析需求，提供复杂的分析操作和决策支持。B站主流湖仓使用Iceberg存储，通过建表优化可以实现常规千万级的指标统计秒级查询，这样就能快速搭建可视化报表，但当数据量达到亿级、需要交叉分析维度复杂多表情况下，想要支持秒级就变得困难。因此B站数据分析或者数据开发同学为了能有秒级响应的报表，需要通过ETL grouping sets 提前设计要参与多维分析的维度和指标，然后在ADS层离线计算好对应的数据cube。这有点类似Kylin的预计算模式，区别是查询效率和查询SQL复杂度要更高，毕竟Kylin底层是KV存储并且做了SQL解释器，而原始grouping sets模式得让下游自己选cube切片。比如Push业务DWB表几十亿数据量，想要快速支持十几个维度和十几个指标秒级交叉分析，只能开发提前配置好要参与分析的维度组合，在可视化界面也需要提前说明只支持这几个维度组合。
在 2023 年的华为开发者大会（HDC）上，华为预告了一个全新的鸿蒙系统 Harmony Next 版本。与之前的鸿蒙系统不同，Harmony Next完全摒弃了对 AOSP 的兼容，彻底基于 OpenHarmony 开源鸿蒙实现。这意味着该系统将仅支持鸿蒙原生应用，Android 应用将不再允许在其上运行。 华为用户在哔哩哔哩的用户生态中一直占据着较大的比例。为了提供更好的用户体验，支持更多的应用生态，哔哩哔哩在去年年底启动了哔哩哔哩鸿蒙原生应用的开发。在对 Harmony Next 系统进行初步调研后，我们发现其从开发语言到运行环境到开发方式，都与 Android 平台完全不同。适配 Harmony Next 就意味着重新开发一个独立的 App 端，无论是短期开发还是长期迭代，这都是一件成本极高的事情。于是我们面临一个问题：是否有跨平台开发的手段来复用现有生态的代码，从而减少开发成本？
随着业务规模的不断扩张和日常需求的快速迭代，即使是最优秀的业务架构、最完善的生产体系也无法确保系统100%的可用性，参考墨菲定律，会出错的事总会出错，故障在生产环境中不可避免。为了在故障发生时能够快速定界定位，采取有效措施止损，避免同根因故障重复发生，我们需要对故障全生命周期进行统一管理。 故障应急体系一般包括以下环节，故障预防、故障发现、故障定位、故障恢复、故障复盘及改进，其中故障预防阶段可以参考B站安全生产专项建设实践，这里不再赘述，本文将围绕故障发生后，对稳定性保障带来的挑战，如何去破局，以及如何沉淀建设平台能力，介绍B站面向故障的应急响应中心建设。
搜索是B站的重要基础功能，需要对包括视频、评论、图文等海量的站内优质资源建立索引，处理来自用户每日数亿的检索请求。离线索引数据的正确、高效产出是搜索业务的基础。我们在这里分享搜索离线架构整体的改造实践：从周期长，流程复杂的手工构建流程，改造为高容量、高性能、易迭代的分布式建库架构的过程。
大约70%的故障都是由变更引起的，B站也深受其害。在经历了多起由变更引发的事故后，B站设计并实施了变更防控平台，从技术支撑能力、技术落地、跨领域赋能、组织文化建设等多方面入手，以期变被动应对为主动防御。目前，该平台已接入60+平台、400+场景，每天执行超过1000次变更检测，日拦截100+次潜在故障。自平台上线后，B站变更类事故占比得到有效下降，实现业务稳定性和效率的双重提升。详细的解决策略和方法，请参阅文章正文。
