阿里妹导读
文章内容基于作者个人技术实践与独立思考，旨在分享经验，仅代表个人观点。
一、背景：实时数据开发为何“重”
直播业务涵盖大促分析、实时大屏、榜单及主链路策略调控等大量实时场景。相较于离线开发仅需关注业务逻辑，实时开发还需应对窗口设计、双流关联、状态管理及乱序处理等流式特性，导致门槛高、纠错成本大。
核心痛点在于：能否通过产品化抽象隔离流式复杂性，让开发回归业务逻辑本身？我们的答案是构建一套AI 辅助、指标驱动的实时数据端到端开发系统。其核心理念是将业务逻辑抽象为“维度 + 指标”，以指标计算过程支撑数据任务骨架。
二、最佳应用案例
以下通过一个典型实时特征需求，展示从自然语言描述到 Flink SQL 任务发布的完整链路。
2.1 需求描述
需求澄清：用户输入自然语言，系统自动召回指标并识别窗口逻辑。
需求确认：用户确认指标、维度及窗口无误后，系统自动生成 DSL。
(上图红框为用户输入，其余为系统生成)
轻量的需求描述得益于指标驱动架构，本质是将自然语言需求转化为结构化技术需求。
2.2 DSL 确认
DSL 是前端、AI 与后端的共识契约。用户浏览确认 DSL（无需强校验，便于排查），系统随即生成 SQL。
(系统生成 DSL)
2.3 SQL 生成
系统基于 DSL 协议工程化生成 SQL，确保 100% 准确。
(系统生成 SQL)
若 SQL 满足需求，可一键发布至 Dataphin；若需调整，则进入增量分析环节。
2.4 增量调整（可选）
针对局部调整（如增加过滤条件），用户可用自然语言描述，系统通过 Hook 协议增量更新链路并重新生成 SQL。
满足需求：直接发布。
需调整：描述调整点，系统融合增量 DSL 协议生成终版 SQL。
本例中，用户补充了筛选、格式转换及兜底处理三个需求，大模型将其转化为增量 DSL 协议（Hook 结构体）与初版融合。
(上图红框为用户输入，其余为系统生成)
2.5 任务发布
系统自动生成包含 Topic 订阅及资源配置的 Flink SQL 脚本，支持一键发布至 Dataphin 平台。
（实时任务脚本）
（任务一键发布到 Dataphin 平台）
2.6 小结
全流程用户手动输入少于 200 字符。人机协作模式下（人决策、AI 执行），开发周期从天级缩短至分钟级，显著提升效率。
三、链路的构建与演进
本章深入系统内部，解析指标驱动引擎如何自动构建初版链路（3.1–3.3）及实现增量演进（3.4）。
3.1 引擎的两个核心动作
依赖回溯建骨架：从目标指标出发，依据依赖关系自主回溯过程指标，自动构建 DAG 拓扑。用户只需声明“要什么”，无需编写“怎么算”。
维度双路填充：过程维度通过与指标关联补全；输出维度从结果向上回溯至源。二者分治，互不干扰。
3.2 链路分层与指标回溯图
下图为引擎回溯生成的完整链路拓扑：
引擎基于指标依赖动态生成任务拓扑，而非使用预置模板。Source 来源、中间视图职责及 Target 汇合方式均由目标指标的计算依赖、窗口语义及聚合需求共同决定。
本例中，引擎将链路动态拆解为清晰的六层结构，每层职责单一：
视图层 |
核心职责 |
加工性质 |
物理源表 |
原始日志接入 + 过滤 |
数据入口 |
源字段派生层（source） |
行级表达式派生 |
无状态映射 |
窗口聚合层（tmp_view_001） |
HOP 窗口 + GROUP BY 聚合 |
有状态聚合 |
封顶加工层（tmp_view_002） |
阈值封顶 + 直通透传 |
后聚合修正 |
维表关联层（tmp_view_003） |
LOOKUP 维表 + 条件复合 |
跨源汇合 |
产出层（target） |
类型转换 |
输出适配 |
该分层机制使引擎能根据指标复杂度动态组织链路：简单指标直通，窗口类指标生成中间层，跨源复合指标扩展多支路。
3.3 链路解读
案例体现四大关键机制：
直通型 vs 复合型：基础指标层层直通；复合指标通过多数据源与维表汇合，展现多级派生能力。
扇出复用：一次聚合，多路消费，避免重复计算。
维表旁路增强：维表仅在特定节点横向注入，作为旁路增强而非主链路加工。
全链路血缘：任意产出指标均可单向回溯至物理源表与原始字段，路径清晰可审计。
xxx_time_10wmr_cap_xxx ├─ xxx_time ← dwd_{source a}.xxx_time ├─ xxx_pv ← dwd_{source b}_di.type └─ xxx_level ← ldm_xxx_info（维表）
3.4 链路的增量演进：Hook 机制
初版链路生成后，系统支持在不改变逻辑拓扑的前提下进行局部调整。
交互与架构设计
体验优先：在生成 SQL 后让用户参照结构描述调整点（如“在 tmp_view_xxx 中增加过滤”），比初始描述更精准。
职责分离：初始需求聚焦高复用核心资产；增量需求解决个性化、一次性调整，不具备跨任务复用价值。
适用场景
精炼口径：增加筛选过滤。
维度调整：格式转换或兜底处理。
输出冗余：增加监控调试字段。
结构化协议：Hook
设计“增量补丁”协议 Hook，AI 仅输出结构化修改指令，由后端引擎执行校验。为降低幻觉，输入上下文严格限制为“初版 DSL + Hook 增量协议”。
{
"hooks": [
{
"hookType": "FILTER | DIMENSION_TRANSFORM",
"layerType": "SOURCE | VIEW | TARGET",
"nodeId": "source_001 | tmp_view_001 | target_001",
"mergeStrategy": "REPLACE | APPEND_AND | APPEND_OR",
"filterExpression": "仅 FILTER 类型时填写",
"dimensionName": "仅 DIMENSION_TRANSFORM 类型时填写",
"expression": "仅 DIMENSION_TRANSFORM 类型时填写",
"reason": "简要说明为什么这样做"
}
]
}安全围栏校验（双保险）
前校验：检查 Hook 结构体合法性。
后校验：验证更新后 DSL 的拓扑逻辑自洽性。
四、方法论
以下是系统设计的五大核心原则：
4.1 指标驱动作为核心范式
数据链路逻辑可归约为“维度 + 指标”，指标依赖构成 DAG。以目标指标驱动，系统自动回溯计算拓扑。这将“写 SQL"转化为“声明指标”，封装流式复杂度，确立声明式开发范式。
4.2「理解」与「正确性」的分离架构
LLM 负责“理解”（自然语言转结构化意图），确定性代码负责“正确性”（执行 + 校验）。AI 幻觉被限制在理解层，无法污染最终产物。此架构适用于所有 LLM 落地生产场景。
4.3 DSL 作为多系统协同的“万能合约”
DSL 兼具存储、传输与校验三重角色，对齐前端、AI 与后端语义。设计兼顾人可读（贴近业务）、AI 可生成（结构规整）与机器可执行（依赖显式）。
4.4 Hook 协议——LLM 安全接入确定性系统的工程范式
让 LLM 输出“增量操作指令”（Hook）而非直接修改复杂 DSL，是可控的关键。Hook 包含操作类型、定位节点与合并策略，配合前后双重校验，消除不确定性，确保终版 SQL 可信。
4.5 实时资产沉淀路径
针对实时数仓 DWS 层复用难的特性，通过指标驱动方式将散落的指标显式化、标准化，做厚“指标资产”层，形成“用得越多、沉淀越厚、复用越易”的正循环。
五、未来规划
全链路能力 Skill 化：增强安全校验，弱化人工干预，适配对话式交互。
Agent 驱动资产复用：自动化需求分析与配置，替代手动录入。
任务迭代与版本管控：支持已有任务的版本管理。
Hook 类型扩展：支持改变拓扑结构的复杂需求（如多路输出）。
依赖指标的维度支持：解决维度生成逻辑依赖过程指标的特殊场景。