2021 年，巨量引擎集团旗下商品总 MAU 已超出 19 亿。在以抖音短视频、今日今日头条、西瓜小视频等为意味着的商品业务环境下，强劲的推荐算法看起来至关重要。Flink 给予了十分强有力的 SQL 控制模块和有状态计算模块。现阶段在字节数强烈推荐场景，即时简易记数特征、对话框记数特征、编码序列特征已经彻底转移到 Flink SQL 计划方案上。融合 Flink SQL 和 Flink 有状态计算工作能力，大家已经创建下一代通用性的基本特征计算统一构架，期待可以高效率适用常见有状态、无状态基本特征的生产制造。

业务环境

针对今日今日头条、抖音短视频、西瓜小视频等巨量引擎集团旗下商品，根据 Feed 流和短时限的建议是关键业务场景。而推荐算法最根本的能源是特征，高效率生产制造基本特征对业务推荐算法的梯度下降法尤为重要。

关键业务场景

• 抖音短视频、火山短视频等为意味着的小视频应用推荐场景，例如 Feed 流强烈推荐、关心、社交媒体、同城网等每个场景，总体在中国大约有 6 亿 经营规模 DAU；
• 今日头条、无籽西瓜等为意味着的 Feed 信息流广告强烈推荐场景，例如 Feed 流、关心、子频道栏目等每个场景，总体在中国数千万经营规模 DAU；

业务困扰和挑戰

现阶段巨量引擎强烈推荐场景基本特征的生产制造现况是“百花争艳”。线下特征计算的基本原则全是根据交易 Kafka、BMQ、Hive、HDFS、Abase、RPC 等数据库，根据 Spark、Flink 计算模块完成特征的计算，而后把特征的結果载入线上、线下储存。各种各样不一样种类的基本特征计算撒落在不一样的服务项目中，欠缺业务抽象化，产生了很大的维护成本费和可靠性问题。

而更主要的是，欠缺统一的基本特征生产制造服务平台，使业务特征开发设计梯度下降法速率和维护保养存有许多麻烦。如业务方要自主维护保养很多线下每日任务、特征生产制造链接欠缺监控器、不能满足飞速发展的业务要求等。

在字节数的业务经营规模下，搭建统一的即时特征生产系统遭遇着比较大挑戰，关键来源于四个方面：

极大的业务经营规模：抖音短视频、今日头条、无籽西瓜、活火山等商品的信息经营规模可做到日均 PB 等级。例如在抖音场景下，晚高峰期 Feed 播放量达上百万 QPS，手机客户端汇报客户个人行为数据信息达到数百万 IOPS。业务方期待在无论怎样，特征每日任务都能够保证持续流、交易沒有 lag 等，这就规定特征生产制造具有十分高的可靠性。

较高的特征即时化规定：在以直播间、电子商务、小视频为象征的强烈推荐场景下，为确保强烈推荐实际效果，即时特征线下生产制造的及时性需完成常态化平稳于分鐘等级。

更强的可扩展性和操作灵活性：伴随着业务场景持续繁杂，特征要求更加灵便变化多端。从统计分析、编码序列、特性种类的特征生产制造，到必须灵便适用对话框特征、多维度特征等，业务方必须特征网易大数据可以适用慢慢衍化而成的新特征种类和要求。

业务梯度下降法速度更快：特征网易大数据给予的面对业务的 DSL 必须充足场景，特征生产制造链接尽可能让业务少敲代码，最底层的计算模块、储存模块对业务彻底全透明，完全释放出来业务计算、储存型号选择、调优的压力，完全完成即时基本特征的产业化生产制造，不断提高特征生产效率；

梯度下降法演变全过程

在字节数业务爆发式增长的历程中，为了更好地达到各种各样的业务特征的要求，强烈推荐场景衍化出了诸多特征服务项目。这种服务项目在指定的业务场景和历史时间情况下不错适用了业务迅速发展趋势，大致的过程如下所示：

强烈推荐场景特征服务项目演变过程

