后互联网时代 - 数据比你更了解自己

闲话画像系统实践

背景

在获客成本昂贵，流量红利日渐减少的后互联网时代，如何充分利用站内已有的流量，发挥用户价值，显得尤为重要。

对于用户的精准运营，往往需要依赖各方位的数据支持，结合运营手段，并通过效果回溯的不断演进。

在这种背景下，一个连接底层数据、服务上层运营同学的画像系统就变得比较重要。

几年前在某家公司也做过画像系统，对于画像系统的理解和系统设计在原有设计的基础上也做了一些扩展。

下面从几个角度，浅显地描述下目前画像的历程。

画像系统是做什么的

A 识

人物标签化

我们的用户是什么样的

（基础标签：性别，城市，年龄，职业）

我们的用户喜欢什么

（偏好标签：类目、店铺、价格带偏好）

我们的用户活动情况

（活跃属性标签：近X天访问/下单/…）

有没有“干坏事”的用户

（风控标签：刷接口，异常交易等等）

这些数据大部分已经由BI同学产生，并存在数仓的不同的结果表里，但离让运营同学可见感知和使用还是有一些距离。

在这些数据的基础上，我们抽象出标签体系，为基础数据定义基础标签。通过标签体系的划分，能够让使用者更方便的从自己关心的角度去认识用户。

这里没有什么特别，所有的画像系统基本都是建立在标签体系的基础上，首先从认识用户作为切入点。

在这个层面上，结合一些业务上的诉求，这次的标签体系设计除了遵循最基本的标签系统划分外，设计了通过基础标签组合高阶标签的功能。

这些高阶标签往往不是一个固定的取值或公式，而是一些和业务强相关的动态指标。

比如XX领域的购买力标签，往往是结合了多个订单相关的数据出价相关数据等等结合而成的一个高阶标签。如上图所示，算是一个RFM模型的简化版。

B 聚

物以类聚，人以群分，相近特性的人往往会有相近的偏好和习惯，而人群也正是画像承接应用的一个核心实体。

基于认识用户的基础上，通过标签的或与非关系组合，人群选定便成为水到渠成的一个流程。

一般在设计上，人群划分定义了实时人群和离线人群。

系统实现上，离线人群事先圈定好人群的标示；在技术实现上，提前在缓存中预热人和人群的映射关系以达到接口的高QPS和低RT。而实时人群则是在用户请求时，计算用户的特征与圈选人群特别的匹配关系，来确定用户的人群归属关系。

从这个角度，本次画像的底层，引入了flink作为实时特征的基础，方便大量生成业务关心的实时指标。

在离线映射关系上，提前比较人群的差异来做缓存的维护。在人群更新的CD时间，及实时标签的生产效率上有了较大幅度的提升。

另外从技术的角度，离线结合实时人群的映射关系也可以通过离线预热结合实时内存匹配的方式支持。

以此支持诸如 杭州 + 25-30岁 + 新人（实时标签）的场景。

业务场景上的灵活性和普适性更好。

C 达

同往常一样，我们对接了常见的运营触达手段：推送和站内资源位投放。

推送系统对接主要解决静态跑数，人工上传等繁琐的流程，解放中间商，辅助实现推送自助。

资源位对接主要实现了业务投放的千人十面的效果，运营活动和业务活动可定向，解放业务系统写死的规则流程，辅助实现活动运营的自助。

是的，做辅助我们是专业的，用数据说话。

画像系统全貌

画像的域

上面没有特别的提用户画像，是因为，这一次，我们把画像按照实体范围划分成了不同的域。

那么怎么把用户画像扩展到商家画像，商品画像，乃至更多的业务域画像呢？

当然是ctrl c, ctrl v,然后改个名字咯～

好吧，虽然我们没那么做，但是整体也差不多。

在画像系统的设计时，包括标签系统的设计时，为每个标签，每一个实体分配的域的标示。

这样虽然大家是一个实体，但是也从应用场景上做了隔离。

目前来说，原则上，不同域之间的标签和数据是不混用的。而使用场景上，简单来说就是：

