数据团队技术债务治理：遗留系统与旧口径的清理策略

大家好，我是朱大喜。每个数据团队都有一本"血泪账本"：三年前建的 DWD 表还在跑、五年前的业务口径没人说得清来龙去脉、仓库里躺着 200 多张"不知道谁在用"的旧表。技术债务不清理，就像家里堆满杂物——每次找数据都得绕半天路。今天聊聊数据团队怎么治理技术债务。

一、数据技术债务的四种形态

不是所有"旧东西"都是技术债务。我们先把债务分类：

类型一：表级债务

最常见的表现：

• 仓库里有 500 张表，实际在用的不到 200 张
• 表没有注释、字段没有注释、分区没有注释
• 字段类型不一致：同一个 user_id 在 A 表是 BIGINT，B 表是 STRING

类型二：口径债务

最隐蔽、危害最大的债务：

• "活跃用户"在 3 张表里有 3 套定义
• 业务方改了统计口径，但表结构没更新
• 新人接手后完全不知道某个指标是怎么算出来的

为什么口径债务是四种债务里最隐蔽、危害最大的？表级债务你能看到——表没注释、没人用，扫一眼就发现了；但口径债务是"隐性"的：表结构看起来一切正常，SQL 也能跑，最后产出的数字也没报错。直到有一天财务部门和运营部门分别出了一份"月活用户数"报表，同一个月份数字差了 22%，两个团队在会议上吵起来，你才发现——一张表用"30 天内有过登录"算活跃，另一张用"30 天内有过登录+浏览+支付任一行为"算活跃。口径债务不会让系统报错，它只会让决策建立在错误的数据共识上。

类型三：链路债务

• ETL 链路里套了 5 层中间表，每层都有"历史原因"
• 某张表没人维护了，但 10 个下游任务在依赖它
• 定时任务超时，没人知道原因，每次手动重跑

类型四：工具债务

• 关键脚本只有原作者看得懂
• BI 看板的数据源直接连生产表，没人敢动
• 使用了已不再维护的开源组件

二、债务评估：先量化再治理

治理债务的第一步不是"动手清理"，而是先搞清楚债有多大。

