| 一、问题背景 在客户排查离线任务或数据链路问题时，一个高频问题是： - 这个输出数据集是谁产出的？ - 对应的是哪个数据流？ - 数据流里具体是哪个输出节点在写这个数据集？ 如果只靠页面逐层点开查看，效率较低。本文给出一套可直接落地的元数据库查询方案，帮助快速完成定位。 二、这份方案解决了什么 这套查询方案主要解决 3 件事： 1. 通过输出数据集 `dsId` 反查对应的数据流定义。 2. 定位到该数据流里的输出节点（`node_id`）并解析节点名称。 3. 给出标准回复口径，便于支持、实施、研发统一对外说明。 三、核心思路 离线开发元库有 `t_ds_process_definition_lineage` 表，输出数据集对应记录满足 `resource_type = 1`、`relation_type = 2`、`resource_id = 输出数据集 dsId`。该记录中的 `data_flow_definition_id` 是数据流定义 ID，`node_id` 是数据流内部输出节点 ID。再关联 `t_ds_process_definition` 并解析数据流 `process_definition_json -> actions`，用 `node_id` 匹配 action 的 `id`，即可得到输出节点名称（如“库存数据”）。 核心依赖表： - `t_ds_process_definition_lineage` 这是离线开发元数据库中的血缘关系表，记录了工作流/数据流与资源之间的输入输出关系。 对“输出数据集 -> 数据流”的定位，关键过滤条件是： - `resource_type = 1`（资源是数据集） - `relation_type = 2`（关系是输出） - `resource_id = 输出数据集 dsId` - `data_flow_definition_id is not null` 查到后： - `data_flow_definition_id` 就是产出该数据集的数据流定义 ID。 - `node_id` 是该数据流内部输出节点 ID。 四、推荐查询 SQL（可直接复用） ```sql select p.name as workflow_name, df.process_definition_id as dataflow_id, df.name as dataflow_name, l.resource_id as output_ds_id, l.node_id as output_node_id, action_item.action ->> 'name' as output_node_name, action_item.action ->> 'type' as output_node_type from t_ds_process_definition_lineage l join t_ds_process_definition p on p.process_definition_id = l.process_definition_id join t_ds_process_definition df on df.process_definition_id = l.data_flow_definition_id left join lateral jsonb_array_elements(df.process_definition_json::jsonb -> 'actions') action_item(action) on action_item.action ->> 'id' = l.node_id where l.resource_type = 1 and l.relation_type = 2 and l.resource_id = '<输出数据集dsId>' and l.data_flow_definition_id is not null and p.is_del = false and df.is_del = false; ``` 查询结果重点关注： - `dataflow_id` / `dataflow_name`：产出该数据集的数据流 - `output_node_id`：输出节点 ID - `output_node_name`：输出节点名称（例如“库存数据”） - `output_node_type`：通常为 `OUTPUT_DATASET` 或 `INCREMENT_OUTPUT_DATASET` 上面的SQL在pg workflow库里执行 五、只有数据集名称时怎么查 很多现场场景里，客户只知道数据集名称（比如 `ads_pdtqty`），不知道 `dsId`。 可以先到 BI 后端元库查 `dsId`： ```sql select ds_id, name from data_source where name = 'ads_pdtqty' and is_del = 0; ``` 拿到 `ds_id` 后，再回到离线开发元库执行上一节 SQL。 六、能力边界与常见误区 1. 这张血缘表能直接回答什么？ 可以直接回答： - 某数据流用了哪些输入数据集（`relation_type = 1`） - 某数据流产出了哪些输出数据集（`relation_type = 2`） - 某输出数据集对应哪个数据流和哪个输出节点 2. 不能直接回答什么？ ` t_ds_process_definition_lineage ` 不是“输入 A -> 输出 B”的节点级边表。 如果要精确追溯“某个输出节点究竟由哪几个输入节点加工而来”，需要继续解析： - `t_ds_process_definition.process_definition_json -> actions` 并结合 action 的： - `id` - `sources` - `type` - `name` 做节点链路追踪。 七、总结 这套方法的价值在于： - 查询路径短，定位效率高 - 可作为“输出数据集溯源”的标准排查步骤沉淀 如果后续需要做到“输入节点到输出节点”的全链路可视化，再基于 `process_definition_json.actions` 做二次解析即可。 |
