如何为大数据处理构建高性能Hadoop集群

Posted 2023-04-23

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了如何为大数据处理构建高性能Hadoop集群相关的知识，希望对你有一定的参考价值。

越来越多的企业开始使用Hadoop来对大数据进行处理分析，但Hadoop集群的整体性能却取决于CPU、内存、网络以及存储之间的性能平衡。而在这篇文章中，我们将探讨如何为Hadoop集群构建高性能网络，这是对大数据进行处理分析的关键所在。

　　关于Hadoop

　　“大数据”是松散的数据集合，海量数据的不断增长迫使企业需要通过一种新的方式去管理。大数据是结构化或非结构化的多种数据类型的大集合。而 Hadoop则是Apache发布的软件架构，用以分析PB级的非结构化数据，并将其转换成其他应用程序可管理处理的形式。Hadoop使得对大数据处理成为可能，并能够帮助企业可从客户数据之中发掘新的商机。如果能够进行实时处理或者接近实时处理，那么其将为许多行业的用户提供强大的优势。

　　Hadoop是基于谷歌的MapReduce和分布式文件系统原理而专门设计的，其可在通用的网络和服务器硬件上进行部署，并使之成为计算集群。

　　Hadoop模型

　　Hadoop的工作原理是将一个非常大的数据集切割成一个较小的单元，以能够被查询处理。同一个节点的计算资源用于并行查询处理。当任务处理结束后，其处理结果将被汇总并向用户报告，或者通过业务分析应用程序处理以进行进一步分析或仪表盘显示。

　　为了最大限度地减少处理时间，在此并行架构中，Hadoop“moves jobs to data”，而非像传统模式那样“moving data to jobs”。这就意味着，一旦数据存储在分布式系统之中，在实时搜索、查询或数据挖掘等操作时，如访问本地数据，在数据处理过程中，各节点之间将只有一个本地查询结果，这样可降低运营开支。

　　Hadoop的最大特点在于其内置的并行处理和线性扩展能力，提供对大型数据集查询并生成结果。在结构上，Hadoop主要有两个部分：

　　Hadoop分布式文件系统(HDFS)将数据文件切割成数据块，并将其存储在多个节点之内，以提供容错性和高性能。除了大量的多个节点的聚合I/O，性能通常取决于数据块的大小——如128MB。而传统的Linux系统下的较为典型的数据块大小可能是4KB。

　　MapReduce引擎通过JobTracker节点接受来自客户端的分析工作，采用“分而治之”的方式来将一个较大的任务分解成多个较小的任务，然后分配给各个TaskTrack节点，并采用主站/从站的分布方式(具体如下图所示)：

Hadoop系统有三个主要的功能节点：客户机、主机和从机。客户机将数据文件注入到系统之中，从系统中检索结果，以及通过系统的主机节点提交分析工作等。主机节点有两个基本作用：管理分布式文件系统中各节点以及从机节点的数据存储，以及管理Map/Reduce从机节点的任务跟踪分配和任务处理。数据存储和分析处理的实际性能取决于运行数据节点和任务跟踪器的从机节点性能，而这些从机节点则由各自的主机节点负责沟通和控制。从节点通常有多个数据块，并在作业期间被分配处理多个任务。

　　部署实施Hadoop

　　各个节点硬件的主要要求是市县计算、内存、网络以及存储等四个资源的平衡。目前常用的并被誉为“最佳”的解决方案是采用相对较低成本的旧有硬件，部署足够多的服务器以应对任何可能的故障，并部署一个完整机架的系统。

　　Hadoop模式要求服务器与SAN或者NAS进行直接连接存储(DAS)。采用DAS主要有三个原因，在标准化配置的集群中，节点的缩放数以千计，随着存储系统的成本、低延迟性以及存储容量需求不断提高，简单配置和部署个主要的考虑因素。随着极具成本效益的1TB磁盘的普及，可使大型集群的TB级数据存储在DAS之上。这解决了传统方法利用SAN进行部署极其昂贵的困境，如此多的存储将使得Hadoop和数据存储出现一个令人望而却步的起始成本。有相当大一部分用户的Hadoop部署构建都是采用大容量的DAS服务器，其中数据节点大约1-2TB，名称控制节点大约在1-5TB之间，具体如下图所示：