在这里在其中 2020 今年初是一个关键连接点，大家刚开始在特征生产制造中引进 Flink SQL、Flink State 技术性管理体系，逐渐在记数特征系统软件、实体模型培训的样版拼凑、对话框特征等场景开展落地式，探寻更新一代特征生产制造计划方案的构思。

新一代系统架构图

融合以上业务环境，大家根据 Flink SQL 和 Flink 有状态计算工作能力再次设计了新一代即时特征计算计划方案。新计划方案的精准定位是：处理基本特征的计算和线上 Serving，给予更为抽象化的基本特征业务层 DSL。在计算层，大家根据 Flink SQL 灵便的数据处理方法语言表达能力，及其 Flink State 状态储存和计算工作能力等技术性，适用各种各样错综复杂的对话框计算。巨大地减少业务基本特征的生产周期，提高特征产出率链接的可靠性。新的构架里，大家将特征生产制造的链接分成数据库提取/拼凑、状态储存、计算三个环节，Flink SQL 进行特征数据信息的提取和流式的拼凑，Flink State 进行特征计算的正中间状态储存。

有状态特征是十分关键的一类特征，在其中最经常使用的是含有各种各样渠道的特征，例如统计分析近期 5 分鐘短视频的播放视频 VV 等。针对对话框种类的特征在字节数内部结构有一些根据储存模块的计划方案，总体策略是“轻线下重线上”，即把对话框状态储存、特征汇聚计算所有放到储存层和线上进行。线下数据流分析承担基本上数据信息过虑和载入，线下清单数据信息依照時间切分汇聚储存（类似 micro batch），最底层的储存绝大多数是 KV 储存、或是专业提升的储存模块，线上层进行比较复杂的对话框汇聚计算逻辑性，每一个要求来啦以后线上层拉取储存层的清单数据信息做汇聚计算。

大家新的处理构思是“轻线上重线下”，即把非常重的時间切成片清单数据信息状态储存和对话框汇聚计算所有放到线下层。对话框結果汇聚根据线下对话框开启体制进行，把特征結果推倒线上 KV 储存。线上控制模块十分轻量，只承担简易的线上 serving，巨大地优化了线上层的构架复杂性。在线下状态储存层。大家关键依靠 Flink 给予的原生态状态储存模块 RocksDB，灵活运用线下计算群集当地的 SSD 硬盘資源，巨大缓解线上 KV 储存的資源工作压力。

针对长对话框的特征（7 天以上窗口特征），因为涉及到 Flink 状态层清单数据信息的回朔全过程，Flink Embedded 状态储存模块沒有给予特别好的外界数据信息地热井体制（换句话说不适合做）。因而针对这类“状态冷启”场景，大家引进了去中心化储存做为最底层状态储存层的存储介质，总体是 Hybrid 构架。例如 7 天之内的状态储存在当地 SSD，7～30 天状态储存到去中心化的储存模块，线下数据信息回朔可以十分便捷的载入去中心化储存。

除对话框特征外，这套体制一样适用其他类型的有状态特征（如编码序列种类的特征）。

即时特征归类管理体系

特征种类

界定

特征举例说明

有状态特征

有状态特征是一类十分关键的特征，大家对有状态特征的定位是：计算特征必须缓存文件前后文数据信息。

• 含有对话框的特征，例如抖音短视频近期1h的关注量（滑动窗口）、直播房间客户近期一个 session 的看播时间（session 对话框）等；
• 编码序列特征，例如近期100个强烈推荐呈现短视频。

无状态特征

简易的 ETL 特征，根据简洁的数据信息过虑可以计算的特征。

实体模型预计特征

必须通过外界繁杂实体模型预计的特征

客户的年纪、性別等特征。

图特征

直播间和社交媒体关联场景存有比较多的必须二跳关联的图种类的特征。

许多图特征与此同时也是有状态种类的特征。

• 礼品排列：客户收看较多的网络主播接到较多的礼品，优选必须寻找客户收看较多的网络主播 ArchorId，随后根据 archon_id 获得到网络主播接到较多的礼品 id；
• 社交媒体关联：朋友（可能是发掘出的关联）关心、看播、送礼物、连麦直播的屋子，社交媒体关联纯天然是图算法设计。

总体构架

