【袋鼠云】标签系统
文章目录
- 客户画像标签建设的演进
-
- 1. 业务单元独立作战
- 2. 离线数仓统一建设
- 3. 实时数据多维补充
- 4. 标签产品化管理
- 5. 数据智能化管理
- 标签体系设计与加工
-
- 一、标签体系设计
-
- 1. 数据梳理
- 2. 基于OLP模型体系化梳理标签
- 3. 定义标签与加工口径
- 二、标签模型设计
- 三、标签配置
-
- 1. 根据业务对象，创建实体、关系
- 2. 读入原子标签
- 3. 创建衍生标签
- 4. 创建组合标签
- 5. 创建实时、算法标签
- 标签体系建设方法论
-
- 一、数字营销是数字化转型排头兵
- 二、标签体系建设方法论
-
- 标签体系建设三目标
-
- 目标一 解决业务问题
- 目标二 业务人员好用、易用
- 目标三 可持续更新迭代
- 标签体系建设五步法
-
- 第一步 明确建设目标
- 第二步 标签体系设计
- 第三步 标签加工与更新
- 第四步 标签生命周期管理
- 第五步 标签应用与回流
- 三、标签体系在某基金的建设案例
- 标签加工与更新
-
- 一、加工方式：传统 VS 在线
- 二、各类型标签加工
-
- 原子标签
- 规则标签
- 指标体系设计与加工
转载自知乎大佬
客户画像标签建设的演进
在数据应用场景中，从数据产品、数据开发、运营人员、营销人员、客服人员其实对“标签”都不陌生，比如给用户打上“性别”、“会员等级”、“收入水平”、“是否有老人、小孩”等标签，能够让我们在数据使用时，更加准确快速的定位到这个用户，辅助业务人员更准确、更快的确定自己的目标营销群组，优化其营销策略，加快业务迭代效率。
本次结合数仓建模的发展、标签建设的发展情况，一起来聊一聊标签建设的演进。
1. 业务单元独立作战
在这个阶段，还未出现数据中台这种统一存储以及计算的理念，基本是业务单元独立作战，数据一般存储在传统的关系型数据库中，建立一些基础的标签。如下图：
- 技术特点:
小数据量慢查询
- 数据存储：Oracle、MySQL等关系型数据库
- 标签计算：Oracle、MySQL等关系型数据库
- 标签查询：Oracle、MySQL等关系型数据库
- 业务特点：
此时，由于业务数据分管的独立性、存储的独立性，造成数据不能联动，标签体系不完善，标签对于业务的作用甚微，只能基础的去看一些标签内容，还处于基础标签建设阶段。
2. 离线数仓统一建设
随着数据建设进程的发展、数据量增大、以及数据技术的演进，此时出现MPP类的数据库进行数据存储与计算，如Greenplum、Vertica、GBase等数据库用于大数据量的计算。以及16年左右，阿里提的“大中台、小前台”，Hadoop逐渐成为主流趋势，数据统一存储计算，到18、19年左右数据中台的元年，OneData、OneModel理念下，此时标签的来源数据进行了统一，存储到统一的数据仓库中，标签的数据域变广，标签体系更加完善。
此时，标签的加工主要是离线计算，即“T+1”跑批，今天可用的标签是前一天的数据加工出来的，以及当日新建的标签一般当日不可用。且ES作为成熟的检索引擎，标签圈群的查询一般使用ElasticSearch，ES具有快速存储检索数据的特点，且相对稳定。
刚才提到ES作为常用的检索引擎，但其存在支持的数据规模小、不支持复杂的adhoc查询、高并发不理想等特点，后续随着Hadoop社区的蓬勃，Presto、Impala等只做查询不做存储的OLAP查询引擎逐渐应用在标签圈群、分析上面，能够实现大数据量的秒级查询。
同时在这个阶段会呈现出标签加工一般由数据开发写SQL完成，业务人员不参与标签的加工，且没有统一的标签管理界面的特点，无法进行标签生命周期的管理。业务人员更偏向基于已打好的标签，直接进行内容营销。
- 技术特点:
大数据量快查询一代
- 数据存储：MPP类数据库、Hive
- 标签计算：MPP、Spark
- 标签查询：ES、presto、Impala
- 业务特点:
- 由于数据统一存储、打通，标签体系更加完善；
- 离线标签加工为主；
- 解决了大数据量的标签计算问题；
- 标签加工通过数据开发SQL实现，不能进行标签生命周期管理；
3. 实时数据多维补充
在离线批处理成熟的情况下，实时数据企业也逐渐应用起来，可以基于实时数据，比如用户实时的行为数据、交易数据等，创建出来一些实时标签，是营销策略的发放更加及时，以及实时标签也可以引用到实时推荐场景中。
实时标签的计算跟随流计算技术的发展，从SparkStreaming到Flink流计算引擎，进行实时标签的加工，如基于用户实时的浏览、单击、购买等行为数据，计算一些实时标签。
- 技术特点:
大数据量快查询二代
- 数据存储：Hive 、Hbase
- 标签计算：Spark、Flink
- 标签查询：Presto、Impala、ES
- 业务特点:
- 离线标签为主，实时标签多维补充，标签体系更加全面，营销策略的发放时效更短；
4. 标签产品化管理
之前是基于数仓的建模，一般标签需求由业务方来提，标签的加工由数据部门的数据开发进行，最终加工出来基本是一张存储在数据库的标签宽表，没有可视化的界面供业务人员管理这些标签。业务人员通常标签圈群界面，圈选其目标人群，且针对圈选好的群组，分析也较少，不能多维分析群组，掌握群组特征。
基于在第二和第三阶段的沉淀、数据需求的蓬勃，市场上出现提供标签产品的大数据厂家，如阿里云的QuickAudience、神策的用户画像、袋鼠云的智能标签等产品，涵盖标签萃取、标签管理、标签圈群、群组细分、全面画像等全流程，提供标准化的产品服务，应用于企业的运营与营销。标准产品的出现能够解决没有大数据团队企业的标签生产与使用需求。
通过标签产品，可以实现：
- 标签加工产品化，大部分市场上的产品可支持规则类、SQL类的标签加工，业务人员也可参与到标签加工中，加快了标签建设速率，提升业务流转效率；
- 标签全生命周期管理，支持标签的上下线，流程审批等；
- 人群圈选，且基于圈选好的人群进行群组画像分析、对比分析、显著性分析、交并差计算等；
- 单个用户画像查看；
- 标签数据的统一对外服务；
- 与CDP平台对接，进行营销活动的推送等；
此阶段技术选型与之前差异不大，数据存储一般使用hive，计算使用Spark、Flink，查询使用Presto、Impala等。
5. 数据智能化管理
目前大部分企业的标签主要是离线标签，实时标签与算法（预测类）标签较少，一个是这类标签业务场景少，一个是有上手难度。后续随着企业常用标签的普及，少量的能够解决特定问题的标签也会逐渐普及、应用起来，以及标签分析会更加精细化。主要会包含以下几方面：
· 算法预测类标签的加工，如基于用户的基金交易行为，预测该用户属于追涨、杀跌、高抛等哪种类型的客户，分析客户的风险偏好；
· 基于机器学习模型的人群圈选、人群放大、人群分析等，如根据正负人群样本，得出该群组的影响特征，进行新的人群进化圈选；通过算法将人群特征向量化，利用K近邻等算法判断某用户是否属于目标人群，进行人群扩大； 以及利用分类算法实现RFM用户价值的评估。
· 离线标签、实时标签同时可在线圈选；
· 标签相似度计算、标签质量评估等；
随着数据湖的兴起，像Hudi、Iceberg等数据库可解决Hive2不能单列单行更新的问题、进行批流统一存储进行准实时计算、以及能够很好的兼容Spark、Flink、Presto等计算引擎，是一种新的标签加工、查询解决方案。
- 技术特点:
- 湖仓一体、统一查询
- 数据存储：Iceberg 、Hudi
- 标签计算：Spark、Flink
- 标签查询：Presto
- 业务特点:
- 机器学习模型集结合人为经验判断，让数据营销更加精准化；
- 标签分析维度更加精细、全面，更加准确的为业务场景提供判断；
最后再总结一下，标签业务发展与技术发展不同阶段的特点：
标签体系设计与加工
导读：
在企业的数字化进程中，标签体系的创建与使用在业务场景需求中经常用到，也基本是数据建设过程中必不可少的环节。一般有互联网基因的大公司，有专业的数据技术人才储备，会自己实现整个标签加工使用流程、技术选型等，也存在不具备相应人才的公司需要标准产品帮他们快速实现这个过程，无需再自己探索，B端的标准产品可以帮客户快速实现标签体系的搭建与标准化管理，解决业务问题。
本次我们一些项目交付经验，先来聊聊标签的设计与加工。
标签的建设与应用一般需要经过几个步骤
- 标签体系设计；
- 标签模型设计；
- 标签加工与更新；
- 标签应用；
一、标签体系设计
标签服务于业务应用场景，好的标签体系设计能够让业务人员在使用时随需随取，及时查询出需要的数据，就算不具备这个标签时，业务人员也可以自己快速加工出来，无需寻求数据开发的帮助。那需要做到（1）标签类目划分合理；（2）标签涵盖的数据源丰富，标签完善；（3）后续扩展性高，即基于基础标签加工出新的标签时，方便快速。标签体系的设计一般会按照以下步骤：
1. 数据梳理
根据现有业务背景，以及数据，梳理出大概的标签体系。如企业一般数据大概来源于这几部分：
- 用户基础数据：用户ID、性别、年龄、手机号、邮箱、身份证号、会员等级等基础信息；
- 业务交易数据：如在零售领域，用户发生的每一笔交易都会有记录，如下图：
- 用户行为数据：如用户在APP、PC、小程序等的浏览、点击、收藏、评论行为，可反映出用户的行为特点；
- 活动/积分数据：会员商城的cha会员等级、积分兑换等数据
- 售后投诉数据：客户投诉、售后处理等数据
基于对数据的梳理，可进行标签基本体系的梳理，梳理出一部分有价值的标签。
2. 基于OLP模型体系化梳理标签
OLP模型是目前比较通用的建立标签体系的模型，OLP指“实体-关系-属性”模型，用下方场景举例：
- 实体：指对象，如人、书籍、门店等，可针对每个实体建立一套标签体系；
- 属性：实体带的特征，如人有性别、年龄属性，书籍有价格、内容属性，门店有售卖渠道、地址位置等属性，属性是一种类型的标签；
- 关系：通过动作产生关系，如基于购买动作，人和书籍产生关系，基于这个动作可产生消费时段偏好、支付方式偏好等标签；
基于该模型，对标签进行查漏补缺，梳理出标签类目与标签。
3. 定义标签与加工口径
标签中文、英文名：标签的中文名称、英文名称；标签所属类目：标签所属一级、二级、三级类目；标签类型：根据不同维度的划分，采用其中一种。比如统计类标签、预测类标签、自定义标签等，亦或是原子标签、衍生标签、组合标签、算法标签等；标签值定义：定义每个标签的标签值，如“近一个月买入金额区间”标签，可根据购买金额的区间段定义“零/低端”、“普通”、“中端”、“准高端”、“高端”等标签值；标签含义（描述）：描述该标签业务含义，如“最近30天的购买商品的金额区间，对用户消费力进行评估”标签业务口径：标签以哪个数据定义为准，如“用户活跃城市”标签，以用户购买次数最多的城市为口径加工，而不是浏览次数、评论次数等；标签技术口径：描述该标签从哪个表的哪个字段取值，SQL取数逻辑是什么；业务方来源：该标签的业务需求方是谁；标签更新周期：描述标签更新频次，天(如T+1、T+2等)、周、月、小时、分钟更新等；标签更新优先级：同一时间端跑多个标签时，若资源有限，先跑优先级高的标签；
基于以上工作，最终得出一份标签体系表，以这份表和业务方最终确认标签划分、标签与标签值、标签加工口径是否有疑义，没问题，便可进入标签开发环节。
二、标签模型设计
进入具体开发之前，需考虑标签模型层设计，在数仓加工出来哪些数据，标签产品加工哪些数据。标签模型依旧遵循数仓建模的“ODS-DWD-DWS-ADS”分层设计，基于DWD、DWS层抽象一层标签模型层，加工标签基础标签，届时在标签产品上让业务人员通过规则可加工生成新的标签。
一般遵循“公共层数据”、“大数据量计算”的标签放在数仓中数据开发写SQL实现，“通过规则可定义”、“标签规则经常修改”的标签在标签产品中配置。数仓一般实现：
- 公共层数据，包含基础属性数据、基础指标（指标也可以作为一种标签，如最近30天购买金额、最近30天访问次数等）,这些数据不仅给标签系统用，也可以给BI报表、数据门户使用，所以放在数仓中加工表；
· 基础信息类标签：
· 交易类标签：
· 行为类标签
2. 大数据量计算的标签：如计算历史最高花费金额、商品的历史最高库存、累计消费金额、用户排序等，这些标签的计算基于的数据量大，最好放在hive中跑批上线；
在数仓中加工好标签基础表，这些表中的标签一般称之为原子标签，再将该表对接标签产品，在标签产品中进行衍生类、组合类标签加工。
三、标签配置
基于标签模型的设计，一部分基础指标类的标签在数仓已建设完成，一部分标签需要在产品界面上实现。我们接下来看下业务人员如何在袋鼠云标签产品中配置标签。
1. 根据业务对象，创建实体、关系
假设一个电商类客户，需要建立一套用户标签体系，则首先创建“用户“实体对象，并在实体对象下可以接入标签多张基础表，如用户基础信息表、用户行为事件的指标表等，这些表的字段可作为原子标签直接使用，作为后续加工衍生、组合标签的基础。
同时，在后续加工衍生标签时，在某些场景上会用到多个实体下的原子标签加工，这时候可以用“关系”将2个实体关联起来，如将“用户”实体与“书籍”实体通过用户表的“最近购买商品ID”、以及书籍表的“书籍ID”关联起来，便可以用到2个表的字段进行某个标签的加工，如下图：
2. 读入原子标签
从标签基础表中读入原子标签，进行原子标签的元数据管理。
读入原子标签时，有些字段可能存储的是编号或一些枚举值，但业务人员需要看到具有真实业务含义的值，此处可做一层字典值映射。比如将“省市编号”映射为具体的省市名称。
3. 创建衍生标签
基于接入的数据表的原始字段和原子标签，通过“且、或”关系、“求和、去 重计数、计数、最大值、最小值、均值”聚合函数、“等于、不等于、小于、小于等于、大于、大于等于、包含、不包含等”操作符，对源表字段进行加工，生成衍生标签。如基于用户访问次数、交易次数，加工“用户活跃度“衍生标签，包含“高活跃”、“一般活跃”、“睡眠状态”标签值，对用户活跃度进行衡量。
除通过可视化规则加工标签外，也会开放SQL界面写SQL加工标签，因为在实际场景中，客户场景不禁相同，有些复杂标签需要SQL快速实现，在产品界面上也可直接操作。
同时，虽然产品上会开放基于函数计算的标签加工、SQL类的标签加工，但还是会建议客户将公共层的指标类标签、及复杂类标签放在数仓中实现，以使标签配置这层轻量，届时进行数据跑批时快速。
4. 创建组合标签
基于原子标签和衍生标签，可进行组合标签的创建，如基于最近交易时间、最近1年交易次数，最近1年交易金额区间这3个标签，加工“用户综合价值”组合标签，将客户分为“低价值用户”、“一般保持用户”、“重要发展用户”等。
5. 创建实时、算法标签
实时标签：如基于用户实时行为数据通过Flink引擎计算实时标签，如用户点击APP上的一个商品广告，且加入购物车，判断该客户属于“某类型商品感兴趣用户”，作为客户短期兴趣标签，可在袋鼠云流计算平台实现
算法标签：如基于用户的基金交易行为，预测该用户属于追涨、杀跌、高抛等哪种类型的客户，作为客户的风险偏好标签，可在袋鼠云算法平台完成。
最终将这些实时与算法标签的元数据可统一接入标签平台统一管理。
标签逻辑创建好之后，同时配置标签的更新周期、更新优先级，进行标签的定时跑批、手动跑批等。
标签体系建设方法论
一、数字营销是数字化转型排头兵
《⼗四五数字经济发展规划》中强调，要⼤⼒推进数字化转型，形成数据驱动的智能决策能⼒，提升企业整体运营效率。要做好数字化转型，企业可从产、研、供、销、⽤等多个环节入手，而 “销” 恰好是第一关键要素，企业转型往往从营销场景入手，因此我们说数字化营销是企业数字化转型的排头兵。
在数字化营销转型过程中，由于各个企业的数字化建设进程不同，往往会遇到多种挑战，如：
- 企业数据如何打通？
- 客户画像如何建设？
- 营销 ROI 如何提升？
- 营销策略如何迭代？
要想解决以上问题，在业务⽣产与业务应⽤之前，让产业数字化营销，我们需要进⾏：
- 数据的统⼀存储
- OneID 的数据打通
- OneModel 的数据模型建设
- 数据资产的统⼀管理
打好这些基础，接下来就能开始建设企业自己的个性化标签体系，让标签作为企业数字化营销的基石，帮助消费者画像更加精确；实现用数据指导营销，而不再只是含糊的经验；让活动的数据再回流到数仓中，作为标签数据来源的一部分，形成营销业务闭环。
二、标签体系建设方法论
那么如何帮助企业构建完美的标签体系呢？我们总结出 “三目标 + 五步法” 的方法论：
标签体系建设三目标
目标一 解决业务问题
要确定我们建设标签体系是为了解决什么具体的业务问题，想要达到什么效果，时间上要做到分期而治，小步快跑，早日推广应用。
目标二 业务人员好用、易用
标签体系的建设目标是要灵活可扩展，让业务人员可以轻松衍生标签、生产效率高。同时标签应用方式还需要多种多样，以适应不同的业务要求。
目标三 可持续更新迭代
标签体系作为重要数据资产，需要我们对它进行持续完善，形成业务应用与数据开发部门良好互动，助力生产更有价值的数据。
标签体系建设五步法
第一步 明确建设目标
在开始建设标签时，我们需要明确建设目标，目标可以指导我们的执行策略无偏差，最终达到想要的结果，否则在建设过程中随着一些信息的输入、困难的出现，容易今天一榔头明天一棒槌，顾此失彼，达不到业务期望的结果。
（1）业务建设目标
业务建设目标，指通过标签项目想解决什么样的问题，达到什么样的业务效果。比如
- 现在属于粗略式的运营，需要基于标签体系实现精细化运营，将营销活动的转化率提升5%。
- 标签加工流程过于缓慢，从业务人员提需求到需求实现需要1-2周时间，需要将改时间缩短至1-3天。
- 现在数据来源过于单一，只有交易域，需要汇总其他域的数据，比如行为数据、评论数据、活动数据等丰富标签体系维度。
一般列举5-10条目标，业务部门与技术部门一起制定，基于这些目标，进行系统建设。
（2）系统建设目标
为实现对应的业务目标，需要建设一个怎样的系统，是内部实现，还是外部采购，各自的实现周期与成本，若外部采购，采购的标准是什么等都需要考虑，该问题一般是技术部门来考虑。
- 系统给谁使用
是建设一个标签加工与管理的标签管理工具，主要给技术部门使用，因为企业已经有了营销系统、涵盖标签圈群与推送给的功能。还是需要一个集合加工、管理、圈群、分析一体化的工具，数据分析师、业务人员也要用。不同的使用对象，系统建设的内容不一样。 - 系统的技术架构要求
公司内部的大数据部门若已经用了一些底层平台或技术组件，从节省成本方面，应当尽量用同一套底层存储与计算平台，比如已经采购了CDH、TDH的Hadoop，那标签系统需要可直接对接这些系统进行数据存储与计算。
以及标签系统需要和CRM系统、营销平台实现对接，便需要有相应的对接方案，如通过标签服务API接口，或数据同步、推送等当时，将数据给到下游系统。 - 系统功能要求
基于标签的加工、标签的生名周期管理、标签的数据安全、标签的评估治理、标签圈群、画像洞察、对外服务等多方面梳理需要的功能。 - 系统性能要求
基于司内的数据量，标签加工的速度、并发，标签圈群与分析的查询时间，所需要的部署资源、一年需要花费的成本需要进行评估与计算。
（3）参与部门与执行计划
根据我们一些标签项目的建设经理，会出现这样的情况，大数据部门一期项目建好的标签，很难推动业务人员使用起来，主要有以下几点原因：
- 业务人员觉得建设的标签有用的很少，大多数都用不上
- 用了一下标签，觉得数据不准确，不敢用
- 领导没有说要用这些标签，还是按照自己的既定模式来工作好了
基于这些问题，标签项目推进之初，需要拉上业务部门的领导、对接人一起参与，确定一个先应用标签的项目或场景，做出效果，再应用到更多的部门及项目，否则刚开始大而全，周期长、且没有目标性，往往后续推广使用时会遇到阻碍。
参与部门包含以下：
- 需要标签项目服务的业务部门（核心）：如市场部、运营部、客服部、风控部等，各指定一名对接人员。
- 项目需求收集分析者：数据产品经理、数据分析师。
- 系统建设和标签加工者：数据科技部门。
制定执行计划：
- 项目是否需要分期，一期项目的目标和建设的标签有哪些。
- 各期项目时间周期、负责人，上线场景。
- 上线后业务人员需要持续反馈使用情况，业务变化情况，不断的优化迭代。
第二步 标签体系设计
明确好建设目标之后的下一步就是标签体系设计。
在此之前，我们先对一些标签的重要概念做一些介绍：
标签体系设计是一种对对象统一进行本质刻画的数据描述办法，把个体观察升级为群体观察，而非过去对个体现象的归纳，更具有面向未来的场景化适应能力。标签体系设计的整体流程可分为 4 大步骤 + 2 大阶段：
在此过程中我们需要：
01 规划实体对象
确定标签体系的对象，梳理标签间的关系，设计标签体系，做好标签类目创建。
实体指我们要建立标签体系的对象，如客户标签体系、商品标签体系、渠道标签体系、客户经理标签体系，客户、商品、渠道、客户经理都属于我们的实体对象。其类似一颗树的根，后续要基于“实体”，长出树的枝干、叶子、花等，所以划分正确的实体很重要。
关系指多个实体之间的关系，如“客户”购买“基金”，会使客户实体与基金实体发生关系，形成新的标签，比如加工“投资风险偏好”标签，标签值为“高风险”、“中高风险”、“低风险”等，需要利用客户最近一年的交易记录结合基金维表，当用户购买基金的基金类型包含高风险，且最近一年购买金额>5000时，为高风险偏好。需要用到2个实体形成一个关系，来加工这个标签。
02 探查数据
根据标准数据建仓规范，梳理下大概的客户的数据域、业务过程、数据表、表的数据量、数据分布等，掌握基于该数据，可以加工出哪些标签。
03 设计标签类目
基于已采集的业务需求、掌握的数据情况、规划的实体的对象，建立实体对象的标签类目体系。除根据客户业务建设外，也会提供一些行业通用模板，作为参考。
标签类目体系是“实体”树的枝干，为以后标签生长的繁茂建立基础，需要做到枝枝粗壮、分明，即每个类目需要有明显的分割，且标签的数量不能过多和过少，建议一个子类目不超过20个标签，不少于3个标签。
标签类目层级根据业务实际情况划分，一般2~3层即可（不包含标签、标签值）。如下图：
04 设计标签内容
包含标签定义、加工方法判断、加工范围判断等。
根据前面的需求调研、数据调研、类目划分，梳理标签体系中的标签，需包含以下内容：
1）标签中文、英文名：标签的中文名称、英文名称；
2）标签所属类目：标签所属一级、二级、三级类目；
3）标签类型：根据不同维度的划分，采用其中一种。比如事实标签、统计类标签、预测类标签，亦或是原子标签、衍生标签、组合标签、自定义标签等；
4）标签值定义：定义每个标签的标签值，如“近一个月买入金额区间”标签，可根据购买金额的区间段定义“零/低端”、“普通”、“中端”、“准高端”、“高端”等标签值；
5）标签含义（描述）：描述该标签业务含义，如“最近30天的购买商品的金额区间，对用户消费力进行评估”
6）标签业务口径：标签以哪个数据定义为准，如“用户活跃城市”标签，以用户购买次数最多的城市为口径加工，而不是浏览次数、评论次数等；
7）标签技术口径：描述该标签从哪个表的哪个字段取值，SQL取数逻辑是什么；
8）业务方来源：该标签的业务需求方是谁；
9）标签更新周期：描述标签更新频次，天(如T+1、T+2等)、周、月、小时、分钟更新等；
10）标签更新优先级：同一时间端跑多个标签时，若资源有限，先跑优先级高的标签；
第三步 标签加工与更新
标签加工与更新包含各类型标签加工、标签测试和标签上线与更新几个步骤，在技术层面实现营销需求。
判断标签加工方法：
梳理标签的加工方式，判断哪些是离线标签、实时标签、算法标签，从而引入对应的产品和相应的开发人员来开发。业务场景中，离线标签偏多，实时标签次之，算法标签少之。
离线标签：定时跑批，一般为天粒度，T+1跑批，晚上跑标签结果，业务人员第二天做查询。一些标签若高频率更新，也支持小时、分钟粒度的更新。常需要Spark、Presto、Impala等跑批组件及产品。
实时标签：实时加工，一般为秒或毫秒级加工，常见于用户行为实时传上来，基于用户的实时行为，打标签，进行商品推荐等。常需要采用Kafka消息队列、Flink实时计算引擎组及产品。
算法标签：利用机器学习算法、深度学习算法，做一些预测类标签，如根据用户的购物商品和频率，预测家里是否有小孩、小孩年龄等。常需要Python开发环境和机器学习算法包。
不用的加工类型，往往需要采用不同的计算引擎和框架，需判断企业内容是否有这样的能力加工，若无，外部采购的话需要供应商有什么样的能力，需要有大致的判断。
划分加工范围：
标签的使用人员是业务人员，在以往老的流程中，需要业务人员向数据开发提需求加工新标签，开发一个新标签的周期一般1-2周之间。为了使业务人员能够灵活的加工规则标签，尽快提取自己想要的数据，标签的加工、管理目前多通过产品化的方式，使数据开发、数据分析师、业务人员都能参与标签的开发。
这里便涉及到哪些标签由开发人员加工，哪些标签由业务人员加工，标签加工流程是什么等。
可按照上述流程，在数据开发和业务人员之间有个标签管理团队，用来维护标签的生命周期，包括标签需求的分解、上下架等，可由数据分析师、业务人员组成。
大的划分原则是：
基础标签的标签由数据开发团队加工，这类标签是基于数仓数据加工的最细粒度标签（是能打在用户身上的标签，不是某个单纯的字段），不能再被拆解。
基于基础标签可通过规则衍生的，由业务人员完成。
以上图为例：当有一个“是否30天登录未注册用户”标签需求时，标签管理团队可判断该标签是否可基于基础标签衍生，若不行，则由数据开发加工对应的标签；若可以，则判断是否有对应的基础标签可衍生，如举例标签，可拆解成“APP最近一次登录日期”或"距最近一次登录时间"，与“是否注册”2个基础标签，便可基于基础标签，业务人员完成这2个标签的加工与上线。
第四步 标签生命周期管理
标签生命周期管理是指包含标签评估、标签治理和标签迭代等几个对标签的实际使用状态负责的管理流程，帮助实现标签建设与营销的有机结合，不浪费任何一个动作指标。
袋鼠云从以下维度来评估标签的重要性：
- 标签使用度评分：根据标签引用次数、标签分析次数、标签调用次数来评估标签的使用度。
- 标签关注度评分：根据标签搜索次数、标签浏览次数、标签收藏次数来评估标签的关注度。
- 标签质量评分：根据标签值的覆盖情况来评估标签的质量，若null值过多，则说明标签规则设置不合理。
- 标签持续优化度评分：根据标签上线后，再编辑优化的次数来评估标签的持续优化情况。
- 标签安全评分：根据标签是否脱敏、是否设置行级权限、是都需要申请、是否设置可见性来判断标签的安全度。
基于以上5个维度计算标签的综合评分，可查看各标签的评分、评估标签的重要性。
同时，基于标签使用度评分、标签关注度评分、标签持续优化度评分来计算热门标签排行、沉默标签排行，找出不太用的标签进行下线，完成标签的“定义-开发-上线-优化-下线”全生命周期管理。
第五步 标签应用与回流
标签应用与回流则是指标签圈群、画像洞察和对外服务几项具体的落地结果操作，也是标签建设必不可少的一环。
以一个场景举例：
营销策略：为维持老顾客的忠诚度，并引导现在购买初级产品的老客户向高级产品进阶，圈选出为“老顾客升级”用户，为这些客户发放高端产品的优惠券。
人群包选择：“最近1年购买次数>=1”且“最近1年消费金额>=1000”且“性别=女”的客户
基于目前群组进行画像洞察：
群组画像：进一步分析“老客户升级”这批用户的会员等级、月消费支出、是否为活跃用户等，进一步掌握群组特征，根据活动预算调整自己的营销策略
群组分析：圈选出一个“高端产品用户”群组，监控每天忠实用户的人数，看是不是有明显波动，某些活动发放后，数据是否有提升；某个时间人数是否有骤减，保障群组的稳定持续上升。
群组交并差计算：分析“老顾客升级”群组与“高端客户”的重合度，看是否有重复人群，最终推送优惠券可进行策略调整，不针对这部分重合客户进行本次推送。
确定好人群后，便可进行市场投放，看其对业务带来的作用，除分析活动带来的GMV、客单价提升外，我们也需要知道活动参与情况也是用户行为数据的一种，需要将这些数据也回流至数仓，生成新的标签。
三、标签体系在某基金的建设案例
在上文中我们介绍了标签体系建设的方法论，如何将理论落地实践，袋鼠云数栈智能标签产品给出了答案。
智能标签管理分析平台（DataTag），通过标签萃取、标签管理、群组细分、全面画像，构建以业务价值为导向的标签体系和多样化群组，将数据资产标签化，数据标签价值化，应用于企业智能化运营与营销。
接下来我们以某基金客户的案例，来为大家介绍标签体系建设的实际应用。
● 项目背景
身处一个全方位数字化的平台型经济时代，企业的数字化转型已是由内而外的必然趋势，在数字化浪潮下，基金客户的各项业务迅猛发展、客户数据量急剧增长，公司对客户、产品、渠道、反洗钱等方面的数据分析、运营提出了更高要求，在此背景下，搭建一套完整的标签平台，提升营销效率，无疑是最佳的选择。
● 客户痛点
1、客户数据分散在各个系统，无统一的分析平台
2、各类数据分析和提取大多采用半自动的工作模式，无科学的标签体系
3、客户活动开发周期长，运营不精准，营销效果缺乏及时追踪、运行反馈不及时
● 建设方案
1、对接星环 TDH 引擎
2、提供标签实施服务，为客户梳理标签体系，完标签开发，建立客户标签体系，支持销售、服务、合规等不同角度的需求
3、便捷的标签开发、运算、展示和输出等全生命周期管理；支持客户个体及群组画像、客户群圈选和对比，支持快速推广、智能营销、精准服务
● 建设流程
1、业务层面：以客户实际业务现状和业务需求为基础，量身定制适用于业务的标签体系
2、数据层面：将各业务系统中消费者数据回流至数据中台，根据标签设计，进行数据探查、清洗、建模、开发等工作并实施上线
● 业务效果
1、标签体系：建立客户、基金、基金经理、渠道 4 个标签体系
2、标签数量：600 + 标签
3、加工效率：标签加工效率从 1 周缩短到 2 天，运营效率提升至 2~3 次 / 周
4、标签应用：应用在基金营销、反洗钱风险控制、用户流失召回等多个方向
标签加工与更新
在标签生命周期流程中，标签体系设计完成后，便进入标签加工与上线运行阶段，一般来说数据开发团队会主导此过程，但我们需要关心以下几个问题：
标签如何快速创建和实现标签逻辑的在线化管理
业务人员怎么参与到标签建设流程中
百级别的标签如何落表
一、加工方式：传统 VS 在线
当企业无标签系统时，一般由数据开发在离线数仓中完成标签加工和运行，运营或市场同学需要某个标签需要通过产品经理向数据开发提需求，这个过程存在很多问题：
（1）标签资产不可见：标签是存在于表里的字段，业务人员不清楚现在有多少标签；标签的加工逻辑与业务逻辑是否一致只能查看SQL代码；新上线的标签只有部分人知道，标签价值散发慢等。
（2）标签资产不可管：加工好的标签，有多少在真正被使用，有多少没人用，完全黑盒，不用的标签每天继续运行浪费计算与存储资源。
（3）标签加工效率低：当业务人员需要某个简单标签时，也需要提交需求给数据开发，加工到上线基本需要2-3天流程。
基于以上这些问题，标签在线化创建与管理显得尤为重要，在线化主要包含以下内容：
（1）标签在线化加工
（2）标签在线化管理
（3）标签在线化更新
其让标签加工过程、有哪些标签变得透明，业务人员也可以参与进标签建设的流程中。
二、各类型标签加工
标签类型的区分在此处便不再赘述了。在袋鼠云智能标签产品中，我们按照标签加工逻辑，将标签分为下文类型，各类型标签的加工层次如下图：
接下来，我们看下具体各类型标签的加工吧。
原子标签
该类标签由数据开发在数仓加工中完成，一般基于数仓DWD、DWS层的明细表与汇总表加工而来，处理逻辑较为复杂，同时维表中的一些字段也可以作为原子标签。这类标签一般包含哪些内容呢？
比如建立用户的标签体系，会包含：
- 用户维表中的用户基础属性：性别、年龄、置业、会员等级、手机号、身份证号…等信息，一般用户系统会有该类信息，
- 基于交易表加工的交易指标：最近30天购买次数、最近30天交易金额、最近7天购买次数、最近7天交易金额。这部分标签也建议放在数仓中实现，有以下几点原因：
- 因为其本身也是一个指标，除后续作为标签进行画像分析外，也常用于在数据门户、BI报表中分析，可作为对外服务的指标放在ADS层中，并且市场上也会有专门指标管理的产品，来实现该指标的加工。
- 这类标签若属于同一个统计维度（如都计算最近7天），数据开发可以在一个SQL片段中计算多个标签，节约计算成本。
- 若业务人员直接基于DWS层的轻度汇总表（每天汇总的交易次数、交易金额）、或DWD层的明细表（每条交易记录一行数据）来加工最近30天购买次数这个标签，需要针对对应的字段进行求和，稍微涉及到一点SQL理解，有一点难度。
故该类使用场景多、对于业务人员有计算难度，可在数仓中合并加工降低成本的标签，可在数仓中作为原子标签加工。
- 基于行为表加工的行为指标：可经过数仓加工成如下表格式，加工行为类的标签，便于后续业务人员去衍生。
原子标签在数仓加工好后，可导入到标签系统中，进行在线化管理。
规则标签
该类标签配置可由数据开发或数据分析师来完成，可基于单张表或关联表中的字段进行在线化加工，可设置统计周期、数据过滤条件，其内置常用的聚合函数（求和、均值、计数、去重技术、最大值、最小值等）、操作符（大于、小于、区间、有值、无值、包含等），通过规则化的在线配置完成标签加工。配置界面如以下：
根据上面的描述，该类标签可以将指标的类型的标签在数仓或指标平台加工好，导入至标签平台作为原子标签，再基于这些原子标签取操作符更好。但在实际场景中，基于不同考虑，有的客户也会在标签平台直接加工此类型标签，如以下场景：
（1）数仓无对应的基础标签，但业务人员很着急需要该标签某标签，走正常的排期、数仓加工、测试，上线到使用基本2天以上了，基于这种情况可以通过该类标签在标签系统直接配置，5分钟即可配置、更新完成，业务人员便可以使用了；
（2）客户方想把标签的加工逻辑在线化呈现、方便查找与追溯，通过可视化的方式在线配置。
-
SQL标签：SQL标签主要数据开发、数据分析师使用，主要解决通过规则标签无法表达的逻辑，如用到排序函数、字符转化函数、子查询等内容。可以通过标准SQL语法灵活完成标签加工。
-
模型标签：模型标签可由业务人员创建。系统集成常见的用户分层RFM模型，用户营销AIPL模型、用户生命周期模型，用户输入对应的指标值区间，便可定义对应的标签值。
以RFM模型举例，基于该模型生成“客户价值”标签。可基于最近一次购买时间、最近一年消费金额、最近一年消费频率等几个原子标签，进行不同区间的取值，给用户打上“重要价值客户”、“重要发展客户”、“重要发展客户”、“重要挽留客户”等
5.组合标签：模型标签可由业务人员创建。基于已生成的原子、规则、SQL、模型标签等，进行规则衍生，生成组合标签。如组合标签“高收入低购买”用户，可通过“收入水平”衍生标签，与“最近3年消费金额区间”衍生标签组合加工，如下图：
6.自定义标签：自定义标签可由业务人员创建。手动为某些用户打上标签，该类标签手动导入，常见场景如下：
（1）客服人员和用户ID为1001的用户沟通后，给该用户打上”性格：温和、有耐心”标签。
（2）如监管机构提供的一些信贷黑名单用户，该类标签可直接导入进标签系统，为用户打上新的标签。
7.算法标签：算法标签由算法开发同学创建，该类标签可在算法平台完成，将算好的结果存储至Hive表中，标签系统可获取算法标签的元数据，拿到算法标签的中文名、英文名，注册至标签系统中，在标签系统中完成算法标签的标签信息查看、标签查询等。如利用机器学习模型加工预测类的算法标签，如根据用户的特征，预测哪些用户是否即将流失，流失的概率等，从而在用户流失之前做一些措施来挽留
8.实时标签：实时标签由数据开发同学创建，该类标签可在流计算平台完成，实时行为数据打入到kafka中，用FlinkSQL消费，再输出到Kafka、或数据表中，下游直接订阅或查询。
三、标签更新与落库
标签配置完成后，便需要进行标签更新与落库，即将标签打到对象（如用户）的身上，这样业务同学就可以根据标签圈选目标群组啦。在此处我们需要说明以下几个问题：
1.技术选型
首先说明一下标签加工的技术选型，在袋鼠云智能标签产品中我们用的 Trino（Presto）高性能分析引擎读写 Hive 表的方式，标签表存储在Hive中。主要有以下几点原因：
随着国家对数字化转型的支持，从金融、政府到小企业都在建设数仓，进行数字化应用，在这个过程中，大多采用的是分布式的Hadoop系统作为计算存储引擎（不论是开源Hadoop，还是发行版的CDH、TDH、FusionInsight等），Hive表便是最常用的存储形式。标签是基于数仓模型搭建出来的，与数仓用同一种存储可以节省存储资源以及不用两种存储之间进行数据交换。
而用Trino（Presto）的原因是其首先是一个分析型引擎，读写速度均可；其次是其SQL语法完备、函数丰富、灵活，可以处理绝大多是业务场景的需求；并且支持跨库同时读取，如Trino可以同时取Hive与MySQL的数据进行数据处理。
但没有一种完美的技术选型，只能贴合企业自己的业务，选取最合适的技术。在这里我们就不分析各种标签的技术选型了。
- 落表方式
上面我们介绍了有各种类型的标签，标签如何落表呢，大家看下面这个图：
在业务场景中，存在有的标签需要每天更新，如最近30天消费金额区间。而有的标签周更新、月更新即可，更新频率不高，如活动类型偏好。这样，便需要支持每个标签有不同的更新频率，但hive2.x版本不支持单列更新，为了解决该问题，我们将每个标签先在临时表存一下（就包含2列，1列用户ID，1列标签）该临时表即建即用即删，每个标签只有一个临时表（非分区表），每个标签占用的占用不大，又能解决标签更新周期不一致的问题。
但如果后续的标签圈群、群组画像分析，我们基于这些单独表的去做联合查询，那效率会很低，因为每个用营销活动，我们需要5个标签圈选出来一批人群，并查询出这群人的性别、年龄、月消费、会员等级、是否活跃用户等信息，加起来用到了10个标签左右，会涉及到10个表的join操作，客户集群资源不丰裕的情况，查询速度慢。
所有我们便将多个临时表通过聚合任务，将所有的临时表join到一张标签大宽表中，进行固化，这张表是一个分区表，可以每天存储一份全量用户标签信息，当然可以自行设置该表的更新周期与保存多少个分区。这样，业务人员进行圈群和分析就可以一张表查询数据，查询效率大大提升。通过标签跑批时间的消耗换取业务的查询速度。
但会遇到有些企业标签数量在500-1000个之间，用户量在千万、亿级别，这样的话，用一张表去存所有的标签会遇到标签大宽表跑批时间过长或跑不出来的情况，所以便需要分表，可以根据标签数量分表。
综上，以上加工存储方式，有缺点的地方便是大宽表加工时，需要join多个临时表，消耗内存，跑批时间长。为解决该问题，袋鼠云智能标签产品在引入数据湖Iceberg进行标签表的存储，其可以实现单列更新，每个标签可以单独更新，这样，便不需要那些临时表了，解决加工效率的问题。
该篇讲了标签的加工与落库，欢迎大家留言讨论，也可以分享下自己见到一些好的标签加工方式，我们共同进步。
对了，业务人员怎么参与到标签建设流程中，该问题在【标签画像系列】标签画像建设方法论中有介绍过，可以去那里查看。
指标体系设计与加工
- 指标建设的必要性
1.1 什么是指标
指标是可客观描述某个事物某个特征的可量化的数字度量，如用户最近30天购买次数，某商品最近30天销售额等。
指标常从多个维度来描述，如某地区的新增用户数、线上线下的新增用户数，维度让指标更加具象与丰满。
1.2 建设背景
大数据时代数字化转型背景下，企业所需要的往往不单单是数据，而是数据背后映射的业务洞察，相比较数据我们更加关心的是其体现的业务价值以及覆盖的业务场景
庞大的数据只有和业务相结合转化为信息，经过处理呈现才能真正体现他们的价值。指标作为数据计算的结果，是直接反映衡量业务效果的依据，应用在企业的方方面面，如数据报表、分析平台及日常取数等。
数据报表
它最直接的指标结果查看的载体，作为业务部门的人，可能每月或者每周甚至每天都要输出业务报表，不管是传统的纸质文档，线上的excel还是后来的报表工具，最终目的都是一样，我们希望通过报表实现数据驱动业务精益增长的目的。
分析平台
作为数据计算结果多样化展示的平台，不管是可视化大屏、还是其他一些BI系统，都通过数据计算结果的呈现更好地辅助业务了解行业现状
日常取数
有数据在哪里，便要去哪里拿，取数的过程，往往是基于不同的业务场景，满足不同的业务需求，对数据进行加工计算获取，当然在这过程中，数据计算结果往往需要保证较高的准确性和一致性
1.3 建设过程中遇到的问题
数据指标作为数据计算的结果，是企业数据价值的直观体现，在业务扩张、指标计算需求的暴增背景下，随之而来的指标管理问题也越来越多：
指标管理不统一：管理机制不统一、分散管理、重复建设、成本高、费时费力。
指标口径不一致：同名不同义、同义不同名、计算逻辑复杂多变、开发技术门槛高，过程不可视。
指标流程不规范：没有统一的流程控制，开发和使用人员分离，沟通成本高、周期长，结果可信度不高。
1.4 解决方案
要解决以上问题，帮助企业建立指标体系，我们需要从以下三个方面入手：
指标平台
建立统一的指标管理平台，集中管理数据指标，沉淀指标资产
指标体系
有一套标准规范的指标搭建方法论，搭建企业级数据指标体系
流程管理
搭载统一的流程控制机制，全面把控数据指标的生命周期
如果是平台、流程是基础，那指标内容的搭建便是关键。指标体系的搭建作为整个指标管理的核心，为指标管理提供最坚实的基础支撑。
- 指标建设五步法
袋鼠云总结以下五个步骤，从0到1搭建指标体系：
2.1 明确目标
搭建指标体系的第一步就是明确搭建目标，大部分企业由于目标不清晰造成指标管理混乱，通过指标体系的搭建，我们要实现“一个指标、一个口径、一次加工、多次使用”，做到统一指标口径，减少重复工作，结果统一输出。
统一关键指标
创建公司级统一的关键指标，帮助企业通过统一的指标框架来助力业务业务扩张。
减少重复工作
为每一个成员提供统一的平台来协同，了解企业整体数据业务情况，减少数据团队重复性工作和时间花费
结果统一输出
针对指标结果，提供一套能将指标和上层应用结合起来的输出方式，发挥数据指标最大的价值
2.2 需求分析
明确目标之后，我们开始着手去构建指标体系，在设计指标之前，我们首先要进行需求分析。
同一个企业，不同的业务线、不同的部门，甚至是同一部门的不同人员，提出来的指标计算需求都会有所不同。所以在需求分析的阶段，我们要做到基于不同行业的业务情况，分析数据指标需求，合理划分主题，更好地为后续指标设计提供业务支撑。
2.2.1 需求调研
主导人
数据分析师，数仓架构师
调研方式
列好提纲，面对面访谈。
调研内容
1）指标应用场景调研：指标应用在哪些业务场景中，应用方式有哪些（BI使用、业务人员自行取数、数据门户展现等）
2）指标来源调研：指标加工的源数据来源于哪些系统，数据是否都采集上来，分为哪些业务域、业务过程。
3）指标现有情况调研：现在有哪些指标，缺少多少，能满足百分之多少的业务场景。指标建设现在遇到的问题是什么。之前的指标加工是否规范，是否需要调整。
4）指标需求调研：了解客户需要完成的指标加工范围。
产出
访谈汇总结果与需求收集表
2.2.2 需求分析
目标
梳理需要加工的指标，指标业务口径，指标更新频率
主导人
数据分析师
产出
指标需求表
数据分析师基于业务部门、科技部门的业务场景和需求，挖掘和提炼具体的指标、业务定义、优先级、实现难易程度、大概的实现方式。
并根据指标数量、难易程度、数据依赖关系，划分初步的阶段性计划，一期完成哪些指标、给哪些业务场景用，二期完成哪些指标，给哪些业务场景用。
2.3 指标设计
2.2.1 指标拆解
主导人
数据分析师
根据上述的业务需求分析，按照从上往下的方式对指标进行分级拆解，看需要的指标需要由哪些指标加工出来，各个指标的关系，，明确各指标之间的关系，可层层溯源，一般分为3层：
一级指标：公司战略层面的指标，全公司认可的衡量公司业务目标的核心指标，如某大业务线产品收入、累计用户数、新增用户数、付费用户数等，面向管理层。
二级指标：业务策略层面的指标，如产品收入拆解到各个产品线，累计用户数拆解到各个渠道，面向不同业务线。
三级指标：业务执行层面的指标，对二级指标进行路径拆解，如产品收入需要拆解到付费用户数、客单价上面。付费用户数又可以拆解为新增付费用户数、复购用户数，根据这些指标可以不断优化运营或销售策略，面向业务部门。
2.2.2 指标建模
主导人
数仓架构师
根据对业务需求的理解、数据情况的探查，划分对应的业务域、业务过程、维度、度量、统计周期等，搭建指标建设的框架。
数据来源
数据指标遵循ODS-DWD-DWS-ADS的数仓设计架构，主要基于DWS轻度汇总表来加工。
数据架构师根据指标需求，看企业数仓设计的完善性，是否需要增加底层的明细表或汇总表，将基础表梳理加工好之后，开始指标的加工。
指标定义
我们先了解下指标的的组成：
指标= 统计周期+维度+过滤条件+度量
维度：描述性数据，指标统计的环境，如地区、个人账户、产品名称、产品类型、销售渠道…
度量：数字性数据，销售金额、贷款金额、销售数量、如账户余额、国债余额、基金余额…
统计周期：计算指标的时间范围，如近30天、当年、当月、近7天、上月、上周、去年…
过滤条件：计算指标的条件限制，如正常状态、有效状态、全国范围内，西湖区的、工作日的…
统计周期、维度、度量是组成的必要条件，过滤条件根据业务场景而定。
维度与度量
在指标加工前，需要先定义数据模型，数据模型中定义“维度”与“度量”，因为这两个是组成模型的基础必要条件。
数据模型按照数仓的业务主题来创建，如存款业务、贷款业务，可遵循星型模型或雪花模型，建立事实表与维表的关联关系，其可以是多张表的关联关系，也可以是单张表。表确定好之后，选择“维度”与“度量”，作为后续指标加工的基础。
我们以一个银行“存款业务模型”的模型来看，其是围绕账户存款余额明细数据建立的存款业务主题数据模型。
表名称 表注释 类型
index_fact_dep_act 账户存款交易事实表 主表
index_dim_dep_act 账户维表 关联表
index_dim_dep_org 机构维表 关联表
index_dim_dep_cust 客户维表 关联表
index_dim_dep_empe 客户经理维表 关联表
数据模型建好之后，选取维度与度量，作为后续指标加工的基础。
维度
选取数据模型中，作为环境描述的字段作为统计的维度。
度量
选取数据模型中，后续要加计算的数值型字段作为度量。
统计周期
统计周期也是指标必不可少的条件，描述一个指标应该指定其时间周期，比如累计交易次数、最近30天交易次数、最近90天交易次数等。一般系统会内置常用的统计周期，也会支持用户自定义统计周期，统计周期需要特别注意的便是日期格式了，比如yyyyMMdd，还是yyyy-MM-dd。
根据以上内容，已准备好数据模型，和指标的三要素：维度、度量、统计周期。
2.2.3 指标分类
袋鼠云指标管理产品按照指标加工类型，分为原子指标、派生指标、复合指标、SQL指标。
原子指标：某一业务行为事件的度量，统计数据来源，如交易笔数、交易金额、交易用户数、账户余额。
派生指标：基于原子指标进行维度、统计周期的派生。派生指标=统计周期+派生维度+过滤条件+原子指标，如近7天账户消费金额，去年账户余额总和、昨天产品销售金额等。
复合指标：多个指标的加减乘除运算，如平均交易额、资产负债率等。
SQL指标：通过自定义SQL生成的指标，适应复杂的指标配置逻辑，满足开发人员不同的指标开发场景。
2.2.4 指标内容
主导人
数据分析师、数仓架构师
基于指标需求、指标建模、指标分类确定指标的具体内容，作为指标开发的指导。
指标名称：指标中文名称
指标编码：指标英文名称，也是存表的字段名
指标目录：指标所属类目的分类
指标分类：属于原子、派生、复合、SQL指标的哪种
业务口径：指标的业务口径，如最近30天付费用户数指最近30天发生过一笔及以上购买交易的用户数量之和。
技术口径：由哪个指标、哪些维度加工而来。
指标责任人：该指标的负责人，可作为该指标的维护人与告警接收人。
更新频率：日更新、周更新、月更新等
描述信息：对指标的额外描述信息。
2.2.5 指标评审
主导人
数据分析师、数仓架构师
指标模型设计完成、指标内容设计完成后，数据分析师与数仓架构师召开指标评审会议，面向数据开发、业务人员进行评审。
1）说明每个指标的定义、业务口径、技术口径、更新周期等
2）说明各个数据指标的类型，以及派生指标由数仓的哪些数据模型加工，其派生维度是什么，统计周期是什么。复合指标的派生维度，由哪些指标加工而成。
评审后进行补充完善，之后进入指标开发阶段。
2.4 指标开发
2.4.1 指标加工
我们来看下各类指标如何加工。
1.原子指标
原子指标来源于数据模型，是从上述“数据模型”中直接读到的度量，是数据模型表中的一个字段，如上述的“存款业务模型”中，可以把“存款利率”、“存款汇率”、“账户余额”、“固定余额”、“分成比例”等度量作原子指标。
选好度量后，同时需要选取描述该度量的维度，这些维度用于描述度量。如将“账户编号”、“机构编号”、“客户经理编号”、“客户编号”、“账户状态”等作为维度，则可以表示各个账户的存款账户余额、各个客户的存款账户余额、各个分行/支行的存款账户余额，各个客户经理管理账户的存款账户余额等。
所以原子指标是数据模型中维度和度量的组合映射，非一个有真实含义的指标，因为它表示的“客户”的“账户余额”，还没有加上统计周期与计算逻辑，比如客户当日账户余额、客户最近一年平均账户余额等。但原子指标是后续派生、复合指标加工的基础，不可缺少。
2.派生指标
派生指标是基于原子指标进行维度与统计周期的派生，并设置计算逻辑。
如“当日存款账户余额”，可基于原子指标“账户余额”来进行派生，维度选取“账户编号”、“机构编号”、“客户经理编号”、“客户编号”，计算逻辑选取“求和”，统计周期选取“当日”，表示各个账户的当日存款账户余额、各个客户的当日存款账户余额、各个分行/支行的当日存款账户余额，各个客户经理管理账户的当日存款账户余额等。
派生指标中内置的计算逻辑有：求和、均值、计数、去重计数、最大值、最小值等，也可以自定义函数。
内置的统计周期有：当日、当月、当年、去年、最近7天、最近30天、历史截止当前，也支持自定义。
- 复合指标
复合指标是基于原子指标或派生指标进行的加减乘除运算。
如“当日基金账户利润”复合指标，可基于复合指标“当日基金账户利润率”、派生指标“当日基金账户余额”加工而来。
在“当日基金账户利润率”>1时，
当日基金账户利润=当日基金账户利润率 * 当日基金账户余额；
在“当日基金账户利润率”<=1时，
当日基金账户利润=（当日基金账户利润率+ 0.05）* 当日基金账户余额。
复合指标的维度，需为加工公式中用到指标的公共维度，可以计算这些维度的该复合指标。如“当日基金账户利润率”指标的维度有“机构编号”，“当日基金账户余额”指标的维度有“账户编号”、“客户编号”、“机构编号”、“客户经理编号”，则基于这2个指标加工的复合指标“当日基金账户利率”只能有其公共维度“机构编号”，可查看各个机构的当日基金账户利率。
高级设置：公式中用的来源指标可设置指标数据的过滤条件，加工后的复合指标可取聚合函数，根据实际情况使用即可。
以上便是复合指标的加工。
- SQL指标
当存在以上通过内置函数、内置运算符加工不出来的逻辑较为复杂的指标时，可采用自定义SQL指标实现。只要遵循正确的语法结构，便可以灵活加工。
指标加工完后，后续可在指标血缘关系中查看指标间的上下游关系。
2.4.2 指标落库
指标逻辑配置成功后，每个指标可配置其更新周期，调度策略配置完成后，进行指标发布。发布后便按照设定周期周期性加工。同时，也支持手动立即更新。
指标更新后，会将每个指标和其维度存储在Hive表中，每个指标和其维度存储一张单独的表。
2.4.3 指标运维
指标上线后，运维同学便需要进行指标的日常运维，观察指标运行情况，及时处理报错情况，保证指标的正常加工和线上业务可用。
2.5 指标应用
指标常应用在数据门户、BI数据分析、可视化大屏展示，业务人员数据分析中。那产生的指标怎么与上层应用对接呢？
2.5.1 指标API
通过API服务将指标平台加工好的指标，提供给上层的展示、分析系统。
在创建API时定义需要查询出去的指标，多个指标的公共维度作为该API的入参。通过API接口，查询对接的指标结果。
外部系统调用API的url，用API-TOKEN认证便可以进行数据的查询。
2.5.2 自助取数
在自助取数平台中，可直接查询指标平台定义好的维度、指标，业务人员灵活拖拉拽，实现在线取数。并且取数逻辑可沉淀成固定的报表模板，报表可周期性自动生成数据，业务人员届时拿结果数据即可。