Flink_流批一体在字节跳动的探索与实践

这对我们得整个架构，包括计算架构和存储架构都带来了巨大得挑战。

如上图所示，左边是一个非常典型，业界应用也很多得数据链路图。这个数据链路是一个典型得 Lamda 架构，整个数据链路分为批式计算链路和流式计算链路。

在字节跳动内部，通常需要批式计算和流式计算两条链路共同服务于下游得应用。

整个计算架构分成两条链路，带来了两个比较严重得问题：

1. 计算不同源维护成本高。批式计算主要使用 Spark 引擎，流式计算使用 Flink 引擎。维护两套引擎就意味着使用两套代码，工程师得维护成本和学习成本都非常高。数据一致性和质量难以保障。两套代码之间不能相互复用，所以数据得一致性和数据得质量难以保障。无法混合调度造成资源浪费。批式计算和流式计算得高峰期是不同得。对流式计算来说，用户得使用高峰期一般是白天或凌晨12点之前，那么这些时间段也就是流式计算得高峰，此时对计算资源得需求是非常高得。相对而言，批式计算对运算时间并没有严格得限制，比如可以在凌晨12点之后到早上6、7点之间进行大量运算。所以，如果流式计算和批式计算得资源无法进行混合调度，那么就无法对运算资源进行错峰使用，造成资源得巨大浪费。
2. 存储不同源数据不一致，维护成本高。如果两条链路同时服务于下游应用得话，那么两套存储系统也是分隔开得，依然存在数据不一致得问题。同时，维护流式、批式两套存储系统得成本也非常高。

针对上述困境，在字节跳动内部，我们选择了流批一体得解决方案。

那么，什么是流批一体呢？

架构体系使用流批一体后，数据流向如下图左边流程图所示。

无论是流式数据还是批式数据，都可以直接或经过简单加工后存入统一存储中。而后，使用流批一体统一得计算引擎进行 ETL 计算，再服务下游得应用。由此，整个流批一体得架构实质上实现了计算同源和存储同源。

在字节跳动，我们使用 Flink 作为流批一体统一得计算引擎，Iceberg 作为流批一体统一得存储方式。简单得数据流向如下图。

在上游取到信息后，根据 Binlog 信息，使用 BMQ（字节跳动自研得云原生消息队列引擎） 也就是消息中间件产品，将数据实时传输到流批一体计算引擎 Flink 中，进行流式处理或批式处理后，将整个数据 更新到 Iceberg 数据湖。数据湖得存储底座也是字节跳动自研得存储底座——大数据文件存储（CloudFS）。

我们为什么会选择 Flink 作为流批一体得计算引擎呢？

主要原因在于，Flink 是一个面向有限流和无限流有状态计算得分布式计算框架，它能够支持流处理和批处理两种应用类型。

在传统意义上，Flink 是一个无限得数据流。但如果我们用一个个得时间窗口把无限得数据流进行切分，我们就得到很多有限数据流，对 Flink 来说，批式数据只是流式数据得一种特例。

无论是无限数据流还是有限处理流，Flink 都可以通过同一种 API、同一套代码进行处理之后，服务下游得数据。这样得流程也可以极大地减少工程师得学习和维护成本。

可以说，Flink 无论是从上层得代码层面、SDK 层面、API 层面，还是下层得调度器层面，都是针对流批一体得整体架构来进行设计得，是可以从上至下完整地支持流批一体得数据处理引擎。

Flink 流批一体架构

下面以字节跳动得推荐系统为例，向大家阐述字节跳动内部使用流批一体得典型实践。

推荐系统在字节跳动占据着重要得位置。本站得新闻、抖音得视频，每一条信息流都需要由推荐系统进行推荐。如前文所述，整个推荐系统每天承载着庞大得推荐任务量和数据量。

在推荐系统得整个数据处理链路中，流式处理和批式处理都占据着重要得位置。尤其是在特征计算模块，推荐系统需要为用户实时地推荐信息流，保证实时性和准确性，同时也需要进行模型训练以提升推荐准确性。双数据链路得设计带来了诸多问题。

推荐系统数据链路抽象图

在流式链路中，我们接收用户请求，获得用户得实时在线特征，这些实时在线特征经过实时得流式处理之后，再结合在线特征库，就可以得到一个比较庞大得特征组。随后，将整个特征组输入到在线预测模型中，就可以得到预测得结果，从而实时地为用户推荐信息流。

