UAS:大众点评用户行为系统

标签: dev | 发表时间:2018-07-08 00:00 | 作者:
出处:http://itindex.net/relian

背景

随着整个中国互联网下半场的到来,用户红利所剩无几,原来粗放式的发展模式已经行不通,企业的发展越来越趋向于精耕细作。美团的价值观提倡以客户为中心,面对海量的用户行为数据,如何利用好这些数据,并通过技术手段发挥出数据的价值,提高用户的使用体验,是我们技术团队未来工作的重点。

大众点评在精细化运营层面进行了很多深度的思考,我们根据用户在App内的操作行为的频次和周期等数据,给用户划分了不同的生命周期,并且针对用户所处生命周期,制定了不同的运营策略,比如针对成长期的用户,主要运营方向是让其了解平台的核心功能,提高认知,比如写点评、分享、收藏等。同时,我们还需要为新激活用户提供即时激励,这对时效性的要求很高,从用户的行为发生到激励的下发,需要在毫秒级别完成,才能有效提升新用户的留存率。

所以,针对这些精细化的运营场景,我们需要能够实时感知用户的行为,构建用户的实时画像。此外,面对大众点评超大数据流量的冲击,我们还要保证时效性和稳定性,这对系统也提出了非常高的要求。在这样的背景下,我们搭建了一套用户行为系统(User Action System,以下简称UAS)。

面临的问题

如何实时加工处理海量的用户行为数据,我们面临以下几个问题:

  1. 上报不规范:点评平台业务繁多,用户在业务上产生的行为分散在四处,格式不统一,有些行为消息是基于自研消息中间件Mafka/Swallow,有些行为消息是基于流量打点的Kafka消息,还有一些行为没有对应的业务消息,收集处理工作是一个难点。

  2. 上报时效性差:目前大部分行为,我们通过后台业务消息方式进行收集,但是部分行为我们通过公司统一的流量打点体系进行收集,但是流量打点收集在一些场景下,无法满足我们的时效性要求,如何保证收集处理的时效性,我们需要格外关注。

  3. 查询多样化:收集好行为数据之后,各个业务对用户行为的查询存在差异化,比如对行为次数的统计,不同业务有自己的统计逻辑。无法满足现有业务系统的查询需求,如何让系统既统一又灵活?这对我们的业务架构能力提出了新要求。

针对问题模型,方案思考


格式统一

面对繁杂的格式,我们如何进行统一?在这里我们参考了5W1H模型,将用户的行为抽象为以下几大要素:

其中行为作用的地方,这里一般都是作用对象的ID,比如商户ID,评论ID等等。行为的属性,代表的是行为发生的一些额外属性,比如浏览商户的商户品类、签到商家的城市等。

上报统一

对于用户行为的上报,之前的状态基本只有基于流量打点的上报,虽然上报的格式较为标准化,但是存在上报延时,数据丢失的情况,不能作为主要的上报渠道,因此我们自建了其他的上报渠道,通过维护一个通用的MAPI上报通道,直接从客户端通过专有的长连接通道进行上报,保证数据的时效性,上报后的数据处理之后,进行了标准化,再以消息的形式传播出去,并且按照一定的维度,进行了TOPIC的拆分。目前我们是两个上报通道在不同场景使用,对外是无感知的。

服务统一

不同场景下,对用户行为处理的数据规模要求,时效性要求也是不一样的,比如有些场景需要在用户行为上报之后,立刻做相关的查询,因此写入和查询的性能要求很高,有些场景下,只需要进行行为的写入,就可以采取异步的方式写入,针对这样不同的场景,我们有不同的解决方案,但是我们统一对外提供的还是UAS服务。

架构统一

从数据的收集上报,到处理分发,到业务加工,到持久化,UAS系统架构需要做到有机的统一,既要能满足日益增长的数据需求,同时也要能够给业务充分的灵活性,起到数据中台的作用,方便各个业务基于现有的架构上,进行快速灵活的开发,满足高速发展的业务。

系统整体架构

针对这样的一些想法,开始搭建我们的UAS系统,下图是UAS系统目前的整体架构:

