英语原文共 10 页，剩余内容已隐藏，支付完成后下载完整资料
Apache Hadoop在Facebook实时运行
摘要
Facebook最近部署了Facebook信息,它是第一次将面向用户的应用程序建立在Apache Hadoop的平台上。Apache HBase是作为一个数据库的层次建立在Hadoop上的，用来支持每天数十亿的消息。本文介绍了Facebook选择Hadoop和HBase与其他系统如Apache Cassandra和Voldemort的原因，并讨论了应用程序对一致性，可用性，分区容限，数据模型和可伸缩性的要求。 我们探索了对Hadoop的增强，使其成为一个更有效的实时系统，我们在配置系统时做出的权衡，以及这个解决方案如何在Facebook和其他网络规模的其他应用程序中使用的分片MySQL数据库方案有显着的优势公司。 我们讨论我们的设计选择背后的动机，我们在日常运营中面临的挑战，以及未来的功能和改进仍在开发中。 我们将这些观察结果作为其他公司的模型，这些公司正在考虑一种基于Hadoop的解决方案，而不是传统的分片式RDBMS部署。
类别和主题描述符
[信息系统]：其他。
一般术语
管理、测量、性能、分布式系统、设计、可靠性、语言。
关键词
数据、可伸缩性、资源共享、分布式文件系统、Hadoop、Hive、HBase、Facebook、Scribe、日志聚合、分布式系统。
允许为个人或课堂教学使用全部或部分此作品或者制作数据，无需付费，但前提是开发的应用不是为了制造利润或商业利益而制作或分发，且应用需要带有此通知和第一页上的完整引文 。 要以其他方式复制或重新发布，在服务器上发布或重新发布到列表，需要事先获得特定许可和/或收费。
SIGMOD rsquo;11, June 12–16, 2011, Athens, Greece.
Copyright 2011 ACM 978-1-4503-0661-4/11/06...$10.00.
1.简介
Apache Hadoop [1]是一个顶级的Apache项目，包括分布式文件系统[2]和MapReduce的开源实现，它们受到Google的GFS [5]和MapReduce [6]项目的启发。 Hadoop生态系统还包括像Apache HBase [4]这样的项目，它是由Google的BigTable，Apache Hive [3]，一个建立在Hadoop之上的数据仓库和Apache ZooKeeper [8]的灵感，一个分布式系统的协调服务。
在Facebook，Hadoop传统上与Hive结合使用，用于存储和分析大型数据集。 大多数分析发生在离线批处理作业中，并且重点在于最大化吞吐量和效率。 这些工作负载通常从磁盘顺序读取和写入大量数据。 因此，通过提供对HDFS的低延迟访问，不太重视为随机访问工作负载提供Hadoop性能。 相反，我们使用了大型MySQL数据库集群和使用memcached [9]构建的缓存层的组合。 在许多情况下，Hadoop的结果会上传到MySQL或memcached中供Web层使用。
最近，在Facebook上产生了新一代应用，其需要非常高的写吞吐量和便宜和弹性的存储，同时需要低延迟和磁盘高效的顺序和随机读取性能。 MySQL存储引擎被证明并具有非常好的随机读取性能，但通常遭受低随机写入吞吐量。 难以快速扩展我们的MySQL集群，同时保持良好的负载平衡和高正常运行时间。 MySQL集群的管理需要相对较高的管理开销，并且它们通常使用更昂贵的硬件。 鉴于我们对HDFS的可靠性和可扩展性的高度信心，我们开始探索Hadoop和HBase这样的应用程序。
第一组应用程序需要实时并发，但顺序，读取访问存储在HDFS中的非常大的实时数据流。 生成和存储这样的数据的示例系统是Scribe [10]，一种由Facebook创建并广泛使用的开源分布式日志聚合服务。 以前，Scribe生成的数据存储在昂贵且难以管理的NFS服务器中。 属于此类别的两个主要应用程序是实时分析[11]和MySQL备份。 我们已经增强了HDFS，成为一个高性能低延迟文件系统，并已能够减少我们使用昂贵的文件服务器。
第二代非MapReduce Hadoop应用程序需要动态索引快速增长的数据集以进行快速随机查找。 这样的应用程序的一个主要的例子是Facebook Messages [12]。 Facebook消息给每个Facebook用户一个facebook.com电子邮件地址，集成了一对或一组用户之间的所有电子邮件，短信和聊天消息的显示，有强大的控制谁从谁接收消息，并且是 社交收件箱。 此外，这个新的应用程序必须适合在发布后立即由5亿多人进行生产使用，并且需要扩展到许多PB级数据，并具有严格的正常运行时间要求。 我们决定在这个项目中使用HBase。 HBase反过来利用HDFS的可扩展和容错存储和ZooKeeper分布式共识。
在下面的章节中，我们更详细地介绍了一些新的应用程序，以及为什么我们决定使用Hadoop和HBase作为这些项目的通用基础技术。 我们描述了对HDFS和HBase的具体改进，以便能够扩展到Facebook的工作负载和操作注意事项以及在生产环境中使用这些系统的最佳做法。 最后，我们讨论这些项目中的持续和未来工作。
2.工作负载类型
在决定一个特定的软件栈和是否要摆脱我们基于MySQL的架构之前，我们研究了一些特定的应用程序，其中现有的解决方案可能有问题。 这些用例将具有难以扩展的工作负载，因为写入吞吐量非常高，大量数据集，不可预测的增长或在分片式RDBMS环境中可能很难或不是最佳的其他模式。
2.1 Facebook消息
最新一代的Facebook Messaging将现有的Facebook消息与电子邮件，聊天和短信相结合。除了保持所有这些消息之外，新的线程模型还需要为每个参与用户存储消息。作为应用服务器要求的一部分，每个用户将粘附到单个数据中心。
2.1.1高写吞吐量
由于每天有数百万条消息和数十亿条即时消息的现有速率，因此从第一天开始，摄取数据量将非常大，并且只会继续增长。非正规化的要求将进一步增加对系统的写入次数，因为每个消息可以被写入若干次。
2.1.2大表
作为产品要求的一部分，除非用户明确地这样做，否则消息不会被删除，因此每个邮箱将无限增长。正如大多数消息传递应用程序中的典型情况一样，消息只在最近几次读取时才会被读取，然后很少再次查看。因此，绝大多数不会从数据库读取，但必须始终可用并且具有低延迟，因此归档将是困难的。存储用户的所有成千上万条消息意味着我们将有一个数据库模式，由用户用不断增长的线程和消息列表索引。使用这种类型的随机写入工作负载，随着表中的行数增加，写入性能通常会在像MySQL这样的系统中降低。新消息的绝对数量也意味着沉重的写入工作负载，这可能转换为在这种类型的系统中的大量随机IO操作。
2.1.3数据迁移
新的Messaging产品最具挑战性的一个方面是新的数据模型。这意味着所有现有用户的消息都需要操作和加入新的线程范例，然后迁移。能够执行大型扫描，随机访问和快速批量导入将有助于减少将用户迁移到新系统所花费的时间。
2.2 Facebook Insights
Facebook Insights为开发者和网站所有者提供了与社交插件，Facebook页面和Facebook广告的网站的Facebook活动相关的实时分析。使用匿名数据，Facebook表面活动，如展示次数，点击率和网站访问。这些分析可以帮助每个人从企业到博客获得有关人们如何与他们的内容进行交互的洞察，以便他们可以优化他们的服务。
域和URL分析以前是通过我们的Hadoop和Hive数据仓库以定期的离线方式生成的。然而，这产生了差的用户体验，因为数据仅在其发生几小时之后才可用。
2.2.1实时分析
洞察小组希望在用户操作数秒内（而不是之前支持的时间段）向用户提供统计信息。这将需要大规模的异步排队系统，用于用户操作以及处理，聚合和持久化这些事件的系统。所有这些系统都需要是容错的，并且每秒支持超过一百万个事件。
2.2.2高吞吐量增量
为了支持现有的洞察功能，时间和基于人口统计的聚合是必要的。然而，这些聚合必须保持最新，并因此通过数字计数器一次处理一次，一次一个事件。拥有数百万个独特的聚合和数十亿事件，这意味着大量的计数器，甚至更多的操作对他们。
2.3 Facebook度量系统（ODS）
在Facebook，所有硬件和软件将统计信息导入称为ODS（操作数据存储）的度量收集系统。例如，我们可能会收集给定服务器或服务器层上的CPU使用量，或者我们可能会跟踪到HBase集群的写入操作数。对于每个节点或节点组，我们跟踪数百或数千个不同的度量，工程师将要求在不同粒度上绘制它们随时间的变化。虽然这个应用程序对写吞吐量有很高的要求，但是现有的基于MySQL的系统的一些更大的困难在于数据的重新分布以及对表扫描进行分析和时间累加的能力。
2.3.1自动分片
大量的索引和时间序列写入和不可预测的增长模式很难在一个分片的MySQL设置上进行协调。例如，给定产品可以仅在长时间段内收集十个度量，但是在大量推出或产品发布之后，相同的产品可以产生数千个度量。使用现有系统，单个MySQL服务器可能会突然处理比它可以处理的负载更多的负载，迫使团队手动将数据从此服务器重新分片到多个服务器上。
2.3.2最近数据和表扫描的快速读取
对指标系统的大多数读取都是针对最近的原始数据，但是所有历史数据也必须可用。最近写入的数据应该快速可用，但是整个数据集也将被周期性地扫描以执行基于时间的汇总。
3. 为什么是HADOOP和HBASE
上述工作负载对存储系统的要求可以总结如下（无特定顺序）：
1.弹性：我们需要能够以最小的开销和无停机时间向存储系统添加增量容量。在某些情况下，我们可能希望快速添加容量，系统应该在新硬件之间自动平衡负载和利用率。
2.高写吞吐量：大多数应用程序存储（并且可选地索引）大量的数据，并且需要高的聚合写吞吐量。
3.数据中心内高效和低延迟的强一致性语义：有一些重要的应用程序，如在数据中心内需要强一致性的消息。这个要求通常直接来自用户期望。例如，主页上显示的“未读”消息计数和收件箱页面视图中显示的消息应该彼此一致。虽然全球分布的强一致性系统实际上是不可能的，但是至少在数据中心内提供强一致性的系统将使得提供良好的用户体验成为可能。我们还知道（与其他Facebook应用程序不同），消息易于联合，以便特定用户可以完全从单个数据中心提供服务，从而在单个数据中心内实现强一致性，这是Messages项目的关键要求。类似地，其他项目，如实时日志聚合，可以完全部署在一个数据中心内，如果系统提供强一致性保证，则更容易编程。
4.从磁盘进行有效的随机读取：尽管在Facebook规模上广泛使用应用级缓存（无论是嵌入还是通过memcached），但是大量访问错过了缓存并命中后端存储系统。 MySQL在从磁盘执行随机读取时非常有效，任何新系统都必须具有可比性。
5.高可用性和灾难恢复：我们需要为涵盖计划和计划外事件的用户提供非常高的正常运行时间的服务（前者的例子是软件升级和添加硬件/容量的事件，后者例如失败硬件组件）。我们还需要能够容忍数据中心的丢失，并且最小的数据丢失，并且能够在合理的时间框架内从另一个数据中心提供数据。
6.故障隔离：我们在运行大型农场的MySQL数据库的长期经验告诉我们，故障隔离至关重要。个人数据库可以并且确实下降，但只有一小部分用户受到任何此类事件的影响。类似地，在我们的Hadoop的仓库使用中，单个磁盘故障仅影响一小部分数据，并且系统从这些故障中快速恢复。
7.原子读 - 修改 - 写原语：原子增量和比较和交换API在构建无锁并发应用程序中非常有用，并且是底层存储系统必须具有的。
8.范围扫描：几个应用程序需要高效检索特定范围内的一组行。例如，给定用户的所有最近100条消息或给定广告客户过去24小时内的每小时展示次数。
还值得指出的是非要求：
1.单个数据中心内网络分区的容差：不同的系统组件通常固有地集中。例如，MySQL服务器可以全部位于几个机架内，并且数据中心内的网络分区将导致其中的服务能力的主要损失。因此，通过具有高度冗余的网络设计，做出了在硬件级别上消除这种事件的可能性的每一努力。
2.个别数据中心故障时的零停机：根据我们的经验，这种故障是非常罕见的，虽然并非不可能。在一个不太理想的世界里，系统设计的选择归结于可接受的妥协选择，这是我们愿意作出的一个妥协，因为这种事件的发生率很低。
3.跨不同数据中心的主动 - 主动服务能力：如前所述，我们很容易做出假设，即用户数据可以跨不同数据中心联合（基于用户位置）。延迟（当用户和数据局部性不匹配时）可以通过使用靠近用户的应用程序缓存来屏蔽。一些不太明显的因素也在工作。拥有现有的Facebook生产经验和内部专业知识的系统非常受欢迎。当考虑开源项目时，社区的力量是一个重要因素。考虑到建设和维护系统的工程投资水平，选择一个广泛适用的解决方案（而不是基于不同的架构和每个工作负载的代码库）。
经过大量的研究和实验，我们选择Hadoop和HBase作为这些下一代应用的基础存储技术。该决定是基于HBase在评估时的状态，以及我们对通过内部
剩余内容已隐藏，支付完成后下载完整资料
资料编号：[137593]，资料为PDF文档或Word文档，PDF文档可免费转换为Word
以上是毕业论文外文翻译，课题毕业论文、任务书、文献综述、开题报告、程序设计、图纸设计等资料可联系客服协助查找。
