数据血缘

场景　"这张表的数据到底是哪来的、删了会不会搞坏别的东西"——这是排查数据问题时最常被问到、出了事故又最难临时补的一类问题。数据血缘让"数据从哪来、被谁依赖"变成平台自动维护的既成事实,而不是靠文档和口口相传。

能干什么

你想做的事	配置成数据血缘长这样(示意)
想知道一张表的数据到底是从哪算出来的、有没有下游在用它	打开该表的「血缘」,看上下游的表级/列级关系图,不需要额外配置,作业跑过就有
删表删库前想确认会不会影响别的作业	平台自动检查血缘引用,还有存活作业依赖就直接拦下删除并提示原因,不用自己一个个排查

亮点

血缘是平台自动记的,不用手工登记——数据同步、SQL 作业这类会真正产出数据的作业,一旦上线跑过,平台就自动记下"这张表的数据来自哪张源表、哪个字段对应哪个字段",不需要额外画图或补文档,过程中也不会漏记。
血缘同时是删表删库前的一张安全网——一张表如果还被某个存活的作业依赖(血缘链上有它),删除会被直接拦下并提示原因,不用等到下游作业跑挂了才发现是谁删错了表。

ods_orders_from_mysql 这张表由一个离线集成(数据同步)作业产出,源表是 mysql_10_biz_source.demo_source.orders,按字段一一映射写入。这个作业一旦上线运行,平台自动记下每个字段的来源,不需要额外配置血缘、也不用手工登记:

数据血缘图(列级):mysql_10_biz_source.demo_source.orders 的 id/user_id/amount/status/create_time 五个字段,逐列映射到 ods_orders_from_mysql 的同名字段

mysql_10_biz_source.demo_source.orders 仍然被上面这个存活作业的血缘引用着,这时候如果想把它从平台移除,会被直接拦下,而不是悄悄放行:

text

表仍被作业引用（数据血缘），不能删除；请先调整或删除相关作业

尝试移除仍被作业血缘引用的源表,平台直接拦下并给出原因

想看这张表在哪、归谁管、怎么导入和授权,看元数据管理;想了解空间隔离与权限体系的整体设计,看生产级安全与多租户隔离。