分散处理 Hadoop架构服务器角色分工

2019-03-28 13:42|来源: 网络

  在 Hadoop运算集群架构中,先分解任务,分工处理再汇总结果这些服务器依据用途可分成Master节点和Worker节点,Master负责分配任务,而Worker负责执行任务,如负责分派任务的操作,角色就像是Master节点。

   Hadoop架构服务器角色分工

  Hadoop运算集群中的服务器依用途分成Master节点和Worker节点。Master节点中安装了JobTracker、NameNode、TaskTracker和DataNode程序,但Worker节点只安装TaskTracker和DataNode。
分散处理 Hadoop架构服务器角色分工


  另外在系统的运行架构上,最简单的Hadoop架构,可以分成上层的MapReduce运算层以及下层的HDFS数据层。

  在Master节点的服务器中会执行两套程序,一个是负责安排MapReduce运算层任务的JobTracker,以及负责管理HDFS数据层的NameNode程序。而在Worker节点的服务器中也有两套程序,接受JobTracker指挥,负责执行运算层任务的是TaskTracker程序,而与NameNode对应的则是DataNode程序,负责执行数据读写动作,以及执行NameNode的副本策略。

  在MapReduce运算层上,担任Master节点的服务器负责分配运算任务, Master节点上的JobTracker程序会将 Map和Reduce程序的执行工作,指派给Worker服务器上的TaskTracker程序,由TaskTracker负责执行Map和Reduce工作,并将运算结果回复给Master节点上的JobTracker。

  在HDFS数据层上,NameNode负责管理和维护HDFS的名称空间、并且控制文件的任何读写操作,同时NameNode会将要处理的数据切割成一个个文件区块(Block),每个区块是64MB,例如1GB的数据就会切割成16个文件区块。NameNode还会决定每一份文件区块要建立几个副本,一般来说,一个文件区块总共会复制成3份,并且会分散储存到3个不同Worker服务器的DataNode程序中管理,只要其中任何一份文件区块遗失或损坏,NameNode会自动寻找位于其他DataNode上的副本来回复,维持3份的副本策略。

  在一套Hadoop集群中,分配MapReduce任务的JobTracker只有1个,而TaskTracker可以有很多个。同样地,负责管理HDFS文件系统的NameNode也只有一个,和JobTracker同样位于Master节点中,而DataNode可以有很多个。

  不过,Master节点中除了有JobTracker和NameNode以外,也会有TaskTracker和DataNode程序,也就是说Master节点的服务器,也可以在本地端扮演Worker角色的工作。

  在部署上,因为Hadoop采用Java开发,所以Master服务器除了安装操作系统如Linux之外,还要安装Java运行环境,然后再安装Master需要的程序,包括了NameNode、JobTracker和DataNode与TaskTracker。而在Worker服务器上,则只需安装Linux、Java环境、DataNode和TaskTracker。

更多Hadoop相关信息见Hadoop 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=13

相关问答

