“伯恩斯崖”、“哥伦比亚山”、“奋进号”和“博纳维尔陨石坑”听起来是否像是天外之物？ 没错！ 这是一些 NASA 的火星探测漫游车 (MER) 访问过的地理结构。多年来，漫游者号传送回了大量令人激动的数据，其中包括火星的高分辨率图像。现在，Amazon Simple Workflow Service (Amazon SWF) 引入了一些关键的计算技术来支持这些任务，使 NASA 科学家们能够可靠地推进关键任务运营，并高效地处理我们所收集到的且正在不断增加的关于宇宙的知识。
火星探测漫游者号
NASA Jet Propulsion Laboratory (JPL) 将 Amazon SWF 作为多项任务（包括火星探测漫游者 (MER) 和北极保护区碳脆弱性实验 (CARVE)）必不可少的组成部分。这些任务不断生产大量数据，这些数据必须做高效可靠地处理、分析和存储。用于操作策略和科学分析的数据处理流程设计大量有顺序的执行步骤，每一个步骤都很大机会出现多个服务器平行计算的情况。类似的示例包括从成对的图像生成立体数据，通过拼接数十亿像素的全景照片来为科学家呈现火星地形，以及平铺这些数十亿像素的图像来实现按需加载数据。全球众多运营商和科学家们都依赖这些数据。该社区用户通常需要遵循紧张的协同操作时间表，时间短到仅有几个小时。为了满足这些需求，JPL 的工程师们设定了在几分钟之内处理和传播火星图像的目标。
JPL 长期以来都在 AWS 中存储和处理数据。此工作的大部分内容是使用 Polyphony 框架完成的，该框架是 JPL 面向云的架构的参考实现。它为云中的数据处理作业的调配、存储、监控和任务协调提供支持。Polyphony 现有的用于数据处理和分析的工具集包括：适用于计算容量的 Amazon EC2、适用于存储和数据分配的 Amazon S3，以及 Amazon SQS 和 MapReduce 实施（例如，适用于任务分配和执行的 Hadoop）。然而，这缺少了一个关键部分： 用于可靠地管理大型复杂工作流的协调服务。
尽管队列可提供有效的方法来分配大规模的并行作业，但是工程师们很快就遇到了障碍。由于无法表达队列中的顺序和依赖关系，这使它们不适用于复杂的工作流。JPL 工程师还必须在使用队列时处理重复的消息。例如，图像拼接在一起时，拼接图像的重复任务会导致昂贵的冗余处理，其结果又会随着流程的继续推进而导致进一步的昂贵计算，最终不会产生任何效益。JPL 还拥有许多使用案例，它们的数据处理过程非常粗糙并且需要一些机制来驱动控制流。尽管借助 MapReduce，工程师们能够轻松地实施其数据驱动的工作流，但是他们发现要在框架语义中表达流程内的每一步则非常困难。尤其是，随着数据处理复杂性的增加，他们在表示处理步骤间的相关性和处理分散的计算故障方面也遇到了困难。
JPL 工程师确定了对具有以下特征的协调服务的需求：
- 高度可用： 用于支持关键任务操作
- 可扩展： 促进从数百个 Amazon EC2 实例同时并行执行的过程
- 一致： 必须在可能性很高的情况下一次性执行计划任务
- 富有表现力： 通过简单的方式表达复杂的工作流以便加快开发
- 灵活： 工作流的执行一定不能局限于 Amazon EC2，而且任务必须可以被路由
- 高性能： 以最少延迟安排任务
JPL 工程师使用了 Amazon SWF 并将该服务与 Polyphony 流程（该流程负责火星图像的数据处理，以用于战术操作）相集成。他们对流程的分布式执行有了前所未有的控制和了解。最重要的是，他们能够以简洁地方式展现复杂的工作流，而无需被迫以特定的范式展现问题。
为了支持用于好奇号漫游车的快速运动实地测试，也称为火星科学实验室，JPL 的工程师们必须处理图像、生成立体影像并构建全景。立体影像要求在同一时间获得两张图像，并且生成范围数据，告知战术操作员从漫游者号到图像中像素的距离和方向。左侧和右侧图像可以并行处理；但是只有在每个图像都经过处理后，才能启动立体处理。很难使用基于队列的系统来表达这一经典的拆分-合并工作流，但是在 SWF 中仅需几行简单的 Java 代码和 AWS Flow Framework 注解即可表达。
生成全景的任务也将作为工作流来实施。出于策略目的，将在漫游车停放和拍摄的每个位置生成全景照片。因此，无论何时收到来自某个特定位置的新照片，都要使用该新信息完善全景照片。由于需要尽快生成大规模全景照片，所以必须区分该问题，并通过大量机器协同处理。工程师所采用的算法将该全景划分为多个较大的行。该工作流的第一个任务是根据该位置上的可用图像生成各个行。这些行生成后，它们将缩小为多个分辨率并进行平铺，以供远程客户端使用。使用 Amazon SWF 提供的丰富的功能集，JPL 的工程师们已将该应用程序流表达为 Amazon SWF 工作流。
包含 77 幅彩色图像的总大小为 11280×4280 像素的 Opportunity Pancam 相机拼接。属于六个细节级别的拼接部分需要将该图像传输到任意大小的查看器。黄色网格线表示每个图像所需的拼接部分。火星科学实验室的 Mastcam 仪器所拍摄的全景中包含多达 1296 张图像并具有近 2 千兆像素的分辨率！ 相应的全景图像如下所示。
通过在云中协调业务流程，Amazon SWF 使 JPL 能够利用环境内部和外部资源，并将应用程序执行无缝分配到公共云中，使它们的应用程序能够动态扩展并真正以分布式的方式运行。
许多 JPL 数据处理流程已进行了结构化，可作为上载经防火墙保护的数据的自动化工作程序、作为并行处理数据的工作程序，以及作为下载结果的工作程序。上载和下载工作程序可以在本地服务器上运行，而数据处理工作程序可以在本地服务器和 Amazon EC2 节点上运行。通过使用 Amazon SWF 的路由功能，JPL 开发人员可以在流程中动态融入工作程序，同时利用工作程序特点，如数据局部性。该处理应用程序同样高度可用，因为即使本地工作程序失败，基于云的工作程序还会继续推动处理。由于 Amazon SWF 不限制工作程序节点的位置，因此 JPL 可以在多个区域和本地数据中心内运行作业，以为关键任务系统提供最高的可用性。由于 Amazon SWF 可用于多个区域，JPL 计划将自动故障转移跨区域集成到 SWF。
JPL 对 Amazon SWF 的使用不受数据处理应用程序的限制。使用 Amazon SWF 中的调度功能，JPL 的工程师们构建了分布式 Cron 作业系统，该系统可以及时可靠地执行关键任务操作。除了可靠性，JPL 还通过借助 AWS 管理控制台中提供的 Amazon SWF 可见性功能，获得了对这些分散作业的前所未有的集中式可见性。JPL 甚至构建了一个应用程序，用来备份来自 Amazon S3 上 MER 的重要数据。借助分布式的 Cron 作业，JPL 可以根据项目需要，不断更新备份并审核数据的完整性。该应用程序的所有步骤，包括加密、上载到 S3、随机选择要审核的数据，以及通过比较现场数据与 S3 来进行实际审核，均通过 Amazon SWF 进行了可靠的规划。此外，几个 JPL 团队通过利用 AWS Flow Framework 提供的编程支持，已快速迁移了其现有的应用程序，以使用云中的业务流程协调。
JPL 继续将 Hadoop 用于简单的数据处理流程，对于在处理步骤之间有着复杂依赖关系的应用程序，Amazon SWF 现在已成为实施它们的自然选择。开发人员还经常使用 AWS 管理控制台提供的诊断和分析能力，在开发过程中和跟踪分布式执行时调试应用程序。借助 AWS，之前需花费数月进行开发、测试和部署的关键任务应用程序，现在只需几天即可完成。