数据源简介

我们处理的数据源分为实时数据源和离线数据源:

  1. 实时数据源主要分两块,一块是基于客户端打点上报,另外一块是我们的后台消息,这两部分是基于公司的消息中间件Mafka和开源消息中间件Kafka,以消息的形式上报上来,方便我们后续的处理,MQ的方式能够让系统更好的解耦,并且具备更高的吞吐量,还可以指定消费的起始时间点,做到消息的回溯。

  2. 历史数据的来源主要是我们的Hive和HDFS,可以方便的做到大数据量的存储和并行计算。

离线计算简介

在离线处理这块,主要包含了MR模块和Spark模块,我们的一些ETL操作,就是基于MR模块的,一些用户行为数据的深度分析,会基于Spark去做,其中我们还有一个XT平台,是美团点评内部基于Hive搭建的ETL平台,它主要用来开发数据处理任务和数据传输任务,并且配置相关的任务调度信息。

实时计算简介

对于用户行为的实时数据处理,我们使用的是Storm实时大数据处理框架,Storm中的Spout可以方便的对接我们的实时消息队列,在Bolt中处理我们的业务逻辑,通过流的形式,可以方便的做到业务数据的分流、处理、汇聚,并且保持它的时效性。而且Storm也有比较好的心跳检测机制,在Worker挂了之后,可以做到自动重启,保证任务不挂,同时Storm的Acker机制,可以保持我们实时处理的可靠性。

接下来,我们按照用户行为数据的处理和存储来详细介绍我们的系统。

数据的处理

离线处理

离线数据的处理,主要依赖的是我们的数据开发同学,在构建用户行为的数据仓库时,我们会遵循一套美团点评的数据仓库分层体系。

同时我们会出一些比较通用的数据,方便线上用户使用,比如我们会根据用户的行为,发放勋章奖励,其中一个勋章的发放条件是用户过去30天的浏览商户数量,我们不会直接出一个30天的聚合数据,而是以天为周期,做一次聚合,然后再把30天的数据聚合,这样比较通用灵活一些,上层应用可以按照自己的业务需求,进行一些其他时间段的聚合。

在数据的导入中,我们也有不同的策略:

  1. 比如用户的行为路径分析中,我们在Hive中计算好的结果,数据量是非常庞大的,但是Hive本身的设计无法满足我们的查询时效性要求,为了后台系统有比较好的体验,我们会把数据导入到ES中,这里我们无需全量导入,只要抽样导入即可,这样在满足我们的查询要求的同时也能提高我们的查询效率。

  2. 在导入到一些其他存储介质中,传输的效率有时候会成为我们的瓶颈,比如我们导入到Cellar中,数据量大,写入效率也不高,针对这种情况,我们会采用增量导入的方式,每次导入的数据都是有发生变化的,这样我们的导入数据量会减少,从而减小我们的传输耗时。

实时处理

实时处理这块,我们构建了基于点评全网的流量网关,所有用户产生的行为数据,都会通过实时上报通道进行上报,并且会在我们的网关中流转,我们在这里对行为数据,做一些加工。

Reader

我们目前使用的是Storm的Spout组件对接我们的实时消息,基于抽象的接口,未来可以扩展更多的数据来源,比如数据库、文件系统等。

Parser

Parser是我们的解析模块,主要具备以下功能:

  1. 我们会对字段做一些兼容,不同版本的打点数据可能会有差异。

  2. JSON串的处理,对于多层的JSON串进行处理,使得后续可以正常解析。

  3. 时间解析,对于不同格式的的上报时间进行兼容统一。

Transformer

Transformer是我们的转换模块,它是一种更加高级的处理过程,能够提供给业务进行灵活的行为属性扩展:

  1. 比如需要根据商户ID转换出商户的星级、品类等其他信息,我们可以在我们的明细扩展层配置一个Transformer。

  2. 或者业务有自己的转换规则,比如他需要把一些字段进行合并、拆分、转换,都可以通过一个Transformer模块,解决这个问题。

Sender

