⑴ 年，字节跳动旗下产品总 MAU 已超过 亿。在以抖音、今日头条、西瓜视频等为代表的产品业务背景下，强大的推荐系统显得尤为重要。Flink 提供了非常强大的 SQL 模块和有状态计算模块。目前在字节推荐场景，实时简单计数特征、窗口计数特征、序列特征已经完全迁移到 Flink SQL 方案上。结合 Flink SQL 和 Flink 有状态计算能力，我们正在构建下一代通用的基础特征计算统一架构，期望可以高效支持常用有状态、无状态基础特征的生产。
⑵如上文所述，新的特征一体化方案解决的主要痛点是：如何应对各种类型（一般是滑动窗口有状态特征的计算问题。对于这类特征，在离线计算层架构里会有一个状态存储层，把抽取层提取的 RawFeature 按照切片 Slot 存储起来(切片可以是时间切片、也可以是 Session 切片等)。切片类型在内部是一个接口类型，在架构上可以根据业务需求自行扩展。状态里面其实存储的不是原始 RawFeature（存储原始的行为数据太浪费存储空间，而是转化为 FeaturePayload 的一种 POJO 结构，这个结构里面支持了常见的各种数据结构类型：
⑶状态层更新的业务接口：输入是 SQL 抽取/拼接层抽取出来的 RawFeature，业务方可以根据业务需求实现 updateFeatureInfo 接口对状态层的更新。对于常用的特征类型内置实现了 update 接口，业务方自定义特征类型可以继承 update 接口实现。
⑷当然对于无状态的 ETL 特征是不需要状态存储层的。
⑸特征计算层完成特征计算聚合逻辑，有状态特征计算输入的数据是状态存储层存储的带有切片的 FeaturePayload 对象。简单的 ETL 特征没有状态存储层，输入直接是 SQL 抽取层的数据 RawFeature 对象，具体的接口如下：
⑹有状态特征聚合接口
⑺无状态特征计算接口
⑻另外通过触发机制来触发特征计算层的执行，目前支持的触发机制主要有：
⑼周期性定时触发特征的计算逻辑
⑽上游状态层每次更新即触发特征计算
⑾自定义特征计算的触发时机
⑿目前在字节推荐场景，新一代特征架构已经在抖音直播、电商、推送、抖音推荐等场景陆续上线了一些实时特征。主要是有状态类型的特征，带有窗口的一维统计类型、二维倒排拉链类型、二维 TOPK 类型、实时 CTR/CVR Rate 类型特征、序列类型特征等。
⒀在业务核心指标达成方面成效显著。在直播场景，依托新特征架构强大的表达能力上线了一批特征之后，业务看播核心指标、互动指标收益非常显著。在电商场景，基于新特征架构上线了 +实时特征。其中在直播电商方面，业务核心 GMV、下单率指标收益显著。在抖音推送场景，基于新特征架构离线状态的存储能力，聚合用户行为数据然后写入下游各路存储，极大地缓解了业务下游数据库的压力，在一些场景中 QPS 可以下降到之前的 %左右。此外，抖音推荐 Feed、评论等业务都在基于新特征架构重构原有的特征体系。
⒁值得一提的是，在电商和抖音直播场景，Flink 流式任务状态最大已经达到 T，而且这个量级还在不断增大。预计不久的将来，单任务的状态有可能会突破 T，这对架构的稳定性是一个不小的挑战。
⒂目前 Flink 提供两类 StateBackend：基于 Heap 的 FileSystemStateBackend 和基于 RocksDB 的 RocksDBStateBackend。对于 FileSystemStateBackend，由于数据都在内存中，访问速率很快，没有额外开销。而 RocksDBStateBackend 存在查盘、序列化/反序列化等额外开销，CPU 使用量会有明显上升。在字节内部有大量使用 State 的作业，对于大状态作业，通常会使用 RocksDBStateBackend 来管理本地状态数据。RocksDB 是一个 KV 数据库，以 LSM 的形式组织数据，在实际使用的过程中，有以下特点：
⒃业务方使用 State 的场景多是 get-update，在使用 RocksDB 作为本地状态存储的过程中，出现过以下问题：
⒄针对上述问题，可以通过在内存维护一个对象 Cache，达到优化热点数据访问和降低 CPU 开销的目的。通过上述背景介绍，我们希望能为 StateBackend 提供一个通用的 Cache 功能，通过 Flink StateBackend Cache 功能设计方案达成以下目标：
⒅经过和字节基础架构 Flink 团队的合作，在实时特征生产升级，上线 Cache 大部分场景的 CPU 使用率大概会有高达 %左右的收益；
⒆在字节内部的实时特征离线生成链路当中，我们主要依赖的数据流是 Kafka。这些 Kafka 都是通过 PB 定义的数据，字段繁多。公司级别的大 Topic 一般会有 +的字段，但大部分的特征生产任务只使用了其中的部分字段。对于 Protobuf 格式的数据源，我们可以完全通过裁剪数据流，mask 一些非必要的字段来节省反序列化的开销。PB 类型的日志，可以直接裁剪 idl，保持必要字段的序号不变，在反序列化的时候会跳过 unknown field 的解析，这对于 CPU 来说是更节省的，但是网络带宽不会有收益，预计裁剪后能节省非常多的 CPU 资源。在上线了 PB IDL 裁剪之后，大部分任务的 CPU 收益在 %左右。
⒇新架构特征生产任务本质就是一个有状态的 Flink 任务，底层的状态存储 StateBackend 主要是本地的 RocksDB。主要面临两个比较难解的问题，一是任务 DAG 变化 Checkpoint 失效，二是本地存储不能很好地支持特征状态历史数据回溯。
⒈当前新一代架构还在字节推荐场景中快速演进，目前已较好解决了实时窗口特征的生产问题。
⒉出于实现统一推荐场景下特征生产的目的，我们后续会继续基于 Flink SQL 流批一体能力，在批式特征生产发力。此外也会基于 Hudi 数据湖技术，完成特征的实时入湖，高效支持模型训练场景离线特征回溯痛点。规则引擎方向，计划继续探索 CEP，推动在电商场景有更多落地实践。在实时窗口计算方向，将继续深入调研 Flink 原生窗口机制，以期解决目前方案面临的窗口特征数据退场问题。
⒊郭文飞，字节跳动推荐系统基础服务方向负责人。 年初加入字节，主要负责推荐系统基础服务方向，例如消重、计数、特征等。
⒋字节跳动推荐架构团队实时计算方向，负责抖音、今日头条、西瓜视频等超 亿用户产品推荐系统架构实时计算系统的设计和开发，保障系统稳定和高可用。抽象通用实时计算系统、构建统一的推荐特征中台，实现灵活可扩展的高性能存储系统和计算模型，为推荐业务实现先进的消重、计数、特征服务等实时推荐数据流系统。