0.概述
研究了下阿里的RecEng、Amazon和开源EasyRec推荐系统，孰优孰劣,针对一个通用的推荐系统设计的方法是什么。
1.阿里推荐RecEng架构
离线计算的数据类型分为:接入数据、中间数据和输出数据三类。接入数据指客户离线提供的用户、物品、日志等数据，中间数据是在离线算法流程中产生的各种中间性质的结果数据表，输出数据是指推荐结果数据表，该结果最终将会被导入到在线存储中，供在线计算模块使用。
近线计算主要处理用户行为发生变化、推荐物品发生更新时，对离线推荐结果进行更新。近线程序的输入数据可以来自多个数据源，如在线的表格存储（原OTS），以及用户的API请求，又或者是程序中的变量；输出可以是程序变量，或者写回在线存储，或者返回给用户。
在线计算负责的任务是推荐API接收到API请求时，实时对离线和近线修正产生的推荐结果进行过滤、排重、补足等处理。
2.阿里推荐RecEng引擎流程
3.阿里推荐RecEng优缺点
缺点：每个配置流程都很慢，依赖平台型太强。系统支持的推荐算法没有清晰的内部实现过程说明。
优点：配置度比较灵活，可以自定义模板和算法(但是成本太高，扩展性不太清楚,自定义算法手册没有找到)。和Amazon的架构有很多的相似处。架构理念正确。
4.Amazon推荐系统架构
系统被分为3部分， online，nearLine和离线部分(offLine)。Online和nearLine部分一起认为是实时部分。
离线部分就是传统的个性化推荐系统的主体，定期将大量存储的数据拿出来进行批处理运算，然后对模型进行建立与更新，这里就不详细介绍了。
nearLine部分，是将用户产生的事件，利用流式计算得到一些中间结果，这些中间结果一方面发送给online部分用于实时更新推荐模型，另一方面将中间结果存储起来，例如存储在MemCached、Cassandra、MySQL等可以快速查询的存储中作为备份。在NetFlix的系统中，他们的流式计算是通过一个叫做NetFlix.Manhattan来实现的，它是一个类似于Storm的实时流式计算框架，只是针对他们自己的应用有一定的特异性，不是通用的实时计算框架。
然后是online部分。这一部分利用离线部分的主体模型并考虑nearLine部分的实时数据对模型进行增量更新，然后可以得到一个实时的推荐模型，进而根据用户的行为来对用户进行实时推荐。
5.阿里RecEng和开源EasyRec的对比
开源EasyRec是一个比较完整的推荐系统，内置已经实现的管理规则算法，插件话的开发模式，支持自定义插件和算法。但是属于半成品，itemitem,cf,svg等经典的推荐算法都没有完整实现，目前版本更新停止，整个系统是针对离线推荐做的，对在线推荐场景支持不到位，整个架构没有考虑到在线推荐的场景。但模块比较完整，报表，API等比较齐全。对企业自主研发推荐系统有很多借鉴的地方。架构方面可以和Amazon的做一个结合，在通用性方面已经比较完整。
个性化推荐系统架构的关键问题，就是如何以无缝方式实现在线和离线计算过程，说到底，也是算法的设计，如何将算法的计算步骤合理分配到各个部分，使得得到的模型既可以非常准确，又可以快速计算出来以满足实时性的要求。