【沙龙干货】主题二:一个用户行为分析产品的设计与实现

分享内容


今天想跟大家分享一下我们目前推出的一个海量用户行为分析产品---“神策分析”的设计与实现。由于脱离需求和产品谈技术是不合时宜的,所以我首先会先讲一下我们产品所面临的用户需求,我们是如何根据这些用户需求来确定我们的产品设计,以及这些产品设计对于技术选型的一些要求,后面再详细讲一下我们产品整体架构和技术实现。

简单来看我们的产品面临的第一个需求,我们的客户普遍需要一个可以私有化部署的用户行为分析产品,这个需求是可以理解的,也是有很多实际的原因:首先是出于对数据安全和隐私的考虑;其次则是希望能够完成数据资产的积累;第三个则是希望可以对数据做深度的应用与二次开发,满足数据的更高阶的应用需求,而这些都是只有私有化部署才能够满足的。因此,私有化部署是客户对产品的一个非常实际的需求,也我们产品和技术上带来一些挑战。

首先我们做设计和开发的时候,需要考虑因为私有部署所带来的对运维、部署和设计的技术挑战,我们整个开发过程中,有至少三分之一的精力花在解决私有化部署带来的这些技术挑战上;另外一个方面,做整个产品架构设计的时候,就要考虑数据、API、计算和存储资源的开放,要让每个环节都能开放出去给用户使用;第三点,则是让我们决定整个架构以开源技术为主,如果选择一些非常冷门的技术,可能别人在这个基础上做二次开发是一个很难的事情;第四点则是为了满足客户的积累数据资产的需求,我们需要能够向用户提供明细数据,提供最细力度数据,这也是最终决定我们存储选型的一个关键性因素。

到了现在这个年代,特别是移动互联网、O2O已经蓬勃发展了这么多年,每一个产品的业务都越来越复杂,线下成分越来越重,因此全端的数据采集会是一个非常常见的需求。所谓的全端数据采集,就是要打通一个真实用户在不同端的行为,可能是iOS、安卓、Web、微信,也可能是业务数据库、第三方服务,需要能够把同一个用户在这些不同端的行为都贯通起来,一起进行分析和处理。为了满足的这一个需求,我们提供了各种不同的埋点和数据采集的手段,并且需要有一个技术手段来管理这些埋点。与此同时,我们也为客户提供了 ID-MAPPING 功能。在这里,我们对需求做了一个折中,为了保证我们的秒级导入时效性,ID-MAPPING不能向前回溯数据,因此我们选择了牺牲ID-MAPPING的部分功能而保留数据的导入时效性,这是一个客户需求与最终技术实现相互折中的一个最终例子。

我们目前有了如下的一些核心的技术决策,首先我们的产品要能私有化部署,并且花了很大的代价来解决运维的问题;其次,我们要做一个全开放的PaaS 平台,以开源技术为主,便于用户做二次开发;第三,我们要能够保证在十亿数据量下秒级导入、秒级查询的时效性。因此,我们最终没有选择预先聚合数据,而是存储明细数据,也就是说存储一条条最明细的数据,在 MOLAP 与 ROLAP 的抉择之间,我们选择了ROLAP的方案。

前边是对我们产品跟设计的一个简单的回顾,后面主要讲产品的具体技术实现。

我们在做客户端数据采集的时候,对于数据发送策略要做很多很多优化。我这里边详细列了一下我们目前所做的优化的策略,首先是我们整个数据采集策略的核心,以保证用户体验为核心,在用户体验和数据采集的时效性两方面的抉择上,宁愿牺牲部分数据采集的时效性,以保证不影响用户正常使用APP的体验。首先我们数据并不会逐条的实时的向后台发送,先在本地做缓存,网络情况比较好的时候才会往后面发送数据,发送数据的时候也会做一些打包压缩的情况。

后端日志也是比较常用的一种需要采集的数据。采集方案有两种,一种是在模块里面用代码的方式直接调用数据采用的API。之前我们提供了一整套日志打印的库,可以让这个日志直接打印到后台数据仓库里面,并且是以格式化的方式打印,从而保证一条日志在打印之后几分钟就已经能够被查询到。另外一种方案则是为了减少我们业务模块跟后面数据仓库的耦合性,会选择先在业务模块打印文本或者格式化的日志,然后用LogAgent 的方式将这些日志向数据仓库发送。

除了后端日志跟前端操作,业务数据也是一种比较常见的需要采集的数据源,主要通过工具采数据。

我们的数据接入层,因为我们要支持前端采集并通过公网传输数据,所我们的API采用了 HTTP 协议,所以这是一个很好的选择。

这里我们选择了Nginx做数据接入服务,在只需要接收 HTTP 请求并且打印日志的情况下,Nginx 可以保证很好的可靠性、很高的性能。能够很轻松满足单台接收十几万条用户行为的需求,能够满足绝大多数产品的需要。同时Nginx也能很容易做到负载均衡和服务冗余,这方面有很多成熟的方案。

然后我们有一个模块叫做 Extractor,它会实时读取和处理Nginx日志,然后把处理结果发送到kafka。

