Flink 在字节跳动数据流的实践

字节跳动数据流的业务背景

数据流处理的主要是埋点日志。埋点，也叫 Event Tracking，是数据和业务之间的桥梁，是数据分析、推荐、运营的基石。

用户在使用 App、小程序、Web 等各种线上应用时产生的行为，主要通过埋点的形式进行采集上报，按不同的来源分为客户端埋点、Web 端埋点、服务端埋点。

不同来源的埋点都通过数据流的日志采集服务接收到 MQ，然后经过一系列的 Flink 实时 ETL 对埋点进行数据标准化、数据清洗、实时风控反作弊等处理，最终分发到下游，主要的下游包括 ABTest、推荐、行为分析系统、实时数仓、离线数仓。

所以，如果用一句话来概括数据流主要业务，其实就是埋点的收集、清洗、分发。

目前在字节跳动，清洗和分发环节是基于 Flink 搭建的。

01 - 数据流业务规模

• 业务数量：在 字节跳动，包括抖音、今日头条、西瓜视频、番茄小说在内的 3000 多个大大小小的 APP 和服务都接入了数据流。

• 数据流峰值流量：当前，字节跳动埋点数据流峰值流量超过 1 亿每秒，每天处理超过万亿量级埋点，PB 级数据存储增量。

• ETL 任务规模：目前，字节跳动数据流在多个机房部署超过 1000 个 Flink 任务和超过 1000 个 MQ Topic，使用超过 50W Core CPU，单任务最大 12W Core CPU ，Topic 最大 10000 Partitio。

02 - 数据流业务挑战

字节跳动数据流 ETL 遇到的挑战主要有四点：

• 第一点，流量大，任务规模大。

• 第二点，处在所有产品数据链路最上游，下游业务多，ETL 需求变化频繁。

• 第三点，高 SLA 要求，下游推荐、实时数仓等业务对稳定性和时效性有比较高的要求。

• 最后一点，在流量大、业务多、SLA 要求高的情况下，针对流量、成本、SLA 保障等多维度的综合治理也面临挑战。

下面从两个数据流业务场景中介绍一下我们遇到的业务挑战。

1、UserAction ETL 场景

在 UserAction ETL 场景中，我们遇到的核心需求是：种类繁多且流量巨大的客户端埋点需求和 ETL 规则动态更新的需求。

在字节内部，客户端的埋点种类繁多且流量巨大，而推荐关注的只是部分埋点，因此为了提升下游推荐系统处理效率，会在数据流配置一些 ETL 规则，对埋点进行过滤，并对字段进行删减、映射、标准化之类的清洗处理，将埋点打上不同的动作类型标识。

处理之后的埋点一般称之为 UserAction，UserAction 数据会和服务端展现等数据在推荐 Joiner 任务的分钟级窗口中进行拼接 Join，产出 Instance 训练样本。

 

举个例子：一个客户端的文章点赞埋点描述了用户在一个时间点对某一篇文章进行了点赞操作，埋点经过数据流日志采集服务进入数据流 ETL 链路，通过 UserAction ETL 处理后实时地进入到推荐 Joiner 任务中拼接生成样本更新推荐模型，从而提升用户体验。

​

如果产出 UserAction 数据的 ETL 链路出现比较大的延迟，那么就不能在窗口内及时完成拼接，可能导致用户体验下降。

因此对于推荐来说，数据流的时效性是一个强需求。

而推荐模型的迭代、产品埋点的变动都可能导致 UserAction 的 ETL 规则的变动。如果 ETL 规则硬编码在代码中，每次修改都需要升级