数据如何分类分级

数据分类分级，是数据治理中最基础的一项工作，也是最容易被做成形式化工作的一项内容。

在很多数据治理项目中，分类分级通常从数据盘点开始。项目组梳理系统、数据库、数据表和字段，再按照既定的数据目录和等级规则逐项标注，最后形成一张规模庞大的分类分级清单。

从结果上看，企业似乎已经知道哪些属于客户数据、哪些属于生产数据，哪些是一般数据、哪些是重要数据，甚至能够统计不同等级的数据分别有多少条。

但问题在于，如果分类分级最终只是给数据增加两个标签——“属于哪一类”“属于哪一级”——那么它与真正的数据治理之间仍然存在很大的距离。

因为企业真正需要解决的并不是“这个字段应该贴什么标签”，而是更现实的一组问题：企业究竟拥有哪些数据？这些数据对应什么业务对象？它们为什么重要？一旦发生错误、泄露、丢失或者不当使用，会产生什么影响？不同类型、不同等级的数据，又应该采取什么样的质量、安全、共享和使用控制？

因此，数据分类分级的本质，不是给数据贴标签，而是在数据对象与治理规则之间建立映射关系。

一、数据分类首先解决的，是企业如何认识自己的数据

企业中的数据并不是天然有序存在的。

同一个业务对象可能分布在多个系统中，同一种数据也可能分别存在于数据库、接口、文件、数据仓库、数据湖以及各种数据产品之中。

如果直接从系统和数据库开始分类，很容易得到一套技术目录，却未必能够形成真正统一的数据认知。

例如“客户”这个业务对象，可能同时存在于 CRM 系统、营销系统、订单系统、客服系统和数据仓库中。如果按照系统划分，就可能出现：CRM 客户数据、营销客户数据、订单客户数据、客服客户数据。

从系统管理角度看，这样的分类没有问题。但从企业数据治理角度看，一个更基础的问题仍然没有解决：这些数据描述的其实是不是同一个“客户”？

因此，数据分类不能从数据库结构出发，而应首先从业务结构出发。一个比较合理的分类逻辑是：

业务领域 → 业务对象 → 数据主题 → 数据类别 → 数据项

例如，在销售业务领域中，可以进一步识别客户、产品、订单、合同等核心业务对象。围绕“客户”这一对象，又可以继续形成客户基本信息、客户身份信息、客户联系信息、客户交易信息、客户行为信息等不同数据主题和类别。再继续向下，才会落到客户姓名、证件号码、联系电话、客户编号等具体数据项。

因此，分类首先建立的并不是数据库目录，而是企业数据的业务语义结构。它让分布在不同系统中的数据能够重新回到统一的业务对象体系中。

二、业务分类最终必须映射到真实的数据载体

只建立业务分类目录还不够。数据治理最终必须能够作用于真实的数据。

因此，业务对象、数据主题和数据项，还需要继续向底层系统进行映射。例如：

客户 → 客户身份信息 → 证件号码 → CRM 系统 → customer_info 表 → id_number 字段

这样才真正建立起业务对象—业务数据项—物理数据之间的对应关系。

这一步非常重要。因为业务分类解决的是“企业怎么看待这项数据”，而真正的数据权限、质量检查、脱敏、加密和访问控制，最终都要作用于具体的数据库字段、接口字段、文件或者数据集。

因此，一套完整的数据分类体系实际上存在两个视角。一个是业务认知视角：业务领域 → 业务对象 → 数据主题 → 数据项。另一个是技术执行视角：系统 → 数据库 → 表 → 字段。

二者并不是两套独立体系，而应该通过数据项映射连接起来。

业务对象 → 业务数据项 → 物理字段

只有建立这种映射，企业才能既知道数据“是什么意思”，也知道数据“究竟在哪里”。

三、分类分级必须先确定颗粒度

分类分级真正进入实施以后，会立即遇到一个非常现实的问题：究竟以什么为最小单元开展分类分级？是系统、数据库、数据表，还是字段？这是分类分级能否真正落地的关键问题。

如果颗粒度过粗，例如直接把一个系统整体认定为某一等级，那么就无法识别系统内部不同数据之间的差异。但如果颗粒度过细，又可能产生巨大的维护成本。

因此，分类分级需要区分两个概念：业务认知颗粒度与治理执行颗粒度。

在业务层面，分类应该从业务对象逐层细化到业务数据项。而在结构化数据环境中，真正开展分类分级时，通常应当以字段作为最小执行颗粒度。更准确地说，是以能够被独立识别和独立控制的最小业务数据项作为基本治理单元。

之所以需要做到字段级，是因为同一张表内部的数据可能具有完全不同的属性。

如果直接把整张表作为最小分级单位，那么这些差异就会被抹平。因此，更合理的过程应该是：先对字段分类，再对字段分级。

字段级分类分级结果，构成整个分类分级体系最基础的判定结果。

