一、lambda架構(gòu)
lambda架構(gòu)由storm的作者nathan marz提出。 旨在設(shè)計(jì)出一個(gè)能滿足實(shí)時(shí)大數(shù)據(jù)系統(tǒng)關(guān)鍵特性的架構(gòu)，具有高容錯(cuò)、低延時(shí)和可擴(kuò)展等特性。
lambda架構(gòu)整合離線計(jì)算和實(shí)時(shí)計(jì)算，融合不可變性（immutability），讀寫分離和復(fù)雜性隔離等一系列架構(gòu)原則，可集成hadoop，kafka，storm，spark，hbase等各類大數(shù)據(jù)組件。
1.1 lambda架構(gòu)理論點(diǎn)
lambda架構(gòu)對(duì)系統(tǒng)做了如下抽象：
query = function(all data)
簡(jiǎn)言之：查詢是應(yīng)用于數(shù)據(jù)集的函數(shù)。 data是自變量，query是因變量。
lambda有兩個(gè)假設(shè)
不可變假設(shè)：lambda架構(gòu)要求data不可變，這個(gè)假設(shè)在大數(shù)據(jù)系統(tǒng)是普遍成立的：因?yàn)槿罩臼遣豢勺兊模硞€(gè)時(shí)刻某個(gè)用戶的行為，一旦記錄下來(lái)就不可變。
monoid假設(shè)： 理想情況下滿足monoid 的function可以轉(zhuǎn)換為:
query = function(all data/ 2) function(all data/ 2)
monoid的概念來(lái)源于范疇學(xué)（category theory），其一個(gè)重要特性是滿足結(jié)合律。如整數(shù)的加法就滿足monoid特性：(a b) c=a (b c)
不滿足monoid特性的函數(shù)很多時(shí)候可以轉(zhuǎn)化成多個(gè)滿足monoid特性的函數(shù)的運(yùn)算。如多個(gè)數(shù)的平均值avg函數(shù)，多個(gè)平均值沒法直接通過結(jié)合來(lái)得到最終的平均值，但是可以拆成分母除以分子，分母和分子都是整數(shù)的加法，從而滿足monoid特性。
1.2 lambda架構(gòu)
三層架構(gòu)：批處理層、實(shí)時(shí)處理層、服務(wù)層，如圖1所示：
圖1
批處理層：批量處理數(shù)據(jù)，生成離線結(jié)果
實(shí)時(shí)處理層：實(shí)時(shí)處理在線數(shù)據(jù)，生成增量結(jié)果
服務(wù)層：結(jié)合離線、在線計(jì)算結(jié)果，推送上層
1.3 lambda架構(gòu)優(yōu)缺點(diǎn)
優(yōu)點(diǎn)：
實(shí)時(shí)：低延遲處理數(shù)據(jù)
可重計(jì)算：由于數(shù)據(jù)不可變，重新計(jì)算一樣可以得到正確的結(jié)果
容錯(cuò)：第二點(diǎn)帶來(lái)的，程序bug、系統(tǒng)問題等，可以重新計(jì)算
復(fù)雜性分離、讀寫分離
缺點(diǎn)：
開發(fā)和運(yùn)維的復(fù)雜性：lambda需要將所有的算法實(shí)現(xiàn)兩次，一次是為批處理系統(tǒng)，另一次是為實(shí)時(shí)系統(tǒng)，還要求查詢得到的是兩個(gè)系統(tǒng)結(jié)果的合并，可參考 http://www.infoq.com/cn/news/2014/09/lambda-architecture-questions
1.4 典型推薦架構(gòu)
實(shí)時(shí)處理范式的需求
推薦系統(tǒng)的最終目的是提高轉(zhuǎn)化率，手段是推送用戶感興趣的、需要的產(chǎn)品。為什么需要實(shí)時(shí)處理范式？
1號(hào)店會(huì)根據(jù)你實(shí)時(shí)瀏覽、加車、收藏、從購(gòu)物車刪除、下單等行為，計(jì)算相關(guān)產(chǎn)品的權(quán)重，把相應(yīng)的產(chǎn)品立刻更新到猜你喜歡欄位。同樣在亞馬遜搜索瀏覽了《基督山伯爵》這本書，亞馬遜首頁(yè)很快增加一行新推薦：包含4個(gè)版本《基督山伯爵》
答案不言而喻：讓推薦引擎更具時(shí)效性。如圖2、圖3所示：
圖2
圖3
netflix推薦架構(gòu)
netflix推薦架構(gòu)如圖4所示
圖4
批處理層：從hive、pig數(shù)據(jù)倉(cāng)庫(kù)，離線計(jì)算推薦模型，生成離線推薦結(jié)果
實(shí)時(shí)處理層：從消息隊(duì)列（hermes、user event queue）實(shí)時(shí)拉取用戶行為數(shù)據(jù)與事件，生成在線推薦結(jié)果
服務(wù)層：結(jié)合離線、在線推薦結(jié)果，為用戶生成推薦列表
二、1號(hào)店推薦系統(tǒng)實(shí)踐
2.1. 推薦引擎組件
目前共有6大推薦引擎：
用戶意圖：實(shí)時(shí)分析用戶行為，存儲(chǔ)短期內(nèi)興趣偏好
用戶畫像：用戶興趣偏好的長(zhǎng)期積累（商品類目、品牌等），自然屬性（年齡、性別），社會(huì)屬性（居住地、公司）
千人千面：群體分析（某一大學(xué)、某一小區(qū)、公司、好友群）
情境推薦：根據(jù)季節(jié)、節(jié)日、天氣等特定情境做推薦
反向推薦：根據(jù)商品購(gòu)買周期等，方向生成推薦結(jié)果
主題推薦：分析用戶與主題的匹配度（如：美食家、極客等），根據(jù)主題對(duì)用戶進(jìn)行推薦
產(chǎn)品架構(gòu)如圖5所示
圖5
今天主要討論其中的主題推薦
2.2 主題推薦
首先主題推薦有三個(gè)步驟
建立關(guān)系（主題與商品，用戶與商品，用戶與主題）
選品，建立主題選品池
推薦，根據(jù)用戶與主題的關(guān)系，從選品池為用戶進(jìn)行推薦 用公式表示就是：topic_recommend = topic_recommend_function(offline data)僅僅完成上面步驟，不需要“實(shí)時(shí)處理范式”就可以完成 后來(lái)主題推薦加入了“增量推薦”功能，通過用戶的實(shí)時(shí)行為，對(duì)推薦結(jié)果進(jìn)行調(diào)整
根據(jù)用戶在線行為（瀏覽、購(gòu)買、評(píng)論）等，調(diào)整離線推送的主題推薦結(jié)果 用公式表示就是topic_recommend= mege ( topic_recommend_function1(offline data), topic_recommend_function2(online data) )
顯然這演變成了一個(gè)lambda架構(gòu)，如圖6所示
圖6
2.3 主題推薦存儲(chǔ)設(shè)計(jì)
存儲(chǔ)最重要的就是 “主題推薦結(jié)果表”，需要滿足如下特性
kv查詢，根據(jù)用戶id查詢推薦結(jié)果；
保留一定時(shí)間內(nèi)歷史推薦數(shù)據(jù)。
根據(jù)上述兩個(gè)特點(diǎn)，我們決定選用hbase。hbase的kv、多版本屬性滿足上述需求。有如下兩個(gè)要點(diǎn)
讀寫分離
我們使用hbase主從方式，來(lái)讀寫分離，采用hbase主從的主要原因是
在cap理論里面hbase犧牲的是可用性保證強(qiáng)一致性，flush、split、compaction都會(huì)影響可用性。檢測(cè)region server掛斷、恢復(fù)region都需要一定時(shí)間，這段時(shí)間內(nèi)region數(shù)據(jù)不可用。
離線任務(wù)大量讀寫，對(duì)region server造成壓力（gc、網(wǎng)絡(luò)、flush、compaction），影響前端響應(yīng)速度。
cache
為了進(jìn)一步提高響應(yīng)速度，我們?cè)诜?wù)層增加了一級(jí)緩存，采用1號(hào)店內(nèi)部分布式緩存ycache(與memcache的封裝)。
產(chǎn)品效果如圖7所示
圖7
2.4 hbase的維護(hù)
熱點(diǎn)均衡：不要指望預(yù)split解決一切問題，熱點(diǎn)的造成不可避免，尤其隨著業(yè)務(wù)數(shù)據(jù)的增長(zhǎng)，一些冷region該合并就合并。
做好為hbase修復(fù)bug的準(zhǔn)備，尤其是升級(jí)新版本。
三、lambda的未來(lái)
與其說(shuō)lambda的未來(lái)，不如說(shuō)“實(shí)時(shí)處理范式”與“批處理范式”的未來(lái)。工程實(shí)踐中l(wèi)ambda之前提到的缺點(diǎn)有不少體會(huì)
邏輯一致性。許多公共數(shù)據(jù)分析邏輯需要實(shí)現(xiàn)兩套，并且需要保證一致性。換個(gè)角度來(lái)看就是公共邏輯提取費(fèi)力。
維護(hù)、調(diào)試兩套平臺(tái)
jay kreps認(rèn)為lambda架構(gòu)是大數(shù)據(jù)方案中的臨時(shí)解決方案，原因是目前工具不成熟。 他提供了一個(gè)替代架構(gòu)，該架構(gòu)基于他在linkedin構(gòu)建kafka和samza的經(jīng)驗(yàn)，他還聲稱該架構(gòu)在具有相同性能特性的同時(shí)還具有更好的開發(fā)和運(yùn)維特性。
圖8
讓我想起了spark streaming既可以做實(shí)時(shí)處理，又很自然做批量。讓我想起了storm的drpc，就是為了做離線處理。有人說(shuō)streaming本質(zhì)是批量方式，實(shí)際上“實(shí)時(shí)”沒有絕對(duì)界限，關(guān)鍵在于延遲。你認(rèn)為10s，我也可以認(rèn)為2s內(nèi)才算實(shí)時(shí)。
對(duì)于lambda架構(gòu)問題，社區(qū)提出了kappa架構(gòu)，一套系統(tǒng)滿足實(shí)時(shí)、批處理需求。 目前看來(lái)，是朝著 “實(shí)時(shí)”框架去主動(dòng)包含“批量處理”的方向發(fā)展
四、個(gè)人的兩點(diǎn)思考
兩種不同的需求，一個(gè)框架搞定，是不是很熟悉？我們都想搞大而全，一勞永逸的事情，但許多往往被證明是錯(cuò)的。
mr是不是過時(shí)了？we need more，期待著數(shù)據(jù)與邏輯更便捷、更深入的交集。
五、q&a
q1：hbase你們遇到最詭異的是啥問題?
因?yàn)閔dfs客戶端沒有設(shè)置讀超時(shí)，導(dǎo)致hbase lock hang住，最后集群宕機(jī)。
q2：玩推薦引擎首先想到的是mahout，王老師是否也有這方面的涉獵?
mahout、mlib 這些東西都是數(shù)據(jù)挖掘框架，主要看算法好壞，選誰(shuí)區(qū)別不大。
q3：日志量多大？kafka集群配置怎樣broker、replica等？碰到什么坑嗎？
1天2t多數(shù)據(jù)，kafka是整個(gè)公司公用。kafka還是比較穩(wěn)定，我們這邊幾乎沒遇到問題，storm問題出了不少。kafka集群replica有些是2、有些3，broker是10。遇到大量數(shù)據(jù)的時(shí)候kafka每隔一陣可能出現(xiàn)close_wait的問題
q4：千人千面引擎最后體現(xiàn)的效果是什么？用在什么地方？
千人千面效果，針對(duì)小區(qū)用戶轉(zhuǎn)化率提升

19阿里去哪里買云服務(wù)器
微信小程序取什么名好
云南租用高防服務(wù)器
云主機(jī)速度如何解決
阿里云服務(wù)器自動(dòng)續(xù)費(fèi)怎么弄
云服務(wù)器和主機(jī)怎么購(gòu)買
尊敬的工程師月日有收到貴公司發(fā)的信息
MEC使能5G新商業(yè)