# 棱柱架構-使用社交網絡上的機器學習來弄清您應該在網絡上閱讀的內容 > 原文： [http://highscalability.com/blog/2012/7/30/prismatic-architecture-using-machine-learning-on-social-netw.html](http://highscalability.com/blog/2012/7/30/prismatic-architecture-using-machine-learning-on-social-netw.html)  *關于 [Prismatic](http://getprismatic.com/) 的體系結構的帖子改編自與 Prismatic 程序員 [Jason Wolfe](http://w01fe.com/berkeley/)* 的電子郵件對話。 您今天應該在網上閱讀什么？ 任何一個完全現代的人都必須每天解決這個難題，通常使用一些神秘的方法來判斷他們的許多供稿中的重要內容：Twitter，RSS，Facebook，Pinterest，G +，電子郵件，Techmeme，以及無數其他信息來源。 Prismatic 的 Jason Wolfe 慷慨地同意使用機器學習，社交圖譜，BigData，函數式編程和內存實數等性感詞來描述其徹底的現代解決方案，以回答“讀什么” 及時飼料加工。 結果可能更加隱秘，但是這或類似的事情將是我們如何面對尋找隱藏在無限深的信息池中的有趣主題和故事的挑戰。 關于 Prismatic，有兩點很突出。 他們想讓您知道 Prismatic 是由一個由四名計算機科學家組成的小組組成的，其中三名來自斯坦福大學和伯克利分校的非常強大的年輕 PHD。 半危險的方法不會起作用。 他們正在為解決信息過載問題帶來大腦力量。 但是這些 PHD 還是程序員，他們從事網站，iOS 編程以及性感的 BigData / ML 后端編程等所有工作。 使 Prismatic 作為一種體系結構令我興奮的一件事是，將來需要一遍又一遍解決的問題是將機器學習實時應用于大量的社會中介信息流 。 保密性使他們無法對自己的機器學習技術說太多話，但是我們的確在幕后高峰。 正如您所期望的，他們在做事上有些不同。 他們選擇了 Clojure（一種可編譯為 Java 字節碼的現代 Lisp）作為他們的編程語言。 這個想法是使用函數式編程來構建細粒度，靈活的抽象，這些抽象被組成來表達特定于問題的邏輯。 一個功能強大的例子是它們的圖形庫，他們在各處使用它們。 例如，可以描述計算圖以為每個用戶創建等效于低延遲，流水線化的 map-reduce 作業集。 另一個示例是使用子圖以模塊化方式緊湊地描述服務配置。 鑒于對功能闡述的關注，他們避免使用諸如 Hadoop 之類的大型框架，而是選擇了一個更小，更可靠，更易于調試，更易于擴展且更易于理解的代碼庫。 對 Prismatic 方法的批評是要取得成果需要很長時間的培訓。 首先，他們說開始獲取優質的內容根本不需要花費很長時間。 其次，我要補充一點，開始使用 Long Sight 考慮這些類型的系統。 基于 ML 的推薦器將從兒童期開始接受培訓，并將與您一生保持在一起。 您頭腦中的可擴展數字模擬物將同時充當信息守衛和邊鋒。 在 [Tech Crunch 文章](http://techcrunch.com/2012/06/07/in-the-studio-prismatics-bradford-cross-wants-to-reinvent-social-news/)中，Prismatic 創始人 Bradford Cross pithily 將 Prismatic 描述為“圍繞復雜的系統構建，該系統可提供大規模，實時，動態的個性化信息重新排名， 很好地將主題分類和歸類為本體。” 現在，讓我們看看該系統是什么樣的... ## 統計資料 * 每天都會從 Twitter，Facebook，Google Reader 和網絡上獲取并分析成千上萬種社交信號，并分析成千上萬的新新聞文章，博客文章和其他共享內容。 * 在用戶注冊 Prismatic 的幾秒鐘內，就提取并分析了他們足夠的歷史活動，以提供非常可靠的主題和發布者建議。 消化了他們的社交網絡以尋找似乎分享最相關內容的朋友。 用戶在 Prismatic 上進行的每個交互也是一個學習的機會。 * 在訪問家庭供稿后的十分之幾秒內，通過將用戶興趣模型與所有這些內容進行匹配，生成了最有趣的故事的供稿。 * 每周為用戶提供數百萬的文章展示次數 ## 平臺 * 托管在 EC2 / Linux 上。 * 99.9％的后端管道和 API 服務器是用 Clojure 編寫的，Clojure 是一種現代 Lisp，可以編譯為 Java 字節碼。 * 所有繁重的工作都發生在 JVM 內部。 * MongoDB * 的 MySQL * S3 * 發電機 * 專注于構建自定義代碼以有效解決特定問題。 ## 數據存儲和 IO * 系統不是圍繞每個服務在數據庫或分布式文件系統之間讀取和寫入實時數據的典型體系結構，而是圍繞數據設計系統。 * 大多數數據通過后端管道從一項服務流向另一項服務，而沒有任何磁盤往返。 * 在管道的最后，API 機器嚴重依賴于自定義的內存數據結構，這些數據結構會定期快照到磁盤。 * 通過使數據盡可能靠近 CPU，大多數 API 請求幾乎沒有 IO 即可得到服務。 這樣可以以非常低的延遲提供提要，從而使 API 機器保持 CPU 綁定，并可以輕松擴展以更輕松地處理更多用戶。 * 使用了許多現成的存儲解決方案：MongoDB，MySQL 和 Amazon 的 S3 和 Dynamo。 每一個都經過仔細選擇，以匹配要存儲的數據的大小，訪問模式和其他特征。 ## 服務 * 從較高的層次上看，該體系結構分為大約 10 種不同的服務類型，大致分為 5 種不同的類別：數據攝取-后端； 入職； API-面向客戶； 其他服務-面向客戶； 批處理和其他服務。 * 每個服務被設計為執行一種操作，可以以特定方式進行水平擴展，并且通常受到一種或兩種特定資源類型（IO，CPU，RAM）的限制。 * 經濟因素偏向于大型機器，因此服務是單身人士，但沒有重大瓶頸會阻止水平擴展的預期。 ## 數據提取-后端 * 每天都會創建大量有趣的內容（新聞文章，博客文章，其他網頁等），并且 Prismatic 希望盡可能多地了解它。 * 對于每個內容，必須知道誰在共享它，以及他們在說什么，以便可以在文章旁邊顯示相關評論，從而可以向用戶顯示由其朋友或具有相似品味的人共享的內容。 * 此過程的第一步是攝取和分析內容和社交數據。 采集管道的頂部是輪詢器： * RSS 輪詢器在供稿中循環查找新文章 * Twitter 和 Facebook 輪詢器連接到相應的 API，并從用戶及其朋友那里獲取評論/推文。 * 這些服務非常簡單，并且大多數都是無狀態的。 * 唯一的真實狀態和有趣的部分是弄清楚已經看到的內容，并智能地確定接下來要輪詢的內容的優先級。 * 實際上，最困難的問題之一是在每次社交互動流入管道的其余部分之前，先確定其內容是什么。 這很困難，因為人們可能會共享同一篇文章的許多版本（縮短的鏈接，移動版本和常規版本等）。 * 從這里，RSS 條目和評論/共享/推文（具有正確規范的 URL）流入障礙，在障礙中確定實際獲取和分析的內容。 * 垃圾郵件和其他垃圾將在稍后的版本中消除，但是最好的偉哥垃圾郵件文章是不會浪費更多的周期的文章。 * 進行剪切的 URL 傳遞到獲取/分析管道 * 此階段的 URL 進入獲取/分析管道。 這是許多魔術開始發生的地方。 * 保留一個 URL 隊列，每個 URL 都通過一個“圖”運行，該“圖”依次詳細說明 URL，獲取其 HTML，應用機器學習算法提取文章文本，識別最佳圖像，提取發布者，并標記適用的標簽 主題等等。 * 為了使這些算法能夠快速運行，適合內存并且性能良好，已經進行了大量的工程設計。 處理所有 URL 本身的問題當然令人尷尬地是并行的。 * 提取階段的末尾是 doc master，其工作是接收有關它們的精心撰寫的文章和社交環境（隨著時間的推移不斷滴入），進行匹配，將文章（以在線方式）聚集到故事中 集群，確定當前有效的文檔集，并管理 API 機器的索引。 ## 入門-后端 * 入職是吸收有關新用戶的數據，因此可以在注冊該應用后的幾秒鐘內為他們提供出色的個性化體驗。 這有兩個主要組成部分： * 根據用戶在 Twitter，Facebook 或 Google 閱讀器上的活動，為用戶找出建議的主題和發布者， * 分析用戶的社交圖譜，以推斷出哪些朋友的分享是他們喜歡文章的最有力信號。 * 這些服務令人尷尬地是并行的，這次是跨用戶的。 除了有效的社交圖分析的復雜性（Prismatic 不想說太多）之外，關鍵是如何將這些服務調整為具有非常低的延遲和合理的吞吐量： * 例如，對于活躍于 Twitter，Facebook 或 Google Reader 的用戶，可以在 15 秒或更短的時間內計算出一百多個準確的主題和發布者建議。 這足夠快，可以在用戶 OAuth 登錄后開始計算建議，并且通常在用戶完成創建帳戶（選擇句柄和密碼）并進入演練時就可以使用個性化建議。 * 在這 15 秒內，發生了很多事情： * 用戶最近的帖子可在 Twitter 和 Facebook 上獲取，他們喜歡的文章可在 Google Reader 上獲取，等等。 這本身可能需要 10 秒鐘或更長時間才能完成。 * 標識用戶，她的朋友等共享的多達一千個左右唯一 URL 的集合。 * 這些流進入獲取/分析管道的版本中，在該版本中，所有 URL 都使用上述相同的 ML 堆棧進行提取和詳細說明 * 該分析的結果被匯總，后處理并保存到 DynamoDB 和 S3 * 此過程的延遲確實很關鍵，因此這些過程無法串行執行-必須盡可能地進行流水線化和并行化。 * 吞吐量也很重要，因為該過程非常繁瑣，并且在進行大量注冊時，需要花費大量精力來降低延遲。 這正是 Prismatic 的流處理和聚合庫真正發揮作用的地方，它為每個用戶（并行供多個用戶）使用接近全容量的低延遲，流水線化的 map-reduce 作業集提供了等效的性能。 機。 ## API-面向客戶 * API 機器中包含了 Onboarding 和 Data Ingest 服務。 * 除了實際的提要生成過程外，不會說太多，只是它是一個復雜且高度優化的過程，該過程具有許多階段，這些階段與用戶的“指紋”相匹配，并針對索引進行查詢，檢索，排序和分頁生成的提要。 幾百毫秒。 * 從系統角度來看，這里的主要設計目標/挑戰是： * 必須將最新文章編入索引，并且可以用于生成低延遲的提要 * 該索引非常大（許多 GB），并且必須實時更新，以便用戶可以找到重大新聞 * 用戶應在各臺計算機之間實現負載平衡，并且響應負載而將新計算機啟動（并關閉）相對容易和快速。 * 產生良好的用戶供稿不僅需要索引-我們還需要用戶的“指紋”-他們的興趣，社交關系，他們最近看過的文章等等。 * 該指紋非常大，并且隨著用戶查看站點上的內容并與之交互而不斷變化。 * 前幾個問題的解決方案涉及 doc-master。 * doc-master 機器會整理我們當前的文檔集，對文檔進行預處理，然后每隔幾分鐘就會將一組準備好的索引文件寫入 S3。 * 當新的 API 機器啟動時，它首先讀取這些文件并將其轉儲到內存中，從而為其提供索引的近乎最新的副本。 * doc-master 還向所有實時 API 機器實時發布用于索引更改（文檔/注釋添加和刪除，故事集群更改等）的命令。 * 當一臺新機器出現時，它會重放最近幾分鐘的更改歷史，以使索引保持最新狀態。 * 機器所需的其他一般狀態（非特定于用戶的狀態）也將從 S3 讀取到內存中并定期刷新，或者如果數據較大且訪問頻率較低，則存儲在發電機中。 * 剩下的問題是如何有效地為用戶提供提要，而又不會產生 IO 成本以及在每個請求上獲取和更新指紋的延遲。 * 這里的方法是使用將用戶綁定到 API 機器的粘性會話 * 用戶首次登錄時，他們的數據都將在過期的刷新回寫緩存中全部加載到內存中 * 在整個用戶會話中，此數據保留在內存中，并用于生成其供稿 * 在整個會話過程中，所有用戶操作均通過此同一 API 機器 * 會話到期或計算機關閉時，每隔幾分鐘就對指紋中次要部分的更新進行批處理并刷新到冗余存儲中 * 更重要的更新是同步完成的，或者至少使用直接寫緩存進行。 * 在整個會話過程中僅讀取一次用戶指紋就需要付出很高的 IO 費用，這筆費用會在（通常）相對大量的 Feed 點擊，頁面，文章點擊，共享等用戶所獲得的費用中攤銷，并且 限制此數據的回寫次數。 當一臺計算機宕機時，數據將被刷新并將用戶轉移到另一臺計算機上-在最壞的情況下，對于某些用戶而言，幾分鐘的非關鍵數據將會丟失，這對于簡單性和可伸縮性的好處是值得的 。 始終可以通過以后的原始事件日志上的批處理作業來彌補此損失。 ## 其他服務-面向客戶 還有其他一些單獨的面向客戶的服務： * 公共提要-對未登錄的用戶進行主題和發布者提要的智能緩存，根據需要從常規 API 獲取它們，并允許對每個提要的多個年齡進行分頁。 * 身份驗證-處理帳戶創建，登錄等。 通常是 SQL 數據庫前面的薄層，用于存儲需要定期快照和備份的關鍵用戶數據。 * URL 縮短器 ## 批處理及其他服務 * 機器語言培訓，數據歸檔和事件跟蹤/分析的其他服務。 * MongoDB 用于存儲服務器指標和用戶分析，主要是因為它支持一個很好的低麻煩的故事，用于發送不同形狀的原始事件，維護正確的索引以及保持在線匯總計數。 ## 圖庫 * 這是一種很好地聲明式描述計算圖的方法，它發揮了 Clojure 的優勢。 圖只是 Clojure 映射，其中的鍵是關鍵字，而值是關鍵字函數，這些關鍵字函數采用由映射中的其他函數計算的值以及外部參數。 * 它在各處使用。 例如，文檔分析管道是一個圖形，其中文檔的每個詳細說明都可能取決于之前的內容（例如，確定文檔的主題取決于是否已提取其文本）； 新聞提要生成過程是一個由許多查詢和排名步驟組成的圖形； 每個生產服務本身就是一個圖，其中每個資源（例如數據存儲，內存索引，HTTP 處理程序等）都是可以依賴于其他資源的節點。 * 這樣可以輕松地執行以下操作： * 以模塊化方式（例如，使用子圖）緊湊地描述服務配置 * 產生圖表，描繪出流程或服務的依賴性 * 測量諸如文檔分析之類的復雜計算中每個節點上發生的計算時間和錯誤，或諸如 API 之類的復雜服務的每個資源上的活動 * 在不同的線程（或理論上甚至是機器）上智能地調度此類計算的不同節點 * 通過使用模擬替換圖表中的幾個節點（例如偽造存儲空間）等，輕松編寫我們整個生產服務的測試。 ## 基于文檔和用戶的機器學習 文檔和用戶是 Prismatic 應用 ML（機器學習）的兩個領域： ### 文件 ML * 給定一個 HTML 文檔： * 了解如何提取頁面的主要文本（而不是側邊欄，頁腳，注釋等），標題，作者，最佳圖像等 * 確定相關功能（例如，文章的主題，主題等） * 其中大多數任務的設置非常典型。 使用其他機器上的大批作業對模型進行訓練，這些機器從 s3 讀取數據，將學習到的參數文件保存到 s3，然后在攝取管道中從 s3 讀取（并定期刷新）模型。 * 流出系統的所有數據都可以反饋到該管道中，這有助于了解更多有趣的內容，并隨著時間的推移從錯誤中學習。 * 從軟件工程的角度來看，Prismatic 編寫的最有趣的框架之一是“ flop”庫，該庫實現了最先進的 ML 訓練和推理代碼，看起來與精美的普通 Clojure 代碼非常相似，但是可以編譯（使用 宏的魔力）到低級數組操作循環，這些循環與 Java 一樣接近金屬而無需借助 JNI。 * 與相應的 Java 相比，該代碼可以緊湊和易于閱讀，并且執行速度基本相同。 * 創建[快速運行的故事群集組件](http://blog.getprismatic.com/blog/2012/4/17/clustering-related-stories.html)付出了很多努力。 ### 用戶 ML * 猜測用戶對社交網絡數據感興趣的內容，并使用應用內的顯式信號（+ /刪除）完善這些猜測。 * 使用顯式信號的問題很有趣，因為用戶輸入應該很快反映在其提要中。 如果用戶連續從給定的發布者中刪除了 5 篇文章，請立即停止向他們展示該發布者的文章，而不是明天。 這意味著沒有時間在所有用戶上運行另一個批處理作業。解決方案是在線學習：立即根據用戶提供給我們的觀察結果更新用戶模型。 * 用戶交互事件的原始流已保存。 這樣可以在以后發生機器故障或類似情況時通過原始數據上的松散寫回緩存丟失任何數據，從而在以后的原始事件中重新運行用戶感興趣的 ML。 在線學習中的漂移可以得到糾正，并且可以計算出更準確的模型。 ## 得到教訓 * **查找您的故事**。 請仔細考慮整個管道以及流經該管道的所有數據。 使用針對特定問題的解決方案來應對可伸縮性挑戰。 每個服務都內置了自己的擴展故事，并且這些服務以一種通信方式進行通信，應該可以輕松地擴展每個組件，而又不會給其他組件帶來太多壓力。 相反，從圍繞 Hadoop 作業構建的系統開始，將所有數據以原始格式存儲在分布式數據庫/文件系統中，Prismatic 會講一個不同的故事。 * **尷尬地發現并行的機會并加以利用**。 * **在用戶等待**的同時并行工作。 例如，入職流程會吸收有關新用戶的數據，以便可以在注冊該應用后的幾秒鐘內為他們提供出色的個性化體驗。 * **使用函數式編程**構建細粒度，靈活的抽象。 這些抽象構成為表達特定于問題的邏輯。 * **避免使用大型，整體式框架**，例如 Hadoop。 這樣就產生了一個較小的代碼庫，在所有條件相同的情況下，它更不容易出錯，更易于理解并且更易于擴展。 之所以建立自己的庫，僅僅是因為開源代碼的許多功能都被鎖定在整體框架中，并且在某些問題中斷或無法擴展時，不容易重用，擴展或調試。 * **合適的人對于使這一切都至關重要。 當前的后端團隊由三位 CS 博士組成，他們從事從 ML（機器語言）算法到低級系統工程到 Web 和 iPhone 客戶端代碼的所有工作。** * **所有代碼都盡早投入生產，**通常是通過對使構建和調試生產服務變得簡單而有趣的工具進行投資。 * **保持簡單**。 不要為簡單的東西承擔復雜的庫或框架的負擔，并且當一個簡單得多的解決方案就足夠好的時候也不要幻想。 例如，使用簡單的基于 HTTP 的消息傳遞協議，而不是流行的框架之一。 在合理的情況下，樂于為剛剛可用的托管解決方案（例如 S3 或 Dynamo）支付更多費用。 * **投資構建出色的工具和庫**。 例如，Prismatic 的“觸發器”庫使他們可以在代碼的 1/10 中編寫與 Java 一樣快的數字運算機器學習算法。 “存儲”將鍵值存儲的許多不重要的細節抽象掉，從而允許編寫用于緩存，批處理和刷新的高級抽象，這些抽象可在各種情況下在各種存儲引擎中工作。 “圖形”使編寫，測試和監視分布式流處理服務變得輕而易舉。 * **仔細考慮每種數據類型**，不要指望找到一種適用于 IO 和存儲的千篇一律的解決方案。 ## 相關文章 * [Prismatic 希望成為數字時代的報紙](http://gigaom.com/2012/05/03/prismatic-wants-to-be-the-newspaper-for-a-digital-age/) * [棱柱形博客](http://blog.getprismatic.com/) * [關于 Clojure 的主題演講](https://github.com/strangeloop/clojurewest2012-slides) * [棱柱形希望創建一個新類別的社會新聞](http://bits.blogs.nytimes.com/2012/04/03/prismatic-hopes-to-offer-a-new-category-of-social-news/) * [Prismatic 的布拉德福德·克羅斯（Bradford Cross）在工作室里想重塑社交新聞](http://techcrunch.com/2012/06/07/in-the-studio-prismatics-bradford-cross-wants-to-reinvent-social-news/ ) * [Prismatic 的軟件工程](http://blog.getprismatic.com/blog/2012/4/5/software-engineering-at-prismatic.html) * [Prismatic 如何處理數據存儲和聚合](http://blog.getprismatic.com/blog/2012/4/9/how-prismatic-deals-with-data-storage-and-aggregation.html) * [DataSift 架構：每秒 120,000 條推文的實時數據挖掘](http://highscalability.com/blog/2011/11/29/datasift-architecture-realtime-datamining-at-120000-tweets-p.html ) 好看！ 半危險=危險？ 我第一次聽到這個詞。 干杯， --rj 羅杰擊敗了我，但是： “半危險的方法不會起作用。” 那么好吧，我想什至根本不考慮那些完全危險的方法。 = P 我每天都會使用 getprismatic.com 數周，我必須承認，現在它已成為新聞探索的一部分。 夢幻般的建筑，當我想到它們如何實時帶來如此優質的內容時，甚至讓我驚訝。 感謝您對他們的文章進行了詳細的高級介紹。 很棒的文章！ 好讀！ :) 這都是有點老的學校。 機器學習= 1980。 您是否考慮過將 Redis 用于內存中的數據結構？ 聽起來很合適。