Lambda架构与推荐在电商网站实践

王富平

现为1号店搜索与精准化部门架构师，之前在百度从事数据挖掘相关工作，对实时处理有着深刻的研究。一直从事大数据相关研发工作，2013年开发了一款SQL实时处理框架，致力于建设高可用的大数据业务系统。

一、Lambda架构

Lambda架构由Storm的作者Nathan Marz提出。旨在设计出一个能满足实时大数据系统关键特性的架构，具有高容错、低延时和可扩展等特性。

Lambda架构整合离线计算和实时计算，融合不可变性（Immutability），读写分离和复杂性隔离等一系列架构原则，可集成Hadoop，Kafka，Storm，Spark，HBase等各类大数据组件。

1.1 Lambda架构理论点

Lambda架构对系统做了如下抽象：

Query = Function(All Data)

简言之：查询是应用于数据集的函数。 data是自变量，query是因变量。

Lambda有两个假设

不可变假设：Lambda架构要求data不可变，这个假设在大数据系统是普遍成立的：因为日志是不可变的，某个时刻某个用户的行为，一旦记录下来就不可变。

Monoid假设：理想情况下满足Monoid 的function可以转换为:

query = function(all data/ 2) + function(all data/ 2)

Monoid的概念来源于范畴学（Category Theory），其一个重要特性是满足结合律。如整数的加法就满足Monoid特性：(a+b)+c=a+(b+c)

不满足Monoid特性的函数很多时候可以转化成多个满足Monoid特性的函数的运算。如多个数的平均值avg函数，多个平均值没法直接通过结合来得到最终的平均值，但是可以拆成分母除以分子，分母和分子都是整数的加法，从而满足Monoid特性。

1.2 Lambda架构

三层架构：批处理层、实时处理层、服务层，如图1所示：

图1

批处理层：批量处理数据，生成离线结果

实时处理层：实时处理在线数据，生成增量结果

服务层：结合离线、在线计算结果，推送上层

1.3 Lambda架构优缺点

优点：

实时：低延迟处理数据

可重计算：由于数据不可变，重新计算一样可以得到正确的结果

容错：第二点带来的，程序bug、系统问题等，可以重新计算

复杂性分离、读写分离

缺点：

开发和运维的复杂性：Lambda需要将所有的算法实现两次，一次是为批处理系统，另一次是为实时系统，还要求查询得到的是两个系统结果的合并，可参考 http://www.infoq.com/cn/news/2014/09/lambda-architecture-questions

1.4 典型推荐架构

实时处理范式的需求

推荐系统的最终目的是提高转化率，手段是推送用户感兴趣的、需要的产品。为什么需要实时处理范式？

1号店会根据你实时浏览、加车、收藏、从购物车删除、下单等行为，计算相关产品的权重，把相应的产品立刻更新到猜你喜欢栏位。同样在亚马逊搜索浏览了《基督山伯爵》这本书，亚马逊首页很快增加一行新推荐：包含4个版本《基督山伯爵》

答案不言而喻：让推荐引擎更具时效性。如图2、图3所示：

图2

图3

Netflix推荐架构

Netflix推荐架构如图4所示

图4

批处理层：从Hive、pig数据仓库，离线计算推荐模型，生成离线推荐结果

实时处理层：从消息队列（Hermes、User Event Queue）实时拉取用户行为数据与事件，生成在线推荐结果

服务层：结合离线、在线推荐结果，为用户生成推荐列表

二、1号店推荐系统实践

2.1. 推荐引擎组件

目前共有6大推荐引擎：

用户意图：实时分析用户行为，存储短期内兴趣偏好

用户画像：用户兴趣偏好的长期积累（商品类目、品牌等），自然属性（年龄、性别），社会属性（居住地、公司）

千人千面：群体分析（某一大学、某一小区、公司、好友群）

情境推荐：根据季节、节日、天气等特定情境做推荐

反向推荐：根据商品购买周期等，方向生成推荐结果

主题推荐：分析用户与主题的匹配度（如：美食家、极客等），根据主题对用户进行推荐

产品架构如图5所示

图5

