时光匆匆，2022年2月21日诞生的哔哩哔哩技术团队公众号已经走过了第一个春秋。这一年我们共发布了101篇原创文章，在大家的喜爱和支持下，也有了10W+阅读量的文章，今天为各位送上2022年最受欢迎的20篇文章，请大家品读分享，也可以关注留言你未来想看到的内容。
目前B站已在自建视频CDN下行中全量部署了基于QUIC和HTTP/3协议的网关服务（以下简称QUIC网关）。和TCP网关相比，QUIC网关在视频首帧、卡顿率以及加载失败率等常见的QoE/QoS指标方面都有不错的收益。另一方面，由于QUIC使用了更复杂的协议头和解析规则，此外Linux内核对UDP收发包的性能也不甚理想，这些方面都使得QUIC占用了更多的CPU负载，最终导致了更多资源成本的消耗。 为了给B站用户提供更稳定流畅的视频观看体验，同时降低成本，网络协议组团队通过技术选型，排除了DPU方案，决定使用AF_XDP技术来优化QUIC网关的收发包效率，减少CPU负载。
随着持续集成和敏捷开发的不断发展，移动应用的发布变得越来越频繁。以B站应用为例，主站粉版APP每周都会发布一次新的版本，主站HD应用的Android端与ipad端每周交替发布新的版本。在应用快速迭代的同时，QA需要在规定时间内进行大量的回归测试以保证应用的质量。一方面，大量的测试用例需要耗费较多的人力和时间，另一方面，BUG检出时间的不确定性导致给予研发修复的时间并不是很充足。因此急需一种技术来帮助QA快速筛选出高风险用例，将BUG的发现时间提前，从而给研发更多时间去修复BUG。在此背景下，我们经过调研后，选择了使用测试用例排序优化技术(Test Case Prioritization，以下简称TCP)来帮助QA对测试用例进行优先级排序，提高测试效率。
以Flink为基础的实时计算在B站有着广泛而深入的应用。目前B站的Flink作业主要运行在三种集群环境下：纯物理机部署的YARN集群、为了提高Kafka集群资源利用率而和Kafka混部的YARN集群以及为了提高线上服务器而和K8S混部的YARN集群（这部分有计划在不远的将来使用Flink On K8S部署方式代替）。其中纯物理机YARN集群使用纯SSD盘的统一机型的服务器，包含1000+台服务器；和Kafka混部的集群目前为Flink提供了2000+ cores；和线上的K8S混部的集群已经使用了6000+ cores，并且还在持续增加。在业务方向上，B站的Flink已经应用在了包括AI、广告、数仓、数据传输和其它的很多业务上。目前B站Flink作业的最大并行度为2000。下图展示了B站实时应用的整体架构及Flink Runtime的工作范围。
S12决赛尾声，伴随DRX成员们从眼泪到荣耀的升华，技术保障团队的心也松弛下来，逐渐把目光从监控中挪开。一方面分享胜利的喜悦，一方面也为实现了“边喝茶边保障”的目标而高兴。 B站在本次直播为了提升用户体验，开启了送礼特效。以送礼为核心的营收场景是业务主推的方向之一。为此团队的小伙伴们在业务需求繁忙的情况下，同时做了大量的准备和优化。 本文我们聚焦于以写为主的送礼场景，对我们的技术保障思路做个简单的总结。聚焦到一个问题，那就是：高写场景该如何做技术保障？
为了给用户提供更好的视频观看体验，B站已研发出很多先进的视频图像分析与处理算法。在视频转码任务中，这些算法既可以改善视频画质，也可以促进转码效率的提升，从而实现更高清、更流畅的视频效果。研发的算法种类繁多，用途各异，同时B站不同业务对于算法的要求也各不相同。为了能够对各种基本算法进行高效部署和管理，同时向各个业务方提供简单灵活且统一的调用接口，B站研发了一套功能强大的视频图像分析与处理引擎——BANG（Bilibili video/image Analyzing and processiNg enGine）。
观众对画质的追求越来越高，有需求就有市场，主播也使用越来越高的画质进行直播。在这个过程中，直播平台需要负担的带宽成本也迅速攀升。 事实上，网络带宽的支出在技术成本侧是占比最大的部分。为了将成本控制在一个可以接受的范围，各直播平台纷纷使用P2P技术来降低服务器带宽。云服务提供商也提供了成套的解决方案，可以为没有自研能力、无法负担自研成本或短时间内无法完成自研的直播平台提供快速接入。 随着B站内部对HLS协议直播的传输研发完成度不断提高，自研P2P的前提条件具备了。HLS本身是一种切片式的直播传输格式，具体细节可以参考前面的《HLS直播协议在B站的实践》。因为切片是静态文件，所以可以通过HTTP带Range头的请求下载这个文件的指定部分。如果让不同的观众下载同一个切片文件的不同部分，然后这些观众之间再互相交换一下数据，大家就都有完整的数据了，而服务器事实上只传了一份数据出去，带宽成本就大幅度降低了。
数据质量是基于大数据衍生的应用有效与否的重要的前提和保障之一。为了能在大数据上面孵化出更加有深度，更加有竞争力的应用，以及B站高速发展的业务都需要我们数据平台能提供实时的，准确的，可以被信赖的数据。 而另一方面，数据平台要向终端用户提供可以信赖的数据，又依赖于整个数据加工链路环境的稳定迭代和健康发展，这涉及到数据平台模型本身的质量，业务调度的可靠，资源调度的高效，以及各种执行引擎的高效协作等等，最后所有这些大数据基础组件的稳定又离不开PAAS, IAAS等基础服务的稳定。 总之，可信赖的数据质量是大数据平台核心竞争力的体现，是大数据航母战斗群的预警机。数据质量团队的背后是大兵团级别的组织、协作和保障工作。数据质量的高可信度依赖于业务模型团队，数据质量平台，业务调度团队，计算引擎团队，和各种存储和搜索查询引擎等兄弟舰队通力合作和鼎力支持。
