熱點聚集
本篇文章4416字，閱讀大概需要6分鐘
微博是一個廣播社交網絡平臺，通過有趣的機制共享短期信息。微博用戶注重訂閱內容。在這種情況下，推薦系統可以很好地與訂閱分發系統集成并相互促進。微博的兩個關鍵基礎：第一，建立用戶關系，第二，內容溝通微博致力于優化這兩點，促進微博的發展。
微博推薦開發過程改變了系統的方向，業務不斷變化，目標重置，產品理念，架構和算法發生變化。本白皮書主要描述了推薦架構在此過程中的演變，并希望通過此機會探索業務與技術之間的關系，同時在產品目標，算法需求和技術開發方面為讀者提供完整的開發環境。
通常，架構是在團隊和業務環境中創建的，努力基于環境因素解決環境問題，結構由強大的功能組成，并且創建面向實現的效果。本白皮書詳細介紹了微博建議的三個階段，包括環境因素，架構配置和特性以及實施影響。
1獨立1.0
1.1環境
影響結構形成的環境因素可分為內部環境因素和外部環境因素。內部因素主要與團隊和成員有關，但外部因素主要在外部部門，整個公司或整個行業。
這個項目有很多項目，當時平均每個團隊有5個并行開發項目。當然，最重要的因素是微博產品是快速生成器，微博需要在很多地方提供支持。同時，由于項目周期很短，調度緊急，很難有時間進行清理和抽象。典型產品包括微棒，微小組，微分布，微結構，用戶和內容對齊。
基于以上原因，當我們面對單個項目時，我們使用熟悉的技術堆棧通過建立我們自己的理解來逐個構建我們的流程。
雖然開發過程中存在許多缺點，但我們已為后續架構優化奠定了基礎。結果如下。
在微博快速發展的過程中，微博滿足了微博對推薦業務支持的要求，完成了20多個獨立項目。
吳的框架誕生了，內部的高效計算框架誕生于此。
Web應用程序層的持續需求摘要，推薦的通用應用程序框架配置2樓2.0
我們介紹了一個獨立的1.0。根據架構開發的方式，我們去了一個分支路口，一個是流行的LAMP架構，另一個是與廣告和搜索相匹配的CELL架構。 LAMP架構數據策略是獨立的，腳本語言是業務開發的主要語言，該項目是快速開發和迭代的首選。 CELL架構強調本地流程處理，數據和業務組合，自行開發的服務以及適用于高性能應用程序的數據庫。畢竟，我們選擇與兩者兼容，并且我們傾向于擁有業務架構。為什么會這樣？我們來看看當時的環境。
2.1環境
微博推薦2.0期間為2013年3月至2014年底。此期間的內部環境因素為：
今天，團隊成員已經合作了很長時間，并就技術選擇達成了一些共識。
團隊產品專注于內容/用戶/垂直課程推薦，場景分為源主頁，正文頁面和PC主頁。這種集中不僅有助于統一建筑，還有助于獲得技能。
外部因素包括：
該公司明確定位建議，提高關系績效和內容溝通效率，并為推薦廣告的技術探索，場景干預和用戶體驗提供基礎。
在推薦的字段中，每個公司都有自己的架構輸出，這是微博建議的重要指南。
2.2架構配置和功能
隨著團隊實施核心業務實施，工具和框架不斷發展，2.0部署的目標正在變為現實。
1.技術目標
與1.0不同，僅僅實現業務需求不再是2.0的技術目標。要獲得完整的推薦流程，您需要：
第一步是實施完整的推薦流程，包括候選人，調整，策略，演示，反饋和評估。
數據是第一個提取數據架構的數據。為了實現數據比較，效果是基于數據的，實現數據通道，反映反饋，實現數據著陸和執行業務需求。
提供一種方便干預算法的方法。
這不僅可以確保快速迭代和業務開發，還可以支持高效計算。
2.建筑
微博推薦2.0架構如圖5所示。它不再是一個獨立的系統，開發人員也無法使用類似的技術來解決類似的問題。該架構圖主要包括以下部分：
應用層：主要負責推薦的策略和演示，其特點是充分利用腳本語言的特性來響應重復的要求。您可以在對齊后顯示大多數推薦的內容，但必須在技術級別完成此IO密集型層，因為您需要合并，刪除和重新定位前端產品策略。在技術選擇框架中，開發最初基于Apache + mod_python并且創建了common_recom_frame。該框架面向能夠成功實施推薦業務流程的二級開發人員。該框架的核心思想是提取項目，任務和數據的三層接口。該項目適用于每個推薦項目，每個推薦項目的推薦任務不同，一種管理的訪問方法。兩個規格同時設置。一種是集成推薦的接口，無論用戶，內容或行業如何，另一種是通過保護不同協議數據庫的訪問方法來顯著提高開發效率。 common_recom_frame框架的誕生基本上解決了產品的各種推薦策略要求，并走在了產品的前面。圖5微博推薦2.0架構的示意圖
計算層：主要消耗CPU，該層為算法提供干預方法，并執行支持算法模型迭代的推薦排序計算。在這個技術選擇層，我們繼承了原始的WOO協議框架，這是一個基于c/c ++開發的內部高效通信框架。當然，我已經做了很多擴展，并且我借用了上面提到的common_recom_frame思想來實現基于WOO框架的項目/工作/數據管理，為二級開發人員提供了更高效的開發工具。在您團隊的開源項目中包含此工具：https://github.com/wbrecom/lab_common_so
數據層：主要負責推薦的數據流和存儲。數據層的任務主要是解決數據的IN/OUT/STORE問題。 IN數據輸入到系統，OUT是數據訪問方法，STORE是數據存儲方法。在進行數據層規劃時，分析了微博推薦的數據特征，該屬性可以分為靜態和動態兩大類。靜態數據的定義如下：更新需要大量低頻率和低并發性的數據，動態數據定義為：增量數據同時以高頻率動態更新。因此，在靜態和動態數據，RIN/R9接口，徑向/流明，tmproxy /呼吸機或工具框架生成期間，唯一的IN/OUT/SOTRE的通用方向。下面說說擴展，RIN數據訪問動態數據，支持通過Web服務接收數據，后端隊列管理，消費者集群得到多服務框架ckestrel的補充，用戶需要執行自己的業務開發您可以在線快速使用動態數據。 R9接口處理器訪問靜態數據推薦行為針對R9接口框架的Hadoop集群靜態計算[MR Hive SQL和SPARK行為]通知管理和數據加載，解決了多個靜態數據。動態數據使用許多redis群集，靜態數據使用lushan群集來存儲推薦數據。對于lushan，這個工具也包含在團隊開源項目中：https://github.com/wbrecom/lushan。 tmproxy/ventilation為了解決OUT數據的問題，再加上通風訪問中間件代理來處理靜態和動態數據的推薦請求，后端數據減少了業務變化的影響。基本服務：推薦系統的基本服務主要包括監控，報警和評估系統，數據監控系統分為性能和影響監控兩類，評估系統主要用于下級評估。在去之前有一定的期望和影響。
3.特點
優點是：
數據的集成方法，以提供完整的推薦流程支持
在快速實現業務功能的過程中，效果技術不斷深化。
該算法得到了很好的支持。
首次使用您的數據的想法將幫助您全面比較您的影響并繼續提高您的推薦效果。
密封系統易于放置，質量保證包含在測試中。
缺陷如下。
與推薦的核心有一定距離，并且與建議不完全一致。
推薦的策略算法完全傳遞給開發人員，不適合一般使用。
算法培訓不包括在內，只是在線交付系統，因此構建完整的推薦系統是不夠的。
2.3結果
微博推薦2.0的誕生產生了良好的效果。
微博的核心業務是通過諸如機構推薦，趨勢用戶推薦，趨勢內容推薦，各種場景中的用戶推薦，粉絲經濟學，賬戶推薦等系統完成的。
為lab_common_so創建一個基本框架并執行開源
一個靜態存儲集群解決方案，lushan，誕生了。
聯陣框架的誕生極大地提高了企業生產的效率，也為開放社區做出了貢獻。
3平臺類型3.0
在前一節的2.0描述中提到的一個主要缺點是“與推薦的核心存在一定距離，并且與推薦不完全一致”。我們希望在建議3.0中修復它。為什么在滿足業務需求時推薦的架構會繼續發展？我們將向您展示微博推薦的平臺風格3.0設計。讓我們來看看環境。
3.1環境
從2014年底到現在的當前內部環境因素如下，微博建議3.0。
推薦產品沒有擴展，它們更重要，并且重點從業務開發和迭代轉向針對性能的技術迭代。
如果您以迭代方式提出新項目或業務，則會有許多重復性任務，重復任務，因為架構未得到解決。
外部因素包括：
該公司還從業務擴展轉向效率優先，以改善用戶體驗和內容質量。
微博建議在推薦的技術鏈接的距離區域中存在一定距離，并且存在追趕狀況。
3.2架構配置和功能
當前環境也可以反映3.0的技術目標。
1.技術目標
與2.0不同，全范圍推薦過程不是3.0的目標。目標是：摘要在推薦過程中候選/對齊/訓練/反饋的一般方法。
推薦算法，需要建立推薦系統算法的角度數據問題，接近算法策略
2.建筑
如圖7所示，建議基于此開發2.0找到微博3.0體系結構，因為運行當前體系結構系統，我們維護了一個實際在框架2.0中使用的大型分層系統和工具。以下是一些要點：
兩個標準：應用層的一個總體輸出框架，所有這些都是在一個應用層中包含標準輸入和輸出參數的接口規范，與動態輸入精益相關并且離線計算，這可以確定我們的結構因此，輸入層工具R9接口規范是相互依賴的***不需要為分割級別的標準設置設置線串，例如數據/記錄。
通過標準生成候選者的方法增加計算層：Artemis候選內容模塊，項目候選用戶模塊，......應該只選擇此方法來生成項目開發的候選者。
添加了一個名為EROS的戰略平臺來解決算法模型的問題。 EROS的主要特點是1）訓練模型2）特征選擇3）在線比較測試。
R9界面層和生成在線和離線候選精益增長的數據推薦了產生結果的一般策略。
圖7微博推薦3.0的示意圖
3.特點
它主要解釋了它的優點：
它繼承了原有的2.0特性并保持其優點。深入理解這些建議，并結合推薦的候選/對齊/訓練算法的最重要解決方案
3.3結果
微博推薦3.0的誕生，結果如下：
微博推薦的核心業務逐步遷移到系統，算法數據作為提高效率的驅動因素。
技術來自業務并改善業務發展。業務發展是技術發展和相互影響的關系背后的驅動力。隨著業務發展的技術還活著。
技術架構選擇建議是目前找到最短路徑然后迭代優化。將所有東西放在一起是不現實和不合理的。
推廣框架和工具的最佳方式不是行政命令或待遇，但每個人都是參與者。與開源項目一樣，每個人都是所有者，因此每個人都得到維護和使用。
