高可用架构分享及传播在架构领域具有典型意义的文章

　　高可用架构分享及传播在架构领域具有典型意义的文章

　　摘要：高可用架构文章的分享与传播在架构领域具有典型意义。本文基于王富平的分享记录。请注明高可用架构公众号 ArchNotes。王富平现任1号店搜索精准部架构师。此前在百度从事数据挖掘相关工作，对实时处理有深刻理解...

　　

　　算法

　　

　　大数据

　　

　　架构

　　

　　卡夫卡

　　

　　HBase

　　王富平

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

　　一、Lambda 架构

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

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

　　1.1 Lambda 架构理论要点

　　Lambda 架构将系统抽象如下：

　　查询 = 函数（所有数据）

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

　　Lambda 有两个假设

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

　　Monoid 假设：理想情况下，满足 Monoid 的函数可以转换为：

　　查询=函数（所有数据/2)+函数（所有数据/2)

　　Monoid 的概念来自范畴论，其重要特征之一就是满足结合律。比如整数相加满足幺半群特征：(a+b)+c=a+(b+c)

　　不符合 Monoid 特性的函数，往往可以转化为多个符合 Monoid 特性的函数的运算。比如多个数的average avg函数，多个平均值不能直接组合得到最终的平均值，但是可以分为父级和分子除法。分母和分子都是整数的加法，满足幺半群特性。

　　1.2 Lambda 架构

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

　　

　　图一

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

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

　　服务层：结合离线和在线计算结果并推送上层

　　1.3 Lambda 架构优缺点

　　优点：

　　实时：低延迟处理数据

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

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

　　复杂度分离，读写分离

　　缺点：

　　开发运维复杂度：Lambda需要将所有算法实现两次，一次用于批处理系统，一次用于实时系统。还要求查询的结果是两个系统的组合，可以参考

　　1.4 典型推荐架构

　　实时处理范式需求

　　推荐系统的最终目标是通过推送用户感兴趣和需要的产品来提高转化率。为什么我们需要实时处理范式？

　　1号店会根据您的实时浏览、添加购物车、采集、删除购物车、下单等情况计算相关商品的权重，并立即将相应商品更新至猜你喜欢栏目。我还在亚马逊上搜索并查看了《基督山伯爵》一书。亚马逊主页上很快添加了一个新推荐：收录了 4 个版本的《基督山伯爵》。

　　答案不言而喻：让推荐引擎对时间更敏感。如图2、图3：

　　

　　图二

　　

　　图 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(离线数据), topic_recommend_function2(在线数据))

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

　　

　　图 6

　　2.3 主题推荐收纳设计

　　存储最重要的是“话题推荐结果表”，需要满足以下特点

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

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

　　基于以上两个特点，我们决定使用HBase。 HBase 的 kv 和多版本属性满足上述要求。主要有以下两点

　　读写分离

　　我们采用HBase的主从方式进行读写分离。采用HBase主从的主要原因是

　　在CAP理论中，HBase牺牲了可用性来保证强一致性。刷新、拆分和压缩都会影响可用性。检测区域服务器挂掉并恢复区域需要一定的时间，在此期间区域数据不可用。

　　大量离线任务读写，给region server带来压力（gc、network、flush、compaction），影响前端响应速度。

　　缓存

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

　　产品效果如图7

　　

　　图 7

　　2.4 HBase 维护

　　热点平衡：不要指望拆分就能解决所有问题，热点在所难免，尤其是随着业务数据的增长，一些冷区在合并时应该合并。

　　准备修复 HBase 的错误，尤其是升级新版本。

　　三、Lambda 的未来

　　Lambda 的未来与其说是“实时处理范式”和“批处理范式”的未来，还不如说是“批处理范式”的未来。之前Lambda在工程实践中提到的缺点有很多经验

　　逻辑一致性。很多常见的数据分析逻辑需要实现两套，并且需要保证一致性。从另一个角度来看，公共逻辑的提取是费力的。

　　维护和调试两套平台

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

　　

　　图 8

　　让我想起 Spark 流可以进行实时处理，也可以自然地进行批处理。让我想起了 Storm 的 DRPC，只是为了离线处理。有人说流式传输本质上是一种批处理方法。事实上，“实时”是没有界限的。关键是延迟。你认为10s，我也可以认为实时只有2s。

　　针对Lambda架构问题，社区提出了Kappa架构，一个满足实时和批处理需求的系统。目前似乎正在走向“实时”框架，积极将“批处理”纳入其中。

　　四、个人两个想法

　　是否熟悉两种不同的需求和一种框架？我们都想一劳永逸地做大而全面的事情，但很多事情往往被证明是错误的。

　　MR 过时了吗？我们需要更多，期待更方便、更深入的数据与逻辑的交集。

　　五、Q&A

　　Q1：您在使用 HBase 时遇到的最奇怪的问题是什么？

　　因为hdfs客户端没有设置读超时，导致HBase锁挂起，集群宕机。

　　Q2：玩推荐引擎的时候首先想到的是驯象师。王老师也涉足这个领域吗？

　　Mahout 和 mlib 都是数据挖掘框架。主要看算法的好坏，选谁没多大区别。

　　Q3：日志量有多大？ Kafka集群的broker、replica等如何配置？有坑吗？

　　Kafka 每天超过 2T 数据，全公司共享。 Kafka还是比较稳定的。我们这里几乎没有问题，还有很多 Storm 问题。有的Kafka集群replicas是2、约3个，brokers是10个。遇到大量数据时，Kafka可能会偶尔出现CLOSE_WAIT的问题

　　Q4：千面引擎的最终效果是什么？用在什么地方？

　　千人千面效应，社区用户转化率提升100%

　　Q5：推荐排名采用什么算法，算法模块有多少人负责？

　　在app首页，我们正在尝试逻辑回归和学习排名，7~8个人正在研究算法

　　新登录用户的推荐流程是怎样的？题目推荐的人工干预量是多少？除了推荐算法的转化率，1号店还会从算法的角度关心哪些指标？

　　新用户冷启动，采取两种策略

　　数据平滑

　　热销精品补充

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

　　Q7：Storm遇到过哪些坑了很久都填不完的，可以分享一下吗？

　　Storm 倾向于以高 tps 积累消息。之前看过kafka，拉的模式。实时推荐需要实时反映用户的行为，用户下单后还在推荐。后来自己开发的跳线用于读取订单的行为，push方式解决了快速获取订单的行为，其他行为采用了Kafka。

　　不合理的资源分配和隔离。其他任务内存泄漏等问题会影响其他任务。

　　Q8：如何解决HBase的热点问题？是不是先分析key的分布然后写一个split脚本？

　　基本思路是一样的，写工具检测。重点是请求的数量，而不是密钥的分配。

　　Q9：批处理层将离线计算结果推送到服务层的周期是多少？数据量大对在线HBase有影响吗？

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

　　4

　　

　　鲜花

　　

　　握手

　　

　　棒极了

　　

　　路过

　　

　　鸡蛋

　　刚刚发表意见的朋友()