| 克服挑战并将基于云的
Hadoop 部署的优势最大化
Hadoop 和云似乎是最佳搭档。它们都包含灵活和分布式的处理与存储，而且都带有一个灵活的实例系统。它们还使您能够根据数据和处理需求来扩大和收缩
Hadoop 集群。但这会引发各种管理与调度问题。本文将了解所有这些问题，并描述基于云的 Hadoop
部署的挑战与优势。
了解云部署的范围
Hadoop 系统是一个用起来颇有挑战性的环境，但由于云环境所具有的限制（与自由），云部署会引入额外的复杂性。
例如，借助云中的 Hadoop，如何处理可变的集群规模与信息的有效分布？如何有效地扩大和收缩云环境，以便应付您期望处理的
Hadoop 负载？如何计划和控制任务与处理，以便在云实例可用时最大限度地利用它们？
根据具体云服务的不同，云部署的优势与劣势会对这些环境中 Hadoop 的使用产生相应的影响。请记住，与公有云相比，私有云服务的约束与限制存在巨大差异。如果使用自己的
VM 环境或诸如 OpenStack 这样的解决方案时，那么您将拥有极大的灵活性来定制服务与功能。
为了让云中的 Hadoop 发挥最大功效，您首先需要了解已经存在的云部署解决方案，以及它们对于
Hadoop 环境有哪些影响。
基于服务的云部署
某些云解决方案完全基于某个特定服务，该服务将会加载并处理数据。例如，借助
IBM Bluemix?，您可以基于 IBM InfoSphere?
BigInsights? 配置一个 MapReduce 服务，该服务可以处理高达
20GB 的信息。但 Hadoop 服务的大小、配置与复杂性是不可配置的。其他基于服务的解决方案也提供同样类别的复杂性。
您必须根据自己的需要来选择或配置服务解决方案的大小，因为您可能无法控制磁盘、I/O、CPU
或 RAM 的可用性。
确定需求的惟一途径就是通过测试。在计算结果上再增加 25% 或更高，以便为使用率最高和最复杂的情况留出余地。
基于（虚拟）机器的云部署
尽管云环境完全基于机器或虚拟机风格的部署，Hadoop 在虚拟环境中的安装方式与在物理机器上极为相似。您可以对可配置参数的范围进行配置，而这些参数会改变您针对集群部署的选择。
每个节点的配置尤其需要认真考虑，包括 CPU、RAM、磁盘容量和磁盘 I/O
速度。尽管优秀的 Hadoop 集群部署可以隐藏节点之间的镜像差异，但在需要标准支持和提高速度与运算能力时，了解配置可以帮助您调整部署的规模。
和所有基于云的系统或安装部署一样，配置取决于以下因素：
CPU
精确的 CPU 计算或任意单元。除非部署的是基于 YARN 的解决方案，否则应考虑为集群内所有的数据与处理节点部署完全相同的配置。这种方法让计算所需的集群规模与容量变得更轻松。针对基于
YARN 的部署，可以将集群内不同节点配置为支持和处理不同级别的 CPU 容量。例如，这种方法可以使用指定项目的特定高性能
CPU 节点组来扩展现有集群。
RAM
所有节点都至少应该拥有 4GB 空间，但此空间的大小可能会受到实际可用空间的限制。此外还要记住，一定要留出一些空间用于文件缓存，这样可以提高性能。有些解决方案（如
HBase）可以使用额外的内存。
存储器容量
确保对操作系统和 Hadoop 存储使用了单独的卷，这种实践可以提高性能并让扩展
HDFS 存储变得更简单。在缩放集群大小之前，应估计要使用的存储容量，并标准化指定的大小。这种方法可确保在整个集群上实现最大程度的平均分布。
磁盘 I/O
HDFS 环境应该限制磁盘 I/O 的暴露，因为所有工作都分布在集群上。然而在没有必要的情况下，不要将磁盘
I/O 限制到节点无法有效访问和处理数据的程度。在众多云环境中，基准或最低的磁盘 I/O 配置可能过低，甚至降低了总体性能。更糟糕的是，如果无法确保磁盘
I/O 速率位于某个特定水平上，那么在处理任务的过程中，可能会遭遇性能下降。
网络 I/O
Hadoop 需要进行大量的网络 I/O 才能完成操作；除了原始写入之外，每个文件都至少被复制两次，而且
MapReduce 操作期间使用的数据都必须采用类似的方式通过网络进行传输。在众多云环境中，网络性能是受限的，这可能成为部署中的一个限制因素。
混合型云部署
在一些混合型云部署中，有些元素是固定的，而其他元素是可变的。在这种情况下，您可以在某些限制下定义特定的机器容量，同时控制节点的总体数量。在这些
Hadoop 云部署中，选择正确的 RAM 与 CPU 组合，然后调整集群，使之满足这种配置。
扩展与收缩 Hadoop 集群
云环境最吸引人的方面之一就是能够扩展和收缩 Hadoop 集群的规模，使之满足将要提交的任务对于负载与存储的要求。在以基于服务架构为基础的云环境中，扩展与收缩通常是通过云服务的控制部分进行管理的。
扩展集群通常很容易，因为通过给现有配置增加更多节点，就可以更加轻松地使用额外的资源。收缩集群困难一些，有可能会导致性能受损和任务中断。
根据您选择的云环境，用于增加或减少 Hadoop 集群规模的具体方法也会有所不同。基于服务的云环境有一些内置的伸缩功能。基于虚拟机的单元需要在集群内进行部署、安装软件和授权。
使用有弹性的 Hadoop 集群
真正有弹性的 Hadoop 集群需要大量的工作与管理。即便是启动云服务，大量增加节点，稍后再删除它们，实际的数据增加与管理工作也会很复杂。
大问题在于，对于要以最高效率处理问题的集群而言，真正需要做的是将数据与工作负载分布到集群上。
此外，还要考虑这些处理所花费的时间。甚至在最理想的情况下，启动每个节点并让它们开始处理工作的过程需要花费
5 到 10 分钟。
收缩规模一直是更为复杂的问题，因为必须避免可能保存同一数据块的所有副本的节点停止运行。为了缩小集群的规模，必须首先执行再次平衡，确定数据被正确存储，而且数据副本分布在余下的节点上，如果需要再次缩小规模，只需重复以上过程即可。
扩展 Hadoop 集群
使用新节点扩展集群是一种常见的需求，过程也很简单。通常，在云环境中增加节点时，新节点的大小与容量与现有节点相同。这种方法有助于未来的容量规划。这条通用规则不适用于以下情形：
1.在您 计划使用更多空间、CPU 或 RAM 容量升级节点时。
2.在集群到达 80% 容量之前扩展集群时。仅在当前容量达到 80% 时才增加节点数量。被动等待扩展集群可能会导致容量不够用。
决定增加更多节点后，实际的过程则十分简单：
向云环境添加新节点。
在每个新节点上安装 Hadoop。（从镜像获取一个预先安装好的节点是最容易的方式。）
在主节点上的 conf/slaves 文件中添加新节点的信息。
启动如 清单 1 中所示的 Hadoop 流程。
清单 1. 启动 Hadoop 流程
$ hadoop-daemon.sh start datanode
$ hadoop-daemon.sh start tasktracker |
不同的 Hadoop 变体可能有不同的步骤，但这些属于基本步骤。您可能还想确保主节点通过检查 dfs.hosts
配置能够正确识别它们。为了检查它们是否被正确识别，可以运行 清单 2 中的代码。
清单 2. 确保 Hadoop 变体被正确识别
$ hadoop mradmin -refreshNodes
$ hadoop dfsadmin -refreshNodes |
这段代码针对 MapReduce 任务处理来设置节点，但没有移动任何现有数据。下一步骤是确保移动文件块。
重新分布已存储的数据块
可以在集群内移动已存储的数据块，以便更好地使用增加的节点，移动的方法有如下几种：
1.将文件复制到不同的目录。这项操作将自动重新分布数据块，因为文件被有效重写到 HDFS 中。这个步骤需要额外的工作，但它可以与工作流同时执行。
2.临时增加复制容量。默认值为 3。将这个值提高到 4 将向集群添加新的数据块副本。将这个值减少为 3
将从某些机器上移除数据块。
3.显式启动一次调整操作：
请记住，启动任意类型的调整操作都需要大量的 I/O 与网络传输，直到调整完成为止。
收缩 Hadoop 集群
收缩 Hadoop 集群时要考虑以下因素：
1.是否能安全地缩小集群规模？ 如果有任务正在运行，在每个节点上运行一次停止运行过程（decommission
process）。此过程将删除节点并以可重新开始的方式停止所有正在运行的任务（使用状态 KILLED_UNCLEAN），这样当下次检查队列并且
JobTracker 重新分配任务时，就可以在可用节点上重新安排任务执行。
2.是否能够在其他节点上释放空间？请记住，缩小集群规模就是减少用于复制数据的计算机数量，并提高剩余节点上的磁盘使用。
注意： 一次停止运行的节点绝不能超过一个。
云环境的魅力在于，可以在 100 个节点的集群中启动 20 个新节点来应对高峰，稍后便可移除它们。这种方法使得集群面临较少的风险，甚至可能完全移除已存储数据的风险。停止运行过程会自动在余下节点中重新分布数据副本。尽管可以减少大的数据块，但这样做会给系统带来很大的负载。但会减少多个数据块中的节点。
停止运行的最安全方法是分阶段完成停止运行过程。例如，如果要移除 20 个节点，每次停止运行 3 到 5
个节点：
将要移除的节点从集群添加到 dfs.hosts.exclude 设置。
运行 dfs 刷新来更新节点列表：
$ hadoop dfsadmin -refreshNodes |
刷新 MapReduce 配置：
$ hadoop mradmin -refreshNodes |
节点现在被标记为已停止运行。在节点最终停止运行并安全移除机器之前，要将数据副本复制到其他集群中的其他主机。
现在，对每个额外的数据块重复这些步骤。通常，此过程花费的时间要长于扩展过程，但它消除了数据丢失的风险。
升级节点配置
云环境的主要优势之一是可以灵活地修改单独节点配置，甚至可以根据需要完全更新和替换节点。您可以分阶段地完成这些修改，将前面描述的扩展和收缩过程合二为一。您甚至可以将这个过程作为针对特定任务的计划扩展与收缩过程的一个组成部分。
例如，要将 20 个数据节点从 4 CPU 系统变为 8 CPU 系统，可以执行以下步骤：
添加 4 个具有新配置的新节点。
将它们添加到配置。
启动服务。
执行调整。
从旧配置停止运行 4 个数据节点
重复这些步骤。
结果是获得了一个首先通过添加新配置节点进行扩展，然后通过移除旧配置节点进行收缩的集群。
任务调度与分布
根据任务调度需要确定扩展与收缩集群的时间，以及处理该过程所需的容量大小。
借助云模型，您有时可以使用多个单独的集群代替一个大型集群，从中获得一些优势。您可以根据数据复杂性和集群规模来调度工作。例如，一个较大的处理任务可能需要更多的节点，但需要的存储较少，而其他任务可能需要更多的存储，但需要的处理节点较少。
在云中进行处理时，尝试在最大化集群配置的同时不扩展或增加集群规模。很多工具都能做到这一点，包括基本的任务调度和使用复杂的工作流，比如
IBM InfoSphere BigInsights 中的应用程序管理器和 Oozie。我们的目标是在不增加成本的情况下让集群获得最大性能，并确保不会让集群过载到无法轻松扩展或恢复的程度。
应对存储与负载高峰
最复杂的过程很可能是了解如何应对突如其来的存储与负载高峰。根据部署环境，可用的选择可能有很大差异。对于您可以改变的一些因素，当您意识到集群已经超出容量时，您会怎样做？
显著的观点是从一开始就尝试避免这个特定问题。您可能希望时刻关注容量，并确保留出 20% 到 30% 的容量来处理工作。运行容量超过
80% 时会带来一些麻烦。
确定需求
首先确定是否需要增加磁盘或 MapReduce 容量。这二者具有不同的属性。二者的做法均是为了添加更多的节点，添加更多的节点通常可以解决问题，但其代价可能是不必要的。
如果问题是在存储上，那么可以考虑给现有节点增加更多的存储设备。有些云环境能够在不重新引导或修改系统的情况下提供这个选项。在这种情况下，可以将
dfs.datanode.data.dir 配置更新为包含新挂载的目录。这个选项始终比使用新节点扩展集群要快得多，也容易得多。
如果属于长期问题，则应该考虑 增加节点和使用拥有更大容量的节点替换一些现有的节点。从长远角度看，这是一项值得的投资，因为这样做可以防止在未来面临高峰时出现更多的问题。
如果需要 CPU 能力，但是只愿意等待存储需求而不愿意进行调整，那么可以添加新的节点，安装 Hadoop，然后启动数据节点与任务跟踪器过程，但不执行任何调整。
确定是否能通过足够快地扩展（和收缩）来达到效果
如果与任务的计划长度相比，高峰期较短，那么可能不值得添加节点，因为创建新主机所花费的时间比处理任务还要长。
尽管不存在通用规则，但要牢记，云部署或许能够将节点容量提高 10%，甚至是 100%，但以完全线性的方式来看它可能不会提高性能，特别是在云环境中。
如果任务的预计运行时间是 6 小时，而您可以在不到一小时内将集群的规模有效提高 50%，那么扩展集群是值得的。
当高峰结束时是否也能够及时收缩？
考虑高峰结束时收缩规模所需的时间长短。收缩需要花费额外的时间来完成停止运行过程，并将数据块重新分布到集群的余下节点上。图
1 显示了同一任务在 10 个节点上运行，然后在更多节点上运行的大约时间，其中包括向集群添加节点和让节点停止运行的时间，所有时间的测量单位均为小时。
图 1. 同一任务在 10 个节点上运行的大约时间
从这张图中可以看出，增加 5 个节点很快，将集群规模扩展三倍很简单，但在节点停止运行时额外花费了 2.5
小时的时间。此过程最终仅节省了一个小时，但成本却变为原来的三倍。
结束语
在云中部署 Hadoop 需要了解云环境的限制，并能够根据需要动态地扩展和收缩集群规模的优点。但灵活的特性不代表没有缺陷。因此，有效的
Hadoop 部署需要您了解运行任务，以及扩展和收缩过程所需的时间长短，从而将云中任务执行的时间缩至最短。
|