四、分类和分级的颗粒度逻辑并不完全相同

这里还需要进一步区分分类与分级。分类解决的是“里面是什么”。因此，一张表完全可能同时包含多个数据类别。

例如客户信息表中，可能同时包含客户基本信息、身份信息、联系信息和状态信息。所以从分类角度看，一张表不一定只能属于一个最细分类。更加合理的表达是：这张表属于“客户数据”这一较高层级主题，同时包含多个下级数据类别。

也就是说，分类向上汇聚强调的是业务归属和组成关系。

而分级不同。分级解决的是“这张表整体应该以多高的强度进行控制”。由于数据访问和数据处理经常以整张表为单位，因此只要一张表中包含高等级字段，就存在访问整张表时同时接触高等级数据的可能。

所以，在表级控制上通常应采取“就高原则”。也就是说，表的治理等级原则上根据表内字段的最高等级确定。

例如一张表中有 20 个字段：17 个字段为一级，2 个字段为二级，1 个字段为三级。那么这张表在整体访问、传输、备份、开发测试和权限管理等方面，原则上就应该按照三级数据所要求的控制强度执行。

字段等级 L1、L1、L2、L1、L3…… → 表级控制等级 Max（字段等级） → 按照 L3 控制要求管理整张表

五、字段决定表的控制等级，但并不改变其他字段自身的等级

这里有一个非常容易混淆的问题。

当一张表因为包含一个高等级字段，而按照最高等级进行整体控制时，并不意味着表内所有字段都自动变成了高等级数据。

例如，某个身份证号码字段为三级。由于该字段存在，这张表整体需要按照三级要求进行权限控制和安全管理。但表中的 create_time 字段，仍然可以保持其自身原有的一级数据属性。

因此必须区分两个概念：数据自身等级和数据载体的控制等级。

数据自身等级回答：这一项数据本身是什么等级？数据载体控制等级回答：承载这些数据的表、数据集、数据库或者系统，需要具备什么等级的保护能力？

二者不能混为一谈。否则就容易出现一种错误：只要某个系统存在少量高等级数据，就把系统中全部数据重新定义成高等级数据。这不仅会造成分类分级结果失真，也会导致治理成本不必要地扩大。

六、等级需要从字段逐级向上形成治理基线

字段级完成分级以后，还需要继续解决表、数据集、数据库和系统层面的治理问题。

因此，可以建立一个等级向上传递机制：

字段 → 表 → 数据集 → 数据库 → 系统

其中，字段是基础判断单元。表级通常依据所包含字段中的最高等级确定整体控制要求。由多张表组合形成的数据集，也需要根据其中高等级数据确定整体治理基线。数据库和系统则需要具备承载相应等级数据所要求的安全、权限、审计、备份和运维能力。

因此，一个更加准确的逻辑不是字段等级逐级把所有上层对象“变成”高等级数据，而是字段级数据属性向上形成载体级控制基线。

这一点对于真正的数据治理实施非常重要。它意味着分类分级不仅要形成字段标签，还需要形成一套字段等级—表级控制—系统能力之间的映射关系。这时，分类分级结果才真正可以进入技术实施。

七、数据分级的本质，是判断数据失控以后会造成什么影响

确定了分级颗粒度之后，才进入真正的等级判断。

数据分级最本质的问题其实是：如果这项数据发生问题，会产生多大的影响？

这里所谓的数据问题，不应只理解为泄露。数据可能出现泄露、篡改、错误、丢失、越权访问、不当共享以及不当使用。

不同数据发生问题以后，造成的影响并不相同。例如普通设备运行参数发生一定误差，可能只是影响某个分析页面。但如果同样的数据进入安全预警模型，并进一步影响设备停机或者自动控制，那么数据错误造成的业务后果就可能显著提高。

因此，数据等级不能只根据数据名称或数据内容进行静态判断。一个更加完整的判断逻辑应该是：

数据属性 × 业务重要性 × 使用场景 × 影响后果 → 数据等级

这意味着，分级至少要回答四个问题：数据本身是否敏感？它是否支撑关键业务？它正在被用于什么场景？如果发生问题，影响范围和严重程度有多大？

八、数据等级既要看风险，也要看价值

实际项目中，数据分级很容易被等同于数据安全分级。于是，判断某项数据等级时，主要看是否涉及个人信息，是否涉及商业秘密，是否属于敏感数据。这些因素当然重要。

但对于完整的数据治理而言，这还不够。因为有些数据虽然并不高度敏感，却可能对企业运行具有非常高的重要性。

例如关键生产参数、核心设备状态、经营核算口径、监管报送数据、关键算法模型输入等。这些数据即使没有任何泄露风险，只要发生错误、缺失或者无法及时获得，也可能直接影响生产、经营和决策。

因此，数据分级至少需要同时考虑两个方向：风险程度和业务价值。风险回答的是数据失控以后会造成多大的负面影响，价值回答的是企业对这份数据有多强的依赖。