来源：Brad Hedlund, DELL公司

　　对于大多数的Hadoop部署来说，基础设施的其他影响因素可能还取决于配件，如服务器内置的千兆以太网卡或千兆以太网交换机。上一代的CPU和内存等硬件的选择，可根据符合成本模型的需求，采用匹配数据传输速率要求的千兆以太网接口来构建低成本的解决方案。采用万兆以太网来部署Hadoop也是相当不错的选择。

　　万兆以太网对Hadoop集群的作用

　　千兆以太网的性能是制约Hadoop系统整体性能的一个主要因素。使用较大的数据块大小，例如，如果一个节点发生故障(甚至更糟，整个机架宕机)，那么整个集群就需要对TB级的数据进行恢复，这就有可能会超过千兆以太网所能提供的网络带宽，进而使得整个集群性能下降。在拥有成千上万个节点的大型集群中，当运行某些需要数据节点之间需要进行中间结果再分配的工作负载时，在系统正常运行过程中，某个千兆以太网设备可能会遭遇网络拥堵。

　　每一个Hadoop数据节点的目标都必须实现CPU、内存、存储和网络资源的平衡。如果四者之中的任意一个性能相对较差的话，那么系统的潜在处理能力都有可能遭遇瓶颈。添加更多的CPU和内存组建，将影响存储和网络的平衡，如何使Hadoop集群节点在处理数据时更有效率，减少结果，并在Hadoop集群内添加更多的HDFS存储节点。

　　幸运的是，影响CPU和内存发展的摩尔定律，同样也正影响着存储技术(TB级容量的磁盘)和以太网技术(从千兆向万兆甚至更高)的发展。预先升级系统组件(如多核处理器、每节点5-20TB容量的磁盘，64-128GB内存)，万兆以太网卡和交换机等网络组件是重新平衡资源最合理的选择。万兆以太网将在Hadoop集群证明其价值，高水平的网络利用率将带来效益更高的带宽。下图展示了Hadoop集群与万兆以太网的连接：

许多企业级数据中心已经迁移到10GbE网络，以实现服务器整合和服务器虚拟化。随着越来越多企业开始部署Hadoop，他们发现他们完全不必要大批量部署1U的机架服务器，而是部署更少，但性能更高的服务器，以方便扩展每个数据节点所能运行的任务数量。很多企业选择部署2U或4U的服务器(如戴尔 PowerEdge C2100)，每个节点大约12-16个核心以及24TB存储容量。在这种环境下的合理选择是充分利用已经部署的10GbE设备和Hadoop集群中的 10GbE网卡。

　　在日常的IT环境中构建一个简单的Hadoop集群。可以肯定的是，尽管有很多细节需要微调，但其基础是非常简单的。构建一个计算、存储和网络资源平衡的系统，对项目的成功至关重要。对于拥有密集节点的Hadoop集群而言，万兆以太网能够为计算和存储资源扩展提供与之相匹配的能力，且不会导致系统整体性能下降。参考技术A Hadoop中有很多方法可以加入多个数据集。MapReduce提供了Map端和Reduce端的数据连接。这些连接是非平凡的连接，并且可能会是非常昂贵的操作。Pig和Hive也具有同等的能力来申请连接到多个数据集。Pig提供了复制连接，合并连接和倾斜连接（skewed join），并且Hive提供了map端的连接和完整外部连接来分析数据。

一个重要的事实是，通过使用各种工具，比如MapReduce、Pig和Hive等，数据可以基于它们的内置功能和实际需求来使用它们。至于在Hadoop分析大量数据，Anoop指出，通常，在大数据/Hadoop的世界，一些问题可能并不复杂，并且解决方案也是直截了当的，但面临的挑战是数据量。在这种情况下需要不同的解决办法来解决问题。

