Lambda架構與推薦在電商網站實踐

高可用架構分享及傳播在架構領域具有典型意義的文章，本文根據王富平分享記錄。轉載請注明高可用架構公眾號ArchNotes。

王富平 

現為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、讀寫分離。