facebook大数据,facebook云计算
脸书实时Hadoop系统 Solrex-杨文博的博客记录了我的生活、技术、思想和梦想。
脸书的实时Hadoop系统2011-07-22
脸书在今年6月的SIGMOD 2011上发表了一篇名为“Apache Hadoop在脸书走向实时”的会议论文(pdf)，其中介绍了脸书用来构建实时HBase系统的独特秘密技术。因为这篇论文提到的应用场景和我弟弟负责的问题域差不多，所以我花时间仔细看了这篇论文。以下是我根据论文内容的一些看法和感受。如有错误，请指正。
这篇长达10页的文章主要内容是脸书在Hadoop系统上的工程实践，而这些工程实践的目标就是题目中指定的——实时。虽然我缺乏开发或使用Hadoop系统的经验，但我认为这并不妨碍我对本文的理解。在我看来，HDFS是GFS，HBase是BigTable。它们的实现可能有所不同，但主要思想应该是相同的。如果你熟悉GFS和BigTable，那么这篇文章也算是GFS和BigTable的“进阶”了。
1.应用场景和需求文章从一些背景介绍开始，主要给出了三种类型的应用场景：脸书消息传递、脸书洞察和脸书度量系统(ODS)。Messaging是脸书的新消息服务，Insight是提供给开发者和网站所有者的数据分析工具，ODS是脸书的内部软件和硬件状态统计系统。这三种应用场景各有特点，但一言以蔽之，都面临着同一个问题：单一或拆分的关系数据库无法满足需求。
基于应用场景的数据特征，脸书抽象出了对存储系统的几个需求。由于描述有些复杂，比如数据中心内的效率和低延迟强一致性语义，这些需求就不一一列举了。与需求相比，更有意思的是它的“非需求”。总共有三个：
容忍单个数据中心内的网络差异。脸书认为，应该从网络硬件层面(冗余设计)而不是软件层面解决这个问题；单个数据中心的停机不会影响服务。脸书认为这种灾难很难发生，所以它愿意接受这种风险。跨数据中心的数据热备服务能力。脸书假设用户数据分布在一个固定的数据中心，可能的响应延迟问题应该通过缓存来解决。从这些“非要求”可以看出，脸书考虑的是更实际的情况，而不是理想的分布式系统，可以借鉴。
根据以上需求和非需求，脸书很自然的给出了选择Apache Hadoop的理由，包括社区的成熟度，Hadoop在一致性、可扩展性、可用性、容错性、读写效率等方面的优势等。这些优势也是有目共睹的。
2.构建HDFSHDFS自己设计的实时分布式文件系统，支持离线MapReduce计算。虽然它在可扩展性和吞吐量方面有很好的表现，但在实时性方面表现不佳。如果想让基于HDFS的HBase有更好的性能，HDFS层的优化是必然的。为了使HDFS成为一个通用的低延迟文件系统，脸书主要做了以下优化。
2.1 NameNode的高可用性——AvatarNodeHDFS NameNode是系统的单点，也就是说挂起NameNode会导致系统不可用。NameNode重新启动时，加载内存快照、应用日志和收集DataNode的数据块信息报告大约需要45分钟。即使使用BackupNode，仍然需要收集数据块信息报告，切换时间可能仍然会超过20分钟。然而，具有实时要求的系统通常要求系统24x7可用。因此，脸书对单点NameNode进行了改进，实现了NameNode的双节点热备，称为AvatarNode，如下图所示：
AvatarNode
简单来说，备份AvatarNode通过NFS读取并回放主AvatarNode的事务日志，保持数据同步，同时接收DataNode的数据块信息报告，保证了主AvatarNode和备份AvatarNode之间的数据间隙尽可能小，使备份avatar node能够快速切换到主节点的角色。备用AvatarNode的角色注册在ZooKeeper中，DataNode可以根据ZooKeeper中的信息判断需要服从哪个AvatarNode。
为了实现热备用AvatarNode的数据同步和易用性，脸书还改进了NameNode事务日志，并部署了DAFS(Distributed Avatar File System)来屏蔽AvatarNode的故障转移，使这些变化对客户端透明。本文并未提及AvatarNode的切换是手动还是自动，但考虑到ZooKeeper的租用机制，自动切换应该不难实现。
2.2 Hadoop RPC兼容性和数据块可用性在前面的系统需求中，提到了故障隔离，而脸书的Hadoop系统部署在单个房间，所以同样的服务必然会使用多个Hadoop系统。为了独立方便的升级系统，客户端自然要兼容不同版本的Hadoop RPC。
尽管HDFS在分配副本块位置时会考虑机架位，但总体而言，它仍然是相当随机的。其实我之前也和同事讨论过类似的问题，是随机分配副本位置，还是用某些组策略来分配。随机分布的优点是简单均衡，缺点是一旦多台机器宕机，副本的随机分布导致所有数据副本丢失的概率很高。使用某种组策略进行分配的好处是，如果同一个组没有发生多次宕机，数据不会丢失，但是一旦同一个组发生多次宕机，就会丢失大量数据。脸书似乎选择了组策略分配的方法，并认为在同一个组中发生多次停机的可能性不大。
但我怀疑这样做是否正确。同一机架或相邻机架中的服务器通常具有相同的上架时间、硬件型号等。所以同时发生的故障事件并不是完全独立的，它们的概率大于理想故障分布情况下的概率。我想这就是为什么脸书最终计划中的一组机器是(2，5)，2个机架和5个服务器。这两种挂架的选择，如果非常谨慎的话，可以尽量避免我所说的情况。但是，一切都要看执行力。如果不了解部署情况而选择机架，可能达不到预期效果。
2.3实时负载的性能优化除了以上改动，脸书还对客户端的RPC进程进行了优化。为RPC添加一个超时机制，加快撤销文件租约的速度(因为我不懂HDFS文件操作，不明白为什么要加快撤销租约的速度)。
另外提到了最重要的一点：地方性！脸书增加了检查文件块是否在本地计算机中的功能，如果在本地计算机中，可以直接读取。不知道是怎么实现的，但我觉得这种做法其实“很黄很暴力”，不知道会不会破坏数据一致性。
2.4 HDFS同步优化和并发读取。为了提高写入性能，脸书允许在不等待同步结束的情况下写入，这看起来也很暴力。不知道会不会影响数据正确性。
为了能够读取最新的数据，脸书允许客户端读取一个未完成的数据文件。如果您读取了正在写入的最后一个块，请重新计算校验和。
3.为实时生产创造了一个糟糕的环境。HBase3.1行级原子性和一致性。尽管HBase已经保证了行级原子性，但是节点停机时间可能会导致最后的更新日志不完整。脸书还不够满意，所以它引入了WALEdit，这是一个日志事务概念，用于确保每个更新日志的完整性。
在一致性方面，HBase似乎可以满足需求。但是，在三个副本同时验证失败，导致数据块不可用的情况下，脸书增加了后分析的机制，而不是简单地丢弃它们。
3.2可用性为了提高HBase的可用性，脸书对其进行了完美的测试，解决了以下问题：
重写HBase Master，并将分区分配信息存储在ZooKeeper中，以确保正确完成停机切换。可以中断压缩以加快RegionServer的正常退出速度，可以实现滚动重启(即逐个升级)，以减少程序升级对服务的影响。down RegionServer的日志拆分功能与主服务器分离，由多个区域服务器进行拆分，以提高区域服务器的恢复效率。这些问题的解决方案是通用的，我认为在不久的将来，它们可能会被纳入Hadoop代码中。
3.3性能优化性能优化主要从两个方面进行，一是压缩性能，二是读取性能。
读过BigTable论文的人应该熟悉它的memtable和compaction特性。本文主要讨论让次要压缩删除数据的优点，以及如何进行主要压缩来提高合并的性能。
在数据读取性能方面，本文主要讨论了减少IO操作的方法，包括bloom filter和使用特定类型的元信息(时间戳)。在部署中保持RegionServer和物理文件的本地性也非常重要！
文章还介绍了脸书在部署和运行维护方面的一些经验，其中有一些有趣的地方。以后可能会写文章讨论他们，这里就不细说了。
4.总结之前我们也讨论了如何构建一个基于分布式文件系统的实时数据分析系统。当时我们认为，如果有一个成熟的GFS，这个工作会更简单。当我读到这篇关于脸书的文章时，我意识到最初想法的天真。从本文技术点所反映的工作量来看，说这个系统是多年持续工作的结晶是有说服力的。当然，这也意味着要复制这样的体系并不容易。
从系统设计的结果来看，这个系统应该可以满足文章开头设定的需求，也可以满足大部分应用场景的需求。然而，我怀疑的一点是洞察的实时分析功能。实时很好，但是HBase的分析支持有多好呢？你可能需要多了解HBase的功能才能有答案。
从这个系统的许多细节中，我们可以发现有许多妥协和诡计。我觉得这才是真实的世界。任何事情都很难做到完美，工程也是如此。设计系统的时候追求完美没有错，但是你需要考虑成本和可行性。不要忘记满足需求是最重要的目标。另外，列出一些“非要求”也是可取的。消除这些限制可以大大降低系统的复杂性。