一些分析任务是从日志文件中统计明确的ID的数目、在特定的日期范围内改造存储的数据、以及网友排名等。所有这些任务都可以通过Hadoop中的多种工具和技术如MapReduce、Hive、Pig、Giraph和Mahout等来解决。这些工具在自定义例程的帮助下可以灵活地扩展它们的能力。参考技术B 大讲台实战项目最多的Hadoop培训

如何为Hadoop集群选择正确的硬件

温馨提示：要看高清无码套图，请使用手机打开并单击图片放大查看。

当我们想搭建一个Hadoop大数据平台时，碰到的第一个问题就是我们到底该如何选择硬件。

虽然Hadoop被设计为可以运行在标准的X86硬件上，但在选择具体服务器配置的时候其实没那么简单。为已知的工作负载或者应用场景选择硬件时，往往都要综合考虑性能因素和性价比，才能选择合适的硬件。比如，对于IO密集型的工作负载，用户往往需要为每个CPU core匹配更多的存储或更高的吞吐(more spindles per core)。

通过本文，您将学习到如何根据工作负载来选择硬件，包括一些其他您需要考虑的因素。

1.计算和存储

过去的十年，业界基本已经形成了刀片和SANs(Storage Area Networks)的标准，从而满足网格和处理密集型的工作负载。这种模式对于许多标准应用（比如Web服务器，应用服务器，较小的结构化数据和数据搬运）还都是适用的，但是随着数据量和用户数据的增长，基础设施的需求也发生了变化。Web服务器现在已经有了缓存层，数据库借助本地磁盘开始支持海量并发，数据搬运的压力迫使我们需要更多的在本地处理数据。

“很多人在搭建Hadoop集群时都没有去真正了解过工作负载”

硬件供应商更新了对应的产品来满足相应的需求，包括存储刀片，SAS(Serial Attached SCSI)交换机，外挂的SATA阵列和容量更大的机架。然而，Hadoop是基于一个全新的存储和处理数据的方式，尽量避免数据传输。Hadoop通过软件层来实现大数据的处理以及可靠性，而不像一个SAN存储所有数据，如果计算则传输到一系列刀片进行计算。

Hadoop将数据分布式存储在各台服务器上，使用文件副本来保证数据不丢以及容错。这样一个计算请求可以直接分发到存储数据的相应服务器并开始进行本地计算。由于Hadoop集群的每台节点都会存储和处理数据，所以你就需要考虑怎样为集群里的这些服务器选择合适的配置。

2.为什么跟工作负载有关系

在很多情况下，MapReduce/Spark都会遭遇瓶颈，比如从磁盘或者网络读取数据(IO-bound的作业)，或者在CPU处理大量数据时(CPU-bound的作业)。IO-bound的作业的一个例子是排序，一般需要很少的处理（简单的比较）却需要大量的读写磁盘。CPU-bound的作业的一个例子是分类(classification)，一些数据往往需要很复杂的处理。

典型的IO-bound的工作负载如下：

索引(Indexing)
分组(Grouping)
数据导入导出
数据传输和转换

典型的CPU-bound工作负载如下：

聚类和分类(Clustering/Classification)
复杂的文本挖掘
自然语言处理
特征提取

我们需要完全了解工作负载，才能够正确的选择合适的Hadoop硬件。很多人因为从来没有研究过工作负载，往往会导致Hadoop运行的作业是基于不合适的硬件。此外，一些工作负载往往会受到一些其他的限制。比如因为选择了压缩，本应该是IO-bound的工作负载实际却是CPU-bound的，或者因为算法选择不同而使MapReduce或者Spark作业受限。由于这些原因，当您不熟悉未来将要运行的工作负载时，可以选择一些较为均衡的硬件配置来搭建Hadoop集群。

接下来我们就可以在集群中运行一些MapReduce/Spark作业进行基准测试，来分析它们的bound方式。可以通过一些监控工具来确定工作负载的瓶颈。当然Cloudera Manager提供了这个功能，包括CPU，磁盘和网络负载的实时统计信息。通过Cloudera Manager，当集群在运行作业时，系统管理员可以通过dashboard很直观的查看每台机器的性能表现。

