流处理中的模型服务模式

在流处理管道中部署机器学习 (machine learning)模型，需要从传统的批处理评分模式进行根本性转变。传统批处理场景通常优先考虑吞吐量 (throughput)，而延迟通常不重要。然而，流式系统，特别是那些由Flink和Kafka支持的系统，则需要一种针对端到端延迟优化的架构，同时仍保持高吞吐量。关于如何集成模型（无论是直接嵌入 (embedding)到算子中还是作为外部服务公开），将决定管道的容错性、可扩展性和操作复杂度。

嵌入 (embedding)式模型模式

对于低延迟推理 (inference)来说，性能最高的方法是嵌入式模型模式。在这种架构中，模型工件直接加载到Flink TaskManager的内存中。推理逻辑作为标准算子函数执行，通常是RichMapFunction或RichFlatMapFunction。

这种方法消除了网络开销。数据保留在进程边界内，如果需要混洗，数据通过本地内存或网络缓冲区从特征生成算子传递到推理算子。对于可以表示为POJO（Plain Old Java Objects）或通过PMML或ONNX等轻量级格式序列化的模型，这可以实现亚毫秒级的推理时间。

要实现这一点，您需要重写Flink函数的open()方法来加载模型。这确保模型是每个并行实例加载一次，而不是每个事件加载一次。

public class EmbeddedInference extends RichMapFunction<FeatureVector, Prediction> {
    private transient ModelWrapper model;

    @Override
    public void open(Configuration parameters) {
        // 从分布式文件系统或缓存加载模型
        this.model = ModelLoader.load("s3://models/v1/classifier.onnx");
    }

    @Override
    public Prediction map(FeatureVector features) {
        return model.predict(features);
    }
}

然而，嵌入模型带来了很大的资源管理挑战。模型会与Flink运行时竞争CPU和内存。模型原生库中的内存泄漏（在TensorFlow或PyTorch的JNI桥接中很常见）可能导致整个TaskManager崩溃，从而造成管道不稳定。此外，扩展推理层需要扩展整个Flink作业，如果瓶颈纯粹是计算密集型推理而非I/O，这可能导致资源过度分配。

使用嵌入式模式时，数据在TaskManager内流动。推理逻辑与流处理在同一JVM中运行，共享资源。

外部服务模式

对于大型深度学习 (deep learning)模型或需要严格资源隔离的场景，外部服务模式更受青睐。在这种模式下，Flink算子充当客户端，向专用的模型服务基础设施（例如TensorFlow Serving、TorchServe或NVIDIA Triton）发送RPC调用（gRPC或REST）。

这种架构将流处理器与机器学习 (machine learning)模型的生命周期解耦。模型服务层可以在专用硬件（GPU/TPU）上独立扩展，而Flink则在标准通用硬件上管理状态和数据流。

实现主要依赖于Flink的异步I/O API（AsyncDataStream）。同步调用会阻塞算子线程，导致背压向上游传播并大幅降低吞吐量 (throughput)。通过使用AsyncWaitOperator，Flink可以并发处理多个进行中的请求。

在此模式下，单个事件的总延迟$L_{total}$定义为：

$L_{总} = L_{网络} + L_{队列} + L_{推理} + L_{序列化反序列化}$

其中$L_{网络}$是网络往返时间，$L_{队列}$是服务层队列中的等待时间，$L_{序列化反序列化}$是特征向量 (vector)序列化和预测反序列化的开销。

嵌入 (embedding)式执行与外部RPC调用之间的延迟分布比较。外部调用由于网络状况，引入了更高的基线延迟和更大的波动。

外部模式在顺序和检查点方面引入了复杂度。Flink为异步结果提供了两种模式：orderedWait和unorderedWait。

• 有序等待：确保如果事件A先于事件B进入，则A的结果在B之前发出。这增加了延迟缓冲，因为算子必须等到较早的结果到达后才能发出较快的结果。
• 无序等待：一旦外部服务响应，立即发出结果。这最大限度地减少了延迟并最大化了吞吐量，但会打乱事件顺序。如果下游需要严格的顺序（例如，用于时间序列分析），则必须使用水印和窗口进行流的重新排序。

动态模型更新

在生产环境中，模型会随时间退化并需要重新训练。为更新模型二进制文件而重启管道通常是不可接受的，因为这会导致停机时间和状态恢复成本。

对于嵌入 (embedding)式模式，Flink的**广播状态（Broadcast State）**模式提供了一种方案。您可以定义一个连接到模型仓库或通知主题的辅助流。当新的模型版本可用时，控制流会将模型元数据（如果模型文件较小，也可以是模型文件本身）广播到所有并行推理 (inference)算子。然后，这些算子会在内存中热插拔模型实例。

// 用于模型更新的控制流
BroadcastStream<ModelConfig> controlStream = env
    .addSource(new ModelConfigSource())
    .broadcast(modelStateDescriptor);

// 将数据流与控制流连接
dataStream
    .connect(controlStream)
    .process(new BroadcastModelProcessor());

在外部服务模式中，更新对Flink是透明的。模型服务集群执行滚动更新或金丝雀部署。Flink继续向负载均衡器端点发送请求。这减轻了数据工程团队的操作负担，但需要协调以确保Flink生成的特征与新模型版本预期的输入之间存在模式兼容性。

选择合适的架构

嵌入 (embedding)式模式和外部模式之间的选择通常取决于模型的复杂度以及组织的运行限制。

因素	嵌入式模式	外部服务模式
模型大小	小到中等 (< 500MB)	大型 (GB级别), LLM
延迟要求	超低 (< 10ms)	中等 (> 20ms)
硬件	CPU (为主)	GPU/TPU
扩展性	与Flink并行度耦合	独立扩展
部署	需要更新管道	独立于管道

对于许多高频交易或欺诈检测场景，由于延迟限制，嵌入式模式是必选方案。对于需要深度学习 (deep learning)的推荐引擎或内容分析，外部模式提供了必要的灵活性和硬件支持。

一种新兴的混合方法，通常称为Sidecar模式，试图连接这两种方式。在Kubernetes环境中，模型容器与Flink TaskManager在同一个Pod中运行。它们通过回环接口（localhost）通信，消除了物理网络跳数，同时保持进程隔离。这显著降低了$L_{网络}$，同时避免模型崩溃导致JVM停机。但这也增加了Kubernetes调度器和资源定义的复杂度。