1、高端计算集群上用于遥感数据处理的云计算摘要Hadoop 是一种分布式文件系统和 MapReduce 架构最初由谷歌为搜索应用而开发并随后作为一种开源系统被 Apache 基金会采纳。我们认为这种并行计算架构十分适合于一些列针对科学应用的服务，特别是，遥感系统的卫星数据处理。我们表明，通过运行于一组 IBM PowerPC 刀片服务器组成的集群上的 Hadoop 系统，我们可以高效处理多年遥感数据，相比于现有的多处理器计算方法，期待看到速度方面的改进，并有更多的内存有效利用，以允许更精细的网格划分。此外，这些改进可以不用重大的编码结构改变而得到。1.简介云计算最初被 Google 提出并随后被
2、Apache 基金会按照开源软件提供为 Hadoop是基于一种并行编程范例 MapReduce，它采用分布式文件系统在极大规模的低端处理器（例如，很可能是上千个或更多处理器）集群上实现，目的是基于文本的搜索。程序员们利用这种软件系统的众多优点之一是,它提供了一种简单并行编程结构的同时使得所有数据的管理和移动操作变得自动化。这篇论文的目的是探索当实现于高端计算集群时，Hadoop MapReduce 并行编程范例处理更广泛领域的科学数据处理问题的可能性。我们描述了多核计算中心刀片计算集群，和在基于 Section 2.0 的 JS20 刀片服务器的 IBM PowerPC 集群上 Hadoop
3、的安装。在这篇论文中我们选择了遥感领域需要需对卫星观测数据特别处理的科学应用。该应用与相互独立的观测数据由卫星上的仪器每月或每小时拍摄，类似于网络文档的文档检索有着相似的性能。在卫星绕地球轨道运行时，该仪器收集新数据，但以相同的类似于出现于文本文档中一页的单词目录的格式包含电磁光谱能量（例如辐射观测数据）的测量值。本文中，我们特别关注了 Aqua 卫星上设备产生的数据，也就是说，由 AIRS 设备收集的可见光/近红外数据。我们描述了 网格化遥感数据的问题和联系，介绍了网格化这些数据的非 Hadoop 方法。为了比较，我们同时描述了一种推荐的 Hadoop MapReduce 方法。这篇论文的余
4、下部分安排如下：首先，我们简单介绍了我们将称其为标准算法的非 Hadoop 算法，随后是 Hadoop 算法，然后我们比较了这两种算法的运行结果。2.Hadoop 计算集群UMBC（马里兰大学巴尔的摩分校）的多核计算中心管理着一组计算机研究设施，它维护了两个非常高端的多核集群，为需要由这些先进硬件系统提供计算力的研究人员服务。这两个集群都通过一个共同的管理节点访问，并且在外部通过 10Gb 光纤相互连接。这两个集群的系统名称是 BlueGrit。一个系统包含 33 台 IBM 的双核 2.2 GHz PowerPC 处理器、2GB 内存的 JS20 刀片服务器，14 台双核 2.5 GHz P
5、owerPC 处理器、4GB 内存的 JS21 刀片服务器，4 台四核 4.0 GHz PowerPC 处理器、32GB 内存的 JS22 刀片计算机，并为 UMBC 提供了一个 138 核的 IBM PowerPC 集群。每一个刀片服务器 包含两个这样的处理器芯片。另一配置包含 14 台 IBM QS20 Cell 刀片服务器和 10 台 QS22 刀片服务器。每一台 QS20/22 服务器包含 2 个 Cell 处理器，每个 Cell 处理器有一个 3.0 GHz PowerPC 处理器和 8 个 SPU处理器。QS20 拥有访问速度为 25 GB/s 的 1 GB 本地内存，每个 SPU
6、 处理器支持每秒 240亿次浮点运算（24Gflops/proc） 。QS22 有 32 GB 内存。 并且，这 8 个在同一芯片上的 SPU处理器由 200GB/s 的 Broadband 网络为在处理器和内存间移动的数据提供了空前的访问速度连接在一起。此外，BlueGrit 拥有 2 个配备了 Intel 奔腾 4 双核处理器和安装有 Hadoop 软件的 2.25 TB 硬盘的谷歌机架服务器。还有一个配置为 PVFS（并行虚拟文件系统）的 16TB 的硬盘矩阵。BlueGrit 有一个基于英特尔（处理器）的头节点和一个大的基于英特尔（处理器）的NFS（网络文件系统）服务器。每一个 JS2
7、0 刀片服务器有 2 个 2.2GHz PowerPC 970 处理器和 512M 内存。这些双核节点配备有 2.3 GHz 处理器和 2 GB 内存。NFS 服务器（storage001）现在总计有 2.2 TB 存储空间，2.5 GB 内存和 2 个 3.0 GHz Intel Xeon 处理器。管理节点是一个拥有两个 2.8 GHz Xeon 处理器的系统，配备了 256 MB 内存，和5.4 TB 共享存储空间。操作系统使用了 Red Hat 4.0 企业版 Linux。我们在 IBM JS20 刀片服务器上安装了 Hadoop。本文写作时，使用的 Hadoop 版本为0.18.1。一
8、台 JS20 刀片服务器 被设定为 Hadoop 控制节点。其余的 JS20 刀片服务器被设定为文件和计算节点。每一台刀片服务器安装了 Fedora 8。JAVA 运行时环境，版本为1.5.0，为从 IBM 获得的二进制版本。Hadoop 的配置文件大部分保留为它们的默认值。在hadoop-site.conf 文件中的唯一的修改包括如下变量： hadoop.tmp.dir：设置为本地硬盘以存放数据 fs.default.name：设置为 Hadoop 控制节点的 IP 地址 mapred.job.tracker：设置为 Hadoop 控制节点的 IP 地址 dfs.replication：设置
9、为 1，阻止答复 mapred.reduce.tasks：设置为 30，表示集群有 30 个节点 mapred.task.tracker.http.address：设置为 31337不幸的是，当前 Hadoop 有一个限制：它只能处理文本文件。 Hadoop 的未来版本将能够处理二进制文件，但是本文写作时，Hadoop 只能读取文本文件。因此，我们的实验被设定为从文本文件读取辐射数据。这导致了显著的处理速度降低，因为文件必须以文本读入，转换为二进制，然后再处理。此外，使用文本文件读入的文件大小取决于存储的数据量。因此我们不能在一次操作中读入整个文件，而必须执行多次读取。这也导致了处理速度的显著
10、降低。为了得到一个好的对比，两种算法被使用同样的输入文件进行测试。在将来，当 Hadoop 支持二进制文件时，我们将测试两种方法以二进制数据作为输入时的性能差异。3.算法实现Aqua 卫星上的“大气红外探测器” （AIRS）设备是在太阳同步、 近极地圆形、在地球上空约 700 千米、穿越 78N至 78S的轨道上运行。地球在该卫星下每天做一次完整的旋转，同时卫星每天延轨道运行约 12 圈，每次在轨道上升部分以 30的偏移穿越赤道。仪器越过轨道中线扫描约 1400 千米，在卫星正下方以约 14 千米、在扫描范围的远端以约 70千米的空间分辨率获得观测数据。仪器每次扫描在 2374 个波段上采集数
11、据。此外，在可见光和近红外（Vis/Nir）的四个额外的波段上，仪器以 1 千米的分辨率采集一个 89 阵列的观测值。数据以被称作粒度的每 6 分钟间隔采集和储存，一天采集 240 个粒度。图 1 显示了每条扫描线上观测值的数量和相对于地球的位置关系。网格化中的问题包括在地球表面定义一个整齐的经纬网格，即 1 度的经度间隔和 0.5 度的纬度间隔，并确定哪个观测值在哪个网格。图 2 所示的每个网格的观测值被平均到确定的时间段，即日、月、年或每十年。图 1图 23.1 非 Hadoop 方法目前使用的标准网格化方法被分为了两部分。第一部分是完成一天的网格化。这一步可以并行执行以完成多天的网格化。
12、在本节我们描述了该算法。我们将实际运行时间信息推到下一节比较该算法和 Hadoop 算法运行时间处。标准并行网格化算法包括分配一个给定的处理器网格化一整天的观测值的任务。由于每一天的观测值独立于另一天，多个处理器可以同时处理多天的数据。选取天为单位有如下原因：科学家们经常想分析与天气相关的日变量；网格化的数据可以被用来验证每天的天气预报；因为遥感网络从 NASA 数据库传送较大块的数据在检查瓶颈和/或断线时会产生计算错误。每个处理器的工作包括读取特定日期的每一个粒度。每个粒度包括纬度、经度和每一次扫描以及每一个光学波段的辐射值。经纬度决定了辐射值所属的网格。属于同一网格的辐射数据累加，同时该网
13、格已累加的辐射数据的数目加一。当完整的一天被读入和网格化后，每一个网格的辐射总值依据该网格累加的辐射数量分组并获得平均值。最终值被输出到硬盘上并用来做计算和可视化。当有多天需要被网格化时，则标准算法重复用于每一天。每一天产生的所有格网为产生最终结果的格网中的每一个网格做均值。这种方法可以通过在不同的电脑上对每一天执行网格化并在一台电脑上计算所有日期的最终均值而轻易地并行使用。由于它们依赖于对每一天的均值取均值，这种计算方法的结果并不完全准确。为了更加精确，需要额外的计算。当单独一天的格网产生后，该算法需要额外的记录落入特定网格中的辐射数量。这些额外的信息使得最终的网格化变得精确，通过将单独日期
14、的均值与该网格的辐射数目相乘，然后对所有日期求均值。3.2Hadoop 方法借助 MapReduce，计算被分为两个函数，Map 函数和 Reduce 函数。在我们的实现中，Map 函数执行最初的处理。为它提供输入数据，它便负责将其处理为键/值输出对。这些键/值对被排序并按键分组。特定键的所有值被作为输入提供给 Reduce 函数。Reduce 函数负责处理特定键的所有值并生成最终的键/值结果。为了在本方法中完成网格化，标准的网格化算法被修改为一个 Map 和一个 Reduce 阶段。此外，Map 和 Reduce 阶段的通讯必须经由键/值对完成。通讯通过为每一个网格分配一个特定的数值完成。在
15、分辨率为 100 千米的格网中经度和纬度方向各有 360 个网格。本例中我们使用墨卡托格网投影实现网格化。每个小网格被分配一个数字，自北极网格阵列的左上角从 0 开始，与其相邻的网格首先沿着纬度线递增，然后在下一条纬度线上对应地加上 360。图 3：未使用 Hadoop（a）和使用了 Hadoop（b）网格化一个月数据的结果。这两幅图的相似暗示着这两种算法有相同的结果。图 4：从标准算法结果减去 Hadoop 算法结果产生的差异可以用舍入误差来解释。因此，这两种算法（的结果）是相同的。当一个单独的网格处理完毕，Map 函数可以使用这个网格的编号作为它产生的键/值对中的键与 Reduce 函数通
16、讯。Map 函数读取输入的辐射值并决定该辐射属于哪一个网格。它记录了落入每一个网格中的辐射总值和数目。当所有的数据被读入完毕，Map 函数产生一个键/值输出，键为单一网格的编号，值为辐射总值和数目。与文档文字搜索的相似之处是特定辐射观测值的网格位置在特定粒度中的出现与给定的单词在给定文档中的出现相对应。在这一步，对于本地计算节点上所有可用的输入文件，Map 函数被重复调用。Map 函数在所有计算节点并行运行，并且每个函数被分配了本地可用数据。随着键/值对的产生，Hadoop Map 函数排列所有的键并将特定键的所有值分组 。一旦所有的 Map 函数完成计算，Hadoop 指定一个随机选择的节点
17、来计算按照键分组的 Reduce 函数，每一个 Reduce 函数调用的所有值都属于同一个网格。Reduce 函数将所有的辐射的总值和数目相加，并用辐射总值除以总数目。最后，Reduce 函数产生最终的键/ 值输出对，在该输出对里键与输入的键相同，值为最终除运算的结果。这些输出结果与标准算法产生的相同。这些结果的形象比较如图 3 所示。图 4 中显示的两种算法的不同之处在本质上是相同的。4.性能标准算法和 Hadoop 算法被部署在 30 台 IBM JS20 刀片服务器上。每台服务器有512MB 内存和 40GB 硬盘，其中约 25GB 空闲。每台服务器有一个双核 2.2GHz PowerP
18、C处理器。对于标准算法输入数据被放置在一个拥有 1GBit 连接速度的 NFS 服务器上。对网格化我们使用了 Aqua 卫星上的 AIRS 可见光仪器。我们在三种不同的分辨率（10.5，0.50.25，0.250.125）上执行了网格化。网格化处理了一个月间隔（的数据）并在大小变化的集群上执行。图 5 显示了标准化算法和 Hadoop 算法以不同的分辨率运行在从 5 个到 30 个节点变化的集群上的运行时间。从结果中我们可以看出，在较少节点上 Hadoop 方法最初比较慢。这被确定为由于 Hadoop 额外的串音。在约 30 个节点时，MapReduce 算法获得了明显的加速以至于快于在 30
19、 个节点运行的标准算法。第二个值得注意之处是 Hadoop 算法似乎更少依赖于网格的大小。图 5：对一个月的数据进行网格化，Reduce 节点随 Map 节点的增加而增加。我们可以看出，与标准算法相比，随着节点数目的增加，Hadoop 算法的加速更快。例如，在 30 个节点时这三种不同大小的网格的网格化时间只有极小的差别。然而，使用标准算法，越精细的分辨率需要始终如一地越多的运行时间。此外，从图 5 我们可以看出，在 5 个节点时，Hadoop 的运行时间明显慢于常规方法。我们认为这些区别可以解释为数据大小和计算方法。我们选择使用 Hadoop 在粒度级别进行网格化。由于每一个粒度仅包含 5
20、分钟的传感器数据，它使用我们的 Map 函数处理得较快。作为一个副作用 Map 函数启动和停止很快。相比之下，标准网格化算法是在处理一整天数据之间启动和停止。Hadoop 的 Map 函数平均地需要 20 秒的执行时间而标准网格化方法需要 12 分钟。我们相信，这个差距是导致总运行时间巨大差别的主要因素。随着计算节点数目的增加，更多的 Map 函数同时启动和停止，导致更少的（时间）积累。将来，实验将通过增加 Hadoop 的处理分辨率到一整天来验证这一结论。5.结论我们已经展示了 Hadoop Map-Reduce 并行编程范例可以被用来处理科学卫星数据，并且它可以改进网格化算法的处理时间。尽
21、管一个月间隔的网格化时间接近基本算法的时间，我们已经表明，随着分辨率的增加和平均周期的延长，如季度或年，Hadoop 算法显示出了增长性的计算时间的节省。为 Hadoop 算法编写的代码也比基本算法的简单。这归功于一个事实即 Hadoop 算法不需要任何并行代码。标准算法需要额外的代码在众多节点间同步和处理同步问题。此外，由于此系统将使用更加合理，Hadoop 文件系统将拥有建立在自动管理回滚之上的恢复能力，以防止出现处理器差错。当前，我们已经使 Hadoop 作为一项服务可以使用，所以任何可以使用 BuleGrit 的MC2 用户可以调用这个并行编程泛型。它也可以被用在由任何遥感系统以产生更高级别的数据。本项目的未来工作包括处理其他的设备并测量它们的速度改进。例如 AVHRR 和MODIS 的仪器将被包含在该 Hadoop 网格化算法中并与标准网格化算法进行比较。6.致谢我们十分乐意向 IMB 系统工艺组为他们慷慨的礼物为我们提供计算资源来完成这些研究和他们对本项目的支持以表达我们的感谢。本次工作也获得了 NASS ACCESS 授权的支持。7.参考文献
