1总览：本次实测的关键数字
全部来自生产库只读实测，非交接转述。证据分级：E1=结构证据，E2=样本验证；本报告不含未经业务复核的 E3/E4 结论。
546 GB
疑似停更 ≥1 年的核心表
m_vat_invoice_item_all
高优先风险80 族
重复建设表族
TOP40 冗余约 5.4 TB
可清退1,599
空壳表（占 28%）
psa_ 一族占 1,156 张
待评审440
统计信息失效表
批量 ANALYZE 可修复
零风险速赢
21.86 TB
总存储 · 4,133 张有数据表
psa_ 贴源占 71%
20
活跃账号（8 天窗口）
含 2 套未登记 BI + 9+ 个人账号
一句话结论
这是一个「厚贴源、薄建模」的发票 SaaS 数仓。本次把交接的"下一步方向"落成了实测证据：确认了主键体系、验证了最大表粒度、量化了 5.4 TB 冗余、产出 1,599 张空壳清单，并揪出一张停更一年的 546 GB 核心表——后者是本期最高优先级单点风险。
2实体与主键识别
全仓列名频次分析（出现 ≥50 表的列名共 60 个），剔除审计列后的业务连接键实测分布。来源 information_schema.columns。
印证治理方案的警告仓内根本没有 enterprise_id。主体身份不能靠一个统一企业 ID，必须用 seller_tax_no / purchaser_tax_no（法定唯一税号）+ tenant_id 建含有效期的主体映射表来还原。
最大表粒度实测通过（E2）m_finacc_seller_invoice（750 GB / 26.6 亿行）68 列含票头要素 + 红冲要素、无票行字段；200 万行样本内 invoice_id 零重复 → 一行 = 一张发票（票头粒度）。可作发票单据事实候选基表。
3重复建设量化
按"去后缀基名"（剥离 _v1/_v2/_0/_bak/_temp/_copy/_日期）归并出 80 个表族。是清退候选，非可直接删除清单。
发票核心链路：同一贴源 8 个版本并存 ≈ 1.6 TB
pre_invoice_item_v1
161 GB
pre_invoice_item_v1_0
140 GB
典型重复族
| 基名 | 变体数 | 性质 |
|---|
| tmp_wqs | 12 | 个人临时表反复落地 |
| m_vat_invoice_item_all_month_temp | 12 | 按月分裂的临时中间表 |
| tmp_majun_monitor_system | 9 | 监控中间结果按日堆积 |
| psa_inv_seller_pre_invoice_item | 6 | 预开票明细多版本并存 |
| dim_report_sys_org_struct | 6 | 维度表 5 份 temp 副本 |
5.4 TB 冗余存储已量化族内，非基名成员冗余 TOP40 合计约 5.4 TB。check_* 对账校验族占冗余榜前列——ETL 自检副产物、几乎无下游，是最安全的清退入口。
4空壳表与临时表
空壳 = pg_class 有、svv_table_info 无（零数据块）。全量 1,599 张清单已落盘 evidence/empty_tables.csv。
空壳表族群归因（1,599 张，占全部物理表 28%）
psa_ 一族 1,156 张空壳 = 接入治理问题说明贴源接入存在大量"建了壳、没灌数"的僵尸管道——不只是存储浪费，更是接入流程失控的信号。temp/tmp 共 574 张 / 640 GB，大头是少数几个"按月/按日复制"的习惯（m_vat_*_month_temp_*、tmp_wqs_*、tmp_majun_*）。
5数据新鲜度画像
8 张代表性大表 12 个候选时间列实测 MAX（90s 受控）。MAX 只代表样本下最大值，超时/空 = 未确认，不等于停更。
| 表 | 时间列 | MAX 值 | 判读 | 状态 |
|---|
| m_vat_invoice_item_all | delta_time | 2024-08-22 | 疑似停更 ≥1 年（546 GB / 63 亿行，全仓第三大表） | 高优先风险 |
| psa_inv_seller_invoice_item | create_time | 2026-09-09 02:37 | 活跃，当日凌晨 | 正常 |
| psa_seller_invoice | paper_drew_date | 2026-09-08 21:54 | 活跃，当日 | 正常 |
| m_walmart_seller_invoice_item | delta_time | 2026-09-08 21:39 | 活跃 | 正常 |
| m_finacc_seller_invoice | paper_drew_date | 20290611 | 字符串日期，含 2029 未来值 | 质量问题 |
| psa_inv_seller_invoice_item | paper_draw_date | 2029-07-29 | 时间戳型，含未来值 | 质量问题 |
| psa_seller_invoice_item | create/update_time | —（超时/空） | 未能在受控窗口确认 | 待复核 |
🔴 本期最高优先级单点风险m_vat_invoice_item_all（546 GB / 63 亿行）delta_time 停在 2024-08-22，超一年无增量。名字里的 "all" 暗示是全量增值税发票明细汇总——若下游仍在引用，读到的是一年前的旧数据。需立即核实管道与消费方，恢复或下线。
🟡 业务日期列存在未来值开票日期出现 2029 年值（paper_drew_date / paper_draw_date），会污染任何按时间窗口的统计。需建质量规则拦截未来日期后才能做时间序列分析。
6消费方实况复核
8 天窗口 stl_connection_log，截至 2026-09-09 10:13。与交接一致：消费方结构当下仍成立，无一套 BI 已下线。
个人账号跑生产未登记/个人 BI 账号系统/平台账号
治理问题持续存在个人账号 gongjianfeng（3,499 会话）及 tianyang / lvwenjing / sunquanfeng / guiweidong 等仍在活跃。两套 BI（Redash、阿里云 QuickBI）在连接清单中完全缺失——代码抽取原理上看不见 BI 工具和人肉连接。
7治理发现与建议（按优先级）
所有清退均为候选，下线需走「依赖确认 → 保留核验 → 观察/归档 → 审批 → 回滚准备」流程。
F1
高
m_vat_invoice_item_all 疑似停更 ≥1 年
546 GB 核心表，delta_time 停在 2024-08-22。下游若仍引用将读到一年前旧数据。
动作：立即核实管道/消费方，恢复或下线
F2
高
业务日期列存在未来值
paper_drew_date / paper_draw_date 出现 2029 年值，污染时间窗口统计。
动作：建质量规则拦截未来日期
F3
中
发票链路多版本冗余
psa_inv_seller_(pre_)invoice_item 一族 8 版本约 1.6 TB；全仓 80 族冗余 TOP40 约 5.4 TB。
动作：定主线版本，其余归档
F4
中
1,599 张空壳表（28%）
psa_ 1,156 张为"建壳未灌数"僵尸管道。
动作：按族群评审清退，check_ / temp_ 先行
F5
低
440 张表统计信息失效
TOP30 已落盘，含 97.9% / 100% 严重表，导致坏执行计划。
动作：批量 ANALYZE，零风险速赢，可立即执行
F6
中
个人账号跑生产
gongjianfeng(3,499 会话) / tianyang / lvwenjing 等仍活跃。
动作：收编为服务账号，最小权限
F7
信息
无 enterprise_id 字段
主体识别只能靠 seller_tax_no / purchaser_tax_no + tenant_id。
动作：建主体映射表（含有效期），设计待验证
F8
信息
最大表粒度实测通过（E2）
m_finacc_seller_invoice 200 万样本 invoice_id 无重复 → 票头粒度。
动作：可作发票单据事实候选基表，待 E3/E4 业务复核
实施顺序
速赢
① 批量 ANALYZE 440 张失效表
② 空壳表评审（check_/temp_ 先行）
本期核心
③ 核实 m_vat 停更
④ 发票链路 5.4 TB 冗余收敛
⑤ 建主体映射表
下一步
关联验证 / 金额勾稽 / 红冲语义
（需业务签署升至 E4）