个性化离线实时分析系统pora

标签: 分布式技术 hbase storm ups 个性化搜索 | 发表时间:2012-11-26 09:58 | 作者:悟时
出处:http://www.searchtb.com

1.业务场景
伴随着市场和技术的发展,个性化已经成为淘宝搜索的一个重要目标。简单来说,个性化就是让每个用户在使用淘宝搜索时都能够获取自己最想要的结果,而不再是千篇一律的展示。实现个性化最直接的手段就是通过分析用户的历史行为日志,为用户打上不同的标签,在搜索中根据这些标签来展示最贴近的结果。
在淘宝,用户属性分析是通过每天在云梯上定时运行的map reduce job来完成的,产出结果导入我们的在线kv存储ups中,搜索引擎通过查询ups获取用户属性来为用户返回个性化的结果。在云梯上执行的全量计算能够进行复杂的模型计算,并且由于利用了云梯强大的计算能力,计算全部用户几十天的日志也只需花费几个小时。
全量计算的不足之处在每次计算的输入数据都是前一天到前N天的日志,无法将用户当天的行为考虑进去,因此得到的用户属性永远是滞后一天的,无法将某些用户当前的属性很好地反映出来。实时增量弥补了这一空缺,通过实时分析用户的行为日志,将最新的用户属性反馈给搜索引擎,能够为用户展现最贴近其当前需求的结果。

2.系统需求
结合我们的业务场景和现状,对实时分析系统大致有以下几点需求。
(1)不影响在线查询的效率。这是一个最基本的需求,也决定了我们系统的定位:离线分析,将相对较重的分析过程放在离线阶段完成,在线过程只需要查询离线计算产出的结果即可。
(2)实时。既然称为实时系统,这也是一个起码的要求。至于要多实时,初步的目标是从用户一次行为发生到最后的属性更新在几秒内完成。
(3)可水平扩展。个性化是一个需要长期打磨的系统工程,在不同的阶段对系统的容量自然有不同的需求,这就需要我们的系统能够具备良好的水平扩展能力。
(4)能应对复杂多变的业务。算法同学会在个性化方面做各种尝试,我们系统需要提供便利的方式来支持这些尝试,最好是能够将相对公用的东西与具体的业务逻辑剥离开,简单来说,就是算法逻辑插件化。
(5)高效。实时分析每天需要处理的日志量是巨大的,但是在其业务价值没有得到足够证明之前,是不可能占用太多的机器资源的,因此高效也成为了我们的一个基本需求。

3.系统架构
说到实时分析,前提是实时日志收集,这方面淘宝已经有了一套的强大的日志收集和分发系统–TimeTunnel,俗称TT,TT的延迟在几百毫秒以内,并且提供根据游标来取消息的功能,基本满足了我们消息对消息实时性和完整性的需求。全量计算的输出是实时分析系统的另一个重要的数据源,因为我们写入到ups提供给搜索引擎的是用户属性的最终结果,合并全量和增量的过程需要在实时分析系统中完成。全量计算是在云梯上完成的,结果存放在hdfs中,hdfs不能够提供记录级别的操作,考虑到我们的系统需求,必须要有另外一个提供高效的记录级操作的存储系统来保存这些数据。此外,由于算法逻辑通常会将用户近两天的行为都考虑进去,我们还需要保存用户近期的行为记录。我们选择hbase作为全量结果和近期行为数据的存储介质,一是由于hbase具有良好的水平扩展性,二是由于我们对hbase的使用比较熟悉。在计算系统的选型上,我们选择了人见人爱的开源系统storm.各个组件的选型确定,整个系统的架构也就出来了。
系统架构

(1)全量数据的导入。首先通过distcp方式将云梯上的数据拷贝到我们的hadoop集群中,然后使用bulk-load方式将数据导入到hbase表中。bulk-load是hbase提供的一种高效的数据批量导入工具,具体使用方法可以参考 http://hbase.apache.org/book/arch.bulk.load.html。 全量导入过程每天运行一次,我们会根据日期新建对应的表。
(2)全量数据的切换和删除。为了让运行在storm中的实时分析拓扑检测并使用到新全量表,我们另外创建了一张全量数据索引表,每次导入到新的全量数据表时更新对应的索引,实时分析拓扑定期扫描索引,在检测到索引更新时自动切换到使用新表。
(3)消息完整性的保证。实时分析拓扑中会保存消息处理的游标,并定期刷入到hbase中,这样即使在节点失败或者拓扑重启的情况下也能够恢复游标,处理堆积的消息。

