一、Lambda架構(gòu)

Lambda架構(gòu)由Storm的作者Nathan Marz提出。 旨在設(shè)計出一個能滿足實時大數(shù)據(jù)系統(tǒng)關(guān)鍵特性的架構(gòu)，具有高容錯、低延時和可擴展等特性。

創(chuàng)新互聯(lián)建站服務(wù)項目包括豐都網(wǎng)站建設(shè)、豐都網(wǎng)站制作、豐都網(wǎng)頁制作以及豐都網(wǎng)絡(luò)營銷策劃等。多年來，我們專注于互聯(lián)網(wǎng)行業(yè)，利用自身積累的技術(shù)優(yōu)勢、行業(yè)經(jīng)驗、深度合作伙伴關(guān)系等，向廣大中小型企業(yè)、政府機構(gòu)等提供互聯(lián)網(wǎng)行業(yè)的解決方案，豐都網(wǎng)站推廣取得了明顯的社會效益與經(jīng)濟效益。目前，我們服務(wù)的客戶以成都為中心已經(jīng)輻射到豐都省份的部分城市，未來相信會繼續(xù)擴大服務(wù)區(qū)域并繼續(xù)獲得客戶的支持與信任！

Lambda架構(gòu)整合離線計算和實時計算，融合不可變性（Immutability），讀寫分離和復(fù)雜性隔離等一系列架構(gòu)原則，可集成Hadoop，Kafka，Storm，Spark，HBase等各類大數(shù)據(jù)組件。

1.1 Lambda架構(gòu)理論點

Lambda架構(gòu)對系統(tǒng)做了如下抽象：

Query = Function(All Data)

簡言之：查詢是應(yīng)用于數(shù)據(jù)集的函數(shù)。 data是自變量，query是因變量。

Lambda有兩個假設(shè)

不可變假設(shè)：Lambda架構(gòu)要求data不可變，這個假設(shè)在大數(shù)據(jù)系統(tǒng)是普遍成立的：因為日志是不可變的，某個時刻某個用戶的行為，一旦記錄下來就不可變。

Monoid假設(shè)： 理想情況下滿足Monoid 的function可以轉(zhuǎn)換為:

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

Monoid的概念來源于范疇學（Category Theory），其一個重要特性是滿足結(jié)合律。如整數(shù)的加法就滿足Monoid特性：(a+b)+c=a+(b+c)

不滿足Monoid特性的函數(shù)很多時候可以轉(zhuǎn)化成多個滿足Monoid特性的函數(shù)的運算。如多個數(shù)的平均值avg函數(shù)，多個平均值沒法直接通過結(jié)合來得到最終的平均值，但是可以拆成分母除以分子，分母和分子都是整數(shù)的加法，從而滿足Monoid特性。

1.2 Lambda架構(gòu)

三層架構(gòu)：批處理層、實時處理層、服務(wù)層，如圖1所示：

圖1

批處理層：批量處理數(shù)據(jù)，生成離線結(jié)果

實時處理層：實時處理在線數(shù)據(jù)，生成增量結(jié)果

服務(wù)層：結(jié)合離線、在線計算結(jié)果，推送上層

1.3 Lambda架構(gòu)優(yōu)缺點

優(yōu)點：

實時：低延遲處理數(shù)據(jù)

可重計算：由于數(shù)據(jù)不可變，重新計算一樣可以得到正確的結(jié)果

容錯：第二點帶來的，程序bug、系統(tǒng)問題等，可以重新計算

復(fù)雜性分離、讀寫分離

缺點：

開發(fā)和運維的復(fù)雜性：Lambda需要將所有的算法實現(xiàn)兩次，一次是為批處理系統(tǒng)，另一次是為實時系統(tǒng)，還要求查詢得到的是兩個系統(tǒng)結(jié)果的合并，可參考 http://www.infoq.com/cn/news/2014/09/lambda-architecture-questions

1.4 典型推薦架構(gòu)

實時處理范式的需求

推薦系統(tǒng)的最終目的是提高轉(zhuǎn)化率，手段是推送用戶感興趣的、需要的產(chǎn)品。為什么需要實時處理范式？

1號店會根據(jù)你實時瀏覽、加車、收藏、從購物車刪除、下單等行為，計算相關(guān)產(chǎn)品的權(quán)重，把相應(yīng)的產(chǎn)品立刻更新到猜你喜歡欄位。同樣在亞馬遜搜索瀏覽了《基督山伯爵》這本書，亞馬遜首頁很快增加一行新推薦：包含4個版本《基督山伯爵》

