「Agent 工程化」方向-Kafka 不止于消息 流·算·湖一体化实时数据平台 数据进来即算、算完即入湖 一个 Kafka 打通实时链路的采集、计算与沉淀

Kafka不止于消息流·算·湖一体化实时数据平台数据进来即算、

算完即入湖

——

一个

Kafka

打通实时链路的采集、

计算与沉淀3技术深潜2流

·

算

·

湖一体化1趋势与挑战目录

数据新鲜度谁掌握了实时数据的入口，谁就掌握了AI应用的数据命脉AI时代，实时数据成为核心生产资料数据一致性实时供给数据即用实现「实时采集→计算→入湖」

，

过去要拼装一条长链路链路每多一跳，延迟、故障点与成本都在叠加组件多链路长成本高运维重重磅发布ApsaraMQfor

Kafka算Kafka

原生流计算能力流统一实时数据入口一句话定位：

流入、就地算、原生入湖——一个平台闭环原生入湖沉淀湖整体架构：

一份数据，

流转算存一体ApsaraMQ

for

Kafka

实时数据平台流算湖数据源数据湖

/

下游流

·Stream：统一实时数据入口——平台的地基所有实时数据的第一跳

，决定了后面算与湖的上限一份多用统一入口缓冲削峰算

·

Processing：

Kafka原生流计算能力——数据进来即算三层能力同源于一份流入数据，按需组合、互不前置Streaming

Agent智能体Embedding流计算向量化SQL实时

ETL示例SQL实时处理能力过滤/裁剪/转换/脱敏窗口聚合多流Join

·维表关联结果多路输出全托管Serverless对流入数据做实时清洗与标准化滚动/滑动/会话窗口，实时指标统计实时宽表构建

，多源数据即时融合写回新Topic、直接入湖、或推送下游按计算量计费

，无需管理计算集群流计算

·SQL：

用熟悉的SQL定义实时数据处理典型用途SQL实时处理能力内建对接千问大模型

向量随数据流转

批量

+重试

+缓存

实时

Embedding：数据流经

Kafka即完成向量化，

直连AI场景数据一次流入，

即完成向量化，AI场景无需再等离线加工典型AI场景实时知识库构建实时召回特征内容语义索引Streaming

Agent：数据流经

Kafka时，

被AI实时理解与处理实时内容审核实时智能分流事件驱动AI处理告警智能研判实时调用大模型智能路由有状态Agent阿里云百炼协同平台能力典型用途湖

·

Lake：原生入湖沉淀——实时进、

湖里存、

随处用原生写

OSS

·

DLF

管元数据Schema

自适应演进开放不锁定核心价值：从拼装长链路，到一个平台闭环链路更短实时智能分流事件驱动AI处理告警智能研判链路长组件多运维重成本高现在

·一个平台闭环过去

·拼装长链路技术特点：六大特性

，

重新定义实时数据平台030604010205同一套平台能力，按场景组合，不需要为每个场景重建链路典型场景：谁在用、

用来做什么实时数仓

/

湖仓一体IoT

/

车联网AI

应用实时供给日志实时分析一套底座，

两条独立数据路径T

E

C

H

N

IC

A

L

D

E

E

P

D

I

V

E03共同底座

·存算分离

Kafka标准

Kafka协议

·存算分离

·Serverless弹性可选组合01TABLE

·原生入湖（完整历史/可追溯）完整历史与可追溯02SQL

·实时计算（在线决策/新鲜度）在线决策依赖新鲜度技术主线

·需求与能力闭环产品路径产品路径责任边界责任边界存算分离支撑快速扩缩与故障接管，

Fence与

EpochCAS守住单写边界存算分离弹性架构存算分离底座

·存算分离高可用架构单写一致性保障IO

Fence解决主从切换双写快速故障切换性能与规模效率性能效率｜线程、GC与存储协同优化底座

·领先的弹性与规模效率共享存储底座已在生产环境实现计算与数据解耦

，故障恢复无需搬迁历史数据，并经过大规模、多行业场景的长期验证与持续打磨。领先架构故障恢复｜目标秒级恢复规模效应｜集群越大收益越明显架构代际｜共享存储领先落地缩短的是外部运行时与责任边界；可见性由提交间隔与文件布局共同决定外部运行时的代价（Flink/Spark外置成表）开放表路径已成熟

，难点在持续写入与维护TableTopic路径（托管成表关系）Topic一键启用湖

·原生入湖8个环节

，责任分散责任收敛进平台状态与提交分散三步可见链路运维边界偏重开放复用OSS

Table

Bucket

·承载开放表与原子提交Table

Bucket承载开放表

·多引擎按同一Snapshot读取有效一次（effectiveexactly-once）：候选文件可重写

，只让一个提交结果可见位点与Snapshot

同步推进，才构成可恢复、可重复执行的入湖语义04可见Snapshot02Schema感知湖

·写入总图03事务提交01记录映射4202380治理目标不是「少写文件」

，而是让文件、快照与元数据始终处于可控状态无需客户侧常驻维护任务存储内核级优化湖

·后台维护Small

FileStorm四重放大元数据先筛文件，查询才能少扫数据Table

Bucket后台自运维小文件：实时写入的长期成本940189引擎一

·

Kafka原生入湖（OSSTable

Bucket）引擎二

·流计算SQL入湖（DLF

2.0）湖

·落地形态共享元数据底座

，

独立执行链路产品定位产品定位处理链路处理链路SQL示例产品集成

·统一入口统一入口

·AUTOCU弹性产品入口统一开发、部署与观测；数据面以独立SQL任务运行，故障不进入

Broker热路径实时SQL处理闭环数据入口·

流式表

与

数据面职责清晰任务级观测边界约束算

·产品内

SQLSQL能力实时输出列式扫描

·

向量化读（回放/湖表）列式批量解码计算层

·行式Code

GenerationSQL→物理计划→

代码生成算

·SQL

执行引擎组合拳的性价比二进制行格式

BinaryRowDataColumnarRowData零拷贝代理缓存友好

+谓词下推流式优先的权衡状态平面｜把容量从本地内存解耦资源效率｜让算力随负载变化前两层降低单机处理成本；状态与资源层决定容量、弹性与恢复上限｜微基准结果，非端到端SLA已验证收益

×下一阶段工程化｜JVM/

内存·数据/执行·状态平面·资源效率算

·性能演进数据/执行｜放大批量处理收益JVM/内存｜降低固定开销0304010201TABL