介绍Facebook的Hadoop和AvatarNode集群方案

Facebook作为世界知名的社交网站，拥有3亿多活跃用户，其中约300万用户每天至少更新一次状态；用户每月上传10亿多张照片和1000万视频；每周共有10亿条内容，包括日志、链接、新闻、微博等。因此，Facebook需要存储和处理的数据量非常大。每天增加4TB压缩数据，扫描135TB大小数据，在集群中执行7500多项Hive任务，每小时计算8万次。因此，高性能云平台对Facebook非常重要，Facebook主要用于日志处理、推荐系统和数据仓库。Facebook将数据存储在由Hadop/Hive构建的数据仓库中。该数据仓库内核4800个，存储容量5.5PB。每个节点可以存储12TB大小的数据。同时，它还有两层网络拓扑。Facebook将数据存储在由Hadop/Hive构建的数据仓库中。该数据仓库有4800个核心和5.5PB存储容量。每个节点可以存储12TB大小的数据。同时，它还有两层网络拓扑。Facebook中的Mapreduce集群是动态变化的。它可以根据负载和集群节点之间的配置信息动态移动。Facebook数据仓库架构，在这个架构中，网络服务器和内部服务生成日志数据，Facebook使用开源日志收集系统，它可以在NFS服务器上存储数百个日志数据集，但大多数日志数据将复制到同一中心的HDFS实例，HDFS存储的数据将放置在使用Hive构建的数据仓库中。Hive提供类SQL语言，结合Mapreduce，创建并发布各种摘要和报告，并在其基础上进行历史分析。基于浏览器的Hive接口允许用户进行Hive查询。Oracle和MySQL数据库用于发布数据容量相对较小的摘要，但查询频率较高，需要实时响应。一些旧数据需要及时归档并存储在更便宜的存储器上。以下是Facebook在Avatarnode和调度策略方面所做的一些工作。AvatarNode主要用于HDFS的恢复和启动。如果HDFS崩溃，原始技术恢复首先需要10美元～读取12GB的文件镜像并在15分钟内写回，并使用20分钟～处理来自2000个Datanode的数据块报告30分钟，最后使用400分钟～NameNode和部署软件需要60分钟才能恢复崩溃。表3-1显示了Backupnode和Avatarnode的区别，Avatarnode作为普通Namenode启动，处理所有来自Datanode的消息。AvatarDatanode类似于Datanode，支持多线程和多主节点的多队列，但无法区分原始和备份。人工恢复使用Avatarshell命令行工具，Avatarshell执行恢复操作，更新Zookeper的znode，恢复过程对用户来说是透明的。现有文件系统的上层实现了分布式Avatar文件系统。基于位置的调度策略在实际应用中存在一些问题：如果需要高内存的任务可能分配给低内存的TaskTracker;有时候CPU资源没有得到充分利用；也很难配置不同硬件的TaskTracker。Facebook采用基于资源的调度策略，即公平享受调度方法，实时监控系统，收集CPU和内存的使用。调度器将分析实时内存消耗，然后公平分配任务之间的内存消耗。它读/读/读/读proc/目录分析过程树，收集过程树上所有CPU和内存的使用信息，然后在心跳中通过TaskCounters(heartbeat)发送信息。Hive用于Facebook的数据仓库，HDFS支持三种文件格式:文本文件(TextFile)，其他应用程序读写方便；顺序文件(SequenceFile)，只有Hadoop能读取并支持分块压缩；RCFile，根据块的存储方式，每个块按顺序存储，具有良好的压缩率和查询性能。未来Facebook将在Hive上进行改进，以支持索引、视图、子查询等新功能。现在Facebook使用Hadoop面临的挑战有:服务质量和隔离，大任务会影响集群性能；在安全性方面，如何处理软件漏洞导致NameNode事务日志崩溃；数据归档，如何选择归档数据，如何归档数据；性能提升，如何有效解决瓶颈。2004年，Mapreduce创建了Mapreduce，Mapreduce系统成功的原因之一是为编写需要大规模并行处理的代码提供了简单的编程模式。Mapreduce集群可以包括数千台并行操作的计算机。同时，Mapreduce允许程序员在如此庞大的集群中快速转换数据并执行数据。它受到Lisp函数编程特性和其他函数语言的启发。Mapreduce与云计算非常匹配。Mapreduce的关键特点是能够隐藏开发人员并行语义并行编程的具体工作模式。HDFS（HadoopDistributedFilesystem）它是专门为Mapreduce框架下的大规模分布式数据处理而设计的。HDFS可以将大数据集（TB级）存储为单个文件，而大多数文件系统没有这种能力。(编者:NTFS5MaxFilesonVolume：264bytes(16Exabytes)minus1KB，1EB=1，000，000TB)。这也是HDFS风靡全球的一个重要原因。目前，FacebookHadop集群中的HDFS物理磁盘空间承载着100多个PB数据(100多个集群分布在不同的数据中心)。优化HDFS已成为Facebook为用户提供高效可靠的服务的关键因素，因为HDFS存储Hadop应用程序需要处理的数据。HDFSNamenode是如何工作的？HDFS客户端通过被称为Namenode单服务器节点执行文件系统的原始数据操作。同时，Datanode将与其他Datanode进行通信，并复制数据块以实现冗余，使单个Datanode损坏不会导致集群数据丢失。但是NameNode失败的损失是无法容忍的。Namenode的主要职责是跟踪文件如何分割成文件块，文件块存储在哪些节点，分布式文件系统的整体运行状态是否正常。然而，如果NameNode节点停止运行，数据节点将无法通信，客户端将无法向HDFS读取和写入数据。事实上，这也将导致整个系统停止工作。TheHDFSNamenodeisasinglepointoffailure(SPOF)Facebook也知道“Facebook”Namenode-as-SPOF因此，Facebook希望建立一个系统来打破问题的严重性Namenode-as-SPOF"隐患。但在了解这个系统之前，让我们来看看Facebook在使用和部署HDFS时遇到了什么问题。Facebook数据仓库的使用在Facebook数据仓库中部署了最大的HDFS集群。数据仓库的使用是传统的Hadopmapreduce工作负载——由于集群非常大，一小部分Mapreduce批处理操作在大型集群中运行，客户端和许多Datanode节点和Namenode节点传输大量原始数据，这导致NameNode的负载非常重。来自CPU、内存、磁盘和网络带来的压力也使得NameNode在数据仓库集群中的高负载情况屡见不鲜。来自CPU、内存、磁盘和网络带来的压力也使得Namenode在数据仓库集群中的高负载情况屡见不鲜。Facebook在使用过程中发现，HDFS引起的故障占数据仓库总故障率的41%。HDFSNamenode是HDFS的重要组成部分，也是整个数据仓库的重要组成部分。虽然高可用的Namenode只能防止数据仓库10%的计划外停机，但消除Namenode对SPOF来说是一个重大胜利，因为这使得Facebook可以执行预订的硬件和软件回复。事实上，Facebook预计，如果Namenode能够消除集群50%的计划停机。那么高可用性NameNode是什么样子的呢？它将如何工作？让我们来看看高可用性NameNode的图表。在这种结构中，客户端可以与PrimaryNamenode和StandbyNamenode进行通信。同样，许多Datanode也有能力将Blockreports发送给PrimaryNamenode和StandbyNamenode。本质上，Facebook开发的Avatarnode是一种具有高可用性Namenode的解决方案。Avatarnode：为了解决单Namenode节点的设计缺陷，Facebook在大约两年前开始在内部使用Avatarnode。同时，Avatarnode提供了高可用性的Namenode、热故障切换和回滚功能。目前，Facebook已经为开源社区贡献了Avatarnode。AvatarNode经过无数次的测试和bug修复，已经在Facebook最大的Hadoop数据仓库中稳定运行。很大程度上要感谢Facebook工程师Dmytromolkov。发生故障时，AvatarNode的两个高可用NameNode节点可以手动转移故障。AvatarNode将现有的NameNode代码打包并放置在Zookeper层。Avatarnode的基本概念如下：1.拥有PrimaryNamenode和StandbyNamenode2。目前，Master主机名保存在Zokeper中。3.改进后的Datanode将blockeports发送到PrimaryNamenode和StandbyNamenode4。改进后的HDFS客户端将在每件事开始前检查Zokeper，如果失败会转移到另一件事上。同时，如果在写入过程中出现AvatarNode故障转移，AvatarNode机制将允许完整的数据写入。Avatarnode客户端Avatarnodedatanode有人可能会对Facebook的解决方案名称感到好奇，因为FacebokHadop工程师Dhrubabortakur来到公司时，正好是Jamescameron电影《阿凡达》的热播时间。(我们应该很高兴，如果是1998年，也许应该叫TitanicNode)。(我们应该很高兴，如果是1998年，可能叫Titanicnode)。Avatarnode经受住了Facebook内部最恶劣的工作环境，未来Facebook将继续大大提高Avatarnode的可靠性和HDFS集群的管理性。整合与一般高可用性框架的整合，也将实现无人值守、自动化和安全故障转移的特点。Facebook已将自己使用的Hadop和AvatarNode解决方案托管到GitHub。有兴趣的朋友可以下载研究。当然，不仅Facebook试图解决Hadop的缺陷，Mapr和Cloudera的产品也有类似的能力。