规划Hadoop集群_从硬件到版本

字数 11267阅读 8029评论 0赞 2

编写：胡旻    版权所有 Hadoop是一个免费开源的分布式存储和计算平台。它被用来实现在商用硬件上以集群模式存储和计算海量数据。在过去的几年中，Hadoop成为了大数据项目的实时标准。接下来我们要讨论几个主题1.选择和规划Hadoop集群的硬件2.Hadoop版本的选取3.Hadoop集群操作系统的选择 作为一个Hadoop管理员或架构师，集群实现的实战部分从决定需要使用哪一种硬件，以及需要的硬件数量开始。但是在这之前有一些必要的问题需要得到解答。这些问题中有集群设计相关的，像集群需要存储多少的数据，数据的增长率是多少，主要的数据访问模式是什么，集群是不是用于预定的任务调度，是不是一个用于数据分析探索的多用户环境？Hadoop的架构和数据访问模型允许极大的灵活性。它可以容纳不同类型的工作负载，就像大量数据的批处理过程，或者，借助Impala支持准实时分析。 同时，一些集群为了更好的用于专门的特定工作，需要在硬件方面专门的考虑一些因数。当规划使用数百台服务器的时候，关于硬件的初始决定和总体布局将会极大的影响集群的性能、稳定性和相关费用。Hadoop硬件的选择Hadoop是一个用于大规模数据处理的可扩展非共享集群系统。Hadoop的整个概念是：单节点不在整个集群的性能和可靠性方面起重要的作用。这个理念假设单节点只用于处理整个集群数据中很小的一部分，因此不需要在硬件层面考虑过多的可靠性和冗余性。总所周知，组成Hadoop集群的服务器有很多种类型。比如主控节点，如NameNode，Secondary NameNode和JobTracker；工作节点被称为DataNodes；除了核心的Hadoop组件服务器，通常我们会部署一些辅助服务器，如网关(Gateways)、Hue服务器以及Hive元服务器。<a class="example-image-link" href="/home/attachment/201507/4/58961_1435996734yRCu.png" data-image-size="548,370" data-lightbox="example-set"><img class="example-image" src="/home/attachment/201507/4/58961_1435996734yRCu.png" data-image-size="548,370" alt="aa.png" ></a> 因为这些类型的服务器在集群中的角色不同，所以对于硬件规格和可靠性的要求也不同。接下来我们会讨论DataNode、NameNode、Jobtracker不同节点的不同硬件需求和选择。DataNode硬件的选择DataNode是Hadoop集群中主要的工作节点，它承担两种角色：一将数据存储在HDFS文件系统上；二执行MapReduce任务。DataNode是Hadoop主要的存储和计算资源。大家可能认为因为DataNode节点在集群发挥这么重要的作用，你应该给他们最好的硬件。这其实不完全正确，Hadoop设计理念是基于DataNode是“临时工”，DataNode服务器是作为集群的一个组成部分能够足够快的去做些有用的工作，但是如果宕机只需付出很小的代价就可以替换。在一个大型集群中频繁的硬件故障，是一个Hadoop内核开发人员要重点考虑的问题。Hadoop解决这个问题的方法是将冗余机制从硬件做到软件。 注：Hadoop在很多层面提供冗余。每一个DataNode存储一些文件，以block的形式存放在HDFS上，这些block复制多份到不同的节点上。因此当一个服务器发生故障，数据任然可以访问。集群甚至可以容忍多个节点故障，这依赖与你选择的设置。配置中可以让你指定服务器和所在的RACK，我们可以将副本放在不同的RACK上，这增强了即使整个RACK出现故障，数据仍然可访问。这种设计意味着没有必要将RAID卡控制器引入Hadoop的DataNode(注：但是现实情况没有那么乐观，服务器在很多时候是需要有RAID支持的) 与在本地磁盘使用RAID不同，我们选择JBOD(一组磁盘序列)作为配置中更好的选择。这种方式提供了Hadoop在工作负载和reduces硬件消耗方面更好的性能。你不用担心单块磁盘的失效，因为HDFS提供数据块的冗余。 存储数据是DataNode的一种角色，第二种角色是作为数据处理节点，执行定制化的MapReduce代码。MapReduce的任务会切分成很多的独立子任务，这些子任务会在多个DataNode上并行的执行。任务的完成依赖于所有子任务的完成。 这就意味着Hadoop不仅仅在存储方面的冗余，也是在计算层面的冗余。Hadoop会尝试在不同的节点上运行失败的子任务。而不中断整个任务。它也会跟踪那些故障率很高的节点或响应很慢的节点，将他们加入黑名单。从集群中移除。 那么典型的数据节点硬件应该是怎么样的呢？DataNode应该在合理的磁盘存储和处理能力上寻求平衡。说道平衡和合理的存储容量，并不是一个简单的任务。有很多的因素会影响最佳Hadoop集群的构建。一个最重要的考虑是整个集群的存储能力和集群的存储密度。这些参数是紧密相关的。整个集群的存储能力是简单的估计。这需要回答一些问题，如我们能把多少数据装入集群。下面是一系列步骤让你可以用来估计你的集群需要的容量。 1.确定数据源：列出所有已知的数据源，确定数据源是否需要全量还是部分导入。我们需要扩大至少15-20%的容量预估值。为的是应对一些未考虑到的数据量规模增长。 2.估计数据的增长率每一个确定的数据源将有一个数据的增量。例如，如果你计划每日从你的OLTP数据库中导入数据，你可以很容易的预估你每周、每月、每年你数据的导入量，为了得到相对正确的数字，你还需要做一些导入测试。 3.将你估算的存储需求乘上复制因子到目前为止，我们谈论的是使用的数据空间，Hadoop会在HDFS层面通过拷贝数据块多份数和把这些数据块放在集群不同的节点上，以形成冗余。默认情况下，每个数据块会复制3份。当然你可以通过修改复制因子，达到增加或减少这个复制份数参数的目的。将复制因子设置为1完全减少了集群的稳定性，所以不应该使用。因此为了得到原始的集群存储能力的估计，你需要乘以复制因子。如果你估计当年需要300TB的使用空间，并且你计划使用的复制因子是3，那么你需要的原始存储能力需要达到900TB。 4.考虑MapReduce临时文件和系统数据的影响MapReduce 任务执行过程中从Map阶段到Reduce阶段会产生一些中间数据。这些中间数据不是存在HDFS上的。但是你需要为临时文件预留整个服务器磁盘容量25-30%的空间。此外，你需要为操作系统预留些磁盘空间。操作系统对于存储的需要通常是很很小的。所以确定整个的使用空间和集群实际存储容量是确定DataNode硬件规格存储特征的第一步。为了进一步讨论，当我们涉及集群总的可用存储时指的是集群的原始容量。因为这对硬件选择非常重要。另外一个重要的指标就是存储密度，指的是整个集群的存储容量由多少台DataNode服务器来承担（密度=总存储容量/服务器数量）。一般情况，你有两个选择：一个是部署很多的存储容量小的机器形成低密度存储集群；另一个是使用较少的容量大的机器形成高密度存储集群。接下来我们会讨论两种选择的利弊。 低密度存储集群从历史上来看，Hadoop集群部署在合理的低密度存储的服务器上，那时候使得可以利用市场上低能力的硬件驱动器将集群扩展到PB级别。虽然在过去几年硬件驱动器能力得到了显著的增强。使用大规模低密度集群仍然是应对很多场景的有效手段。成本是你决定是否要进行此种选择的一个重要原因。对于决定单台Hadoop节点性能的不光是存储容量，还有内存/CPU和磁盘之间的平衡。每个DataNode拥有很多的存储,却没有处理所有数据的足够内存和CPU资源，在很多的集群中也无法达到一个理想的结果。给出一个Hadoop集群推荐的硬件配置通常是一件很难的工作。一个平衡的方案不仅依赖于集群的负载也依赖于分配的预算。市场上新的硬件会不断的更新，所以任何的考虑会根据情况做些调整。我们将使用如下的例子来说明低密度集群的硬件的选择方式：假设我们选择一个拥有6个硬盘插槽的服务器。我们选择合理价格的2TB的硬盘，这将给我们带来每台服务器12TB的存储能力。 注：这里几乎没有理由为你的集群选择15000转速的硬盘，对于Hadoop集群来说顺序的读写对性能比起随机读写性能影响因子更大。在大多数的方案和应用中7200转的硬盘是更好的选择。对于一个低密度的服务器，我们的目标和选择依据是保持单台服务器的低成本，以保证其能承担大量的机器。2路4核的CPU满足这种需求并且能给出合理的处理速度。可以设置每一个map或reduce任务利用到一个CPU的核。当然我们配置的时候也可以超过CPU的核，比如我们有8个核可用，我们能为每个节点设置12map或reduce槽位，只是一些时间将会消耗在IO等待上。每一个任务需要2到4G的内存，所以对这种服务器来说36G内存大小是一个合理的选择，48G的内存是一个理想选择。注意到我们试着去平衡不同的组件，对于增加单台机器的内存容量没有太大的意义，因为不会有足够多的任务只分布在一个节点上执行。让我们来看看，假如你计划在你的集群中存储500TB的数据。默认复制因子是3，这将导致1500TB的存储容量需求。如果采用低密度数据节点的方案。我们需要125台服务器来满足需求。如果你的存储容量需求扩大一倍，你会需要在你的集群中增加100多台(125)服务器。管理这么多服务器本身就将面临很多的挑战。你需要思考在你的数据中心有没有足够的空间能摆放足够的机架，另外电能的消耗和空调制冷也是服务器增加的一个重要挑战。为了解决这些问题，你可以增加单台服务器的存储容量，也可以选择其他规格的硬件。高密度存储集群很多的公司在通过提升单台机器的存储和计算能力来寻找构建小集群的方案。这种方案除了可以解决上面第密度存储集群遇到的问题外，还更好的适合工作负载，解决工作负载的效果比满足大量的存储的效果更好。这种工作负载是计算密集型的操作，包括机器学习、数据探索分析和其它的一些问题。选择高密度组件平衡的理由和低密度组件相似，作为这种配置的一个例子，我们选择16*2T的硬盘服务器和24*1TB的硬盘服务器。每台拥有更多更低容量的磁盘更好，因为这将提供更好的IO吞吐量和更好的容错能力。为了增加每台机器的计算能力，我们选择16核CPU和96GB的内存。 NameNode和JobTracker(Resource Manager)的硬件选择Hadoop实现了一个中心协调模型。其中有一个(或一组)特别的节点，这些节点作用是用来协调集群中的服务器中的任务。其中负责HDFS协调服务的称为NameNode；负责MapReduce任务分发协调的称为JobTracker。实际上NameNode和JobTracker只是一些独立的Hadoop进程，但是由于他们在整个集群中的重要性，这些服务需要运行在特定的机器上。 NameNode节点的硬件选择NameNode对于HDFS的可用性来说至关重要，其存储了文件系统中所有的元数据，哪一个文件由那个数据块组成，这些数据块分分布在哪些DataNode中，有多少可用的数据块，这些数据块在哪些主机上。如果没有NameNode，HDFS上的数据将变得完全不可用。的确数据还都在那，但是没有NameNode你将无法从数据块中重构文件，你也没有办法上传数据，很长一段时间，NameNode都是一个单点故障，这对于一个线上的生产系统来说是必须解决的问题。在Hadoop2.0的时候这个问题得到解决，但是对于NameNode和DataNode相比硬件需求仍然是比较特殊，让我们从NameNode的内存估算开始。NameNode会存储所有的HDFS的元数据信息，包括文件、目录结构和数据块的位置，这些信息都会驻留在内存中。这看上去好像是对内存的一个极大的浪费。但是NameNode必须保证在成百上千的机器上的一个快速的文件访问。所以使用硬盘来存储需要访问的这些信息将会变得很慢。根据Apache Hadoop的文档，每个HDFS的数据块将会占用大约250个字节的内存。加上每个文件和目录将会占用250个字节。让我们假设你要存放5000个文件，平均每个文件大小是20GB，如果你使用默认的HDFS数据块大小64MB并且复制因子是3。那么你的NameNode将需要维系近5百万的数据块，这需要近1.5GB的内存(数据块占用的内存+文件系统占用的内存)。这可能和你像想的不一样，但在很多的实际情况中，集群中会存放更多的文件，而且每一个文件至少会占用一个Block。所以在NameNode中内存的消耗量会更大。这里对主控节点中的内存并没有限制，所以原则上是越大越好。一般来说64-96GB的内存对于主控节点来说是一个很好的选择。 为了保证文件系统元数据的持久性，NameNode必须要在硬盘上保持一份内存结构的拷贝，为此，主控节点维护一个editlog的文件，用来记录在HDFS上所有的改变。如新目录文件的创立以及复制因子的改变。这个和关系型数据库中的redo日志文件很像。除了editlog外NameNode还维系着当前HDFS元数据的一个完整镜像，以fsimage文件存在。每次发生重启、服务器宕机、NameNode都会加载使用最新的fsimage文件，并且加载editlog中，文件系统变化的一系列操作。和传统的数据库不同，NameNode分配周期性的任务，并利用一个称之为Secondary NameNode的单独服务来将editlog和fsimage文件进行合并转换。这样做的目的是控制editlog文件的大小。因为一些改变已经应用合并到fsimage了，不在需要在editlog文件中存在，这也可以缩短恢复时间。因为这些文件是镜像NameNode保留在内存中的数据结构，所以他们对硬盘大小的需求很低。Fsimage不会增长到超过你能分配的内存。并且默认情况下editlog到达64M就会触发NameNode对editlog和fsimage的合并。这意味着你可以将NameNode的磁盘需求控制在500GB的范围。对于NameNode上使用RAID是非常有意义的。因为其提供了对数据的重要保护措施。NameNode除了提供HDFS客户端对文件系统的访问请求外，也会接收处理来自集群中每一个DataNode的心跳信息。这种类型的工作负载需要较强的CPU资源。所以对于NameNode提供8-16核CPU是一个好的配置，但具体还依赖于整个集群的规模大小。 JobTracker(ResourceManager)硬件选择除了NameNode和Secondary NameNode外，另外一个在Hadoop集群中的主控节点我们称为JobTracker或ResourceManager，从概念上说，JobTracker对于MapReduce框架的地位和NameNode对于HDFS的地位相当。JobTracker负责将提交的任务分配给TaskTracker，TaskTracker服务也运行在每台DataNode上。TaskTracker也会周期性的将心跳信息送给JobTracker。报告当前任务的运行状态，可用的map/Reduce槽位数，等等。除此之外，JobTracker在内存中保存一个执行任务历史清单。所以内存的可用性对于JobTracker来说是非常重要的，通常来说JobTracker的内存要比NameNode小。24-48GB的内存对于一个中等规模集群来说是合理的。如果你的集群承担多用途、多租户环境，那么需要重新考虑这个数值，默认配置下，Jobtracker不保存任何状态信息到磁盘上，只是会对一些日志进行持久化存储。这意味着这种服务对于磁盘的需求是很小的。和NameNode一样，JobTracker需要处理大量的TaskTracker发出的心跳信息。接收和分发用户任务，也会负责将调度算法的使用，使得集群的更加有效。这些任务是CPU密集型的。所以确认你采用的CPU是快速的多核处理器，和你选择NameNode的CPU类似。所提到的三种类型的主控节点对于Hadoop集群的可用性来说是非常重要的。如果你没有NameNode服务，你将无法访问HDFS上的数据、如果没有SecondNameNode，不会导立刻的影响，但会延长文件系统的检查进程。类似的，没有JobTracker服务将导致所有运行的MapRTeduce任务失败，并且没有新的任务运行。所有这些都会影响控制节点的硬件选择，使之与我们讨论的DataNoe的不同。对于主控节点，对于控制节点的重要数据使用RAID，冗余的网络和双电源支持以及高级别的企业级硬盘组件来说是一个理想的选择。 网关和其它附属服务器的硬件选择网关服务器是客户登入Hadoop集群的入口。和HDFS上的数据交互，关系到客户端程序和所有集群中的节点。这不是从网络设计和安全视角下的网关(这里其实是链接外部和集群之间的一种桥梁，可以理解为接口机)。网关经常部署在集群外用来作为数据的导入和运行其它的用户程序。其它的设备组件可以部署在独立的服务器或者和其它服务部署在一起。对于这些服务器的硬件需求相对集群中节点的配置来说可以低很多。并且你可以将其部署在虚机上。对于网关服务器通常4-8核，16-24GB的内存。 网络硬件选择在Hadoop集群中，网络是一个和CPU、磁盘、内存同等重要的部件。HDFS需要依赖网络通信，在NameNode上更新当前文件系统的状态。也要接受和发送数据块到客户端。MapReduce任务也使用网络传递状态信息。如果出现下列一些情况，还将需要额外的带宽。如执行任务的TaskTracker需要的数据块不在本地，以及Map阶段产生的中间数据传递给Reduce的过程，等等。总之在Hadoop集群中会出现很多的网络活动。对于网络硬件的选择有两个主要的需考虑的因素。千兆网络是很便宜的，但却是限制了整个的吞吐量。万兆网络又将极大增加大规模集群的部署成本。像集群中的其它组件选择一样。网络的选择也依赖与集群的用途。对于很大的集群，我么一般采用低密度机器，即每个节点拥有少量的磁盘、内存和CPU。通过机器的数目来提供足够的容量。对于小集群，我们选择高密度机器，对于这两种情况，我们可以用同样的思维来选择不同的网络架构。一方面，对于由多个低密度机器组成的集群，配置万兆网卡基本上没有太大的意义，这会增加整体的集群搭建成本。比如，每个数据节点配备6个硬盘，你需要达到420MB的本地写的带宽。这比网络带宽低。这意味着集群的瓶颈会从网络能力转移到磁盘的IO能力。另一方面，拥有高密度服务器组成的小集群，使用千兆的网卡可能会限制其能力，使得很多其它资源使用的浪费。因为这样集群小的原因，万兆网卡的成本对于预算来说不会带来特别大的影响。注：当前大多数的服务器都配备网络控制器。你可以使用绑定(bonding)的方式增加网络的带宽。 Hadoop硬件总结让我们总结下对不同类型集群的硬件需求：低存储密度集群的DataNode(每台)配置参考<table> <tbody><tr> <td> 硬件 </td> <td> 描述 </td> </tr> <tr> <td> 存储 </td> <td> 2个600GB SAS盘RAID1，做系统 6-8个2TB硬盘，做数据JBOD安装，无RAID </td> </tr> <tr> <td> CPU </td> <td> 8核CPU </td> </tr> <tr> <td> RAM </td> <td> 32-48GB </td> </tr> <tr> <td> Network </td> <td> 千兆网卡，做双网卡绑定能合理的提高带宽 </td> </tr></tbody></table>高存储密度集群的 DataNode(每台)配置参考<table> <tbody><tr> <td> 硬件 </td> <td> 描述 </td> </tr> <tr> <td> 存储 </td> <td> 2个600GB SAS盘RAID1，做系统 16-24个1TB硬盘，做数据JBOD安装，无RAID </td> </tr> <tr> <td> CPU </td> <td> 16核 </td> </tr> <tr> <td> RAM </td> <td> 64-96GB </td> </tr> <tr> <td> 网络 </td> <td> 万兆网卡 </td> </tr></tbody></table>NameNode集群配置(Active/Standby)<table> <tbody><tr> <td> 硬件 </td> <td> 描述 </td> </tr> <tr> <td> 存储 </td> <td> 小容量硬盘，600G RAID10或RAID5 用于存放fsimage和editlog。如果有网络存储可以作为这些文件的备份 </td> </tr> <tr> <td> CPU </td> <td> 8-16核，取决于集群的大小 </td> </tr> <tr> <td> 内存 </td> <td> 64-96GB </td> </tr> <tr> <td> 网络 </td> <td> 千兆或万兆接口，做双网卡绑定能合理的提高带宽 </td> </tr></tbody></table>JobTracker<table> <tbody><tr> <td> 硬件 </td> <td> 描述 </td> </tr> <tr> <td> 存储 </td> <td> 小容量硬盘，600GB应该可以应付大部分的情况 </td> </tr> <tr> <td> CPU </td> <td> 8-16核，取决于集群的大小 </td> </tr> <tr> <td> 内存 </td> <td> 64-96GB </td> </tr> <tr> <td> 网络 </td> <td> 千兆或万兆接口，做双网卡绑定能合理的提高带宽 </td> </tr></tbody></table> Hadoop版本选择Hadoop有很多的版本，当前有很多的公司都有自己的发型版。接下来介绍下这个领域的几个主要的公司和他们的发行版从软件版本的角度来看，有很多不同的Hadoop版本，这些版本拥有不同的稳定性，和不同的特征，如当前可以获取的0.23、1.0和2.0。值得注意的是高的版本不总是包含低版本的全部特性。例如：对于0.23版本包含了NameNode的HA和Federation特性，但是却没有了对MapReduce(MRv1)的支持，而是用YARN框架(MRv2)来替换了。在API层面，MRv2是和MRv1是兼容的，但是进程的启动和设置以及概念是不一样的，Hadoop版本V1.0包含了MRv1模块，但是缺乏NameNode的HA和Federation特征。如果直接用于生产系统被认为是有风险的。Hadoop版本V2.0是基于0.23,并且和0.23拥有相同的特征集， 但是需要不断的开发和完善。对于Hadoop版本非连续上升的逻辑的一个解释是Hadoop任然是一种较新的技术，用户对其的很多功能期待很高，比如YARN，这将会导致很多的分支的产生，结果会导致不同的分支拥有不同的稳定性，会带来用户对版本选择的一些困惑。对于规划将Hadoop用于生产环境，我们会应该注于稳定的Hadoop版本，提供一些成熟的组件如MRv1，也会包含一些NameNode重要的可用性等特征，注意到这些会让我们缩小选择的范围。 Apache的Hadoop版本并不是唯一的版本，有很多的公司也在专注做自己的发行版，最流行的非Apache的Hadoop发行版是Cloudera公司的Hadoop版本，也就是CDH。 ClouderaHadoop发行版Cloudera是一家为Hadoop提供商业支持，专业服务和高级工具的公司。他们的CDH发行版是开源免费的。遵循Apache2.0。CDH对于用户来说没有很多的分支版本，版本号是连续的，而且有较好的兼容性，当前CDH的版本是CDH5，具有Apache2.0和1.0的特点。包括NameNode HA和Federation，同时支持MRv1和MRv2。这是当前Apache版本不具备的。CDH的另一个特点是CDH集成了不同的Hadoop生态系统项目，HDFS和MapReduce曾是Hadoop的核心组件，而在此之上出现了越来越多的组件。这些组件使得Hadoop使用起来更加友好，缩短了开发周期。使得编写MapReduce任务更加简单。这里要提及下CDH中的Impala项目，这个项目可以完全绕过MapReduce层，直接从HDFS上获取数据，来对Hadoop进行实时的查询，CDH解决了Hadoop生态系统中众多组件的依赖。提供了大多数生态圈的组件。解决了组件之间的兼容性。这一点对用户来说选择CDH是一个很大的优势，也使得CDH变得如此受欢迎，为了辅助CDH，Cloudera发布了一个基于web的管理工具Cloudera Manager，用于规划、配置和监控Hadoop集群，Cloudera Manager拥有免费版本和付费企业版本。 HortonworksHadoop发行版另外一个流行的Hadoop版本是Horonworks出品的Horonworks Data Platform(HDP)，和Cloudera类似，Horonworks提供了一个一体化安装版本，并提供商业支持和服务。提供HDP1.2和2.0。其中HDP1.2提供了一些其它发行版不具备的特性，Horonworks在Hadoop1.0的基础上实现了NameNode的HA(注：这种HA利用Linux HA技术，而不是使用JournalNode)，HDP包含了HCatalog，用来提供Pig和Hive这样项目的一个整合服务。为了吸引用户，Horonworks很注意和传统BI结合。HDP为Hive提供了ODBC驱动。使得可以喝大多数存在的BI工具做个适配。HDP的另外一个特点是可以运行在windows平台，不过这个稳定性还在测试中。HDP利用Ambari来做集群的管理和监控。Ambari是一个类似Cloudera Manager的Web端工具。不同的是100%完全免费和开源。MapR发行版除了Cloudera和Hortoworks外MapR也是一家提供基于Hadoop平台的公司。它们产品拥有不同的版本。M3是一个具有功能限制的免费版本，M5和M7是企业版。和Cloudera和Hortoworks不同MapR提供的软件都是不是免费的。但是提供了一些企业级的特征，MapR和Apache Hadoop的主要区别在于MapR没有使用HDFS而是使用MapR-FS文件系统。MapR-FS是用C++实现比起Java写的HDFS提供低延时和高并发度。虽然在API方面兼容，但是完全是不同的实现。除此之外，MapR-FS提供了NFS卷、集群快照和集群监控等能力，这些能力都是基于MapR-FS实现的。 正如你看到的，在Hadoop领域我们有很多可以选择的，对于用于生产环境的Hadoop，我们可以缩小我们的选择范围，用于生产的Hadoop版本需要稳定并且通过测试。需要包含重要的组件，如NameNode HA和提供对MRv1计算框架的支持。对于一个Hadoop的管理员，Hadoop节点的方便的自动部署是需要考虑的。而且不需要太担心组件之间的兼容性。于是CDH和HDP是值得考虑和进一步了解的。 为Hadoop集群选择操作系统相对而言，为你要部署的Hadoop集群选择操作系统是一件简单的任务，Hadoop内核和生态系统中的部分的组件是Java写的。因为Java代码本身是跨平台的，所以理论上可以运行在各种操作系统上，当前Hadoop建议部署在Linux系统上，这是因为在Hadoop的设计过程中借鉴了很多Linux的设计思路，使得Hadoop和其组件的很多代码如：start/stop脚本及权限模型都依赖于Linux的环境。对于Linux的发行版来说，Hadoop一视同仁，并没有针对特定的发行版采用不同的代码实现，所以对于Linux 的操作系统如Red Hat、CentOS、Debian、Ubuntu、Suse和Fedora。都可以较好的运行Hadoop。更一般的来说，Hadoop是可以很好的支持符合POSIX的OS，如Solaris和BSD。我们只要考虑处理好相关的依赖和对应的shell脚本都能运行就可以了。目前大多数的生产系统都将Linux作为运行Hadoop的首选操作系统，CentOS和Red Hat是生产系统中使用频率最多的两种。

商业智能 Hadoop 规划

著作权归作者所有

如果觉得我的文章对您有用，请点赞。您的支持将鼓励我继续创作！

添加新评论0 条评论

Ctrl+Enter 发表

匿名评论

规划Hadoop集群_从硬件到版本

添加新评论0 条评论

作者其他文章

相关文章

相关问题

相关资料