更多
  • 如果你的应用程序将循环已知的次数(即你确定它将在一段时间内完成),你可以增加循环内的时间限制: foreach ($data as $row) { set_time_limit(10); // do your stuff here } 此解决方案将保护您免于进行一次失控迭代,但只要您需要,它将让您的整个脚本不受干扰地运行。 If you have an application that is going to loop a known number of times (i.e. you a ...
  • 我建议你研究一个名为Web of trust的模型。 它被例如PGP用于分散认证。 这句话总结得很好: 随着时间的推移,您将积累来自其他人的密钥,您可能希望将其指定为可信赖的介绍人。 每个人都会选择自己值得信赖的介绍人。 每个人都会逐渐积累并用他们的钥匙分发来自其他人的一系列认证签名,期望任何接收它的人都会信任至少一个或两个签名。 这将导致所有公钥出现分散的容错信任网。 I suggest you look into a model called Web of trust. It's used by for ...
  • 它就像电子邮件,但有更多的图形处理堆栈(如下)。 It's like email but with more of a graph-processing stack (following).
  • 使用Firebase设备组消息传递 ,您可以创建设备组并在其中注册所有设备令牌,然后使用下面的JSON有效负载将下游消息发送到客户端应用程序 。 https://fcm.googleapis.com/fcm/send Content-Type:application/json Authorization:key=AIzaSyZ-1u...0GBYzPu7Udno5aA { "to": "aUniqueKey", "data": { "hello": "This is a Fireb ...
  • 不确定它对你有帮助,但是在[UIImage setFrame:]之后我遇到了同样的问题,如果转换了UIImage,决定是使用setBounds而不是setFrame 在评论中解决讨论中的问题: 如果autoresizesSubviews属性为YES,则在shouldAutorotateToInterfaceOrientation中的viewDidLoad之后调用方法setFrame - (void)viewDidLoad { [super viewDidLoad]; self.view.autoresize ...
  • 我不知道你的分布式系统的背景是什么,但是已经建立了共识算法(例如Raft,Paxos,Viewstamped Replication等),它们处理从集群中添加和删除服务器而不影响已提交的事件。 通常,在多数人提交事件之前,您不会应用事件,特别是因为(如您所述)某些应用事件将具有外部可见性(例如,您从ATM机器中释放500美元)。 因此,为了使服务器应用事件,它必须知道事件已经提交。 此外,当将服务器添加到系统时,必须使它们与已提交的事件保持同步, 并且它们可能不会选择不同的值 。 如果他们可以选择不同的值, ...
  • 警告:我没有一个明确的解决方案,但只是一些观察和建议如何调试[基于多年编写/调试Linux设备驱动程序的经验]。 我认为你认为回调没有完成,因为你没有得到任何printk消息。 但是,回调是唯一拥有它们的地方。 但是,printk级别设置得足够高以查看消息吗? 我将一个dev_info添加到你的模块init,以证明它按预期打印。 此外,如果dma_start没有按预期工作,你[可能]将不会得到回调,所以我也会在那里添加一些dev_info调用(例如,在步骤7中调用之前和之后)。 我还注意到并非所有调用dma ...
  • 我偏爱Git,但我相信这个理论适用于大多数其他系统...... 分散式VCS旨在通过在每次提交中保持指向前一次提交的指针来处理分支和合并作为其DNA的一部分,因此任何更改都可以追溯到共同的祖先。 修订“数字”本身并不用于指代提交。 显然,如果是这种情况,将会有多个序列...在Git的情况下,唯一标识任何提交的指针“key”是SHA1哈希。 使整个排列顺序的唯一因素是引用每个提交的父级的指针图。 在实践中,开发人员将他们的工作提交给他们自己的本地副本,当他们与其他人共享时,他们会以三种方式这样做: 请其他开发 ...
  • 删除scatter-gather消息处理器周围的async范围,这确实为您进行了并行化,因此您不必这样做。 编辑 :还删除处理MULE_CORRELATION属性的set-property消息处理器。 scatter-gather应该为你做到这一点。 编辑2 :您可以删除单个flow-ref周围的processor-chain :它没用。 此外,似乎对scatter-gather作用存在深刻的误解:你强行使其子流响应汇聚到一个Join-Flow ,在那里聚合东西,有效地绕过并重新实现scatter-gath ...
  • 您的设置和分散原则上是可以的。 你的问题出在打印上,因为你误解了散点/聚集的细节。 当散布4元素数组时,每个进程只获得一个元素(正如您使用MPI_Scatter call()的第2和第5个参数定义的MPI_Scatter call() )。 此元素存储在本地数组的0索引中。 它实际上是一个标量。 通常,您可能会分散非常大的数组,并且每个进程可能仍然需要处理大型本地数组。 在这些情况下,必须正确计算全球指数和当地指数 。 假设存在以下玩具问题:您希望将数组[1 2 3 4 5 6]分散到两个进程。 Proc0 ...