王富平? 現(xiàn)為1號店搜索與精準化部門架構(gòu)師，之前在百度從事數(shù)據(jù)挖掘相關(guān)工作，對實時處理有著深刻的研究。一直從事大數(shù)據(jù)相關(guān)研發(fā)工作，2013年開發(fā)了一款SQL實時處理框架，致力于建設(shè)高可用的大數(shù)據(jù)業(yè)務(wù)系統(tǒng)。 一、Lambda架構(gòu) Lambda架構(gòu)由Storm的作者Nathan Marz提出。 旨在設(shè)計出一個能滿足實時大數(shù)據(jù)系統(tǒng)關(guān)鍵特性的架構(gòu)，具有高容錯、低延時和可擴展等特性。 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è)置讀超時，導致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、讀寫分離。

轉(zhuǎn)載于:https://www.cnblogs.com/davidwang456/articles/8360497.html

《新程序員》：云原生和全面數(shù)字化實踐50位技術(shù)專家共同創(chuàng)作，文字、視頻、音頻交互閱讀

總結(jié)

以上是生活随笔為你收集整理的Lambda架构与推荐在电商网站实践的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。