浅谈Hbase在用户画像上的应用

背景

用户画像，即用户信息标签化，是大数据精细化运营和精准营销服务的基础。设计从基础设施建设到应用层面，主要有数据平台搭建及运维管理、数据仓库开发、上层应用的统计分析、报表生成及可视化、用户画像建模、个性化推荐与精准营销等应用方向。

基本流程是：根据人口学特征、浏览行为&内容、社交活动和消费行为等信息而抽象出的一个标签化的用户模型。通过分析用户的基础信息、特征偏好、社会属性等各维度的数据，刻画出用户的信息全貌，从中挖掘用户价值。

用户画像的定义并不复杂，是系统通过用户自行上传或埋点上报收集记录了用户大量信息，为便于各业务应用，将这些信息进行沉淀、加工和抽象，形成一个以用户标志为主 key 的标签树，用于全面刻画用户的属性和行为信息，这就是用户画像。简而言之：画像是由标签树及末级标签的标签值构成的，全面定量刻画用户的结构化信息产品。画像是标签的总成，用户标签是具体刻画用户的结构化信息。

介绍

基础处理逻辑架构：

数仓架构：

主要覆盖模块：

数据仓库ETL加工流程是对每日的业务数据、日志数据、埋点数据等数据经过ETL过程，加工到对应的原始数据层（ODS）、数据仓库（DW）、数据集市层（DM）中。

用户画像不是产生数据的源头，是经过ODS层、DW层、DM层中的数据与用户相关数据的二次建模加工得到的数据。

在ETL过程将用户标签写入Hive，根据不同数据对应不同数据库的应用场景，再将数据同步到MySQL、HBase、Elasticsearch等数据库中。

Hive：存储用户标签、用户人群及用户特征库的计算结果
MySQL：存储标签元数据，监控相关数据，导出到业务系统的数据
HBase：存储线上实时数据
Elasticsearch：支持海量数据的实时查询分析

其中用户画像最主要的两个部分：

用户指标体系
用户标签体系

指标体系：

数据指标体系是建立用户画像的关键环节，也是在标签开发前要进行的工作，具体来说就是需要结合企业的业务情况设定相关的指标。

通常我们讲述的指标是指将业务单元精分后量化的度量值，譬如：DAU、订单数、金额等。当然，原子指标还会基于维度、修饰词、统计口径而构建出派生指标。指标的核心意义是它使得业务目标可描述、可度量、可拆解。

一个好的指标体系设计，不能说可以规避掉百分百的问题，但至少让问题出现时各方临危不乱。

首先，业务同学需要对自己的业务有一个大概的预判，譬如：在整体的业务里程碑上什么时间点会有哪些策略动作，对应的业务体量会是多大。与此同时也提前去预知大概会监控哪些指标，从哪些维度拆解等

其次，在有了初步预判之后与团队技术沟通，与数据团队沟通，尽量让各方信息对称。这样的好处是我们能尽量提前将指标体系设计得不重不漏、条理清晰。同时技术团队也会有所准备，在做数据底层设计时多去考虑其稳定性、扩展性等。

1、明确业务是什么

在搭建指标体系之前，需要明确自己的业务是什么？公司整体的目标是什么？在产品实现上，如何帮助用户解决问题？

譬如像：电商C2C企业，业务本质上要解决的是需求「匹配」和「匹配效率」的问题，是一个不断丰富供给和满足需要的过程。目标上会去追求实现更多用户的双边关系需要，对应到数据去看会衍生出「DAU」、「订单」、「GMV」等战略指标。

2、按业务大盘拆解

根据企业战略目标，按照业务大盘的方式拆解数据指标体系，在业内有个有名的方法论AARRR（也叫海盗指标法，Acquisition用户获取、Activation用户活跃、Retention用户留存、Revenue营收、Refer传播），整体的拆分逻辑是「获取→活跃→留存→营收→传播」，观察其在业务主流程上，不同阶段实现用户侧买家和卖家需求时，用户会做什么、产生哪些数据、我们需要监控哪些数据。

