实时特征框架的生产实践

一、业务背景

使用场景

推荐系统在当今的互联网应用中扮演着至关重要的角色，它极大地丰富了用户体验，帮助用户在海量信息中发现和探索他们可能感兴趣的内容。然而，随着数据量的激增和用户需求的日益多样化，传统的离线推荐系统已经难以满足用户对于实时性和个性化推荐的需求。在这种背景下，实时推荐系统应运而生，它能够迅速响应用户的行为变化，并提供更为精准的个性化推荐。

为了实现这一目标，高效的实时推荐系统必须能够持续更新用户和物品的特征，以实时捕捉和反映它们的最新行为和兴趣变化。在这个过程中，实时特征的准确性和稳定性变得至关重要，它们直接影响到推荐系统在生产环境中的效果表现。

解决问题

目前特征体系可以分为两类：统计类型、属性类型。

在实时特征计算的实践中，如果单纯依赖Flink SQL而不进行定制开发，可能会面临一些挑战，例如处理同质滑窗特征状态的冗余性以及特征冷启动的线上问题。为了突破这些限制，需要构建一个全面的实时处理框架，以适应多样化的实时特征业务场景。

该框架旨在简化与底层组件（如Flink、Kafka、Redis、HBase等）的交互，隐藏其复杂性，让业务开发人员无需深入了解这些组件的细节。通过内置的序列特征和滑动窗口特征算子，开发人员可以专注于业务逻辑的实现，从而提升开发效率和系统的可维护性。

二、框架设计

整体构架

外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传

状态设计

业务上有许多同质滑窗特征，它们具有相同的计算逻辑，但查询的窗口长度各异。如果对每个滑窗特征都使用Flink原生的hopWindow，不仅会导致状态的无限膨胀，还可能在数据刷新时引发IO爆炸的风险。为了解决这一问题，我们对状态管理进行了优化重构。

根据最小的窗口单位将状态划分为多个分片，确保每个分片对齐到完整的时间粒度。例如，如果以小时为单位，就对齐到每小时的整点；如果以天为单位，则对齐到每天的0点。这样，具有相同窗口单位的特征就可以共享状态，例如，最近1小时、2小时、3小时的统计特征都可以从1小时的分片中进行统计。

当数据到达时，根据事件的时间戳（eventTime）将其合并到相应的分片中。然后，根据窗口的大小配置，查询对应的分片并进行聚合，最后刷出聚合结果。这种方法不仅提高了数据处理的效率，还降低了系统资源的消耗。

通过上面的状态重构方案，我们来解决滑动窗口的两类问题：

比如计算一个item最近1小时、2小时、3小时内的曝光数、点击数和转化数。

满足不同长度时间周期的计算

可以根据窗口单位选择对应的分片进行合并计算，这意味着，可以直接利用已经对齐到小时分片的状态，而无需为每个不同长度的窗口单独维护状态。

满足不同查询时间(滑动查询)的计算

在处理滑动查询时，如果遇到数据上报的空白期，比如11:00到12:00之间没有数据，我们利用Flink的定时器功能来应对。通过设定定时器，可以在没有新数据到达时自动触发计算，将这段时间的数据视为0，并更新状态。这样，即使数据上报出现间断，我们也能确保推荐系统的状态保持最新。

算子实现

接口定义

框架设计了三种核心算子来处理实时特征：普通序列特征算子、滑动序列特征算子和滑窗统计算子。这些算子都继承自一个公共的算子抽象类，并实现了特定的方法来执行它们的功能。

compute 方法负责根据事件时间（eventTime）来获取相应的状态分片，注册下一个触发计算的定时器，并完成聚合结果的输出。这个方法是算子处理实时数据流的核心，确保了数据的实时处理和状态的及时更新。

onTimer 方法则处理定时器触发时的逻辑。当定时器触发时，它会根据触发时间（triggerTime）扫描相应的状态分片，并输出聚合结果。这允许算子在预定的时间点进行数据的聚合和输出，即使在数据流中出现间隙或延迟的情况下也能保持计算的连续性。

// 计算特征结果，由子类实现
public abstract void compute(long processTimeInMillis, FcDataObj input, byte[] stateBytes,                             
                             StateContext context) throws InvalidProtocolBufferException;

// 定时器触发时调用的方法，由子类实现
public void onTimer(long triggerTime, byte[] currentStateBytes, StateContext context)        
        throws Exception {
}