当前AI故障源于批处理导致数据陈旧。Apache Kafka提供流式管道，实现低延迟实时预测，通过分区、实时特征工程等，确保数据新鲜度。实时AI成功依赖流式数据基础设施，批处理是劣势。
译自：Your AI Models Aren’t Slow, but Your Data Pipeline Might Be
作者：Anil Inamdar
当前工程领域中一个显而易见的问题是，大多数 AI 故障并非源于模型准确性，甚至也不是训练数据的质量。相反，许多组织未能从 AI 中获得他们想要（或期望）的结果，是因为他们试图通过批处理数据管道提供实时预测。
我接触过许多企业，他们构建了令人印象深刻的机器学习 (ML) 模型，能够提供亚秒级推理时间……然后却向这些模型喂食已经有数小时之久的数据。法拉利引擎却配着方形轮子。
亟需关注的架构鸿沟
生产 AI 遵循一种可预测的模式：在测试中表现出色的模型一投入生产，就立即在每晚的 ETL（提取、转换、加载）作业、伪装成数据湖的数据沼泽以及难以跟上流量速度的特征存储面前举步维艰。于是，欺诈在六小时后才发现可疑交易，你的推荐引擎建议的是上周已过时的意图信号，而你的“动态”定价却运行在静态数据上。
这正是 Apache Kafka（明确地说，我指的是完全 开源的 Apache Kafka）从根本上改变游戏规则的地方。当所有人都痴迷于 Transformer 模型和神经网络架构时，那些在生产 AI 中真正取得成功的团队却悄悄地解决了构建流式数据管道的问题，从而完全消除了数据陈旧的问题。
为什么 Kafka 适用于批处理失败的场景
AI 工作负载有特定的要求，批处理无法满足，也永远无法满足。当你每秒提供数百万次预测时，每一毫秒的数据陈旧都会累积成客户面临的问题。Kafka 以 2 毫秒延迟交付消息的能力，成为发现欺诈与向审计师解释损失之间的区别。
传统消息队列在 AI 规模下会成为瓶颈，因为它们并非为机器学习工作负载的体量和速度而设计。Kafka 的分区模型允许你并行化数据摄取和模型服务，而不会出现协调器瓶颈。该架构完美地映射了推理工作负载的易并行性：每个模型实例一个分区、自动负载分配和无缝横向扩展。
大多数企业尚未为实时 AI 做好准备，因为他们的数据基础设施仍然停留在批处理时代。
然而，真正的魔力在于有状态的流处理。通过 Kafka Streams，你不仅在系统之间移动数据，而是在传输过程中对其进行转换。特征工程发生在流中，而不是批处理作业中。聚合持续更新。你的模型始终能看到当前特征向量，因为特征本身正在实时计算。
成功采用这种方法的团队遵循一种可识别的模式，其中：
- 原始事件从应用程序流入 Kafka 主题。
- Kafka Streams 执行窗口聚合，跟踪用户在过去五分钟、一小时和一天内的行为。
- 新数据到达时，特征向量立即更新。
- 模型从充满预计算特征的丰富主题中消费。
- 预测回到 Kafka，馈送给下游系统，下游系统立即对其采取行动。
最终结果是一种始终与现实保持同步的架构。没有延迟或批处理瓶颈，只有持续智能从源头流向模型再流向应用程序。
实施细节至关重要
启动一个 Kafka 集群然后寄希望于最好结果并不是一个策略。你是否能成功实施取决于对这些关键模式的理解。
你的分区策略决定了下游的一切。随机分布看似最简单，但会破坏数据局部性。相反，请按实体（如 user_id、session_id 或 device_id）进行分区。这样做可确保相关事件落在同一分区上，从而在无需分布式事务的情况下实现有状态处理。
然后，当你的推荐模型需要用户的所有事件时，它们已经同位存放。或者，无论何时你的欺诈检测系统需要交易历史时，它都可以无需跨分区连接即可轻松访问。
模式演进也可能成就或毁掉你的部署。我保证你的 AI 模型将比你的数据契约演进得更快。从第一天开始就使用 Avro 或 Protobuf 结合模式注册中心。JSON 最初可能看起来更容易，但生产 AI 管道中无模式数据会导致静默故障、数据损坏以及模型基于畸形输入进行预测。与 JSON 相比，二进制格式还能显著减少消息大小（通常是大幅减少），从而降低基础设施成本和减少延迟。
在金融或医疗保健 AI 系统中，精确一次语义是基本要求。将生产者配置为安全重试，将消费者配置为完全事务性。是的，你将损失大约 20% 的吞吐量，但这对于完整性而言是微小的代价（而且远低于清理重复收费或在监管机构面前为糟糕的医疗预测辩护的成本）。
那些目前在 AI 领域取得成功的人，与其说他们拥有最好的模型，不如说他们拥有最好的数据基础设施。
训练数据需要持久存储，但将所有内容保存在 Kafka 的热存储中会破坏经济效益。将分层存储部署到你偏好的对象存储，同时保持 24 到 48 小时的数据为热数据以用于实时处理，并自动将其余数据老化至冷存储。你的训练管道仍然可以访问历史数据，而无需支付昂贵的 SSD 存储费用。
如果说 Kafka 有一个我看到团队持续错过的超能力，那就是针对特征存储的日志压缩。日志压缩仅保留每个键的最新值，同时保留主题结构。它非常适合那些你只需要当前状态而不需要全部历史记录的特征存储。你的模型始终能获得最新的用户资料、当前账户余额和最新互动，所有这些都无需查询数据库或维护复杂的缓存层。
构建你的流式 AI 架构
从一个受数据延迟困扰的用例开始。也许你的推荐系统提供陈旧结果，或者你的监控系统延迟 30 分钟才发出警报。构建一个概念验证，展示流式处理的优势。
将应用程序事件直接流式传输到 Kafka，跳过中间存储。然后：
- 在 Kafka Streams 中计算特征，而不是在批处理中进行预处理。
- 让模型从 Kafka 主题中消费，而不是查询数据库。
- 将预测通过 Kafka 流回下游系统。
- 严格监控你的 P99 延迟。
- 一旦数据新鲜度低于你的服务级别协议 (SLA)，那就是你的扩展触发器。
- 在需要之前增加分区。
- 在出现故障之前增加副本。
过度配置 Kafka 的成本与提供陈旧预测的成本相比是最小的。
以一个令人不安的真相结尾
大多数企业尚未为实时 AI 做好准备，因为他们的数据基础设施仍然停留在批处理时代。他们投入数百万美元用于为历史分析而非实时智能优化的数据湖和数据仓库。他们围绕批处理作业编排而非流处理组建团队，并创建了假设数据处于静止状态而非运动状态的架构。
Kafka 不仅仅是一种技术选择。这个开源平台是一种架构理念，它认为数据应从源头持续流向消费端。有了 Kafka，你将致力于消除批处理引入的人为延迟，并认识到在现代 AI 系统中，新鲜数据始终胜过复杂模型。
那些目前在 AI 领域取得成功的人，与其说他们拥有最好的模型，不如说他们拥有最好的数据基础设施。这种基础设施越来越多地建立在流式基础上，从源头消除数据陈旧。批处理是你再也无法承受的竞争劣势。