Sender是我们的发送模块,将处理好的数据,按照不同的业务数据流,进行转发,一般我们是发送到消息队列中,Sender模块,可以指定发送的格式、字段名称等。

目前我们的实时处理,基本上已经做到可视化的配置,之前需要几人日才能做到的用户行为数据分发和处理,现在从配置到验证上线只需要几分钟左右。

近实时处理

在近线计算中,我们会把经过流量网关的数据,通过Kafka2Hive的流程,写入到我们的Hive中,整个过程的时延不超过15分钟,我们的算法同学,可以利用这样一些近实时的数据,再结合其他的海量数据,进行整体的加工、存储,主要针对的是一些时效性要求不高的场景。

通过上面三套处理方法,离线、实时、近实时,我们可以很好的满足业务不同的时效性需求。

数据的存储

经过实时处理之后,基本上已经是我们认为的标准化数据,我们会对这些数据进行明细存储和聚合存储:

明细存储

明细的存储,是为了保证我的数据存储,能够满足业务的查询需求,这些明细数据,主要是用户的一些核心操作行为,比如分享、浏览、点击、签到等,这些数据我们会按照一定的粒度拆分,存储在不同的搜索集群中,并且有有一定的过期机制。

上图是我们的处理方式:

  1. 通过Transformer,业务方可以通过自己的服务,对数据的维度进行扩展,从而Sender发出的Message就是满足业务需求的数据。

  2. 然后在Kafka2Hive这一步,会去更新对应的Hive表结构,支持新的扩展数据字段,同时在XT作业中,可以通过表的关联,把新扩展的字段进行补齐。

  3. 重跑我们的历史之后,全量数据就是已经扩展好的字段。同时,实时数据的写入,也是扩展之后的字段,至此完成了字段的扩展。

NoSQL存储

通过明细数据的存储,我们可以解决大部分问题。虽然搜索支持的查询方式比较灵活,但是某些情况下,查询效率会较慢,平均响应时间在20ms左右,对一些高性能的场景,或者一些基础的用户行为画像,这个响应时间显然是偏高的。因此我们引入了NoSQL的存储,使用公司的存储中间件Squirrel和Cellar,其中Cellar是基于淘宝开源的Tair进行开发的,而Squirrel是基于RedisCluster进行开发的,两者的差异就不在此赘述,简单讲一下我们的使用场景:

  1. 对于冷热比较分明,单个数据不是很大(小于20KB,过大会影响查询效率),并且value不是复杂的,我们会使用Cellar,比如一些低频次的用户行为数据。

  2. 在大并发下,对于延迟要求极为敏感,我们会使用Redis。

  3. 对于一些复杂的数据结构,我们会使用到Redis,比如我们会用到Redis封装好的HyperLogLog算法,进行数据的统计处理。

系统特性

灵活性

构建系统的灵活性,可以从以下几个方面入手:

  1. 对用户的行为数据,可以通过Transformer组件进行数据扩展,从而满足业务的需求,业务只需要开发一个扩展接口即可。

  2. 第二个方面就是查询,我们支持业务方以服务注册的方式,去编写自己的查询逻辑,或者以插件的形式,托管在UAS平台,去实现自己负责的业务逻辑,比如同样一个浏览商户行为,有些业务的逻辑是需要看某批用户最近7天看了多少家3星商户,并且按照shopID去重,有些业务逻辑可能是需要看某批用户最近7天浏览了多少个品类的商户。因此这些业务复杂的逻辑可以直接托管在我们这里,对外的接口吐出基本是一致的,做到服务的统一。

  3. 我们系统目前从实时分发/计算/统计/存储/服务提供,是一套比较完备的系统,在不同的处理阶段,都可以有不同的组件/技术选型,根据业务的需求,我们可以做到灵活的组合、搭配。

低延时

对于一些跨周期非常长,存储非常大的数据,我们采用了Lambda架构,既保证了数据的完备性又做到了数据的时效性。其中Batch Layer为批处理层,会有固定的计算视图,对历史数据进行预计算,生成离线结果;Speed Layer为实时计算层,对实时数据进行计算,生成增量的结果,最终Server Layer合并两个视图的数据集,从而来提供服务。

