朱凯:侧用户行为检索系统实战解析

向作者提问
美团技术团队官方账号
查看本场Chat

2018年7月9日,周一晚20:30,美团高级工程师朱凯带来了主题为《点评侧用户行为检索系统》的交流。以下是主持人张帅整理的问答实录,记录了作者和读者间问答的精彩时刻。


  • UAS的使用场景主要有哪些?
  • 为什么不直接聚合出30天数据,而要分历史层和实时层?
  • 实时处理中对海量数据的统计去重是如何做的?
  • 怎么通过脚本给用户打标签?
  • 简单介绍下整个系统的架构,用的技术框架有哪些?
  • 是通过什么数据库来保存用户标签的?
  • 详细解释下 T+1 作业可以吗?
  • 数据库选型有什么建议?
  • 后面 Storm 会转 Spark 体系吗?
  • 离线模型上传到 JStorm的实时场景时,对离线模型有哪些好的打包方式或者处理方式?
  • 目前这个系统所用到的服务器配置架构大概是什么模型?什么样的量级分别使用什么样的架构?
  • 实时场景都是直接实时训练模型吗?

问:UAS 的使用场景主要有哪些?
答: UAS 作为用户行为系统,主要应用场景有两个:

  1. 在精细化运营的场景下,我们需要根据用户的行为画像,去构建一些运营场景,比如引导用户完成核心行为,完成之后给他下发奖励,通过这样的方式,提高用户的核心行为的次数,从而提升用户的留存,达到促活的目的;

  2. 在搜索和推荐场景下,需要根据用户的一些实时行为,比如浏览商户等,来实时变更推荐结果,以更加符合用户的意图。或者浏览了但是未购买,会理解到用户的意图,做一些券的营销和推荐。


问:为什么不直接聚合出30天数据,而要分历史层和实时层?

答:这里首先解释一下30天数据的概念,也就我们会看用户最近30天一些行为的次数,这些次数直接决定了用户的生命周期(俗称魔数)这里是借鉴了 Lambda 架构的思想,如果直接出30天聚合数据,会有以下几个问题:历史数据跨度大,直接查询有性能问题;如果用 T+1 作业的方式,数据的时效性不满足需求。

通过 Lambda 架构,我们可以解耦为历史数据和实时数据,历史数据专注做过去一段时间数据的聚合,如果聚合逻辑有变更或者有问题,也可以根据明细数据重跑,实时数据存放最近几天的数据,做最近几天数据的聚合,然后将两部分数据合并。能够方便的满足一些固定时间跨度的查询。


问:实时处理中对海量数据的统计去重是如何做的?

答:我们分为两步,第一步是在内存中进行去重统计,达到一定的数据量或者一定的时间之后,对内存数据刷新。第二步写入存储,刷新的数据,我们写进入到 Redis,这块我们利用的是 Redis 的 HyperLogLog 算法,在基数统计的领域应用比较广泛,精度高并且占用的存储少。


问:怎么通过脚本给用户打标签?

答:这个其实是数据挖掘领域的问题,不在我们这个范围内,但是我可以简单解答一下。我们一般是通过一些 ETL 作业,根据一定的算法,根据的行为分布等因素,打上相应的标签。


问:简单介绍下整个系统的架构,用的技术框架有哪些?

答:系统的架构,可以看一下我的文章,主要用到的技术框架还是 Storm 进行实时数据处理,Hadoop 做离线处理,数据存储使用到的中间件是 Tair,RPC 服务用到的是公司自研的 Piegon。


问:是通过什么数据库来保存用户标签的,MongoDB 吗?

答:这个其实要看使用的场景,如果是通过人来查这个人的标签,标签数量不多,其实 MySQL 足矣,但是如果是一些标签量很多,并且请求的量很大,这个时候可以用一些分布式存储比如 Redis,Tair。通过标签值的压缩,可以提高请求的性能。

如果是通过标签来查人,并且支持人的数量速查,这个时候用 ES 比较好。所以使用什么存储,不是一成不变的,还是要结合使用的场景,在不同的场景下用不同的存储。


问:详细解释下T+1作业可以吗?

答: T+1作业其实就是 MapReduce 作业,我们的明细历史数据都是存储在 Hive 中的,然后通过 MapReduce 作业进行计算,这样的话,我们只能在今天算昨天的数据,我们一般叫 T+1 作业,当然也有公司喊 T-1。


问:数据库选型有什么建议?

答:这个问题,其实刚才有涉及到,如果你的数据量很小,QPS 很低,可以收集一个埋点就计算存储一次,用 MySQL 存储就可以,而对我们来说 QPS 很高,对一些抢购活动,页面的 PV/UV 很高。我们分为三步,第一步是在内存中进行去重统计,达到一定的数据量或者一定的时间之后,对内存数据刷新。第二步写入存储,刷新的数据,我们写进入到 Redis,这块我们利用的是 Redis 的 HyperLogLog 算法。第三步,是把数据持久化下来,做报表展示。


问:后面 Storm 会转 Spark 体系吗?

答:目前不会的,其实不同的 流计算引擎各有长短,目前我们对 Flink 关注比较多,它有更加有好的状态恢复机制(checkPoint),同时天然支持到滑动窗口/滚动窗口。


问:离线模型上传到 JStorm的实时场景时,对离线模型有哪些好的打包方式或者处理方式?

答:目前我们的实时模型和离线模型是分开的,因此没有直接把离线模型打包,JStrom 也是阿里比较老的 Strom 优化版本了,我们没有使用。


问:目前这个系统所用到的服务器配置架构大概是什么模型?什么样的量级分别使用什么样的架构?

答:这里的确是需要看你处理的用户数据量的量级,我们 UAS 的定位是用户行为的快速检索,在少量数据可以直接用 KV 的存储+RPC 服务即可, 如果数据的量级越来越大,我们会对 K 进行拆分,保证 V 不过大,保证快速的检索。


问:实时场景都是直接实时训练模型吗?

答:这里我理解这个同学其实想问的是一些模型训练的问题,这块其实我们目前大部分都是离线训练,实时做的是事情比较简单,也会按照一定的衰减因子做一些模型的整合,但是不存在直接把离线模型应用在实时模型上的情况。


本文首发于Gitchat,未经授权不得转载,转载需要与GitChat联系。

微信扫描登录