""" 数据技术债务评估工具 —— 量化分析四类债务的严重程度 """ import pandas as pd from datetime import datetime, timedelta class DataDebtEvaluator: """数据技术债务评估器""" def __init__(self): self.debt_report = {} def evaluate_table_debt(self): """ 评估表级债务：从元数据中心拉取所有表的元数据 计算每张表的"债务分数" """ # 从元数据中心查询所有数据表信息 tables_query = """ SELECT table_name, -- 表名 db_name, -- 库名 table_comment, -- 表注释（空=债务+1） create_time, -- 创建时间 last_access_time, -- 最后访问时间 owner, -- 负责人（空=债务+1） storage_bytes, -- 存储大小 field_count, -- 字段数量 SUM(CASE WHEN col_comment = '' THEN 1 ELSE 0 END) AS no_comment_cols -- 无注释字段数 FROM metadata.table_catalog WHERE db_name NOT IN ('ods_tmp', 'test') -- 排除临时库和测试库 GROUP BY table_name, db_name, table_comment, create_time, last_access_time, owner, storage_bytes, field_count """ df_tables = pd.read_sql(tables_query, engine) # === 债务评分规则 === def calculate_debt_score(row): score = 0 reasons = [] # 规则1：60天以上未访问 → 疑似废弃表 days_since_access = (datetime.now() - row['last_access_time']).days if days_since_access > 60: score += 30 reasons.append(f"表 {days_since_access} 天未访问，疑似废弃") # 规则2：无注释 + 无负责人 → 孤儿表 if pd.isna(row['table_comment']) or row['table_comment'] == '': score += 20 reasons.append("缺少表注释") if pd.isna(row['owner']) or row['owner'] == '': score += 20 reasons.append("缺少负责人") # 规则3：超过30%字段无注释 → 维护差 if row['field_count'] > 0: no_comment_ratio = row['no_comment_cols'] / row['field_count'] if no_comment_ratio > 0.3: score += 15 reasons.append(f"字段注释缺失率 {no_comment_ratio:.0%}") # 规则4：存储大于100GB且无访问 → 资源浪费 if row['storage_bytes'] > 100 * 1024**3 and days_since_access > 30: score += 15 reasons.append(f"存储占用 {row['storage_bytes']/1024**3:.0f}GB 但超过30天未访问") return score, '; '.join(reasons) df_tables[['debt_score', 'debt_reason']] = df_tables.apply( lambda row: pd.Series(calculate_debt_score(row)), axis=1 ) # 债务分级 df_tables['debt_level'] = pd.cut( df_tables['debt_score'], bins=[0, 20, 40, 100], labels=['🟢 健康', '🟡 需关注', '🔴 严重'] ) self.debt_report['table_debt'] = { "总表数": len(df_tables), "严重债务表": len(df_tables[df_tables['debt_level'] == '🔴 严重']), "待清理表": df_tables[df_tables['debt_score'] >= 50]['table_name'].tolist(), "资源可释放": f"{df_tables[df_tables['debt_score'] >= 50]['storage_bytes'].sum() / 1024**3:.1f} GB" } return df_tables.sort_values('debt_score', ascending=False) def evaluate_metric_debt(self): """ 评估口径债务：统计口径字典中的重复定义和冲突 """ # 同一个指标在口径字典中有多条记录 → 口径混乱 metric_query = """ SELECT metric_name, -- 指标名称（如"日活用户数"） COUNT(DISTINCT definition) AS def_count, -- 不同定义的个数 COLLECT_LIST(definition) AS definitions, -- 所有定义汇总 COLLECT_LIST(table_source) AS sources -- 所有来源表 FROM metadata.metric_catalog GROUP BY metric_name HAVING COUNT(DISTINCT definition) > 1 -- 定义不唯一的指标 """ df_metrics = pd.read_sql(metric_query, engine) self.debt_report['metric_debt'] = { "口径冲突指标数": len(df_metrics), "冲突指标列表": df_metrics['metric_name'].tolist(), "建议": "以上指标存在多套定义，需统一口径后下线冗余版本" } return df_metrics # 执行评估 evaluator = DataDebtEvaluator() table_debt = evaluator.evaluate_table_debt() metric_debt = evaluator.evaluate_metric_debt() print(f"表级债务报告：严重表 {evaluator.debt_report['table_debt']['严重债务表']} 张") print(f"口径债务报告：冲突指标 {evaluator.debt_report['metric_debt']['口径冲突指标数']} 个")

三、清理策略：分阶段治理

阶段一：识别与标记（第1-2周）

用上面的评估脚本把仓库扫一遍，输出一份"债务清单"，按严重程度排序。

阶段二：分级排序（第3周）

# 清理优先级矩阵 CLEANUP_PRIORITY = { "P0-立刻处理": { "条件": "debt_score >= 70 且 无下游依赖", "动作": "直接下线/删除", "审批": "不需要，负责人自批" }, "P1-本周处理": { "条件": "debt_score >= 50 且 下游依赖 < 3", "动作": "迁移后下线", "审批": "TL 审批" }, "P2-本月处理": { "条件": "debt_score >= 30", "动作": "制定重构计划", "审批": "纳入迭代排期" }, "P3-保持观察": { "条件": "debt_score < 30", "动作": "补充注释和元数据", "审批": "日常维护" } }

阶段三：冻结与下线（第4-6周）

-- 安全下线流程：先冻结（停止写入），观察7天后正式删除 -- Step 1: 查找哪些任务在使用这张表 SELECT job_name, -- 任务名称 schedule_owner, -- 任务负责人 last_run_time, -- 最后运行时间 job_status -- 任务状态 FROM scheduler.job_catalog WHERE job_sql LIKE '%old_user_behavior_di%' -- 搜索引用该表的任务 AND job_status != 'OFFLINE'; -- 只查在线任务 -- Step 2: 如果无人使用，冻结写入权限（保留读取7天） ALTER TABLE dwd.old_user_behavior_di SET TBLPROPERTIES ( 'freeze.write' = 'true', -- 冻结写入 'freeze.time' = '2026-07-29', -- 冻结日期 'freeze.reason' = '技术债务清理-废弃表' ); -- Step 3: 7天后确认无影响，执行删除 -- DROP TABLE IF EXISTS dwd.old_user_behavior_di;

