Hadoop 1.x不使用Zookeeper。即使在Hadoop 1.x安装中,HBase确实使用zookeeper。
Hadoop从2.0版本开始采用Zookeeper。
Zookeeper的目的是集群管理。这符合使用较小的专用组件的* nix的一般理念 - 因此,希望集群功能的Hadoop组件依赖于Zookeeper而不是开发自己的组件。
Zookeeper是一个分布式存储,提供以下保证(从中复制) Zookeeper概述页面 ):
你可以用这些来实现不同的“ 食谱 “这是集群管理所需要的,如锁,领导者选举等。
如果你打算自己使用ZooKeeper,我建议你看一下 来自Netflix的策展人 这使它更容易使用(例如,他们实现了一些开箱即用的食谱)
从 动物园管理员 文档页面:
ZooKeeper是一种集中式服务,用于维护配置信息,命名,提供分布式同步和提供组服务。所有这些类型的服务都以分布式应用程序的某种形式使用。 每次实施它们都需要做很多工作来修复不可避免的错误和竞争条件。由于难以实现这些类型的服务,应用程序最初通常会吝啬它们,这使得它们在变化的情况下变得脆弱并且难以管理。即使正确完成,这些服务的不同实现也会在部署应用程序时导致管理复杂性。
ZooKeeper是一种集中式服务,用于维护配置信息,命名,提供分布式同步和提供组服务。所有这些类型的服务都以分布式应用程序的某种形式使用。
每次实施它们都需要做很多工作来修复不可避免的错误和竞争条件。由于难以实现这些类型的服务,应用程序最初通常会吝啬它们,这使得它们在变化的情况下变得脆弱并且难以管理。即使正确完成,这些服务的不同实现也会在部署应用程序时导致管理复杂性。
从 Hadoop的 文档页面:
阿帕奇? Hadoop的?该项目开发了用于可靠,可扩展,分布式计算的开源软件。 Apache Hadoop软件库是一个框架,允许使用简单的编程模型跨计算机集群分布式处理大型数据集
阿帕奇? Hadoop的?该项目开发了用于可靠,可扩展,分布式计算的开源软件。
Apache Hadoop软件库是一个框架,允许使用简单的编程模型跨计算机集群分布式处理大型数据集
关于你的查询:
为什么我们需要Hadoop Stack中的ZooKeeper?
绑定因子是分布式处理和高可用性。
例如Hadoop Namenode故障转移过程。
Hadoop高可用性是围绕Active Namenode& amp;用于故障转移过程的备用Namenode。在任何时候,您不应该同时拥有两个主服务器(活动名称节点)。
从Apache文档链接开始 HDFSHighAvailabilityWithQJM :
对于HA群集的正确操作而言,一次只有一个NameNode处于活动状态至关重要。否则,命名空间状态将在两者之间快速分歧,冒着数据丢失或其他不正确结果的风险。为了确保这个属性并防止所谓的“大脑”情景,JournalJournalNodes只允许一个NameNode一次成为一个作家。 在故障转移期间,要激活的NameNode将简单地接管写入JournalNodes的角色,这将有效地阻止其他NameNode继续处于Active状态,从而允许新的Active安全地进行故障转移。
对于HA群集的正确操作而言,一次只有一个NameNode处于活动状态至关重要。否则,命名空间状态将在两者之间快速分歧,冒着数据丢失或其他不正确结果的风险。为了确保这个属性并防止所谓的“大脑”情景,JournalJournalNodes只允许一个NameNode一次成为一个作家。
在故障转移期间,要激活的NameNode将简单地接管写入JournalNodes的角色,这将有效地阻止其他NameNode继续处于Active状态,从而允许新的Active安全地进行故障转移。
Zookeeper已被用于避免分裂 - 大脑情景。你可以在下面的问题中找到Zookeeper的角色:
Hadoop Namenode故障转移过程如何工作?
Zookeeper解决了可靠的分布式协调问题,而hadoop是一个分布式系统,对吧?
有一篇优秀的论文 Paxos算法 你可以阅读这个主题。