2. 数据资产盘点与分类：如何建立数据资产目录？数据分类分级标准
数据治理这件事，说白了第一步就是搞清楚你手里到底有什么数据。我见过太多团队一上来就搞数据质量、搞血缘分析，结果连自己有哪些表、哪些字段、哪些文件都说不清楚。嗯，这就像你要整理房间，却连衣柜里有什么衣服都不知道——那还整理个啥？
这一章我们就来聊聊数据资产盘点和分类分级。我个人习惯把这一步叫做“数据家底清查”，它是一切成本优化的起点。
2.1 数据资产目录：你的数据“户口本”
数据资产目录，说白了就是给每份数据上个“户口”。它记录数据的来源、格式、负责人、存储位置、访问频率、敏感等级等等。有了这个目录，你才能知道哪些数据该优化、哪些数据该保护。
核心观点：没有数据资产目录的成本优化，就像蒙着眼睛开车——你根本不知道油门踩下去会撞到什么。
2.1.1 目录应该包含哪些字段？
我建议至少包含以下核心字段。你可以根据企业情况增减，但这几项是底线：
| 字段类别 | 字段名称 | 说明 |
|---|---|---|
| 基础信息 | 数据资产ID | 全局唯一标识，建议用UUID |
| 基础信息 | 数据名称 | 业务名称，如“用户订单表” |
| 基础信息 | 数据格式 | 结构化/半结构化/非结构化 |
| 存储信息 | 存储位置 | 数据库名/文件路径/对象存储桶 |
| 存储信息 | 存储引擎 | MySQL / HDFS / S3 / HBase |
| 存储信息 | 数据量级 | 记录数或存储大小（GB/TB） |
| 访问信息 | 访问频率 | 每秒/每分钟/每小时/每天/每周 |
| 访问信息 | 最近访问时间 | 最后一条查询或写入的时间戳 |
| 安全信息 | 敏感等级 | L1~L4 或 公开/内部/敏感/绝密 |
| 安全信息 | 数据负责人 | 谁对这个数据资产负责 |
我的经验：我曾经帮一家金融客户做数据盘点，发现他们光“用户信息”就有7个不同版本的表，分布在3个不同的数据库里。原因就是没有统一的数据资产目录，各业务线各自为政。最后我们花了2周时间清理冗余，直接节省了40%的存储成本。
2.1.2 如何自动化构建目录？
手动录入？别闹了。几百张表、几万个文件，手录到猴年马月去。我建议用自动化工具扫描元数据。下面是一个简单的Python脚本思路，你可以根据实际环境改造：
# 伪代码示例：扫描MySQL元数据构建资产目录
import pymysql
import json
def scan_mysql_tables(host, user, password, database):
conn = pymysql.connect(host=host, user=user, password=password, database=database)
cursor = conn.cursor()
# 获取所有表
cursor.execute("SELECT TABLE_NAME, TABLE_ROWS, DATA_LENGTH, CREATE_TIME FROM information_schema.TABLES WHERE TABLE_SCHEMA = %s", (database,))
tables = cursor.fetchall()
assets = []
for table in tables:
asset = {
"asset_id": f"mysql_{database}_{table[0]}",
"name": table[0],
"format": "structured",
"location": f"{host}/{database}/{table[0]}",
"engine": "MySQL",
"row_count": table[1],
"size_bytes": table[2],
"created_at": str(table[3]),
"sensitivity": "unknown", # 需要后续分级
"owner": "unknown"
}
assets.append(asset)
return assets
# 输出为JSON，后续导入目录系统
assets = scan_mysql_tables("192.168.1.100", "admin", "pass123", "order_db")
with open("data_assets.json", "w") as f:
json.dump(assets, f, indent=2)
注意：自动化扫描只能获取技术元数据。业务元数据（如数据含义、负责人、敏感等级）通常需要人工补充。我曾经见过一个团队完全依赖自动化，结果目录里全是“unknown”，最后还是得人工填一遍——白费功夫。
2.2 数据分类分级标准：给数据贴上“价签”
有了目录，下一步就是分类分级。为什么要做这个？你想想看，如果你把所有数据都当成宝贝一样存着，那成本肯定爆炸。只有区分出哪些是黄金、哪些是石头，你才能把资源花在刀刃上。
我个人习惯把分类分级分成两个维度：安全维度（敏感数据分级）和成本维度（热/温/冷数据分类）。
2.2.1 敏感数据分级（安全维度）
敏感数据分级，说白了就是判断数据泄露了会造成多大损失。我建议采用四级标准，参考GDPR和等保2.0的要求：
| 等级 | 名称 | 定义 | 示例 | 存储要求 |
|---|---|---|---|---|
| L1 | 公开 | 泄露无影响 | 产品目录、新闻稿 | 无特殊要求 |
| L2 | 内部 | 泄露有轻微影响 | 内部报表、会议纪要 | 访问控制 |
| L3 | 敏感 | 泄露有较大影响 | 用户手机号、邮箱 | 加密存储 + 脱敏展示 |
| L4 | 绝密 | 泄露有灾难性影响 | 身份证号、银行卡号、密码 | 加密存储 + 审计日志 + 最小权限 |
避坑指南：我曾经见过一家公司把所有数据都标成L4，结果导致业务部门根本没法正常使用数据，最后大家干脆绕过数据平台自己搞——安全是安全了，但数据治理彻底崩了。分级要合理，别矫枉过正。
2.2.2 热/温/冷数据分类（成本维度）
这个维度直接关系到成本优化。你想想看，一个三年前的历史订单，可能一年都没人查一次，你却把它放在SSD上——这不是烧钱是什么？
我一般按访问频率和时效性来分：
| 类别 | 访问频率 | 时效性 | 推荐存储 | 成本对比 |
|---|---|---|---|---|
| 热数据 | 每秒/每分钟 | 近7天 | SSD / 内存 | 高 |
| 温数据 | 每小时/每天 | 近30天~90天 | HDD / 标准对象存储 | 中 |
| 冷数据 | 每周/每月/更少 | 90天以上 | 归档存储 / 磁带 | 低 |
我的经验：有一次帮一家电商公司做成本优化，发现他们90%的查询都集中在最近30天的订单上，但所有历史数据都放在同一个SSD集群里。我们把超过90天的订单迁移到归档存储，存储成本直接降了70%。而且因为冷数据查询极少，用户根本感觉不到延迟变化。
2.3 数据资产盘点的核心流程
光有标准还不够，你得有一套可执行的流程。我总结了一个四步法，你可以直接拿去用：
- 扫描发现：用自动化工具扫描所有数据源，生成原始资产清单。
- 人工标注：业务负责人补充业务元数据，包括数据含义、敏感等级、生命周期。
- 分类打标：根据敏感分级和冷热分类标准，给每条资产打上标签。
- 持续更新：建立变更监听机制，新数据源自动注册，旧数据源定期复核。
下面这张图展示了整个流程的逻辑关系：
2.4 落地时常见的坑
理论说完了，聊聊实战中我踩过的坑。嗯，这些教训都是用真金白银换来的。
- 坑一：分类标准太细，执行不下去。我曾经设计过一个包含20多个维度的分类体系，结果业务部门根本填不完。最后简化到5个核心维度，反而执行得很好。记住：能落地的标准才是好标准。
- 坑二：只做一次盘点，后续不管了。数据是活的，今天的热数据明天可能就变冷了。我建议至少每季度复核一次冷热分类，每半年复核一次敏感分级。
- 坑三：忽略非结构化数据。很多团队只盘数据库表，忽略了日志文件、图片、文档。这些非结构化数据往往占存储的大头，而且很多都是冷数据——恰恰是成本优化的金矿。
特别提醒：数据资产目录不是一次性的项目，而是一个持续运营的机制。我见过最成功的案例，是把目录维护纳入了数据负责人的KPI，每个月更新一次，每季度做一次全量复核。这样目录才不会变成“僵尸目录”。
2.5 小结：从盘点开始，为成本优化铺路
数据资产盘点和分类分级，听起来像是基础工作，没什么技术含量。但恰恰是这一步，决定了后续所有成本优化动作的成败。你想想看，如果你连自己有哪些数据、哪些是敏感的、哪些是冷的都不知道，你怎么可能做出有效的优化决策？