4.实时分析拓扑
当一条日志进入pora系统后,首先通过解析器解析出若干字段,然后通过过滤逻辑来判断该条日志是否需要进行分析,如果需要,则会根据这些字段执行需要的join操作,例如将用户、宝贝的信息补全,然后将join好的日志以及用户的近期行为和全量属性传递给系统中的算法插件,依次进行分析,最后将最新的用户属性更新到ups中,提供给外部使用。分析流程对应于storm的拓扑结构大致如下:
(1)parser. 负责解析日志,根据配置文件取出需要的字段来。
(2)filter. 过滤逻辑,根据某些规则过滤掉一些不感兴趣的用户日志。
(3)joiner. 日志中的字段往往不能够提供完整的信息,需要一个join过程来补全字段。在当前的实现中,我们会根据日志中的”行为”字段来使用不同的join方式。
(4)analyzer. 主体分析逻辑。我们将这部分做成了一个 framework + plugins 的结构,其中framework负责取全量属性、取近期行为、取当前行为,合并计算结果。每个plugin只需要实现analyze(全量属性 + 近期行为 + 当前行为)的方法。framework对用户属性进行了字段切分,每个plugin只需要关心自己处理的那个字段即可。
在joiner和analyzer阶段,我们做了一个很小的批量处理,不一定每条日志都会触发计算,只有当累积够一定条数后,才做一次集中处理,这样在latency方面会有一些损失,但是能够将对hbase的访问打包,提高hbase的读写性能,从而大大提高系统的qps.这个批量的大小是可配的,用户可以根据场景选择配置,在qps和latency之间做trade-off,当配置为1的时候,就是完全的单条计算。
(5)updater.负责将analyzer计算后发生更新的用户属性发送到ups中,继而提供给搜索引擎使用。

5.系统监控
监控是一个线上系统必不可少的一部分。我们除了使用了一些基础的机器状态监控外,hbase集群还使用了集团hbase团队开发的专用监控系统,非常直观。此外,我们还需要一些业务指标的监控,例如我们的qps,latency,gap(日志处理时间与日志生产时间质检单 间隔),这方面也花费了我们一些心思。例如latency的监控,storm ui本身提供了即时数字的显示,但是没有我们想要的曲线图(或许0.9版本中会有吧)。最后我们选择了基于hbase的监控绘图工具openTSDB。我们通过借助storm的ack机制来统计消息处理的latency,打印到日志中,然后使用一个脚本来搜集这些信息发送给openTSDB服务器来展示曲线。
pora目前在淘宝个性化搜索中稳定运行,每天处理几十亿的日志信息,平均延迟在秒级。

6.经验教训
(1).zookeeper集群独立。因为zookeeper无论对于hbase还是storm都是至关重要的,最好将其单独搞一个负载较低的集群。
(2).hbase表的预分区。尽量将请求分散到各个节点上,至于预分区的原则,就根据业务场景来制定了。例如我们在存储用户全量属性数据时是按照用户名做哈希取模的。
(3).storm使用经验
(a).根据需要修改默认参数。这点是显然的,storm的默认参数并不能符合每个业务场景的需要,在storm源码中的conf/defaults.xml目录下有各个参数的默认取值,用户可根据需要修改。
(b).emit tuple时一定要new list.出于效率的考虑,storm底层的发送线程不会对该list进行深拷贝,会直接使用。如果用户不小心修改了该list,会导致一些莫名其妙的失误。
(c).重启supervopior前删除本地data目录。storm的supervisor会在本地data目录保存一些状态信息,在某些情况下这些状态与zk中的最新状态并不能保持一致,如果不删除data目录,容易导致supervisor重启失败。

相关 [个性 离线 实时] 推荐:

个性化离线实时分析系统pora

- - 搜索技术博客-淘宝
伴随着市场和技术的发展,个性化已经成为淘宝搜索的一个重要目标. 简单来说,个性化就是让每个用户在使用淘宝搜索时都能够获取自己最想要的结果,而不再是千篇一律的展示. 实现个性化最直接的手段就是通过分析用户的历史行为日志,为用户打上不同的标签,在搜索中根据这些标签来展示最贴近的结果. 在淘宝,用户属性分析是通过每天在云梯上定时运行的map reduce job来完成的,产出结果导入我们的在线kv存储ups中,搜索引擎通过查询ups获取用户属性来为用户返回个性化的结果.

