本地开发存在编译慢、机器发热、卡死、阻塞开发等问题。介于此前移动端已有庞大的 CI 构建集群，我们探索出一种新的开发编译方式——云编译。

随着业务不断发展，B站的评论系统逐渐组件化、平台化；通过持续演进架构设计，管理不断上升的系统复杂度，从而更好地满足各类用户的需求。

在 2021 年时我们通过数据分析发现：在电脑端有越来越多用户的电脑屏幕切换成了大屏，现有 B 站的网页设计风格已经难以在宽屏设备上高效率的做内容分发，因此我们决定对 B 站网页版的整体视觉风格做一个大的更新。

一位业务部门的同事找到我们，咨询了一个经典问题：

「需求方经常说我们做的报表看起来数据不准，有什么办法吗？」

为了解释这个问题，我以我们团队在数据质量管理中积累下来的方法，为他写下四行字：

• 数据质量期望——业务需求想要把数据质量保障到什么样的标准
• 数据质量测量——怎么评估数据质量水平的高低、是否达到标准
• 数据质量保障——为提升质量水平，达到质量期望，具体的保障实施动作和内容
• 数据质量运营——如何通过数据化运营，提高保障的成果与效率

这四行字，概括了我们在数据质量管理执行中的理论大纲。

以Flink为基础的实时计算在B站有着广泛而深入的应用。

回顾弹幕工程建设的发展历程，大致可以分几个阶段：

1. 基础能力：在高并发、热点场景下，保证弹幕服务的稳定和高可用 、
2. 负向治理：以管控为目标，通过删除、自见、打薄等手段过滤低质弹幕内容
3. 正向推荐：以优化视频消费体验为目标，筛选优质弹幕内容上屏展示

这三个阶段的目标始终在并行推进，在1和2的基本问题完成之后，作为B站的特色功能和社区文化重要载体，弹幕业务在承接基础功能之外也需要持续探索优化消费体验的能力。这也就必须在稿件维度优选的基础上通过用户特征交互获得更大的策略空间，建设千人千面的弹幕推荐能力。

这个过程离不开工程、算法、产品等多个团队的倾力合作，本文会以工程团队的视角重点介绍工程架构对推荐系统的能力支持。

本期内容由B站大数据平台工具开发团队从平台总体简介、数据开发体系、数据开发后续工作三个方面讲解哔哩哔哩大数据平台建设之路。

S12决赛尾声，伴随DRX成员们从眼泪到荣耀的升华，技术保障团队的心也松弛下来，逐渐把目光从监控中挪开。一方面分享胜利的喜悦，一方面也为实现了“边喝茶边保障”的目标而高兴。

近年来，随着系统架构逐渐向微服务架构演进，开发效率以及系统扩展性大幅提高，服务之间的依赖所带来的不确定性也成指数级增长。

B站作为今年S12的官方直播渠道，哔哩哔哩赛事直播间实时人气一度超过3.1亿，如何保障整个S赛洪峰流量下系统的稳定性和流畅性，给我们带来了巨大挑战。

在介绍Presto在B站的实践之前，先从整体来看看SQL在B站的使用情况，在B站的离线平台，核心由三大计算引擎Presto、Spark、Hive以及分布式存储系统HDFS和调度系统Yarn组成。

如下架构图所示，我们的ADHOC、BI、DQC以及数据探查等服务都是通过自研的Dispatcher路由服务来进行统一SQL调度，Dispatcher会结合查询语句的语法特征，库表读HDFS的数据量以及引擎的负载情况等因素动态决定选择最合适的计算引擎执行，如果是Hive的语法需要用Presto执行的，目前利用Linkedin开源的coral对语句进行转化，如果执行的SQL失败了会做引擎自动降级，降低用户使用门槛；调度平台支持Spark、Hive、Presto cli的方式提交ETL作业到Yarn进行调度；Presto gateway服务负责对Presto进行多集群管理和路由；我们通过Kyuubi来提供多租户能力，对不同部门管理各自的Spark Engine，提供adhoc查询；目前各大引擎Hive、Spark、Presto以及HDFS都接入了Ranger来进行权限认证，HDFS通过路径来控制权限，计算引擎通过库/表来控制权限，并且我们通过一套Policy来实现表, column masking和row filter的权限控制；部分组件比如Presto、Alluxio、Kyuubi、Presto Gateway、Dispatcher, 包括混部Yarn集群都已经通过公司k8s平台统一部署调度。

元数据是数据平台的衍生数据，比如调度任务信息，离线hive表，实时topic，字段信息，存储信息，质量信息，热度信息等。在数据平台建设初期，这类数据主要散落于各种平台子系统的数据库中，例如HiveMetaStore,调度系统db等，在这个时期数据平台主要以服务业务数据需求为主，平台也以管理表，写ETL，配置调度这类功能性需求作为重点，对于这些散落元数据的收集与统一管理并没有太过强烈的诉求。

随着数据平台业务规模的增长，平台会沉淀大量的数据表，调度任务等元数据。由于前期快速的业务发展产生大量数据管理成本，存储计算成本。此时会逐步产生诸如模型规范治理、模型变更影响，指标异动定位，重复建设治理等需求场景。基于这些场景需求，此时数据平台仅提供数据开发相关的功能便难以满足业务需求，需要建设以数据地图（找数），血缘地图（定位数据链路），影响分析工具，资产看板，治理工具 等一系列偏向于事后的信息查询、治理相关产品工具。

由于先前元数据的散落，导致系统间数据相互耦合，边界不清楚，无法以全局视角观察分析平台数据资产，无法串联数据之间的生产加工关系。于是建设起完善可靠的元数据服务成为后续满足数据发现，数据治理业务的关键。

数据平台部作为B站的基础部门，为B站各业务方提供多种数据服务，如BI分析平台，ABTest平台，画像服务，流量分析平台等等，这些服务、平台背后都有海量数据的取数查询需求。伴随着业务的发展，取数服务也面临越来越多的挑战：

1. 需求多、人力紧张，越来越多业务基于数据驱动来做运营，相关的取数需求如：指标查询、UP主、稿件等明细数据的个性化查询需求越来越多，导致在需求响应上，有限的人力跟不上业务发展。
2. 系统架构重复建设：基于Lambda，Kappa的大数据应用架构在B站有一些应用积累，但非平台化，导致在新场景支持上，出现重复建设，增加了维护成本。
3. 性能优化成本高：在满足多种取数场景需求上，数据服务引入多种引擎，比如Elasticsearch、ClickHouse、HBase、MongoDB，这些引擎都需要查询定制优化，增加了研发成本。

基于这些问题的思考，我们在取数服务上经过了2次大的架构升级，不断探索服务化，平台化之路，下面介绍我们在这方面的工作，欢迎大家一起学习交流。

直播行业从传统的娱乐直播发展到教育直播、电商直播等形式，产生了很多新的玩法。

在webrtc技术栈里面，STUN协议虽然不是非常的引人注目，但却是非常重要的一个部分。

为了给用户提供更好的视频观看体验，B站已研发出很多先进的视频图像分析与处理算法。