第5章 · 流式数据架构与实时视频AI

第 5 章 · 流式数据架构与实时视频AI

章节摘要：实时 AI 不只是推理快，它背后的数据也必须是"流动的"。传统批处理架构（攒一批再算）无法支撑实时推荐、实时风控、在线学习这类场景——用户行为产生的数据要立刻被处理、算成特征、喂给模型。这一章先讲流式数据架构：Kafka 作为消息总线承接高吞吐数据流，Flink 做流式计算算实时特征，向量数据库支撑实时检索。再讲流式视频 AI：视频流（监控、直播、车载摄像头）要逐帧或抽帧做目标检测、跟踪、分割，数据量巨大，怎么用边缘计算（Jetson、RK3588）配合 WebRTC 做低延迟处理。两块合起来，是实时 AI 的数据底座。

学习目标

阅读完本章，你应当能够：

1. 说清 Kafka 作为消息队列在流式数据架构里的角色
2. 区分批处理和流处理，理解 Flink 的流式计算模型
3. 描述实时特征计算和在线推理的数据链路
4. 设计一个流式视频 AI 的边缘处理架构
5. 对比云端、边缘、端侧三种视频 AI 处理方案的优劣

核心概念速览

实时 AI 的数据链路：数据产生即入流，流处理即算特征，特征即喂模型，模型即出决策。每一环都要低延迟，任何一环攒批都会拖垮整体。

子章节导航

5.1 Kafka与Flink流式数据处理

讲流式数据架构的两大支柱：Kafka 做高吞吐、可持久化的消息总线，Flink 做流式计算算实时特征。还包括向量数据库在实时检索里的角色，以及流批一体的架构演进。

5.2 流式视频AI与边缘计算

视频流数据量巨大，全传云端不现实。这节讲流式视频 AI 怎么做——抽帧策略、目标检测与跟踪、边缘计算（Jetson、RK3588、Hailo）分担云端压力、WebRTC 低延迟传输。

子章节之间的逻辑关系

先讲通用的流式数据管道（5.1 的 Kafka+Flink），这是所有实时 AI 的数据底座；再聚焦视频这一特殊数据类型（5.2），它数据量最大、对边缘计算需求最强。从通用到特定。

5.1 通用流式数据管道  ──►  5.2 视频流特殊处理
（Kafka+Flink）            （边缘+抽帧+检测）
​

前置知识与后续延伸

• 前置知识：第 1 章的延迟和吞吐权衡，第 2 章的流式推理基础。理解推理端的延迟来源后，才能理解数据管道的延迟如何与之叠加。
• 后续延伸：本章的流式数据架构和第 4 章的端侧推理结合，就是完整的"云-边-端"协同实时 AI 体系。

流式数据架构的演化坐标

把本章放在更大的架构演化里看。数据系统的主旋律过去二十年是"批到流"的迁移：2003 年的 MapReduce 论文确立了"攒一批、洗一批、算一批"的范式，Hive 数仓把它推向成熟；但批处理的固有延迟（小时级 T+1）撑不住推荐和风控的秒级需求，2011 年 LinkedIn 开源 Kafka（高吞吐日志总线）和之后 UC Berkeley 孵化的 Spark Streaming、再后来的 Flink（真流式、事件时间语义），共同构成了 lambda 架构的双腿——批层保准确、流层保新鲜。最近十年的方向是两条腿合并：Kafka 用 Exactly-Once 语义和可重放日志把"流"变成可回溯的事实来源，Flink 用流批一体 API 让同一份计算逻辑既能跑实时也能跑离线回填，lambda 架构的双系统维护成本随之大幅下降。理解这条线，你就能判断自己该上多重的架构：日增千万级事件、秒级新鲜度要求，才需要完整的 Kafka+Flink 栈；更小的量级用云厂商托管的轻量管道（如队列加函数计算）往往更划算。

视频 AI 这条支线的演化同样有阶段感。第一代是"摄像头回传、云端分析"：专线拉流、云端 GPU 集群解码检测，带宽成本高、延迟秒级到分钟级。第二代是"边缘盒子前置"：Jetson、RK3588 这类边缘设备在摄像头旁完成解码和推理，只回传结构化结果和异常片段，带宽成本降一到两个数量级。正在发生的第三代是"摄像头内生智能"：ISP 芯片直接集成 NPU，检测跟踪在传感器内部完成。选型时先看自己处在哪一代的需求：多数中小场景，第二代边缘盒子加云端聚合仍是性价比最优解。

图：云-边-端三层实时 AI 体系

章节衔接的自查问题

读完本章，问自己三个问题：实时特征从事件发生到被推理读取，中间经过几跳、每一跳的延迟预算是多少？你的场景里哪些数据值得走流式、哪些留在批处理，判断依据是什么？如果边缘设备断网，你的视频分析链路是降级还是停摆？这三个问题分别对应 5.1 的管道设计、流批取舍和 5.2 的边缘自治能力，答不上来就回到对应小节再翻一遍，把管道图和边缘分层图在自己手上重画一次，印象会扎实很多。画图时顺带标出每条数据流的量级（事件条数、视频码率、上行的字节数），这张带数字的图就是你跟老板、跟运维、跟云厂商谈判时的底牌，也是日后排障时最先摊开看的作战地图。数字会过时，但「先画图再标数」这个动作不会，它强迫你在动手前想清楚每一层各自承担什么。