为什么冻结-观察-删除三步走比直接 DROP 更稳妥？WHERE job_sql LIKE '%old_table%'这种依赖检测只能找到直接引用表名的任务，但找不到通过宏变量、动态 SQL 或者外部调度系统间接引用的场景。某张"废弃表"可能在 Airflow 的某个 DAG 里被{{ ds }}拼接引用，也可能在 Metabase 的某个看板上被一个 Saved Question 调用——这两种引用都不会出现在job_catalog.job_sql的 LIKE 匹配里。7 天的观察期就是留给这些"隐形依赖"一个暴露的机会：如果表冻结后有人发现数据不更新了、看板变灰了，说明还有依赖在，不能删。

阶段四：重构核心表（第7周起）

对于高债务但还在用的表，不能简单删除，需要重构：

-- 重构示例：统一"活跃用户"的定义 -- 旧表：dwd.user_activity_old_di —— 3套口径混在一起，谁也不敢改 -- 新表：dwd.user_activity_new_di —— 一个字段一个口径，清清楚楚 CREATE TABLE dwd.user_activity_new_di ( ds STRING COMMENT '数据日期', user_id BIGINT COMMENT '用户ID', -- ✅ 每个口径独立一个字段，不再混在一起 is_active_strict INT COMMENT '严格活跃：当日有核心行为（下单/发帖/搜索）', is_active_loose INT COMMENT '宽松活跃：当日有打开App即算活跃', active_score INT COMMENT '活跃度得分：核心行为3分+次要行为1分加总', -- 通过字段设计解决口径混乱 —— 源头治理 core_action_cnt INT COMMENT '核心行为次数', minor_action_cnt INT COMMENT '次要行为次数' ) COMMENT '用户活跃明细表（重构版，口径标准化）' PARTITIONED BY (ds STRING) STORED AS PARQUET;

四、防止新债产生的机制

清理完旧债，更重要的是不让新债产生：

结论

🚨 踩坑提醒

1. debt_score 的阈值不能一刀切：文章里的 60 天未访问 = 30 分，30% 字段无注释 = 15 分，这些阈值是业务环境相关的。一张日更的核心 DWD 表如果 5 天没被访问，比一张月更的冷备表 60 天没访问更危险。建议对不同类型的表（ODS/DWD/DWS/ADS/维表）分别设定不同的阈值矩阵，而不是一套规则打天下。

2. 依赖检测可能漏掉外部系统的引用：调度系统的job_catalog只能查到调度任务里的 SQL 引用，但找不到 BI 工具里的 Saved Query、API 接口里动态拼接的 SQL、Python 脚本里的 ODBC 连接以及分析师的 ad-hoc 查询。建议在正式冻结表之前，在元数据平台发一条"该表即将下线"的公告，保留至少一个完整业务周期（如月末关账周）的缓冲。

3. 口径字典本身如果不是权威来源，清理就变成空中楼阁："注册一个口径字典"说起来简单，但如果录入过程靠人工、没有和 ETL 代码做绑定检查，字典很快就会过期。建议在口径字典的每一条记录里外挂一个"数据源校验"——定期跑一条测试 SQL 验证这个指标的实际计算结果是否和字典里定义的一致。不一致就告警，否则字典只是另一份无人维护的 Excel。

数据技术债务治理就四句话：

1. 量化先行：先评估再治理，别凭感觉删表
2. 安全第一：下线用"冻结→观察→删除"三步走，别一上来就 DROP
3. 源头治理：清理旧债 + 建立规范，双管齐下
4. 持续迭代：技术债务不是一次性能清理完的，建成例行机制

治理债务这件事，开始做比做完美更重要。哪怕只是把无注释的表补上注释，也是一个好的开始。