Flink SQL在业务使用中有较多的双流join场景，当左右流的流量都较大，Join的等待时间即使为1小时，Flink Keyed State（Flink State分Operator State和Keyed State，后文所有State均代表后者）的存储大小也很容易达到TB级（内部默认使用的是RocksDBStateBackend）。 在State我们内部[1]之前就做了RT和长度的metric，当State的存储达到TB级别后，会发现State的scan/next/readNull请求RT会变得较高，另外双流Join不仅流量大，Join query的字段也较多，导致State的Value长度也较大，从而使得任务在流量高峰期CPU存在明显的周期性毛刺，根因是RocksDB的compaction引发。我们下面的内容主要是从业务场景跟进到RocksDB的读写行为，来优化RT耗时高的问题，并使用优化方案缓解compaction的压力。
随着直播业务和用户规模日益壮大，如何丰富直播间内容、增强直播间内用户互动效果，提升营收数据变得更加关键。为此，直播互动玩法应运而生。通过弹幕、礼物、点赞、大航海等方式，用户可以参与主播的直播内容。B站还通过开放平台，为第三方厂商和开发者提供了强大的技术支持，让直播互动玩法更加便捷、稳定和高效，为用户和主播创造了更多的乐趣和价值。
UI自动化测试能够在一定程度上确保产品质量，尤其在降本提效的大背景下，其重要性愈发凸显。理想情况下，UI自动化测试不仅能够能帮我们规避不少线上问题，又能加快产品上线速度。然而现实却往往相去甚远，在多数情况下，编写测试脚本的工作量很大，且由于应用程序的频繁迭代，这些脚本很快就会过时。此外，网络数据的多变也常常导致测试结果不稳定，从而影响测试的可信度。 基于这些挑战，我们开发了一套UI自动化测试平台- AutoMotion，旨在降低UI自动化测试的使用门槛、提升易用性。该平台不但能便捷地生成用例，且借助最新的大型语言模型，该平台也具备了用例自愈能力，能够智能适应界面的合理变动，并自动修正测试脚本；同时，通过构造数据沙箱来隔离和控制测试数据，使平台能够确保测试的一致性和可重复性。 本文将对AutoMotion平台的设计理念、核心功能以及实现原理进行介绍，希望能与大家一同交流进步。
在广告检索系统中，增量索引（实时索引）是一类常见的技术，用于使广告信息的变更及时生效。其中一种主要的思路即由检索系统消费广告更新数据流，实时更新内存索引，对此行业中已有很多优秀方案实现。然而，对与如何构建出“广告更新数据”，却鲜有提及。 本文将针对如何构建出完整、可靠、可维护的“广告更新数据流”进行展开叙述。
自从我站从2020年逐步灰度自研P2P开始, 在直播下行带宽方面取得巨大的成功,带宽成本每年节省数亿。与此同时, 由于直播下行同时存在FLV和HLS两种直播协议,在回源带宽上也产生了双份费用,在2022年整个行业也处在下行阶段,为了进一步降本增效, 我们从回源成本出发,设计了一套新的流媒体协议,以应对当前多种下行协议分发的难题。
随着微服务和容器化技术的迅速发展，传统的基于SDK和服务框架的微服务架构在面对多元化的技术和逐步增多的服务数量时弊端逐渐显现，为了解决这些问题，service mesh作为新一代的微服务框架逐渐展露头角。这种架构模式可以将其视为微服务时代的TCP/IP协议，通过将网络通信层下沉，来屏蔽分布式系统带来的复杂性。因此各大厂纷纷向这种微服务架构模式升级，用该种模式解决东西向流量（server-server）和南北向流量（client-server）问题，期望可以让开发者回归业务，更聚焦业务。但在软件开发中并没有银弹，从传统微服务模式升级到service mesh架构模式可谓困难重重。鉴于以上问题，结合集团现状，集团针对RPC流量的服务治理体系已经很成熟，但是缺少针对HTTP流量的统一治理体系，同时集团针对南北向流量处理的微服务治理框架也已经很成熟，因此团队直接聚焦于使用该种架构模式解决HTTP东西向流量的治理问题。考虑到实现成本与推广难度问题，在实现过程中团队并不想要重复造轮子，因此期望能够在兼容现有的架构情况下实现MESH化，同时，致力于在对业务零侵入的情况下，丰富现有的服务治理能力
2017年，《Attention Is All You Need》的一声惊雷，给世人带来了Transformer模型。2022年，以Transformer结构为核心的chatGPT，凭借其震惊世界的表现，掀起了“AI元年" 的序幕：从此，各方纷纷投入大模型领域，前赴后继，热情高涨。然而，随之而来地，大模型在软硬件基础设施、算法及数据集等多方面的挑战和困难也逐步显现；今天我们将从AI-Infra角度出发，带大家了解目前大模型在算力、存储、通信等多方面上硬件资源的挑战和瓶颈，并且提供相关指标的量化手段和选型指导。
商业侧的业务比较复杂，B端项目中含有大量常量类的类型判断，且因历史原因，很多常量值前端无法直接知其含义，这既不利于新人的上手，也不利于项目的维护。 在开发协作上，前后端的API沟通，大都通过配置swagger api来进行，要不就是口口相传或者通过写info文档来定义结构、入参及出参，这种协作方式不仅沟通成本高，且前端缺少能主动感知后端API变更的手段。 同时，为了提高项目的可维护性，组内推动前端项目TS工程化，在改造过程中，也会因为业务迭代，需要创建新的项目，而新项目TS工程化的过程，不仅需要自定义大量的类型，也需要定义后端API类型参数，如果全部通过手动敲，代价太大，不仅很容易出错，也会影响业务的开发效率。 因此，为了提升开发协作效率，增加前端主动感知API的能力，提升项目的可维护性和开发效率，开发实现了TS自动化生成工具。
色彩空间（Color Space）是一种数学模型，用于描述和表示颜色的方式。不同的色彩空间有不同的用途和特点，可以用于不同的应用，如图像处理、计算机图形、印刷、摄影等领域。它一般用于描述设备的色彩能力，或者视频、图片的色彩范围。比如现在大部分人用的手机的屏幕，色彩空间大多为sRGB或者DCI-P3；网页上常见的图片或者视频内容，大多属于sRGB色彩空间；B站客户端播放的HDR视频，则处于BT.2020色彩空间。 目前B站UP主投稿视频是千变万化的，它们包含各种不同的色彩参数, 比如不同的色深，不同的色度采样坐标，不同的色彩空间，不同的亮度传递函数等等（如下图），而且每个用户观看这些视频的终端也不一样，这样就产生了各种各样的兼容性问题——很多时候用户的设备并不能完全正确显示UP主投稿的“原片”，而且老旧的设备或者浏览器也并不支持广色域或者HDR视频。为了考虑终端设备的兼容性和B站服务的完整性，我们会对用户投稿的不同色彩空间的视频进行统一处理。但是如何将各种不同色彩参数的视频进行准确地统一处理，同时又能保证视频的处理速度，这对于我们来说是一个巨大的挑战。
为了给用户提供更清晰的画质体验，B站自研的超分辨率算法已经在站内广泛应用，支持了如《赛马娘》、《流浪地球2》、《权力的游戏》、英雄联盟S赛赛事直播等知名番剧、电影电视剧以及重要游戏赛事直播的 4K 视频流生产。