今天主要讨论其中的主题推荐

2.2 主题推荐

首先主题推荐有三个步骤

建立关系（主题与商品，用户与商品，用户与主题）

选品，建立主题选品池

推荐，根据用户与主题的关系，从选品池为用户进行推荐用公式表示就是：Topic_recommend = topic_recommend_function(offline data) 仅仅完成上面步骤，不需要“实时处理范式”就可以完成后来主题推荐加入了“增量推荐”功能，通过用户的实时行为，对推荐结果进行调整

根据用户在线行为（浏览、购买、评论）等，调整离线推送的主题推荐结果用公式表示就是Topic_recommend= mege ( topic_recommend_function1(offline data), topic_recommend_function2(online data) )

显然这演变成了一个Lambda架构，如图6所示

图6

2.3 主题推荐存储设计

存储最重要的就是 “主题推荐结果表”，需要满足如下特性

KV查询，根据用户id查询推荐结果；

保留一定时间内历史推荐数据。

根据上述两个特点，我们决定选用HBase。HBase的kv、多版本属性满足上述需求。有如下两个要点

读写分离

我们使用HBase主从方式，来读写分离，采用HBase主从的主要原因是

在CAP理论里面HBase牺牲的是可用性保证强一致性，flush、split、compaction都会影响可用性。检测region server挂断、恢复region都需要一定时间，这段时间内region数据不可用。

离线任务大量读写，对region server造成压力（gc、网络、flush、compaction），影响前端响应速度。

Cache

为了进一步提高响应速度，我们在服务层增加了一级缓存，采用1号店内部分布式缓存ycache(与memcache的封装)。

产品效果如图7所示

图7

2.4 HBase的维护

热点均衡：不要指望预split解决一切问题，热点的造成不可避免，尤其随着业务数据的增长，一些冷region该合并就合并。

做好为HBase修复bug的准备，尤其是升级新版本。

三、Lambda的未来

与其说Lambda的未来，不如说“实时处理范式”与“批处理范式”的未来。工程实践中Lambda之前提到的缺点有不少体会

逻辑一致性。许多公共数据分析逻辑需要实现两套，并且需要保证一致性。换个角度来看就是公共逻辑提取费力。

维护、调试两套平台

Jay Kreps认为Lambda架构是大数据方案中的临时解决方案，原因是目前工具不成熟。他提供了一个替代架构，该架构基于他在Linkedin构建Kafka和Samza的经验，他还声称该架构在具有相同性能特性的同时还具有更好的开发和运维特性。

图8

让我想起了Spark streaming既可以做实时处理，又很自然做批量。让我想起了Storm的DRPC，就是为了做离线处理。有人说streaming本质是批量方式，实际上“实时”没有绝对界限，关键在于延迟。你认为10s，我也可以认为2s内才算实时。

对于Lambda架构问题，社区提出了Kappa架构，一套系统满足实时、批处理需求。目前看来，是朝着 “实时”框架去主动包含“批量处理”的方向发展

四、个人的两点思考

两种不同的需求，一个框架搞定，是不是很熟悉？我们都想搞大而全，一劳永逸的事情，但许多往往被证明是错的。

MR是不是过时了？we need more，期待着数据与逻辑更便捷、更深入的交集。

五、Q&A

Q1：HBase你们遇到最诡异的是啥问题?

因为hdfs客户端没有设置读超时，导致HBase lock hang住，最后集群宕机。

Q2：玩推荐引擎首先想到的是mahout，王老师是否也有这方面的涉猎?

mahout、mlib 这些东西都是数据挖掘框架，主要看算法好坏，选谁区别不大。

Q3：日志量多大？Kafka集群配置怎样broker、replica等？碰到什么坑吗？

1天2T多数据，Kafka是整个公司公用。Kafka还是比较稳定，我们这边几乎没遇到问题，Storm问题出了不少。Kafka集群replica有些是2、有些3，broker是10。遇到大量数据的时候Kafka每隔一阵可能出现CLOSE_WAIT的问题

Q4：千人千面引擎最后体现的效果是什么？用在什么地方？

千人千面效果，针对小区用户转化率提升100%

