数据中台-标签建设-标签层设计

前言

中台：贴源 - 数仓 - 标签 - 应用

标签层：对象-标识-标签层次-标签设计-标签汇集表

标签设计

通过标签类目设计，已经有了某类对象的标签体系框架，只是还没有具体的标签内容。标签设计就是设计合适的标签并将其挂载到标签类目。

前面介绍标签按照产生和计算方式的不同可以分为属性标签、统计标签、算法标签，每一类标签深挖下去，都可以有无数个。这里探讨什么样的标签才是需要的、有什么原则以及注意事项。

标签本质上是一种对客观世界中实体对象的度量或描述，是经过缜密的逻辑分析和处理后的产物，用以引导发挥数据应用价值。数据必须转化成能帮助业务提升的标签才具有价值，否则就是数据负累。因此大数据业内一直尝试探索的最核心环节就是数据的商业变现，或者叫数据到商机价值之间的桥梁通道建设。

标签即业务需求的数据呈现，商业价值核心承载在标签上，再配以相应的工程化能力，将标签快速、稳定、便捷地输送到业务以供使用，即完成了数据服务过程。

将数据提炼转化为标签的过程就叫标签化，也就是标签设计过程。一个好的标签设计，等于已经完成了好的数据服务50%的工作，标签设计考验的是理解、抽象、提炼、提升业务场景的数据能力。标签设计要充分考虑两大前提条件。

1）标签必须是业务上需要的，能体现业务价值，帮助业务人员做出业务判断或者能创造性的地唤醒新业务场景的数据项，在业务中往往会称其为属性、特征、指标、参数等。

2）必须要探查清楚根据业务需求提炼、整理出的标签是否具有数据可行性，是否有原始数据可以用于加工成标签，不能天马行空，没有落地点。

在分析业务需求，设计出初始业务所需标签的基础上，要进行数据可行性分析，剔除没有数据支撑的标签，这是一个筛减调整的过程。数据可行性的判断需要了解数据源有哪些，了解数据普查信息及数据字典信息，充分利用数据设计丰富的标签以保障标签的落地可行性。更多：用户画像-标签体系（dwt层）

了解了标签设计的两个前提条件，就可以着手设计满足条件的标签了。标签的设计是业务需求与经验结合的结晶，是一个漫长的持续迭代的过程，没有一个具体的步骤可以快速构建。

提到标签，有一些容易混淆的概念，比如标签类目和标签、标签与标签值。标签设计的内容不仅包括标签名，还要有归属标签类目、计算逻辑、取值范围、安全等级等。

另外标签设计也有一些必须关注的事项。厘清标签设计容易混淆的一些概念、设计所包含的内容及注意事项，有助于设计出更规范化、体系化、可扩展的标签体系。

1.标签根目录、标签类目、标签和标签值

标签根目录指的是标签的对象，往往是一种较为模糊、宽泛、简单的名词或动词，例如购房者、旅游酒店、报修。按照之前提到的大数据思维，世上的一切事物都可以归类为人、物、场景三类对象，因此一个用来指向某个对象的词（名词指向人、物，动词指向场景）都不应该是标签，往往是根目录。在物理层面可以和某张大宽表中的主键对应，这张大宽表是对该主键对象的详细刻画和数据记录。

对对象的拆分及对象的角度、层面或过程，一般是类目，例如基本信息、地理位置、社交关系、功能效用、从属关系、准备、过程、结果等，也往往由名词构成。在物理层面可以和某张具体表对应，多张这样的具体表按照共同的主键关联在一起就可以形成该主键对象的大宽表。对对象具体属性、特征、信息、内容的字段级刻画，是标签，例如购房者姓名、购房者电话、旅游酒店地址、报修工单号、报修时间，往往由前后两个名词构成，前一次名词作为定语修饰后一个名词。

在物理层面可以和某张具体表中的字段对应，因此最近1天报修工单量、最近3天报修工单量、最近7天报修工单量，这些时间维度不同、统计方式和统计对象相同的标签，属于3个标签，因为它的底层由3个字段一一对应。对对象属性、特征、信息、内容的具体取值，是标签值，例如张三、李四是购房者名称这个标签的标签值，男、女是性别这个标签的标签值，往往由形容词、名词、数字组成。在物理层面可以和某张具体表中的字段值字典对应，标签值有些是可枚举的离散值，有些是不可枚举的连续值。

