实时与批处理特征计算

特征平台为模型获取特征提供了统一的接口，但填充它的底层数据管道可以以两种基本不同的模式运行：批处理和实时。主要的工程任务是设计这些管道，以确保在两种环境下计算特征的方式保持一致，从而防止训练-服务偏差。这个决定直接影响系统的延迟、成本和运行复杂性。

批处理特征计算

批处理特征计算涉及在独立、按计划运行的作业中处理大量数据。这是生成训练数据和处理无需秒级新鲜度特征的传统模式。

主要应用场景：训练数据生成

批处理最常见的应用是为模型训练创建历史特征集。一个按计划运行的作业，可能每天或每周运行，从数据湖（如Amazon S3或Google Cloud Storage）或数据仓库读取原始历史数据，应用一系列转换，并将生成的特征写入离线存储。这种离线存储通常针对训练作业的高吞吐量读取进行优化，常使用Apache Parquet或Delta Lake等列式格式。

架构和工具

典型的批处理管道经过编排，可以高效处理数TB的数据。该过程利用分布式计算框架将工作负载并行化到机器集群中。

这是一个标准的批处理特征计算管道。数据批量读取，由Apache Spark等分布式引擎使用预定义逻辑处理，并存储为离线优化格式。

批处理计算的特点是：

• 高吞吐量： 用于经济高效地处理大量数据。
• 高延迟： 作业是按计划运行的，可能需要数分钟、数小时甚至更长时间才能完成。数据新鲜度以小时或天衡量。
• 成本效益： 优化以实现每处理字节的低成本，通常利用计算集群的竞价实例。
• 示例特征： 用户生命周期价值、30天购买次数，或基于整个商品目录计算的产品嵌入。

实时特征计算

相反，实时（或流式）特征计算在数据到达时处理，通常是逐个事件或以小微批次形式。这种方法对于必须反映用户或系统即时情况的特征来说是必需的。

主要应用场景：在线推理

当模型对实时请求进行预测时，可能需要仅几秒或几毫秒前生成的特征。例如，欺诈检测模型需要知道信用卡是否刚刚在另一个城市被使用，或者推荐引擎需要加入用户刚刚点击的产品。实时管道通过从Apache Kafka或AWS Kinesis等消息队列消费事件、执行转换，并将结果加载到低延迟的在线特征存储中来实现这一点。

架构和工具

实时特征计算的架构旨在实现高速和持续可用性。

一个标准的实时特征计算管道。Apache Flink等流处理引擎消费实时事件，应用转换，并更新Redis等低延迟在线存储。

实时计算的特点是：

• 低延迟： 旨在实现亚秒级数据新鲜度，使特征能够即时用于推理。
• 持续处理： 系统“始终开启”，处理持续的事件流。
• 更高的成本和复杂性： 维护高可用的流系统和低延迟数据库在运行上比运行计划的批处理作业要求更高且成本更昂贵。
• 示例特征： 过去5分钟内查看的商品数量、用户当前位置，或60秒窗口内的平均交易价值。

统一的挑战

批处理（例如PySpark）和实时（例如Flink）管道拥有两个独立的 codebase 会带来很大的风险。即使在空值处理或时间戳舍入方式上存在微小差异，也可能导致训练期间和在线服务时使用的特征值出现偏差。这是训练-服务偏差的一个典型原因。

目标是确保转换逻辑一致。一种现代且有效的设计模式是采用流优先架构。

在这种模式下，所有特征逻辑都在流处理框架中一次定义。该框架成为单一的数据来源。

1. 用于实时服务： 流式作业持续运行，消费实时事件并填充在线存储。
2. 用于批处理训练： 相同的流式应用程序逻辑用于处理历史数据。这通过将数据湖中的事件“回放”到流处理器中完成，流处理器随后将计算出的特征写入离线存储。

这种统一的方法保证了特征 f(x_train) 和 f(x_serve) 由完全相同的代码计算。

一种统一的流优先架构。单一流处理器，通过共享的特征逻辑，既可以根据实时事件服务在线存储，也可以通过回放历史事件来回填离线存储。

如何选择合适方案

大多数生产系统采用混合方法。决定是批处理还是实时计算特征，完全取决于模型对数据新鲜度的要求以及可接受的成本。

特性	批处理计算	实时计算
延迟	高（分钟到天）	低（毫秒到秒）
数据量	非常大（TB到PB）	小，持续的事件流
成本	每单位数据低	每单位数据高
复杂性	较低的运行开销	较高的运行开销
主要应用	训练数据生成	在线推理服务
示例特征	user_lifetime_spend	user_clicks_last_minute

作为AI基础设施工程师，您的职责不仅是构建这些管道，还要提供一个平台，让数据科学家可以轻松定义特征，系统能够智能地将它们路由到相应的计算引擎，同时保证训练和服务环境之间的一致性。