最近实践｜如何快速查询 BI 中某张物理表被哪些数据集引用
适用产品：观远 BI
适用版本：6.6 以上
简介：
在数据库治理场景里，经常需要快速回答一个问题：某张物理表当前在 BI 中还被哪些数据集引用。如果完全依赖人工逐个翻查数据集，效率较低，也不方便持续排查。
这次实践基于元数据库中的 data_source 表，先提取数据集模型中的查询 SQL，再从 SQL 中解析出物理表名，最终生成一张“物理表 - 数据集”映射表，并搭建一个支持输入表名快速检索的页面。
最终效果是：输入表名，即可查看当前 BI 中命中的数据集名称，适合数据库表下线评估、资源盘点和数据集治理排查。
涉及数据集：
本次方案使用 1 个元数据输入数据集和 1 个 ETL 输出数据集。
1、元数据输入数据集
元数据库只读账号的获取方式，可直接参考帮助中心文档：
本文中使用该元数据库账号连接 UAT 环境，并读取 data_source 表，核心保留字段如下：
name：BI 中的数据集名称config：数据集模型配置 JSONds_id：数据集 ID
本次实践对象：
- 数据集名称：
元数据_data_source_新建_20260326_1841
- 查询 SQL：
select * from data_source
2、ETL 输出数据集
ETL 将输入数据集中的 config 字段解析后，输出为便于查询和展示的宽表。
- 输出数据集名称：
元数据_物理表数据集映射_输出_20260330_1015
- 输出字段：
表名、数据集名称、数据集ID、模型查询SQL
数据处理：
1、元数据来源说明
元数据库账号来源不在 ETL 中单独配置，而是先按帮助中心中的 GuanOps 说明获取元数据库只读账号，再新建一个输入数据集读取 data_source 表。这样做的好处是：
- 输入来源清晰，便于后续复用
- ETL 只关注加工逻辑，不直接承担连库配置
- 后续如果需要替换账号或环境，只需要调整输入数据集
2、新建 ETL 并引入输入数据集
本次 ETL 采用“输入数据集 -> SQL 节点 -> 输出数据集”的标准链路，输入节点直接引入 元数据_data_source_新建_20260326_1841。
3、提取模型查询 SQL 并解析物理表名
data_source.config 中保存了数据集模型结构，本次从 $.tableQuery.query 路径提取查询 SQL，再通过正则抓取 from 或 join 后面的首个物理表名。
本次 ETL 中保留的 SQL 注释如下，可直接作为导出逻辑给用户复用：
-- 从元数据 data_source 中提取模型查询 SQL，并解析 FROM/JOIN 后的物理表名
SELECT
regexp_extract(lower(get_json_object(config, '$.tableQuery.query')), '(?:from|join)\s+([a-z0-9_\.]+)', 1) AS `表名`,
name AS `数据集名称`,
ds_id AS `数据集ID`,
get_json_object(config, '$.tableQuery.query') AS `模型查询SQL`
FROM input1
WHERE config IS NOT NULL
AND trim(config) <> ''
AND get_json_object(config, '$.tableQuery.query') IS NOT NULL
AND trim(get_json_object(config, '$.tableQuery.query')) <> ''
说明：
get_json_object(config, '$.tableQuery.query') 用于从模型结构里提取查询 SQLregexp_extract(...) 用于抽取 from/join 后的首个物理表名- 当前逻辑以“快速定位引用关系”为目标，因此只取首个命中表名
4、输出结果宽表
处理完成后，ETL 输出的数据字段如下：
表名：从模型查询 SQL 中解析出的物理表名数据集名称：BI 中实际数据集名称数据集ID：用于进一步定位数据集模型查询SQL：用于回查原始模型逻辑
本次 ETL：
- ETL 名称：
元数据_data_source提取_ETL_修正_20260330
5、ETL 结果示意
ETL 最终产出了一张“物理表 - 数据集”映射表，该输出数据集可直接作为页面查询的数据源。
6、ETL 逻辑导出附件
这里可以点击下载 ETL 的 zip 文件，在 ETL 里导入即可。文件名：元数据_data_source提取_ETL_修正_20260330.zip
看板搭建：
1、新建卡片并完成配置
基于 ETL 输出数据集，新建一个普通表格卡片，放入字段 表名 与 数据集名称。在卡片配置完成后，再为 表名 增加升序排序，方便用户浏览结果。
- 页面名称：
元数据映射Demo页面_20260326_124633
字段放置完成后的卡片配置如下：
排序保存后的效果如下：
2、创建筛选器并完成联动
为了支持用户直接输入表名检索，在页面顶部新增输入型筛选器，筛选字段绑定为 表名，并将该筛选器联动到目标表格卡片。
筛选器属性配置示意：
筛选器联动关系配置示意：
3、发布效果说明
最终页面支持：
- 输入表名进行模糊查询
- 卡片中同时展示
表名 与 数据集名称
- 结果按
表名 排序显示
这里也补充一个实践结论：页面尺寸或卡片宽度的拖拽调整，在最终发布页中的改善并不稳定，通常还会继续受到响应式布局、浏览器窗口宽度和表格自身渲染方式影响，因此不建议把“页面大小调整”作为关键步骤。真正有效的步骤仍然是卡片字段配置、表名排序、筛选器创建和筛选器联动。
实践结果：
通过这次实践，我们得到了一套可直接复用的“元数据查表引用”方案：
- 使用元数据库
data_source 作为统一入口
- 在 ETL 中提取模型 SQL，并解析物理表名
- 输出标准映射表，沉淀为可复用数据集
- 通过页面筛选器支持用户输入表名快速查询
- 在卡片中同步展示
表名 与 数据集名称
这套方案尤其适合以下场景：
- 数据库表下线前确认影响范围
- BI 资源盘点
- 数据集治理与冗余排查
- 运维或数据团队快速定位“哪张表被谁在用”
总结：
这次实践把“查询某张物理表被哪些 BI 数据集引用”整理成了一套可长期复用的链路：先获取元数据库账号并建立输入数据集，再通过 ETL 统一提取模型 SQL、解析物理表名，最后用一个轻量页面把查询入口交给使用方。
如果后续还要继续扩展，这套方案还可以自然演进到两个方向：
- 扩展 SQL 解析规则，覆盖多表模型
- 继续补充页面、目录、负责人等字段，形成更完整的引用治理看板
| 