Q5：请问下推荐排序时使用了什么算法，以及大概多少人负责算法模块？

在app首页正在尝试逻辑回归和learn to rank，7~8人做算法

Q6：1号店对新登陆用户做什么推荐处理? 主题推荐人工介入量有多大？1号店对其推荐算法出过转化率外，从算法角度会关心哪些指标?

新用户冷启动，采用两个策略

数据平滑

热销优质商品补充

推荐最重要的是看排序效果，主要是推荐位置的转换率。

Q7：Storm都遇到哪些填好久都填不完的坑可以分享下么？

Storm在高tps时候容易消息堆积。之前读Kafka，拉的模式。实时推荐需要实时的反应用户的行为，用户明明下单了还在推荐。后来读取订单的行为用了自主研发的jumper，推的方式解决了快速得到订单行为，其他行为用Kafka。

资源分配、隔离不合理。其他任务出现内存泄露等问题会影响其他任务task。

Q8：HBase热点问题怎么解决的呢？是分析key的分布，然后写脚本split么？

基本思路一样，写工具检测。重点在request量，不在key的分布。

Q9：批处理层向服务层推送离线计算结果的周期是怎样的？会因数据量大而对线上的HBase造成冲击吗？

目前是一天一次，冲击不大。 1、错峰； 2、bulkload；3、读写分离。

转载于:https://www.cnblogs.com/davidwang456/articles/8360497.html

Lambda架构与推荐在电商网站实践相关推荐

电商详情页缓存架构（一）电商网站的商品详情页架构
小型电商网站的商品详情页的页面静态化架构以及其缺陷小型电商网站,一般使用页面静态化的方案,提前将数据渲染到模板中. 问题:每次模板变更,模板对应的所有数据需要全部重新渲染大型电商网站的异步多级缓存 ...
ASP.NET三层架构全站开发的电商网站
这里写自定义目录标题欢迎使用Markdown编辑器新的改变功能快捷键合理的创建标题,有助于目录的生成如何改变文本的样式插入链接与图片如何插入一段漂亮的代码片生成一个适合你的列表创建一 ...
大型网站的架构演进从一个电商网站开始
为了更好的理解,我们用电商网站来举例,作为一个交易类型的网站,一定会具备用户(用户注册.用户管理).商品(商品展示.商品管理).交易(下单.支付)这些功能假如我们只需要支持这几个基本功能,那么我们最开 ...
大型电商网站架构案例和技术架构【推荐】
大型网站架构是一个系列文档,欢迎大家关注.本次分享主题:电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功能需求外,还具备一定的高性能,高可用,可伸 ...
大型网站电商网站架构案例和技术架构的示例
大型网站架构是一个系列文档,欢迎大家关注.本次分享主题:电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功能需求外,还具备一定的高性能,高可用,可伸 ...
大型网站架构系列：电商网站架构案例(1)
大型网站架构系列:电商网站架构案例(1) 大型网站架构是一个系列文档,欢迎大家关注.本次分享主题:电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功 ...
大型电商网站架构分析
电商网站架构案例.从电商网站的需求,到单机架构,逐步演变为常用的,可供参考的分布式架构的原型.除具备功能需求外,还具备一定的高性能,高可用,可伸缩,可扩展等非功能质量需求(架构目标). 根据实际需要, ...
关于大型网站架构系列：电商网站架构案例（目前最有深意喜欢的文章）
算法与数据结构C++精解 ThinkPHP5.0+小程序商城构建全栈应用 AngularJS仿拉勾网WebApp开发移动端单页应用 Thinkphp 5.0实战仿百度糯米开发多商家电商平台原文出处 ...
电商总结（八）如何打造一个小而精的电商网站架构
前面写过一些电商网站相关的文章,这几天有时间,就把之前写得网站架构相关的文章,总结整理一下.把以前的一些内容就连贯起来,这样也能系统的知道,一个最小的电商平台是怎么一步步搭建起来的.对以前的文章感兴趣 ...

Lambda架构与推荐在电商网站实践

Lambda架构与推荐在电商网站实践相关推荐

最新文章

热门文章