# Rackspace 現在如何使用 MapReduce 和 Hadoop 查詢 TB 的數據 > 原文： [http://highscalability.com/blog/2008/1/30/how-rackspace-now-uses-mapreduce-and-hadoop-to-query-terabyt.html](http://highscalability.com/blog/2008/1/30/how-rackspace-now-uses-mapreduce-and-hadoop-to-query-terabyt.html) 您如何每天查詢來自 600 多個活動服務器的數百 GB 新數據？ 如果您認為這聽起來像是 [MapReduce 與數據庫大戰](http://highscalability.com/database-people-hating-mapreduce)激烈對峙的完美戰場，那么您是正確的。 Mailtrust（Rackspace 的郵件部門）的首席技術官 Bill Boebel 慷慨地提供了一個有趣的說明，說明他們如何將其日志處理系統從存儲在每種計算機方法中的早期變形蟲文本文件發展到尼安德特人關系 最終無法與之抗衡的數據庫解決方案，最后成為基于 Homo sapienic Hadoop 的解決方案，該解決方案對他們來說是明智的選擇，并且具有無限的可擴展性潛力。 Rackspace 面臨一個現在熟悉的問題。 大量數據流進來。您將所有這些數據存儲在哪里？ 您如何使用它呢？ 在他們的系統的第一個版本中，日志存儲在純文本文件中，并且必須由登錄到每臺機器上的工程師手動搜索。 然后是相同過程的腳本版本。 下一個重大發展是單機 MySQL 版本。 由于大量的數據洪泛導致大量索引混亂，因此插入很快成為瓶頸。 定期散裝加載是解決此問題的方法，但分度指數的剪切大小使其減慢了速度。 然后根據時間將數據分為合并表，因此索引更新不是問題。 隨著越來越多的數據，此解決方案由于負載和操作問題而崩潰。 面對指數級增長，他們花了大約 3 個月的時間使用 Hadoop（Google 文件系統和 MapReduce 的開源實現），Lucene 和 Solr 構建新的日志處理系統。 遷移到已分區的 MySQL 數據集是一種選擇，但他們認為，這樣做只會花費時間，并且將來無論如何都需要創建更具可擴展性的解決方案。 未來是今年年初。 他們的新系統的優勢在于，他們現在可以按照自己想要的任何方式查看其數據： * 每晚 MapReduce 作業收集有關其郵件系統的統計信息，例如按域，傳輸的字節數和登錄數的垃圾郵件計數。* 當他們想知道客戶從哪個世界登錄時，便創建了一個快速的 MapReduce 作業，并在幾個小時內得到了答案。 在典型的 ETL 系統中，實際上是不可能的。 此開關更改了他們經營業務的方式。 Stu Hood 很好地總結了這種影響：“現在，只要我們想到有關客戶使用模式的復雜問題，我們都可以通過 MapReduce 在數小時內從日志中獲取答案。這是強大的功能。” 在本文的其余部分中，Bill 描述了其系統的演變以及促使其從關系數據庫解決方案遷移到 MapReduce 系統的力量。 在開始之前，我真的要感謝 Bill Boebel 花了很多時間和精力來創建這份非常有價值的體驗報告。 ## 信息來源 * [Rackspace 上的 MapReduce](http://blog.racklabs.com/?p=66)* Mailtrust（Rackspace 的郵件部門）的首席技術官 Bill Boebel 發送給我的文檔。 這篇文章與通常的內容有所不同，因為到目前為止，大多數內容都是由 Bill 撰寫的，我對它的組織方式也有所不同。 ## 該平臺 * Hadoop 的* Hadoop 分布式文件系統（HDFS）* Lucene* 索爾* Tomcat ## 統計資料 * Rackspace 擁有超過 5 萬個設備和 7 個數據中心。* 郵件系統和日志記錄服務器當前位于 3 個 Rackspace 數據中心中。* 該系統在 Solr 中存儲了 8 億多個對象（一個對象=用戶事件，例如接收電子郵件或登錄 IMAP），在 Hadoop 中存儲了 96 億個對象，相當于 6.3 TB 壓縮。* 每天會生成數百 GB 的電子郵件日志數據。 ## Mailtrust 的背景 * 電子郵件托管公司* 成立于 1999 年，于 2007 年與 Rackspace 合并，以前的名稱為：Webmail.us* 80K 商業客戶，700K 郵箱。* 2 個托管郵件產品：值得注意的，MS Exchange* 值得一提的系統： *自產，基于 Linux，POP3，IMAP，網絡郵件，RSS 提要，共享日歷，Outlook 同步，Blackberry 同步。 *約 600 臺服務器和商用硬件，旨在解決常見故障。* MS Exchange 系統： * MAPI，POP，IMAP，OWA，Blackberry，Goodmail，ActiveSync。 *約 100 臺服務器，高端硬件，SAN & DAS 存儲。 ## 架構 當前基于 Hadoop 的系統的工作方式是：* 原始日志從數百個郵件服務器實時傳輸到 Hadoop 分布式文件系統（“ HDFS”）。* 計劃運行 MapReduce 作業以使用 Apache Lucene 和 Solr 索引新數據。* 一旦建立索引，它們將被壓縮并存儲在 HDFS 中。* 每個 Hadoop 數據節點都運行一個 Tomcat servlet 容器，該容器承載許多 Solr 實例，這些實例拉并合并新索引，并向我們的支持團隊提供真正快速的搜索結果。 ## 系統替代 ### 問題 Mailtrust 是一家非常注重客戶服務的公司。 對于我們的支持技術人員而言，能夠檢查郵件日志以對我們的客戶進行故障排除非常重要。 我們的支持技術人員每天需要搜索日志數百次，因此提供此功能的工具必須快速準確。 每天有 600 多個郵件服務器和數百 GB 的原始日志數據產生，因此管理起來很棘手。 這是 Mailtrust 日志記錄體系結構的簡要歷史，我們面臨的問題，如何克服它們以及當今系統的外觀... ### 記錄 v1.0 日志以純文本格式存儲 每個郵件服務器的本地磁盤上的文件，并保留了 14 天。 我們的支持技術人員沒有對服務器的登錄訪問權限，因此，要搜索日志，他們將必須向我們的工程師升級。 然后，工程師將不得不進入每個郵件服務器并使用 grep / var / log / maillog。 問題：一旦我們在十幾臺服務器上發展了很多，這種手動登錄每個服務器的過程對于我們的工程師來說就變得很耗時。 ### 記錄 v1.1 通過編寫腳本來加快搜索過程，該腳本將通過從集中式服務器運行的一個命令來搜索多個服務器。 工程師可以告訴腳本要搜索的郵件服務器類型（入站 smtp，出站 smtp，后端郵箱）。 該腳本將在/ etc / hosts 中查找該類型的服務器列表，然后遍歷每個服務器，執行 ssh，執行 grep，然后輸出結果。 該腳本過去也可以通過“ gunzip -c /var/log/maillog.* | grep”進行搜索。 問題：支持技術人員仍必須向工程師升級故障單才能執行搜索 。 隨著客戶和服務器數量的增加，這開始占用了我們工程師的稀缺時間。 另外，在活動服務器上存儲和搜索日志會對服務器的性能產生負面影響。 更糟的是，工程團隊不斷壯大，我們開始遇到問題，兩名工程師將同時執行搜索，這實際上使事情變慢了。 ### 記錄 v2.0 我們發布了一個日志搜索工具，支持技術人員可以直接使用它，而無需工程師參與。 支持團隊使用了基于 Web 的工具，可以在其中搜索日志。 它允許按發件人或收件人的電子郵件地址，域名或 IP 地址進行搜索。 所有這些都是 MySQL 數據庫中的索引字段。 不允許使用通配符文本搜索（即 MySQL“ LIKE”語句），因為數據集非常大，而且這些查詢的速度非常慢。 每天的日志都存儲在一個單獨的表中，因此我們可以通過簡單地刪除并重新創建 MySQL 表來清除舊數據。 與在大表上運行條件 DELETE 命令相比，這確實使清除工作非常快。 日志數據僅保留了 3 天，以使 MySQL 數據庫減小到合理的大小。 為了使日志進入數據庫，每個郵件服務器最初將其日志數據寫入本地 16MB tempfs 分區。 每 60 秒鐘通過 cron 調用一次 Logrotate 來旋轉臨時日志文件，然后在將數據發送到集中式日志服務器之前對其進行預處理。 此預處理步驟減少了必須通過網絡傳輸到日志服務器的數據量，并且這也分散了處理工作量，以避免在日志服務器上造成瓶頸。 在本地處理數據之后，腳本會將逗號分隔的日志數據發送回本地服務器上的 syslog-ng，然后 syslog-ng 會通過網絡將其發送到集中式日志服務器。 日志服務器配置為在 6 個不同的端口上接收數據，每種類型的日志數據都接收一個端口...入站 smtp，出站 smtp，后端 smtp，垃圾郵件/病毒過濾，POP3 和 IMAP。 接收到日志數據后，將通過 MySQL INSERT 命令將記錄一一插入到數據庫中。 問題：我們很快意識到，MySQL 插入存在瓶頸。 隨著表的增長，對每個條目的索引在插入時變慢。 在測試的最初幾個小時內，插入開始變慢，無法跟上接收數據的速度。 記錄系統的 2.0 版從未在生產中使用過。 ### 記錄 v2.1 通過對集中式日志服務器上本地文本文件中的日志條目進行排隊并定期將其批量加載到數據庫中，解決了 MySQL INSERT 瓶頸。 由于 syslog-ng 在其 6 個端口上接收到日志，因此數據將流式傳輸到 6 個單獨的文本文件中。 每隔 10 分鐘，腳本將輪換這些文本文件并執行 MySQL LOAD，以將數據加載到數據庫中。 這比一次插入一個記錄的日志數據快得多。 問題：隨著數據庫的增長，LOAD 的速度將逐漸變慢，這是因為隨著插入的表變大，MySQL 索引性能會下降。 這個版本的速度足夠快，可以發布到生產中，但是我們知道，如果不進行額外的工作，該系統就不會擴展太多。 ### 記錄 v2.2 引入了合并表，以加快將日志數據加載到數據庫中的速度。 在此版本中，腳本每 10 分鐘會創建一個新的數據庫表，然后將文本日志加載到空表中。 這使得 LOAD 命令非常快，因為沒有現有的數據庫索引可能會對性能產生負面影響。 加載數據后，腳本將修改一組合并表，這些合并表將所有 10 分鐘的表合并在一起。 修改了 Web 搜索工具，以允許在以下時間范圍內進行搜索：全天，過去 12 小時，過去 6 小時，過去 2 小時。 每個時間段都存在對應的合并表，并且在創建新表時每 10 分鐘進行一次修改。 問題：此版本的日志記錄系統可靠運行了大約一年。 但是隨著我們的支持團隊，客戶群和服務器數量的增加，我們開始遇到問題。 當我們到達大約 100 臺服務器時，數據庫 LOAD 操作將需要 2-3 分鐘才能運行，這是可以接受的，但是服務器現在始終處于沉重的 cpu 和磁盤 IO 負載之下。 搜索的執行頻率更高，并且變得越來越慢。 在嘗試創建新表或修改合并表時，我們開始看到一些奇怪的問題，例如隨機錯誤。 這些錯誤逐漸變得更加頻繁，導致丟失日志數據。 支持團隊開始對系統的準確性失去信心。 此外??，在很多情況下，我們的工程師對特定應用程序進行了軟件升級，從而改變了日志格式，從而破壞了預處理腳本。 由于我們的原始日志每 60 秒就會從本地郵件服務器中刪除一次，因此發生這種情況時，我們將無法恢復丟失的日志。 此外，日志搜索工具對于我們支持團隊的日常運營變得越來越重要。 但是，日志系統沒有冗余。 沒有 RAID，沒有備份，沒有故障轉移系統。 對于將日志系統擴展到單個整體服務器之外，我們也沒有一個好的計劃。 使用日志系統逐步修補問題和調整性能會占用大量時間，我們需要更好的東西。 我們需要一種新的解決方案，該解決方案必須快速，可靠并且可以隨著我們的發展無限擴展。 我們需要真正可擴展的東西。 ### 記錄 v3.0 在設計 v3.0 時，我們研究了幾種商業日志處理應用程序。 Splunk 脫穎而出，幾乎完成了我們想要的一切； 但是，我們擔心使用這樣的供應商產品可能會限制我們在將來構建新功能的能力。 例如，我們想要構建一個工具，使我們的客戶可以直接搜索其日志。 自 Apache Hadoop 項目成立以來，我們一直在關注它，其進展和方向給我們留下了深刻的印象。 Hadoop 是 Google File System 和 MapReduce ...的開源實現，該系統是專為大規模分布式數據處理而設計的。 它通過添加服務器并在服務器之間分配數據和 MapReduce 作業來橫向擴展其工作負載。 其他公司已經在使用它進行自己的日志處理。 因此選擇了 Hadoop。 在大約 3 個月的時間內，我們使用 Hadoop，Lucene 和 Solr 構建了全新的日志處理系統。 該系統的描述如下：http://blog.racklabs.com/?p=66 我們相信隨著我們公司的發展，這個新系統將能夠與我們一起擴展。 Hadoop 項目背后有很多動力，這使我們對它的可擴展性將繼續提高充滿信心。 雅虎是該項目的主要貢獻者之一，并已構建了包含數千臺服務器的 Hadoop 集群，并且他們正積極努力使 Hadoop 支持數以萬計的服務器。 問題：迄今為止，我們發現的唯一問題是我們自己的錯誤。 我們會在找到它們后修復它們。 今天我們正在積極運行 v3.0，但我們不會在這里停止。 我們有許多新功能的計劃... ### 未來 目前正在對 3.1 版進行編碼。 它包括支持 Microsoft Exchange 日志處理的新 MapReduce 作業。 （當前，我們僅使用此系統處理值得注意的日志）。 我們計劃在三月上線。 在 4.0 版中，我們計劃將日志搜索工具交到客戶手中，以便他們可以擁有與支持團隊相同的故障排除能力。 這很可能需要重新組織我們存儲日志索引分片的方式，以便按用戶對它們進行分組，而不是讓 Solr 將它們隨機分組。 我們的經銷商對此感到很興奮，因為它可以使他們更好地為客戶提供支持。 誰知道 v4.0 之后會構建什么... ## 相關文章 * [Google 體系結構](http://highscalability.com/google-architecture)* [數據庫人們討厭 MapReduce](http://www.highscalability.com/database-people-hating-mapreduce)* [產品：Hadoop](http://www.highscalability.com/product-hadoop)* [在 Amazon EC2 和 Amazon S3 上運行 Hadoop MapReduce](http://www.highscalability.com/running-hadoop-mapreduce-amazon-ec2-and-amazon-s3)* [Solr](http://lucene.apache.org/solr/) 非常令人印象深刻。 每天在日志文件中有數百演出？！？！？！ 哇，我只能說。 那么，是否有任何關系數據庫可以使用少量機器來處理這種負載？ 還是對 RDBMS 無法處理的數據存在魔術限制？ 致敬 Hadoop 人士！ [http://codershangout.com](http://codershangout.com) 編碼人員可以進行視頻群聊的地方！ “任何 RDBMS 都能做到這一點？” 我會以任何合理的費用加價。 該文章缺少的是，這種 Hadoop 基礎架構在 Rackspace 的構建和運行上花費了多少成本。 總擁有成本（TCO）是真正強大和改變游戲規則的主要因素。 然后要真正回答您的問題，我只是說，不。 我唯一知道的甚至可能是禱告，可能是 Vertica（ [http://www.vertica.com/）](http://www.vertica.com/))但是，Vertica 也不是真正的標準 RDBMS 不知道要花多少錢。 “這使擁有計算機集群的任何人都可以編寫簡單的代碼來快速，可靠地對海量數據集執行任務”（摘自“ Rackspace 的 MapReduce”）。 -任何人 -帶有計算機集群 -簡單的代碼（執行“迅速而可靠”） 哇，這些正是這類 IT 工作/技能，永遠不會外包給其他國家/地區。 感謝您殺死另一個高端利基市場。 這對于大公司/玩家總是很樂于助人（谷歌，ibm 等），而對那些愿意做完全一樣的工作的外包公司也不錯，因為它很容易標準化。 我們不需要你 我們得到了 Apache Foundation。 晚安。 如果您的工作安全依賴于您編寫糟糕的，復雜的，整體的軟件，那么您可能應該重新考慮自己的技能。 “絕不會外包給其他國家...” 許多 Hadoop 提交者位于這些國家/地區。 克服你的偏見。 如果您假設如果無法使用 mySQL 和本地磁盤執行此操作，則無法使用數據庫執行此操作，這是完全合乎邏輯的。 幾年前，其他數據庫已解決了上述數據庫問題：分區表，可靠性，禁用索引（按分區）和啟動星型模式。 我很好奇是否有任何工具可以幫助創建報告或進行臨時查詢。 很難想象有必要聘請專門的 map-reduce 開發人員編寫自定義代碼來回答業務問題。 杰瑞 [http://www.databasecolumn.com/2008/01/mapreduce-a-major-step-back.html“](<a rel=) > MapReduce：一些數據庫專家向后退了一步。我不 知道的東西足以使我同意或不同意，但是我仍然認為這是非常有趣的食物。 越來越少的 kkep 每天都會出現，而較老的技術則很快消失 ----- [http://underwaterseaplants.awardspace.com“](<a rel=) >海洋植物 [http://underwaterseaplants.awardspace.com/seagrapes.htm“](<a rel=) >海葡萄... [http://underwaterseaplants.awardspace.com/plantroots.htm”](<a rel=) >植物根 請參見 CloudBase- [http://cloudbase.sourceforge.net'](<a rel="nofollow" href="http://cloudbase.sourceforge.net) > [http://cloudbase.sourceforge.net](http://cloudbase.sourceforge.net) 它是一種基于 Hadoop Map Reduce 架構的數據倉庫系統，允許使用 ANSI SQL 查詢 TB 和 PB 的數據。 它帶有 JDBC 驅動程序，因此可以使用第三方 BI 工具，報告框架直接連接到 CloudBase。 它解決了這場辯論中指出的大多數問題- [http://www.databasecolumn.com/2008/01/mapreduce-a-major-step-back.html'](<a rel="nofollow" href="http://www.databasecolumn.com/2008/01/mapreduce-a-major-step-back.html) > Mapreduce 一個主要步驟 它具有優化的算法來處理聯接，并計劃在下一個版本中支持表索引。 感謝作者和 Rackspace 分享了如此出色的文章。 就像這篇文章一樣，我們還使用 Hadoop（MapReduce，HDFS）和 Lucene / Solr 構建我們的分布式索引和查詢系統。 我們還支持某些 MapReduce 作業的即席查詢。 現在，我們還為應用程序提供了 JDBC / SQL 接口。 在平臺級別，我們還使用 Bigtable（Hypertable 或 HBase）來管理全局索引。 Bigtable 可以解決索引合并的問題并提供全局訪問。 我認為這比分片解決方案更好。 您能否分享在解決方案中使用 Bigtable 的任何想法。