一、引言
很多企业已经建设了元数据平台，采集了表结构、字段说明、血缘关系、标签和负责人，却仍然无法回答一个朴素问题：业务同学到底该用哪张表？问题不在于"数据不够多"，而在于元数据还停留在目录阶段，没有变成可判断、可比较、可运营的资产信号。
元数据目录回答的是"有什么"，资产运营回答的是"什么值得用、值得管、值得继续投入"，这两个问题看起来相近，实际差别很大。一张表有字段、分区、血缘和描述，只能说明它被登记过；只有当它有明确负责人、稳定消费接口、可验证质量、使用证据和生命周期状态时，它才进入资产运营的范围。
数据资产运营要在元数据之上继续回答六类问题：谁负责这份数据，谁真的在用它，它是否可信，它值不值得持续投入，它何时应该下架，以及有没有更合适的资产可复用。
资产运营不是替代元数据，而是给元数据增加责任、行为、信任和经营判断。很多治理项目失败，是因为只把"元数据完整率"当作目标。字段描述补齐了，标签也挂上了，但消费者仍然不知道哪张表最新、哪张表可信、哪张表有人负责、哪张表即将下线。资产运营的起点，是承认目录只是底座，真正的价值来自持续变化的运营信号。
二、资产模型
数据资产不应等同于所有表。临时表、调试表、一次性中间表如果全部进入资产视图，会制造新的噪声。资产应该是被业务或技术消费者持续使用、拥有明确责任人、具备可验证质量与生命周期状态的数据对象。
DataHub 的 Data Product 被定义为面向发现和消费的资产集合，可以包含表、任务、仪表盘、图表、Notebook、ML 模型等，并且每个 Data Product 必须归属一个 Domain；资产关联中还可以标记 output port，用来区分内部资产和对外发布资产。这个模型很适合作为"资产不是单表，而是可消费数据产品"的参考。
yaml
Asset
├─ Identity : asset_id, type, platform, physical_locator
├─ Context : domain, product, glossary_terms, description
├─ Accountability: business_owner, technical_owner, steward
├─ Signals
│ ├─ usage : users, queries, consumers, last_access
│ ├─ quality : rules, pass_rate, freshness, incidents
│ ├─ lineage : upstream, downstream, critical_consumers
│ └─ economics : storage_cost, compute_cost, maintenance_cost
└─ Lifecycle : draft, published, active, declining,
deprecated, quarantined, retired资产实体既保存描述性元数据，也关联随时间变化的运营信号。资产主键要稳定，不要把组织名、负责人名、业务别名写进物理标识。组织会调整，负责人会变化，业务术语也会迭代；真正稳定的是资产 ID、平台、物理位置、版本和与上游下游的关系。业务域、标签、等级、负责人都应作为可变属性管理。
三、归属与负责人
Owner=张三"不是责任机制。资产运营至少需要三个角色：业务所有者、技术所有者和数据管家。
业务所有者负责口径、定义、使用边界和业务优先级；技术所有者负责生产链路、质量规则、SLA 和故障恢复；数据管家负责术语、分级、敏感标签和治理流程。
| 事件 | 首责角色 | 处理结果 | 可量化信号 |
|---|---|---|---|
| 指标口径变更 | 业务所有者 | 确认定义、兼容策略和生效日 | 确认耗时、争议次数 |
| 质量规则失败 | 技术所有者 | 修复、回滚、豁免或发布说明 | MTTA、MTTR、复发率 |
| 敏感标签缺失 | 数据管家 | 补充分级、标签和访问策略 | 元数据完整率、标签覆盖率 |
| 下架申请 | 业务与技术共同负责 | 确认影响、替代资产和恢复窗口 | 未确认消费者数、迁移完成率 |
负责人机制要和事件连接。质量失败时，系统不只是展示红色状态，而是把事件派发给技术所有者；指标口径冲突时，不能只让平台研发判断，而要交给业务所有者；敏感字段未分级时，应进入数据管家的治理队列。
还要识别"责任失联"。如果负责人离职、群组为空、告警长期无人响应，资产状态应该被标记为责任异常。否则页面上虽然显示了 owner，实际没有人能为资产承担决策责任。
四、使用热度
查询次数是最容易拿到、也最容易误导的指标。一个资产每天被调度任务扫 500 次，不代表它被 500 个业务场景使用；一个核心财务表每月只在关账日被访问几次，也不代表它价值低。
建议用五类信号计算热度：
ini
Heat = 0.25·U + 0.20·F + 0.20·R + 0.20·C + 0.15·T| 符号 | 含义 | 解释 |
|---|---|---|
| U | 独立消费者 | 去重后的团队、账号、应用或报表数量 |
| F | 有效访问频次 | 过滤监控、血缘扫描、管理员巡检后的访问次数 |
| R | 近期性 | 距离最近一次真实消费的时间衰减 |
| C | 关键场景覆盖 | 是否被核心报表、模型、API、监管任务使用 |
| T | 连续活跃趋势 | 是否持续被使用，而不是偶然爆发 |
markdown
质量分
高 │ 沉睡精品：推广/推荐 │ 核心资产：重点保障
│ 检查入口与文档 │ 提升 SLA 与容量
├───────────────────────────┼───────────────
低 │ 低价值候选：评估下架 │ 高风险热点：优先治理
│ 先做影响分析 │ 限流、修复、告警
└───────────────────────────┴───────────────▶ 热度
低 高热度必须和质量一起看。高热度低质量资产，比低热度资产更需要优先治理。这组权重不是行业标准，只是一个起点。广告、金融、物流、游戏等业务对"关键场景"的定义不同，热度模型要用历史数据和人工评审不断校准。
五、质量评分
质量评分最怕一个总分掩盖所有问题。一个资产 20 条规则通过了 19 条，但唯一失败的是"交易金额不能为负"，它就不应该被评为高质量。
建议质量评分采用"规则加权 + 关键规则封顶 + 覆盖率惩罚 + 事故惩罚"的方式：
ini
Quality =
Σ(wᵢ × passᵢ × freshnessᵢ) / Σwᵢ
× CoveragePenalty
× IncidentPenalty| 设计点 | 说明 |
|---|---|
| 规则加权 | 主键唯一、金额合法、核心枚举有效等规则权重更高 |
| 关键规则封顶 | 关键规则失败时，质量等级最多为 C |
| 覆盖率惩罚 | 只有一两条规则的资产不能轻易拿高分 |
| 事故惩罚 | 近期 P1/P2 数据事故会降低资产信任度 |
| 证据下钻 | 分数必须能追溯到规则、样本、运行时间和责任人 |
质量分不是为了给团队排名，而是为了帮助消费者判断"能不能放心用"。如果一个资产分数低但原因清晰，治理团队知道该修哪里；如果只有一个 86 分，没人知道风险藏在哪里。
六、价值评估
价值不能直接等于热度。高频访问可能来自重复建设或低效查询，低频访问也可能支撑财务关账、监管报送或董事会经营分析。
建议把价值拆成四个子分，再单独展示风险惩罚：
ini
Value =
0.30·Impact
+ 0.25·Reuse
+ 0.25·Trust
+ 0.20·CostEfficiency
DecisionScore = Value − RiskPenalty| 子分 | 来源 | 示例 |
|---|---|---|
| Impact | 业务影响 | 收入指标、核心流程、监管报送、管理决策 |
| Reuse | 复用收益 | 跨团队消费者、替代重复建设、被多个数据产品引用 |
| Trust | 信任水平 | 质量分、文档完整度、负责人响应、稳定性 |
| CostEfficiency | 成本效率 | 存储、计算、维护成本与实际消费的匹配程度 |
| RiskPenalty | 风险惩罚 | 敏感数据、合规风险、事故历史、口径争议 |
上述公式没有跨平台官方标准，虽然能证明所有权、数据产品、质量规则、生命周期事件等能力存在，但不会替企业定义"价值分"。价值模型必须结合业务目标校准，不能照搬权重。
机器适合计算访问、质量、血缘、成本和事故；人更适合判断收入影响、监管义务、战略意义和声誉风险。一个成熟的价值评估机制，应该让机器负责排序，让业务和治理团队负责解释与决策。
七、资产下架
很多数据平台敢建表，不敢下表。久而久之，平台里充满没人维护、没人使用、没人敢删的"僵尸资产"。建议下架流程：先候选、再评审、再弃用、再隔离，最后才物理清理。
下架候选可以由系统生成，但删除不能自动发生。系统要先沿血缘分析下游表、任务、报表、接口和模型特征；还要识别查询日志观察不到的月度、季度任务。通知期结束后，应先禁止新增依赖，再进入只读或隔离状态，保留恢复窗口，最后才做物理清理。
下架不是为了"删得快"，而是为了让平台减少噪声和成本，同时不破坏仍在运行的业务。
八、复用推荐
当用户搜索"订单明细""用户画像""门店销售"时，平台不应该只返回名字相似的表，而应推荐更可信、更适合复用的资产。
复用推荐可以分三步：候选召回、硬过滤、重排序。候选召回看名称、描述、业务术语、Schema、血缘邻居、共同消费者和历史联查关系；硬过滤先剔除无权限、已下架、关键质量失败、负责人失联的资产；重排序再综合语义相关性、质量、热度、成本和复用证据。
diff
RecommendScore =
0.35·Semantic
+ 0.20·Schema
+ 0.15·CoUsage
+ 0.15·Lineage
+ 0.15·Trust
治理约束要放在排序之前，避免把"相似但不可信"的资产推给用户。推荐结果必须解释原因。比如"字段重合 82%""同属客户域数据产品""被 12 个同类报表使用""质量规则连续 30 天通过""当前资产的认证替代版本"。没有解释的推荐，会让数据消费者把平台当成黑盒搜索引擎。
九、事件驱动架构
数据资产运营不应该把所有逻辑塞进元数据仓库。更稳妥的架构是：元数据图保存实体、关系和稳定属性；事件总线接收访问、质量、成本、血缘和生命周期事件；特征服务按时间窗口聚合；评分服务输出带版本的分数和解释。
最小存储模型可以包含五张表：
| 表 | 用途 | 关键字段 |
|---|---|---|
| asset_snapshot | 保存资产当前状态 | asset_id, domain, owners, lifecycle, version |
| asset_event | 保存不可变事件 | event_id, asset_id, event_type, actor, event_time, payload |
| asset_feature_daily | 保存日粒度特征 | users_30d, queries_30d, quality, cost, incidents |
| asset_score | 保存评分与解释 | score_type, score, feature_window, model_version, reasons |
| lifecycle_decision | 保存下架与恢复审计 | from_state, to_state, approvers, impact, alternative |
评分表不要只保存最终分数。至少要保存特征窗口、模型版本、权重版本、主要贡献因子和决策理由。否则当业务质疑"为什么这张表被推荐/下架"时，平台无法解释。
十、落地路径
第一阶段先解决身份和责任。统一资产 ID，建立业务域，补齐业务所有者、技术所有者和数据管家，把质量失败、口径变更、下架申请路由到具体角色。
第二阶段接入运营信号。采集访问日志、报表调用、任务依赖、质量结果、成本账单和事故记录，形成热度、质量、成本、风险等可解释子分。
第三阶段进入真实决策。上线复用推荐、下架候选、高价值资产保障和治理看板，让资产评分参与搜索排序、SLA 分级、成本优化和重复建设治理。
第四阶段引入反馈学习。推荐被采纳、资产被投诉、下架被撤回、质量豁免被批准，都应成为新的事件，用来调整权重和规则。
起步时不建议一上来覆盖全公司。更好的方式是选择一个业务域，挑选 50 到 200 个稳定资产，用 8 到 12 周历史访问和质量数据回放评分，再邀请生产者与消费者核对前 20 名和后 20 名。模型先被业务认可，再进入自动化流程。