3、第一关键指标

“第一关键指标”指的是当前阶段无比重要的第一指标，同时也指出了在创业阶段的任意时间点上应该且只关注一项重要指标。这套理论在我们去考核不同团队的时候同样有借鉴意义，公司当前阶段的“第一关键指标”拆解到不同部门之后，就成了各部门的“第一关键指标”，也是团队的考核度量（OKR或KPI）

例如：订单体系

数据指标体系设计流程：

注意：模型未动，指标先行。

常见C端的指标模型：

标签体系：

在我们建立用户标签时，首先要明确基于哪种维度去建立标签。

一般除了基于用户维度（userid）建立用户标签体系外，还有基于设备维度（cookieid）建立相应的标签体系，当用户没有登录设备时，就需要这个维度。当然这两个维度还可以进行关联。而两者的关联就是需要ID-Mapping算法来解决，这也是一个非常复杂的算法。更多的时候我们还是以用户的唯一标识来建立用户画像。

用户指标体系和用户标签体系的最大的区别是：用户指标是我们定义的一系列和业务相关的统计指标，而标签是在指标上面的一层聚合和模型的定义。虽然可以定义成千上万个指标，但是可能多个指标的聚合才能对用户的某个维度进行打标签。而且标签是分层级的，可以为标签建模提供标签子集，梳理某类别的子分类时，尽可能的遵循MECE原则（相互独立、完全穷尽），最后要依据标签的相识度，标签的权重，以及标签的组合去圈选用户，做精确化营销或者推送。

用户画像指标体系和标签分类从两个不同角度来梳理标签，用户画像指标体系偏战略和应用，标签分类偏管理和技术实现侧。
例如：

一个比较成熟的画像系统，会有成千上百的标签，这些标签的生产不是一次完成的，而是随着业务的发展需要，逐步补充完善，最终呈现在大家眼前的就是一棵庞大的标签树。所以在前期最重要的仍然是搭好画像骨架，确保后续的发展过程中，依然保持清晰的结构和高延展性。相反的，如果一开始为了抢时间，将大量标签无序的堆在线上，后期管理和使用的难度会迅速凸显出来，重构的代价巨大。

一个好的标签树结构要满足两个条件，“高概括性”和“强延展性”，高概括性意味着结构体系能够很好的包含一个用户的基本属性和产品交互的相关行为，同时对于业务重点单独强调，没有遗漏；“强延展性”意味着结构全面的同时也有一定的抽象概括能力，保证新增的标签可以很好的找到对应的分类，整个体系不会过于收敛局限。

从对用户打标签的方式来看，一般分为三种类型：1、基于统计类的标签；2、基于规则类的标签、3、基于挖掘类的标签。下面我们介绍这三种类型标签的区别：

统计类标签：这类标签是最为基础也最为常见的标签类型，例如对于某个用户来说，他的性别、年龄、城市、星座、近7日活跃时长、近7日活跃天数、近7日活跃次数等字段可以从用户注册数据、用户访问、消费类数据中统计得出。该类标签构成了用户画像的基础；
规则类标签：该类标签基于用户行为及确定的规则产生。例如对平台上“消费活跃”用户这一口径的定义为近30天交易次数>=2。在实际开发画像的过程中，由于运营人员对业务更为熟悉、而数据人员对数据的结构、分布、特征更为熟悉，因此规则类标签的规则确定由运营人员和数据人员共同协商确定；
机器学习挖掘类标签：该类标签通过数据挖掘产生，应用在对用户的某些属性或某些行为进行预测判断。例如根据一个用户的行为习惯判断该用户是男性还是女性，根据一个用户的消费习惯判断其对某商品的偏好程度。该类标签需要通过算法挖掘产生。

画像通常从八个维度组织标签，分别为：基本属性、平台属性、行为属性、产品偏好、兴趣偏好、敏感度、消费属性、用户生命周期及用户价值，每个维度再分成二级标签、三级标签等。