我们所有的数据都是要发到KAFKA,是一个高可用的数据分布式队列,用它是作为数据接入与数据处理之间的缓冲,也是数据的一个暂存,并且可以对外提供访问。

怎么样把KAFKA里面的数据实时写到我们的存储系统里面?

在存储上,我们选择了 Kudu 和 Parquet 两个存储方案。其中,Kudu 被我们用作 WOS,响应实时的写入。Parquet 被我们用作 ROS,保证良好的查询性能。下面是我们的整个存储写入的流程图。简单的来说我们有一个模块叫 KafkaConsumer,是一个常驻内存的 MapReduce程序,会实时地从kafka订阅数据,并将数据实时写入到Kudu中。在Kudu中有两类表,一类是正在被写入,另一类则是不再被写入。当一张表的写入数据量达到阈值时,它就不再会被写入,而是会写入新的表中。每一个不再被写入的 Kudu 表,都会被一个后台程序转换成Parquet文件,并且移动到相应的一系列Partition中。由于这种操作过程,每一个Partition下都可能会有一系列碎文件,则我们后台会有一个定时的 MapReduce程序,用来将碎文件合并成理想大小的文件,目前我们在多次尝试后,选择了 512MB 作为一个比较理想的文件大小,从而提高查询和扫描的速度。

我们跟用户打交道的一个模块是WebServer,它是用来转发前端查询请求的,会接收客户通过我们前端发送过来的查询请求。当然,前端也提供了相应的 API,以满足客户的二次开发需求。WebServer会把这个查询请求转发给QueryEngine,后者会将查询请求翻译成SQL提交给Impala。Impala是一个目前很流行的 MPP 架构的分布式计算系统。前面我们提到,数据是存储在Kudu和Parquet两个存储体系里面,所以在这里我们将他们构建了一个视图,让Impala直接在这个视图上面进行查询,然后把查询的结果返回给前端。

原文发布于微信公众号 - 美团点评技术团队(meituantech)

原文发表时间:2016-08-05

本文参与腾讯云自媒体分享计划,欢迎正在阅读的你也加入,一起分享。

发表于

我来说两句

0 条评论
登录 后参与评论

相关文章

来自专栏QQ会员技术团队的专栏

大规模排行榜系统实践及挑战

在过去的一年中,排行榜系统从无到有,接入的业务从单一的QQ会员到企鹅电竞动漫等20几个各类业务,接入的排行榜数实现了从几个到数万的突破,单个排行榜用户数最大90...

3.5K1
来自专栏ITCloud的专栏

聊聊腾讯云TStack上云Oracle的应用

能否利用TStack的计算、网络和存储能力,将Oracle运行在X86服务器,IP网络,云存储的“云化”架构上,去掉IOE架构中的I和E呢?

9.4K1
来自专栏非著名程序员

十大技巧快速提升原生APP开发性能

移动应用市场用户争夺战日益激烈,原来做APP拼想法拼创意拼是否抓住用户痛点。现在,精细化用户体验成为了一个APP能否留存用户的关键问题,一旦用户觉得体验不畅,马...

18510
来自专栏ImportSource

微服务与API 网关(上): 为什么需要API网关?

本文是来自于Macro在一次大会上的一个分享。 本系列共有两个部分,主要关注我们如何以及为什么要在我们的微服务应用中部署API 网关。第二部分主要关注我们如何把...

4016
来自专栏BestSDK

十大技巧快速提升原生APP开发性能

编辑导语 移动应用市场用户争夺战日益激烈,原来做APP拼想法拼创意拼是否抓住用户痛点。现在,精细化用户体验成为了一个APP能否留存用户的关键问题,一旦用户觉得体...

2259
来自专栏架构师小秘圈

互联网分层架构,为啥要前后端分离?

作者:58神剑,来源:架构师之路 一,典型后端架构 ? 通用业务服务化之后,系统的典型后端结构如上: web-server通过RPC接口,从通用业务服务获取数据...

3485
来自专栏杨建荣的学习笔记

Datapump数据迁移的实践总结 (r9笔记第60天)

虽说实践了不少的数据迁移项目,但是从我的感触来说,一些很细小的差别就会造成整个数据迁移方案的大不同。数据是系统的核心命脉,所以对于DBA来说,保证数据...

2493
来自专栏技术翻译

为什么使用微型服务?

Netflix,亚马逊等公司都在其产品中采用了微服务的概念。微服务是软件行业中最热门的话题之一,许多组织都希望采用它们。并且,DevOps可以很好地与微服务配合...

832
来自专栏java一日一条

大型分布式网站架构技术总结

本文是学习大型分布式网站架构的技术总结。对架构一个高性能,高可用,可伸缩,可扩展的分布式网站进行了概要性描述,并给出一个架构参考。一部分为读书笔记,一部分是个人...

422
来自专栏云加新鲜事儿

腾讯云多Kubernetes的多维度监控实践

本次分享的主要内容涉及腾讯云容器的顶层整体设计,包括产品功能,及提供的附加能力。同时会介绍我们现在Master集群化部署的整体方案。

7050

扫描关注云+社区