九、数据等级不是永久不变的标签

数据分类通常具有一定稳定性。客户手机号长期仍然属于客户联系信息。但数据等级并不一定永远不变。

因为数据等级不仅受数据自身属性影响，也受到使用场景影响。

例如一个普通设备参数，在单独用于趋势分析时可能等级并不高。但当它进一步成为安全预警模型、生产调度系统或者自动控制系统的关键输入以后，其业务重要性就发生了变化。

再例如，一份已经脱敏处理的数据，在企业内部统计分析时风险较低，但如果进入跨组织共享或者公开发布场景，其风险边界也可能发生改变。

因此，可以建立“基础等级 + 场景校正”的机制。首先根据数据自身属性和基础业务重要性形成数据的基础等级，然后在数据进入新的加工、组合、共享和使用场景时，根据实际影响进行重新评估。

十、分类分级最终必须转化为差异化治理

完成分类分级，并不意味着工作结束。事实上，到这里分类分级才刚刚真正进入治理阶段。

因为分类分级最终必须回答：不同等级的数据究竟应该怎样管理？

如果一级数据和三级数据采用完全相同的数据采集方式、质量标准、访问权限、共享审批和审计要求，那么分类分级本身就没有产生实际治理价值。

因此，需要进一步建立“数据分类 + 数据等级 → 治理规则”之间的映射。

例如，在数据采集阶段，高等级数据可以配置更严格的来源校验和完整性验证；在数据质量环节，可以设置更高的质量门槛和更严格的问题闭环要求；在数据存储环节，可以实施更严格的权限、隔离、加密和备份要求；在数据加工过程中，可以加强版本控制、过程留痕和变更审计；在数据共享环节，则可以配置更加严格的授权、脱敏、审批和使用范围约束。

于是，分类分级结果开始进入采集、存储、加工、质量、共享、使用、归档和销毁全过程。

十一、分类分级应当成为持续运行的治理机制

很多分类分级项目最终的问题在于：完成一次盘点以后，结果长期不再更新。

但企业的数据环境并不是静态的。新的系统持续建设，新的字段不断产生，数据持续发生加工和组合，新的数据产品不断形成，数据共享范围也不断扩大。

因此，分类分级必须嵌入数据全生命周期。

当新数据产生时，需要确定分类和基础等级；当数据模型发生变化时，需要重新判断字段和表的结构；当高等级字段进入新的表或者数据集时，上层载体的控制等级需要重新计算；当数据用途发生变化时，需要重新判断场景风险；当数据对外共享时，也需要重新审视其使用边界。

所以，一个完整的分类分级过程应该形成持续闭环：

业务识别 → 对象识别 → 数据分类 → 字段映射 → 字段分级 → 等级汇聚 → 规则配置 → 过程控制 → 监测反馈 → 动态调整

分类分级由此不再是一项一次性项目，而成为数据治理体系中持续运行的一项基础能力。

不同等级的数据在采集、存储、加工、质量、共享、使用和归档销毁环节接受差异化控制，并通过监测反馈持续优化。

十二、数据分类分级，本质上是在建立“对象—等级—规则”的映射

回到整个数据治理体系来看，分类分级真正解决的是一个非常基础的问题：企业拥有大量数据，但不同的治理规则到底应该作用于哪些数据？

分类告诉企业治理对象是谁；分级告诉企业治理强度应该多高；颗粒度告诉企业治理应该精确到哪里；而规则配置进一步告诉企业具体应该如何治理。

因此，可以形成一条完整链路：

业务对象 → 数据分类 → 业务数据项 → 物理字段 → 字段等级 → 表 / 数据集 / 系统控制等级 → 治理规则 → 过程控制 → 数据应用

这实际上就是数据分类分级在整个数据治理体系中的真正位置。

它不是一个孤立的标签管理模块，而是连接数据认知与数据控制的中间机制。

结语

企业最终需要治理的，不是数据库中的几千张表或者几百万个字段，而是一组不断伴随业务活动产生、加工、流转和使用的数据对象。

因此，成熟的数据分类分级体系，也不能停留在“字段 → 分类标签 → 等级标签”这一层面。

更加完整的逻辑应该是：从业务对象出发认识数据，从业务数据项映射到物理字段，以字段作为基本执行颗粒度完成分类分级，按照高等级数据向上形成表、数据集和系统的控制基线，再将不同等级映射为质量、安全、权限、共享、审计和生命周期规则。

业务对象 → 数据分类 → 数据项 → 字段分级 → 等级汇聚 → 治理规则 → 过程控制 → 持续演化

分类分级最终的目标，不是让所有数据都拥有一个标签，而是让不同的数据，根据自身业务身份、价值、风险和使用场景，在整个生命周期中接受与其相匹配的治理。这才是数据分类分级真正的意义。