① 基本属性

基本属性是指一个用户的基本社会属性和变更频率低的平台特征，例如真实社会年龄、性别、婚姻状况、昵称、号码、账号、lbs 等标签。这些标签类型多为直采型，可从用户基本信息表中直接获取，不需要统计或者算法挖掘。

② 平台属性

平台属性是用户在平台上表现出的基本属性特征，是利用用户行为进行算法挖掘，标识用户真实属性的标签。

最典型的平台属性标签例如平台年龄标签，这里就有一个疑问，为什么在用户的基础属性中已经有年龄标签，但在平台属性中重复又有一个呢，这里就涉及两者之间的差别。设想一个真实的场景：一个用户社会身份为 20 岁，但他喜欢中年人的穿衣风格，在使用 app 购物的时候，表现出的真实偏好为 30-40 岁，对于这样使用产品时表现出的用户心智和真实年龄不相符合的用户，如果只采用上传的基本属性，给他推荐年轻人喜欢的物品，是不是很难命中个体用户的兴趣呢？

数据源与计算逻辑：基础属性是利用用户自行上传的存储在用户基础信息表里的数据，平台属性则利用客户端或者服务端埋点上报采集的用户行为数据进行挖掘计算生成。基本属性是典型的直采型标签，平台属性是典型的算法挖掘型标签。

应用场景：平台属性通过用户行为进行挖掘，更能代表用户的真实倾向，输出结果比基本属性准确率高，在定向营销和算法里，年龄、性别等通常采用平台属性。而社会属性中电话、身份证、账号、昵称等使用较多。

③ 行为属性

行为属性记录的是用户的全部单点行为，用户的单点行为包括启动、登录、浏览、点击、加车、下单等非常多，而且跟不同的产品，不同的模块交互，不同的时间窗选取，行为就更加复杂了，如何能够全面的梳理，可以按照“产品＊功能模块＊用户单点行为 * 时间”四大要素来组织。

④ 产品偏好

产品偏好是对用户使用某些产品、产品核心功能或者其他渠道的偏好程度的刻画，属于挖掘型标签，其中产品的选取可以包括自家产品、竞品；功能和渠道包括站内产品功能，也包括 push、短信、开屏、弹窗等几大运营和产品法宝。

示例：搜索模块偏好、直接竞品 _ 京东偏好、短信偏好。

⑤ 兴趣偏好

兴趣偏好是用户画像内非常重要的维度，以电商产品为例，用户对商品的喜爱程度是用户最终的信息之一，兴趣偏好就是对用户和物品之间的关系进行深度刻画的重要标签，其中最典型的要属品牌偏好、类目偏好和标签偏好。

⑥ 敏感度

在营销活动时，我们留意到有些用户不需要优惠也会下单，而有些用户一定要通过优惠券刺激才会转化，优惠券的额度也影响了用户下单的金额，这种情况下，如何识别对优惠敏感的用户发放合理的券额的优惠券，保证优惠券不浪费，去报促销活动的 ROI 最大，其中一个很重要的标签就是用户的敏感度标签，敏感度代表用户对平台活动或者优惠的敏感程度，也是典型的挖掘类标签。

示例：热点敏感度、折扣敏感度。

⑦ 消费属性

无论是电商、内容或者其他领域，公司的目标最终都是收益，所以消费属性往往作为一个单独的维度重点刻画。消费属性包括统计型标签——消费频次、消费金额、最近一次消费时间等，也包括挖掘型标签——消费能力和消费意愿，同时包含敏感度标签——优惠促销敏感度、活动敏感度、新品敏感度、爆款敏感度等。

⑧ 用户生命周期及用户价值

用户生命周期是用户运营的重要法典，一个用户从进入产品到离开，通常会经历“新手”“成长”“成熟”“衰退”“流失”5 个典型阶段，每个阶段对用户运营存在策略差异，画像在其中的作用是明确标记用户所处生命周期的阶段，便于后续业务同学落地。

