剖析Elasticsearch集群系列涵盖了当今最流行的分布式搜索引擎Elasticsearch的底层架构和原型实例。

本文是这个系列的第二篇，我们将讨论Elasticsearch如何处理分布式的三个C((共识(consensus)、并发(concurrency)和一致(consistency))的问题、Elasticsearch分片的内部概念，比如translog(预写日志，WAL(Write Ahead Log))，以及Lucene中的段。

本系列已经得到原文著者Ronak Nathani的授权

在本系列的前一篇中，我们讨论了Elasticsearch的底层存储模型及CRUD（创建、读取、更新和删除）操作的工作原理。在本文中，我将分享Elasticsearch是如何应对分布式系统中的一些基本挑战的，以及分片的内部概念。这其中包括了一些操作方面的事情，Insight Data的工程师们已经在使用Elasticsearch构建的数据平台之上成功地实践并真正理解。我将在本文中主要讲述：

• 共识——裂脑问题及法定票数的重要性
• 并发
• 一致——确保读写一致
• Translog(预写日志)
• Lucene的段

共识——裂脑问题及法定票数的重要性

共识是分布式系统的一项基本挑战。它要求系统中的所有进程/节点必须对给定数据的值/状态达成共识。已经有很多共识算法诸如Raft、Paxos等，从数学上的证明了是行得通的。但是，Elasticsearch却实现了自己的共识系统(zen discovery)，Elasticsearch之父Shay Banon在这篇文章中解释了其中的原因。zen discovery模块包含两个部分：

• Ping: 执行节点使用ping来发现彼此
• 单播(Unicast):该模块包含一个主机名列表，用以控制哪些节点需要ping通

Elasticsearch是端对端的系统，其中的所有节点彼此相连，有一个master节点保持活跃，它会更新和控制集群内的状态和操作。建立一个新的Elasticsearch集群要经过一次选举，选举是ping过程的一部分，在所有符合条件的节点中选取一个master，其他节点将加入这个master节点。ping间隔参数ping_interval的默认值是1秒，ping超时参数ping_timeout的默认值是3秒。因为节点要加入，它们会发送一个请求给master节点，加入超时参数join_timeout的默认值是ping_timeout值的20倍。如果master出现问题，那么群集中的其他节点开始重新ping以启动另一次选举。这个ping的过程还可以帮助一个节点在忽然失去master时，通过其他节点发现master。

注意：默认情况下，client节点和data节点不参与这个选举过程。可以在elasticsearch.yml配置文件中，通过设置discovery.zen.master_election.filter_client属性和discovery.zen.master_election.filter_data属性为false来改变这种默认行为。

故障检测的原理是这样的，master节点会ping所有其他节点，以检查它们是否还活着；然后所有节点ping回去，告诉master他们还活着。

如果使用默认的设置，Elasticsearch有可能遭到裂脑问题的困扰。在网络分区的情况下，一个节点可以认为master死了，然后选自己作为master，这就导致了一个集群内出现多个master。这可能会导致数据丢失，也可能无法正确合并数据。可以按照如下公式，根据有资格参加选举的节点数，设置法定票数属性的值，来避免爆裂的发生。

discovery.zen.minimum_master_nodes = int(# of master eligible nodes/2)+1

这个属性要求法定票数的节点加入新当选的master节点，来完成并获得新master节点接受的master身份。对于确保群集稳定性和在群集大小变化时动态地更新，这个属性是非常重要的。图a和b演示了在网络分区的情况下，设置或不设置minimum_master_nodes属性时，分别发生的现象。

注意：对于一个生产集群来说，建议使用3个节点专门做master，这3个节点将不服务于任何客户端请求，而且在任何给定时间内总是只有1个活跃。

我们已经搞清楚了Elasticsearch中共识的处理，现在让我们来看看它是如何处理并发的。

并发

Elasticsearch是一个分布式系统，支持并发请求。当创建/更新/删除请求到达主分片时，它也会被平行地发送到分片副本上。但是，这些请求到达的顺序可能是乱序的。在这种情况下，Elasticsearch使用乐观并发控制，来确保文档的较新版本不会被旧版本覆盖。

每个被索引的文档都拥有一个版本号，版本号在每次文档变更时递增并应用到文档中。这些版本号用来确保有序接受变更。为了确保在我们的应用中更新不会导致数据丢失，Elasticsearch的API允许我们指定文件的当前版本号，以使变更被接受。如果在请求中指定的版本号比分片上存在的版本号旧，请求失败，这意味着文档已经被另一个进程更新了。如何处理失败的请求，可以在应用层面来控制。Elasticsearch还提供了其他的锁选项，可以通过这篇来阅读。

当我们发送并发请求到Elasticsearch后，接下来面对的问题是——如何保证这些请求的读写一致？现在，还无法清楚回答，Elasticsearch应落在CAP三角形的哪条边上，我不打算在这篇文章里解决这个素来已久的争辩。

但是，我们要一起看下如何使用Elasticsearch实现写读一致。

一致——确保读写一致

对于写操作而言，Elasticsearch支持的一致性级别，与大多数其他的数据库不同，允许预检查，来查看有多少允许写入的可用分片。可选的值有quorum、one和all。默认的设置为quorum，也就是说只有当大多数分片可用时才允许写操作。即使大多数分片可用，还是会因为某种原因发生写入副本失败，在这种情况下，副本被认为故障，分片将在一个不同的节点上重建。

对于读操作而言，新的文档只有在刷新时间间隔之后，才能被搜索到。为了确保搜索请求的返回结果包含文档的最新版本，可设置replication为sync(默认)，这将使操作在主分片和副本碎片都完成后才返回写请求。在这种情况下，搜索请求从任何分片得到的返回结果都包含的是文档的最新版本。即使我们的应用为了更高的索引率而设置了replication=async，我们依然可以为搜索请求设置参数_preference为primary。这样，搜索请求将查询主分片，并确保结果中的文档是最新版本。

我们已经了解了Elasticsearch如何处理共识、并发和一致，让我们来看看分片内部的一些主要概念，正是这些特点让Elasticsearch成为一个分布式搜索引擎。

Translog(预写日志)

因为关系数据库的发展，预写日志(WAL)或者事务日志(translog)的概念早已遍及数据库领域。在发生故障的时候，translog能确保数据的完整性。translog的基本原理是，变更必须在数据实际的改变提交到磁盘上之前，被记录下来并提交。

当新的文档被索引或者旧的文档被更新时，Lucene索引将发生变更，这些变更将被提交到磁盘以持久化。这是一个很昂贵的操作，如果在每个请求之后都被执行。因此，这个操作在多个变更持久化到磁盘时被执行一次。正如我们在上一篇文章中描述的那样，Lucene提交的冲洗(flush)操作默认每30分钟执行一次或者当translog变得太大(默认512MB)时执行。在这样的情况下，有可能失去2个Lucene提交之间的所有变更。为了避免这种问题，Elasticsearch采用了translog。所有索引/删除/更新操作被写入到translog，在每个索引/删除/更新操作执行之后（默认情况下是每5秒），translog会被同步以确保变更被持久化。translog被同步到主分片和副本之后，客户端才会收到写请求的确认。

在两次Lucene提交之间发生硬件故障的情况下，可以通过重放translog来恢复自最后一次Lucene提交前的任何丢失的变更，所有的变更将会被索引所接受。

注意：建议在重启Elasticsearch实例之前显式地执行冲洗translog，这样启动会更快，因为要重放的translog被清空。POST /_all/_flush命令可用于冲洗集群中的所有索引。

使用translog的冲洗操作，在文件系统缓存中的段被提交到磁盘，使索引中的变更持久化。现在让我们来看看Lucene的段。

Lucene的段

Lucene索引是由多个段组成，段本身是一个功能齐全的倒排索引。段是不可变的，允许Lucene将新的文档增量地添加到索引中，而不用从头重建索引。对于每一个搜索请求而言，索引中的所有段都会被搜索，并且每个段会消耗CPU的时钟周、文件句柄和内存。这意味着段的数量越多，搜索性能会越低。

为了解决这个问题，Elasticsearch会合并小段到一个较大的段（如下图所示），提交新的合并段到磁盘，并删除那些旧的小段。

这会在后台自动执行而不中断索引或者搜索。由于段合并会耗尽资源，影响搜索性能，Elasticsearch会节制合并过程，为搜索提供足够的可用资源。

接下来有什么？

从搜索请求角度来说，一个Elasticsearch索引中给定分片内的所有Lucene段都会被搜索，但是，从Elasticsearch集群角度而言，获取所有匹配的文档或者深入有序结果文档是有害的。在本系列的后续文章中我们将揭晓原因，让我们来看一下接下来的主题，内容包括了一些在Elasticsearch中为相关性搜索结果的低延迟所做的权衡。

• Elasticsearch准实时性方面的内容
• 为什么搜索中的深层分页是有害的？
• 搜索相关性计算中的权衡之道

查看原文地址：Anatomy of an Elasticsearch Cluster: Part II

剖析Elasticsearch集群系列涵盖了当今最流行的分布式搜索引擎Elasticsearch的底层架构和原型实例。本文是这个系列的第三篇，我们将讨论Elasticsearch是如何提供近实时搜索并权衡搜索相关性计算的。

本系列已经得到原文著者Ronak Nathani的授权

在本系列的前一篇中，我们讨论了Elastisearch如何解决分布式系统中的一些基本挑战。在本文中，我们将探讨Elasticsearch在近实时搜索及其权衡计算搜索相关性方面的内容，Insight Data的工程师们已经在使用Elasticsearch构建的数据平台之上，对此有所实践。我将在本文中主要讲述：

• 近实时搜索
• 为什么深层分页在分布式搜索中是有害的？
• 计算搜索相关性中的权衡

近实时搜索

虽然Elasticsearch中的变更不能立即可见，它还是提供了一个近实时的搜索引擎。如前一篇中所述，提交Lucene的变更到磁盘是一个代价昂贵的操作。为了避免在文档对查询依然有效的时候，提交变更到磁盘，Elasticsearch在内存缓冲和磁盘之间提供了一个文件系统缓存。内存缓存(默认情况下)每1秒刷新一次，在文件系统缓存中使用倒排索引创建一个新的段。这个段是开放的并对搜索有效。

文件系统缓存可以拥有文件句柄，文件可以是开放的、可读的或者是关闭的，但是它存在于内存之中。因为刷新间隔默认是1秒，变更不能立即可见，所以说是近实时的。因为translog是尚未落盘的变更持久化记录，它能有助于CRUD操作方面的近实时性。对于每次请求来说，在查找相关段之前，任何最近的变更都能从translog搜索到，因此客户端可以访问到所有的近实时变更。

你可以在创建/更新/删除操作后显式地刷新索引，使变更立即可见，但我并不推荐你这样做，因为这样会创建出来非常多的小segment而影响搜索性能。对于每次搜索请求来说，给定Elasticsearch索引分片中的全部Lucene段都会被搜索到，但是，对于Elasticsearch来说，获取全部匹配的文档或者很深结果页的文档是有害的。让我们来一起看看为什么是这样。

为什么深层分页在分布式搜索中是有害的？

当我们的一次搜索请求在Elasticsearch中匹配了很多的文档，默认情况下，返回的第一页只包含前10条结果。search API提供了from和size参数，用于指定对于匹配搜索的全部文档，要返回多深的结果。举例来说，如果我们想看到匹配搜索的文档中，排名为50到60之间的文档，可以设置from=50，size=10。当每个分片接收到这个搜索请求后，各自会创建一个容量为from+size的优先队列来存储该分片上的搜索结果，然后将结果返回给协调节点。

如果我们想看到排名为50,000到50,010的结果，那么每个分片要创建一个容量为50,010的优先队列来存储结果，而协调节点要在内存中对数量为shards * 50,010的结果进行排序。这个级别的分页有可能得到结果，也有可以无法实现，这取决于我们的硬件资源，但是这足以说明，我们得非常小心地使用深分页，因为这非常容易使我们的集群崩溃。

一种获取全部匹配结果文档的可行性方案是使用scroll API，它的角色更像关系数据库中的游标。使用scroll API无法进行排序，每个分片只要有匹配搜索的文档，就会持续发送结果给协调节点。

获取大量文档的时候，对结果进行得分排序会非常昂贵。并且由于Elasticsearch是分布式系统，为每个文档计算搜索相关性得分是非常昂贵的。现在，让我们一起看看计算搜索相关性的诸多权衡中的一种。

计算搜索相关性中的权衡

Elasticsearch使用tf-idf来计算搜索相关性。由于其分布式的性质，计算全局的idf(inverse document frequency，逆文档频率)非常昂贵。反之可以这样，每个分片计算本地的idf并将相关性得分分配给结果文档，返回的结果只关乎该分片上的文档。同样地，所有分片使用本地idf计算的相关性得分，返回结果文档，协调节点对所有结果排序并返回前几条。这样做在大多数情况下是没有问题的，除非索引的关键字词项有倾斜或者单个分片上没有代表全局的足够数据。

比如说，如果我们搜索“insight”这个词，但包含"insight"这个词项的大多数文档都存放在一个分片上，这样以来匹配查询的文档将不能公平地在每个分片上进行排序，因为每个分片上的本地idf的值非常不同，得到的搜索结果可能不会非常相关。同样地，如果没有足够的数据，那么对于某些搜索而言，本地idf的值可能大有不同，结果也会不如预期相关。在有足够数据的真实场景中，本地idf值一般会趋于均等，搜索结果是相关的，因为文档得到了公平的得分。

这里有2种应对本地idf得分的办法，但都不建议真正在生产环境中使用。

• 一种办法是一索引一分片，本地idf即是全局idf，但这没有为并行计算/水平伸缩留有余地，对于大型索引并不实用。
• 另一种办法是在搜索请求中使用dfs_query_then_search (dfs = distributed frequency search，分布式频率搜索) 参数，这样以来，会首先计算每个分片的本地idf，然后综合这些本地idf的值来计算整个索引的全局idf值，最后使用全局idf计算相关性得分来返回结果。这种方式不为生产环境推荐，因为有足够的数据确保词项频率分布均匀。

在本系列的过去几篇中，我们回顾了一些Elasticsearch的基本原则，对于我们理解并上手Elasticsearch，这些内容非常重要。在接下来的一篇中，我将使用Apache Spark来研究Elasticsearch中的索引数据。

查看英文原文：Anatomy of an Elasticsearch Cluster: Part III

剖析Elasticsearch集群系列涵盖了当今最流行的分布式搜索引擎Elasticsearch的底层架构和原型实例。

本文是这个系列的第一篇，在本文中，我们将讨论的Elasticsearch的底层存储模型及CRUD（创建、读取、更新和删除）操作的工作原理。

本系列已经得到原文著者Ronak Nathani的授权

Elasticsearch是当今最流行的分布式搜索引擎，GitHub、 SalesforceIQ、Netflix等公司将其用于全文检索和分析应用。在Insight，我们用到了Elasticsearch的诸多不同功能，比如：

• 全文检索
  • 比如找到与搜索词项(term)最相关的维基百科文章。
• 聚合
  • 比如在广告网络中，可视化的搜索词项的竞价直方图。
• 地理空间API
  • 比如在顺风车平台，匹配最近的司机和乘客。

正是因为Elasticsearch如此流行并且就在我们身边，我决定深入研究一下。本文，我将分享Elasticsearch的存储模型和CRUD操作的工作原理。

当我在思考分布式系统是如何工作时，我脑海里的图案是这样的：

水面以上的是API，以下的才是真正的引擎，一切魔幻般的事件都发生在水下。本文所关注的就是水下的部分，我们将关注：

• Elasticsearch是主从架构还是无主架构
• Elasticsearch的存储模型是什么样的
• Elasticsearch是怎么执行写操作的
• Elasticsearch是怎么执行读操作的
• 如何定义搜索结果的相关性

在我们深入这些概念之前，让我们熟悉下相关的术语。

1 辨析Elasticsearch的索引与Lucene的索引

Elasticsearch中的索引是组织数据的逻辑空间(就好比数据库)。1个Elasticsearch的索引有1个或者多个分片(默认是5个)。分片对应实际存储数据的Lucene的索引，分片自身就是一个搜索引擎。每个分片有0或者多个副本(默认是1个)。Elasticsearch的索引还包含"type"(就像数据库中的表)，用于逻辑上隔离索引中的数据。在Elasticsearch的索引中，给定一个type，它的所有文档会拥有相同的属性(就像表的schema)。

(点击放大图像)

图a展示了一个包含3个分片的Elasticsearch索引，每个分片拥有1个副本。这些分片组成了一个Elasticsearch索引，每个分片自身是一个Lucene索引。图b展示了Elasticsearch索引、分片、Lucene索引和文档之间的逻辑关系。

对应于关系数据库术语

Elasticsearch Index == Database  Types == Tables  Properties == Schema

现在我们熟悉了Elasticsearch世界的术语，接下来让我们看一下节点有哪些不同的角色。

2 节点类型

一个Elasticsearch实例是一个节点，一组节点组成了集群。Elasticsearch集群中的节点可以配置为3种不同的角色：

• 主节点：控制Elasticsearch集群，负责集群中的操作，比如创建/删除一个索引，跟踪集群中的节点，分配分片到节点。主节点处理集群的状态并广播到其他节点，并接收其他节点的确认响应。

  每个节点都可以通过设定配置文件elasticsearch.yml中的node.master属性为true(默认)成为主节点。

  对于大型的生产集群来说，推荐使用一个专门的主节点来控制集群，该节点将不处理任何用户请求。

• 数据节点：持有数据和倒排索引。默认情况下，每个节点都可以通过设定配置文件elasticsearch.yml中的node.data属性为true(默认)成为数据节点。如果我们要使用一个专门的主节点，应将其node.data属性设置为false。

• 客户端节点：如果我们将node.master属性和node.data属性都设置为false，那么该节点就是一个客户端节点，扮演一个负载均衡的角色，将到来的请求路由到集群中的各个节点。

Elasticsearch集群中作为客户端接入的节点叫协调节点。协调节点会将客户端请求路由到集群中合适的分片上。对于读请求来说，协调节点每次会选择不同的分片处理请求，以实现负载均衡。

在我们开始研究发送给协调节点的CRUD请求是如何在集群中传播并被引擎执行之前，让我们先来看一下Elasticsearch内部是如何存储数据，以支持全文检索结果的低延迟服务的。

存储模型

Elasticsearch使用了Apache Lucene，后者是Doug Cutting(Apache Hadoop之父)使用Java开发的全文检索工具库，其内部使用的是被称为倒排索引的数据结构，其设计是为全文检索结果的低延迟提供服务。文档是Elasticsearch的数据单位，对文档中的词项进行分词，并创建去重词项的有序列表，将词项与其在文档中出现的位置列表关联，便形成了倒排索引。

这和一本书后面的索引非常类似，即书中包含的词汇与其出现的页码列表关联。当我们说文档被索引了，我们指的是倒排索引。我们来看下如下2个文档是如何被倒排索引的：

文档1(Doc 1): Insight Data Engineering Fellows Program
文档2(Doc 2): Insight Data Science Fellows Program

如果我们想找包含词项"insight"的文档，我们可以扫描这个(单词有序的)倒排索引，找到"insight"并返回包含改词的文档ID，示例中是Doc 1和Doc 2。

为了提高可检索性(比如希望大小写单词都返回)，我们应当先分析文档再对其索引。分析包括2个部分：

• 将句子词条化为独立的单词
• 将单词规范化为标准形式

默认情况下，Elasticsearch使用标准分析器，它使用了：

• 标准分词器以单词为界来切词
• 小写词条(token)过滤器来转换单词

还有很多可用的分析器在此不列举，请参考相关文档。

为了实现查询时能得到对应的结果，查询时应使用与索引时一致的分析器，对文档进行分析。

注意：标准分析器包含了停用词过滤器，但默认情况下没有启用。

现在，倒排索引的概念已经清楚，让我们开始CRUD操作的研究吧。我们从写操作开始。

剖析写操作

创建((C)reate)

当我们发送索引一个新文档的请求到协调节点后，将发生如下一组操作：

• Elasticsearch集群中的每个节点都包含了改节点上分片的元数据信息。协调节点(默认)使用文档ID参与计算，以便为路由提供合适的分片。Elasticsearch使用MurMurHash3函数对文档ID进行哈希，其结果再对分片数量取模，得到的结果即是索引文档的分片。

  shard = hash(document_id) % (num_of_primary_shards)

• 当分片所在的节点接收到来自协调节点的请求后，会将该请求写入translog(我们将在本系列接下来的文章中讲到)，并将文档加入内存缓冲。如果请求在主分片上成功处理，该请求会并行发送到该分片的副本上。当translog被同步(fsync)到全部的主分片及其副本上后，客户端才会收到确认通知。
• 内存缓冲会被周期性刷新(默认是1秒)，内容将被写到文件系统缓存的一个新段上。虽然这个段并没有被同步(fsync)，但它是开放的，内容可以被搜索到。
• 每30分钟，或者当translog很大的时候，translog会被清空，文件系统缓存会被同步。这个过程在Elasticsearch中称为冲洗(flush)。在冲洗过程中，内存中的缓冲将被清除，内容被写入一个新段。段的fsync将创建一个新的提交点，并将内容刷新到磁盘。旧的translog将被删除并开始一个新的translog。

下图展示了写请求及其数据流。

(点击放大图像)

更新((U)pdate)和删除((D)elete)

删除和更新也都是写操作。但是Elasticsearch中的文档是不可变的，因此不能被删除或者改动以展示其变更。那么，该如何删除和更新文档呢？

磁盘上的每个段都有一个相应的.del文件。当删除请求发送后，文档并没有真的被删除，而是在.del文件中被标记为删除。该文档依然能匹配查询，但是会在结果中被过滤掉。当段合并(我们将在本系列接下来的文章中讲到)时，在.del文件中被标记为删除的文档将不会被写入新段。

接下来我们看更新是如何工作的。在新的文档被创建时，Elasticsearch会为该文档指定一个版本号。当执行更新时，旧版本的文档在.del文件中被标记为删除，新版本的文档被索引到一个新段。旧版本的文档依然能匹配查询，但是会在结果中被过滤掉。

文档被索引或者更新后，我们就可以执行查询操作了。让我们看看在Elasticsearch中是如何处理查询请求的。

剖析读操作((R)ead)

读操作包含2部分内容：

• 查询阶段
• 提取阶段

我们来看下每个阶段是如何工作的。

查询阶段

在这个阶段，协调节点会将查询请求路由到索引的全部分片(主分片或者其副本)上。每个分片独立执行查询，并为查询结果创建一个优先队列，以相关性得分排序(我们将在本系列的后续文章中讲到)。全部分片都将匹配文档的ID及其相关性得分返回给协调节点。协调节点创建一个优先队列并对结果进行全局排序。会有很多文档匹配结果，但是，默认情况下，每个分片只发送前10个结果给协调节点，协调节点为全部分片上的这些结果创建优先队列并返回前10个作为hit。

提取阶段

当协调节点在生成的全局有序的文档列表中，为全部结果排好序后，它将向包含原始文档的分片发起请求。全部分片填充文档信息并将其返回给协调节点。

下图展示了读请求及其数据流。

(点击放大图像)

如上所述，查询结果是按相关性排序的。接下来，让我们看看相关性是如何定义的。

搜索相关性

相关性是由搜索结果中Elasticsearch打给每个文档的得分决定的。默认使用的排序算法是tf/idf(词频/逆文档频率)。词频衡量了一个词项在文档中出现的次数 (频率越高 == 相关性越高)，逆文档频率衡量了词项在全部索引中出现的频率，是一个索引中文档总数的百分比(频率越高 == 相关性越低)。最后的得分是tf-idf得分与其他因子比如(短语查询中的)词项接近度、(模糊查询中的)词项相似度等的组合。

接下来有什么？

这些CRUD操作由Elasticsearch内部的一些数据结构所支持，这对于理解Elasticsearch的工作机制非常重要。在接下来的系列文章中，我将带大家走进类似的那些概念并告诉大家在使用Elasticsearch中有哪些坑。

• Elasticsearch中的脑裂问题及防治措施
• 事务日志
• Lucene的段
• 为什么搜索时使用深层分页很危险
• 计算搜索相关性中困难及权衡
• 并发控制
• 为什么Elasticsearch是准实时的
• 如何确保读和写的一致性

查看原文地址：http://insightdataengineering.com/blog/elasticsearch-crud

“探索推荐引擎内部的秘密”系列将带领读者从浅入深的学习探索推荐引擎的机制，实现方法，其中还涉及一些基本的优化方法，例如聚类和分类的应用。同时在理论讲解的基础上，还会结合 Apache Mahout 介绍如何在大规模数据上实现各种推荐策略，进行策略优化，构建高效的推荐引擎的方法。本文作为这个系列的第一篇文章，将深入介绍推荐引擎的工作原理，和其中涉及的各种推荐机制，以及它们各自的优缺点和适用场景，帮助用户清楚的了解和快速构建适合自己的推荐引擎。

信息发现

如今已经进入了一个数据爆炸的时代，随着 Web 2.0 的发展， Web 已经变成数据分享的平台，那么，如何让人们在海量的数据中想要找到他们需要的信息将变得越来越难。

在这样的情形下，搜索引擎（Google，Bing，百度等等）成为大家快速找到目标信息的最好途径。在用户对自己需求相对明确的时候，用搜索引擎很方便的通过关键字搜索很快的找到自己需要的信息。但搜索引擎并不能完全满足用户对信息发现的需求，那是因为在很多情况下，用户其实并不明确自己的需要，或者他们的需求很难用简单的关键字来表述。又或者他们需要更加符合他们个人口味和喜好的结果，因此出现了推荐系统，与搜索引擎对应，大家也习惯称它为推荐引擎。

随着推荐引擎的出现，用户获取信息的方式从简单的目标明确的数据的搜索转换到更高级更符合人们使用习惯的信息发现。

如今，随着推荐技术的不断发展，推荐引擎已经在电子商务 (E-commerce，例如 Amazon，当当网 ) 和一些基于 social 的社会化站点 ( 包括音乐，电影和图书分享，例如豆瓣，Mtime 等 ) 都取得很大的成功。这也进一步的说明了，Web2.0 环境下，在面对海量的数据，用户需要这种更加智能的，更加了解他们需求，口味和喜好的信息发现机制。

回页首

推荐引擎

前面介绍了推荐引擎对于现在的 Web2.0 站点的重要意义，这一章我们将讲讲推荐引擎到底是怎么工作的。推荐引擎利用特殊的信息过滤技术，将不同的物品或内容推荐给可能对它们感兴趣的用户。

图 1. 推荐引擎工作原理图
 

图 1 给出了推荐引擎的工作原理图，这里先将推荐引擎看作黑盒，它接受的输入是推荐的数据源，一般情况下，推荐引擎所需要的数据源包括：

• 要推荐物品或内容的元数据，例如关键字，基因描述等；
• 系统用户的基本信息，例如性别，年龄等
• 用户对物品或者信息的偏好，根据应用本身的不同，可能包括用户对物品的评分，用户查看物品的记录，用户的购买记录等。其实这些用户的偏好信息可以分为两类：

• 显式的用户反馈：这类是用户在网站上自然浏览或者使用网站以外，显式的提供反馈信息，例如用户对物品的评分，或者对物品的评论。
• 隐式的用户反馈：这类是用户在使用网站是产生的数据，隐式的反应了用户对物品的喜好，例如用户购买了某物品，用户查看了某物品的信息等等。

显式的用户反馈能准确的反应用户对物品的真实喜好，但需要用户付出额外的代价，而隐式的用户行为，通过一些分析和处理，也能反映用户的喜好，只是数据不是很精确，有些行为的分析存在较大的噪音。但只要选择正确的行为特征，隐式的用户反馈也能得到很好的效果，只是行为特征的选择可能在不同的应用中有很大的不同，例如在电子商务的网站上，购买行为其实就是一个能很好表现用户喜好的隐式反馈。

推荐引擎根据不同的推荐机制可能用到数据源中的一部分，然后根据这些数据，分析出一定的规则或者直接对用户对其他物品的喜好进行预测计算。这样推荐引擎可以在用户进入的时候给他推荐他可能感兴趣的物品。

推荐引擎的分类

推荐引擎的分类可以根据很多指标，下面我们一一介绍一下：

1. 推荐引擎是不是为不同的用户推荐不同的数据

   根据这个指标，推荐引擎可以分为基于大众行为的推荐引擎和个性化推荐引擎

   • 根据大众行为的推荐引擎，对每个用户都给出同样的推荐，这些推荐可以是静态的由系统管理员人工设定的，或者基于系统所有用户的反馈统计计算出的当下比较流行的物品。
   • 个性化推荐引擎，对不同的用户，根据他们的口味和喜好给出更加精确的推荐，这时，系统需要了解需推荐内容和用户的特质，或者基于社会化网络，通过找到与当前用户相同喜好的用户，实现推荐。

   这是一个最基本的推荐引擎分类，其实大部分人们讨论的推荐引擎都是将个性化的推荐引擎，因为从根本上说，只有个性化的推荐引擎才是更加智能的信息发现过程。

2. 根据推荐引擎的数据源

   其实这里讲的是如何发现数据的相关性，因为大部分推荐引擎的工作原理还是基于物品或者用户的相似集进行推荐。那么参考图 1 给出的推荐系统原理图，根据不同的数据源发现数据相关性的方法可以分为以下几种：

   • 根据系统用户的基本信息发现用户的相关程度，这种被称为基于人口统计学的推荐（Demographic-based Recommendation）
   • 根据推荐物品或内容的元数据，发现物品或者内容的相关性，这种被称为基于内容的推荐（Content-based Recommendation）
   • 根据用户对物品或者信息的偏好，发现物品或者内容本身的相关性，或者是发现用户的相关性，这种被称为基于协同过滤的推荐（Collaborative Filtering-based Recommendation）。
3. 根据推荐模型的建立方式

   可以想象在海量物品和用户的系统中，推荐引擎的计算量是相当大的，要实现实时的推荐务必需要建立一个推荐模型，关于推荐模型的建立方式可以分为以下几种：

   • 基于物品和用户本身的，这种推荐引擎将每个用户和每个物品都当作独立的实体，预测每个用户对于每个物品的喜好程度，这些信息往往是用一个二维矩阵描述的。由于用户感兴趣的物品远远小于总物品的数目，这样的模型导致大量的数据空置，即我们得到的二维矩阵往往是一个很大的稀疏矩阵。同时为了减小计算量，我们可以对物品和用户进行聚类， 然后记录和计算一类用户对一类物品的喜好程度，但这样的模型又会在推荐的准确性上有损失。
   • 基于关联规则的推荐（Rule-based Recommendation）：关联规则的挖掘已经是数据挖掘中的一个经典的问题，主要是挖掘一些数据的依赖关系，典型的场景就是“购物篮问题”，通过关联规则的挖掘，我们可以找到哪些物品经常被同时购买，或者用户购买了一些物品后通常会购买哪些其他的物品，当我们挖掘出这些关联规则之后，我们可以基于这些规则给用户进行推荐。
   • 基于模型的推荐（Model-based Recommendation）：这是一个典型的机器学习的问题，可以将已有的用户喜好信息作为训练样本，训练出一个预测用户喜好的模型，这样以后用户在进入系统，可以基于此模型计算推荐。这种方法的问题在于如何将用户实时或者近期的喜好信息反馈给训练好的模型，从而提高推荐的准确度。

其实在现在的推荐系统中，很少有只使用了一个推荐策略的推荐引擎，一般都是在不同的场景下使用不同的推荐策略从而达到最好的推荐效果，例如 Amazon 的推荐，它将基于用户本身历史购买数据的推荐，和基于用户当前浏览的物品的推荐，以及基于大众喜好的当下比较流行的物品都在不同的区域推荐给用户，让用户可以从全方位的推荐中找到自己真正感兴趣的物品。

深入推荐机制

这一章的篇幅，将详细介绍各个推荐机制的工作原理，它们的优缺点以及应用场景。

基于人口统计学的推荐

基于人口统计学的推荐机制（Demographic-based Recommendation）是一种最易于实现的推荐方法，它只是简单的根据系统用户的基本信息发现用户的相关程度，然后将相似用户喜爱的其他物品推荐给当前用户，图 2 给出了这种推荐的工作原理。

图 2. 基于人口统计学的推荐机制的工作原理
 

从图中可以很清楚的看到，首先，系统对每个用户都有一个用户 Profile 的建模，其中包括用户的基本信息，例如用户的年龄，性别等等；然后，系统会根据用户的 Profile 计算用户的相似度，可以看到用户 A 的 Profile 和用户 C 一样，那么系统会认为用户 A 和 C 是相似用户，在推荐引擎中，可以称他们是“邻居”；最后，基于“邻居”用户群的喜好推荐给当前用户一些物品，图中将用户 A 喜欢的物品 A 推荐给用户 C。

这种基于人口统计学的推荐机制的好处在于：

1. 因为不使用当前用户对物品的喜好历史数据，所以对于新用户来讲没有“冷启动（Cold Start）”的问题。
2. 这个方法不依赖于物品本身的数据，所以这个方法在不同物品的领域都可以使用，它是领域独立的（domain-independent）。

那么这个方法的缺点和问题是什么呢？这种基于用户的基本信息对用户进行分类的方法过于粗糙，尤其是对品味要求较高的领域，比如图书，电影和音乐等领域，无法得到很好的推荐效果。可能在一些电子商务的网站中，这个方法可以给出一些简单的推荐。另外一个局限是，这个方法可能涉及到一些与信息发现问题本身无关却比较敏感的信息，比如用户的年龄等，这些用户信息不是很好获取。

基于内容的推荐

基于内容的推荐是在推荐引擎出现之初应用最为广泛的推荐机制，它的核心思想是根据推荐物品或内容的元数据，发现物品或者内容的相关性，然后基于用户以往的喜好记录，推荐给用户相似的物品。图 3 给出了基于内容推荐的基本原理。

图 3. 基于内容推荐机制的基本原理
 

图 3 中给出了基于内容推荐的一个典型的例子，电影推荐系统，首先我们需要对电影的元数据有一个建模，这里只简单的描述了一下电影的类型；然后通过电影的元数据发现电影间的相似度，因为类型都是“爱情，浪漫”电影 A 和 C 被认为是相似的电影（当然，只根据类型是不够的，要得到更好的推荐，我们还可以考虑电影的导演，演员等等）；最后实现推荐，对于用户 A，他喜欢看电影 A，那么系统就可以给他推荐类似的电影 C。

这种基于内容的推荐机制的好处在于它能很好的建模用户的口味，能提供更加精确的推荐。但它也存在以下几个问题：

1. 需要对物品进行分析和建模，推荐的质量依赖于对物品模型的完整和全面程度。在现在的应用中我们可以观察到关键词和标签（Tag）被认为是描述物品元数据的一种简单有效的方法。
2. 物品相似度的分析仅仅依赖于物品本身的特征，这里没有考虑人对物品的态度。
3. 因为需要基于用户以往的喜好历史做出推荐，所以对于新用户有“冷启动”的问题。

虽然这个方法有很多不足和问题，但他还是成功的应用在一些电影，音乐，图书的社交站点，有些站点还请专业的人员对物品进行基因编码，比如潘多拉，在一份报告中说道，在潘多拉的推荐引擎中，每首歌有超过 100 个元数据特征，包括歌曲的风格，年份，演唱者等等。

基于协同过滤的推荐

随着 Web2.0 的发展，Web 站点更加提倡用户参与和用户贡献，因此基于协同过滤的推荐机制因运而生。它的原理很简单，就是根据用户对物品或者信息的偏好，发现物品或者内容本身的相关性，或者是发现用户的相关性，然后再基于这些关联性进行推荐。基于协同过滤的推荐可以分为三个子类：基于用户的推荐（User-based Recommendation），基于项目的推荐（Item-based Recommendation）和基于模型的推荐（Model-based Recommendation）。下面我们一个一个详细的介绍着三种协同过滤的推荐机制。

基于用户的协同过滤推荐

基于用户的协同过滤推荐的基本原理是，根据所有用户对物品或者信息的偏好，发现与当前用户口味和偏好相似的“邻居”用户群，在一般的应用中是采用计算“K- 邻居”的算法；然后，基于这 K 个邻居的历史偏好信息，为当前用户进行推荐。下图 4 给出了原理图。

图 4. 基于用户的协同过滤推荐机制的基本原理
 

上图示意出基于用户的协同过滤推荐机制的基本原理，假设用户 A 喜欢物品 A，物品 C，用户 B 喜欢物品 B，用户 C 喜欢物品 A ，物品 C 和物品 D；从这些用户的历史喜好信息中，我们可以发现用户 A 和用户 C 的口味和偏好是比较类似的，同时用户 C 还喜欢物品 D，那么我们可以推断用户 A 可能也喜欢物品 D，因此可以将物品 D 推荐给用户 A。

基于用户的协同过滤推荐机制和基于人口统计学的推荐机制都是计算用户的相似度，并基于“邻居”用户群计算推荐，但它们所不同的是如何计算用户的相似度，基于人口统计学的机制只考虑用户本身的特征，而基于用户的协同过滤机制可是在用户的历史偏好的数据上计算用户的相似度，它的基本假设是，喜欢类似物品的用户可能有相同或者相似的口味和偏好。

基于项目的协同过滤推荐

基于项目的协同过滤推荐的基本原理也是类似的，只是说它使用所有用户对物品或者信息的偏好，发现物品和物品之间的相似度，然后根据用户的历史偏好信息，将类似的物品推荐给用户，图 5 很好的诠释了它的基本原理。

假设用户 A 喜欢物品 A 和物品 C，用户 B 喜欢物品 A，物品 B 和物品 C，用户 C 喜欢物品 A，从这些用户的历史喜好可以分析出物品 A 和物品 C 时比较类似的，喜欢物品 A 的人都喜欢物品 C，基于这个数据可以推断用户 C 很有可能也喜欢物品 C，所以系统会将物品 C 推荐给用户 C。

与上面讲的类似，基于项目的协同过滤推荐和基于内容的推荐其实都是基于物品相似度预测推荐，只是相似度计算的方法不一样，前者是从用户历史的偏好推断，而后者是基于物品本身的属性特征信息。

图 5. 基于项目的协同过滤推荐机制的基本原理
 

同时协同过滤，在基于用户和基于项目两个策略中应该如何选择呢？其实基于项目的协同过滤推荐机制是 Amazon 在基于用户的机制上改良的一种策略，因为在大部分的 Web 站点中，物品的个数是远远小于用户的数量的，而且物品的个数和相似度相对比较稳定，同时基于项目的机制比基于用户的实时性更好一些。但也不是所有的场景都是这样的情况，可以设想一下在一些新闻推荐系统中，也许物品，也就是新闻的个数可能大于用户的个数，而且新闻的更新程度也有很快，所以它的形似度依然不稳定。所以，其实可以看出，推荐策略的选择其实和具体的应用场景有很大的关系。

基于模型的协同过滤推荐

基于模型的协同过滤推荐就是基于样本的用户喜好信息，训练一个推荐模型，然后根据实时的用户喜好的信息进行预测，计算推荐。

基于协同过滤的推荐机制是现今应用最为广泛的推荐机制，它有以下几个显著的优点：

1. 它不需要对物品或者用户进行严格的建模，而且不要求物品的描述是机器可理解的，所以这种方法也是领域无关的。
2. 这种方法计算出来的推荐是开放的，可以共用他人的经验，很好的支持用户发现潜在的兴趣偏好

而它也存在以下几个问题：

1. 方法的核心是基于历史数据，所以对新物品和新用户都有“冷启动”的问题。
2. 推荐的效果依赖于用户历史偏好数据的多少和准确性。
3. 在大部分的实现中，用户历史偏好是用稀疏矩阵进行存储的，而稀疏矩阵上的计算有些明显的问题，包括可能少部分人的错误偏好会对推荐的准确度有很大的影响等等。
4. 对于一些特殊品味的用户不能给予很好的推荐。
5. 由于以历史数据为基础，抓取和建模用户的偏好后，很难修改或者根据用户的使用演变，从而导致这个方法不够灵活。

混合的推荐机制

在现行的 Web 站点上的推荐往往都不是单纯只采用了某一种推荐的机制和策略，他们往往是将多个方法混合在一起，从而达到更好的推荐效果。关于如何组合各个推荐机制，这里讲几种比较流行的组合方法。

1. 加权的混合（Weighted Hybridization）: 用线性公式（linear formula）将几种不同的推荐按照一定权重组合起来，具体权重的值需要在测试数据集上反复实验，从而达到最好的推荐效果。
2. 切换的混合（Switching Hybridization）：前面也讲到，其实对于不同的情况（数据量，系统运行状况，用户和物品的数目等），推荐策略可能有很大的不同，那么切换的混合方式，就是允许在不同的情况下，选择最为合适的推荐机制计算推荐。
3. 分区的混合（Mixed Hybridization）：采用多种推荐机制，并将不同的推荐结果分不同的区显示给用户。其实，Amazon，当当网等很多电子商务网站都是采用这样的方式，用户可以得到很全面的推荐，也更容易找到他们想要的东西。
4. 分层的混合（Meta-Level Hybridization）: 采用多种推荐机制，并将一个推荐机制的结果作为另一个的输入，从而综合各个推荐机制的优缺点，得到更加准确的推荐。

推荐引擎的应用

介绍完推荐引擎的基本原理，基本推荐机制，下面简要分析几个有代表性的推荐引擎的应用，这里选择两个领域：Amazon 作为电子商务的代表，豆瓣作为社交网络的代表。

推荐在电子商务中的应用 – Amazon

Amazon 作为推荐引擎的鼻祖，它已经将推荐的思想渗透在应用的各个角落。Amazon 推荐的核心是通过数据挖掘算法和比较用户的消费偏好于其他用户进行对比，借以预测用户可能感兴趣的商品。对应于上面介绍的各种推荐机制，Amazon 采用的是分区的混合的机制，并将不同的推荐结果分不同的区显示给用户，图 6 和图 7 展示了用户在 Amazon 上能得到的推荐。

图 6. Amazon 的推荐机制 - 首页
 

图 7. Amazon 的推荐机制 - 浏览物品
 

Amazon 利用可以记录的所有用户在站点上的行为，根据不同数据的特点对它们进行处理，并分成不同区为用户推送推荐：

• 今日推荐 (Today's Recommendation For You): 通常是根据用户的近期的历史购买或者查看记录，并结合时下流行的物品给出一个折中的推荐。
• 新产品的推荐 (New For You): 采用了基于内容的推荐机制 (Content-based Recommendation)，将一些新到物品推荐给用户。在方法选择上由于新物品没有大量的用户喜好信息，所以基于内容的推荐能很好的解决这个“冷启动”的问题。
• 捆绑销售 (Frequently Bought Together): 采用数据挖掘技术对用户的购买行为进行分析，找到经常被一起或同一个人购买的物品集，进行捆绑销售，这是一种典型的基于项目的协同过滤推荐机制。
• 别人购买 / 浏览的商品 (Customers Who Bought/See This Item Also Bought/See): 这也是一个典型的基于项目的协同过滤推荐的应用，通过社会化机制用户能更快更方便的找到自己感兴趣的物品。

值得一提的是，Amazon 在做推荐时，设计和用户体验也做得特别独到：

Amazon 利用有它大量历史数据的优势，量化推荐原因。

• 基于社会化的推荐，Amazon 会给你事实的数据，让用户信服，例如：购买此物品的用户百分之多少也购买了那个物品；
• 基于物品本身的推荐，Amazon 也会列出推荐的理由，例如：因为你的购物框中有 ***，或者因为你购买过 ***，所以给你推荐类似的 ***。

另外，Amazon 很多推荐是基于用户的 profile 计算出来的，用户的 profile 中记录了用户在 Amazon 上的行为，包括看了那些物品，买了那些物品，收藏夹和 wish list 里的物品等等，当然 Amazon 里还集成了评分等其他的用户反馈的方式，它们都是 profile 的一部分，同时，Amazon 提供了让用户自主管理自己 profile 的功能，通过这种方式用户可以更明确的告诉推荐引擎他的品味和意图是什么。

推荐在社交网站中的应用 – 豆瓣

豆瓣是国内做的比较成功的社交网站，它以图书，电影，音乐和同城活动为中心，形成一个多元化的社交网络平台，自然推荐的功能是必不可少的，下面我们看看豆瓣是如何推荐的。

图 8 . 豆瓣的推荐机制 - 豆瓣电影
 

当你在豆瓣电影中将一些你看过的或是感兴趣的电影加入你看过和想看的列表里，并为它们做相应的评分，这时豆瓣的推荐引擎已经拿到你的一些偏好信息，那么它将给你展示如图 8 的电影推荐。

图 9 . 豆瓣的推荐机制 - 基于用户品味的推荐
 

豆瓣的推荐是通过“豆瓣猜”，为了让用户清楚这些推荐是如何来的，豆瓣还给出了“豆瓣猜”的一个简要的介绍。

“你的个人推荐是根据你的收藏和评价自动得出的，每个人的推荐清单都不同。你的收藏和评价越多，豆瓣给你的推荐会越准确和丰富。
每天推荐的内容可能会有变化。随着豆瓣的长大，给你推荐的内容也会越来越准。”

这一点让我们可以清晰明了的知道，豆瓣必然是基于社会化的协同过滤的推荐，这样用户越多，用户的反馈越多，那么推荐的效果会越来越准确。

相对于 Amazon 的用户行为模型，豆瓣电影的模型更加简单，就是“看过”和“想看”，这也让他们的推荐更加专注于用户的品味，毕竟买东西和看电影的动机还是有很大不同的。

另外，豆瓣也有基于物品本身的推荐，当你查看一些电影的详细信息的时候，他会给你推荐出“喜欢这个电影的人也喜欢的电影”， 如图 10，这是一个基于协同过滤的应用。

图 10 . 豆瓣的推荐机制 - 基于电影本身的推荐
 

总结

在网络数据爆炸的年代，如何让用户更快的找到想要的数据，如何让用户发现自己潜在的兴趣和需求，无论是对于电子商务还是社会网络的应用都是至关重要的。推荐引擎的出现，使得这个问题越来越被大家关注。但对大多数人来讲，也许还在惊叹它为什么总是能猜到你到底想要些什么。推荐引擎的魔力在于你不清楚在这个推荐背后，引擎到底记录和推理了些什么。

通过这篇综述性的文章，你可以了解，其实推荐引擎只是默默的记录和观察你的一举一动，然后再借由所有用户产生的海量数据分析和发现其中的规律，进而慢慢的了解你，你的需求，你的习惯，并默默的无声息的帮助你快速的解决你的问题，找到你想要的东西。

其实，回头想想，很多时候，推荐引擎比你更了解你自己。

通过第一篇文章，相信大家对推荐引擎有一个清晰的第一印象，本系列的下一篇文章将深入介绍基于协同过滤的推荐策略。在现今的推荐技术和算法中，最被大家广泛认可和采用的就是基于协同过滤的推荐方法。它以其方法模型简单，数据依赖性低，数据方便采集，推荐效果较优等多个优点成为大众眼里的推荐算法“No.1”。本文将带你深入了解协同过滤的秘密，并给出基于 Apache Mahout 的协同过滤算法的高效实现。Apache Mahout 是 ASF 的一个较新的开源项目，它源于 Lucene，构建在 Hadoop 之上，关注海量数据上的机器学习经典算法的高效实现。

感谢大家对本系列的关注和支持。