1.業務場景
2.系統需求
3.系統架構
說到實時分析，前提是實時日誌收集，這方面**已經有了一套的強大的日誌收集和分發系統–timetunnel，俗稱tt，tt的延遲在幾百毫秒以內，並且提供根據游標來取訊息的功能，基本滿足了我們訊息對訊息實時性和完整性的需求。全量計算的輸出是實時分析系統的另乙個重要的資料來源，因為我們寫入到ups提供給搜尋引擎的是使用者屬性的最終結果，合併全量和增量的過程需要在實時分析系統中完成。全量計算是在雲梯上完成的，結果存放在hdfs中，hdfs不能夠提供記錄級別的操作，考慮到我們的系統需求，必須要有另外乙個提供高效的記錄級操作的儲存系統來儲存這些資料。此外，由於演算法邏輯通常會將使用者近兩天的行為都考慮進去，我們還需要儲存使用者近期的行為記錄。我們選擇hbase作為全量結果和近期行為資料的儲存介質，一是由於hbase具有良好的水平擴充套件性，二是由於我們對hbase的使用比較熟悉。在計算系統的選型上，我們選擇了人見人愛的開源系統storm.各個元件的選型確定，整個系統的架構也就出來了。
(1)全量資料的匯入。首先通過distcp方式將雲梯上的資料拷貝到我們的hadoop集群中，然後使用bulk-load方式將資料匯入到hbase表中。bulk-load是hbase提供的一種高效的資料批量匯入工具，具體使用方法可以參考 全量匯入過程每天執行一次，我們會根據日期新建對應的表。
(2)全量資料的切換和刪除。為了讓執行在storm中的實時分析拓撲檢測並使用到新全量表，我們另外建立了一張全量資料索引表，每次匯入到新的全量資料表時更新對應的索引，實時分析拓撲定期掃瞄索引，在檢測到索引更新時自動切換到使用新錶。
(3)訊息完整性的保證。實時分析拓撲中會儲存訊息處理的游標，並定期刷入到hbase中，這樣即使在節點失敗或者拓撲重啟的情況下也能夠恢復游標，處理堆積的訊息。
4.實時分析拓撲
當一條日誌進入pora系統後，首先通過解析器解析出若干字段，然後通過過濾邏輯來判斷該條日誌是否需要進行分析，如果需要，則會根據這些字段執行需要的join操作，例如將使用者、寶貝的資訊補全，然後將join好的日誌以及使用者的近期行為和全量屬性傳遞給系統中的演算法外掛程式，依次進行分析，最後將最新的使用者屬性更新到ups中，提供給外部使用。分析流程對應於storm的拓撲結構大致如下：
(1)parser. 負責解析日誌，根據配置檔案取出需要的字段來。
(2)filter. 過濾邏輯，根據某些規則過濾掉一些不感興趣的使用者日誌。
(3)joiner. 日誌中的字段往往不能夠提供完整的資訊，需要乙個join過程來補全字段。在當前的實現中，我們會根據日誌中的」行為」欄位來使用不同的join方式。
(4)analyzer. 主體分析邏輯。我們將這部分做成了乙個 framework + plugins 的結構，其中framework負責取全量屬性、取近期行為、取當前行為，合併計算結果。每個plugin只需要實現analyze(全量屬性 + 近期行為 + 當前行為)的方法。framework對使用者屬性進行了字段切分，每個plugin只需要關心自己處理的那個字段即可。
在joiner和analyzer階段，我們做了乙個很小的批量處理，不一定每條日誌都會觸發計算，只有當累積夠一定條數後，才做一次集中處理，這樣在latency方面會有一些損失，但是能夠將對hbase的訪問打包，提高hbase的讀寫效能，從而大大提高系統的qps.這個批量的大小是可配的，使用者可以根據場景選擇配置，在qps和latency之間做trade-off,當配置為1的時候，就是完全的單條計算。
(5)updater.負責將analyzer計算後發生更新的使用者屬性傳送到ups中，繼而提供給搜尋引擎使用。
5.系統監控
監控是乙個線上系統必不可少的一部分。我們除了使用了一些基礎的機器狀態監控外，hbase集群還使用了集團hbase團隊開發的專用監控系統，非常直觀。此外，我們還需要一些業務指標的監控，例如我們的qps,latency,gap(日誌處理時間與日誌生產時間質檢單 間隔)，這方面也花費了我們一些心思。例如latency的監控，storm ui本身提供了即時數字的顯示，但是沒有我們想要的曲線圖(或許0.9版本中會有吧)。最後我們選擇了基於hbase的監控繪圖工具opentsdb。我們通過借助storm的ack機制來統計訊息處理的latency,列印到日誌中，然後使用乙個指令碼來蒐集這些資訊傳送給opentsdb伺服器來展示曲線。
pora目前在**個性化搜尋中穩定執行，每天處理幾十億的日誌資訊，平均延遲在秒級。
6.經驗教訓
個性化推薦系統
基於協同過濾的推薦大體包括 基於專案的協同過濾 item basedcf 基於使用者的協同過濾 user basedcf 基於模型的協同過濾演算法 1 3 基於專案的協同過濾 item basedcf 首先根據不同使用者歷史購買商品的評分資訊計算出各專案之間的相似度，構建各專案之間的相似度矩陣 再找...
個性化推薦系統（六） 超大數量業務個性化實戰
線上系統有些業務是每天幾百篇增量資料個性化，或者是運營每天選定幾百 幾千個商品sku 池子個性化，這種是比較好進行儲存管理以及實現的。全站資料進行個性化，每個人相關資料一般 就只有幾個幾十個多個上百個，這個量級資料還可以快取儲存，可以存下來的。經分析歷史資料發現95 以上使用者只看前30頁，也就是3...
推薦系統概述 個性化推薦
1.從乙個例子出發 兩名使用者都在某電商 購買了a b兩種產品。當他們產生購買這個動作的時候，兩名使用者之間的相似度便被計算了出來。其中一名使用者除了購買了產品a和b，還購買了c產品，此時推薦系統會根據兩名使用者之間的相似度會為另一名使用者推薦專案c。2.應用現狀 推薦系統可以說是無處不在了，比如 ...