字节跳动云原生

亿级用户背后的字节跳动云原生计算最佳实践

Image

Image

作者 | 字节跳动基础架构

互联网时代数据出现爆发式增长,数字化、实时化的趋势也明显加快。基于数据驱动的业务场景不断涌现,无一不在加速着大数据的繁荣发展。而随着云原生概念的兴起,大数据技术产品逐步迭代升级,云原生大数据技术产品开始引领产业变革的浪潮。

“字节跳动大数据业务背景” 

从 2017 年起,字节跳动陆续推出多款广为人知的热门应用,如抖音、今日头条、西瓜视频、剪映、番茄小说、懂车帝等。应用形态从图文、点播,逐步走向更具实时化的直播、实时音视频。海量的数据规模、愈加复杂的实时场景使得各大业务对字节跳动底层运算能力的要求不断提高。
Image
字节跳动业务的数据存储和日志规模每日已达到 EB 级别
实时推荐峰值每秒达到百万次
以抖音的实时推荐为例。系统从亿万级别的内容库中选出用户可能感兴趣的内容,运用复杂的模型对内容进行打分排序,再通过广告系统的处理,最后呈现给用户,整个过程需要在 300 毫秒内完成。
这就对背后的计算能力提出了很高的要求,只有庞大的计算资源和极致的性能优化,才能达到这一业务需求。
云原生技术在字节跳动的敏捷迭代和创新的背后发挥了重要的作用,也正是这项关键的技术让字节跳动可以在 27 天内完成央视春晚红包项目的备战。字节跳动的大数据生态和云原生技术从早期的独立发展,到后来的大规模在离线混部, 再到今天的融合调度,大数据已经完全融入到云原生的生态中。

“字节跳动云原生计算发展历程” 

Namespace Scope 资源

字节跳动的流式计算引擎经历了由 Storm/JStorm 完全替换为 Flink 的演进。

在 2017 年以前,字节跳动一直在使用 Storm/JStorm 框架作为流式计算引擎。但随着业务的不断发展,Storm 不支持 Exactly Once、缺少 SQL 以及状态的支持、运维比较复杂、稳定性不高等缺点愈加凸显。

经过一系列调研,2017 年中,字节跳动基础架构团队正式开始尝试使用 Flink 作为流式计算引擎。

流式计算 Flink 引擎的高速发展

由于推荐系统和线上服务的大规模应用,字节跳动早期的技术体系主要是以 Python 为主。为了更好地实现生态对接,基础架构的工程师们在底层计算引擎上封装了一套 Python 的接口,各业务作业通过 Python 框架使用流式计算引擎。

得益于 Python 框架的存在,底层引擎从 JStorm 变更为 Flink 的工作得以在业务用户无感知的情况下完成,即用户仍然可以使用同样的 API 来实现自己的业务逻辑。在这个过程中还主要解决了两个问题:

  • 通过 SmartResources,防止资源空置和浪费。早期的流式计算引擎使用 YARN 作为调度系统,而从 JStorm 迁移而来的业务用户对设置 CPU 和 Memory 没有概念。为了保障作业的稳定运行,业务用户往往倾向于设置很大的资源量,这也就导致非常大的资源浪费。SmartResources 可以通过作业历史和当前的运行状况,自动调整 Container CPU 和内存的实际资源使用量,这在防止资源浪费上能够提供很大的收益。

  • 通过单点故障重启,解决大规模模型训练场景下的作业重启问题。Flink Exactly Once 的特性决定了任何一个 Worker 失败都会导致整个作业的重启。但在大规模模型训练场景下,重启时间对线上效果的影响将会被无限放大。在此背景下,基础架构的工程师们修改了 Flink DAG 的 Failover 实现,使得在特定的 Topology 下,单 Task 失败可以只重启单个 Task,从而实现了非常短的时间内的故障恢复。

到 2019 年,流式计算引擎已经完成了 JStorm 作业 100% 迁移。基于开源社区对 SQL 能力的增强,基础架构流式计算团队开始在公司内部大力推广 Flink SQL,Flink 的应用场景在字节内部得到不断拓展,特别是与直播、广告等业务团队一起共同探索流批一体应用场景。

