??xml version="1.0" encoding="utf-8" standalone="yes"?> 剖析Elasticsearch集群pd늛了当今最行的分布式搜烦引擎Elasticsearch的底层架构和原型实例?/p> 本文是这个系列的W二,我们讨论Elasticsearch如何处理分布式的三个C((p(consensus)、ƈ?concurrency)和一?consistency))的问题、Elasticsearch分片的内部概念,比如translog(预写日志QWAL(Write Ahead Log))Q以及Lucene中的Dc?/p> 本系列已l得到原文著者Ronak Nathani的授?/p> 在本pd?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">前一?/a>中,我们讨论了Elasticsearch的底层存储模型及CRUDQ创建、读取、更新和删除Q操作的工作原理。在本文中,我将分nElasticsearch是如何应对分布式pȝ中的一些基本挑战的Q以及分片的内部概念。这其中包括了一些操作方面的事情QInsight Data的工E师们已l在使用Elasticsearch构徏的数据^C上成功地实践q真正理解。我在本文中主要讲qͼ p是分布式pȝ的一基本挑战。它要求pȝ中的所有进E?节点必须对给定数据的?状态达成共识。已l有很多p法诸如Raft?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Paxos{,从数学上的证明了是行得通的。但是,Elasticsearch却实C自己的共识系l?zen discovery)QElasticsearch之父Shay Banon?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">q篇文章中解释了其中的原因。zen discovery模块包含两个部分Q?/p> Elasticsearch是端对端的系l,其中的所有节点彼此相q,有一个master节点保持z跃Q它会更新和控制集群内的状态和操作。徏立一个新的Elasticsearch集群要经q一ơ选DQ选D是pingq程的一部分Q在所有符合条件的节点中选取一个masterQ其他节点将加入q个master节点。ping间隔参数 注意Q?/span>默认情况下,client节点和data节点不参与这个选Dq程。可以在elasticsearch.yml配置文g中,通过讄 故障的原理是这LQmaster节点会ping所有其他节点,以检查它们是否还zȝQ然后所有节点ping回去Q告诉master他们q活着?/p> 如果使用默认的设|,Elasticsearch有可能遭?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">裂脑问题的困扰。在|络分区的情况下Q一个节点可以认为masterMQ然后选自׃为masterQ这导致了一个集内出现多个master。这可能会导致数据丢失,也可能无法正合q数据。可以按照如下公式,Ҏ有资格参加选D的节ҎQ设|法定票数属性的|来避免爆裂的发生?/p> q个属性要求法定票数的节点加入新当选的master节点Q来完成q获得新master节点接受的masterw䆾。对于确保群集稳定性和在群集大变化时动态地更新Q这个属性是非常重要的。图a和b演示了在|络分区的情况下Q设|或不设|?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;"> 注意Q?/span>对于一个生产集来_使用3个节点专门做masterQ这3个节点将不服务于M客户端请求,而且在Q何给定时间内L只有1个活跃?/p> 我们已经搞清楚了Elasticsearch中共识的处理Q现在让我们来看看它是如何处理ƈ发的?/p> Elasticsearch是一个分布式pȝQ支持ƈ发请求。当创徏/更新/删除h到达d片时Q它也会被^行地发送到分片副本上。但是,q些h到达的顺序可能是乱序的。在q种情况下,Elasticsearch使用乐观q发控制Q来保文档的较新版本不会被旧版本覆盖?/p> 每个被烦引的文档都拥有一个版本号Q版本号在每ơ文档变更时递增q应用到文档中。这些版本号用来保有序接受变更。ؓ了确保在我们的应用中更新不会D数据丢失QElasticsearch的API允许我们指定文g的当前版本号Q以使变更被接受。如果在h中指定的版本h分片上存在的版本hQ请求失败,q意味着文档已经被另一个进E更C。如何处理失败的hQ可以在应用层面来控制。Elasticsearchq提供了其他的锁选项Q可以通过q篇来阅诅R?/p> 当我们发送ƈ发请求到Elasticsearch后,接下来面对的问题?#8212;—如何保证q些h的读写一_现在Q还无法清楚回答QElasticsearch应落?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">CAP三角形的哪条边上Q我不打在q篇文章里解册个素来已久的争辩?/p> 但是Q我们要一L下如何用Elasticsearch实现写读一致?/p> 对于写操作而言QElasticsearch支持的一致性别,与大多数其他的数据库不同Q允讔R查,来查看有多少允许写入的可用分片。可选的值有quorum?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">one 对于L作而言Q新的文档只有在h旉间隔之后Q才能被搜烦到。ؓ了确保搜索请求的q回l果包含文档的最新版本,可设|replication?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">sync(默认)Q这操作在主分片和副本碎片都完成后才q回写请求。在q种情况下,搜烦h从Q何分片得到的q回l果都包含的是文档的最新版本。即使我们的应用Z更高的烦引率而设|了replication=asyncQ我们依然可以ؓ搜烦h讄参数_preference?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">primary。这P搜烦h查询主分片Qƈ保l果中的文档是最新版本?/p> 我们已经了解了Elasticsearch如何处理p、ƈ发和一_让我们来看看分片内部的一些主要概念,正是q些特点让Elasticsearch成ؓ一个分布式搜烦引擎?/p> 因ؓ关系数据库的发展Q预写日?WAL)或者事务日?translog)的概忉|已遍及数据库领域。在发生故障的时候,translog能确保数据的完整性。translog的基本原理是Q变更必d数据实际的改变提交到盘上之前,被记录下来ƈ提交?/p> 当新的文档被索引或者旧的文档被更新ӞLucene索引发生变_q些变更被提交到磁盘以持久化。这是一个很昂贵的操作,如果在每个请求之后都被执行。因此,q个操作在多个变更持久化到磁盘时被执行一ơ。正如我们在上一文?/a>中描q的那样QLucene提交的冲z?flush)操作默认?0分钟执行一ơ或者当translog变得太大(默认512MB)时执行。在q样的情况下Q有可能失去2个Lucene提交之间的所有变更。ؓ了避免这U问题,Elasticsearch采用了translog。所有烦?删除/更新操作被写入到translogQ在每个索引/删除/更新操作执行之后Q默认情况下是每5U)Qtranslog会被同步以确保变更被持久化。translog被同步到d片和副本之后Q客L才会收到写请求的认?/p> 在两ơLucene提交之间发生g故障的情况下Q可以通过重放translog来恢复自最后一ơLucene提交前的M丢失的变_所有的变更会被烦引所接受?/p> 注意Q?/span>在重启Elasticsearch实例之前昑ּ地执行冲ztranslogQ这样启动会更快Q因重放的translog被清I?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">POST /_all/_flush命o可用于冲z集中的所有烦引?/p> 使用translog的冲z操作,在文件系l缓存中的段被提交到盘Q索引中的变更持久化。现在让我们来看看Lucene的段?/p> Lucene索引是由多个D늻成,D|w是一个功能齐全的倒排索引。段是不可变的,允许Lucene新的文档增量地d到烦引中Q而不用从头重建烦引。对于每一个搜索请求而言Q烦引中的所有段都会被搜索,q且每个D会消耗CPU的时钟周、文件句柄和内存。这意味着D늚数量多Q搜索性能会越低?/p> Z解决q个问题QElasticsearch会合q小D到一个较大的D(如下图所C)Q提交新的合q段到磁盘,q删除那些旧的小Dc?/p> q会在后台自动执行而不中断索引或者搜索。由于段合ƈ会耗尽资源Q媄响搜索性能QElasticsearch会节制合q过E,为搜索提供够的可用资源?/p> 从搜索请求角度来_一个Elasticsearch索引中给定分片内的所有LuceneD都会被搜烦Q但是,从Elasticsearch集群角度而言Q获取所有匹配的文档或者深入有序结果文档是有害的。在本系列的后箋文章中我们将揭晓原因Q让我们来看一下接下来的主题,内容包括了一些在Elasticsearch中ؓ相关性搜索结果的低gq所做的权衡?/p> 查看原文地址Q?/span>Anatomy of an Elasticsearch Cluster: Part II 剖析Elasticsearch集群pd늛了当今最行的分布式搜烦引擎Elasticsearch的底层架构和原型实例。本文是q个pd的第三篇Q我们将讨论Elasticsearch是如何提供近实时搜烦q权衡搜索相x计的?/p> 本系列已l得到原文著者Ronak Nathani的授?/p> 在本pd?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">前一?/a>中,我们讨论了Elastisearch如何解决分布式系l中的一些基本挑战。在本文中,我们探讨Elasticsearch在近实时搜烦及其权衡计算搜烦相关性方面的内容QInsight Data的工E师们已l在使用Elasticsearch构徏的数据^C上,Ҏ有所实践。我在本文中主要讲qͼ 虽然Elasticsearch中的变更不能立即可见Q它q是提供了一个近实时的搜索引擎。如前一?/a>中所qͼ提交Lucene的变更到盘是一个代h늚操作。ؓ了避免在文档Ҏ询依然有效的时候,提交变更到磁盘,Elasticsearch在内存缓冲和盘之间提供了一个文件系l缓存。内存缓?默认情况??U刷Cơ,在文件系l缓存中使用倒排索引创徏一个新的段。这个段是开攄q对搜烦有效?/p> 文gpȝ~存可以拥有文g句柄Q文件可以是开攄、可ȝ或者是关闭的,但是它存在于内存之中。因为刷新间隔默认是1U,变更不能立即可见Q所以说是近实时的。因?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">translog 你可以在创徏/更新/删除操作后显式地h索引Q变更立即可见Q但我ƈ不推荐你q样做,因ؓq样会创建出来非常多的小segment而媄响搜索性能。对于每ơ搜索请求来_l定Elasticsearch索引分片中的全部LuceneD都会被搜烦刎ͼ但是Q对于Elasticsearch来说Q获取全部匹配的文档或者很q果页的文档是有害的。让我们来一L看ؓ什么是q样?/p> 当我们的一ơ搜索请求在Elasticsearch中匹配了很多的文档,默认情况下,q回的第一只包含?0条结果。search API提供?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">from?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">size参数Q用于指定对于匹配搜索的全部文档Q要q回多深的结果。D例来_如果我们想看到匹配搜索的文档中,排名?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">50?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">60之间的文档,可以讄from=50Q?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">size=10。当每个分片接收到这个搜索请求后Q各自会创徏一个容量ؓfrom+size的优先队列来存储该分片上的搜索结果,然后结果返回给协调节点?/p> 如果我们想看到排名ؓ50,000?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">50,010的结果,那么每个分片要创Z个容量ؓ50,010的优先队列来存储l果Q而协调节点要在内存中?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">数量为shards * 50,010的结果进行排序。这个别的分页有可能得到结果,也有可以无法实现Q这取决于我们的g资源Q但是这以说明Q我们得非常心C用深分页Q因非常Ҏ使我们的集群崩溃?/p> 一U获取全部匹配结果文档的可行性方案是使用scroll APIQ它的角色更像关pL据库中的游标。?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">scroll API无法q行排序Q每个分片只要有匚w搜烦的文档,׃持箋发送结果给协调节点?/p> 获取大量文档的时候,对结果进行得分排序会非常昂贵。ƈ且由于Elasticsearch是分布式pȝQؓ每个文档计算搜烦相关性得分是非常昂贵的。现在,让我们一L看计搜索相x的诸多权衡中的一U?/p> Elasticsearch使用tf-idf来计?a href="http://insightdataengineering.com/blog/elasticsearch-crud/#search-relevance" style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">搜烦相关?/a>。由于其分布式的性质Q计全局的idf(inverse document frequencyQ逆文档频?非常昂贵。反之可以这P每个分片计算本地的idfq将相关性得分分配给l果文档Q返回的l果只关乎该分片上的文档。同样地Q所有分片用本地idf计算的相x得分,q回l果文档Q协调节点对所有结果排序ƈq回前几条。这样做在大多数情况下是没有问题的,除非索引的关键字词项有倾斜或者单个分片上没有代表全局的够数据?/p> 比如_如果我们搜烦“insight”q个词,但包?insight"q个词项的大多数文档都存攑֜一个分片上Q这样以来匹配查询的文档不能公q_在每个分片上q行排序Q因为每个分片上的本地idf的值非怸同,得到的搜索结果可能不会非常相兟뀂同样地Q如果没有够的数据Q那么对于某些搜索而言Q本地idf的值可能大有不同,l果也会不如预期相关。在有够数据的真实场景中,本地idfg般会于均等Q搜索结果是相关的,因ؓ文档得到了公q的得分?/p> q里?U应Ҏ地idf得分的办法,但都不徏议真正在生环境中用?/p> 在本pd的过d中Q我们回了一些Elasticsearch的基本原则,对于我们理解q上手ElasticsearchQ这些内定w帔R要。在接下来的一中Q我用Apache Spark来研IElasticsearch中的索引数据?/p> 查看英文原文Q?/span>Anatomy of an Elasticsearch Cluster: Part III 剖析Elasticsearch集群pd늛了当今最行的分布式搜烦引擎Elasticsearch的底层架构和原型实例?/p> 本文是这个系列的W一,在本文中Q我们将讨论的Elasticsearch的底层存储模型及CRUDQ创建、读取、更新和删除Q操作的工作原理?/p> 本系列已l得到原文著者Ronak Nathani的授?/p> Elasticsearch是当今最行的分布式搜烦引擎QGitHub?SalesforceIQ、Netflix{公司将其用于全文检索和分析应用。在InsightQ我们用CElasticsearch的诸多不同功能,比如Q?/p> 正是因ؓElasticsearch如此行q且在我们w边Q我军_深入研究一下。本文,我将分nElasticsearch的存储模型和CRUD操作的工作原理?/p> 当我在思考分布式pȝ是如何工作时Q我脑v里的图案是这LQ?/p> 水面以上的是APIQ以下的才是真正的引擎,一切魔q般的事仉发生在水下。本文所x的就是水下的部分Q我们将xQ?/p> 在我们深入这些概念之前,让我们熟悉下相关的术语?/p> Elasticsearch中的索引是组l数据的逻辑I间(好比数据库)?个Elasticsearch的烦引有1个或者多个分?默认??。分片对应实际存储数据的Lucene的烦引,分片自n是一个搜索引擎。每个分片有0或者多个副?默认??。Elasticsearch的烦引还包含"type"(像数据库中的表)Q用于逻辑上隔ȝ引中的数据。在Elasticsearch的烦引中Q给定一个typeQ它的所有文档会拥有相同的属?像表的schema)?/p> (点击攑֤囑փ) 图a展示了一个包?个分片的Elasticsearch索引Q每个分片拥?个副本。这些分片组成了一个Elasticsearch索引Q每个分片自w是一个Lucene索引。图b展示了Elasticsearch索引、分片、Lucene索引和文档之间的逻辑关系?/p> 对应于关pL据库术语 现在我们熟悉了Elasticsearch世界的术语,接下来让我们看一下节Ҏ哪些不同的角艌Ӏ?/p> 一个Elasticsearch实例是一个节点,一l节点组成了集群。Elasticsearch集群中的节点可以配置?U不同的角色Q?/p> 主节?/span>Q控制Elasticsearch集群Q负责集中的操作,比如创徏/删除一个烦引,跟踪集群中的节点Q分配分片到节点。主节点处理集群的状态ƈq播到其他节点,q接收其他节点的认响应?/p> 每个节点都可以通过讑֮配置文gelasticsearch.yml中的node.master属性ؓtrue(默认)成ؓ主节炏V?/p> 对于大型的生产集来_推荐使用一个专门的主节Ҏ控制集群Q该节点不处理M用户h?/p> 数据节点Q持有数据和倒排索引。默认情况下Q每个节炚w可以通过讑֮配置文gelasticsearch.yml中的node.data属性ؓtrue(默认)成ؓ数据节点。如果我们要使用一个专门的主节点,应将?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">node.data属性设|ؓfalse?/p> 客户端节?/span>Q如果我们将node.master属性和node.data属性都讄?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">falseQ那么该节点是一个客L节点Q扮演一个负载均衡的角色Q将到来的请求\由到集群中的各个节点?/p> Elasticsearch集群中作为客L接入的节点叫协调节点。协调节点会客Lh路由到集中合适的分片上。对于读h来说Q协调节Ҏơ会选择不同的分片处理请求,以实现负载均衡?/p> 在我们开始研I发送给协调节点的CRUDh是如何在集群中传播ƈ被引擎执行之前,让我们先来看一下Elasticsearch内部是如何存储数据,以支持全文检索结果的低gq服务的?/p> Elasticsearch使用?a style="text-decoration: none; color: #286ab2; outline: none !important; margin: 0px; border: 0px; padding: 0px;">Apache LuceneQ后者是Doug Cutting(Apache Hadoop之父)使用Java开发的全文索工具库Q其内部使用的是被称为倒排索引的数据结构,其设计是为全文检索结果的低gq提供服务。文档是Elasticsearch的数据单位,Ҏ档中的词进行分词,q创建去重词的有序列表Q将词项与其在文档中出现的位|列表关联,便Ş成了倒排索引?/p> q和一本书后面的烦引非常类|即书中包含的词汇与其出现的页码列表关联。当我们说文档被索引了,我们指的是倒排索引。我们来看下如下2个文档是如何被倒排索引的: 文档1(Doc 1): Insight Data Engineering Fellows Program 如果我们x包含词项"insight"的文档,我们可以扫描q个(单词有序?倒排索引Q找?insight"q返回包含改词的文档IDQ示例中是Doc 1和Doc 2?/p> Z提高可检索?比如希望大小写单词都q回)Q我们应当先分析文档再对其烦引。分析包?个部分: 默认情况下,Elasticsearch使用标准分析器,它用了Q?/p> q有很多可用的分析器在此不列举,请参考相x档?/p> Z实现查询时能得到对应的结果,查询时应使用与烦引时一致的分析器,Ҏ档进行分析?/p> 注意Q标准分析器包含了停用词qo器,但默认情况下没有启用?/p> 现在Q倒排索引的概念已l清楚,让我们开始CRUD操作的研I吧。我们从写操作开始?/p> 当我们发送烦引一个新文档的请求到协调节点后,发生如下一l操作: Elasticsearch集群中的每个节点都包含了改节点上分片的元数据信息。协调节?默认)使用文档ID参与计算Q以便ؓ路由提供合适的分片。Elasticsearch使用MurMurHash3函数Ҏ档IDq行哈希Q其l果再对分片数量取模Q得到的l果x索引文档的分片?/p> 下图展示了写h及其数据?/p> (点击攑֤囑փ) 删除和更C都是写操作。但是Elasticsearch中的文档是不可变的,因此不能被删除或者改动以展示其变更。那么,该如何删除和更新文档呢? 盘上的每个D都有一个相应的.del文g。当删除h发送后Q文档ƈ没有真的被删除,而是?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">.del文g中被标记为删除。该文档依然能匹配查询,但是会在l果中被qo掉。当D合q?我们在本系列接下来的文章中讲到)Ӟ?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">.del文g中被标记为删除的文档不会被写入新段?/p> 接下来我们看更新是如何工作的。在新的文档被创建时QElasticsearch会ؓ该文档指定一个版本号。当执行更新Ӟ旧版本的文档?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">.del文g中被标记为删除,新版本的文档被烦引到一个新Dc旧版本的文档依然能匚w查询Q但是会在结果中被过滤掉?/p> 文档被烦引或者更新后Q我们就可以执行查询操作了。让我们看看在Elasticsearch中是如何处理查询h的?/p> L作包?部分内容Q?/p> 我们来看下每个阶D|如何工作的?/p> 在这个阶D,协调节点会将查询h路由到烦引的全部分片(d片或者其副本)上。每个分片独立执行查询,qؓ查询l果创徏一个优先队列,以相x得分排?我们在本系列的后箋文章中讲?。全部分片都匹配文档的ID及其相关性得分返回给协调节点。协调节点创Z个优先队列ƈ对结果进行全局排序。会有很多文档匹配结果,但是Q默认情况下Q每个分片只发送前10个结果给协调节点Q协调节点ؓ全部分片上的q些l果创徏优先队列q返回前10个作为hit?/p> 当协调节点在生成的全局有序的文档列表中Qؓ全部l果排好序后Q它向包含原始文档的分片发赯求。全部分片填充文档信息ƈ其q回l协调节炏V?/p> 下图展示了读h及其数据?/p> (点击攑֤囑փ) 如上所qͼ查询l果是按相关性排序的。接下来Q让我们看看相关性是如何定义的?/p> 相关性是由搜索结果中Elasticsearch打给每个文档的得分决定的。默认用的排序法是tf/idf(词频/逆文档频?。词频衡量了一个词在文档中出现的ơ数 (频率高 == 相关性越?Q逆文档频率衡量了词项在全部烦引中出现的频率,是一个烦引中文档L的百分比(频率高 == 相关性越?。最后的得分是tf-idf得分与其他因子比?短语查询中的)词项接近度?模糊查询中的)词项怼度等的组合?/p> q些CRUD操作由Elasticsearch内部的一些数据结构所支持Q这对于理解Elasticsearch的工作机刉帔R要。在接下来的pd文章中,我将带大家走q类似的那些概念q告诉大家在使用Elasticsearch中有哪些坑?/p> 查看原文地址Q?/span>http://insightdataengineering.com/blog/elasticsearch-crud
]]>
]]>p——裂脑问题及法定票数的重要?/h2>
ping_interval
的默认值是1U,ping时参数ping_timeout
的默认值是3U。因点要加入Q它们会发送一个请求给master节点Q加入超时参?span style="font-weight: 600; margin: 0px; border: 0px; padding: 0px;">join_timeout
的默认值是ping_timeout
值的20倍。如果master出现问题Q那么群集中的其他节点开始重新ping以启动另一ơ选D。这个ping的过E还可以帮助一个节点在忽然失去masterӞ通过其他节点发现master?/p>discovery.zen.master_election.filter_client
属性和discovery.zen.master_election.filter_data
属性ؓfalse
来改变这U默认行为?/p>discovery.zen.minimum_master_nodes = int(# of master eligible nodes/2)+1
minimum_master_nodes
q发
一?#8212;—保d一?/h2>
Translog(预写日志)
Lucene的段
接下来有什么?
]]>q实时搜?/h2>
Z么深层分在分布式搜索中是有害的Q?/h2>
计算搜烦相关性中的权?/h2>
]]>1 辨析Elasticsearch的烦引与Lucene的烦?/h2>
Elasticsearch Index == Database Types == Tables Properties == Schema
2 节点cd
存储模型
文档2(Doc 2): Insight Data Science Fellows Program剖析写操?/h2>
创徏((C)reate)
shard = hash(document_id) % (num_of_primary_shards)
更新((U)pdate)和删?(D)elete)
剖析L?(R)ead)
查询阶段
提取阶段
搜烦相关?/h2>
接下来有什么?
]]>
“探烦推荐引擎内部的秘?#8221;pd带领读者从入q学习探烦推荐引擎的机Ӟ实现ҎQ其中还涉及一些基本的优化ҎQ例如聚cd分类的应用。同时在理论讲解的基上,q会l合 Apache Mahout 介绍如何在大规模数据上实现各U推荐策略,q行{略优化Q构建高效的推荐引擎的方法。本文作个系列的W一文章,深入介l推荐引擎的工作原理Q和其中涉及的各U推荐机Ӟ以及它们各自的优~点和适用场景Q帮助用h楚的了解和快速构建适合自己的推荐引擎?/span>
信息发现
如今已经q入了一个数据爆炸的时代Q随着 Web 2.0 的发展, Web 已经变成数据分n的^収ͼ那么Q如何让Z在v量的数据中想要找C们需要的信息变得越来越难?/span>
在这L情Ş下,搜烦引擎QGoogleQBingQ百度等{)成ؓ大家快速找到目标信息的最好途径。在用户对自己需求相Ҏ的时候,用搜索引擎很方便的通过关键字搜索很快的扑ֈ自己需要的信息。但搜烦引擎q不能完全满用户对信息发现的需求,那是因ؓ在很多情况下Q用户其实ƈ不明自q需要,或者他们的需求很隄单的关键字来表述。又或者他们需要更加符合他们个人口呛_喜好的结果,因此出现了推荐系l,与搜索引擎对应,大家也习惯称它ؓ推荐引擎?/span>
随着推荐引擎的出玎ͼ用户获取信息的方式从单的目标明确的数据的搜烦转换到更高更符合h们用习惯的信息发现?/span>
如今Q随着推荐技术的不断发展Q推荐引擎已l在电子商务 (E-commerceQ例?AmazonQ当当网 ) 和一些基?social 的社会化站点 ( 包括音乐Q电影和图书分nQ例如豆瓣,Mtime {?) 都取得很大的成功。这也进一步的说明了,Web2.0 环境下,在面Ҏv量的数据Q用户需要这U更加智能的Q更加了解他们需求,口味和喜好的信息发现机制?/span>
回页?/span>
推荐引擎
前面介绍了推荐引擎对于现在的 Web2.0 站点的重要意义,q一章我们将讲讲推荐引擎到底是怎么工作的。推荐引擎利用特D的信息qo技术,不同的物品或内Ҏ荐给可能对它们感兴趣的用戗?/span>
?1 l出了推荐引擎的工作原理图,q里先将推荐引擎看作黑盒Q它接受的输入是推荐的数据源Q一般情况下Q推荐引擎所需要的数据源包括:
昑ּ的用户反馈能准确的反应用户对物品的真实喜好,但需要用户付出额外的代hQ而隐式的用户行ؓQ通过一些分析和处理Q也能反映用L喜好Q只是数据不是很_Q有些行为的分析存在较大的噪韟뀂但只要选择正确的行为特征,隐式的用户反馈也能得到很好的效果Q只是行为特征的选择可能在不同的应用中有很大的不同,例如在电子商务的|站上,购买行ؓ其实是一个能很好表现用户喜好的隐式反馈?/span>
推荐引擎Ҏ不同的推荐机制可能用到数据源中的一部分Q然后根据这些数据,分析Z定的规则或者直接对用户对其他物品的喜好q行预测计算。这h荐引擎可以在用户q入的时候给他推荐他可能感兴的物品?/span>
推荐引擎的分cd以根据很多指标,下面我们一一介绍一下:
Ҏq个指标Q推荐引擎可以分为基于大众行为的推荐引擎和个性化推荐引擎
q是一个最基本的推荐引擎分c,其实大部分h们讨论的推荐引擎都是个性化的推荐引擎,因ؓ从根本上_只有个性化的推荐引擎才是更加智能的信息发现q程?/span>
其实q里讲的是如何发现数据的相关性,因ؓ大部分推荐引擎的工作原理q是Z物品或者用L怼集进行推荐。那么参考图 1 l出的推荐系l原理图Q根据不同的数据源发现数据相x的Ҏ可以分ؓ以下几种Q?/span>
可以惌在v量物品和用户的系l中Q推荐引擎的计算量是相当大的Q要实现实时的推荐务必需要徏立一个推荐模型,关于推荐模型的徏立方式可以分Z下几U:
其实在现在的推荐pȝ中,很少有只使用了一个推荐策略的推荐引擎Q一般都是在不同的场景下使用不同的推荐策略从而达到最好的推荐效果Q例?Amazon 的推荐,它将Z用户本n历史购买数据的推荐,和基于用户当前浏览的物品的推荐,以及Z大众喜好的当下比较流行的物品都在不同的区域推荐给用户Q让用户可以从全方位的推荐中扑ֈ自己真正感兴的物品?/span>
q一章的幅Q将详细介绍各个推荐机制的工作原理,它们的优~点以及应用场景?/span>
Z人口l计学的推荐机制QDemographic-based RecommendationQ是一U最易于实现的推荐方法,它只是简单的Ҏpȝ用户的基本信息发现用L相关E度Q然后将怼用户喜爱的其他物品推荐给当前用户Q图 2 l出了这U推荐的工作原理?/span>
从图中可以很清楚的看刎ͼ首先Q系l对每个用户都有一个用?Profile 的徏模,其中包括用户的基本信息,例如用户的年龄,性别{等Q然后,pȝ会根据用L Profile 计算用户的相似度Q可以看到用?A ?Profile 和用?C 一P那么pȝ会认为用?A ?C 是相似用P在推荐引擎中Q可以称他们?#8220;d”Q最后,Z“d”用户的喜好推荐l当前用户一些物品,图中用?A 喜欢的物?A 推荐l用?C?/span>
q种Z人口l计学的推荐机制的好处在于:
那么q个Ҏ的缺点和问题是什么呢Q这U基于用L基本信息对用戯行分cȝҎq于_糙Q尤其是对品呌求较高的领域Q比如图书,电媄和音乐等领域Q无法得到很好的推荐效果。可能在一些电子商务的|站中,q个Ҏ可以l出一些简单的推荐。另外一个局限是Q这个方法可能涉及到一些与信息发现问题本n无关却比较敏感的信息Q比如用Lq龄{,q些用户信息不是很好获取?/span>
Z内容的推荐是在推荐引擎出C初应用最为广泛的推荐机制Q它的核心思想是根据推荐物品或内容的元数据Q发现物品或者内容的相关性,然后Z用户以往的喜好记录,推荐l用L似的物品。图 3 l出了基于内Ҏ荐的基本原理?/span>
?3 中给ZZ内容推荐的一个典型的例子Q电影推荐系l,首先我们需要对电媄的元数据有一个徏模,q里只简单的描述了一下电qcdQ然后通过电媄的元数据发现电媄间的怼度,因ؓcd都是“爱情Q浪?#8221;电媄 A ?C 被认为是怼的电影(当然Q只Ҏcd是不够的Q要得到更好的推荐,我们q可以考虑电媄的导演,演员{等Q;最后实现推荐,对于用户 AQ他喜欢看电?AQ那么系l就可以l他推荐cM的电?C?/span>
q种Z内容的推荐机制的好处在于它能很好的徏模用L口味Q能提供更加_的推荐。但它也存在以下几个问题Q?/span>
虽然q个Ҏ有很多不_问题Q但他还是成功的应用在一些电影,音乐Q图书的C交站点Q有些站点还请专业的人员对物品进行基因编码,比如潘多拉,在一份报告中说道Q在潘多拉的推荐引擎中,每首歌有过 100 个元数据特征Q包括歌曲的风格Q年份,演唱者等{?/span>
随着 Web2.0 的发展,Web 站点更加提倡用户参与和用户贡献Q因此基于协同过滤的推荐机制因运而生。它的原理很单,是Ҏ用户对物品或者信息的偏好Q发现物品或者内Ҏw的相关性,或者是发现用户的相x,然后再基于这些关联性进行推荐。基于协同过滤的推荐可以分ؓ三个子类Q基于用L推荐QUser-based RecommendationQ,Z目的推荐(Item-based RecommendationQ和Z模型的推荐(Model-based RecommendationQ。下面我们一个一个详l的介绍着三种协同qo的推荐机制?/span>
Z用户的协同过滤推?/span>
Z用户的协同过滤推荐的基本原理是,Ҏ所有用户对物品或者信息的偏好Q发C当前用户口味和偏好相似的“d”用户,在一般的应用中是采用计算“K- d”的算法;然后Q基于这 K 个邻居的历史偏好信息Qؓ当前用户q行推荐。下?4 l出了原理图?/span>
上图C意出基于用L协同qo推荐机制的基本原理,假设用户 A 喜欢物品 AQ物?CQ用?B 喜欢物品 BQ用?C 喜欢物品 A Q物?C 和物?DQ从q些用户的历史喜好信息中Q我们可以发现用?A 和用?C 的口呛_偏好是比较类似的Q同时用?C q喜Ƣ物?DQ那么我们可以推断用?A 可能也喜Ƣ物?DQ因此可以将物品 D 推荐l用?A?/span>
Z用户的协同过滤推荐机制和Z人口l计学的推荐机制都是计算用户的相似度QƈZ“d”用户计推荐,但它们所不同的是如何计算用户的相似度Q基于h口统计学的机制只考虑用户本n的特征,而基于用L协同qo机制可是在用L历史偏好的数据上计算用户的相似度Q它的基本假设是Q喜Ƣ类似物品的用户可能有相同或者相似的口味和偏好?/span>
Z目的协同过滤推?/span>
Z目的协同过滤推荐的基本原理也是cM的,只是说它使用所有用户对物品或者信息的偏好Q发现物品和物品之间的相似度Q然后根据用L历史偏好信息Q将cM的物品推荐给用户Q图 5 很好的诠释了它的基本原理?/span>
假设用户 A 喜欢物品 A 和物?CQ用?B 喜欢物品 AQ物?B 和物?CQ用?C 喜欢物品 AQ从q些用户的历史喜好可以分析出物品 A 和物?C 时比较类似的Q喜Ƣ物?A 的h都喜Ƣ物?CQ基于这个数据可以推断用?C 很有可能也喜Ƣ物?CQ所以系l会物?C 推荐l用?C?/span>
与上面讲的类|Z目的协同过滤推荐和Z内容的推荐其实都是基于物品相似度预测推荐Q只是相似度计算的方法不一P前者是从用户历史的偏好推断Q而后者是Z物品本n的属性特征信息?/span>
同时协同qoQ在Z用户和基于项目两个策略中应该如何选择呢?其实Z目的协同过滤推荐机制是 Amazon 在基于用L机制上改良的一U策略,因ؓ在大部分?Web 站点中,物品的个数是q远于用户的数量的Q而且物品的个数和怼度相Ҏ较稳定,同时Z目的机制比Z用户的实时性更好一些。但也不是所有的场景都是q样的情况,可以设想一下在一些新L荐系l中Q也许物品,也就是新ȝ个数可能大于用户的个敎ͼ而且新闻的更新程度也有很快,所以它的Ş似度依然不稳定。所以,其实可以看出Q推荐策略的选择其实和具体的应用场景有很大的关系?/span>
Z模型的协同过滤推?/span>
Z模型的协同过滤推荐就是基于样本的用户喜好信息Q训l一个推荐模型,然后Ҏ实时的用户喜好的信息q行预测Q计推荐?/span>
Z协同qo的推荐机制是C应用最为广泛的推荐机制Q它有以下几个显著的优点Q?/span>
而它也存在以下几个问题:
在现行的 Web 站点上的推荐往往都不是单U只采用了某一U推荐的机制和策略,他们往往是将多个Ҏ混合在一P从而达到更好的推荐效果。关于如何组合各个推荐机Ӟq里讲几U比较流行的l合Ҏ?/span>
介绍完推荐引擎的基本原理Q基本推荐机Ӟ下面要分析几个有代表性的推荐引擎的应用,q里选择两个领域QAmazon 作ؓ电子商务的代表,豆瓣作ؓC交|络的代表?/span>
推荐在电子商务中的应?– Amazon
Amazon 作ؓ推荐引擎的E,它已l将推荐的思想渗透在应用的各个角落。Amazon 推荐的核心是通过数据挖掘法和比较用L消费偏好于其他用戯行对比,借以预测用户可能感兴的商品。对应于上面介绍的各U推荐机ӞAmazon 采用的是分区的合的机制Qƈ不同的推荐l果分不同的区显C给用户Q图 6 和图 7 展示了用户在 Amazon 上能得到的推荐?/span>
?6. Amazon 的推荐机?- 首页
?7. Amazon 的推荐机?- 览物品
Amazon 利用可以记录的所有用户在站点上的行ؓQ根据不同数据的特点对它们进行处理,q分成不同区为用h送推荐:
值得一提的是,Amazon 在做推荐Ӟ设计和用户体验也做得特别独到Q?/span>
Amazon 利用有它大量历史数据的优势,量化推荐原因?/span>
另外QAmazon 很多推荐是基于用L profile 计算出来的,用户?profile 中记录了用户?Amazon 上的行ؓQ包括看了那些物品,C那些物品Q收藏夹?wish list 里的物品{等Q当?Amazon 里还集成了评分等其他的用户反馈的方式Q它们都?profile 的一部分Q同ӞAmazon 提供了让用户自主理自己 profile 的功能,通过q种方式用户可以更明的告诉推荐引擎他的品味和意图是什么?/span>
推荐在社交网站中的应?– 豆瓣
豆瓣是国内做的比较成功的C交|站Q它以图书,电媄Q音乐和同城zdZ心,形成一个多元化的社交网l^収ͼ自然推荐的功能是必不可少的,下面我们看看豆瓣是如何推荐的?/span>
当你在豆瓣电׃一些你看过的或是感兴趣的电影加入你看过和想看的列表里,qؓ它们做相应的评分Q这时豆瓣的推荐引擎已经拿到你的一些偏好信息,那么它将l你展示如图 8 的电影推荐?/span>
豆瓣的推荐是通过“豆瓣?#8221;Qؓ了让用户清楚q些推荐是如何来的,豆瓣q给Z“豆瓣?#8221;的一个简要的介绍?/span>
“你的个h推荐是根据你的收藏和评h自动得出的,每个人的推荐清单都不同。你的收藏和评h多Q豆瓣给你的推荐会越准确和丰富?/span>
每天推荐的内容可能会有变化。随着豆瓣的长大,l你推荐的内容也会越来越准?/span>”
q一点让我们可以清晰明了的知道,豆瓣必然是基于社会化的协同过滤的推荐Q这L戯多,用户的反馈越多,那么推荐的效果会来准?/span>
相对?Amazon 的用戯为模型,豆瓣电媄的模型更加简单,是“看过”?#8220;想看”Q这也让他们的推荐更加专注于用户的品呻I毕竟C西和看电q动机q是有很大不同的?/span>
另外Q豆瓣也有基于物品本w的推荐Q当你查看一些电q详细信息的时候,他会l你推荐?#8220;喜欢q个电媄的h也喜Ƣ的电媄”Q?如图 10Q这是一个基于协同过滤的应用?/span>
在网l数据爆炸的q代Q如何让用户更快的找到想要的数据Q如何让用户发现自己潜在的兴和需求,无论是对于电子商务还是社会网l的应用都是臛_重要的。推荐引擎的出现Q得这个问题越来越被大家关注。但对大多数人来Ԍ也许q在惊叹它ؓ什么L能猜C到底惌些什么。推荐引擎的力在于你不清楚在这个推荐背后,引擎到底记录和推理了些什么?/span>
通过q篇lD性的文章Q你可以了解Q其实推荐引擎只是默默的记录和观察你的一举一动,然后再借由所有用户生的量数据分析和发现其中的规律Q进而慢慢的了解你,你的需求,你的习惯Qƈ默默的无声息的帮助你快速的解决你的问题Q找C惌的东ѝ?/span>
其实Q回头想惻I很多时候,推荐引擎比你更了解你自己?/span>
通过W一文章,怿大家Ҏ荐引擎有一个清晰的W一印象Q本pd的下一文章将深入介绍Z协同qo的推荐策略。在C的推荐技术和法中,最被大家广泛认可和采用的就是基于协同过滤的推荐Ҏ。它以其Ҏ模型单,数据依赖性低Q数据方侉K集,推荐效果较优{多个优Ҏ为大众眼里的推荐法“No.1”。本文将带你深入了解协同qo的秘密,q给出基?Apache Mahout 的协同过滤算法的高效实现。Apache Mahout ?ASF 的一个较新的开源项目,它源?LuceneQ构建在 Hadoop 之上Q关注v量数据上的机器学习经典算法的高效实现?/span>
感谢大家Ҏpd的关注和支持?/span>