标签与元数据管理：任务标签体系设计、表级元数据采集、生命周期管理

账单精细化管理，说白了就是要把每一分钱都算清楚、讲明白。但数据平台动辄几千个任务、上万张表，你怎么知道哪个任务在烧钱？哪张表该清理了？

我个人的经验是——没有标签和元数据，成本治理就是瞎子摸象。这一章，咱们就聊聊怎么把这两件事落地。

任务标签体系设计：给每个任务一个“身份证”

先问个问题：你平台上有多少个任务？几百？几千？如果现在让你找出“所有离线ETL任务”或者“所有高优任务”，你能在5分钟内搞定吗？

我在一家互联网公司遇到过这种情况。当时平台上有3000多个任务，运维同学想排查某个业务线的成本，结果花了整整两天人工翻代码。嗯，从那以后，我坚决要求所有任务必须打标签。

标签分类原则

标签不是乱打的。我习惯把标签分成三类：

• 基础标签：任务类型（离线/实时/流式）、调度频率（天/小时/分钟）、负责人、业务线
• 成本标签：资源消耗等级（高/中/低）、计算引擎（Spark/Flink/Hive）、数据量级
• 治理标签：是否核心任务、是否可降级、是否可延迟、SLA等级

标签命名规范

标签命名这件事，看着简单，坑却不少。我曾经见过一个团队，标签名五花八门——有的叫“离线任务”，有的叫“offline_job”，还有的叫“batch-task”。结果统计的时候，同一个意思的标签被分成了三份。

我建议统一采用英文小写+下划线的格式：

# 基础标签
task_type=offline
schedule_freq=daily
owner=zhangsan

# 成本标签
cost_level=high
engine=spark
data_scale=large

# 治理标签
is_critical=true
can_degrade=false
sla_level=p0

标签管理平台

标签不能靠人工维护，必须系统化。我参与设计过一个标签管理平台，核心流程是这样的：

1. 标签注册：管理员在后台定义标签key和可选value
2. 标签绑定：任务创建时自动打基础标签，成本标签由系统根据资源消耗自动计算
3. 标签校验：每天跑一次校验任务，检查是否有任务缺少必填标签
4. 标签审计：每周生成标签覆盖率报告，低于95%的团队需要整改

表级元数据采集：把数据资产“摸清楚”

元数据是什么？说白了就是“数据的数据”。表名、字段、分区、存储量、最后访问时间……这些信息如果不采集，你根本不知道平台上到底有哪些数据。

我记得有一次做成本分析，发现某个表占了30TB存储，但最后访问时间是一年前。一问才知道，这是三年前的一个临时表，早就没人用了。你看，没有元数据，这种“僵尸表”就会一直烧钱。

元数据采集范围

我一般把元数据分成三层：

层级	采集内容	采集频率
表级	表名、库名、所有者、创建时间、最后DDL时间、存储格式、压缩方式	每天一次
分区级	分区字段、分区值、分区大小、分区记录数、最后访问时间	每天一次
字段级	字段名、字段类型、字段注释、是否为空、是否有索引	每周一次

采集架构设计

元数据采集不能影响线上业务。我习惯用异步采集+消息队列的方式：

# 伪代码示例：元数据采集流程
def collect_table_metadata(table_name):
    # 1. 从Hive Metastore获取表结构
    schema = get_table_schema(table_name)
    
    # 2. 从HDFS获取存储信息
    storage_info = get_hdfs_storage(table_name)
    
    # 3. 从审计日志获取访问信息
    access_info = get_access_log(table_name)
    
    # 4. 组装成元数据记录
    metadata = {
        "table_name": table_name,
        "schema": schema,
        "storage": storage_info,
        "access": access_info,
        "collect_time": int(time.time())
    }
    
    # 5. 发送到Kafka，由下游消费写入元数据中心
    kafka_producer.send("metadata_topic", metadata)

元数据血缘

光有元数据还不够，还得知道数据从哪里来、到哪里去。这就是血缘分析。

我参与过一个项目，需要排查某个报表的数据异常。如果没有血缘，你得人工翻代码、找依赖，至少半天。有了血缘，点一下就能看到完整的上下游链路，5分钟定位问题。

血缘采集的核心逻辑：

• 解析SQL：从任务代码中解析出输入表和输出表
• 构建DAG：把表之间的依赖关系组织成有向无环图
• 存储血缘：用图数据库（如Neo4j）或关系型数据库存储
• 可视化展示：提供血缘查询和展示界面

生命周期管理：让数据“生得明白，死得清楚”

数据不是越多越好。每张表都在消耗存储和计算资源。生命周期管理，就是要给数据定一个“保质期”。

我见过最夸张的情况：一个团队把所有表都设成“永久保留”，结果存储成本每年翻倍。后来我们做了生命周期管理，一年省了40%的存储费用。

生命周期策略

我习惯把数据分成三类，分别制定不同的生命周期策略：

数据类别	保留周期	清理方式	示例
核心数据	永久保留	不清理，但做冷热分离	用户表、订单表
中间数据	7-30天	到期自动删除	临时表、中间结果表
日志数据	30-90天	到期归档到冷存储	访问日志、监控日志

自动化清理流程

生命周期管理不能靠人工，必须自动化。我设计过一个清理流程：

1. 元数据扫描：每天凌晨扫描所有表，获取最后访问时间和存储量
2. 策略匹配：根据表的标签和元数据，匹配对应的生命周期策略
3. 生成清理清单：列出所有需要清理的表，发送给负责人确认
4. 自动执行：如果负责人24小时内未回复，系统自动执行清理
5. 清理审计：记录清理日志，包括清理时间、清理量、清理人

冷热分离

对于核心数据，虽然不能删除，但可以做冷热分离。热数据放在SSD上，冷数据放在HDD或者对象存储上。

我习惯用访问频率作为冷热判断标准：

• 热数据：最近7天被访问超过10次
• 温数据：最近30天被访问过
• 冷数据：超过30天未被访问

冷热分离的迁移策略：

# 冷热分离伪代码
def migrate_cold_data():
    # 1. 查询所有表的最新访问时间
    tables = get_all_tables()
    
    for table in tables:
        last_access = table.last_access_time
        days_since_access = (now - last_access).days
        
        if days_since_access > 30:
            # 2. 冷数据迁移到对象存储
            migrate_to_cold_storage(table)
            
            # 3. 在原位置创建外部表，指向冷存储
            create_external_table(table, cold_storage_path)
            
            # 4. 记录迁移日志
            log_migration(table, "cold")

知识体系总览

说了这么多，咱们用一张图把这一章的核心逻辑串起来：

你看，标签、元数据、生命周期这三件事是环环相扣的。标签告诉你“这是什么任务”，元数据告诉你“这个任务用了哪些数据”，生命周期告诉你“这些数据该不该留”。三者结合起来，成本治理才能落地。