GIDO Batch feature map: Studio, DAG, scheduling, quality, lineage
Batch reliability is less about writing SQL and more about orchestration, instances, alerts, and governance.
系列：《Cloud GIDO 三产品特性深讲》第 4/15 篇
标签：GIDO Batch、数据开发、工作流、调度、数据质量
开篇：批处理真正难的不是「写出 SQL」
离线数仓团队都写过 SQL。真正拖垮团队的是：
- 脚本版本混乱，线上跑的是谁改的不知道
- DAG 靠口头约定，依赖挂了整链沉默失败
- 调度在 A 系统，日志在 B 系统，告警在群里靠人喊
- 「数据质量」停留在口头，没有规则与执行入口
GIDO Batch 的特性，就是围绕 开发 → 编排 → 发布 → 调度 → 运维 → 治理 把这些能力产品化。
特性 1：数据开发 Studio
是什么： SQL 编辑、运行、看结果的工作台。
解决什么： 把「本地客户端 + 临时脚本」收束到统一入口。
关键点： 与数据源权限、工作空间隔离联动；结果可回看，便于联调。
注意： Studio 解决开发体验，不等于已经具备生产调度闭环。
特性 2：工作流 DAG
是什么： 可视化编排节点依赖，支持草稿 / 上线 / 暂停 / 下线。
解决什么： 依赖从「约定」变成「可执行拓扑」。
关键点： 生命周期完整，才能支撑多人协作与回滚。
注意： DAG 上线后，仍需调度系统真正触发实例。
特性 3：调度与实例中心
是什么： 面向运营的实例视图（GIDO 实例中心）。
解决什么： 回答「今天哪些任务跑了、失败了、能否重跑」。
关键点： 批处理运营的主界面往往在这里，而不是编辑器。
边界： 完整调度常依赖外置调度引擎（如 DolphinScheduler）的有效集成；K8s 最小栈场景要单独验收。
特性 4：运维中心
是什么： 工作流 / 节点两层运维：停止、重试、日志。
解决什么： 故障时有统一操作面，减少 SSH 现场抢救。
关键点： 「看得到日志 + 做得了动作」比只展示状态更重要。
特性 5：告警中心
是什么： 面向任务失败/异常的通知通道（邮件、Webhook、飞书、企微等）。
解决什么： 把故障从「第二天晨会才知道」变成「分钟级感知」。
注意： 平台告警与调度引擎自带 Alert 插件可能是两套概念，集成时要分清责任。
特性 6：数据集成
是什么： 多源同步能力。
解决什么： 减少大量一次性导数脚本。
边界： 增量若是轮询型 CDC，不要按 Debezium/Flink CDC 一体化预期去验收；按你们的时效要求做 PoC。
特性 7：数据探查
是什么： 采样与基础统计。
解决什么： 开发前先「看见数据」，降低写错 SQL 的概率。
搭配： 常与 Studio、数据源管理一起用。
特性 8：数据质量
是什么： 质量规则与执行入口。
解决什么： 把质量从口头变流程。
边界： 执行层可能对某些 JDBC 协议更友好；跨源要对着真实引擎测。
特性 9：数据地图与血缘
是什么： 字典 + 基于 SQL 的血缘解析。
解决什么： 变更影响分析有入口。
边界： SQL 正则血缘对复杂动态 SQL 可能不全——这是已知限制，评估时用复杂脚本压一下。
特性 10：发布审批 + 数据源 + RBAC
这三项看起来「不像 Batch 功能」，却决定 Batch 能不能多人生产：
- 审批：防止未审变更直冲生产
- 数据源：连接与凭证受控
- RBAC / 空间：谁能写、谁能发、谁只能读
一张 Batch 特性验收清单（可直接用）
- Studio 能在目标数据源跑通并出结果
- DAG 生命周期（草稿→上线→暂停→下线）可演示
- 实例中心能看到成功/失败与日志
- 失败可重试/停止（按权限）
- 告警能打到你们现网通道
- 至少一条集成任务符合时效预期
- 质量规则能跑在目标库类型上
- 血缘对你们典型 SQL 是否够用
- 审批 + RBAC 符合组织角色
今日小结
Batch 的「特性完整」= 编辑器漂亮，更是 编排 + 调度实例 + 运维告警 + 治理 齐套。
讲 GIDO Batch，请按这条链讲，听众才听得懂专业度。
讨论： 你们现在批处理最大的洞，是调度实例看不见，还是质量/血缘几乎没有？
下篇：GIDO Stream 特性拆解。
延伸