核心概念
数据血缘
描述数据对象之间来源、加工和消费关系的依赖信息。表级关系帮助定位链路中的直接和传递关系。
沿统一的银行存款余额链路,先确认这份数据的直接来源、加工位置和消费去向。
描述数据对象之间来源、加工和消费关系的依赖信息。表级关系帮助定位链路中的直接和传递关系。
先读一条统一的银行存款余额链路:AccountBalanceSnapshot 等输入经过 dwd_account_balance_detail,汇总到 dws_deposit_balance_daily,再发布到 ads_deposit_balance,最后被存款余额指标消费。点击对象,比较直接上游、传递上游和下游影响。
先观察调度配置明确等待的任务,再展开 V_CUSTOMER 的 SQL 来源。这个样例把两个观察范围并列展示,不把 View 当成调度任务,也不把简化路径当成完整 DAG。
先只看五个对象。点击节点,比较它的直接关系和隔着中间层的传递关系。
“谁先跑”描述运行依赖;“数据从哪里来”描述数据依赖。两个关系可能方向相同,但回答的不是同一个问题。
task_dwd_balancetask_dws_balancedwd_account_balance_detaildws_deposit_balance_daily数据库 View 是正常的查询抽象。下面用一个教学样例分别观察显式调度依赖和 SQL 实际读取;图中不对 View 性能作结论。
这条简图把任务、View 和消费结果放在一起帮助定位;它不是一张统一的调度 DAG,也不能说明 SQL 的完整读取来源。
CustomerAccount这是可观察的配置差异,不表示 SQL 没有读取它们;是否要配置额外调度依赖,应按任务时序和就绪保障判断。
V_CUSTOMER 的 SQL 上游已折叠(2 个来源)。
SQL lineage 回答“查询读取了什么”;Scheduler dependency 回答“运行要等待什么”。View 可以合理存在,排障与影响分析时仍应核对底层 SQL 来源和运行依赖。