此外,流式计算团队开始在公司内部推动 Flink Batch 的落地,数据 Binlog 同步等业务场景的支持,目前每天大概有 10w+ Flink Batch 作业运行。

消息处理峰值 90 亿 QPS

Image
截至目前,字节跳动业务流式作业数量已经达到 4 万个,其中 SQL 作业占 30%,随着 Flink SQL 在字节内部的推行,这一占比还将会继续扩大。
而在这 4 万个作业中,已有 1.8 万个作业开启了 Checkpoint,高峰流量吞吐达到 600GB/s。在资源层面,全球目前业务平均使用的 Flink 资源已经超过 400 万核。
每个夜晚,当今日头条、抖音等软件迎来使用高峰,字节跳动内部的实时计算引擎也随之进入高速运转。据统计,每晚 Flink 作业处理消息的 QPS 可达到 90 亿。

批式计算引擎

长期以来,字节跳动批式计算引擎 Spark 支持构建了公司内绝大部分的数据仓库。发展至今,Spark 作业数已达 90 万,涵盖 SQL/Java/Scala/Python 多种语言。资源核数达 500 万 Core,这之中包括大量的大规模在离线混部资源。

在 Spark 引擎不断发展的过程中,字节跳动批式计算团队的工程师们同样遇到了诸多挑战。

  • 如何提升 Shuffle 稳定性以保障 SLA?

在大规模作业下,开源 ExternalShuffleService 的实现机制容易出现大量随机读导致的磁盘 IOPS 瓶颈, Shuffle Fetch 的请求积压等问题,从而致使运算过程中经常出现 Stage 重算甚至作业失败,继而引起资源使用的恶性循环,严重影响 SLA。

对此,团队提出了 Cloud Shuffle Service 解决方案,解决了 ESS 机制上的一些缺陷,同时独立部署服务,更好地对接更多混部资源。

  • 如何降低运维和资源成本

伴随着业务需求的不断发展,公司内部批式计算作业数量也在不断增加,同时存在资源利用率低,工单数量大等问题。

为此,团队开始考虑通过自动化方案 BatchBrain 来解决。BatchBrain 可提供异常作业(慢作业、失败作业)的自动诊断,以及推荐参数,从而达到降低成本的目的。

“业务验证下的行业标准解决方案” 

经过字节跳动的大规模业务验证,当前火山引擎已正式推出流式计算 Flink 版和批式计算 Spark 版两款云上产品。

流式计算 Flink 版

依托于字节跳动大规模实时计算集群实践。火山引擎流式计算 Flink 版基于火山引擎容器服务 VKE 和弹性容器 VCI,提供 Serverless 极致弹性,是开箱即用的全托管流式计算引擎。在 100% 兼容开源 Flink 的前提下,对产品功能也进行了企业级增强。

  • 开发效率提升。流式计算 Flink 版支持算子级别 Debug 输出、Queryable State、Temporal Table Function DDL,在开发效率上对开源版本 Flink 有显著提升。

  • 可靠性提升。流式计算 Flink 版针对单个 Task 进行 Checkpoint,提高了大并发下的 Checkpoint 成功率。单点任务恢复和节点黑名单机制功能,保障了对故障节点的快速响应,避免业务整体重启。

批式计算 Spark 版

火山引擎批式计算 Spark 版支持了今日头条、抖音的超大规模批计算,提供面向深度学习场景的深度优化。在100%兼容 Apache Spark 的同时,实现企业级功能增强,配备火山引擎独有的 Cloud Shuffle Service 以保障 Spark 的作业性能和稳定性。

批式计算 Spark 版提供租户级端到端安全隔离,具备基于火山引擎容器服务 VKE 和弹性容器 VCI 的 Serverless 极致弹性扩展能力。

- END -

下载云原生白皮书

基于字节跳动基础架构提供的云原生技术能力和技术实践,火山引擎已经构建了全栈的云原生服务产品矩阵,包括面向算力的云原生服务、面向应用的云原生服务和面向场景的云原生服务三大板块。

欢迎下载 IDC 和火山引擎联合出品的云原生白皮书,获取企业数字化转型新理念!

Image

扫描二维码,下载火山引擎云原生白皮书