可用性

数据可用性

前面提到了我们采用Lambda架构处理一些数据,但是离线数据有时候会因为上游的一些原因,处理不稳定,导致产出延迟,这个时候为了保证数据的准确性,我们在Speed Layer会多保留两天的数据 ,保证覆盖到全量数据。如图所示:

服务的可用性

在服务的可用性方面,我们对接入的服务进行了鉴权,保证服务的安全可靠,部分核心行为,我们做了物理上的隔离,保证行为数据之间不会相互影响,同时接入了公司内部基于Docker的容器管理和可伸缩平台HULK, 能做到自动扩容。对于数据使用有严格权限审计,并且做了相关数据脱敏工作。

监控

从用户行为数据的产生,到收集分发,到最后的处理,我们都做到了相关的监控,比如因为代码改动,发生处理时长变长,我们可以立马收到相关的报警,检查是不是代码出问题了。或者监控到的行为产生次数和历史基线比,发生较大变化,我们也会去追踪定位问题,甚至可以早于业务先发现相关问题。下图是分享商户行为的一个监控:

结语

用户行为系统搭建之后,目前:

  1. 处理的上报数据量日均在45+亿。

  2. 核心行为的上报延迟从秒级降低到毫秒级。

  3. 收录用户行为数十项,提供用户行为实时流。

  4. 提供多维度下的实时服务,日均调用量在15亿左右,平均响应时间在3ms,99线在10ms。

目前系统承载的业务还在不断增长中,相比以前的T+1服务延时,大大提升了用户体验。我们希望构建用户行为的中台系统,通过我们已经抽象出的基础能力,解决业务80%的问题,业务可以通过插件或者接口的形式,在我们的中台上解决自己个性化的问题。

未来展望

目前我们的实时计算视图,比较简单,做的是相对比较通用的聚合计算,但是业务的聚合规则可能是比较复杂且多变的,不一定是直接累加,未来我们希望在聚合计算这块,也能直接通过配置的方式,得到业务自定义的聚合数据,快速满足线上业务需求。

同时,用户的实时行为会流经我们的网关,我们对用户行为进行一些特征处理之后,结合用户过去的一些画像数据,进行用户意图的猜测,这种猜测是可以更加贴近业务的。

作者简介

朱凯,资深工程师,2014年加入大众点评,先后从事过账号端/商家端的开发,有着丰富的后台开发架构经验,同时对实时数据处理领域方法有较深入的理解。目前在点评平台负责运营业务相关的研发工作,构建精细化运营的底层数据驱动能力,着力提升用户运营效率。

如果你想近距离与我们的作者沟通、交流,请来GitChat,点击“免费预订”即可参与读者交流, 报名 链接


----------  END  ----------


相关 [uas 大众点评 用户] 推荐:

UAS:大众点评用户行为系统

- - IT瘾-dev
随着整个中国互联网下半场的到来,用户红利所剩无几,原来粗放式的发展模式已经行不通,企业的发展越来越趋向于精耕细作. 美团的价值观提倡以客户为中心,面对海量的用户行为数据,如何利用好这些数据,并通过技术手段发挥出数据的价值,提高用户的使用体验,是我们技术团队未来工作的重点. 大众点评在精细化运营层面进行了很多深度的思考,我们根据用户在App内的操作行为的频次和周期等数据,给用户划分了不同的生命周期,并且针对用户所处生命周期,制定了不同的运营策略,比如针对成长期的用户,主要运营方向是让其了解平台的核心功能,提高认知,比如写点评、分享、收藏等.

2010:数字盘点大众点评