对于用户域，就是一个用户画像的形态，可以去做用户透视，人群选取加精准用户运营。

对于商家域，就是一个商家画像的形态，可以做商家的属性评估，活动的商家选取。

对于商品域，就是一个商品画像的形态，可以做商品趋势分析，选品等。

以此类推可以扩展到其他更多的业务域实体。

技术实现点

数据链路

A 数据源

画像的数据源来源于以下几部分：

埋点日志的实时清洗和计算 --> 实时标签

统计类型离线数据(BI) --> 用户基本信息和离线行为标签

业务消息或者业务数据库消息 --> 业务域标签

B 数据存储

如上上图所示，画像的存储分为以下几个部分：

数据库存储标签和人群的元数据

Hbase作为标签的最底层存储

     选用Hbase作为基础存储主要考虑以下几点：

     1. 列可扩展性，并且适合亿级别的数据存储         

     2. 存储特性，比如ttl机制以cell为单位，未更新数据按照时间消亡。

     3. 方便生成外表和准实时get查询数据。

redis用于业务接口获取人群映射关系及实时标签

elasticsearch用于人群圈选和人群分析及个别属性吐出

C 数据流

实时计算

通过flink大量从埋点日志，业务binlog和业务消息中计算画像中的实时标签。

传统的离线标签提供了相对固定的用户id和人群的映射关系，实时标签的介入使得用户能即时地体现标签的变化。比如新人和非新人的即时感知。

flink的实时标签数据，会落缓存一份，hbase一份，elasticsearch一份。由于flink本身流式计算可以具有事务性，这三个存储的实时数据基本可以保持一致。

缓存主要用于人群的实时条件匹配。而hbase和es主要是用于最底层的数据存储和离线人群圈选。而这两个场景本身对于数据的实时性没有特别的要求。

flink对接站内各个业务，并不断沉淀数据层次，为画像的数据底层提供了非常强大的实时数据支持。

后续考虑继续扩展到实时数仓，不仅在实时标签层面提供很好的支持，也能在数据效果层面提供更实时的效果数据。

离线数据交换

离线数据交换是一个典型的ETL的过程，读取标签系统的元数据信息生成基于datax的异构数据交换任务，通过xxljob定时调度datax任务。这是一个很常规的数据交换场景，这里就不再赘述。

业务结合画像

画像系统结合了业务更大程度的发挥数据的价值

资源位和画像系统的结合

流量首先被人群定向做一次横向的流量切分，再被AB分流系统做一次纵向切分。最终以定向和分流两个角度来对应某个资源位的素材或者活动。

在埋点日志中也体现人群和分流信息，通过日志采集，分别在实时链路和离线链路做最终效果回溯，目前实时链路暂不完备，有待建设中。。。

推送和画像系统的结合

推送系统和画像的结合点主要在于人群信息和文件的同步，这里画像系统通过mq的方式传递人群的变化信息，推送系统异步地获取这些信息，根据需要决定是否再主动获取详细的人群信息。

这里的系统打通减少了很多运营同学和BI同学的交流成本和重复工作量，实现推送人群选定、评估和落地的自助化。

搜索推荐和画像系统结合

这里主要体现在为搜索和推荐提供用户的偏好和行为标签，没有体系化的内容，简单带过。

其他

业务系统和画像人群结合除了人群定向流量的功能，另外隐藏功能就是解放业务逻辑代码，随时支持临时数据相关的业务临时逻辑。

大促正在进行，发券的逻辑不断在调整？

活动快结束，最后来一波助力？

统统配置人群和业务的关系可以灵活解决～

也和以下的固定数据判断say bye bye

后续规划和结语

画像系统月底才呱呱落地，我们在基础设施建设完毕的情况下，接入了业务场景，让数据尽快发挥价值。

后续的重点在于基础建设完善和一些使用模式的多样化, 期待更大数据量和更多业务场景的挑战。

关注【玩物得志技术】公众号
点我扫码[向右] https://w.url.cn/s/AHDWxPI
满满的技术干货