以下内容主要翻译自2015年腾讯发表的论文 TencentRec: Real-time Stream Recommendation in Practice。对于推荐的搭建还是非常有借鉴意义。
简介
传统的推荐系统通过定期（几小时或几天）分析和更新模型并不能满足实时需求。例如，如果一个用户发布了一条“我想看电影”的tweet，那么在数小时或数天之后更新模型的传统推荐系统将错过这个即时需求。传统推荐人系统无法快速响应用户的偏好变更并实时捕捉用户的兴趣，导致推荐结果不佳。因为用户的实时需求通常会随着时间的推移逐渐消失，传统推荐系统的预测在用户偏好变化迅速的情况下，质量会下降。
实时推荐系统在很多情况下都比传统的要好，与传统的推荐系统不同，实时推荐系统更新更频繁，能够捕捉用户的即时需求，延迟很短，比如几秒钟或毫秒。然而，目前的实时推荐系统有他们的局限性。它们要么在处理大量的数据方面缺乏可扩展性，要么由于现实中的隐式反馈问题和数据稀疏问题，在实际应用中无法产生准确的实时建议。这导致了工业界对实用的实时推荐系统的高需求。
实时推荐的要求可以用“大”、“实时”、“准确”三个关键词来描述。首先，推荐系统应该能够处理海量数据，用“大”来描述。第二，系统必须是实时的，一方面它需要实时响应用户的查询，另一方面它应该能够实时捕捉用户的兴趣。最后，“准确”表明推荐系统应该向用户推荐正确的项目，以提高用户的满意度并增加收入。这些要求不是孤立的，而是相互联系和影响的。
算法设计
“实时”、“精确”和“大”挑战对推荐算法提出了多种要求。“准确”要求TencentRec尽可能提高推荐质量，“实时”和“大”则要求算法易于训练和扩展，以适应分布式系统。这两个要求在某种程度上有冲突。为了快速获得大量数据的建议，建议算法应该使用简单，但这往往会降低建议的总体质量。一个高效的推荐系统必须兼顾这两个方面，为了实现可扩展的推荐，实时推荐系统中常用的方法是数据采样，它可以在有限的计算资源内产生推荐，但往往会降低推荐的准确性。我们非常希望使用所有可用的数据来提供准确的建议。考虑到这一点，我们求助于能够扩展分布式推荐系统并保持其有效性的经典算法，如基于内容的算法、协同过滤算法（CF）、基于关联规则的算法（AR）和情境CTR算法。我们在TencentRec实现上述算法，以满足生产应用程序的各种需求。特别是，我们采用了一些机制使这些算法更适用于生产使用，包括应用人口统计学方法来解决数据稀疏问题，以及一些实时过滤技术来捕捉用户的实时兴趣。此外，我们还开发了一种实用的、可扩展的、基于项目的CF方法，可以很容易地在TencentRec等分布式流计算系统中实现。我们将在这里介绍我们的基于项目的实际CF算法，并以它为例说明用于生产使用的机制。
一种实用的基于项目的协同过滤方法
协同过滤（CF）是工业系统中常用的推荐算法，包括基于用户的CF方法和基于项目的CF方法。CF试图根据用户过去的评级行为向其推荐项目。基于用户的CF方法基于与用户最相似的几个客户生成建议，而基于项目的CF方法通过组合用户以前喜欢的项目的类似项目为用户提供建议列表。实证结果表明，基于项目的CF方法比基于用户的CF方法具有更好的性能。我们在TencentRec开发了一个基于实用项目的CF，我们将在下面详细描述它。为了在实际中使用基于项目的CF，我们根据“大”、“实时”、“准确”三个要求设计了算法。具体来说，我们考虑以下三个方面。首先，为了达到“准确”的目标，我们解决了隐式反馈问题。第二，提出了一种基于实时项目的可扩展增量更新机制；第三，提出了一种实时修剪技术，以降低计算成本。
原始item-based CF
我们首先来回顾下基于项目的基本CF算法。Item-based CF的基本思想是认为用户会喜欢和他以前所喜欢的物品相似的物品，其计算分为相似物品计算和用户喜好预测两部分，相似物品计算是整个算法的关键部分，用户喜好预测根据物品相似度加权预测用户对新物品的评分。项目相似度计算是通过计算每对项目的相似度得分来建立一个类似的项目表。假设我们推荐系统中有n个用户和m个项目，项目的用户评分可以用$n\times m$矩阵R表示，其中每个$r_{p,q}$代表用户$u_p$对项目$i_q$的评分。一个项目可以表示为n个用户给它的评级向量，即$i_q=\left \langle r_{1,q},r_{2,q},…,r_{n,q} \right \rangle$。有许多方法可以测量项目之间的相似性。这里我们使用余弦相似性作为我们的度量，因为它的普及性和简单性。定义如下：
$$sim(i_p,i_q) = \frac{\vec{i_p}\cdot \vec{i_q}}{\left \| \vec{i_p} \right \|\left \| \vec{i_q} \right \|}=\frac{\sum_{u\in U}r_{u,p}r_{u,q}}{\sqrt{\sum r^2_{u,p}}\sqrt{\sum r^2_{u,q}}}$$
其中U示一组用户。特别是如果用户u不给项目$i_p$打分，那么评分$r_{u,p}$被认为是零。要为用户推荐项目，我们需要预测他对未看到的项目给出的评分。用户对目标项的预测由用户对其邻居的评分按照物品相似度进行加权平均来计算：
$$\hat{r}_{u,p} = \frac{\sum_{i_q \in N^k(i_p)}sim(i_p,i_q)r_{u,i_q}}{\sum_{i_q \in N^k(i_p)}sim(i_p,i_q)}$$
其中$N^k(i_p)$表示物品的邻居集合，即与物品$i_p$最相似的k个物品集。
隐式反馈问题的解决方案
在传统的推荐算法中，用户对物品的喜好评分由用户打分决定，而现实世界中，用户对物品的打分数据较少，大部分数据是用户行为数据，如浏览、点击等，这些用户行为具有不确定性，比如，用户点击一个物品详情页后关闭，可能表示用户喜欢该物品因为用户点击了详情页，也可能表示用户不喜欢该物品因为用户又关闭了详情页。这种情况下，我们只能从用户行为数据中去猜测用户的喜好。为了降低对用户行为数据的错误理解造成的损失，我们对原始item-based CF算法进行了改进。具体来说，我们为每个用户行为类型设置了评分权重，衡量不同行为表示的用户喜好的可靠性，如，对点击行为我们设定其评分权重为一分，而购买行为三分，因为用户的购买比点击更有可能说明用户喜欢该物品。对于一个物品，用户可能有多种行为，比如点击、购买、评论等，这时我们取权重最高的用户行为评分作为该用户对物品的喜好可以减少各种杂乱的内隐反馈带来的噪声。用户对项目$i_p$和项目$i_q$的共同评级定义为用户项目评价的最小权重，即：
$$\text{co-rating}(i_p,i_q)=\min(r_{u,p},r_{u,q})$$
其中$r_{u,p}$使用u对于项目$i_p$的行为的最大权重。通过将物品的共同评分设定为两个物品评分中较低的那个，我们限定了对行为错误估计的损失为两者的较小值。由于$\text{co-rating}(i_p,i_q)$从$r_{u,p}r_{u,q}$变为$\min(r_{u,p},r_{u,q})$，我们需要重新定义项目$i_p$和项目$i_q$之间的相似性，以确保相似性得分在[0,1]范围内，如下所示：
$$\text{sim}(i_p,i_q) = \frac{\sum_{u \in U}\min(r_{u,p},r_{u,q})}{\sqrt{\sum r_{u,p}}\sqrt{\sum r_{u,q}}}$$
原始item-based CF中的$\left \| \vec{i_p} \right \|$被设置为$\sqrt{\sum r_{u,p}}$来替换L2正则。
此外，为了清楚地描述，当用户对某个项目表现出隐含的兴趣时，我们说用户对该项目进行了评分或喜欢。
可扩展的增量更新
除了隐式反馈问题外，基于实时项目的CF算法还面临着用户评分变化导致的相似项目表频繁更新的挑战。在传统的推荐系统中，采用静态定期更新策略。但是，定期更新不能满足实时推荐的要求，这是一个快速变化的场景。为了捕捉用户的实时兴趣，增量更新策略在我们基于项目的CF算法中是首选的。在增量更新机制的启发下，我们在实际的CF算法中将项目对的相似性得分分为三部分，如下所示：
$$\text{sim}(i_p,i_q) = \frac{\text{pairCount}(i_p,i_q)}{\sqrt{\text{itemCount}(i_p)}\sqrt{\text{itemCount}(i_q)}}$$
$$\text{itemCount}(i_p)=\sum r_{u,p}$$
$$\text{pairCount}(i_p,i_q)=\sum_{u \in U}\text{co-rating}(i_p,i_q)$$
在这种情况下，项目对的相似性得分可以通过$\text{pairCount}(i_p,i_q)$、$\text{itemCount}(i_p)$和$\text{itemCount}(i_q)$计算，所有这些都可以自然地递增更新。我们可以独立地计算$\text{pairCount}(i_p,i_q)$、$\text{itemCount}(i_p)$和$\text{itemCount}(i_q)$的新值，并将这些值组合起来获得新的相似性得分。因此，相似性得分可以按如下方式递增更新：
$${\text{sim}(i_p,i_q)}’ = \frac{{\text{pairCount}(i_p,i_q)}’}{\sqrt{{\text{itemCount}(i_p)}’}\sqrt{{\text{itemCount}(i_q)}’}} = \frac{pairCount(i_p,i_q)+\Delta \text{co-rating}(i_p,i_q)}{\sqrt{\text{itemCount}(i_p)+\Delta r_{u_p}} \sqrt{\text{itemCount}(i_q)+\Delta r_{u_q}}}$$
其中${\text{sim}(i_p,i_q)}’$表示在收到新观察结果（用户、项目、评分）后的新相似性得分。
我们使用三个层并行计算实时增量item to item的相似性，如图所示。首先，包含用户ID、项目ID和其他有关操作的信息的用户操作元组按用户ID分组，这使我们能够并行地引用不同用户的行为历史记录。根据用户的行为历史，我们可以计算出用户对项目给出的新评级和相关项目对的共同评级。此外，旧的评级和联合评级保存在用户的行为历史记录中。我们可以通过将新评级或共同评级与旧评级进行比较来确定需要重新计算的这些变更评级或共同评级。之后，我们将生成的项目或项目对及其变化的权重（即$\Delta r_{u_p}$和$\Delta \text{co-rating}(i_p,i_q)$转移到下一层。用户分级权重按项目ID或项目键对分组。根据等式，我们可以递增地更新项计数和pairCounts，这可以对每个项或项对并行计算。第三，在得到项计数和对计数之后，我们可以用等式计算出项之间的相似性。注意，通过键分组，在某一点上，只有一个工作节点应该在特定的项对上操作。因此，可以安全地进行计算。
实时剪枝
大量的数据对基于实时项目的CF算法的实现提出了另一个挑战。在基于项目的CF中，如果用户倾向于对两个项目进行评分，则认为这两个项目是相关的。我们为项目对设置了一个链接时间，只有当用户在某个时间段内对两个项目进行评分时，才会将它们视为相关项目。在腾讯，每天产生的用户行为超过40亿。以新闻为例，每个用户平均每天都有超过10条新闻被评为最佳。当新闻之间的链接时间设置为6小时时，即我们为两条新闻生成项目对，如果用户在6小时内对其进行评级，则将为每个用户操作生成10个项目对以进行更新。每一个项目对更新都需要多次计算，从而导致大量用户操作的大量计算。对于大多数情况下的建议，例如电子商务网站，链接时间通常设置为3天或7天，每个用户操作生成近100个项目对。在这种情况下，每个用户操作都会导致数百次计算，其中大部分是不必要的，因为生成的项目对的很大一部分不太相似，只有等式中的$N^k(i_p)$中的项目对我们的预测有用，因此会导致很大的资源成本。
为了解决这一问题，我们利用Hoeffding界理论，开发了一种实时修剪技术。使用Hoefffding界建立了快速的决策树，用于数据流分析，可以表示为：假设x是一个实数随机变量，其范围为R(对于相似性得分，其范围为1），假设我们对该变量进行了n次独立的观测，并与给出了它们的平均值$\hat{x}$。Hoefffing界表明，概率为$1-\delta $时，变量的真实平均值至多为$\hat{x}+\epsilon$，其中：
$$\epsilon = \sqrt{\frac{R^2\ln(1/\delta )}{2n}}$$
在TencentRec中，我们将一个项目对在不同时间点的相似性得分作为随机变量。设t为项目相似项列表的阈值，即相似项$N^k(i_p)$之间的最小相似性得分。给定期望的$\delta$，Hoefffing界保证了项对的正确相似性得分不大于t，概率为$1-\delta$，如果此时已经看到n个更新，且$\epsilon < t – \hat{x}$，那么在观察到一些项对的相似性更新操作后，我们可以修剪不同的项对，即不能在$N^k(i_p)$中的项。由于相似度计算涉及两个项目，因此修剪是双向的，我们以两个项目相似项目列表的最小阈值为t来进行修剪计算。请注意，t表示要记录的项目对$(i_p,i_q)$的最小相似性得分，即只有当$\text{sim}(i_p,i_q)$大于t时，$i_q$才可能在$N^k(i_p)$中。实时修剪的基于项目的CF算法的计算如算法如下图所示，其中$n_{ij}$记录项对$i$、$j$和$L_i$表示项$i$的修剪项集。
解决数据稀疏
大量的数据对推荐算法提供高质量推荐提出了额外的挑战。在大多数推荐系统中，与用户项目对的数量相比，已经获得的评分数量通常非常少。我们称之为“数据稀疏”问题。数据稀疏问题往往会影响推荐系统的性能，导致推荐不足。在大数据时代，这比以往任何时候都要严重。由于用户的时间有限，已知评级的数量有限，但这些项目以前所未有的速度增长，导致一个具有少量评级的大型用户项目矩阵。因此，用户项矩阵比以往更加稀疏。
我们开发了两种机制来解决数据稀疏问题，包括人口聚类和基于人口的补充。首先，我们根据用户的性别、年龄和受教育程度等属性将其分为不同的人口统计学组，一个人口统计学组的用户通常具有相似的兴趣或偏好。如图所示，全局用户项矩阵明显比
人口统计组的用户项矩阵稀疏。在人口统计用户组中运行推荐算法，我们将得到一个更精确的模型并产生更精确的结果。
基于聚集的人口统计学群体，我们可以依靠群体信息来进一步了解用户。具体来说，对于历史数据较少的用户，我们提出了基于人口统计的算法（DB）来进一步补充推荐结果。数据库的目标是根据用户的人口统计学向其提供建议。具体来说，我们计算每个人口统计学组的热门项目，即组中最受欢迎的项目。对于诸如基于项目的CF和CB等常用算法无法有效生成好的建议的情况，例如对于新用户或那些特别不活跃的用户，我们可以利用DB算法的结果并向用户推荐热门项目。
实时过滤机制
在像TencentRec这样的实时推荐系统中，推荐会随着时间不断发展。我们利用两种技术来捕捉用户的实时兴趣，包括滑动窗口和实时个性化过滤。我们使用滑动窗口技术捕捉全球实时趋势，并使用实时个性化过滤来满足单个用户的实时需求。这些技术简单而有效地保持了系统对最近数据的敏感性，滑动窗口是一种常用的实时数据流计算技术，用于“忘记”旧数据。滑动时间窗口处理当前时间窗口中的数据，然后丢弃一小组过期数据，并向前移动一小步。在TencentRec，我们将时间窗口分成几个会话，在推荐计算中只考虑最近的会话W。例如，实现滑动窗口时，用于实时基于项目的CF中计算项目计数和pairCounts的$r_{u,p}$将引用用户u在最近W会话中给出的评级，如下所示：
$$\text{sim}(i_p,i_q) = \frac{\sum_{w \in W}\text{pairCount}_w(i_p,i_q)}{\sqrt{\sum_{w \in W}\text{itemCount}_w(i_p)}\sqrt{\sum_{w \in W}\text{itemCount}_w(i_q)}}$$
其中，$\text{itemCount}_w$和$\text{pairCount}_w$是第w时间会话中的相应计数，可以增量更新，例如，${\text{itemCount}_w(i_p)}’=\text{itemCount}_w(i_p)+\Delta r_{u_p}$。这样，我们就实现了以每次会话的时间间隔为滑动步骤的滑动时间窗。由于不同类型的数据具有不同的生命周期，我们提供了在不同时间间隔的滑动窗口上获取建议的灵活性。整个时间窗口和小时间会话的时间间隔都可以由用户指定，这样我们就可以设置不同的时间间隔，以适应不同应用程序的不同要求。
除了滑动窗口机制外，我们还提出了一种实时个性化过滤技术，以满足用户的实时需求。对于每个用户，我们记录他感兴趣的最近k项。基于用户的兴趣随着时间的推移逐渐消失的观点，我们认为只有最近的k项对于用户的推荐计算是有效的。因此，在预测未知的评分时，我们只考虑用户最近的K项做预测。以基于项目的CF为例，公式中的$N^k(i_p)$将重新定义为用户最近的k项集合。此外，如果算法不能以这种方式产生有效的建议，例如，在基于项目的CF计算中，项目对的相似性分数太低，我们使用实时DB算法结果进行补充。实践表明，这种实时补充比基于旧行为的建议更有效。
实施细节
在本节中，我们将介绍TencentRec的实施细节，首先介绍我们的项目概况，然后说明如何解决实施过程中遇到的问题。同时还揭示了实现中的一些优化。
拓扑框架
Storm中的主要概念是流，它表示一个无边界的数据元组序列。“Spout”和“Bolt”是Storm进行流处理的基本操作。“Spout”负责生成Storm集群的输入流，并将数据传递给“Bolt”。一个“Bolt”可以消耗任意数量的输入流，并以某种方式转换这些流。“Bolt”还可以发出新的流并将其传递给其他一些“Bolt”。复杂的流处理，如基于项目的CF推荐算法，可能需要多个“Spout”或“Bolt”的图，其中边缘指示流应该如何传递。该图称为“拓扑”，这是我们提交给Storm进行实时计算的内容。除非消息被杀死，否则拓扑将永远处理消息。
TencentRec作为一个通用的推荐系统，旨在为具有不同特点的不同生产应用提供推荐。这些应用程序对系统提出了不同的要求，从算法到过滤技术。例如，在新闻推荐中，新的项目不断出现，项目的生命周期很短，在这种情况下，基于项目的CF算法不太合适，而是适用于CB方法。在广告推荐中，用户是否单击广告取决于从广告图片到投放位置的任何因素，其中点击率预测算法比一般推荐算法更有效。此外，应用程序通常有自己的过滤技术，例如，推荐的项目应该是一个特定的类别或在一定范围内的价格。为了服务于所有这些应用程序，我们需要一个包含所有这些必需算法的拓扑框架，并且可以很容易地扩展以满足不同应用程序的过滤需求，如图所示：
TencentRec的处理可分为三大层：
- 第一层：预处理层。从TDAccess获取数据，解析原始消息，过滤不合格的数据元组，并将数据元组转换到下一层。
- 第二层：算法层。是TencentRec的主要部分，负责算法的主要计算。我们已经实现了上文中提到的一些著名的推荐算法，包括基于项目的CF、AR、CB、DB和情景CTR算法。
- 第三层：存储层。根据不同应用程序的不同规则对算法层生成的结果进行过滤，并在TDstore中更新计算结果，在响应应用程序的建议查询时，可以通过API轻松访问。
特别地，我们将TencentRec使用的计算单元（“Spout”和“Bolt”）分为四种类型：
- 应用公共单元是指不同应用的公共处理步骤，如预处理和结果存储。它们在图中表示为蓝灰色矩形。
- 应用特定单元是矩形白色单位，表示特定应用（“Spout”和“Bolt”）所特有的单位。
- 算法公共单元是多个算法所需的单元，通常是数据统计，例如用蓝灰色圆角矩形表示的项计数。
- 算法特定单元是图中的白色圆角矩形单位，指特定于算法的单位，通常是特定的计算，如CFBolt和ARBolt。
请注意，拓扑中的某些功能可以分为多个步骤，由多个Blot（如CFBolt）完成。为了图的清晰，我们将这些步骤组合成一个螺栓来表示函数。
公共Blot和特定Blot之间的这种区别使得多个应用程序共享公共步骤，多个算法共享统计数据。因此，我们可以尽可能降低计算和存储成本，从而使资源得到最佳利用。此外，如图6所示，我们将数据统计和算法计算分离到算法层中。数据统计部分计算数据元组的统计结果并将其更新到TDstore中。算法计算部分从TDstore中读取统计数据，执行算法计算。这种设计带来了更好的可扩展性，我们可以方便地扩展或调整推荐算法以满足新的应用程序需求。此外，它还增强了系统的鲁棒性。由于拓扑中的所有计算单元都是无状态的，因此该拓扑可以快速地进行故障恢复，并具有良好的容错性。
通过拓扑框架的多层结构，TencentRec能够为不同的应用提供建议。对于每个应用程序，我们可以构建一个包含必要单元及其特殊要求的拓扑。所有应用程序都是并行运行的，而不是相互作用的。为了方便地部署不同的拓扑，我们实现了一个模块来从XML配置文件生成Storm拓扑。在XML配置文件中，可以方便地导出和部署不同的拓扑结构，我们实现了一个从XML配置文件生成Storm拓扑结构的模块。XML配置文件说明了它需要哪些Spout和Blot以及如何组成它们来构造拓扑。要为特定的应用程序生成拓扑，我们只需要重写XML文件。示例XML文件和生成的Storm拓扑如图7所示，它实现了情境ctr算法，其中包含一个Spout和四个Blot。
临时突发事件
实现TencentRec的第一个挑战是临时突发事件。用户在一天中的不同时间段有不同的活动。高峰时段的用户活动数可能是非高峰时段的数倍甚至数百倍。考虑一个热点新闻爆出，许多用户阅读新闻，导致用户反馈爆出的情况。它需要大量的资源来处理数据元组的突发、处理大量的读写和大量的计算。在这种情况下，存储单元上的大量读写会降低TDstore的性能，我们根据用户在时间突发事件中的活动总是具有项目的小部分t吸引大部分用户的注意力。我们在数据实例的粒度中执行细粒度缓存，即键值对，以使缓存得到最佳利用。实现缓存的主要挑战是如何保持数据一致性。首先，我们使用“流分组”将具有相同密钥的元组发送给同一个工作者，以保证缓存的有效性。此外，对于更新其他工作人员读取的数据的工作人员，他们首先从缓存中读取数据，然后在缓存和TDstore中更新数据。这样，我们就保存了更新工人的读取时间，同时也不影响其他工人使用更新的数据。
热点问题
下一个挑战是我们所说的“热点问题”，指的是热和冷项目之间的访问不平等问题。以新闻为例，热门新闻的阅读时间远远超过一般新闻。将有大量为计算生成的热门新闻记录，例如itemCount统计信息。所有这些记录将通过网络发送给一个Worker，以计算或更新新闻的统计数据。大量的转换和计算
将导致负责处理热点新闻的worker负担过重，导致worker之间的分配失衡或worker崩溃。
我们采用组合技术来解决这个问题。合并器是一个映射，用于缓冲即将到来的元组。当一个Blot接收到一个元组时，它首先将它放入合并器，合并器将用相同的键对元组进行部分合并。合并器操作可以是递增、加法或最大化。我们将从合并器中获取元组，并按照预先定义的时间间隔执行诸如tdstore写入之类的昂贵计算。以itemCount统计为例，我们将观察到用户阅读同一热门新闻的众多阅读操作。我们首先在合并器中添加这些用户的评级变化权重，然后将整个组评级变化权重放入tdstore。
使用合并器，可以显著减少读写次数。由于联合操作比读写操作轻得多，系统的性能将大大提高。此外，在暂时性突发情况下，合路器的效能甚至会得到提高。这是因为合并器在指定的时间间隔内将具有相同键的数据元组组合在一起。因此，合成器映射的使用率在时间突发事件中会增加。
其他优化
在TencentRec的实现中，我们采用了一些额外的技术来加速实时计算，减少资源的使用。最重要的优化之一是多哈希技术。提出了解决TencentRec实施中的写冲突问题。当我们进行人口统计用户组计数统计时，就会出现问题，例如，项计数和pairCounts。一个组中用户的操作可能不会分发到同一个Blot，因为他们的用户ID不同。在这种情况下，每个Blot将向TDstore发送一个itemCount或pairCount更新请求，从而导致来自不同工作人员的多个写入请求，即写入冲突。一个简单的解决方案是在TDstore写入中使用锁机制。但是，这将使编程复杂化，并降低TDstore的性能。我们采用多哈希策略来解决这个问题。对于每个用户操作元组，我们首先根据用户ID将其散列到相应的Blot。更新用户对项目的评级后，我们将根据用户组ID散列评级更改权重到下一个Blot，同一用户组的评级将转到同一Blot。下一个Blot接收用户分级更改的权重数据元组，并更新组对该项的分级。
部署和性能
通过实施丰富的算法，TencentRec可以很容易地应用于各种生产应用，如电子商务网站、新闻、视频、移动应用、社交网络广告推荐等。在腾讯公司，TencentRec已被应用于处理不同类型的产品。
图9显示了TencentRec在生产应用程序中的部署。特别地，我们使用“TDProcess”来表示图中基于Storm的数据处理组件，这有助于更清晰地表达TDAccess和TDStore的用法。在TDAccess的帮助下，TDProcess从各种应用程序获取数据流。将TDProcess的计算结果保存在TDstore中。推荐前端负责与用户交互，即处理用户查询，并向用户显示推荐。推荐引擎接受前端预处理的用户查询，利用TDStore中的计算结果生成推荐结果。前端接受建议结果并以适当的形式向用户显示建议。此外，我们还可以轻松地在部署中添加其他组件，例如离线计算平台来进行离线计算，以及监视器来获得系统运行的概述。
参考链接：