用户价值是体现用户为产品贡献价值高低的标签，最经典的是 RFM 模型获得交易维度标签，与此同时，也应该看到用户的其它价值，例如为产品贡献活跃度，通过裂变拉来新用户，这些都可设计相应的标签。

示例：新手、成长、成熟、衰退、流失、高价值用户、VIP 等级等。

标签命名规范：

在确定好标签后，需要对标签进行命名，以便于管理。

对一个标签，可从多个角度来确定唯一名称。

1、标签主题

标明属于哪个类型的标签，如人口属性（ATTRITUBE），行为属性（ACTION），用户消费（CONSUME），风险控制（RISKMANAGE）等。

2、用户维度

表明该标签来源，是用户唯一标识（userid），还是用户设备（cookie），一般用U和C区分。

一般常用userid，因为用户设备这块不同操作系统对应的唯一标识可能会有区别，而且在关联用户的时候会比较麻烦。

3、标签类型

标签分类，统计型（01）、规则型（02）、算法型（03）。

4、一级归类

在每个标签大类下面，进一步细分的标签类型。

参照上面的命名方式，举例用户的性别标签：

命名规则：标签主题_用户维度_标签类型_一级归类

【男】：ATTRITUBE_U_01_001

【女】：ATTRITUBE_U_01_002

ps: 实际应该全部显示文本，只有背后实现是字母数字。

最后可以根据标签数据进行聚合，ER图如下：

用户画像流程

● 用户画像基础

了解和明确用户画像包含的模块，设计数据仓库架构、开发流程、表结构，及ETL的设计。主要就是明确大方向的规划。

● 数据指标体系

建立数据指标体系，根据业务线梳理，包括用户属性、用户行为、用户消费、风险控制等维度的指标体系。

● 标签数据存储

设计好数据指标体系后，考虑不同应用场景使用哪种存储方式。

● 标签数据开发

重点模块。标签数据开发包含统计类、规则雷、挖掘类、流式计算类标签的开发，以及人群计算功能的开发。

重点内容：数据调研、和业务方确认数据口径、标签开发上线。打通画像数据和各业务系统之间的路，提供接口服务

● 开发性能调优

标签数据开发上线后，为了缩短调度时间、保证数据稳定性，需要对标签脚本、调度脚本进行迭代重构、调优。梳理现有标签开发、调度、校验告警、同步到服务层等相关脚本、明确可以优化的地方，迭代优化

重点内容：减少ETL调度时间，降低调度时的资源消耗。

● 作业流程调度

标签加工、人群计算、同步数据和业务系统、数据监控预警脚本开发完成后，需要调度工具把整套流程调度起来。

重点内容：满足定式调度、监控预警、失败重试，各调度任务之家的复杂依赖关系。

● 用户画像产品化

产品化的模块包括包括标签视图、用户标签查询、用户分群、透视分析等。

重点内容：满足业务方对用户精准营销的需求。

● 用户画像应用

应用场景包括用户特征分析、短信邮件、站内信、Push消息的精准推送、用户圈选等，客户针对不同用户的话术、针对高价值用户的极速退款等高级服务应用等。

重点内容：帮助业务方理解和应用用户画像数据，提高用户活跃度和GMV。

其中指标体系和标签体系这两个重要的点在上面已经介绍完了。后续主要是标签流程的开发和标签数据的存储。

标签完成梳理和命名后，需要维护一张码表用例记录标签id名称、标签含义及标签口径等主要信息，方便元数据的维护与管理。
用户画像的数据存储的技术选型有多种，不同存储方式适用于不同场景。主要有Hive、MySQL、HBase、Elasticsearch。
在数仓建模过程中，主要是设计事实表和维度表的建模开发。
在画像系统中主要使用Hive作为数据仓库，开发相应的事实表和维度表来存储标签、人群、应用到服务层的相关数据。