# 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 的任何想法。