数据驱动理念已被各行各业所熟知，核心环节包括数据采集、埋点规划、数据建模、数据分析和指标体系构建。在用户行为数据领域，对常见的多维数据模型进行信息提炼和模型整合，可以形成一套常见的数据分析方法来发现用户行为的内在联系，能更好洞察用户的行为习惯和行为规律，帮助企业挖掘用户数据的商业价值。 行业内最早可追溯到Google Analytics埋点分析工具，国内较早开始这方面研究的是百度大数据分析平台；随着15年后国内大数据兴起，神策的用户行为分析平台、GrowthingIO的增长平台等独立数据分析平台公司相继成立；18年后一些发展较快的大厂经过几年数据积累也有了自己的分析平台，例如美团点评的Ocean行为分析平台、字节的火山引擎增长分析平台等等。 只有当数据达到一定规模才更适合用科学化的方法来提升数据分析效率，如前面所述，虽然Google和百度在这块最早探索，但后面一些互联网公司也是过几年才有自己的产品，即数据产品的发展需要与实际数据规模和业务发展相符。B站最早从19年开始关注大数据建设，到现在已经有一套较为成熟的数据产品——北极星，可以实现对用户行为数据进行埋点采集、埋点测试、埋点管理
时光匆匆，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头的请求下载这个文件的指定部分。如果让不同的观众下载同一个切片文件的不同部分，然后这些观众之间再互相交换一下数据，大家就都有完整的数据了，而服务器事实上只传了一份数据出去，带宽成本就大幅度降低了。
