3、Serving架构概览：离线批处理Serving、在线实时Serving、流式Serving架构对比

在生产环境中部署XGBoost模型时，选择合适的Serving架构直接决定了数据质量保障策略的复杂度与实施路径。不同的Serving架构对数据时效性、一致性校验、异常检测与回滚机制有着截然不同的要求。本章从数据质量视角出发，系统对比三种主流Serving架构：离线批处理Serving、在线实时Serving与流式Serving，帮助你在不同业务场景下做出正确的架构选型与数据质量保障决策。

3.1 三种Serving架构核心特征对比

3.2 离线批处理Serving架构

离线批处理Serving是最成熟的模型部署方式，适用于对延迟不敏感、需要全量数据打分的场景。典型技术栈包括Spark、Hive、MapReduce等大数据计算框架。

架构特点

• 数据源：HDFS / Hive 表 / 对象存储中的历史数据分区
• 特征计算：批量ETL作业，特征可预先计算并物化
• 模型加载：从模型仓库加载固定版本，一次加载多次预测
• 结果输出：写入结果表 / 文件，供下游消费

数据质量保障要点

• 分区校验：确保输入数据分区完整，无缺失、无重复
• 特征一致性：离线特征与在线特征计算逻辑对齐，避免训练/推理偏差
• 数据漂移检测：对比当前批次与历史批次的数据分布（PSI / KS指标）
• 结果校验：抽样比对预测结果与预期范围，防止模型异常

# 离线批处理数据质量校验示例（伪代码）
def validate_batch_input(spark, table_name, partition_dt):
    # 1. 分区完整性检查
    expected_partitions = generate_expected_partitions(partition_dt)
    actual_partitions = spark.sql(f"SHOW PARTITIONS {table_name}").collect()
    assert set(expected_partitions) == set(actual_partitions), "分区缺失！"
    
    # 2. 特征缺失率检查
    null_rates = spark.sql(f"""
        SELECT 
            SUM(CASE WHEN feature_a IS NULL THEN 1 ELSE 0 END) / COUNT(*) AS null_rate_a,
            SUM(CASE WHEN feature_b IS NULL THEN 1 ELSE 0 END) / COUNT(*) AS null_rate_b
        FROM {table_name}
        WHERE dt = '{partition_dt}'
    """).collect()[0]
    assert null_rates.null_rate_a < 0.05, "特征A缺失率超过5%！"
    
    # 3. 数据漂移检测（PSI）
    psi = compute_psi(histogram_current, histogram_historical)
    assert psi < 0.1, f"PSI={psi:.3f} 超过阈值！"

3.3 在线实时Serving架构

在线实时Serving要求模型在毫秒级内响应请求，通常以RESTful API或gRPC接口形式暴露。典型技术栈包括Flask/FastAPI + XGBoost原生模型、Triton Inference Server、Seldon Core等。

架构特点

• 请求入口：负载均衡 → API Gateway → 模型服务实例
• 特征获取：实时从Redis / 特征存储 / 上游服务获取
• 模型推理：单条请求独立推理，支持模型版本路由
• 响应输出：直接返回预测结果，通常附带置信度与模型版本信息

数据质量保障要点

• 请求特征完整性：实时校验必填特征是否存在，缺失特征使用默认值或拒绝请求
• 特征值域校验：检查特征值是否在合理范围内，防止异常值导致模型崩溃
• 模型版本一致性：确保同一请求链路中特征计算逻辑与模型训练时一致
• 超时与熔断：特征获取超时时的降级策略，避免级联故障

3.4 流式Serving架构

流式Serving介于离线与在线之间，以微批次或事件驱动方式处理持续到达的数据。典型技术栈包括Apache Kafka + Flink、Spark Streaming、Kafka Streams等。

架构特点

• 数据源：Kafka Topic / Pulsar 等消息队列中的实时事件流
• 特征计算：基于滑动窗口 / 会话窗口的实时特征聚合
• 模型推理：微批次推理或逐事件推理，支持状态管理
• 结果输出：写入下游Kafka Topic / 数据库 / 实时仪表盘

数据质量保障要点

• 乱序数据处理：设置watermark与allowed lateness，处理延迟到达的事件
• 窗口边界一致性：确保窗口触发逻辑与模型训练时的窗口定义一致
• 状态一致性：使用exactly-once语义保障状态不丢失、不重复
• 数据倾斜处理：监控key分布，防止热点key导致窗口计算延迟

# 流式Serving数据质量监控（Flink SQL示例）
-- 1. 监控输入事件延迟
SELECT 
    window_start,
    COUNT(*) AS event_count,
    AVG(CASE WHEN event_time < watermark THEN 1 ELSE 0 END) AS late_event_ratio
FROM TABLE(TUMBLE(TABLE events, DESCRIPTOR(event_time), INTERVAL '5' MINUTES))
GROUP BY window_start;

-- 2. 特征缺失率实时监控
SELECT 
    feature_name,
    COUNT(*) AS total_count,
    SUM(CASE WHEN feature_value IS NULL THEN 1 ELSE 0 END) AS null_count,
    SUM(CASE WHEN feature_value IS NULL THEN 1 ELSE 0 END) / COUNT(*) AS null_rate
FROM feature_stream
GROUP BY feature_name;

3.5 三种架构的Serving数据质量保障体系对比

下图从数据质量保障体系的视角，展示了三种Serving架构在数据接入、特征计算、模型推理、结果输出四个阶段的质量控制节点差异。

3.6 架构选型建议

在实际项目中，Serving架构的选择往往不是非此即彼，而是根据业务需求混合使用。以下选型建议可供参考：

3.7 本章小结

• 离线批处理Serving：数据质量重点在数据完整性与特征一致性，适合T+1或小时级批量预测场景。
• 在线实时Serving：数据质量重点在请求级特征校验与模型版本管理，适合毫秒级响应场景。
• 流式Serving：数据质量重点在乱序处理与状态一致性，适合近实时事件驱动场景。
• 三种架构在数据质量保障的时机、粒度、工具链上存在本质差异，需要分别设计质量监控方案。