观众对画质的追求越来越高，有需求就有市场，主播也使用越来越高的画质进行直播。在这个过程中，直播平台需要负担的带宽成本也迅速攀升。 事实上，网络带宽的支出在技术成本侧是占比最大的部分。为了将成本控制在一个可以接受的范围，各直播平台纷纷使用P2P技术来降低服务器带宽。云服务提供商也提供了成套的解决方案，可以为没有自研能力、无法负担自研成本或短时间内无法完成自研的直播平台提供快速接入。 随着B站内部对HLS协议直播的传输研发完成度不断提高，自研P2P的前提条件具备了。HLS本身是一种切片式的直播传输格式，具体细节可以参考前面的《HLS直播协议在B站的实践》。因为切片是静态文件，所以可以通过HTTP带Range头的请求下载这个文件的指定部分。如果让不同的观众下载同一个切片文件的不同部分，然后这些观众之间再互相交换一下数据，大家就都有完整的数据了，而服务器事实上只传了一份数据出去，带宽成本就大幅度降低了。
数据质量是基于大数据衍生的应用有效与否的重要的前提和保障之一。为了能在大数据上面孵化出更加有深度，更加有竞争力的应用，以及B站高速发展的业务都需要我们数据平台能提供实时的，准确的，可以被信赖的数据。 而另一方面，数据平台要向终端用户提供可以信赖的数据，又依赖于整个数据加工链路环境的稳定迭代和健康发展，这涉及到数据平台模型本身的质量，业务调度的可靠，资源调度的高效，以及各种执行引擎的高效协作等等，最后所有这些大数据基础组件的稳定又离不开PAAS, IAAS等基础服务的稳定。 总之，可信赖的数据质量是大数据平台核心竞争力的体现，是大数据航母战斗群的预警机。数据质量团队的背后是大兵团级别的组织、协作和保障工作。数据质量的高可信度依赖于业务模型团队，数据质量平台，业务调度团队，计算引擎团队，和各种存储和搜索查询引擎等兄弟舰队通力合作和鼎力支持。
1. B站的直播间作为整个APP中交互最为复杂的单页面之一，其承担的业务量已经不亚于一个小型APP。对比APP的结构会发现许多相同处，但与组成APP的各个独立Activity不同，直播间由各个独立的视图组成。 2. 业务逻辑基于MVVM的设计分为三层（Service即M层），理想状态下各个业务间的交互是内聚的，各业务间不会感知到其他业务的存在，View显示需要的数据和状态都由各自对应的ViewModel提供。 3. 现实情况中业务交互并没有那么理想，直播间中的一个View显示的数据会受到其他业务的数据、状态影响，因此一个View除了需要处理自己内聚的逻辑为还需要关心其他View的数据变化。
众所周知，B站在不知不觉间已经成为一家拥有相当体量的互联网公司。拥有自己的IDC的小破站，每年都会对以服务器为代表的硬件设备进行选型迭代。服务器选型评估指标有很多，其中性能是最重要的指标之一。服务器性能涉及服务器硬件、操作系统以及业务应用等多个方向，为准确评估服务器硬件性能，服务器硬件与操作系统层面的性能优化也是B站系统组工作重要的组成部分。这篇文章B站系统组就基于单路AMD Milan CPU服务器，粗浅的介绍一下服务器基础性能调优与评测的工作。希望能抛砖引玉，共同学习，将服务器性能调优与评测这个长线工作不断迭代更新下去。
随着短视频行业的蓬勃发展，全民UP主时代已经到来，用户需要的创作手法日新月异，对创作工具的要求越来越高。而音视频质量评估偏主观，复杂功能场景的组合爆炸，使得评测效能提升与传统的人工评测形成了巨大矛盾，因此需要与时俱进，搭建手段丰富且高效的质量评估体系。 我们的实施路径如下，通过行业交流与调研，快速确定评测方案的选型并开展落地 ，再针对本土化过程中遇到的问题，逐步探索形成现在的B站特色音视频质量评估体系。因篇幅有限，本文将着重说明画质在B站的评测实践，主要以生产端为例。
B站基于Elastic Stack的日志系统（Billions） 从2017建设以来， 已经服务了超过5年，目前规模超过500台机器，每日写入日志量超过700TB。 ELK体系是业界最常用的日志技术栈，在传输上以结合规范key的JSON作为传输格式，易于多种语言实现和解析，并支持动态结构化字段。存储上ElasticSearch支持全文检索，能够快速从杂乱的日志信息中搜寻到关键字。展示上Kibana具有美观、易用等特性。 随着业务系统的高速发展，日志系统的规模也随之快速扩展，我们遇到了一系列的问题，同时可观测业界随着OpenTelemetry规范的成熟，推动着我们重新考量，迈入下一代日志系统。
Lancer是B站的实时流式传输平台，承载全站服务端、客户端的数据上报/采集、传输、集成工作，秒级延迟，作为数仓入口是B站数据平台的生命线。目前每日峰值 5000w/s rps, 3PB/天, 4K+条流的数据同步能力。