- - 互联网旁观者
说明:这是一篇旧闻了,转载自大众点评的官方博客( http://blog.dianping.com/archives/77),基本数据还是很有参考意义的. 2010年,有您的支持和关注,大众点评网的各项业务获得高速发展:网站访问获得持续快速增长,成功开拓了团购这一新兴用户服务,并在手机应用这一新兴平台取得了一系列的突破.

Android 大众点评的接入

- - CSDN博客推荐文章
这里介绍的是大众点评的团购中的一个接口,就是所有团购信息,其他的接口的实现是大同小异的. 首先,登录大众点评的开发平台-> 大众点评 . 然后获取到自己的应用的appkey和secret,这个是开发必备的. 可以下载大众点评提供的demo-> demo . DZDPApiTool.java 大众点评提供的Api工具类(请求api -> requestApi这个方法).

口碑网VS大众点评,我的生活谁做主?大众点评!

- wangjia - Tech2IPO
HT实验室观点:口碑网与大众点评均是生活服务类软件,也都是希望为消费者提供一个评论分享、消费指南的平台. 且不管两家在线上线下的服务及数据库等建设如何,就安卓版的App本身来看,大众点评能给用户带来的帮助更大,其用户体验也更好. 因此可以说,我们的生活,暂且应该由大众点评来做主. 大众点评网的定位是“中国最大的本地搜索和城市消费门户网站”;口碑网的定位是“致力于打造生活服务领域的电子商务第一品牌”,并号称是“中国最大的生活搜索引擎”.

戴志康:“撼动大众点评”是个伪命题

- - 产品市场 - UCD大社区
我认为不要去撼动大众点评,它那个就像一本新华字典一样,你碰到不会的字词打开它看看. 所以我认为用大众点评的方式去打败大众点评,这是不可能的,也没必要去探讨. 能探讨的是,我们怎么样用一种差异化的方式在这个市场中赢得自己的一席之地. 口述/腾讯电商控股公司 戴志康. (本文是腾讯电商控股公司、discuz创始人戴志康在“产品家”沙龙的发言).

大众点评网:做O2O+LBS的精准营销

- - 行业资讯
   ●团购是最经典的O2O模式代表,但很多来也匆匆去也匆匆. 李开复曾在专栏公开发文说,“99%的团购网站都要死,不过大众点评例外.   ●底气何来?大众点评网创始人及CEO张涛称,“8年抗战都胜利了,我们坚持了9年. O2O加上LBS,绝对让大众点评如虎添翼.   ●O2O的实质是将发展线下商户、在线支付、营销效果检测这三件事在互联网上有了一个很好的结合.

大众点评数据平台架构变迁

- - leejun_2005的个人页面
最近和其他公司的同学对数据平台的发展题做了一些沟通,发现各自遇到的问题都类似,架构的变迁也有一定的相似性. 以下从 数据&架构&应用的角度对2012.07-2014.12期间大众点评数据平台的架构变迁做一个概括性的总结,希望对还处在数据平台发展初期的同学有一些帮助,欢迎线下沟通. 模型计算程序以python为主.

【干货】大众点评运维架构的图文详解

- - 运维技术的个人空间
今天分享专题大纲如图所示,从5个方面跟大家一起探讨:. 目前我们运维分为4个组,相信跟大部分公司一样,运维团队分为:应用运维、系统运维、运维开发和监控运维,当然还有DBA团队和安全团队,这里就不一一罗列了. 整个运维团队全算上目前是不到40人规模. 应用运维:负责支持线上业务,各自会负责对应的业务线,主要职能是保证线上业务稳定性和同开发共同支撑对应业务,以及线上服务管理和持续优化.

大众点评订单系统分库分表实践

- - 美团点评技术团队
原大众点评的订单单表早就已经突破两百G,由于查询维度较多,即使加了两个从库,优化索引,仍然存在很多查询不理想的情况. 去年大量抢购活动的开展,使数据库达到瓶颈,应用只能通过限速、异步队列等对其进行保护;业务需求层出不穷,原有的订单模型很难满足业务需求,但是基于原订单表的DDL又非常吃力,无法达到业务要求.

开发者眼中的大众点评开放平台:欲迎还拒

- - ITeye资讯频道
在经过了数月准备之后,大众点评正式宣布开放平台( developer.dianping.com). 这家被称为“慢公司”的互联网公司终于走出了开放的第一步,开始向第三方开放本地商户信息、最新点评、优惠、团购等内容. 一位开发者在详细了解开放细则之后向新浪科技深度吐槽,分享他眼中的大众点评开放平台. 以下为开发者口述,新浪创事记整理.