基于 http-flv 的抖音直播端到端延迟优化实践_ 字节跳动技术团队的博客-CSDN博客
基于 http-flv 的抖音直播端到端延迟优化实践
字节跳动技术团队
于 2022-07-05 16:00:24 发布
2149
收藏
文章标签：
网络
人工智能
分布式
算法
java
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明。
本文链接：https://blog.csdn.net/ByteDanceTech/article/details/125631101
版权
动手点关注 干货不迷路 👆
延迟是怎么产生的？
传统直播方案(http-flv、RTMP 等)的架构以及延迟量级如下图所示：
以抖音直播为例，直播链路各环节延迟贡献如下：
推流端——网络延迟平均 20 ～ 30ms，编码延迟依赖编码参数设置而定流媒体服务——在拉流转码的场景下，会额外引入 300ms ～ 2s 的转码延迟(大小与转码参数相关)，如果直接播放源流，则不存在转码延迟播放端——网络延迟 100ms ～ 200ms 左右，主要是链路分发节点之间的传输延迟；防抖 buffer——5 ～ 8s
从各环节延迟贡献看，容易得出一个直观的结论：端到端延迟过大主要是播放器的防抖 buffer 造成，这个表面现象也经常会导致很多同学，认为降低播放器的 buffer，就能降低延迟。这个说法的对错，取决于从什么角度解释。在辩证这个结论前，我们先详细拆解介绍下直播全链路的延迟：
上图主要更细致地拆解了流媒体服务环节，即 CDN 传输链路，拆解为上行(收流节点和上层节点)、源站、下行(上层节点和拉流边缘节点)。各环节延迟归因如下：
主播端(推流器)
主要包含编码延迟以及发送缓存引入的延迟（多数主播网络情况良好，发送缓存延迟平均只有 20 ～ 30ms），这个环节的延迟可优化空间不多，虽然通过调节编码器参数可有效降低编码延迟，但带来的是画质的损失，同时也影响压缩效果，因此多数集中在优化弱网传输(不过出发点是为了提供用户观看流畅体验，而不在于降低延迟)
收流边缘节点&中间链路
针对 http-flv 不需要分片的协议，CDN 传输各节点都是在收到流数据就直接转发到下一个节点，这个环节主要的延迟是由链路传输引起的，与链路长度正相关，一般平均不超过 200ms。
如果播放端拉转码流，那么在网络传输延迟基础之上，会额外增加转码延迟(目前各大 CDN 厂商编码延迟大概分布在 300ms ～ 2s)，包括解码延迟和转码延迟，其中对于无 B 帧的场景，解码延迟较小，主要是编码延迟。编码延迟主要是受编码器缓存帧数影响，假设 FPS=15，那么缓存 6 帧，延迟就 400ms，该部分延迟与推流编码延迟一样，同样可以通过调整转码参数来降低转码延迟，但也同样会带来画质与压缩率的损失，因此这部分延迟需要根据实际场景综合来考虑，如果对延迟要求很高，可以调整下。
拉流边缘节点
不考虑回源的情况，这个环节主要影响延迟的是 gop cache 策略(有的 CDN 厂商也叫做快启 buffer 策略或者快启 cache)，即在边缘节点缓存一路流最新的几个 gop(一般媒体时长平均为 5 ～ 7s)，目的是为了在拉流请求建立时，可以有媒体数据即时发送，优化首帧和卡顿，这样也就导致了播放端收到的第一帧数据就是 5 ～ 7s 前的旧数据，第一帧的延迟就达到了 5 ～ 7s(这个环节才是端到端延迟过大的根因)。
CDN gopCache 的逻辑
字节与 CDN 厂商沟通约定 gop cache 按照下限优先来下发数据，比如下限 6s，表示先在缓存数据中定位最新 6s 的数据，然后向 6s 前的旧数据查找第一个关键帧下发，保证下发第一帧距离最新帧之间的时长不低于 6s：
如上图，如果不考虑生产端和中间链路的延迟，那么 buffer 长度 7.2s 可以近似看作播放的初始端到端延迟，在播放器正常播放且无卡顿的前提下，这个延迟会一直持续到退出直播间，不会变化。这里介绍几个初始延迟计算的通用公式：
延迟分布区间[M,M+gop]s，平均延迟为 M+gop/2，其中 M 为 gopCache 策略的下限，gop 即为编码 gop 的固定大小值
例如抖音秀场 gop 大小是固定的 2s，假设 gopCache 下限为 6s，那么观众的合理端到端延迟分布区间为：[6, 8]s，根据用户请求的时间点，所有观众的延迟都会均匀分布在这个区间内，因此不同观众间的延迟 diff 最大不超过一个 gop 的长度 2s(这点是优化设备间延迟差的理论基础)
观众(播放器)
播放器在 io 模块有分配缓存 buffer(抖音线上分配 buffer 最大为 20s，也就是最多可容纳 20s 的媒体数据，这个 buffer 其实越大越好，抗网络抖动能力也越强)，用于存放从 CDN 边缘节点下载到的流媒体数据。播放器下载是主动下载，在可分配的 buffer 队列未充满的前提下，io 线程是连续下载流媒体数据并存放到 buffer 中，直到没有空闲 buffer 可利用为止。因此，观众网络状况良好的情况下，在用户请求播放，建立链接后，CDN 的边缘节点的快启 buffer，会很快都被下载到播放器的 buffer 中，后续渲染环节消费速度远低于 i/o 下载的速度，这样端到端的延迟就主要分布到了播放器的 buffer 中。但只说明启播后，直播链路的延迟从 CDN 的 gopCache，转移到了播放器，播放器 buffer 并不是延迟的根因，因此，降低播放器的最大缓存 buffer，并不能降低延迟。如果换个角度理解，降低播放器 buffer 中实际缓存的数据，会降低延迟这个说法是正确的，比如通过倍速播放或者丢帧。
现在了解了全链路延迟是怎么产生的，我们可以确认以下几点：
端到端延迟，在 CDN 边缘节点收到 http-get 请求那一刻起，流数据未达到客户端 buffer 前，初始延迟的大小就已经确定了，这个延迟对应于我们的 QoS 指标-首帧延迟影响延迟大小的因素主要有两点：CDN 边缘节点 gop cache 策略(5~7s 延迟)以及视频流 gop 大小(会造成一个 gop 大小的延迟 diff)客户端 buffer 大小与延迟大小之间没有因果关系，buffer 的大小只会影响延迟全链路的分布，但降低播放器 buffer 大小只会降低防抖能力，恶化卡顿，并不会降低延迟较低延迟的有效手段包括：
降低 CDN 的 gopCache，是根本手段增加 buffer 中视频数据的消费速度，也可以有效降低延迟，例如倍速播放或者直接丢弃媒体数据在 gopCache 不变的前提下，降低 gop，也可以降低平均端到端延迟，比如 gop=4s 调整为 2s，平均端到端延迟下降 1s
为什么要优化延迟？
传统的直播技术延迟非常大，从观众评论到看到主播给出反馈一般要在 5-10 秒以上。几个典型的尴尬场景：
单一用户延迟大，导致体验差
在线教育，学生提问，老师都讲到下一个知识点了，再返回来回答。
电商直播，询问宝贝信息，主播“视而不理”。
打赏后迟迟听不到主播的口播感谢。
假设端到端延迟为 6s，那么在线教育和电商直播两个场景，互动延迟由面对面的 0s，增加到了 12s，如下图所示：
打赏场景，互动延迟由面对面的 0s，增加到了 6s，如下图所示：
不同用户延迟 diff 大，导致体验差
在别人的呐喊声知道球进了，你看的还是直播吗？
这个场景的延迟体验问题，并不是某次拉流请求端到端高延迟导致的，主要是因为不同用户间的延迟不一致导致，如下图：
可见，高延时影响了直播互动体验，阻碍了直播在一些场景的落地，特别在电商直播，直播间的评论提问是观众和主播互动的一个重要手段，主播的实时互动反馈对直播间的活跃度和交易达成至关重要。
以上两类由于延迟导致体验差的场景，分别对应我们 QoS 指标中的平均端到端延迟、延迟设备差两个指标，延迟相关的优化也会以这两个指标为标准。
延迟体验优化实践案例
百万英雄答题
直播流链路
延迟需求
所有观众端到端时延在 6s 以内——对应首帧延迟和平均端到端延迟指标不同观众 A，B，C 之间直播流时延差在 2s 以内，避免答题不同步——对应设备延迟差指标
需求分析
对于答题类活动直播场景，用户主要集中精力在听题、读题、答题，与主播的互动不是强需求，因此端到端延迟不是优化重点，只要满足需求的 6s 即可用户使用场景多数是面对面或者实时语音组团答题，会对彼此之间延迟不一致的现象很敏感，因此保证设备延迟差尽可能小是核心需求点
解决方案
满足时延 6s 以内——调整 gopCache 以及 gop 大小
gop=2s，gopCache 下限为 5s，那么首帧延迟分布在[5s, 5+2s]内，平均延迟为(5+(5+2))/2=6s，具体措施如下：
各家 CDN 快启策略需要设置为下限优先，并且快启 buffer 阈值为 5s推流参数设置需要设置 gop=2s，且保持稳定：保证观看同一路流的用户，时延 diff 在 2s 内转码配置需要保持 gop=2s 的配置，并且 I 帧对齐：保证观看不同转码流的用户，时延 diff 在 2s 内
延迟差在 2s 以内
调整 gop=2s 后，仅能保证一直流畅播放无卡顿的 vv，彼此直接的延迟 diff 在 2s 以内，但对于观播过程中发生卡顿的用户，累计延迟增加的情况，延迟 diff 会越来越大，例如用户 A 卡 4s 后，恢复正常播放，那么 A 的端到端延迟会增加 4s，如果 A，B，C 是一个组队答题的小伙伴，A 的题目解说会一直落后 B 和 C，这样的体验很不好。因此需要针对这类场景的设备延迟差做优化：这时候需要播放器追帧微调，使 A 的播放速度追上 B 和 C。具体措施如下：
追帧的原则是：在 A 的播放器 buffer 超过 6s 时，就开始倍速播放，直到 buffer 低于 6s，这时候 A 就追上了 B 和 C追帧阈值 6s，追帧速度是 1.4，这样设置的效果时，A 观众在延迟落后 4s 的情况下，追帧 10s 即可赶上 B 和 C，实际阈值的设置，可以根据需求来确定，原则上是在延迟满足需求时，尽量不触发追帧，保持正常速度播放
效果验收
相对于第一届百万英雄答题，延迟不同步的用户反馈大量减少
4s 低延迟字节内购会
直播流链路
类似于百万英雄
延迟需求
所有观众端到端时延在 4s 以内——对应首帧延迟和平均端到端延迟指标不同用户在听到主播说上链接时，与购物链接弹出时间尽量一致——对应设备延迟差指标
需求分析
内购会有电商主播带货环节，因此对互动延迟敏感内购会是大型组团抢购活动，员工都在工位面对面参与，因此对设备延迟差也会很敏感
解决方案
推流&转码流配置
配置项value配置方式推流 gop2sOBS 推流器配置转码 gop2s转码模版
CDN 侧
相对于百万英雄答题场景，内购会对互动延迟敏感，因此这里相对于百万英雄答题需要做特殊配置，由于各家厂商默认 gopCache 策略，平均端到端延迟在 6s 左右，不满足需求的 4s，需要通过配置 url query 参数控制厂商的 gopCache 策略，保证延迟在 4s 左右
播放端参数配置详情
延迟等级：4s参数配置目标：降低不同设备间延迟差，控制用户延迟分布在[3000ms, 4000ms]内，这样保证设备间延迟差最大不超过 1s——延迟低的用户慢放，延迟高的用户追帧，从而更精确的控制设备延迟差低于 gop 长度 2s
倒计时确认时机
内购会上链接或者答题，是根据现场助理观播的延迟来确定上链接或者发题的倒计时时机，由于有快慢放对齐设备延迟差的过程，建议助理看播 1min 后，延迟稳定后，再确定倒计时
效果验收
线下演练以及正式场不同设备间的流内容延迟，进入观播后通过快慢放调整后，延迟基本都稳定在 4s，且 diff 不超过 1s主播口播“上链接”与实际链接弹出延迟 diff 在 1s 内，抢购体验良好基本无卡顿反馈 case
抖音直播-FLV 低延迟-3s
直播流链路
需求目标
平均延迟达到 3s播放时长、看播渗透、留存等核心业务指标显著正向电商 GMV、充值打赏等营收指标显著正向
需求分析
传统直播场景，不同观众同一时刻经常观看不同主播的流，且经常是个人独立观播，对同一直播间，不同观众延迟一致的诉求基本不存在，因此延迟设备差不是优化重点指标秀场直播、直播带货等场景，是强互动场景，对互动延迟要求高，本需求核心优化点是端到端延迟
解决方案
本次需求场景的受众是抖音的所有直播用户，网络质量的优劣也是参差不齐的，在保证满足降低延迟的需求目标，我们还需要保证观播的流畅性不要负向太多。
延迟解决方案
gop 下调为 2s配置 gopCache 下限参数为 1800ms，延迟区间为[1800+200ms，3800+200ms]，平均 3s
卡顿优化方案
先验知识科普
启播 buffer 策略：表示首帧渲染后，需要等到播放器 audio buffer 达到一定阈值后，再继续播放，这样可以增加网络抗抖能力网络分级 1 ～ 8：
8—等效于非常好的 4G 网络；7—等效于较好的 4G 网络；6—等效于一般的 4G 网络；5—等效于较差的 4G 网络；1 ～ 4—网络质量差
基于网络质量的个性化启播 buffer 策略
方案设计基本原理
基于网络分级，自适应调整启播 buffer设定启播 buffer 最大调整区间为[0,850ms]不同网络分级映射到不同的启播 buffer 区间随着网络分级的变差，启播 buffer 档位递增速率也加快同一网络分级的不同 vv，根据重试和卡顿次数，在该网络分级的启播 buffer 区间中进行微调随着卡顿次数的增加，启播 buffer 在对应档位区间内的微调幅度逐步下降对于同一次 app 启动周期内，发生多次直播 vv 的情况，需要考虑最近一次直播播放 session 中的卡顿和重试情况，且卡顿和重试的影响权重随着时间衰减QoS 收益：卡顿负向降低了 20%
基于网络质量的个性化延迟策略
基于数据统计发现：网络分级 1 ～ 4 的 vv 占比为 5.54%，但卡顿指标却贡献了 47.83%，再结合本需求场景设备间延迟差并不是核心指标，因此可通过个性化延迟来优化卡顿。
方案设计基本原理
基于网络分级，自适应调整延迟不同网络分级映射不同的 gopCache 下限随着网络分级的变差，延迟逐渐增大QoS 收益：卡顿负向降低了 30%+
客户端管控 CDN 卡顿优化策略
在需求推进过程中发现两个奇怪的现象：
在网络质量足够好的场景下进行线下测试，发现低延迟更容易触发 CDN 的丢帧策略(优化卡顿的策略)，从而导致渲染卡顿上涨(和 CDN 沟通后，CDN 侧不愿意透露太多的丢帧策略细节，根因无法求证)在 AB 实验过程中，某一家 CDN 厂商上线了过激的丢帧策略，引起了线上大量反馈，从用户反馈看，基本都是反馈刚进入直播间的卡顿，推测用户对启播阶段的丢帧卡顿，更敏感
结合以上两个现象，基本可以判断低延迟情况下，CDN 在启播阶段更容易丢帧，且启播丢帧会严重影响 QoE 体验，因此管控 CDN 丢帧策略，对 QoS(视频渲染卡顿)以及 QoE 都是有正向优化效果的，管控规则如下：
参数名描述规则protected_period拉流 session 丢帧保护期：请求开始的前 n 毫秒不能丢帧protected_period=0:表示整个拉流过程中都不能丢帧；当 value>0 时，比如 protected_period=5000：表示拉流 session 的前 5000ms 不能丢帧，5000ms 是以系统时钟(本地时间)纬度来衡量gop_keep_duration发生丢帧的 gop 保留时长下限：时长是视频流纬度的 duration当 value>0 时，比如 gop_keep_duration =2000ms，表示丢帧后，对应 gop 必须保留发送到用户的的视频流总时长不低于 2000ms
QoS 收益：FLV 低延迟渲染卡顿负向降低约 30%
最终效果验收
QoE 指标收益
核心业务指标：直播人均看播时长、看播渗透、留存等显著正向营收相关指标：电商人均支付订单数、付费渗透、充值等显著正向Qos 指标
端到端延迟：3.24s卡顿：增加 13%带宽成本收益
由于低延迟降低了 gopCache，延迟下降到 3s，相对于 7s 高延迟 FLV，在启播时会少下载 4s 的数据，尤其抖音直播预览流占比达到 70%，因此低延迟 FLV 可以节省不必要的带宽成本，成本收益为 10%
关于延迟的思考
思考一：观众对互动延迟的感知是否存在拐点，延迟降到一定程度，用户感知不到？我们从三个典型的互动场景来思考：
观众评论，主播看到评论进行口播回复互动：观众对话框输入评论平均耗时至少 2s 以上，再降低互动延迟是否有收益？观众打赏送礼，主播进行口播感谢互动：假设观众打赏耗时平均 1s 左右，此时打赏后互动延迟 3s 口播感谢，此时的延迟水平是否已经满足观众对主播感谢响应度的需求？直播带货场景：无论“上链接”口播与链接实际弹窗是否一致，还是秒拍场景，核心的延迟指标都是设备间延迟差指标会影响体验，是否实际的端到端延迟其实观众并没有互动延迟敏感？
思考二：在传统标准直播 http-flv 场景下，是否可以依然基于本文中介绍的方法，继续下探更低延迟，比如 1s？个人判断是可以做到的，但面临的挑战也更多，需要更精细的播控策略来平衡延迟与播放流畅性，比如：
在 tcp/quic 等传输协议场景，启播时 CDN 侧都存在带宽(最佳的发送速率)探测的算法逻辑，基于实际发送数据探测结合 ACK 等反馈信息来增加发送速率，那么这里就存在一个问题——继续降低 gopCache，满足延迟下降到 1s 的同时，也导致 CDN 用于发送探测的数据量会变少，不足以探测到网络链路实际的带宽，这样会导致 gopCache 阶段平均发送速率会降低，抗网络抖动能力会急剧下降，同时也会影响首帧，因此为进一步下探延迟，需要播放端和 CDN 相互配合优化启播发包速率，这样才能保证流畅性不负向过多更低延迟的场景对延迟的要求也极高，也更容易发生卡顿，但凡发生一次卡顿，延迟就很容易成倍增加，最终导致延迟降不下来，进一步下探延迟也需要配合精细的追帧或者丢帧策略
字节跳动技术团队
关注
关注
点赞
收藏
评论
基于 http-flv 的抖音直播端到端延迟优化实践
动手点关注干货不迷路????延迟是怎么产生的？传统直播方案(http-flv、RTMP 等)的架构以及延迟量级如下图所示：以抖音直播为例，直播链路各环节延迟贡献如下：推流端——网络延迟平均 20 ～ 30ms，编码延迟依赖编码参数设置而定流媒体服务——在拉流转码的场景下，会额外引入 300ms ～ 2s 的转码延迟(大小与转码参数相关)，如果直接播放源流，则不存在转码延迟播...
复制链接
扫一扫
参与评论
您还未登录，请先
登录
后发表或查看评论
博客
字节跳动一站式数据治理思考及实践
12-14
202
动手点关注干货不迷路导读：今天的分享主要分四个部分：机遇与挑战、数据治理思路、技术架构演进以及未来展望1. 机遇与挑战数据治理工作有很多挑战，最主要的一点是落地比较困难。首先，治理工作中与业务有一定的矛盾。第二，治理涉及的组织和管理难度大。第三，规范“人”的动作难度大，治理过程中，需要依靠人来推进和执行，人员能力参差不起，组织文化、目标也存在不对齐的情况。第四，缺乏适配性强的产品工具。因为治理工作...
博客
火山引擎 RTC 助力抖音百万并发“云侃球”
12-07
623
动手点关注干货不迷路1. 背景及技术挑战从电视看直播到手机电脑看直播，直播技术的发展让观众可以随时、随地观看自己喜欢的比赛，并且在看比赛时通过发送表情、发文字进行互动。但表情、文字承载的信息量较小、沟通效率低，我们无法像线下一起看比赛那样和好友边看边聊、一起为精彩的比赛呐喊，观赛体验大打折扣。为了让观众获得更好的观赛体验，抖音在 2022 世界杯比赛直播中推出了“边看边聊”的玩法：每个观众都可以邀...
博客
字节跳动数据中台的 Data Catalog 系统搜索实践
11-21
777
动手点关注干货不迷路1. 背景Data Catalog 能够帮助大公司更好地梳理和管理自己的资产，是 Data-drvien 公司的重要平台。一个通用的 Data Catalog 平台通常包含元数据管理，搜索，血缘，标签，术语等功能。其中，搜索是 Data Catalog 的入口功能，承担着让用户“找到数”的主要能力。在字节跳动数据中台的 Data Catalog 系统中，每天有 70% 以上的用...
博客
火山引擎 RTC 视频性能降级策略解析
11-16
445
动手点关注干货不迷路1. 背景随着 RTC 使用场景的不断复杂化，新特性不断增多，同时用户对清晰度提升的诉求也越来越强烈，这些都对客户端机器性能提出了越来越高的要求 (越来越高的分辨率，越来越复杂的编码器等)。但机器性能差异千差万别，同时用户的操作也不可预知，高级特性的使用和机器性能的矛盾客观存在。当用户机器负载过高时，我们需要适当降级视频特性来减轻系统复杂性，确保重要功能正常使用，提升用户体验...
博客
火山引擎工具技术分享：用 AI 完成数据挖掘，零门槛完成 SQL 撰写
11-14
413
动手点关注干货不迷路在使用 BI 工具的时候，经常遇到的问题是：“不会 SQL 怎么生产加工数据、不会算法可不可以做挖掘分析？”而专业算法团队在做数据挖掘时，数据分析及可视化也会呈现相对割裂的现象。流程化完成算法建模和数据分析工作，也是一个提效的好办法。同时，对于专业数仓团队来说，相同主题的数据内容面临“重复建设，使用和管理时相对分散”的问题——究竟有没有办法在一个任务里同时生产，同主题不同内容的...
博客
大规模分布式链路分析计算在字节跳动的实践
11-07
1025
动手点关注干货不迷路1. 综述微服务架构的快速发展使得分布式链路追踪系统成为观测体系中越来越重要的组件。字节跳动的分布式链路追踪系统经历了数年的发展后，已覆盖了字节的绝大部分在线业务，完成了对数万微服务和数百万微服务实例的在线链路追踪。在经典的指标观测分析和单请求链路追踪的基础上，如何从浩瀚如海的分布式链路数据中进一步挖掘出更高层次的信息，为业务的架构优化、服务治理、成本优化等场景提供更高效的数据...
博客
深度解析字节跳动开源数据集成引擎 BitSail
11-01
976
动手点关注干货不迷路1. 导读BitSail 是字节跳动开源数据集成引擎，支持多种异构数据源间的数据同步，并提供离线、实时、全量、增量场景下全域数据集成解决方案，目前支撑了字节内部和火山引擎多个客户的数据集成需求。经过字节跳动各大业务线海量数据的考验，在性能、稳定性上得到较好验证。10 月 26 日，字节跳动宣布 BitSail 项目正式在 GitHub 开源，为更多的企业和开发者带来便利，降低数...
博客
一文了解 DataLeap 中的 Notebook
10-27
1856
动手点关注干货不迷路一、概述Notebook 是一种支持 REPL 模式的开发环境。所谓「REPL」，即「读取-求值-输出」循环：输入一段代码，立刻得到相应的结果，并继续等待下一次输入。它通常使得探索性的开发和调试更加便捷。在 Notebook 环境，你可以交互式地在其中编写你的代码、运行代码、查看输出、可视化数据并查看结果，使用起来非常灵活。在数据开发领域，Notebook 广泛应用于数据清理和...
博客
火山引擎 RTC 全球化架构设计
10-24
1072
动手点关注干货不迷路1. 为什么 RTC 要做全球化RTC（Real Time Communication）是音视频基础设施，它已经融入了大家生活的方方面面：工作中，我们组织视频会议，即使团队成员身处异国，也能保证项目推进；休息时，我们打开抖音，看主播直播连麦；来一局游戏时，我们打开小队语音，大杀四方；学习时，我们相聚线上互动课堂，知识传播不再受距离的桎梏。RTC 拉近了大家的距离，丰富了大家的生...
博客
Spark AQE SkewedJoin 在字节跳动的实践和优化
10-12
1768
动手点关注干货不迷路1. 概述本文将首先介绍 Spark AQE SkewedJoin 的基本原理以及字节跳动在使用 AQE SkewedJoin 的实践中遇到的一些问题；其次介绍针对遇到的问题所做的相关优化和功能增强，以及相关优化在字节跳动的收益；此外，我们还将分享 SkewedJoin 的使用经验。2. 背景首先对 Spark AQE SkewedJoin 做一个简单的介绍。Spark Ada...
博客
深入理解 Android Studio Sync 流程
10-10
1958
动手点关注干货不迷路1. 初识 Sync我们一般会把 Sync 理解为 Android Studio 的准备阶段，包括解析工程配置信息、下载远程依赖到本地、更新代码索引等准备工作，当修改 gradle build 文件后，需要重新 Sync 将 Gradle 构建配置信息同步到 IDE，进而使 IDE 的功能及时应用新的构建配置，这些功能包括项目的 Gradle Task 列表展示、依赖信息展示等...
博客
火山引擎 RTC 自研音频编码器 NICO 实践之路
09-30
1683
动手点关注干货不迷路1. 前言随着互联网技术的不断发展，越来越多的人开始尝试使用或者依赖实时音视频产品解决团队沟通与协作问题。在通话过程中，我们时常会遇到因为网络波动（如拥塞、丢包、延时和抖动等）而导致的音频卡顿、掉字或者杂音等问题，影响工作效率。为解决此类音频弱网问题，业界一般采用前向纠错（Forward Error Correction，FEC）或者重传等网络策略优化方法，但这些方法存在冗余率...
博客
prompt 综述
09-28
1365
动手点关注干货不迷路1. 概述1.1 基本概念用一句话概括模板学习，即将原本的输入文本填入一个带有输入和输出槽位的模板，然后利用预训练语言模型预测整个句子，最终可以利用这个完整的句子导出最终需要的答案。模板学习最吸引人的关键在于其通过已有的预训练模型，定义合适的模板就能完成 few-shot 或者 zero-shot 任务，这样可以使得语言模型可以在预训练阶段利用尽可能多的信息进行训练，后续也能最...
博客
初探自然语言预训练技术演进之路
09-27
879
动手点关注干货不迷路人工智能的三个层次：运算职能：数据的存储和计算能力，机器远胜于人类。感知职能：视觉、听觉等能力，机器在语音识别、图像识别领域已经比肩人类。认知智能：自然语言处理、常识建模与推理等任务，机器还有很长的路要走。自然语言处理属于认知智能范畴，由于自然语言具有抽象性、组合性、歧义性、知识性、演化性等特点，为机器处理带来了极大的挑战，有人将自然语言处理称为人工智能皇冠上的明珠。近些年来，...
博客
Redis 持久化策略浅析
09-26
1298
动手点关注干货不迷路Redis（Remote Dictionary Server )，即远程字典服务，是一个开源的内存高速缓存数据存储服务。使用 ANSI C 语言编写，支持网络、可基于内存亦可持久化的日志型、Key-Value 数据存储，并提供多种语言的 API。▶ 简介Redis 是内存数据库，数据都是存储在内存中，为了避免进程退出导致数据的永久丢失，需要定期将 Redis 中的数据以某种形式...
博客
Babel 插件：30分钟从入门到实战
09-16
1515
动手点关注 干货不迷路 ????Babel 是一个 source to source（源码到源码）的 JavaScript 编译器，简单来说，你为 Babel 提供一些 JavaScript 代码，Babel 可以更改这些代码，然后返回给你新生成的代码。Babel 主要用于将 ECMAScript 2015+ 代码转换为能够向后兼容的 JavaScript 版本。Babel 使用插件系统进行代码转换，因...
博客
HiveServer2 内存泄漏问题定位与优化方案
09-09
1842
动手点关注 干货不迷路 ????前言HiveServer2 属于 Hive 组件的一个服务，主要提供 Hive 访问接口，例如可通过 JDBC 的方式提交 Hive 作业，HiveServer2 基于 Java 开发，整个服务运行过程中，内存的管理回收均由 JVM 进行控制。在 JVM 语言中的内存泄漏与 C/C++ 语言的内存泄漏会有些差异，JVM 的内存泄漏更多的是业务代码逻辑错误引起大量对象引用被...
博客
火山引擎在行为分析场景下的 ClickHouse JOIN 优化
09-05
1090
动手点关注 干货不迷路 ????1. 背景火山引擎增长分析 DataFinder 基于 ClickHouse 来进行行为日志的分析，ClickHouse 的主要版本是基于社区版改进开发的字节内部版本。主要的表结构：事件表：存储用户行为数据，以用户 ID分 shard 存储。--列出了主要的字段信息CREATETABLEtob_apps_all(`tea_app_id`...
博客
飞书 Android 升级 JDK 11 引发的 CI 构建性能问题
09-02
929
动手点关注干货不迷路????一、摘要本文从飞书 Android 升级 JDK 11 意外引发的 CI 构建性能劣化谈起，结合高版本 JDK 在 Docker 容器和 GC 方面的新特性，深挖 JVM 和 Gradle 的源码实现，抽丝剥茧地介绍了分析过程和修复方法，供其他升级 JDK 的团队参考。二、背景最近飞书适配 Android 12 时把 targetSdkVersion 和 compileSd...
博客
春节活动 - 高峰值奖励发放技术方案
08-30
1168
动手点关注 干货不迷路 ????1. 背景2022年春节活动在8款字节系 APP 上线，包含了红包雨、集年味卡和烟火大会等诸多玩法。红包雨、集卡开奖和烟火大会都存在高峰值突发流量。其中，红包雨活动会在10分钟内给几千万甚至上亿用户发放上亿现金奖励，且大多数请求集中在前3分钟。在项目启动时，红包雨活动作为最大的流量来源，预估的发红包峰值流量有180万 QPS 。为了保证用户体验、活动效果和资金安全，红包雨...
“相关推荐”对你有帮助么？
非常没帮助
没帮助
一般
有帮助
非常有帮助
提交
字节跳动技术团队
CSDN认证博客专家
CSDN认证企业博客
238
原创
9690
周排名
1719
总排名
128万+
访问
等级
8466
积分
5913
粉丝
656
获赞
369
评论
2165
收藏
私信
关注
热门文章
抖音品质建设 - iOS启动优化之原理篇
38182
字节跳动自研万亿级图数据库 & 图计算实践
31420
字节跳动技术团队年度 TOP10 技术干货，陪你度过不平凡的 2020
27557
字节跳动自研线上引流回放系统的架构演进
26426
字节跳动开源云原生机器学习平台 Klever
24539
最新评论
浅谈Linux设备虚拟化技术的演进之路
Bill_Xiang:
vdpa将virtio带入了容器领域，容器是说只能用内核驱动的网络设备，没有vdpa之前virtio应该是说只能虚拟机用，有了vdpa之后容器也能用virtio硬件设备了，然后vduse又进一步可以给容器提供软件的virtio设备，总的来说还是用在容器的场景里，可以这么理解吧
Android 系统 Bar 沉浸式完美兼容方案
huaqiangsina:
鸿蒙无效。
字节跳动智能创作团队多篇论文入选 CVPR 2022
小菜鸡加油:
Dressing in the Wild by Watching Dance Videos 这一篇没有代码吗
抖音Android无障碍开发知识总结
qiixiao:
所以，抖音app是和Mac一样，支持按键操作吗？
西瓜视频 iOS Voice Over 无障碍适配实践
LTOVE-CODE:
多音字怎么处理的
您愿意向朋友推荐“博客详情页”吗？
强烈不推荐
不推荐
一般般
推荐
强烈推荐
提交
最新文章
字节跳动一站式数据治理思考及实践
火山引擎 RTC 助力抖音百万并发“云侃球”
字节跳动数据中台的 Data Catalog 系统搜索实践
2022
12月
2篇
11月
5篇
10月
4篇
09月
8篇
08月
11篇
07月
14篇
06月
21篇
05月
17篇
04月
11篇
03月
6篇
02月
8篇
01月
8篇
2021年58篇
2020年47篇
2019年12篇
2017年6篇
目录
目录
最新文章
字节跳动一站式数据治理思考及实践
火山引擎 RTC 助力抖音百万并发“云侃球”
字节跳动数据中台的 Data Catalog 系统搜索实践
2022
12月
2篇
11月
5篇
10月
4篇
09月
8篇
08月
11篇
07月
14篇
06月
21篇
05月
17篇
04月
11篇
03月
6篇
02月
8篇
01月
8篇
2021年58篇
2020年47篇
2019年12篇
2017年6篇
目录
评论
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
查看更多评论
实付元
使用余额支付
点击重新获取
扫码支付
钱包余额
抵扣说明：
1.余额是钱包充值的虚拟货币，按照1:1的比例进行支付金额的抵扣。 2.余额无法直接购买下载，可以购买VIP、C币套餐、付费专栏及课程。
余额充值