基于数据挖掘的算法来实现推荐引擎是各大电子商务网站、SNS社区最为常用的方法

　　

基于数据挖掘的算法来实现推荐引擎是各大电子商务网站、SNS社区最为常用的方法

　　E-commerce网站search 架构解决方案

　　说是电商搜索架构方案，其实是一个应用。公司寺院不大，人也很少，所以一般都会去看看。之前做过一些例子，所以被拉起来写一个架构方案。我是个懒惰的人，我疯狂地在互联网上采集搜索架构的东西。我暂时没有写代码来做架构。我每天都看别人的博客。结果，花了两周时间才得到一个粗略的草图。这还不清楚。以后会有详细的计划，现在只能分享我的草图。我希望每个人都会等你。在家里乱搞会很郁闷，效率太低了。

　　基于Lucene的搜索解决方案

　　一、Lucene 介绍

　　Lucene 是 Apache 的顶级开源项目。是一个java实现的全文搜索引擎，可以索引和搜索各种文档格式的全文，包括word和pdf，不包括图形。

　　是从Java的Lucene翻译过来的C#版本的Lucene，也被Apache列为开源项目。功能与Java基本相同。但是由于缺乏良好的技术支持和社区活动，它已经被Apache发布了。放入培养箱

　　Lucene write：分析器对源文件进行处理，包括分词、权重处理、生成文档记录、写入存储（硬盘或内存）。

　　Lucene读出：分析搜索关键词，包括分词、权重、范围匹配。源码*敏*感*词*如下：

　　

　　具体流程如下：

　　

　　数据流图如下：

　　

　　二、常用推荐引擎算法问题

　　使用基于数据挖掘的算法实现推荐引擎是各大电商网站和SNS社区最常用的方法。推荐引擎通常使用基于内容的推荐算法和协同过滤算法（Item-Based、User-based）。但从实际应用的角度来看，对于大多数中小企业来说，在电子商务系统中完全采用上述算法还是非常困难的。

　　1），比较成熟，完整，现成的开源方案很少

　　粗略地说，目前数据挖掘和推荐引擎相关的开源项目主要分为以下几类：

　　数据挖掘相关：主要包括Weka、R-Project、Knime、RapidMiner、Orange等

　　文本挖掘相关：主要包括OpenNLP、LingPipe、FreeLing、GATE、Carrot2等，详见LingPipe大赛

　　推荐引擎相关：主要包括Apache Mahout、Duine框架、奇异值分解（SVD），其他包可参考Java编写的开源协同过滤

　　搜索引擎相关：Lucene、Solr、Sphinx、Hibernate Search等

　　2），常用的推荐引擎算法比较复杂，入门门槛高

　　3），常用推荐引擎算法性能低，不适合海量数据挖掘

　　除相对成熟的Lucene/Sor外，以上大部分包或算法仍处于学术研究阶段，不能直接应用于互联网规模的数据挖掘和推荐引擎引擎。

　　（以上都是基于java的，需要自己学习实现，难度很大）

　　注意：除了分类搜索和主动搜索，推荐系统也是用户浏览产品的重要方式。它可以帮助用户找到相似和感兴趣的产品，增加产品的访问量，将访问者转化为购买者，引导用户购买。最终价值在于提升用户的购物体验和用户粘性，增加订单量。例如，亚马逊 30% 的订单来自推荐系统。

　　采用Lucene实现推荐引擎的优势

　　对于很多中小网站来说，由于开发能力有限，如果有一个集成搜索和推荐的解决方案，这样的解决方案肯定会很受欢迎。使用Lucene实现推荐引擎有以下优点：

　　1），Lucene 入门门槛低，网站 的网站搜索大部分使用Lucene

　　2），Lucene 相比协同过滤算法性能更高

　　3），Lucene对于Text Mining、相似度计算等相关算法有很多现成的解决方案

　　在开源项目中，Mahout或者Duine Framework是比较完善的推荐引擎解决方案，尤其是Mahout的核心使用了Lucene，所以其架构值得学习。只是Mahout目前的功能还不是很完善，电商网站的推荐引擎还不成熟。只是从Mahout的实现可以看出，使用Lucene来实现推荐引擎是一个可行的方案。

　　3、使用Lucene实现推荐引擎需要解决的核心问题