数据库层

在新的一体化特征构架中，大家统一把多种类型数据库抽象化为 Schema Table，这是由于最底层依靠的 Flink SQL 计算模块层对数据库给予了十分友善的 Table Format 抽象化。在强烈推荐场景，依靠的数据库十分多种多样，每一个特征上下游依靠一个或好几个数据库。数据源可以是 Kafka、RMQ、KV 储存、RPC 服务项目。针对好几个数据库，适用数据信息流源式、批式拼凑，拼接种类包含 Window Join 和根据 key 粒度分布的 Window Union Join，维表 Join 适用 Abase、RPC、HIVE 等。实际每一种种类的拼凑逻辑性如下所示：

数据库种类

Schema 分析

Kafka、BMQ

Kafka、BMQ 等 message 种类基本上全是 JSON 和 PB，是自描述的数据种类。可以十分便捷地投射成 SchemaTable 格式，在其中针对 PB 种类，业务必须提交 PB IDL 进行 Table Schema 界定。

KV储存

KV 存储里的 Value 绝大多数为 JSON、PB 格式，和 MQ 相近。业务方根据给予 PB IDL 进行 Table Schema 界定。大家根据 FlinkSQL 的维表 Join 工作能力，把一般的获得外界储存数据源全过程抽象化为基础的维表 Join 实际操作，简单化业务开发进度。

RPC

FlinkSQL 给予了对 RPC 维表的 Join 工作能力，业务给予 RPC Thrift IDL 详细 rpc response Table Schema 界定。根据维表 Join，大家把一般的根据 RPC 获得外界数据源的流程抽象化为了更好地基本上维表 Join 实体模型，简单化业务开发进度。

Hive

Hive 自身便是 SchemaTable 的储存格式，针对线上 Join 数据量较小的线下 Hive 数据(实际上便是 MapSide Join)，可根据 Hive 维表 Join 完成。

三种类别的 Join 和 Union 可以组成应用，完成比较复杂的多数据流拼凑。例如(A union B) Window Join (C Lookup Join D)。

拼接种类

拼凑逻辑性

备注名称

Window Join

应用 Flink 原生态 API 给予的 Join 算法，把好几个数据流掉入同样对话框的数据 Join 起來。

立即在初始数据流上运用 TumblingWindow 开展切分，依据event_time 或 process_time 两端对齐2个对话框后再关系数据。

根据 Key 粒度分布的 Interval State Join

和样版拼凑逻辑性相近。根据 Union 上下游好几个数据源，在每一个关系外键约束上边申请注册 timer，等候一个固定不动的周期时间进行多数据源的 Join 实际操作。

Interval State Join 是运用 State 储存数据再解决。上下游2个数据流通过 Union 后，同一个 uid 的 instance 数据和 label 数据落在同一个 operator 内，Joiner 中正负极例样版的发生便是根据这类 Join 方法。

Lookup 维表 Join

根据关系外键约束，从 Abase、RPC、Hive 等服务项目查询必须关系的数据，进行数据的 Join 实际操作。

多数据源 Union

多数据源 Union 起來

此外，Flink SQL 适用复杂字段的计算水平，也就是业务方可以根据数据源界定的 TableSchema 基本字段名完成拓展字段名的测算。业务计算逻辑性实质是一个 UDF，大家会给予 UDF API 插口给业务方，随后提交 JAR 到特点后台管理载入。此外针对非常简单的测算逻辑性，后台管理也适用根据递交简易的 Python 编码完成多语言表达测算。

业务 DSL

从业务角度给予相对高度抽象化的特点生产制造 DSL 语言表达，屏蔽掉最底层测算、储存模块关键点，让业务方对焦于业务特点界定。业务 DSL 层给予：数据由来、数据格式、数据提取逻辑性、数据形成特点种类、数据輸出方法等。

情况储存层

