实时用户画像实践（1）

1.总体方案

  想着做用户画像已经是很久之前的事情了，用户画像，顾名思义是我们通过数据化的资产和一定的计算口径来给我们的用户打上具体的标签，然后呈现给业务或者运营，供给使用。这里，标签包含了很多，诸如和用户相关，还有和其所处的消费场景和历史线索相关，很多很多，基础标签，行为标签以及趋势标签等等。今天要谈的不是我们离线计算好，然后通过实时或者准实时的方式写入到接口侧的那一种，二是通过实时涌动的数据来实时生成的实时用户画像。难点有很多，那么下来，我们就逐一展开。

  首先，说一下具体的方案设计。由于目前我们采用的画像数据大多数来源于日志和数据库，这次我们采集的数据主要是MySQL数据库的binlog日志数据。而后，需要关注的点是业务逻辑和数据流转过程，其实这两者很重要，因为不同的业务计算逻辑可能会与不同的技术架构来融合，那么首先，先讲一下初期的一些思路。

1.1 初期方案

  初期，大家听完需求后，会络绎不绝的感受到业务方的需求和我们想做的是如此之拟合，然而不巧的是，业务方要求的低延迟可能会超过他们自己内心的需求，这个时候，正当你了无其事的觉得都是小case的时候，这时达摩克利斯之剑可能也正好悬在你的头上。所以嘞，问清楚需求尤为重要啊！可能他会跟你说，很简单，就需要三两张表，实时做下join就行了~~~纳尼？实时做join，还要全表，没搞错吧？这个时候，你才意识到不懂技术的业务方有时候觉得技术是如此之简单。后面，你就按他说的全表join，而且还是实时的，那么实时没法做join 啊，这可怎么办？业务产品不知道这个啊，所以自己看着办，那么就诞生了下面这个架构图，大家请先看：

实时画像架构图1

  其实可以看到，数据离线还是要从hive同步的，包括dim表和离线计算的画像标签结果，那么实时需要做以下任务：

• 将离线的join逻辑转化成能在流中使用的类join方式；
• 按照离线业务逻辑来引入数据源；
• 打通整个数据链路；
• 开始用非SQL的方式来完成SQL的计算逻辑；

  当你开始进行这四步时，你会发现，好像走的有点远了。不是真的走远，而是无法回头，远走越远的走远了。这个时候，思考下上面的几个过程，瞬间觉得，这个决定是多么愚蠢。好了不吐槽，开始就上面四点来分析一下，我们就依着这套架子该怎么做。

1. 第一点，要按离线join的逻辑转化到流里面，除非窗口可以解决这个join的结果集，或者是引入第三方存储，kv类型的，可以供给我们使用的如redis、hbase。
2. 第二点就是将有关联的中间结果写入，那么你肯定要问了，没有关联的怎么办呢？对啊，没有关联的，制造关联啊，这么的结局就是业务说的三张表，到最后可能你引入了不止10张；
3. 第三点好办，就是从上游到接入源打通即可，这个有现成的方案；
4. 最后一步计算时会有很多问题，诸如你的数据还没落地就要取状态，或是反复的变化数据需要你考虑不止是SQL的逻辑，无限的数据流如何来按离线来做计算？

  好了，说完上述四点，大概能够明白具体的实现起来逻辑有多复杂，而且计算结果也肯定不会精确，这里就必须提到如何升级架构，来达到和离线一样的计算精确结果以及整体流程的简单易用性。

1.2 最终方案

  目前看，要针对这个流程做一套完整合理的方案，目前看还是要通过SQL的方式来进行。那么要做成实时的SQL，再全表join，计算的时效性就没办法保证。所以说为了准确性，还是要舍弃一定的实时性。下来，我们就这种思路来阐述具体怎么来进行。

  第一，数据源还是按照上面那种的方案来采集，从binlog到canal然后写入kafka，最后通过计算引擎写入到幂等的存储中。然后再经过存储来进行SQL计算，这样就能把复杂的sql计算后延到AnalyticDB中来做，然后触发的计算频率依据业务方接口的调用频率，所以在接口负载和高并发等方面，需要平台开发考量下，在什么环节加一定的缓存，然后过期时间也需要和业务方讨论，当然，这样下来，可能实效性差一些，但稳定性和准确性还是相比上一套要好很多的。

下面是具体的改进后的方式，大家可以看下区别：

实时画像架构图2

2.数据验证

  数据验证的逻辑其实在画像计算中，由于都是线上数据，所以在链路较长的情况下，不是很好实践。只能是测试人员通过以下途径来开展：

