# 观远 BI 元数据表如何做增量同步与历史留存
一、背景
在做观远 BI 元数据接入数仓时，一个常见问题是：
有些元数据表并不是长期保留全量历史数据，而是会随着系统清理任务定期删除旧记录。
例如在排查过程中，常会发现类似下面的现象：
- `task_status` 只能查到近几天甚至近一天的数据
- 某些任务日志、更新历史、离线导出记录无法追溯更早时间
- 客户希望基于元数据做运营分析、运维审计或任务追踪时，发现系统表本身不适合作为长期历史库
这类场景下，建议提前识别哪些表适合做增量同步，哪些表需要尽早抽取到数仓保留历史。
本文基于元数据库结构、迁移 DDL、代码清理策略以及实际排查经验，整理出一份适合实施和交付使用的参考清单。
二、先说结论
观远元数据表大体可以分成两类：
1. 主元数据表
- 这类表主要保存当前有效配置或当前状态
- 通常更适合按 `utime` 做增量同步
- 一般不依赖表内长期保留完整历史
2. 历史/日志类表
- 这类表主要保存任务执行、资源更新、订阅发送、ETL 历史版本等过程数据
- 很多表会被系统清理任务按时间删除旧记录
- 如果客户有审计、追踪、复盘、长期分析需求，建议同步到数仓保留历史
也就是说：
- 如果目标是做“当前配置同步”，重点关注主元数据表
- 如果目标是做“长期追踪分析”，重点关注历史/日志类表
三、主元数据表建议
这类表通常适合做当前状态同步，重点关注更新时间字段即可。
| 表名 | 业务含义 | 是否默认按时间清理 | 建议增量字段 | 说明 |
|---|
| `domain` | 租户信息 | 否 | `utime` | 适合做维表同步 |
| `user` | 用户信息 | 否 | `utime` | 适合做维表同步 |
| `user_sso` | 用户外部账号绑定 | 否 | `utime` | 建议和用户表一起同步 |
| `user_group` | 用户组 | 否 | `utime` | 适合做维表同步 |
| `user_group_rel` | 用户组成员关系 | 否 | `utime` | 建议保留关系变化 |
| `role` | 角色信息 | 否 | `utime` | 适合做维表同步 |
| `role_permission_rel` | 角色权限关系 | 否 | `utime` | 权限分析常用 |
| `permission` | 权限定义 | 否 | `utime` | 适合做维表同步 |
| `directory` | 目录信息 | 否 | `utime` | 适合做维表同步 |
| `page` | 页面信息 | 否 | `utime` | 页面配置主表 |
| `card` | 卡片信息 | 否 | `utime` | 卡片配置主表 |
| `page_card_rel` | 页面与卡片关系 | 否 | `utime` | 页面卡片关系表 |
| `data_source` | 数据集信息 | 否 | `utime` | 数据集主表 |
| `field` | 字段定义 | 否 | `utime` | 字段元信息 |
| `data_flow` | ETL / 数据流主表 | 否 | `utime` | ETL 主表 |
| `schedule` | 订阅配置 | 否 | `utime` | 适合同步当前订阅状态 |
| `resource_role_rel` | 资源授权关系 | 否 | 建议全量或结合业务字段处理 | 部分环境不一定有标准更新时间字段 |
这类表的实施建议
- 优先使用 `utime` 做增量条件
- 如果表存在 `is_del`，同步时建议一起带出删除状态
- 如果客户后续要分析“配置变更历史”，仅靠主表增量还不够，建议在数仓侧做快照或拉链表
四、历史与日志类表建议
这类表是最需要重点关注的，因为它们往往天然更接近“明细事实表”，但又可能被系统自动清理。
| 表名 | 业务含义 | 主要时间字段 | 建议增量字段 | 默认保留策略 | 建议 |
|---|
| `task_status` | 任务执行状态 | `submit_time`、`running_time`、`finished_time`、`utime` | `submit_time` | 默认约 35 天 | 建议同步到数仓做历史留存 |
| `resource_update_history` | 资源更新历史 | `begin_time`、`end_time`、`submit_time` | `begin_time` | 默认约 35 天 | 建议同步到数仓做历史留存 |
| `offline_task_history` | 离线导出/下载任务历史 | `submit_time` | `submit_time` | 默认约 35 天 | 建议同步到数仓做历史留存 |
| `data_flow_history` | ETL 历史版本记录 | `time` | `time` | 默认约 35 天 | 建议同步到数仓做历史留存 |
| `sync_account_history` | 账户同步历史 | `begin_time`、`end_time`、`utime` | `utime` | 未发现固定默认清理策略 | 建议同步到数仓做历史留存 |
| `schedule_log` | 订阅发送日志 | `first_send_time`、`last_send_time`、`ctime`、`utime` | `last_send_time` | 未发现固定默认清理策略 | 建议同步到数仓做历史留存 |
| `audit_log` | 审计日志 | `ctime` | `ctime` | 一般按环境审计保留配置执行 | 建议同步到数仓做历史留存 |
| `baseline_send_log` | 基线通知发送日志 | `send_time`、`ctime` | `send_time` | 默认约 100 天 | 如关注通知历史，建议同步 |
为什么这类表更建议进数仓
原因很简单，这些表本身承载的是“过程型记录”：
- 谁触发了任务
- 任务什么时候开始、结束
- 资源什么时候更新
- ETL 历史版本如何变化
- 订阅是否发送成功
- 审计日志记录了哪些操作
这类信息天然适合做长期追踪分析，但如果只依赖在线元数据库，就会受到系统清理策略影响。
五、为什么有时只能查到一天数据
很多实施现场会碰到这个问题：
> 例如 `task_status` 只能查到近一天的数据，是不是这个表本身就只保留一天？
通常不是“表设计上只存一天”，而更可能是下面几种原因：
1. 环境里有清理任务，旧数据已经被定期删除
2. 清理参数被环境单独配置过，保留天数短于默认值
3. 环境近期做过迁移、重建或清库
4. 查询的是运行历史表，而不是主配置表
因此，看到 `task_status` 当前只剩一天数据，并不能直接推断“产品默认只保留一天”，更合理的判断方式是：
- 先看表类型，是主表还是历史表
- 再看增量字段和清理策略
- 最后结合当前环境实际数据范围判断
六、建议优先抽取到数仓的表
如果客户当前就希望做元数据历史沉淀，建议最少先覆盖下面几张：
- `task_status`
- `resource_update_history`
- `offline_task_history`
- `data_flow_history`
- `sync_account_history`
- `schedule_log`
- `audit_log`
这几张表能够覆盖大部分“任务追踪、更新追踪、订阅追踪、审计追踪”场景。
七、推荐实施方式
1. 主元数据表
推荐方式：
- 按 `utime` 做增量同步
- 同步当前状态到 ODS 或维表层
- 如需保留变更轨迹，在数仓侧做拉链或快照
2. 历史/日志类表
推荐方式：
- 按业务时间字段做增量同步
- 将在线库中的过程记录尽早落到数仓
- 在数仓中保留长期历史，不依赖在线元数据库保留时长
3. 同步策略建议
可以采用下面的实践原则：
| 表类型 | 推荐策略 |
|---|
| 主配置表 | 增量同步当前状态 |
| 关系表 | 增量同步 + 关注删除状态 |
| 历史/日志表 | 明细增量同步 + 长期归档 |
| 高价值追踪表 | 尽量缩短同步周期，避免在线清理后丢数 |
八、排查 SQL 示例
如果想快速看当前环境某些关键表到底保留了多长时间，可以先跑下面这类 SQL：
SELECT 'task_status' AS table_name, MIN(submit_time) AS min_time, MAX(submit_time) AS max_time, 'submit_time' AS incr_field FROM task_status
UNION ALL
SELECT 'resource_update_history', MIN(begin_time), MAX(begin_time), 'begin_time' FROM resource_update_history
UNION ALL
SELECT 'offline_task_history', MIN(submit_time), MAX(submit_time), 'submit_time' FROM offline_task_history
UNION ALL
SELECT 'data_flow_history', MIN(`time`), MAX(`time`), 'time' FROM data_flow_history
UNION ALL
SELECT 'sync_account_history', MIN(begin_time), MAX(begin_time), 'utime(begin_time辅助)' FROM sync_account_history
UNION ALL
SELECT 'schedule_log', MIN(last_send_time), MAX(last_send_time), 'last_send_time' FROM schedule_log
UNION ALL
SELECT 'audit_log', MIN(ctime), MAX(ctime), 'ctime' FROM audit_log;
这类 SQL 不能替代结构分析，但可以很快帮助判断：
- 当前环境到底还剩多久的数据
- 哪些表已经不适合作为唯一历史来源
- 哪些表需要优先接入数仓
九、最终建议
如果客户只想拿到“当前配置状态”，重点同步主元数据表即可；
如果客户希望基于元数据做长期分析、运维审计、问题追溯、任务复盘，那么历史/日志类表应尽快进入数仓。
一句话总结：
**观远元数据表适合分层看待，主表看当前状态，历史表进数仓保留长期价值。**
---
如果你也在做观远 BI 元数据接入，建议在正式实施前先完成三件事：
1. 盘点目标元数据表的增量字段
2. 区分主表与历史表
3. 评估历史表是否存在在线清理风险 | 