以上文上述，新的特点一体化计划方案处理的关键困扰是：怎么看待多种类型（一般是滑动窗口）有情况特点的测算问题。针对这类特点，在线下测算层构架里会有一个情况储存层，把提取层获取的 RawFeature 依照切片 Slot 储存起來(切片可以是時间切片、还可以是 Session 切片等)。切片种类在内部结构是一个接口方式，在构架上可以依据业务要求自主拓展。情况里边实际上储存的并不是初始 RawFeature（储存原有的个人行为数据太消耗储存空间），反而是转换为 FeaturePayload 的一种 POJO 构造，这一构造里边适用了普遍的各种各样数据结构特征：

• Int：储存简易的计标值种类(多层次 counter)；
• HashMap：储存二维计标值，例如 Action Counter，key 为 target_id，value 为计数值；
• SortedMap: 储存 topk 二维记数 ；
• LinkedList： 储存 id_list 种类数据；
• HashMap>：储存二维 id_list；
• 自定种类，业务可以按照要求 FeaturePayload 里边自定数据种类

情况层升级的业务插口：键入是 SQL 提取/拼凑层提取出的 RawFeature，业务方可以依据业务要求完成 updateFeatureInfo 插口对情况层的升级。针对常见的特点种类内嵌完成了 update 插口，业务方自定特点种类可以承继 update 插口完成。

/**
 * 特点情况update插口
 */
public interface FeatureStateApi extends Serializable {
 /**
 * 特点升级插口, 上下游每条日志会获取必需字段名变换为fields, 用于升级相匹配的特点情况
 *
 * @param fields
 * context: 储存特点名字、外键约束 和 一些配备主要参数;
 * oldFeature: 特点以前的情况
 * fields: 服务平台/环境变量 中的提取字段名
 * @return
 */
FeaturePayLoad assign(Context context,FeaturePayLoad feature, Map<String, Object> rawFeature);
}

复制代码

自然针对无状态的 ETL 特点是不用情况储存层的。

测算层

特点测算层进行特点测算汇聚逻辑性，有情况特点测算键入的数据是情况储存层存储的含有切片的 FeaturePayload 目标。简易的 ETL 特点沒有情况储存层，键入立即是 SQL 提取层的数据 RawFeature 目标，实际的插口如下所示：

/**
 * 有情况特点测算插口
 */
public interface FeatureStateApi extends Serializable {
 /**
 * 特点汇聚插口，会依据配制的特点测算对话框, 载入对话框内全部特点情况，排列后传到该插口
 *
 * @param featureInfos, 包括2个field
 * timeslot: 特点情况相匹配的时间槽
 * Feature: 该时间槽的特点情况
 * @return
 */
 FeaturePayLoad aggregate(Context context, List<Tuple2<Slot, FeaturePayLoad>> slotStates);
}

复制代码

有状态特点汇聚插口

/**
 * 无状态特点测算插口
 */
public interface FeatureConvertApi extends Serializable {
 /**
 * 变换插口, 上下游每条日志会获取必需字段名变换为fields, 无状态测算时，变换为内部结构的feature种类;
 *
 * @param fields
 * fields: 服务平台/环境变量 中的提取字段名
 * @return
 */
 FeaturePayLoad convert(Context context, FeaturePayLoad featureSnapshot, Map<String, Object> rawFeatures);
}

复制代码

无状态特点测算插口

此外根据开启体制来开启特点测算层的实行，现阶段适用的开启体制主要是有：

对策

表述

OnTimerTrigger

规律性按时开启特点的测算逻辑性

OnUpdateTrigger

上下游情况层每一次升级即开启特点测算

CustomTrigger

自定特点测算的开启机会

业务落地式

现阶段在字节数强烈推荐情景，新一代特点构架已经在抖音直播、电子商务、消息推送、抖音推荐等情景相继上线一些即时特点。主要是有情况种类的特点，含有对话框的一维统计分析种类、二维倒排拉链类型、二维 TOPK 种类、即时 CTR/CVR Rate 种类特点、编码序列种类特点等。

在业务关键指标值达到层面成效明显。直播间情景，借助新特点构架强劲的语言表达能力上线一批特点以后，业务看播关键指标值、互动交流指标值盈利十分明显。在电子商务情景，根据新特点构架上线 400 即时特点。在其中在直播电商层面，业务关键 GMV、提交订单率指标值盈利明显。在抖音推送情景，根据新特点构架线下情况的储存工作能力，汇聚客户个人行为数据随后载入中下游各界储存，巨大地改善了业务中下游数据库的工作压力，在一些情景中 QPS 可以降低到以前的 10%上下。除此之外，抖音推荐 Feed、评价等业务都是在根据新特点构架构建原来的特点管理体系。