数据仓库简介、发展、架构演进、实时数仓建设、与离线数仓对比

- - zhisheng的博客
数据仓库也是公司数据发展到一定规模后必然会提供的一种基础服务,数据仓库的建设也是“数据智能”中必不可少的一环. 本文将从数据仓库的简介、经历了怎样的发展、如何建设、架构演变、应用案例以及实时数仓与离线数仓的对比六个方面全面分享关于数仓的详细内容. 原地地址: https://ververica.cn/developers/how-to-do-real-time-counting/.

离线存储

- - 崔凯,前端开发
开发WebApp时,遇到一个问题:. 如果把页面配置到服务器上,当服务器挂掉或者用户离线的时候,那这个App也就没法工作了. 而当我把页面打包进App里面,又有一个新问题,更新不方便. 部门就此组织了一次《application cache》的相关讨论. 使用离线存储,来解决上述问题:. 这是一个打包进App的应用地址,阅读源代码可以看到,html标记上给了一个manifest配置文件.

离线功能回归Gmail

- Myheimu - 驱动之家新闻_最新新闻
千呼万唤始出来──用这句话形容离线版Gmail、Google Docs 和 Google Calendar一点不为过,尤其是在Google一刀切取消了以前用于离线的Google Gears之后,大家就一直在等待一个离线版的应用解决方案,在Chromebook发布之后其意义更加重大. 今天Google终于宣布了可让Chrome实现离线的网页应用Gmail Offline ,该应用完全基于HTML5打造,界面则基于Gmail的平板界面(这是最让人不满的),在你没有网络连接的情况下,通过Chrome打开这个离线网页应用,即可管理自己的Gmail邮件了.

美图离线ETL实践

- - SegmentFault 最新的文章
美图收集的日志需要通过 ETL 程序清洗、规整,并持久化地落地于 HDFS / Hive,便于后续的统一分析处理. ETL 即 Extract-Transform-Load,用来描述将数据从来源端经过抽取(extract)、转换(transform)、加载(load)至目的端的过程. ETL 一词较常用在数据仓库,但其对象并不限于数据仓库.

前端离线化探索

- - SegmentFault 最新的文章
原文: 前端离线化探索. 某天,小明同学突然反馈 :“昨晚发现根本无法使用你们的应用. 我和我的小伙伴们立马惊呆了,心想:“老司机多年的经验有一种预感,那就是同学你使用姿势不正确...(此处省略300字)”. 然后默默排查了许久,答案竟然是:. 为了以后能够在飞机上愉快的玩耍,这里的离线体验我们有必要再着重优化下.

Offline Google Mail,离线功能回归Gmail

- 53ke - Chrome迷
今天,Chromestore登陆谷歌官方新款应用Offline Google Mail,这款应用完全基于HTML5,操作界面变动非常大,把PC弄得像平板似的. 在你没有网络连接的情况下,用Chrome打开这个网页应用,即可以管理自己的Gmail邮件. 当然,所有操作只有在联网时才被同步,若没有联网,则暂时记录在本地.

中国离线下载研究

- - Solidot
腾讯旋风、清华大学和美国大学研究人员在本周末举行的ACM IMC 2015会议上发表了一篇论文《Offline Downloading in China: A Comparative Study》,介绍了他们开发的中间件ODR (Offline Downloading Redirector). 这项研究获得了863计划中国云项目的资助.

Web GIS 离线解决方案

- - ImportNew
在离线环境下(局域网中)的GIS系统中如何使用地图. 这里的地图主要指的是地图底图,有了底图切片数据,我们就可以看到地图,在上面加上自己的业务数据图层,进行相关操作. 要在离线环境下看到GIS地图,就要有底图切片数据,地图的底图切片数据在一定时间内是不会变化的,可以使用一些地图下载器下载地图切片,如这个 地图下载器.

【支持定位支持离线包】百度地图

- Daimon - 爱Apps - www.iapps.im
精选限时免费应用,由 AppPusher 为您送达. 无限精彩,尽在 爱Apps - www.iapps.im. 本站原创内容,转载时请务必注明出处,谢谢. 大小: 3.8 MB 系统: 3.0+. 百度地图出了,小编实测了一下,定位很准确,而百度地图本身的资源也是比较新的,这款刚上架不久的百度地图,适合iPhone和iPod,支持手机内下载各省市离线包(很遗憾没发现电脑端传输功能),基本上略大点的二三线城市都有,还是很不错的,大家可以试试.