“第一步是了解运维部门管理的硬件。”

除了根据工作负载来选择硬件外，还可以与硬件厂商一起了解耗电和散热以节省额外的开支。由于Hadoop是运行在数十，数百甚至数千个节点上，尽可能多的考虑方方面面都可以节省成本。每个硬件厂商都提供了专门的工具来监控耗电和散热，以及如何改良的最佳实践。

3.为CDH集群挑选硬件

在挑选硬件的时候，第一步是了解您的运维部门所管理的硬件类型。运维部门往往倾向于选择他们熟悉的硬件。但是，如果您是在搭建一个新的集群，并且无法准确的预测集群未来的工作负载，我们建议您还是选择适合Hadoop较为均衡的硬件。

一个Hadoop集群通常有4个角色：NameNode（和Standby NameNode），ResourceManager，NodeManager和DataNode。集群中的绝大多数机器同时是NodeManager和DataNode，既用于数据存储，又用于数据处理。

以下是较为通用和主流的NodeManager/DataNode配置：

12-24块1-6TB硬盘， JBOD (Just a Bunch Of Disks)
2 路8核，2路10核，2路12核的CPU, 主频至少2-2.5GHz
64-512GB内存
绑定的万兆网（存储越多，网络吞吐就要求越高）

NameNode负责协调集群上的数据存储，ResourceManager则是负责协调数据处理。Standby NameNode不应该与NameNode在同一台机器，但应该选择与NameNode配置相同的机器。我们建议您为NameNode和ResourceManager选择企业级的服务器，具有冗余电源，以及企业级的RAID1或RAID10磁盘配置。

NameNode需要的内存与集群中存储的数据块成正比。我们常用的计算公式是集群中100万个块(HDFS blocks)对应NameNode的1GB内存。常见的10-50台机器规模的集群，NameNode服务器的内存配置一般选择128GB，NameNode的堆栈一般配置为32GB或更高。另外建议务必配置NameNode和ResourceManager的HA。

以下是NameNode/ResourceManager及其Standby节点的推荐配置。磁盘的数量取决于你想冗余备份元数据的份数。

4–6个1TB的硬盘，JBOD(1个是OS, 2个是NameNode的FS image [RAID 1], 1个配置给Apache ZooKeeper, 还一个是配置给Journal node)
2路6核，2路8核的CPU, 主频至少2-2.5GHz
64-256GB的内存
绑定的万兆网

“记住，Hadoop生态系统的设计需考虑并行环境。”

如果预期你的Hadoop集群未来会超过20台机器，建议集群初始规划就跨两个机架，每个机柜都配置柜顶(TOR,top-of-rack)的10GigE交换机。随着集群规模的扩大，跨越多个机架时，我们在机架之上还要配置冗余的核心交换机，带宽一般为40GigE，用来连接所有机柜的柜顶(TOR)交换机。拥有两个机架，可以让运维团队更好的了解机架内以及跨机架的网络通信需求。Hadoop网络要求可以参考Fayson之前的文章。

当搭建好Hadoop集群后，我们就可以开始识别和整理运行在集群之上的工作负载，并且为这些工作负载准备基准测试，以定位硬件的瓶颈在哪里。经过一段时间的基准测试和监控，我们就可以了解需要如何增加什么样配置的新机器。异构的Hadoop集群是比较常见的，特别是随着数据量和用例数量的增加，集群需要扩容时。所以如果因为前期并不熟悉工作负载，选择了一些较为通用的服务器，也并不是不能接受。Cloudera Manager支持服务器分组，从而使异构集群配置变的很简单。

以下是不同的工作负载的常见机器配置：