值得一提的是，在电子商务和抖音直播情景，Flink 流式的每日任务情况较大已经做到 60T，并且这一数量级仍在持续扩大。预估不久的未来，单任务的情况有可能会提升 100T，这对构架的可靠性是一个较大的挑戰。

性能优化

Flink State Cache

现阶段 Flink 给予两大类 StateBackend：根据 Heap 的 FileSystemStateBackend 和基于 RocksDB 的 RocksDBStateBackend。针对 FileSystemStateBackend，因为数据都是在运行内存中，浏览速度迅速，沒有另外花销。而 RocksDBStateBackend 存有查盘、实例化/反序列化等附加花销，CPU 需求量会出现显著升高。在字节数内部结构有很多应用 State 的工作，针对大状态工作，通常会应用 RocksDBStateBackend 来管理方法当地状态数据。RocksDB 是一个 KV 数据库，以 LSM 的方式机构数据，在具体采用的历程中，有下述特性：

1. 网络层和 RocksDB 的数据互动是以 Bytes 二维数组的方式开展，网络层每一次浏览都必须实例化/反序列化；
2. 数据以增加的方式持续载入 RocksDB 中，RocksDB 后台管理会持续开展 compaction 来删掉失效数据。

业务流程方应用 State 的场景多是 get-update，在使用 RocksDB 做为当地状态储存的历程中，发生过下列问题：

1. 网络爬虫数据造成热 key，状态会持续实现升级(get-update)，单 KV 数据做到 5MB，而 RocksDB 增加升级的特性造成后台管理在持续开展 flush 和 compaction，单 task 发生慢连接点（抖音直播场景）。
2. 电子商务场景工作大部分为大状态工作(现阶段已发布工作状态约 60TB)，领域模型中会经常开展 State 实际操作。在结合 Flink State 全过程中发觉 CPU 的开支和原先的根据运行内存或 abase 的建立有 40%~80%的上升。经提升后，CPU 花销关键聚集在实例化/反序列化的历程中。

对于以上问题，可以利用在运行内存维护保养一个目标 Cache，做到提升网络热点数据浏览和减少 CPU 花销的目地。根据以上环境详细介绍，大家期待能为 StateBackend 给予一个常用的 Cache 作用，根据 Flink StateBackend Cache 功能分析计划方案达到下述总体目标：

1. 降低 CPU 花销：根据对网络热点数据开展缓存文件，降低和最底层 StateBackend 的互动频次，做到降低实例化/反序列化花销的目地。
2. 提高 State 吞吐能力：根据提升 Cache 后，State 吞吐能力应该比原来的 StateBackend 给予的吞吐能力更高一些。理论上在 Cache 充足大的情形下，吞吐能力应和根据 Heap 的 StateBackend 类似。
3. Cache 作用集成化：不一样的 StateBackend 可以立即兼容该 Cache 作用。现阶段大家关键支持 RocksDB，将来期待可以同时供应给其他 StateBackend 应用，例如 RemoteStateBackend。

通过和字节数基础架构 Flink 精英团队的协作，在即时特征生产制造更新，发布 Cache 绝大多数场景的 CPU 利用率大约会出现达到 50%上下的盈利；

PB IDL 剪裁

在字节数内部结构的即时特征线下形成链接之中，大家关键依靠的数据流是 Kafka。这种 Kafka 全是根据 PB 界定的数据，字段名多种多样。企业等级的大 Topic 一般会出现 100 的字段名，但绝大多数的特征生产制造每日任务只运用了这其中的一部分字段名。针对 Protobuf 文件格式的数据源，我们可以彻底根据剪裁数据流，mask 一些可选择性的字段名来节约反序列化的花销。PB 种类的日志，可以立即剪裁 idl，维持必需字段名的编号不会改变，在反序列化的过程中会绕过 unknown field 的分析，这针对 CPU 而言是更节约的，可是服务器带宽不容易有盈利，预估剪裁后能节约十分多的 CPU 資源。在上线 PB IDL 剪裁以后，绝大多数每日任务的 CPU 盈利在 30%上下。

