23 內(nèi)容架構(gòu)
日志收集、內(nèi)容發(fā)布、機(jī)器學(xué)習(xí)、信息流服務(wù)、監(jiān)控。
日志收集，是所有排序訓(xùn)練的數(shù)據(jù)來(lái)源，要收集的最核心數(shù)據(jù)就是用用戶在信息流上產(chǎn)生的行為，用于機(jī)器學(xué)習(xí)更新排序模型；
內(nèi)容發(fā)布，就是用推或者拉的模式把信息流的內(nèi)容從源頭發(fā)布到受眾端；
機(jī)器學(xué)習(xí)，從收集的用戶行為日志中訓(xùn)練模型，然后為每一個(gè)用戶即將收到的信息流內(nèi)容提供打分服務(wù)；
信息流服務(wù)，為信息流的展示前端提供 Rest API；
監(jiān)控，這是系統(tǒng)的運(yùn)維標(biāo)配，保證系統(tǒng)的安全和穩(wěn)定等。
24 系統(tǒng)架構(gòu)
1.離線：不用實(shí)時(shí)數(shù)據(jù)，不提供實(shí)時(shí)服務(wù)；
2.近線：使用實(shí)時(shí)數(shù)據(jù)，不保證實(shí)時(shí)服務(wù)；
3.在線：使用實(shí)時(shí)數(shù)據(jù)，要保證實(shí)時(shí)服務(wù)。
24.1 在線層
?在線層常常展現(xiàn)出的形式就是 Rest API 形式，后端則通常是 RPC 服務(wù)內(nèi)部互相調(diào)用，以用戶 ID、場(chǎng)景信息去請(qǐng)求，通常就在 ms 響應(yīng)時(shí)間內(nèi)返回Json 形式的推薦結(jié)果。那么哪些計(jì)算邏輯適合放在在線層呢.？
1.簡(jiǎn)單的算法邏輯；2.模型的預(yù)測(cè)階段；3.商業(yè)目標(biāo)相關(guān)的過(guò)濾或者調(diào)權(quán)邏輯；4.場(chǎng)景有關(guān)的一些邏輯；5.互動(dòng)性強(qiáng)的一些算法。
比如說(shuō)當(dāng)用戶訪問(wèn)一個(gè)物品詳情頁(yè)，需要做相關(guān)推薦，那么在線階段給在線服務(wù)的 Rest API 傳入用戶身份及當(dāng)前的物品 ID，實(shí)時(shí)地取出物品 ID 對(duì)應(yīng)的相關(guān)物品ID 做一些重排和過(guò)濾，就可以輸出了，整個(gè)過(guò)程都是在 ms 級(jí)別完成。這個(gè)實(shí)時(shí)響應(yīng)的過(guò)程中，如果發(fā)生意外，比如說(shuō)這個(gè)物品 ID 就沒(méi)有相關(guān)的物品，那么這時(shí)候服務(wù)就需要降級(jí)，所謂的降級(jí)就是不能達(dá)到最好的效果了，但是不能低于最低要求，這里的最低要求就是必須要返回東西，不能開(kāi)天窗。就降級(jí)為取出熱門排行榜返回。雖然不是個(gè)性化的相關(guān)結(jié)果，但是總比開(kāi)天窗要好。同時(shí)，還需要不斷的使用產(chǎn)品過(guò)程中產(chǎn)生的用戶行為，實(shí)時(shí)報(bào)送有關(guān)模塊，例如不能重復(fù)推薦。
24.2 離線層
批量、周期性地執(zhí)行一些計(jì)算任務(wù)。其特點(diǎn)是“不用實(shí)時(shí)數(shù)據(jù)，不提供實(shí)時(shí)服務(wù)”。
通過(guò) Pig 或者 Hive 等工具，從全量日志中按照算法要求抽取出不同的數(shù)據(jù)，再加上其他數(shù)據(jù)變成了不同算法所需的數(shù)據(jù)源。
離線階段的任務(wù)主要是兩類：模型訓(xùn)練和推薦結(jié)果計(jì)算。通常機(jī)器學(xué)習(xí)類模型，尤其是監(jiān)督學(xué)習(xí)和非監(jiān)督學(xué)習(xí)，都需要大量的數(shù)據(jù)和多次迭代，這類型的模型訓(xùn)練任務(wù)最適合放在離線階段。
大多數(shù)推薦算法，實(shí)際上都是在離線階段產(chǎn)生推薦結(jié)果的。離線階段的推薦計(jì)算和模型訓(xùn)練，如果要用分布式框架，通?？梢赃x擇 Spark 等。
24.3 近線層
近線層的特點(diǎn)是“使用實(shí)時(shí)數(shù)據(jù)，不保證實(shí)時(shí)服務(wù)”。雖然這看上去蠻不講理，但實(shí)際上這是一個(gè)非常重要的一層，它結(jié)合了離線層和在線層的好處，摒棄了兩者的不足。近線層，也叫做準(zhǔn)實(shí)時(shí)層，所謂“準(zhǔn)實(shí)時(shí)”，就是接近實(shí)時(shí)，但不是真的實(shí)時(shí)。
這一層的數(shù)據(jù)來(lái)源是實(shí)時(shí)的行為事件隊(duì)列，但是計(jì)算的結(jié)果并不是沿著輸入數(shù)據(jù)的方向原路返回，而是進(jìn)入了在線數(shù)據(jù)庫(kù)中，得到用戶真正發(fā)起請(qǐng)求時(shí)，再提供服務(wù)。一個(gè)典型的近線計(jì)算任務(wù)是這樣的：從事件隊(duì)列中獲取最新的一個(gè)或少許幾個(gè)用戶反饋行為，首先將這些用戶已經(jīng)反饋過(guò)的物品從離線推薦結(jié)果中剔除，進(jìn)一步，用這幾個(gè)反饋行為作為樣本，以小批量梯度下降的優(yōu)化方法去更新融合模型的參數(shù)。這兩個(gè)計(jì)算任務(wù)都不會(huì)也不需要立即對(duì)用戶做出響應(yīng)，也不必須在下一次用戶請(qǐng)求時(shí)就產(chǎn)生效果，就是說(shuō)當(dāng)用戶實(shí)時(shí)請(qǐng)求時(shí)，不需要去等待近線任務(wù)的最新結(jié)果，因?yàn)閮烧呤钱惒降摹＝€計(jì)算任務(wù)一個(gè)核心的組件就是流計(jì)算，因?yàn)樗幚淼膶?shí)時(shí)數(shù)據(jù)流。常用的流計(jì)算框架有 Storm，SparkStreaming，F(xiàn)Link 等，Netflix 采用的內(nèi)部流計(jì)算框架 Manhattan，這和 Storm 類似。略有區(qū)別的是 Spark Streaming，實(shí)際上并不是實(shí)時(shí)流計(jì)算，而是小批量計(jì)算。
24.4 簡(jiǎn)化
完全舍棄掉近線層；避免使用分布式系統(tǒng)。
在一個(gè)新產(chǎn)品的場(chǎng)景下， 當(dāng)數(shù)據(jù)量還沒(méi)有那么大時(shí)，使用分布式存儲(chǔ)或者計(jì)算框架，非常不劃算。
總結(jié)
25 數(shù)據(jù)采集
推薦算法形形色色，但是他們所需要的數(shù)據(jù)可以概括為兩個(gè)字：矩陣。
基于這個(gè)分析，可以給要收集的數(shù)據(jù)歸納成下面幾種。例如物品id，注意區(qū)分物品與物品之間的不同。
有幾種方式可以獲取數(shù)據(jù)
1.用SDK：友盟，google analytics，得到一些統(tǒng)計(jì)數(shù)據(jù)，但意義不大，可以自己仿照采集一些數(shù)據(jù)。
2.可視化：用開(kāi)源的解決方案 mixpanel，指定收集
3.按自己自己方法
數(shù)據(jù)之外考慮的內(nèi)容：
1.事件的設(shè)備信息，地理位置
2.從什么事件而來(lái)（上下文）
3.什么頁(yè)面而來(lái)
4.事件發(fā)生的用戶相關(guān)屬性，物品相關(guān)屬性。
總結(jié)，基本的推薦系統(tǒng)需要數(shù)據(jù)，如下，不會(huì)出錯(cuò)。
