# Twitter 計劃分析 1000 億條推文 > 原文： [http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html](http://highscalability.com/blog/2010/2/19/twitters-plan-to-analyze-100-billion-tweets.html) 如果 Twitter 是某些人認為的“網絡神經系統”，那么從神經系統來的所有這些信號（推文）的大腦究竟是什么呢？ 大腦就是 Twitter 分析系統，而 Twitter 的分析負責人 Kevin Weil 是負責計算超過 1000 億條 Tweet（約等于人腦中神經元數量）含義的單元。 目前，Twitter 僅占預期的 1000 億條推文的 10％，但始終要做好計劃。 Kevin 在 [Hadoop Meetup](http://www.meetup.com/hadoop/) 上的 Twitter 上發表了 [Hadoop 和協議緩沖區的演講，解釋了 Twitter 如何計劃使用所有數據來回答關鍵業務問題。](http://www.slideshare.net/kevinweil/protocol-buffers-and-hadoop-at-twitter) Twitter 有興趣回答哪種類型的問題？ 幫助他們更好地了解 Twitter 的問題。 像這樣的問題： 1. 一天我們要處理多少個請求？ 2. 平均延遲時間是多少？ 3. 一天有多少次搜索？ 4. 多少個唯一查詢，多少個唯一用戶，他們的地理分布是什么？ 5. 作為用戶的推文，我們能告訴我們什么？ 6. 誰轉發了更多？ 7. 移動用戶的用法有何不同？ 8. 同時出了什么問題？ 9. 哪些功能使用戶著迷？ 10. 用戶的聲譽是什么？ 11. 轉推的深度有多深？ 12. 哪些新功能有效？ 還有更多。 這些問題可以幫助他們理解 Twitter，其分析系統可以幫助他們更快地獲得答案。 ## Hadoop 和 Pig 用于分析 您能想到的任何問題都需要分析大數據來尋找答案。 1000 億是很多推文。 這就是 Twitter 使用 [Hadoop 和 Pig](http://www.slideshare.net/kevinweil/hadoop-pig-and-twitter-nosql-east-2009) 作為其分析平臺的原因。 Hadoop 提供：在分布式文件系統上的鍵值存儲，水平可伸縮性，容錯性以及用于計算的 map-reduce。 Pig 是一種查詢機制，可以在 Hadoop 之上編寫復雜的查詢。 說您正在使用 Hadoop 僅僅是故事的開始。 故事的其余部分是使用 Hadoop 的最佳方法是什么？ 例如，如何在 Hadoop 中存儲數據？ 這似乎是一個奇怪的問題，但答案卻有很大的后果。 在關系數據庫中，您不存儲數據，數據庫存儲您，或者，它為您存儲數據。 API 以行格式移動數據。 Hadoop 并非如此。 Hadoop 的鍵值模型意味著由您決定如何存儲數據。 您的選擇與性能，可以存儲多少數據以及對將來的變化做出反應的敏捷程度有很大關系。 每個推文都有 12 個字段，其中 3 個具有子結構，并且隨著新功能的添加，這些字段可以并且會隨著時間而變化。 存儲此數據的最佳方法是什么？ ## 數據存儲在協議緩沖區中以保持數據的高效和靈活 Twitter 認為 CSV，XML，JSON 和協議緩沖區是可能的存儲格式。 協議緩沖區*是一種以有效但可擴展的格式對結構化數據進行編碼的方法。 Google 幾乎所有內部??RPC 協議和文件格式*都使用協議緩沖區。 BSON（二進制 JSON）尚未進行評估，但可能因為它沒有 IDL（接口定義語言）而無法使用。 [Avro](http://hadoop.apache.org/avro/) 是他們將來會考慮的一種潛在選擇。 創建了一個評估矩陣，該矩陣宣布 Protocol Buffers 為獲勝者。 贏得協議緩沖區是因為它允許將數據拆分到不同的節點上。 它不僅可用于推文（日志，文件存儲，RPC 等），還可用于其他數據； 它有效地解析； 可以添加，更改和刪除字段，而無需更改已部署的代碼； 編碼很小； 它支持層次關系。 所有其他選項均未通過這些條件中的一個或多個。 ## IDL 用于 Codegen 出乎意料的是，效率，靈活性和其他神圣的怪胎指標并不是 Twitter 喜歡協議緩沖區的唯一原因。 通常被視為弱點的是，協議緩沖區使用 IDL 來描述數據結構，實際上被 Twitter 視為大贏家。 必須定義數據結構 IDL 通常被視為浪費時間。 但是作為構建過程的一部分，它們從 IDL 中生成所有與 Hadoop 相關的代碼：協議緩沖區 InoutFOrmats，OutputFormats，Writables，Pig LoadFuncs，Pig StoreFuncs 等。 以前為每個新數據結構手動編寫的所有代碼現在都可以從 IDL 中自動自動生成。 這樣可以節省大量精力，并且代碼的錯誤少得多。 IDL 實際上節省了時間。 某一時刻，模型驅動的自動生成是許多項目的通用策略。 然后，時尚開始產生一切。 Codegen 似乎還不夠敏捷。 一旦生成了所有內容，您就開始真正擔心語言的冗長性，這使每個人都轉向了更加動態的語言，具有諷刺意味的是，DSL 仍然經常被列為 Ruby 之類的語言的優勢。 手編碼的另一個后果是周炎的框架。 框架有助于平息認為必須從頭開始編寫所有內容而造成的損害。 很高興看到代碼生成再次流行。 使用聲明性規范，然后編寫高效的，特定于系統的代碼生成器，功能非常強大。 數據結構是低掛的果實，但是也可以自動化更大，更復雜的過程。 總體而言，這是一次非常有趣和有益的演講。 我喜歡看到基于想要的內容和原因對不同選項進行的仔細評估。 令人耳目一新的是，這些明智的選擇如何協同作用，并構成了一個更好，更穩定的系統。 ## 相關文章 1. [Twitter 上的 Hadoop 和協議緩沖區](http://www.slideshare.net/kevinweil/protocol-buffers-and-hadoop-at-twitter) 2. [Twitter 背后的窺視](http://borasky-research.net/2010/02/17/a-peek-under-twitters-hood)-Twitter 的開源頁面上線了。 3. [Hadoop](http://hadoop.apache.org/) 4. [協議緩沖區](http://code.google.com/p/protobuf/) 5. [Hadoop 灣區用戶組-2 月 17 日在 Yahoo! -RECAP](http://developer.yahoo.net/blogs/hadoop/2010/02/hadoop_bay_area_user_group_feb.html) 6. [Twitter 說](http://blog.twitter.com/2010/02/measuring-tweets.html)“今天，我們每天看到 5000 萬條推文，平均每秒 600 條推文。” > 這就是為什么 Twitter 使用 Hadoop 和 Pig 作為分析平臺的原因 has a broken url 謝謝。 似乎所有 URL 由于某種原因都被轉義。 現在應該修復。 所有這些推文中有 99％是垃圾。 他們究竟將如何分析其中的任何內容？ 從理論上講，每條推文都是一種人類思想或一種交流意識。 分析大量數據將意味著識別人腦在各個方面的功能-例如給定的時間，星期幾，地理位置，文化，趨勢等-因此，了解這種人類行為就構成了識別人的大腦。 在線大眾。 （僅限于 Twitter）。 最后，它是所有統計信息-一定比例的網絡將為這種現象數據做出貢獻。 希望我們能更多地了解人的思想鏈是如何運作的，并希望這有助于神經科學家作為研究工具。 我的$ 0.02 ?Vj 幾個月前，奇怪的 Twitter Twitter Tweet ID 泛濫成災，他們怎么可能擁有 1000 億條 Tweet？ 我會用“神經系統”代替“神經系統”，“神經系統”將這些信號/推文發送給我們的外行賄賂者，改為“突觸發射”，其中指出推文更恰當地是*大腦*內部的信號。 它是對信號觸發或重推的分析，我們發現了模式，并且在這些模式中有意義。 有關 Synaptic 網站的更多信息，請訪問： http://synapticweb.pbworks.com/ @khrisloux 我要說的是 [Vivisimo 的 Velocity 搜索引擎](http://vivisimo.com/)可以為他們提供很多幫助。 有趣的帖子，托德。 您的帖子中有一些復制錯誤： “ 5.作為用戶，我們可以從他們的推特中獲得什么？” | 可能應該是：我們能告訴用戶什么... “ 8.如果同時出錯怎么辦？” | 怎么了... “ 11.轉發的深度有多深？” | 有多深... 不是要分析什么，而是要服務于什么業務目的。 無論如何，tweet 中的 URI 可以為用戶分析提供更多的價值。 “ Protocol Buffers 之所以獲獎，是因為它允許將數據拆分到不同的節點上；它不僅可以用于推文（日志，文件存儲，RPC 等），而且還可以重用；它可以高效地解析；可以添加，更改和刪除字段而無需 更改已部署的代碼；編碼很小；它支持層次關系。所有其他選項都無法通過其中一個或多個條件。” 只需用純文本替換 Protocol Buffer 并享受相同的方法即可：)嚴重的是，我沒有得到 PB 選擇背后的基本原理，但最終還是要隨心所欲。 除非您在 hdfs 的頂部構建 HBase 之類的東西，否則當您運行冗長的批處理作業時，內部存儲格式并不重要。 “今天，我們每天看到 5000 萬條推文，平均每秒 600 條推文。” 什么！？ 每秒 600 條推文！？ ... 哇...我真是令人難以置信地不知所措...我的意思是我覺得 Twitter 可以解決所有這些可擴展性問題，因為它們每秒有成千上萬甚至數十萬條推文。 天哪，如果他們用 C 編寫 Twitter 系統，就可以輕松地通過單個服務器處理“所有”流量。 無論哪種方式，我仍然認為 Twitter 是一個好主意，他們應該得到應有的榮譽，他們在 Twitter 的整個軟件包和聲譽方面都做得很好。 但是，為什么不聘請 C 程序員來重寫他們的堆棧并降低成百上千的成本呢？ @羅伯特·古爾德（Robert Gould）：我也為如此低的數量感到驚訝。 雖然據我了解，問題不在于處理傳入的 tweet，而是將它們發送給所有訂戶。 請記住，某些用戶有數千個（或數百萬個）關注者。 用 C 重寫對可伸縮性沒有多大幫助。 它將使系統稍微快一些，但不超過一個數量級，以可維護性，穩定性和開發速度為代價。 我認為經過大量分析，并從大型 Twitter 數據庫中獲取了大量數據之后，我們會發現我們的邏輯性不如我們想像的那樣，而且實際上是可預測的。 模式將得出結論，就像地球上所有其他生物一樣，我們受到重力，季節，夜晚和白天的影響，x 類型的人更有可能鳴叫 x 等。我認為這一實驗肯定會證實人類是 習慣的生物。