　　Lucene 擅长文本挖掘。它在 contrib 包中提供了 MoreLikeThis 函数，这使得实现基于内容的推荐变得更加容易。但是，Lucene 目前并不擅长结果涉及用户协同过滤行为（所谓的 Relevance Feedback）的解决方案。需要在Lucene的内容相似度算法中加入用户的协同过滤行为配对因子，将用户的协同过滤行为结果转化为Lucene支持的模型。

　　推荐引擎数据来源

　　与电子商务网站和推荐引擎相关的典型行为：

　　购买此商品的顾客也购买了

　　看过此产品的顾客也看过

　　浏览更多同类产品

　　喜欢这个产品的人也喜欢它

　　用户对该产品的平均评价

　　因此基于Lucene的推荐引擎的实现主要处理以下两类数据

　　1），内容相似度

　　例如：产品名称、作者/译者/制造商、产品类别、介绍、评论、用户标签、系统标签

　　2），用户协同行为相似度

　　例如：标记、购买产品、点击流、搜索、推荐、采集、评分、撰写评论、问答、页面停留时间、群组等

　　5、实现计划

　　5.1、内容相似度可以基于Lucene MoreLikeThis实现。

　　5.2、用户协作行为的处理

　　1），用户使用lucene对每一个协作行为进行索引，每一个行为都有一个记录

　　2），索引记录收录以下重要信息：

　　产品名称、产品id、产品类别、产品介绍、标签等重要特征值、其他产品特征元素的用户相关行为、产品缩略图地址、协作行为类型（购买、点击、采集、评分等） ), Boost值（setBoost中每个合作行为的权重值）

　　3），评分、采集、点击等协作行为以产品特征值（标签、标题、摘要信息）为特征

　　4），不同类型的协作行为（如购买、评分、点击）设置不同的值setBoost

　　5）, Lucene MoreLike 这个算法在搜索时使用，将用户的协作转化为内容相似度

　　以上方案只是基于Lucene实现推荐引擎的最简单的实现方案。方案的准确性和详细方案将在后面讨论。

　　更精细的实现可以参考Mahout的算法实现进行优化。

　　其他搜索引擎开源工具推荐：Sphinx，目前基于*敏*感*词*开源全文搜索引擎软件Sphinx，单个索引最多可收录1亿条记录，1000万条情况下的查询速度记录是0. x 秒（毫秒级）。 Sphinx创建索引的速度如下：创建100万条记录的索引只需3到4分钟，50分钟即可创建1000万条记录的索引，增量索引只收录最新的10万条记录记录重建一次。只需几十秒。

　　Sphinx 是根据 GPL 2 协议发布的免费开源全文搜索引擎。它专为更好地集成脚本语言和 SQL 数据库而设计。当前内置的数据源支持直接连接MySQL或PostgreSQL获取数据，也可以使用XML管道机制（XML管道机制，一种基于Sphinx识别的特殊xml格式的索引通道）

　　基于LAMP架构的应用非常广泛，目前已知的商业应用有康盛的Discuz企业版。

　　,

　　三、手机之家的搜索计划（供参考）

　　目前手机之家的Lucene应用采用Lucene2.4.1+JDK1.6（64位）的组合，运行在8CPU、32G内存的机器上，数据量超过3300万，原创数据文件超过14G，每天需要支持35万以上的查询，高峰期QPS超过20。单看这些数据可能不是什么大亮点，但它的重构和更新都是自动完成的，两个任务可以同时运行。另一方面，在不影响服务可靠性的情况下，尽可能快地更新数据。 （如果两者有冲突，优先保证可用性，延迟更新），工作量还是很大的。

　　PPT 连接

　　在*敏*感*词*应用中，Lucene更适合狭义的“搜索”，不应该负责数据存储。如果我们查看Lucene的源码，也可以知道Document和Field的存储效率不够好。移动之家团队也发现了这一点。他们的方法是使用Lucene存储索引，使用Memcache + Berkeley DB（Java版）进行存储。这有两个优点。一是减少Lucene的数据量，提高程序效率；另一方面，该系统还可以提供一些类似SQL的查询功能。其实Lucene本身似乎也注意到了这个问题，在Store中增加了一个db选项，其实就是Berkeley DB。

