公司：哔哩哔哩
bilibili，音译哔哩哔哩，是总部位于中华人民共和国上海市的一个以ACG相关内容起家的弹幕视频分享网站，故简称及通称B站[f]。此外，bilibili的前身为视频分享网站Mikufans，并由网友“⑨bishi”（徐逸）于2009年6月26日创建。Mikufans建站的初衷是为用户提供一个稳定的弹幕视频分享网站，其后于2010年1月24日改为“bilibili”。
bilibili的内容随着发展渐渐不仅限于ACG，主要分区分为番剧、国创、放映厅、纪录片、漫画、专栏、直播、课堂、动画、音乐、舞蹈、游戏、知识、数码、生活、美食、VLOG、鬼畜、时尚、娱乐、影视、电影、电视剧、音频，除此之外亦有会员购、专题中心、全区排行榜、活动中心、能量加油站、社区中心、工坊集市、小黑屋、音乐PLUS、游戏中心（特指由哔哩哔哩代理登陆接口的游戏发布平台）、游戏赛事的区域。除了视频外哔哩哔哩还运营有《命运/冠位指定》、《崩坏学园2》等多部游戏。而现在网站标题中含有“( ゜- ゜)つロ 干杯~”的颜文字以做宣传。除此之外bilibili也被用户称为小破站、小电视。至2015年，75%的用户年龄在24岁以下，是年轻人的聚集地。
至2023年3月31日，B站月均活跃用户达3.15亿，移动端月均活跃用户达2.76亿，分别增加31%及33%。在用户健康增长的基础上，B站也在不断加快商业基础设施建设，提高社群服务管控能力。B站月均付费用户增长至2,720万，同比增长33%，付费率提升至9.3%。不过做大的同时，bilibili的成长空间也逐渐饱和，影视会员与视频业务在2022年营运呈现亏损扩大状态，年轻新人大量涌入却未能利用，而部分老用户指B站感觉变了，对现在的评论管理与风气感到不满，同时其up主也因为投稿不顺、分成不足等问题，开始出现部分停更现象。对此B站开始进行裁员降本增效，重新把精力投入游戏与商业制作上，项目2024年达到盈亏平衡。
B站HTTPDNS自研降本之道
公司目前使用的HTTPDNS服务是商业的HTTPDNS服务。
AF_XDP在B站CDN节点QUIC网关的应用和落地
目前B站已在自建视频CDN下行中全量部署了基于QUIC和HTTP/3协议的网关服务（以下简称QUIC网关）。和TCP网关相比，QUIC网关在视频首帧、卡顿率以及加载失败率等常见的QoE/QoS指标方面都有不错的收益。
B站数据服务中台建设实践
随着公司业务的发展，对于数据的需求会越来越多。怎么在业务系统中高效的使用数据，让业务系统处理大数据时化繁为简，数据服务化基本是必经之路。
推荐算法在用例排序优化上的应用
随着持续集成和敏捷开发的不断发展，移动应用的发布变得越来越频繁。以B站应用为例，主站粉版APP每周都会发布一次新的版本，主站HD应用的Android端与ipad端每周交替发布新的版本。
B站公网架构实践及演进
B站基础网络团队本着社区优先的理念，持续优化互联网接入网络架构，近2年内根据IDC规模发展和业务需求，对公网架构进行了有序升级改造，从稳定性、经济性等方面为B站业务提供了坚实保障。
哔哩哔哩Android打包优化与云编译
本地开发存在编译慢、机器发热、卡死、阻塞开发等问题。介于此前移动端已有庞大的 CI 构建集群，我们探索出一种新的开发编译方式——云编译。
B站评论系统架构设计
随着业务不断发展，B站的评论系统逐渐组件化、平台化；通过持续演进架构设计，管理不断上升的系统复杂度，从而更好地满足各类用户的需求。
哔哩哔哩 Web 首页重构——回首2021
在 2021 年时我们通过数据分析发现：在电脑端有越来越多用户的电脑屏幕切换成了大屏，现有 B 站的网页设计风格已经难以在宽屏设备上高效率的做内容分发，因此我们决定对 B 站网页版的整体视觉风格做一个大的更新。
B站的数据质量管理——理论大纲与实践
一位业务部门的同事找到我们，咨询了一个经典问题：
「需求方经常说我们做的报表看起来数据不准，有什么办法吗？」
为了解释这个问题，我以我们团队在数据质量管理中积累下来的方法，为他写下四行字：
- 数据质量期望——业务需求想要把数据质量保障到什么样的标准
- 数据质量测量——怎么评估数据质量水平的高低、是否达到标准
- 数据质量保障——为提升质量水平，达到质量期望，具体的保障实施动作和内容
- 数据质量运营——如何通过数据化运营，提高保障的成果与效率
这四行字，概括了我们在数据质量管理执行中的理论大纲。
Apache Flink运行时在B站的稳定性优化与实践
以Flink为基础的实时计算在B站有着广泛而深入的应用。
百亿数据个性化推荐：弹幕工程架构演进
回顾弹幕工程建设的发展历程，大致可以分几个阶段：
- 基础能力：在高并发、热点场景下，保证弹幕服务的稳定和高可用 、
- 负向治理：以管控为目标，通过删除、自见、打薄等手段过滤低质弹幕内容
- 正向推荐：以优化视频消费体验为目标，筛选优质弹幕内容上屏展示
这三个阶段的目标始终在并行推进，在1和2的基本问题完成之后，作为B站的特色功能和社区文化重要载体，弹幕业务在承接基础功能之外也需要持续探索优化消费体验的能力。这也就必须在稿件维度优选的基础上通过用户特征交互获得更大的策略空间，建设千人千面的弹幕推荐能力。
这个过程离不开工程、算法、产品等多个团队的倾力合作，本文会以工程团队的视角重点介绍工程架构对推荐系统的能力支持。
哔哩哔哩大数据建设之路—数据开发篇
本期内容由B站大数据平台工具开发团队从平台总体简介、数据开发体系、数据开发后续工作三个方面讲解哔哩哔哩大数据平台建设之路。
直播营收场景技术保障实践
S12决赛尾声，伴随DRX成员们从眼泪到荣耀的升华，技术保障团队的心也松弛下来，逐渐把目光从监控中挪开。一方面分享胜利的喜悦，一方面也为实现了“边喝茶边保障”的目标而高兴。
直播混沌工程之故障演练实践总结
近年来，随着系统架构逐渐向微服务架构演进，开发效率以及系统扩展性大幅提高，服务之间的依赖所带来的不确定性也成指数级增长。
S12技术保障内幕揭秘-如何实现“喝茶保障”
B站作为今年S12的官方直播渠道，哔哩哔哩赛事直播间实时人气一度超过3.1亿，如何保障整个S赛洪峰流量下系统的稳定性和流畅性，给我们带来了巨大挑战。
Presto在B站的实践
在介绍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平台统一部署调度。