碰到的问题

新构架特征生产制造每日任务实质是一个有状态的 Flink 每日任务，最底层的状态储存 StateBackend 主要是当地的 RocksDB。关键遭遇2个较为难破的问题，一是每日任务 DAG 转变 Checkpoint 无效，二是本地存储不可以有效地支持特征状态历史时间数据回朔。

• 即时特征每日任务不可以动态性加上新的特征：针对一个网上的 Flink 即时特征生产制造每日任务，我们不能随便加上新的特征。这也是因为引进新的特征会造成 Flink 每日任务测算的 DAG 发生改变，进而造成 Flink 每日任务的 Checkpoint 没法修复，这对即时有状态特征生产制造每日任务而言是不可以进行的。现阶段大家的打法是严禁变更网上布署的特征每日任务配备，但这也就致使了网上形成的特征是不可以随意退出的。针对这个问题暂时没有寻找更强的解决方案，中后期仍需勇于探索。
• 特征状态冷启问题：现阶段首要的状态储存模块是 RocksDB，不可以有效地支持状态数据的回朔。

后面整体规划

现阶段新一代构架仍在字节数强烈推荐场景中迅速演变，现阶段已不错解决了即时对话框特征的制造问题。

出自于完成统一强烈推荐场景下特征生产制造的目地，大家后面会再次根据 Flink SQL 流批一体工作能力，在批式特征生产制造发力。除此之外也会根据 Hudi 数据湖技术性，进行特征的即时入湖，高效率支持实体模型练习场景线下特征回朔困扰。规则引擎方位，方案再次探寻 CEP，促进在电子商务场景有大量落地式实践活动。在即时对话框测算方位，将再次深层次调查 Flink 原生态对话框体制，以期解决目前计划方案遭遇的对话框特征数据离场问题。

• 支持批式特征：这套特征生产制造计划方案主要是处理即时有状态特征的问题，而现阶段字节数线下场景下也有很多批式特征是根据 Spark SQL 每日任务制造的。后面大家也会根据 Flink SQL 流批一体的计算水平，给予对批式场景特征的统一支持，现阶段也基本拥有好多个场景的落地式；
• 特征线下入湖：根据 Hudi On Flink 支持即时特征的线下数仓基本建设，主要是为了更好地支持实体模型训练样本拼凑场景线下特征回朔；
• Flink CEP 规则引擎支持：Flink SQL 实质上便是一种规则引擎，现阶段线上上大家把 Flink SQL 做为业务流程 DSL 过虑词义最底层的实行模块。但 Flink SQL 善于表示的 ETL 种类的过虑标准，不可以表述含有时钟频率种类的标准词义。直播间、电子商务场景的时钟频率标准必须试着 Flink CEP 更为错综复杂的规则引擎。
• Flink Native Windowing 体制引进：针对对话框种类的有状态特征，大家现在选用上文所讲的抽象化 SlotState 時间切成片计划方案统一开展支持。此外 Flink 自身给予了十分健全的对话框体制，根据 Window Assigner、Window Trigger 等部件可以非常灵活地支持各种各样对话框词义。因而后面大家也会在对话框特征测算场景引进 Flink 原生态的 Windowing 体制，更为灵敏地支持对话框特征梯度下降法。
• Flink HybridState Backend 构架：现阶段在字节数的网上场景中，Flink 最底层的 StateBackend 默认设置全是应用 RocksDB 储存模块。这类嵌入的储存模块不可以根据外界体制去给予状态数据的地热井和多个任务共享资源，因而人们必须支持 KV 去中心化储存计划方案，完成灵巧的特征状态回朔。
• 静态数据特性种类特征统一管理方法：根据特征服务平台给予统一的 DSL 词义，统一管理方法别的外界静态数据种类的特征服务项目。例如一些其它业务流程精英团队层面的客户归类、标识服务项目等。