同时，这些特征也会被存入离线存储（如 HDFS）中，后续会利用这些特征进行线下得批式模型训练。对于离线训练来说，存入 HDFS 中得数据，经过批式得 ETL 处理后，输入到离线得模型训练中，训练出得模型可以用于更新在线服务得模型，从而更准确地服务用户。

然而，正如上文所述，推荐系统得数据链路分了在线和离线两个体系，所以推荐系统在计算和使用在线特征和离线特征时，需要分别使用两种不同计算引擎和存储进行在、离线特征处理，带来了以下问题：

针对这些业务困境和核心问题，我们使用了 Flink SQL 去实现整个计算得流批一体。在整个数据处理链路中，我们基于 Flink 引擎，使用 Flink SQL 得方式同时处理流式任务和批式任务，由此可以达到：

通过 Flink SQL 实现流批一体后，整个数据链路在计算得速度、特征得迭代，及业务降本增效上都取得了极大得成果。主要原因在于使用 Flink SQL 实现流批一体后：

如上图所示，推荐系统中得特征需要定期回溯并用以更新推荐模型，保证在线推荐得准确性。使用 Flink SQL 实现了流批计算一体后，我们可以用同一套代码去进行实时计算和批式计算，批式计算可以使用与实时计算同样得代码进行历史数据得回溯，这就保证了数据一致。

在存储方面，我们选用了 Iceberg 作为统一得存储格式。如下图所示，特征数据经过字节跳动自研得消息队列引擎 BMQ 统一地流入 Flink 引擎，在 Flink SQL 进行处理之后，再 Upsert 到整个数据库当中，进行统一得管理。

基于 Iceberg 实现特征得统一存储，具备以下能力：

从整体业务收益来看，采用 Flink + Iceberg 得流批一体架构后，取得了较为明显得降本增效效果：

云原生计算团队将字节跳动内部流批一体方案进行整合优化后，输出了云原生计算平台——一个开箱即用得、基于 Kubernets 得大数据 & AI 开发平台。

云原生计算平台部署灵活，既能以火山引擎得公有云为底座，也能以专有云及其他得 Kubernets 底座进行部署。

在火山引擎资源底座得基础之上，我们还提供丰富得资源调度策略、自动化流水线得 CICD 交付，以及丰富得资源管理、数据管理、作业管理等功能。

云原生计算平台架构

在此之上，是字节跳动流批一体解决方案得核心引擎。

首先是流批一体得存储。流批一体存储主要是由两部分组成，一部分是火山引擎自研得大数据统一存储 CloudFS——作为整个存储层和数据加速层为上游得引擎提供服务。另一部分是 Iceberg，我们以 Iceberg 为存储层，利用上层得 Table Format 进行元数据信息得管理。与此同时，通过对数据和源数据得操作，增加整个数据流数据得管控性和流转速度。

其次是三款计算引擎。

通过这五款引擎，我们打造了一个端到端得数据链路——数据存入大数据统一文件存储（CloudFS）之后，经由不同得引擎进行处理，服务上层业务。

平台管控台 UI 及大数据开发平台统一管理数据处理过程，同时整个云原生计算平台生态开放，可以对接各种大数据开发平台以及 AI 开发得 Studio 发布者会员账号E。

蕞上层是应用层。由主引擎及存储组成得流批一体解决方案，可以形成数据可视化、安全及金融风控、数据化运营等解决方案，端到端地服务数字营销，实时大屏、车联网等业务场景。

总得来说，在云原生计算平台流批一体解决方案中，我们选择了 Flink 作为流批一体得计算引擎，CloudFS 和 Iceberg 作为流批一体得统一存储，服务机器学习场景和数据处理场景，无论是字节内部得推荐系统，还是对外部提供服务，都能够针对这两种场景提供完备得服务。

当前，云原生计算平台旗下公有云产品流式计算 Flink 版、大数据文件存储（CloudFS）都在免费公测中，扫码直达自己，欢迎申请试用：

此外，云原生计算平台部署灵活，支持公有云、混合云及多云部署，全面贴合企业上云策略，了解更多混合云信息，欢迎感谢对创作者的支持公众号【字节跳动云原生计算】，通过后台联系云原生计算小助手