UAS-点评侧用户行为检索系统

背景

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

大众点评在精细化运营层面进行了不少深度的思考，咱们根据用户在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是基于Redis-cluster进行开发的，二者的差别就不在此赘述，简单讲一下咱们的使用场景：

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年加入大众点评，前后从事过帐号端/商家端的开发，有着丰富的后台开发架构经验，同时对实时数据处理领域方法有较深刻的理解，目前在点评平台负责运营业务相关的研发工做，构建精细化运营的底层数据驱动能力，着力提高用户运营效率。重点打造点评平台数据中台产品——灯塔。