# Facebook 的新實時分析系統：HBase 每天處理 200 億個事件 > 原文： [http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html](http://highscalability.com/blog/2011/3/22/facebooks-new-realtime-analytics-system-hbase-to-process-20.html)  Facebook 再次這樣做。 他們建立了另一個系統，能夠對大量的實時數據流進行有用的處理。 上次我們看到 Facebook 發布其[新的實時消息系統：HBase 每月存儲 135 億條消息](http://highscalability.com/blog/2010/11/16/facebooks-new-real-time-messaging-system-hbase-to-store-135.html)。 這次，它是一個實時分析系統，每天處理*超過 200 億個事件（每秒 200,000 個事件），時延不到 30 秒*。 Facebook 工程經理 Alex Himel [解釋了他們構建的](http://www.facebook.com/note.php?note_id=10150103900258920)（[[視頻](http://www.facebook.com/video/video.php?v=707216889765&oid=9445547199&comments)）以及所需的規模： > 在過去的一年中，社交插件已成為數百萬網站的重要且不斷增長的流量來源。 上周，我們發布了新版本的“網站洞察”，以使網站所有者可以更好地分析人們如何與其內容進行互動，并幫助他們實時優化網站。 為此，我們必須設計一個系統，每天處理 200 億個事件（每秒 200,000 個事件），而延遲不到 30 秒。 亞歷克斯在演講中做得很好。 強烈推薦。 但是讓我們更深入地了解發生了什么... Facebook 通過通過[社交插件](http://developers.facebook.com/docs/plugins/)的病毒傳播，將非 Facebook 網站重新綁定到 Facebook 中，并將 Facebook 網站重新綁定到 Facebook 中，從而實現了這種強大的分析系統的需求，這是 Facebook 出色的計劃，旨在實現全球網絡統治 非 Facebook 網站。 基本上，人們可以做的任何事情都會被 Facebook 捕獲并反饋，而 Facebook 上所做的任何事情都可以顯示在您的網站上，從而在兩者之間建立更緊密的聯系。 Facebook 的社交插件是 Roman Empire Management101。您不必征服所有人就可以建立帝國。 您只要控制每個人，使他們意識到自己可以被征服的威脅，同時使他們意識到，哦，與羅馬友好可以賺很多錢。 我記得這一策略已經工作了很長時間。 毫無疑問，您在網站上看到了社交插件。 社交插件可讓您查看朋友喜歡，在網絡上的站點上評論或共享的內容。 想法是將社交插件放在網站上，使內容更具吸引力。 您的朋友可以看到您喜歡的東西，而網站可以看到每個人都喜歡的東西。 引人入勝的內容為您帶來更多點擊，更多喜歡和更多評論。 對于企業或品牌甚至個人而言，內容越具有吸引力，人們看到的內容就越多，新聞源中出現的內容就越多，從而將其吸引到網站的流量也就越大。 以前的孤狼網是內容獵人無聲無息地跟蹤著網站的地方，如今已變成一個迷人的小村莊，每個人都知道您的名字。 這就是社交的力量。 例如，此處有關 HighScalability 的帖子現在具有 [Like 按鈕](http://developers.facebook.com/docs/reference/plugins/like/)。 TechCrunch 已使用 Facebook 的評論系統移至[。 立即辯論集中在評論系統本身的質量上，但這并不是重點，重點是使 TechCrunch 更深入地投入到 Facebook 的 500+百萬用戶的生態系統中。 其他插件包括：推薦，活動源，登錄，注冊，Facepile 和實時流。](http://techcrunch.com/2011/03/01/facebook-rolls-out-overhauled-comments-system-try-them-now-on-techcrunch/) 除非您能理解所有這些數據，否則它們意義不大，并且還向內容提供商證明了社交插件確實確實使他們的網站更具吸引力。 這就是 Facebook 的[洞察系統](http://www.allfacebook.com/facebook-rolls-out-expanded-insights-for-domains-2011-03)出現的地方。這是一個分析系統，可讓您訪問所收集的所有多汁數據。 它提供統計信息，例如“贊”按鈕分析，“評論”框分析，“熱門頁面”，“受眾特征”和“自然共享”。 想象一下，數百萬個網站和數十億個頁面以及數百萬的人通過這些社交插件不斷地流式傳輸數據。 您如何實時理解所有這些數據？ 這是一個具有挑戰性的問題。 ## 價值主張 借助 Insights System，內容生產者可以看到人們喜歡的東西，這將使內容生產者能夠產生更多人們喜歡的東西，從而提高網絡的內容質量，從而為用戶提供更好的 Facebook 體驗。 ## 系統目標 * 以非常可靠的方式為人們提供實時計數器，這些計數器涉及許多不同的指標，并解決了數據偏差問題。 * 提供匿名數據。 您無法弄清這些人是誰。 * 展示為什么插件很有價值。 您的業??務從中獲得什么價值？ * 使數據更具可操作性。 幫助用戶采取行動，使其內容更具價值。 * 新的 UI 隱喻。 使用漏斗的想法。 * 有多少人看到了該插件，有多少人對此采取了行動，以及有多少人轉化為訪問您網站的流量。 * 使數據更及時。 * 他們實時進行。 從 48 小時轉向 30 秒。 * 消除了多個故障點以實現此目標。 ## 挑戰性 * **許多事件類型** * 跟蹤 100 多個指標。 * 插件印象。 * 喜歡 * 新聞提要印象 * 新聞訂閱源點擊 * 客層 * **大量數據** * 每天 200 億個事件（每秒 200,000 個事件） * **數據偏斜-密鑰分布不均** * 喜歡遵循類似冪律分布的方法。 長尾巴很少有人喜歡，但有些資源卻得到大量喜歡。 * 這帶來了熱區，熱鍵和鎖爭用的問題。 ## 實現了一堆不同的原型 * **MySQL 數據庫計數器** * 排有一把鑰匙和一個柜臺。 * 導致大量數據庫活動。 * 統計信息每天存儲在桶中。 每天午夜時分，統計數據都會累積。 * 當達到過渡期時，這將導致對數據庫的大量寫入，從而導致大量的鎖爭用。 * 嘗試通過考慮時區來分散工作。 * 試圖以不同的方式分割事物。 * 高寫入率導致鎖爭用，很容易使數據庫超載，必須不斷監視數據庫，并且必須重新考慮其分片策略。 * 解決方案不適合該問題。 * **內存中計數器** * 如果您擔心 IO 中的瓶頸，則將其全部放入內存中。 * 沒有規模問題。 計數器存儲在內存中，因此寫入速度快并且計數器易于分片。 * 由于未說明的原因，感覺到內存中的計數器并不像其他方法那樣準確。 甚至只有 1％的失敗率也是不可接受的。 Analytics（分析）可以賺錢，所以計數器必須非常準確。 * 他們沒有實現這個系統。 這是一個思想實驗，準確性問題導致他們繼續前進。 * **MapReduce** * 將 Hadoop / Hive 用于先前的解決方案。 * 靈活。 易于運行。 可以處理大量寫入和讀取的 IO。 不必知道他們將如何提前查詢。 數據可以存儲然后查詢。 * 不是實時的。 許多依賴項。 很多失敗點。 復雜的系統。 不夠可靠，無法達到實時目標。 * **卡桑德拉** * 基于可用性和寫入率，HBase 似乎是一個更好的解決方案。 * 寫速度是要解決的巨大瓶頸。 ## 獲勝者：HBase + Scribe + Ptail + Puma * 在高層次上： * HBase 在分布式計算機上存儲數據。 * 使用尾部架構，新事件存儲在日志文件中，并且尾部有日志。 * 系統匯總事件并將其寫入存儲。 * UI 會拉出數據并將其顯示給用戶。 * 數據流 * 用戶在網頁上單擊“贊”。 * 向 Facebook 發送 AJAX 請求。 * 使用 Scribe 將請求寫入日志文件。 * 編寫極其精簡的日志行。 日志行越緊湊，則可以在內存中存儲的越多。 * 抄寫員處理文件翻轉之類的問題。 * Scribe 建立在 Hadoop 建立在同一個 HTFS 文件存儲上。 * 尾巴 * 使用 Ptail 從日志文件讀取數據。 Ptail 是一個內部工具，用于聚合來自多個 Scribe 存儲的數據。 它拖尾日志文件并提取數據。 * Ptail 數據分為三個流，因此最終可以將它們發送到不同數據中心中自己的群集。 * 插件印象 * 新聞提要印象 * 動作（插件+新聞源） * 彪馬 * 批處理數據可減少熱鍵的影響。 盡管 HBase 每秒可以處理大量寫入操作，但它們仍要批處理數據。 熱門文章會產生大量的印象和新聞提要印象，這將導致巨大的數據偏斜，從而導致 IO 問題。 批處理越多越好。 * 批量平均 1.5 秒。 想要批處理更長的時間，但是它們具有太多的 URL，以至于在創建哈希表時它們用盡了內存。 * 等待上一次刷新完成以開始新批處理，以避免鎖爭用問題。 * UI 渲染數據 * 前端都是用 PHP 編寫的。 * 后端是用 Java 編寫的，并且 Thrift 用作消息傳遞格式，因此 PHP 程序可以查詢 Java 服務。 * 緩存解決方案用于使網頁顯示更快。 * 效果因統計信息而異。 計數器可以很快回來。 在域中查找頂級 URL 可能需要更長的時間。 范圍從 0.5 到幾秒鐘。 * 緩存的數據越長越長，實時性就越差。 * 在 Memcache 中設置不同的緩存 TTL。 * MapReduce * 然后將數據發送到 MapReduce 服務器，以便可以通過 Hive 查詢。 * 這也可以用作備份計劃，因為可以從 Hive 恢復數據。 * 一段時間后，原始日志將被刪除。 * HBase 是分發列存儲。 * Hadoop 的數據庫接口。 Facebook 的內部人員在 HBase 上工作。 * 與關系數據庫不同，您不在表之間創建映射。 * 您不創建索引。 您擁有主行鍵的唯一索引。 * 通過行鍵，您可以擁有數百萬個稀疏列的存儲。 非常靈活。 您不必指定架構。 您定義列族，可以隨時向其中添加鍵。 * WAL 預寫日志是可伸縮性和可靠性的關鍵功能，它是應該執行的操作的日志。 * 根據密鑰，數據將分片到區域服務器。 * 首先寫給 WAL。 * 數據被存入內存。 在某個時間點，或者如果已經積累了足夠的數據，則將數據刷新到磁盤。 * 如果機器出現故障，您可以從 WAL 重新創建數據。 因此，不會永久丟失數據。 * 結合使用日志和內存存儲，它們可以可靠地處理極高的 IO 率。 * HBase 處理故障檢測并自動跨故障路由。 * 當前，HBase 重新分片是手動完成的。 * 自動熱點檢測和重新分片在 HBase 的路線圖上，但還沒有。 * 每個星期二，有人查看密鑰并決定對分片計劃進行哪些更改。 * **模式** * 在每個 URL 上存儲一堆計數器。 * 行鍵是唯一的查找鍵，是反向域的 MD5 哈希 * 選擇適當的密鑰結構有助于掃描和分片。 * 他們遇到的問題是將數據正確分片到不同的計算機上。 使用 MD5 哈希值可以更容易地說出該范圍在此處，該范圍在該位置。 * 對于 URL，它們會執行類似的操作，此外還會在其上添加一個 ID。 Facebook 中的每個 URL 都有一個唯一的 ID，該 ID 用于幫助分片。 * 使用反向域，例如 *com.facebook /* ，以便將數據聚集在一起。 HBase 確實擅長掃描集群數據，因此，如果他們存儲數據以便集群在一起，則它們可以有效地計算整個域的統計信息。 * 將每行 URL 和每個單元格視為一個計數器，就可以為每個單元格設置不同的 TTL（生存時間）。 因此，如果每小時進行一次計數，則沒有必要永久保留每個 URL，因此他們將 TTL 設置為兩周。 通常按每個列族設置 TTL。 * 每個服務器每秒可處理 10,000 次寫入。 * 從日志文件讀取數據時，檢查點用于防止數據丟失。 * 裁縫將日志流檢查點保存在 HBase 中。 * 在啟動時重播，因此不會丟失數據。 * 用于檢測點擊欺詐，但沒有內置欺詐檢測。 * **泰勒熱點** * 在分布式系統中，系統的一個部分可能比另一個部分更熱。 * 一個示例是區域服務器可能很熱，因為以這種方式定向了更多的密鑰。 * 一個尾巴也可能落后于另一個。 * 如果一個拖尾落后一個小時，而其他拖尾已經更新，那么您將在 UI 中顯示哪些數字？ * 例如，展示次數比操作要高得多，因此點擊率在過去一小時中要高得多。 * 解決方案是找出最新的拖尾，并在查詢指標時使用。 * **未來方向** * **熱門列表** * 對于 YouTube 這樣的域名，很難找到最喜歡的 URL（最受歡迎的 URL），因為這些 URL 可以快速共享數百萬個 URL。 * 需要更多創新的解決方案來保持內存中的排序并隨著數據的變化而保持最新。 * **不同的用戶計數** * 一個時間窗中**上有多少人喜歡某個 URL。 在 MapReduce 中很容易做到，而在幼稚的計數器解決方案中很難做到。** * **適用于社交插件**以外的應用程序 * **移至多個數據中心** * 當前是單個數據中心，但希望遷移到多個數據中心。 * 當前的后備計劃是使用 MapReduce 系統。 * 備份系統每晚都會進行測試。 比較針對 Hive 和此新系統的查詢，以查看它們是否匹配。 * **項目** * 花了大約 5 個月的時間。 * 首先有兩名工程師開始從事該項目。 然后添加了 50％的工程師。 * 前端有兩個 UI 人員??。 * 看起來大約有 14 個人從工程，設計，PM 和運營中從事了該產品的工作。 當我們查看消息傳遞系統和此分析系統時，我們注意到兩個系統的共同點：大量，HBase，實時。 以可靠，及時的方式處理大量寫入負載的挑戰是這些問題的共同基礎。 Facebook 專注于 HBase，Hadoop，HDFS 生態系統，并指望稍后解決的操作問題。 其他人之所以選擇 Cassandra，是因為他們喜歡 Cassandra 的可伸縮性，多數據中心功能以及易于使用的功能，但它并不適合整個分析堆棧。 這對您意味著什么？ 即使您不是 Facebook，該體系結構也足夠簡單，并且由足夠多的現成工具組成，甚至可以用于許多小型項目。 ## 相關文章 * [Medialets 體系結構-擊敗艱巨的移動設備數據洪水](http://highscalability.com/blog/2011/3/8/medialets-architecture-defeating-the-daunting-mobile-device.html)-分析平臺的另一種表現。 * [Twitter 的計劃分析 1000 億條推文](http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html) * [擴展分析解決方案技術講座（3/2/11）[HQ]](http://www.facebook.com/video/video.php?v=707216889765&oid=9445547199&comments) 這是一個很棒的文章。 如何在不同的時間范圍內進行匯總？ 每個<計數器和時間窗口>對都有單獨的單元格嗎？ 好消息是，即使您不是 Facebook 人士，也沒有整個工程師團隊來構建您的分析平臺，您仍然可以使用現有的帶有 [OpenTSDB](http://opentsdb.net) 的開源軟件來構建類似的平臺。 在 StumbleUpon，我們僅使用 20 個節點群集中的 3 個即可輕松地[每秒處理 200,000 個事件](https://issues.apache.org/jira/browse/HBASE-2170?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13008872#comment-13008872)，因此，大概您還可以使用更多節點輕松地將其擴展為每天數十億個事件。 當 Facebook 工程師在 6 個月前啟動該項目時，Cassandra 沒有分布式計數器，該計數器現在已提交到主干中。 Twitter 正在 Facebook 上投入大量資金用于實時分析（請參閱 Rainbird）。 由于計數器寫入分散在多個主機上，因此寫入速率對于 Cassandra 來說應該不是瓶頸。 對于 HBase，每個計數器仍然受單個區域服務器性能的約束嗎？ 兩者的性能比較將很有趣。 一個簡單的問題-如果您拖尾的日志文件可能以不同的速率寫入，那么您如何知道從頭到尾有多少行？ 尾巴-跟隨什么？ 但是，如何將其傳送到另一個程序？ 謝謝 HBase 表中的主鍵不是索引。 由于行以排序順序存儲，因此查找速度很快。 這些家伙在做什么只是在計數在線中/事件中的事件.....沒什么好說的，這全都取決于一個人可以計數的速度...... 我認為他們也使它變得復雜 只是為了計算這些點擊/事件