一、数据资产热度分析概述

各位同学好，我是老赵。在数据平台这个行当摸爬滚打了十几年，今天咱们来聊聊一个特别实在的话题——数据资产热度分析。

说白了，就是搞清楚你的数据资产里，哪些是宝贝，哪些是鸡肋。我见过太多团队，辛辛苦苦建了一堆表、跑了一堆任务，结果半年后一问，没人用、没人管、甚至没人知道。嗯，这其实就是我们今天要解决的问题。

1.1 什么是数据资产热度

先给个定义。数据资产热度，指的是数据资产被访问、使用、消费的频率和深度。它不是一个简单的计数器，而是一个综合指标。

我习惯把它拆成三个维度来看：

• 访问频率：这张表一天被查多少次？这个接口被调用了多少回？
• 使用广度：有多少个下游任务依赖它？覆盖了多少个业务部门？
• 消费深度：是简单看一眼，还是做了复杂的ETL？是临时查询，还是核心报表？

举个例子。你有个用户行为日志表，每天被20个数据管道引用，支撑着3个核心报表，还有5个分析师天天跑SQL查它。那这张表的热度就很高。反过来，一张半年前建的临时表，没人知道它的存在，那就是零热度资产。

1.2 为什么需要分析热度

你可能会问，我费这劲干嘛？数据存着不就行了？

说实话，我以前也这么想。直到有一次，我接手一个数据平台，光Hive表就有8000多张，但真正每天被使用的不到300张。剩下的7700张表，占着存储、耗着计算、还让新人找数据时一头雾水。

那次之后，我彻底明白了。分析热度，至少能解决三个核心问题：

1. 降本增效：冷数据该归档归档，该删除删除。存储和计算资源不是大风刮来的。
2. 治理驱动：知道哪些资产没人用，才能推动数据治理。没人用的表，要么是质量差，要么是没人知道它的存在。
3. 价值证明：给老板汇报时，你能拿出数据说：“我们平台每天支撑了XX次查询，服务了XX个业务场景。” 这比空谈数据战略有用得多。

1.3 核心应用场景

热度分析不是花架子，它有很多实打实的应用场景。我挑几个最常见的说说。

场景	说明	我踩过的坑
冷热数据分层	根据热度，把数据放到不同的存储层。热数据放SSD，温数据放HDD，冷数据放对象存储或归档。	曾经一刀切，把“30天未访问”的都算冷数据。结果业务方说有些表是季度报表，每季度才跑一次。后来加了时间窗口和业务标签。
数据资产目录优化	热度高的资产，在数据目录里置顶、加标签、写详细文档。热度低的，标记为“待治理”。	有次把一张核心表的热度算低了，因为它的访问是通过API走的，没记入Hive日志。后来我把API调用也纳入了热度计算。
资源预算分配	热度高的任务，优先分配计算资源。热度低的任务，可以放到低峰期跑，甚至降级。	这个比较顺利，但要注意：有些任务虽然热度低，但SLA要求高（比如月报）。不能只看热度，还要看业务等级。
数据安全与合规	高热度资产往往包含敏感数据，需要重点保护。低热度资产如果包含PII，也要定期清理。	这个场景我做得不够好。早期只关注了热度，没关注敏感度。后来出了个内部审计问题，才把两者结合起来。

你看，热度分析不是孤立的技术活，它跟成本、治理、安全都挂钩。说白了，它是数据平台精细化运营的起点。

1.4 热度分析的整体框架

为了让你有个全局观，我画了一张图。这张图展示了热度分析从数据采集到最终应用的完整链路。

这张图你看懂了吗？我简单解释一下。

最上面是三层核心处理：先采集日志，再算指标，最后打评分。中间是存储层，把热度数据存起来供下游使用。下面是四个应用场景，它们不是孤立的，而是互相影响的。最底下还有个反馈闭环——你用了热度数据之后，发现模型不准，那就回来调整指标权重，重新算一遍。

1.5 一个小例子：热度等级划分

最后，我分享一个我在项目中实际用过的热度等级划分方法。不一定适合所有场景，但可以给你参考。

-- 假设我们有一张表的使用统计
-- 热度等级：热、温、冷、冰

WITH usage_stats AS (
  SELECT
    table_name,
    COUNT(DISTINCT query_id) AS query_count,      -- 查询次数
    COUNT(DISTINCT user_id) AS user_count,         -- 用户数
    COUNT(DISTINCT downstream_task) AS task_count  -- 下游任务数
  FROM usage_log
  WHERE dt >= '2024-01-01'
  GROUP BY table_name
)
SELECT
  table_name,
  query_count,
  user_count,
  task_count,
  CASE
    WHEN query_count > 1000 AND user_count > 10 THEN '热'
    WHEN query_count > 100  AND user_count > 3  THEN '温'
    WHEN query_count > 10   AND user_count > 0  THEN '冷'
    ELSE '冰'
  END AS heat_level
FROM usage_stats
ORDER BY query_count DESC;

这个SQL很简单，但很实用。我当年就是靠这个脚本，第一次摸清了平台的数据家底。结果发现，40%的表是“冰”级别的——半年没人碰过。嗯，那批表后来该删的删，该归档的归档。