公司:哔哩哔哩
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年达到盈亏平衡。
领域驱动点播直播弹幕业务合并设计实践
在业务早期阶段,一个人长期负责一个项目,系统复杂度也不高。上述问题在这一阶段不重要,过度强调设计模式和规范反而会降低效率,影响业务快速启动。
然而当业务逐渐趋向成熟,出现部分业务必须多人合作,同时一个人又需要负责多个业务的情形下,高效上手、交接、维护、协作成了必选项,以上问题亟待解决。
中后台平台化探索和演进
从技术层面看,大量的后台都存在基础能力缺失,或者重复建设,同时技术架构也各不相同。
哔哩哔哩数据服务中台建设实践
烟囱式开发会有比较多的弊端。弊端一:重复建设,包括重复计算、重复存储,造成资源浪费,同时功能上的重复建设也会造成人力资源浪费。弊端二:交付效率低,不同的系统、不同的开发同学对接不同的数据源,数据服务质量不可控,整个对接的标准也不够统一。
DAGW:数据聚合网关的探索与实践
本文对B站访问最频繁的视频详情页的实现技术与fanout read持续增长带来的问题进行深入分析,提出了构建业务关联索引的方案有效降低90%以上服务负载。
基于实时流的广告特征平台的建设与实践
作为一个拥有庞大年轻用户群体和多元化内容资源的视频平台,B站为广告主提供了丰富的投放场景。
持续降本:B站日志平台3.0演进之路
基于ClickHouse的Billions2.0日志方案上线后,虽然能够降低60%的存储成本,但仍然存在几个比较明显的问题,需要进一步的优化和解决。
海外创作端上传链路专项治理
在哔哩哔哩海外市场,视频上传是创作者最重要的功能之一,也是创作者对平台忠诚度和满意度的重要影响因素之一。
哔哩哔哩大规模AI模型推理实践
AI算法复杂度逐年上升,需要高效的方式支持AI模型的推理和部署。
Web 端实时防挡脸弹幕(基于机器学习)
防挡脸弹幕,即大量弹幕飘过,但不会遮挡视频画面中的人物,看起来像是从人物背后飘过去的。
百亿数据百万查询——关系链架构演进
作为一个平台型的业务,关系链服务对外提供一对多关系点查、全量关系列表、关系计数等基础查询,综合查询峰值QPS近百万,被动态、评论等核心业务依赖。
竟然是"你"偷走了那0.001的服务可用性
前段时间有我们活动项目某个服务可用性出现抖动,偶尔低于0.999。虽然看起来3个9的可用性相当高,但是对于一个 10w+ qps 的服务来讲,影响面就会被放大到不可接受的状态。
直播互动开放技术探索之路
直播互动玩法,早在2014年就曾有人在Twitch平台进行尝试,在这一类玩法中,直播间观众可以通过弹幕指令共同操纵主播的游戏内容,在国内被称为“弹幕互动玩法”。
账号多租户架构升级与落地实践
在考虑到账号内部很多不合理的设计在现有系统上维护升级成本较高,我们计划对现有的账号系统进行重构。
B站大数据集群混部实践(上)- 资源超配篇
在过去一年的时间里,B站离线平台资源调度侧的主要挑战有两个方面:
-
随着业务的不断增长,离线集群规模快速膨胀,用户对资源的需求在持续增大,主集群长期处于Pending较高的状态,资源需求超过交付量
-
出于降本增效的考虑,消解Pending的方法不能仅靠物理机的增加了,而是需要在物理机整体数量不变的基础上通过超卖来提升集群整体的资源利用率。
为了应对上述挑战,调度侧在向内与向外两个方向上进行了积极的探索。“向内”聚焦于单台物理机,通过超配的方式不断提高单台物理机的利用率,使得单台节点能够处理更多的任务;“向外”与云平台部门合作,共同探索混部技术的落地,到目前为止,已经完成了离线超配,离在线混部、在离线混部等集群建设以及潮汐混部的技术实现,使得不同集群间的资源能够被更充分地调动。
B站动态outbox本地缓存优化
动态综合页比较容易因为高热事件,引起大量用户持续消费feed流,导致线上拉取动态时间线feed流接口快速飙升至平时峰值2~3倍以上而大量超时,较多用户无法正常消费其feed流。
B站数据平台调度系统之依赖
数据平台的调度系统作用为根据任务配置,包括调度时间与依赖的上游任务,进行调度任务,即等待到达调度时间且上游任务完成,才提交运行下游任务。