答案不言而喻：讓推薦引擎更具時效性。如圖2、圖3所示：

圖2

圖3

Netflix推薦架構(gòu)

Netflix推薦架構(gòu)如圖4所示

圖4

批處理層：從Hive、pig數(shù)據(jù)倉庫，離線計算推薦模型，生成離線推薦結(jié)果

實時處理層：從消息隊列（Hermes、User Event Queue）實時拉取用戶行為數(shù)據(jù)與事件，生成在線推薦結(jié)果

服務(wù)層：結(jié)合離線、在線推薦結(jié)果，為用戶生成推薦列表

二、1號店推薦系統(tǒng)實踐

2.1. 推薦引擎組件

目前共有6大推薦引擎：

用戶意圖：實時分析用戶行為，存儲短期內(nèi)興趣偏好

用戶畫像：用戶興趣偏好的長期積累（商品類目、品牌等），自然屬性（年齡、性別），社會屬性（居住地、公司）

千人千面：群體分析（某一大學、某一小區(qū)、公司、好友群）

情境推薦：根據(jù)季節(jié)、節(jié)日、天氣等特定情境做推薦

反向推薦：根據(jù)商品購買周期等，方向生成推薦結(jié)果

主題推薦：分析用戶與主題的匹配度（如：美食家、極客等），根據(jù)主題對用戶進行推薦

產(chǎn)品架構(gòu)如圖5所示

圖5

今天主要討論其中的主題推薦

2.2 主題推薦

首先主題推薦有三個步驟

建立關(guān)系（主題與商品，用戶與商品，用戶與主題）

選品，建立主題選品池

推薦，根據(jù)用戶與主題的關(guān)系，從選品池為用戶進行推薦 用公式表示就是：Topic_recommend = topic_recommend_function(offline data)僅僅完成上面步驟，不需要“實時處理范式”就可以完成 后來主題推薦加入了“增量推薦”功能，通過用戶的實時行為，對推薦結(jié)果進行調(diào)整

根據(jù)用戶在線行為（瀏覽、購買、評論）等，調(diào)整離線推送的主題推薦結(jié)果 用公式表示就是Topic_recommend= mege ( topic_recommend_function1(offline data), topic_recommend_function2(online data) )

顯然這演變成了一個Lambda架構(gòu)，如圖6所示

圖6

2.3 主題推薦存儲設(shè)計

存儲最重要的就是 “主題推薦結(jié)果表”，需要滿足如下特性

KV查詢，根據(jù)用戶id查詢推薦結(jié)果；

保留一定時間內(nèi)歷史推薦數(shù)據(jù)。

根據(jù)上述兩個特點，我們決定選用HBase。HBase的kv、多版本屬性滿足上述需求。有如下兩個要點

讀寫分離

我們使用HBase主從方式，來讀寫分離，采用HBase主從的主要原因是

在CAP理論里面HBase犧牲的是可用性保證強一致性，flush、split、compaction都會影響可用性。檢測region server掛斷、恢復(fù)region都需要一定時間，這段時間內(nèi)region數(shù)據(jù)不可用。

離線任務(wù)大量讀寫，對region server造成壓力（gc、網(wǎng)絡(luò)、flush、compaction），影響前端響應(yīng)速度。

Cache

為了進一步提高響應(yīng)速度，我們在服務(wù)層增加了一級緩存，采用1號店內(nèi)部分布式緩存ycache(與memcache的封裝)。

產(chǎn)品效果如圖7所示

圖7

2.4 HBase的維護

熱點均衡：不要指望預(yù)split解決一切問題，熱點的造成不可避免，尤其隨著業(yè)務(wù)數(shù)據(jù)的增長，一些冷region該合并就合并。

做好為HBase修復(fù)bug的準備，尤其是升級新版本。

三、Lambda的未來

與其說Lambda的未來，不如說“實時處理范式”與“批處理范式”的未來。工程實踐中Lambda之前提到的缺點有不少體會

邏輯一致性。許多公共數(shù)據(jù)分析邏輯需要實現(xiàn)兩套，并且需要保證一致性。換個角度來看就是公共邏輯提取費力。

維護、調(diào)試兩套平臺

