最近实践｜如何查询最近30天未访问的仪表板，并追溯其数据集与源表
适用产品：观远 BI
适用版本：6.6 以上
简介：
在页面治理场景里，常见需求不是只看“最近 n 天哪些仪表板没人访问”，而是要继续追下去：这些页面当前关联了哪些数据集、用的是哪个元数据库账号、最终落到了哪张源表。
如果完全依赖人工逐个打开页面、卡片和数据集排查，效率较低，也不方便持续治理。这次实践基于 BI 元数据库中的 page、card、data_source、account 表，以及 audit_log 行为日志，先识别最近 30 天未访问的页面，再补出页面到数据集、账号、源表的治理链路，最终生成一张可直接落地使用的治理明细表。
最终效果是：直接查看“长期未访问仪表板治理明细”表格，即可同时看到页面名称、最近访问距今天数、页面卡片数、页面关联数据集、账号名称、连接器类型和推断源表，适合仪表板清理、资源盘点和数据治理排查。
涉及资源：
本次方案使用 5 个输入数据集、1 个 ETL 输出数据集和 1 个治理页面。
1、输入数据集
- 页面访问日志数据集：
codex_page_open_audit_20260420（x219a551277574c3a96407da）
- 页面元数据数据集：
codex_meta_page_20260420（g368016a9d01a47a98d304f9）
- 卡片元数据数据集：
card（h17c85d35cc2441719ba9e98）
- 数据集元数据数据集：
codex_meta_data_source_20260420（c225967e7bed743fcb008161）
- 账号元数据数据集：
codex_meta_account_20260420（se53dcebdecc04b58b52aead）
2、ETL 输出数据集
- 输出数据集名称：
Codex_长期未访问仪表板治理明细_20260420_v2
- 输出数据集 ID：
t54de1579aacd49fe803a20b
- 输出字段示例：
页面名称、最近访问距今天数、30天未访问标记、页面卡片数、页面数据集数、数据集名称、账号名称、连接器类型、推断源表
3、ETL 与页面
- ETL：
Codex_长期未访问仪表板治理ETL_20260420_v2（kbdcdf4352d5e4c4092897cc）
- 页面：
Codex_长期未访问仪表板治理看板_20260420_v2（n5694412456cc71fc10ead32）
数据来源：
1、元数据库账号来源
元数据库账号获取方式可参考帮助中心中的 GuanOps 文档。本文不在 ETL 内直接配置连库信息，而是先建立元数据输入数据集，再把加工逻辑集中放到 ETL 中。这样做有三个好处：
- 输入来源清晰，便于后续复用
- ETL 只承担加工职责，不混入账号配置
- 环境切换时只需要替换输入数据集
2、输入数据集创建 SQL
这次方案不再依赖 user_behavior_analysis 或其他内建链路，而是直接从元数据库与行为日志里取数。对应 SQL 如下：
-- 长期未访问仪表板治理场景：输入数据集建表 SQL
-- 元数据库账号请先按 GuanOps 文档申请只读账号，再在 BI 中创建对应数据集。
-- 1. 页面访问日志：从 audit_log 中提取页面打开行为
select
dom_id,
user_id,
user_name,
obj_id as pg_id,
obj_name as page_name,
event_time as visit_time,
path,
category,
event_category,
resource_type
from audit_log
where path regexp '^/page/[^/]+$'
and event_category = 'Page';
-- 2. 页面元数据
select * from `page`;
-- 3. 卡片元数据
select * from `card`;
-- 4. 数据集元数据
select * from `data_source`;
-- 5. 账号元数据
select * from `account`;
如果当前环境里已经有现成的 card 元数据数据集，也可以直接复用；如果没有，则按上面的方式从 card 表新建一个抽取数据集即可。
数据处理：
1、ETL 整体链路
本次 ETL 采用“5 个输入数据集 -> 1 个 SQL 节点 -> 1 个输出数据集”的标准链路。SQL 节点统一完成最近访问时间计算、页面与卡片关系拼接、数据集与账号信息追溯，以及源表名称推断。
2、识别最近 30 天未访问页面
访问判断直接基于 audit_log 中的页面访问行为。先按 pg_id 聚合出每个页面的最近访问时间，再计算 最近访问距今天数、距今天数筛选值、从未访问、30天未访问标记，这样可以把“从未访问”和“最近 30 天未访问”统一沉淀成一个可直接用于页面过滤的字段。
3、页面 -> 数据集 -> 账号 -> 源表 的追溯逻辑
页面治理的关键不是只找出“没人访问”的页面，而是要继续补齐治理上下文。本次 SQL 中做了三层追溯：
- 页面与卡片关系：通过
page 与 card.pg_id
- 卡片与数据集关系：通过
card.ds_id
- 数据集与账号关系：通过
data_source.ac_id
同时从 data_source.config 中提取 $.tableQuery.query，再通过正则抓取 from/join 后的首个物理表名，生成 推断源表 字段。
本次 ETL 核心输出字段包括：
页面名称最近访问时间最近访问距今天数30天未访问标记页面卡片数页面数据集数数据集名称账号名称连接器类型源表查询SQL推断源表
4、ETL 输出结果
处理完成后，输出数据集会保留治理排查所需的主要字段，后续可直接给页面表格卡片使用。
5、ETL 逻辑导出附件
这里也补充 ETL 导出附件，便于直接下载后导入验证：文件名：长期未访问仪表板治理ETL_20260420_v2.zip
看板搭建：
1、表格卡片配置
页面最终采用普通表格卡片展示治理明细，字段放置如下：
页面名称最近访问距今天数30天未访问标记从未访问页面卡片数页面数据集数数据集名称账号名称连接器类型推断源表卡片名称列表源表查询SQL页面ID数据集ID
2、默认过滤逻辑
为了让页面打开后直接进入治理视角，本次页面没有额外配置选择筛选器，而是在卡片上直接固化了一个默认过滤条件：30天未访问标记 = 是。同时按 距今天数筛选值 倒序排列，使更久未访问的页面优先展示。
3、最终发布效果
实践结果：
通过这次实践，我们沉淀了一套可以直接复用的“长期未访问仪表板治理”方案：
- 直接从元数据库与行为日志取数，不依赖不稳定的内建说明链路
- 先识别最近 30 天未访问的页面，再继续追到页面关联的数据集、账号和源表
- 用
30天未访问标记 固化页面默认治理视角，避免前端筛选条件失真
- 最终沉淀为一张治理宽表和一个可直接展示的明细看板
这套方案尤其适合以下场景：
- 仪表板清理前的影响范围评估
- 页面资源盘点
- 元数据库治理排查
- 下线前确认页面依赖数据集与物理表
总结：
这次实践把“查询最近 30 天未访问的仪表板，并继续追溯其数据集、账号和源表”整理成了一条完整可复用的链路：先建立元数据与日志输入数据集，再通过 ETL 统一沉淀治理宽表，最后用一个普通表格页面承接最终治理结果。
如果后续还要继续扩展，这套方案还可以继续演进到两个方向：
- 把
30天 参数化，扩展为任意 n 天未访问
- 继续补充页面目录、负责人、发布时间等字段，形成更完整的治理台账
| 
