最近实践｜如何批量获取数据集更新 URL，并在页面中直接触发更新
适用产品：观远 BI
适用版本：7.1 以上
简介：
在日常数据运维和业务自助排障场景里，经常会遇到一个很实际的问题：哪些数据集支持通过 URL 触发更新？这些数据集分别由谁创建，最近一次更新时间是什么时候？
如果完全依赖人工逐个点开数据集查看配置，不仅效率较低，也不方便给业务提供统一入口。本次实践基于元数据库中的 data_source 表，提取支持 URL 触发更新的数据集信息，再补充创建者和最近更新时间，最终输出一张“数据集更新地址汇总表”，并通过仪表板页面统一展示。业务在页面中点击“触发更新”后，即可直接调用对应数据集的更新地址。
最终效果是：页面中可以统一查看 数据集名称、创建者、最近更新时间、更新URL、数据集ID，并按数据集名称排序展示，适合数据运维、业务排障和批量更新入口沉淀等场景。
涉及数据集：
本次方案使用 2 个输入数据集和 1 个 ETL 输出数据集。
1、元数据输入数据集
元数据库只读账号的获取方式，可直接参考帮助中心文档：
本次实践中，输入数据集直接读取元数据库原表，不在输入数据集层做加工，后续逻辑统一放在 ETL 中处理。
元数据_data_source_新建_20260326_1841：来源于元数据库 data_source 表，用于提取数据集名称、创建人、最近更新时间、tokenSetting、数据源类型等信息dim_user：用于补充创建者名称
2、ETL 输出数据集
ETL 输出的是一张用于页面展示的宽表，保留字段为 数据集名称、创建者、最近更新时间、更新URL、数据集ID。
本次输出数据集名称：数据集更新URL汇总_输出_20260402
数据处理：
1、数据来源说明
这次方案的核心思路是：先从 data_source 元数据中筛出已勾选 URL 触发更新的数据集，再从 config 中提取 tokenSetting.value 和最近执行时间，按固定规则拼出 public-api 更新地址，最后关联用户维度补充创建者名称。
这里默认遵循两个处理口径：若元数据表存在 is_del 字段，则默认加 is_del = 0；用户维度补充时加 is_del = 0。
2、新建 ETL 并引入输入数据集
本次 ETL 采用“输入数据集 -> SQL 节点 -> 输出数据集”的标准链路，所有字段加工都集中在 SQL 节点中完成。
- ETL 名称：
数据集更新URL汇总_ETL_20260402
- ETL ID：
gb29dc88c07d84e758b02f2d
3、解析更新地址并补充创建者、更新时间
本次 SQL 节点主要做了四件事：
- 从
data_source.config 中提取 sourceType、tokenSetting、lastExecution.endTime
- 只保留已勾选 URL 触发更新且支持 URL 刷新的数据源类型
- 使用
tokenSetting.value 拼接出最终可访问的更新地址
- 关联
dim_user 补充创建者名称
本次实际使用的 SQL 如下，已在 ETL 中添加注释：
-- 目标：汇总当前 testing 域可通过 URL 触发更新的数据集。
-- 说明：
-- 1. 元数据来自 data_source，过滤 is_del = 0，只保留未删除数据。
-- 2. 创建者信息来自 dim_user，并补充 is_del = 0 过滤，避免命中已删除用户。
-- 3. 更新 URL 使用 public-api refresh 接口拼接，只保留已勾选 URL 触发的数据集。
SELECT
input1.ds_id AS `数据集ID`,
input1.name AS `数据集名称`,
coalesce(input2.name, input1.u_id) AS `创建者`,
coalesce(
get_json_object(input1.config, '$.lastExecution.endTime'),
cast(input1.utime AS STRING)
) AS `最近更新时间`,
concat(
'https://uat.guandata.com/bi-test/public-api/data-source/',
input1.ds_id,
'/refresh?token=',
get_json_object(input1.config, '$.tokenSetting.value')
) AS `更新URL`
FROM input1
LEFT JOIN input2
ON input1.u_id = input2.u_id
AND input2.is_del = 0
WHERE input1.is_del = 0
AND input1.dom_id = 'testing'
AND input1.name IS NOT NULL
AND trim(input1.name) <> ''
AND get_json_object(input1.config, '$.sourceType') IN (
'DIRECT_CONNECT_DATABASE',
'GUAN_INDEX',
'UNIVERSE',
'WEB_SERVICE',
'OAUTH_CONNECT',
'DIRECT_SERVER_FILE'
)
AND get_json_object(input1.config, '$.tokenSetting.enabled') = 'true'
AND get_json_object(input1.config, '$.tokenSetting.value') IS NOT NULL
AND trim(get_json_object(input1.config, '$.tokenSetting.value')) <> ''
关键说明：
tokenSetting.enabled = true 是是否勾选 URL 触发更新的关键判断- 更新地址统一按
https://uat.guandata.com/bi-test/public-api/data-source/{dsId}/refresh?token={token} 规则拼接，其中 token 取自 tokenSetting.value
- 最近更新时间优先取
lastExecution.endTime，若为空则回退到元数据 utime
- 本次只保留支持 URL 刷新的数据源类型，避免把不支持的对象误放入页面
4、输出结果宽表
ETL 输出后的字段结构如下：
数据集名称：可触发更新的数据集名称创建者：数据集创建者最近更新时间：最近一次执行结束时间，若无则回退为元数据更新时间更新URL：页面中用于触发更新的地址数据集ID：数据集唯一标识
输出数据集预览结果如下：
5、ETL 逻辑导出附件
这里可以点击下载 ETL 的 zip 文件，在 ETL 里导入即可。文件名：数据集更新URL汇总_ETL_20260402.zip
看板搭建：
1、新建汇总卡片并完成配置
基于 ETL 输出数据集，新建一个普通表格卡片，并将 数据集名称、创建者、最近更新时间、更新URL、数据集ID 放入表格中，同时对 数据集名称 设置升序排序。
- 页面名称：
数据集更新URL汇总Demo页面_20260402
- 页面 ID：
x033c8fa8c6af23f19628b01
- 卡片 ID：
m6dbb7737d7748ab1acea5e8
2、将更新地址配置为可点击链接
为了让业务在页面中直接触发更新，本次将 更新URL 字段配置为“显示为链接”，并将展示文案统一设置为 触发更新。
回读校验时，页面内已成功解析出真实的 public-api/data-source/.../refresh 链接，说明页面中展示的“触发更新”已渲染为真实可点击地址。
3、最终发布效果
最终页面支持汇总查看当前支持 URL 触发更新的数据集，显示数据集名称、创建者、最近更新时间、数据集 ID，并通过 触发更新 链接直接打开对应更新地址，结果按 数据集名称 升序展示。
实践结果：
通过这次实践，我们沉淀出了一套可复用的“数据集更新 URL 汇总”方案：
- 用元数据库统一识别哪些数据集支持 URL 触发更新
- 在 ETL 中集中完成 token 提取、更新时间回填和 URL 拼接
- 通过页面统一沉淀业务可见的更新入口
- 将零散的数据集刷新动作，收口为一个可复用的运维页面
这套方案尤其适合批量更新入口沉淀、业务侧自助触发刷新、数据运维排障和数据集更新时间巡检等场景。
总结：
这次实践把“批量获取数据集更新 URL，并在页面中直接触发更新”整理成了一套可长期复用的链路：输入层保持元数据原样接入，ETL 层集中完成 URL 生成与字段补充，页面层统一展示点击入口，最终把原本分散的数据集刷新动作沉淀成一个业务可直接使用的汇总页面。
如果后续继续扩展，这套方案还可以自然演进到两个方向：一是增加目录、数据源类型、执行状态等治理维度，形成更完整的数据集运维看板；二是结合权限与审计记录，进一步沉淀触发更新的使用追踪能力。 | 