要特别注意的是，往常习惯给别人打标签、贴标签的动作，其实不是在设计标签，而是在设计标签值。例如对某个人的定义“女、20～30岁、白领、活泼开朗”，分别是性别、年龄段、职业、性格标签的具体标签值。

在标签设计实际过程中，经常会碰到的问题是，同一个标签是否能够多挂，即一个标签是否会属于多个叶子类目。

在标签体系方法论中，没有严格规定允许还是不允许多挂，方法论的最核心思维是必须结合企业自身需要来设计组织标签类目体系。因此一家企业如果按照自身需要用严格不冗余的做法来组织安排标签分类的话，就不能多挂。如果企业没有严格要求，为了最大限度帮助业务同事用数据的方式理解事物，或在所需场景中找到所需数据，或根据现有数据激发新场景思考设计，则在必要时可以多挂，但这并不意味着所有可以多挂的标签都要多挂，因为那样会引起冗余问题。

一般情况下，如果是个别标签具备多种类目归属，是可以多挂的；但是如果是一整片大批量标签都有多重属性，建议单独成立一个类目。总而言之，视企业具体情况而定，做好平衡即可。

2.标签设计内容

标签的标签，即元标签的设计内容主要包括标签类目、标签名、标签加工类型、标签逻辑、值字典、取值类型、示例、更新周期、安全等级、表名、字段名、负责人、完成时间等。其中“标签类目、标签名、标签加工类型、标签逻辑、值字典、取值类型、示例、更新周期、安全等级”偏向业务方向，主要登记与业务所需相关的指标；“表名、字段名、负责人、完成时间”偏向技术方向，主要登记的技术开发实施过程相关的指标。

3.标签设计注意事项

1）某具体对象某标签的标签值，只允许有一条记录，即对应在数据表里，是一个字段取值。例如人的某个标签的标签值，在用户表里就一个值一条记录，不存在多条记录，人有“性别”这个标签，每个人的“性别”取值就一个，要么男，要么女，要么未知，不存在男、女两条取值记录。

性别标签容易理解，再举一个复杂一些的例子——“同住时长”标签。该标签可能是人的标签，也有可能是同住关系的标签。如果“同住时长”是人的标签，那么标签取值类型应该是K-V型，记录的是历次同住人同住时长，标签值如“张三：2年；李四：1年”。不允许出现两条标签取值的记录，如“2年”和“1年”，因为标签和标签之间是相互独立的，不存在一个标签必须依赖另一个标签才能使用的情况，因此不能说“同住时长”必须和“同住人”标签联合起来用。从这里也可以看出标签处理和SQL处理的区别。当然如果“同住时长”是同住关系的标签，那么每一次的同住关系记录，就会有一个“同住时长”的标签，这时候同住时长可以是数值型的标签。

2）对于人–物–关系各对象标签间的转化，大家可能会认为身份证号、证件号是“用户”的标签，但实际上身份证号、证件号是“物”的标签，要变成“用户”标签，需要转化成“拥有的身份证号”这个标签。同时，由于一个人可能拥有多个证件（身份证、护照、军官证、驾驶证等），因此“拥有的各证件号”就需要是K-V型，通过key来识别证件类型，其标签

值应为“身份证：330110********0001；护照：110*******001”，而不能直接存证件号码，否则通过“拥有的证件号”取到的号码数值没法区分是什么证件的号码。当然还有一种处理方式是拆成多个标签，如“拥有的护照号”“拥有的军官证号”“拥有的驾驶证号”。

从以上实例中可以发现，不管是物的标签还是关系的标签，都可以按需转化成人的标签，同理也可以实现其他对象类型间的标签转化。经过以上原则方法，可以设计出符合企业业务需要的标签体系。

由于企业的业务在不断变化，数据在不断变化，业务对标签的诉求以及标签的加工方式也在不断变化。所以标签体系建设不是一蹴而就的，而应是一个动态调整的过程。不断更新迭代标签体系，才能更好地支撑业务，更能体现数据价值。