1.业务场景 伴随着市场和技术的发展，个性化已经成为淘宝搜索的一个重要目标。简单来说，个性化就是让每个用户在使用淘宝搜索时都能够获取自己最想要的结果，而不再是千篇一律的展示。实现个性化最直接的手段就是通过分析用户的历史行为日志，为用户打上不同
1.业务场景
伴随着市场和技术的发展，个性化已经成为淘宝搜索的一个重要目标。简单来说，个性化就是让每个用户在使用淘宝搜索时都能够获取自己最想要的结果，而不再是千篇一律的展示。实现个性化最直接的手段就是通过分析用户的历史行为日志，为用户打上不同的标签，在搜索中根据这些标签来展示最贴近的结果。
在淘宝，用户属性分析是通过每天在云梯上定时运行的map reduce job来完成的，产出结果导入我们的在线kv存储ups中，搜索引擎通过查询ups获取用户属性来为用户返回个性化的结果。在云梯上执行的全量计算能够进行复杂的模型计算，并且由于利用了云梯强大的计算能力，计算全部用户几十天的日志也只需花费几个小时。
全量计算的不足之处在每次计算的输入数据都是前一天到前N天的日志，无法将用户当天的行为考虑进去，因此得到的用户属性永远是滞后一天的，无法将某些用户当前的属性很好地反映出来。实时增量弥补了这一空缺，通过实时分析用户的行为日志，将最新的用户属性反馈给搜索引擎，能够为用户展现最贴近其当前需求的结果。
2.系统需求
结合我们的业务场景和现状，对实时分析系统大致有以下几点需求。
(1)不影响在线查询的效率。这是一个最基本的需求，也决定了我们系统的定位：离线分析，将相对较重的分析过程放在离线阶段完成，在线过程只需要查询离线计算产出的结果即可。
(2)实时。既然称为实时系统，这也是一个起码的要求。至于要多实时，初步的目标是从用户一次行为发生到最后的属性更新在几秒内完成。
(3)可水平扩展。个性化是一个需要长期打磨的系统工程，在不同的阶段对系统的容量自然有不同的需求，这就需要我们的系统能够具备良好的水平扩展能力。
(4)能应对复杂多变的业务。算法同学会在个性化方面做各种尝试，我们系统需要提供便利的方式来支持这些尝试，最好是能够将相对公用的东西与具体的业务逻辑剥离开，简单来说，就是算法逻辑插件化。
(5)高效。实时分析每天需
本文来源gao!%daima.com搞$代*!码网1
要处理的日志量是巨大的，但是在其业务价值没有得到足够证明之前，是不可能占用太多的机器资源的，因此高效也成为了我们的一个基本需求。
3.系统架构
说到实时分析，前提是实时日志收集，这方面淘宝已经有了一套的强大的日志收集和分发系统–TimeTunnel，俗称TT，TT的延迟在几百毫秒以内，并且提供根据游标来取消息的功能，基本满足了我们消息对消息实时性和完整性的需求。全量计算的输出是实时分析系统的另一个重要的数据源，因为我们写入到ups提供给搜索引擎的是用户属性的最终结果，合并全量和增量的过程需要在实时分析系统中完成。全量计算是在云梯上完成的，结果存放在hdfs中，hdfs不能够提供记录级别的操作，考虑到我们的系统需求，必须要有另外一个提供高效的记录级操作的存储系统来保存这些数据。此外，由于算法逻辑通常会将用户近两天的行为都考虑进去，我们还需要保存用户近期的行为记录。我们选择hbase作为全量结果和近期行为数据的存储介质，一是由于hbase具有良好的水平扩展性，二是由于我们对hbase的使用比较熟悉。在计算系统的选型上，我们选择了人见人爱的开源系统storm.各个组件的选型确定，整个系统的架构也就出来了。
转载请注明原文链接：个性化离线实时分析系统pora