Jay Kreps認為Lambda架構(gòu)是大數(shù)據(jù)方案中的臨時解決方案，原因是目前工具不成熟。 他提供了一個替代架構(gòu)，該架構(gòu)基于他在Linkedin構(gòu)建Kafka和Samza的經(jīng)驗，他還聲稱該架構(gòu)在具有相同性能特性的同時還具有更好的開發(fā)和運維特性。

圖8

讓我想起了Spark streaming既可以做實時處理，又很自然做批量。讓我想起了Storm的DRPC，就是為了做離線處理。有人說streaming本質(zhì)是批量方式，實際上“實時”沒有絕對界限，關(guān)鍵在于延遲。你認為10s，我也可以認為2s內(nèi)才算實時。

對于Lambda架構(gòu)問題，社區(qū)提出了Kappa架構(gòu)，一套系統(tǒng)滿足實時、批處理需求。 目前看來，是朝著 “實時”框架去主動包含“批量處理”的方向發(fā)展

四、個人的兩點思考

兩種不同的需求，一個框架搞定，是不是很熟悉？我們都想搞大而全，一勞永逸的事情，但許多往往被證明是錯的。

MR是不是過時了？we need more，期待著數(shù)據(jù)與邏輯更便捷、更深入的交集。

五、Q&A

Q1：HBase你們遇到最詭異的是啥問題?

因為hdfs客戶端沒有設(shè)置讀超時，導(dǎo)致HBase lock hang住，最后集群宕機。

Q2：玩推薦引擎首先想到的是mahout，王老師是否也有這方面的涉獵?

mahout、mlib 這些東西都是數(shù)據(jù)挖掘框架，主要看算法好壞，選誰區(qū)別不大。

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

1天2T多數(shù)據(jù)，Kafka是整個公司公用。Kafka還是比較穩(wěn)定，我們這邊幾乎沒遇到問題，Storm問題出了不少。Kafka集群replica有些是2、有些3，broker是10。遇到大量數(shù)據(jù)的時候Kafka每隔一陣可能出現(xiàn)CLOSE_WAIT的問題

Q4：千人千面引擎最后體現(xiàn)的效果是什么？用在什么地方？

千人千面效果，針對小區(qū)用戶轉(zhuǎn)化率提升100%

Q5：請問下推薦排序時使用了什么算法，以及大概多少人負責算法模塊？

在app首頁正在嘗試邏輯回歸和learn to rank，7~8人做算法

Q6：1號店對新登陸用戶做什么推薦處理? 主題推薦人工介入量有多大？1號店對其推薦算法出過轉(zhuǎn)化率外，從算法角度會關(guān)心哪些指標?

新用戶冷啟動，采用兩個策略

數(shù)據(jù)平滑

熱銷優(yōu)質(zhì)商品補充

推薦最重要的是看排序效果，主要是推薦位置的轉(zhuǎn)換率。

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

Storm在高tps時候容易消息堆積。之前讀Kafka，拉的模式。實時推薦需要實時的反應(yīng)用戶的行為，用戶明明下單了還在推薦。后來讀取訂單的行為用了自主研發(fā)的jumper，推的方式解決了快速得到訂單行為，其他行為用Kafka。

資源分配、隔離不合理。其他任務(wù)出現(xiàn)內(nèi)存泄露等問題會影響其他任務(wù)task。

Q8：HBase熱點問題怎么解決的呢？是分析key的分布，然后寫腳本split么？

基本思路一樣，寫工具檢測。重點在request量，不在key的分布。

Q9：批處理層向服務(wù)層推送離線計算結(jié)果的周期是怎樣的？會因數(shù)據(jù)量大而對線上的HBase造成沖擊嗎？

目前是一天一次，沖擊不大。 1、錯峰； 2、bulkload；3、讀寫分離。

本文策劃陳剛、編輯Carson，轉(zhuǎn)載請注明來自"高可用架構(gòu)(ArchNotes)"微信公眾號。高可用架構(gòu)聚焦互聯(lián)網(wǎng)架構(gòu)分享，咨詢投稿或報名分享請回復(fù)“speaker”。

分享題目：Lambda架構(gòu)與推薦在電商網(wǎng)站實踐
URL標題：http://chinadenli.net/article30/cjesso.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供網(wǎng)站營銷、品牌網(wǎng)站設(shè)計、域名注冊、定制開發(fā)、自適應(yīng)網(wǎng)站、營銷型網(wǎng)站建設(shè)

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時需注明來源： 創(chuàng)新互聯(lián)