Light Processing Configuration，1U的机器，一般为测试，开发或者低要求的场景：2个hex-core CPUs，24-64GB内存，8个磁盘（1TB或者2TB）
Balanced Compute Configuration，均衡或主流的配置，1U/2U的机器：2个hex-core CPUs，48-256GB的内存，12-16块磁盘（1TB-4TB），硬盘为直通挂载
Storage Heavy Configuration，重存储的配置，2U的机器：2个hex-core CPUs，48-128GB的内存，16-24块磁盘（2TB-6TB）。这种配置一旦多个节点或者机架故障，将对网络流量造成很大的压力
Compute Intensive Configuration，计算密集型的配置，2U的机器：2个hex-core CPUs，64-512GB memory,4-8块磁盘（1TB-4TB）

注意：以上2路6核为最低的CPU配置，推荐的CPU选择一般为2路8核，2路10核，2路12核

下图显示如何根据工作负载来选择你的机器：

4.其他注意事项

Hadoop生态系统是一个并行环境的系统。在选择购买处理器时，我们不建议选择主频（GHz）最高的芯片，这样一般都代表了更高电源瓦数（130W+）。因为这会产生两个问题：更高的功率消耗和需要更多的散热。较为均衡的选择是在主频，价格和核数之间做一个平衡。

当存在产生大量中间结果的应用程序 – 输出结果数据与输入数据相当，或者需要较多的网络交换数据时，建议使用绑定的万兆网，而不是单个万兆网口。

当计算对内存要求比较高的场景，请记住，Java最多使用10%的内存来管理虚拟机。建议严格配置Hadoop使用的堆大小的限制，从而避免内存交换到磁盘，因为交换会大大影响计算引擎如MapReduce/Spark的性能。

优化内存通道宽度也同样重要。比如，当使用双通道内存时，每台机器都应配置一对DIMM。使用三通道内存时，每个机器都应该具有三倍的DIMM。同样，四通道DIMM应该被分为四组。

5.Hadoop其他组件的考虑

Hadoop远远不止HDFS和MapReduce/Spark，它是一个全面的数据平台。CDH平台包含了很多Hadoop生态圈的其他组件。我们在做群集规划的时候往往还需要考虑HBase，Impala和Solr等。它们都会运行在DataNode上运行，从而保证数据的本地性。

HBase是一个可靠的，列存储数据库，提供一致的，低延迟的随机读/写访问。Cloudera Search通过Solr实现全文检索，Solr是基于Lucene，CDH很好的集成了Solr Cloud和Apache Tika，从而提供更多的搜索功能。Apache Impala则可以直接运行在HDFS和HBase之上，提供交互式的低延迟SQL查询，避免了数据的移动和转换。

由于GC超时的问题，建议的HBase RegionServer的heap size大小一般为16GB，而不是简单的越大越好。为了保证HBase实时查询的SLA，可以通过Cgroups的的方式给HBase分配专门的静态资源。

Impala是内存计算引擎，有时可以用到集群80%以上的内存资源，因此如果要使用Impala，建议每个节点至少有128GB的内存。当然也可以通过Impala的动态资源池来对查询的内存或用户进行限制。

Cloudera Search在做节点规划时比较有趣，你可以先在一个节点安装Solr，然后装载一些文档，建立索引，并以你期望的方式进行查询。然后继续装载，直到索引建立以及查询响应超过了你的预期，这个时候你就需要考虑扩展了。单个节点Solr的这些数据可以给你提供一些规划时的参考，但不包括复制因子因素。

6.总结

选择并采购Hadoop硬件时需要一些基准测试，应用场景测试或者Poc，以充分了解你所在企业的工作负载情况。但Hadoop集群也支持异构的硬件配置，所以如果在不了解工作负载的情况下，建议选择较为均衡的硬件配置。还需要注意一点，Hadoop平台往往都会使用多种组件，资源的使用情况往往都会不一样，专注于多租户的设计包括安全管理，资源隔离和分配，将会是你成功的关键。

7.参考文档

https://blog.cloudera.com/blog/2013/08/how-to-select-the-right-hardware-for-your-new-hadoop-cluster/

https://my.oschina.net/guol/blog/674310?p=1