　　在*敏*感*词*应用中，Cache 非常重要。 PPT中还提到，在程序提供服务之前，可以进行多次“预热”搜索来填充Searcher's Cache。根据我们（Ginkgo Search）的经验，我们还可以在应用中提供Document-specific Cache，这会大大提高性能。 Lucene 似乎已经注意到了这个问题。在2.4 版本中，提供了Cache，并提供了LRU Cache 的实现。但是根据我们的测试，在极端情况下，这个Cache可能会突破大小限制，一路膨胀，最后吃光内存，甚至网上找到的很多LRU Cache实现在极端情况下都可能出现这样的问题，而且最后自己写。一个LRU Cache经过多次修改修改，目前稳定。

　　在编写Java服务程序时，记得设置退出钩子函数（RunTime.getRunTime.addShutdownHook）是一个非常好的习惯。很多Java程序员没有这种意识，或者有，只是写了一个finalize函数。因此，当程序异常退出时，一些外部资源的状态可能会变得不稳定。以Lucene为例。前面的IndexWriter默认是autoCommit，所以每增加一条记录，就提交一次。好处是如果中断了，之前添加的记录都是可用的。缺点是索引速度非常低。在新版本中，autoCommit默认为False，速度有明显提升（我们测试的结果是提升了8倍左右），但是如果中途异常退出，之前的努力就会白费。如果我们添加一个退出钩子函数，并在捕获到退出信号时自动调用writer.close()方法，就可以避免这个问题。

　　目前Lucene兼容JDK1.4，其二进制版本也由JDK1.4编译。如果对性能有较高要求，可以自行下载Lucene Source Code，用较新版本的JDK编译。根据我的测试，jar文件的速度在30%左右。

　　四、XX网搜索解决方案4.1初步解决方案：

　　实现分词搜索、推荐关键词和站内商品简单排序、定时自动更新、索引读写分离。

　　基于服务器的搜索压力大，用户搜索体验不够好。初步解决目标是解决服务器的搜索压力，实现初步的分词搜索，以及索引的自动定期维护。

　　4.1.1数据库产品表分析：

　　大类基表

　　l产品分类扩展基表

　　l品牌基表、品牌系列表基表

　　l产品基表（主表）

　　l颜色基表

　　产品基表数据约8万条，占用空间约40m，单表数据量较小。

　　4.1.2 Lucene 索引程序：

　　库中的数据通过Lucene的索引程序读入流，然后写入Lucene自定义索引文件。此索引文件不执行搜索操作，完成后需要替换为搜索索引。分词过程是在索引过程中进行的。分词组件采用eaglet开发的盘古分词组件（基于apache开源协议开源，更*敏*感*词*需要自行开发）。

　　4.1.3 Lucene 索引库：

　　基表的索引文件大约100m。它分为写作库和搜索库。写入完成后，将合并到搜索数据库中。考虑到新索引被覆盖，索引可能是在索引的时刻生成的。如果索引程序错误或索引文件损坏，搜索程序可以在覆盖的同时通过程序控制读写索引中的文件。

　　l 搜索处理服务：基于产品库搜索，如品牌、品类、价格区间。搜索程序依赖界面，数据库搜索和文件搜索需要随时切换。搜索时，需要使用分词组件进行分词处理，检索分词后的结果。数据库搜索暂时不进行分词处理。

　　lQuery处理：使用mvc查询前台程序，实现产品分词、分类查询、品牌分类、价格区间查询的高亮显示。

　　

　　4.2第二步关键词statistics：

　　Search关键词的集合和search的联合处理，实现一个简单的搜索推荐功能。主要目的是对前台的搜索关键词进行统计分析，并与搜索顺序相关联。完成关键词的初始处理以及与主表关联的索引方案后，就可以做出完整的解决方案了。

　　

　　4.3 第三步优化改进：

　　实现基于消息的索引文件自动增量更新、权重计算、推荐产品计算研究、实时搜索研究。权重计算需要重新开发自己的矢量算法引擎，正在考虑中。

　　实时搜索正在学习中。

　　4.3.1 权重计算

　　权重计算方法将前端用户的统计数据与产品库相关联，为天天网产品开发权重排名计算方法。下面的算法流程图只是一个概念。

　　

　　权重计算设计

　　4.3.2 索引自动更新

　　建立基于消息机制的索引更新维护机制。