• 测试人员找到数据源中和时间以及标签计算逻辑强相关的用户行为数据；
• 根据该部分数据，从采集到缓冲区先查看，是否存在数据丢失的问题；
• 如果之前一切都ok，那么下一阶段则是在实时处理中的容错和一致性语义，需要提醒大家的是，如果是binlog数据，那么一定要做好对单行数据的顺序性消费，包括可能存在的延时的数据，将会使你的结果大相径庭；
• 其实综合整体处理来看，这里我们可以对etl后的数据能够轻度聚合或者合并处理的在处理完后再写入到消息队列进行一个聚合层的存储，之后再从聚合层来写入到AnalyticDB,这样增加了一个环节，但写入的数据某种程度上会减少很多，单独到user这个维度来讲；
• 下面，在实时画像计算时，逻辑要与离线SQL逻辑一致，必须要保证写入的中间表字段和表是一致的，存在业务调整字段的前置问题，这个目前大多是需要提前来做更改，除非你的存储支持动态增加列，这个AnalyticDB应该是支持的，所以这部分可以减少一些开发量；
• 最后，经过写入后，在某一时刻的AnalyticDB的表，我们关联好产出当前的全量数据即可，但其实这里如果可以做成增量的数据是不是会更好，我们只关联这一批次新改动的那些user？这是后续探索的一个方向，如果可行的话，那后面我们是否可以继续考虑放到hbase，后续覆盖列值，但如果这样做会引发另一个hbase的问题，也是当前我们做的不好的点，即对失效的hbase中存储的标签，如果做删除，其实这个用hbase就会产生的问题，因为标签涉及状态问题，有更改就有失效的问题，这一部分失效后的标签，该怎么处理也是需要思考的。

3.基础标签

  大多数场景大家的基础标签都基本一致，比如所在地市，区域，用户基本信息以及注册转化时间信息等。大同小异，所以对于这种较为稳定的标签，是不是我们就可以轻松分辨了，诚然不是这样的。
  因为区分新用户可能大家方式都不同，用注册和转化表join是可以拿到那部分新注册的用户，但这代价太大，可以考虑换个方式来思考，那么，如果我们计算的标签中没有任何信息的用户其实也可以称为新用户，所以，其实不用join，直接通过缓存或者kv存储也能解决这个问题。定位到新用户或者转化用户后，那么下来对于他的基础信息来拿可能还是要回归到表的概念中，可能他的区域和商圈信息，你就需要找另外5张表才能拿到。
  基础标签需要提及到的还有，拉新时间，这个做的话建议放到计算用户标签里面来做，因为纯新你是拿不到转化数据的。可以先做能做的属性字段，然后再逐步加入扩展的一些字段。

4.用户标签

  用户相关的标签可能就要根据业务来分别说说看，先说对提高转化和拉高留存有用的。

4.1 转化留存

• 转化留存永远是互联网行业的根本，如果你被用户薅了很多羊毛而没有转化的话，投资人最终会离你而去的。一般套路都是广撒网，浅收鱼。如果我们可以让一个用户保持一个习惯3个月，那么他是不是会转化为我们的钟爱粉呢？不尽然，所以这里要根据用户的行为来把那部分值得我们投资的用户拉过来，不管是发优惠券还是客服打电话，途径任你选，唯一目的让他转化成为长期的粘性用户。转化留存的意义在这，不用看其他的点，如果1个亿用户中能转化30%，精准定位到他们，可想而知你的收益会有多少？低运营，高转化才是，优质客户有时候可遇不可求，比如线上买菜，始终觉得短时间很难常规化运营。需要整个产业链和产品形象化的提升，说到这，感觉跑题了，我是搞技术的啊？不是产品更不是运营，但他们的思路我们技术也要懂的啊；好，回归正题，这部分标签要做好，一定会是要有用户的优先级划分，高优低优，高潜低潜等；
    说完转化，再谈一下比较热的活动运营相关标签。

4.2 活动运营

• 好的公司必然会有好的活动，这也离不开背后出谋划策的运营。所以，每次有相应的活动时，这部分标签显得尤为重要，它是运营看指标和效果的体现，也是老板们计划下次掏钱时心理的底线。活动类，我们计算中可能跟日常的转化留存思路不一样，主要聚焦范围时间内的短期目标，所以这里可以单独来处理特定的活动逻辑，而且可以从中提炼对后续有指导的部分标签，这些都是相辅相成的。

5.风险与问题

5.1 实时分层能力建设

  通过上述的计算流程和相关指标的计算，大家可以发现实时画像在具体的实践中会有很多问题，因为我们没有一套完整的体系来融入这个过程，所以这部分需要与实时数仓的分层做一定的结合。之后，在我们呢有了实时数据的分层和整体建设较为完整的实时数据之后，再来看整个画像，其实就能够有一个较为直观的认识了。

5.2 实时计算逻辑抽象

  在有了实时分层的数据能力后，我们需要关注的点落到了如果来对数据进行实时的计算，看完上面的部分，想必大家已经有了一些思路，无非是在流里面做或者抽象到流外部来做，这里还会涉及到全量和增量数据的问题。想快，用增量，但怎么结合还需慎重思考。流里面适合的是基础标签这种关联表较少的且维度表不宜过大，而外部计算，则是全量join，无非是我们要做好数据落地的一些查询性能优化。增量join，我想以实时表为增量，然后再去与动态变化的其他表join，是否可以解决全量的数据重复计算问题呢，又是否会因为标签状态的过期于删除问题，我想这里还需要一些时间的尝试。

6.小结

  本文初步介绍了实时用户画像建设中初步遇到和思考的一些问题，大部分都是初次探索的一个过程，如有个人理解和不到之处，还望大家多多批评指正。下一篇，我们就第一版方案开展过程中存在的问题来详细展开。希望这次的你，下次也能不见不散哦~~~