Smart:类MapReduce的原位科学分析框架

  • 摘要
  • 1、介绍
    • 1.1 动机
    • 1.2 贡献
  • 2、背景和挑战
    • 2.1 背景：原位科学分析和MapReduce
    • 2.2 优势和可行性
    • 2.3 挑战
      • 2.3.1 数据加载不匹配
        • 1. 从分布式文件系统加载数据
        • 2. 从共享或本地文件系统加载数据
        • 3. 从内存加载数据
        • 4. 从数据流加载数据
      • 2.3.2 编程视图不匹配
      • 2.3.3 内存限制不匹配
      • 2.3.4 编程语言不匹配
  • 3、系统设计
    • 3.1 系统总览
    • 3.2 两种原位模型
    • 3.3 启动Smart以及运行时提供的API
    • 3.4 数据处理机制和用户API实现
    • 3.5 Smart分析程序示例
  • 4、基于窗口分析的系统优化
    • 4.1 动机
    • 4.2 优化：归约对象早传送
  • 5、实验结果
    • 5.1 应用和环境安装
    • 5.2 与Spark的性能比较
    • 5.3 与低级分析程序的性能比较
    • 5.4 扩展性评估
    • 5.5 内存效率评估
    • 5.6 时间共享和空间共享模式对比
    • 5.7 基于窗口的分析程序优化评估
    • 5.8 结论
  • 6、相关工作
  • 7、结论

摘要

近年来I/O与计算性能的差距越来越大。原位分析通过共同定位模拟和分析程序，避免了昂贵的模拟输出数据移动，是降低I/O和存储成本的有效方法。而开发一个高效的原地实现存在很多挑战，包括并行化分析，执行所需的数据移动和共享，为分析程序的执行分配适当的资源。MapReduce是被广泛采用的并行数据分析编程模型。然而，在原地科学分析的实现上，MapReduce还存在很多问题。

在这篇文章中，我们实现了一个支持高效原地科学分析的类MapReduce框架，叫做Smart。Samrt可以直接从集群节点的内存中加载模拟数据。它利用一个类似MapReduce的API来并行化分析，同时满足分析代码在与模拟共存时的严格的内存限制。使用Smart作原地分析时，只需要对模拟程序做很细微的改动。当每个模拟输出分区准备就绪后，可以从并行（OpenMP和/或MPI）代码区域启动Smart，而并行代码收敛后可以直接得到全局分析结果。我们开发了时间共享和空间共享模式，以在不同的场景中实现性能的最大化。此外，Smart还集成了一个基于窗口的高效原位分析优化。

与Spark的性能比较表明，我们的系统可以实现高效的原位分析，至少比Spark的性能高出一个数量级。与手工制作的分析程序相比，我们的中间件不会增加太多开销（通常小于10%）。通过在多核和多核集群上使用不同的仿真和分析程序，我们展示了系统的功能和可扩展性。平均可以达到93%的并行效率。接下来，我们展示了时间共享和空间共享模式的效率。最后，我们对基于窗口的原位分析的优化可以实现高达5.6倍的加速。

1、介绍

科学模拟的数据驱动发现所面临的一个主要挑战是内存和I/O容量与不断增长的计算能力不同步。造成这种限制的原因有很多，最关键的是，以一种经济高效的方式提供高性能的需求有两个关键瓶颈，内存限制和数据移动成本。科学模拟越来越多地在带有协处理器和加速器的系统上进行，包括gpu和Intel MIC，它们有大量的内核，但每个内核只有少量的内存。由于功率因素推动了高性能计算机的设计和运行，因此必须避免与数据移动相关的功率成本。

为了应对这一前所未有的挑战，原位分析已经成为一种很有前途的数据处理模式，并开始被HPC社区采用。这种方法将上游模拟和下游分析放在同一计算节点上，因此一旦模拟数据可用，它就可以启动分析。与传统的离线处理模拟数据的科学分析相比，原位分析可以完全避免或避免大规模模拟输出到持久存储的昂贵数据移动。这意味着节省了执行时间、电源和存储成本。

1.1 动机

当前的原地分析研究可以大致分为两个领域：1）应用层的原地算法，包括索引、压缩、可视化和其他分析；2）系统级的原地资源调度平台，其目的是提高资源利用率并简化共定位分析代码的管理。这些现场中间件系统主要扮演协调器的角色，目的是方便底层的调度任务，如周期窃取和异步I/O。

尽管最近在这一领域进行了大量的工作，但一个重要的问题仍然几乎完全未被探索：“能否更容易地将应用程序映射到用于原位分析的平台？”换句话说，我们假设需要对原位分析进行编程模型研究。特别是，目前的原位算法是用低层并行编程库（如MPI、OpenMP和Pthread）实现的，这些库提供了高性能，但要求程序员手动处理所有的并行化复杂性。此外，由于类似的分析可能同时应用于原位和离线模式，另一个有趣的问题是 “离线和原位分析代码能（几乎）相同吗？”显然，只有当实现是在一个高级框架中时，这种情况才有可能发生，在这个框架中，应用程序开发人员隐藏了诸如加载和转移数据以及并行化的复杂度等细节。

1.2 贡献

在本文中，我们提出了一个用于原位科学分析的类MapReduce框架。据我们所知，这是首个MapReduce-like-API原位科学分析框架。该系统被称为Smart。我们的系统可以在仿真节点上支持各种科学分析，只需对仿真代码进行最小的修改，无需任何专门的部署（如安装HDFS）。与传统的MapReduce框架相比，Smart通过直接从集群或分布式内存并行机的每个节点的内存访问模拟数据，支持高效的原地处理。此外，与传统的实现不同，我们的工作基于MapReduce API的一个变体，它避免了输出键值对，从而保持了分析程序的低内存消耗。为了解决模拟代码的并行编程视图与MapReduce的顺序编程视图之间的不匹配，在每个模拟输出分区就绪后，可以从并行（OpenMP和/或MPI）代码区域启动Smart，而并行代码收敛后，可以直接获得全局分析结果。此外，我们还开发了时间共享和空间共享模式，以最大限度地提高不同应用场景的性能。此外，对于内存密集型的基于窗口的分析，我们通过支持归约对象的早期输出来提高原位执行效率。

通过在多核和多核集群上使用不同的科学模拟和分析任务，我们对系统的功能和效率进行了广泛的评估。我们首先证明，我们的系统在三种应用中的性能至少可以超过Spark一个或两个数量级。其次，与使用低级程序库（即MPI和OpenMP）编写的分析程序相比，我们的中间件不会增加太多开销（通常小于10%）。接下来，通过改变节点和线程的数目，我们展示了系统的高可伸缩性。此外，通过与另一个包含额外模拟数据副本的系统实现的比较，我们展示了我们的设计（对于分时模式）的效率。此外，我们还评估了我们的空间共享模式如何适用于具有多个核心节点的集群。最后，通过与禁用归约对象的早期输出的实现进行比较，我们展示了我们对基于原地窗口的分析的优化可以实现高达5.6倍的加速。

2、背景和挑战

在本节中，我们首先提供有关原位科学分析和MapReduce的背景信息，然后讨论为什么MapRe-duce API适用于原位分析，最后重点讨论将MapReduce思想应用于高效原位科学分析的挑战。

2.1 背景：原位科学分析和MapReduce

随着I/O与计算能力之间的性能差距空前扩大，原位数据处理在各种科学分析中得到了广泛的应用。这种新兴的数据处理模式可以通过同时定位模拟和分析程序来避免昂贵的模拟输出数据移动，从而显著降低I/O和存储成本。作为一个案例研究，我们将原地分析的性能与传统的离线分析进行了比较，后者先存储后分析，先将模拟数据输出到磁盘，然后将数据加载到分析程序中。


我们使用一个真实的模拟程序Heat3D和k-means集群作为分析程序，以分时模式处理64核上的1TB数据。为了改变计算量，我们在k-均值算法中使用了不同的迭代次数（收敛前）。图1显示了总的处理时间，包括模拟和分析时间，以及离线分析所涉及的I/O开销。事实证明，即使计算量适中，原位分析仍然是离线分析的10.4倍。

尽管与传统的离线分析相比性能有所提高，但为了将对模拟性能的影响降至最低，原位分析要求满足一些严格的资源限制。特别是，由于同一位置的模拟和分析共享相同的内存资源，并且模拟通常是内存受限的，因此非常希望原位分析程序仅使用少量内存进行操作。

另一方面，MapReduce是Google为数据中心的可扩展应用开发而提出的。该模型具有map和reduce两个功能的简单接口，非常适合各种应用程序的并行实现，包括大规模科学分析。map函数接受一组输入实例，并生成一组相应的中间输出（键、值）对。MapReduce库将与同一个键相关联的所有中间值组合在一起，并将它们传递给reduce函数。reduce函数也由用户编写，它接受一个键和一组与该键关联的值。它将这些值合并在一起，形成一个可能更小的值集。

2.2 优势和可行性

MapReduce是开发数据分析实现最广泛采用的编程模型之一，尽管它在科学领域可能不如在商业领域那样被广泛接受。MapReduce API不仅简化了并行化，而且框架实现还处理了许多调度、任务管理和数据移动。然而，它目前的实现都不直接适用于原位科学分析。

我们假设MapReduce API确实适合于在科学模拟中执行大量分析任务。现在，我们给出了一些在各种研究中报告的原位分析的具体使用案例，以及这些案例如何可能适用MapReduce：1）可视化算法，其中大多数步骤可并行，而其他步骤涉及归约；2） 统计分析和相似性分析，其中需要计算平均值、直方图和相互信息等统计数据，这些非常适合使用MapReduce。还有构建在MapReduce之上的更高级别的框架，例如Pig和Hive；3）特性分析和聚类分析，它们在MapReduce中得到了有效的实现（尽管是以一种灵活的方式），例如通过Spark进行的逻辑回归和k均值聚类。

除了目标应用程序之间的匹配和编程模型的选择之外，另一个重要的问题往往是程序员的专业知识。在这方面，我们认为，随着MapReduce近年来越来越受欢迎，许多科学家现在已经接受了为科学分析编写MapReduce风格代码的良好培训。因此，一个类似于MapReduce的框架可以成为一个有希望的方法来提高科学分析的生产力和可维护性。

2.3 挑战

接下来我们将讨论弥合现有科学分析和MapReduce之间差距的挑战，我们将其总结为四个不匹配。

2.3.1 数据加载不匹配

顾名思义，一旦模拟数据可用，下游分析程序就需要直接从（分布式）内存而不是从文件系统获取输入。但是，现有的MapReduce实现并不是为这样的场景而设计的。为了进一步说明这种数据加载不匹配，我们首先根据数据加载机制将所有MapReduce实现分为四种类型。

1. 从分布式文件系统加载数据

一个突出的例子是Hadoop，以及它的变体，如M3R和SciHadoop，它们从Hadoop分布式文件系统（HDFS）加载数据。Hadoop实际上模仿了Google的MapReduce，它从Google文件系统（GFS）加载数据。在Erlang中的MapReduce实现Disco从Disco分布式文件系统（DDFS）加载数据。

2. 从共享或本地文件系统加载数据

MARIANE和CGL MapReduce等系统通过从共享文件系统加载数据，使MapReduce适应科学分析环境。此外，其他基于MPI的实现，如MapReduce MPI和MRO-MPI可以从共享文件系统或本地磁盘加载数据。

3. 从内存加载数据

基于Pthread的MapReduce原型，如Phoenix、Phoenix++和MATE，可以从内存加载数据。然而，这些原型仅限于共享内存环境，因此目前它们不可用于分布式计算。

4. 从数据流加载数据

虽然MapReduce最初是为批处理而设计的，但是HOP、M3和iMR等系统都专注于流处理。

显然，前两类是从文件系统加载数据，不能支持原位分析。类似地，第三类缺乏对分布式环境中所需的全局同步的本机支持。第四类似乎更合适，因为可以考虑将模拟输出包装为数据流的可能性。然而，这种方法仍然存在一些障碍。首先，由于数据是以潜在的大时间范围的形式模拟的，因此将时间范围投射到数据流中是不自然的。这种投射不仅需要额外的开销，而且由于大量模拟数据的突然到达，会导致周期性的峰值，严重降低流处理的性能。其次，由于数据流上只允许一次传递，这样的转换也失去了迭代处理的能力，迭代处理是许多分析程序（如回归和聚类）所需要的。

在我们研究过的所有MapReduce实现中，我们发现Spark是一个例外。其输入数据布局被定义为弹性分布式数据集（RDD），可从上述所有数据源选项中导出。然而，Spark仍然有功能和性能限制，这将通过我们在第5节中报告的一系列实验来证明。

2.3.2 编程视图不匹配

科学模拟和MapReduce之间的关键差距是由不同的编程视图造成的。一方面，模拟通常是用MPI（或PGAS语言）实现的，该语言适合于分布式内存环境（可能与OpenMP/OpenCL等共享内存API结合使用）。使用这些低级并行程序库，程序员在并行程序视图中显式地表示并行性，即所有并行化细节（如数据分区、消息传递和同步）都必须手动处理。另一方面，MapReduce的简化接口提供了一个顺序编程视图，隐藏了所有并行化的复杂性。在这种顺序编程视图中，所有并行化细节对程序员都是透明的。因此，传统的MapReduce实现不能显式地将分区模拟输出作为输入，也不能从SPMD区域启动分析的执行。如果下游MapReduce端没有任何更改，则无法以实际的方式解决此不匹配问题。

例如，可以考虑基于MapReduce重写所有仿真代码。由于存在四个障碍，这一选择显然不切实际。首先，科学家不仅花费多年时间来编写、调试和优化现有的仿真程序，而且这些程序的生命周期也很长。其次，仿真程序大多用FORTRAN或C/C++编写，并将其翻译成MapReduce使用的java或Scala等编程语言，可能会导致性能损失较大。第三，几乎所有的仿真程序都需要在不同分区之间进行点对点数据交换，这种模式与MapReduce不匹配。最后，模拟程序操作阵列板，需要知道元素的位置信息，而传统的MapReduce设计用于处理记录行，不保留任何记录的位置信息。另一种可能是在单个计算节点上收集所有分区的模拟数据，并将其馈送给MapReduce。这种选择显然也非常昂贵。

一个好的选择是开发一个新的MapReduce实现，它可以呈现一个混合编程视图。特别是，在开始的时候，应该提供一个并行编程视图，让程序员在并行执行期间知道所有的分区。在输入分区数据之后，应该跟随一个顺序编程视图，这样就隐藏了并行性细节。

2.3.3 内存限制不匹配

由于模拟程序执行时通常需要占用每个节点的所有或几乎所有的内存，因此原位分析程序只能占用很少的内存。然而，几乎所有现有的MapReduce实现都是内存密集型的，大多数甚至是磁盘密集型的。这主要是因为在映射阶段，每个元素都会产生一个或多个键值对形式的中间数据，这些键值对的大小可能比原始输入数据更大。此外，后续的操作（如排序、shuffling和分组）只重新组织中间数据，而不减小其大小。因此，在执行实际的reduce操作之前，不能降低内存消耗。注意，虽然在映射器端的组合器功能可以显著地减少shuffling阶段中间数据的大小，但它无助于减少映射阶段的峰值内存消耗。除非我们重新设计MapReduce的执行流程，否则无法解决内存约束不匹配的问题——特别是，我们需要避免中间的键值对。

2.3.4 编程语言不匹配

最后一个不匹配是编程语言的不匹配。一方面，几乎所有的HPC仿真都是用FORTRAN或C/C++编写的，而用java或Scala等编程语言改写仿真代码是不现实的。另一方面，Hadoop和Spark是最广泛采用的MapReduce实现（虽然Spark还提供其他功能），但不支持FORTRAN或C/C++。虽然这种不匹配可以通过使用基于C/C++的MapReduce实现来缓解，但这些系统没有被广泛采用。

3、系统设计

在这一章节中，我们将讨论系统的设计和实现。总体而言，Smart解决了我们在上一节中描述的所有挑战，具体来说：1）为了解决数据加载不匹配问题，Smart支持从模拟程序生成的内存中处理数据，并且在一种原位模式（分时）中，这样做不需要额外的数据拷贝；2） 为了解决编程视图不匹配的问题，Smart提供了一个混合编程视图——这将在启动数据处理时向分析程序公开数据分区，并且在执行期间仍然可以隐藏并行性；3）为了解决内存约束不匹配的问题，Smart通过修改原始MapReduce实现了高内存效率的API（并且只增加少量的编程工作），并且避免生成大量的键值对或shuffling；4）为了解决编程语言不匹配，Smart使用C++ 11实现，可与OpenMP和MPI兼容。

3.1 系统总览


图2概述了在分布式环境中使用Smart的典型应用程序的执行流程。首先，给定一个仿真程序，每个计算节点在每个时间段生成一个数据分区。不将数据输出到磁盘，而是将驻留在内存中的数据分区立即作为下游Smart分析作业的输入。由于数据分区是从模拟程序的SPMD区域生成的，因此Smart作业也从同一代码区域启动。与大多数分布式数据处理系统不同，Smart可以直接将这些分区公开给后续处理，而不涉及计算节点之间的任何显式数据分区。

接下来，Smart运行时调度程序逐块处理分区数据。对于每个数据块，Smart运行时调度程序将其平均分为多个拆分，其中每个拆分都分配给一个线程进行处理。此外，Smart将每个线程绑定到一个特定的CPU核心，最大限度提高性能。

在拆分中处理元素时，有两个关键操作：归约和组合，分别在归约和组合两个核心映射结构上执行。为了支持这些操作，程序员需要定义一个归约对象，它表示两个映射的键值对中的值的数据结构。此数据结构维护具有相同键的所有键-值对的累积（或归约）值。在归约操作中，首先为拆分中的每个元素生成一个键。使用这个键，运行库下一步在归约映射中定位一个归约对象，然后在这个归约对象上累积相应的元素。在合并过程中，所有的归约映射在局部合并为一个单一的合并映射，然后在主节点上进一步合并每个节点上的所有合并映射。

最后，当并行代码收敛时，最终的输出可以在序列代码区域中检索。向用户呈现顺序编程视图。或者当原位分析任务部署为MapReduce管道时，一些预处理步骤（如平滑、过滤和重组）在每个分区上只有一个本地输出。在这种情况下，通过关闭全局组合过程，用户可以直接在并行代码区域中检索输出，然后将输出传送到下一个Smart作业。

上面的执行流程修改了最初的MapReduce处理，但它也是Smart高内存效率的关键。具体来说，明确声明归约对象消除了MapReduce的shuffling阶段。在分析程序中，除了自我定义的归约对象外，归约和组合操作都可以通过一个简单的API定制。但是除了声明归约对象外，编程的工作量并不比使用原始MapReduce API所需的工作量高——因为这个API不涉及任何并行化细节，所以程序员只需要编写顺序代码，像传统的MapReduce一样带来良好的可编程性。

3.2 两种原位模型

为了在不同的场景中实现性能的最大化，我们的系统提供了两种原位模式：时间共享和空间共享。更具体地说，我们观察到：1）对于某些模拟和/或体系结构，内存可能是一个重要的限制，我们必须避免不必要的数据复制；2）在许多核心体系结构中，模拟可能无法有效地使用所有可用的核，将一定数量的核用于数据分析是可行的而且很有吸引力。上述两种情况（不一定是排他性的）导致了时间共享和空间共享模式。

时间共享模式：时间共享模式旨在通过避免仿真输出的额外数据拷贝，将分析的内存消耗降至最低。请注意，尽管内存复制本身可能不是一个昂贵的操作，但它会增加总内存需求，这在某些情况下会导致性能下降。

如图3所示，为了避免额外的数据复制，Smart在内存空间上设置一个读指针，该指针对应于特定时间步（当数据准备就绪时）的输出。因此，这些数据现在可以被仿真和分析程序共享。但是，由于该内存空间可能被模拟程序覆盖，因此分析逻辑必须在模拟程序恢复之前执行。因此，在这种模式下，模拟程序和分析程序轮流运行，并且每个都充分利用每个节点的所有核心（因此被称为时间共享）。

空间共享模式：考虑一个集群，其中每个节点都是Intel Xeon Phi。由于每个协处理器都有比CPU多得多的核，为标准多核集群编写的仿真程序不太可能有效地使用Xeon Phi的所有核。在这种情况下，不必定期停止模拟进程并执行分析，而是可以轻松地为分析程序指定一定数量的可用内核。更具体地，所有核心被分为两个独立的组，一个专门用于模拟，另一个专门用于分析。在这种模式下，除了多线程的并行性和多个节点上的并行性外，在这两个并行级别之上还放置了另一个任务级并行性。

如图4所示，Smart在内部维护一个循环缓冲区，其中每个单元可以按需分配内存，并用于缓存时间步的输出。在此模式下，可以将仿真程序和Smart分别视为生产者和消费者。一旦生成了时间步的输出，如果循环缓冲区未满，则可以通过将此数据复制到空单元将其传送到Smart中间件。否则，模拟程序将被阻塞，直到循环缓冲区中的单元可用为止。

3.3 启动Smart以及运行时提供的API


Smart是用C++ 11编写的，使用OpenMP和MPI实现并行性，并且也可以兼容科学模拟环境。因此，启动Smart不需要安装额外的库（例如HDFS）。现在我们展示如何在两种不同的原位分析模式下启动Smart。如表1所示，运行时提供一组函数，在应用程序代码中调用这些函数即可初始化系统并运行分析程序。这些函数对程序员是透明的。具体来说，表1中的函数1-4行用于两种模式，5和6行用于分时模式，7-9行用于空间共享模式。

在分时模式下启动Smart：Smart的一个显著特点是易用性。在分时模式下，Smart可以最小化对原始模拟代码的修改。如清单1所示，要在此模式下运行Smart，只需要向模拟程序添加3行（第4-6行）。


示例代码Listing 1显示了处理单个时间步骤的执行情况。在给定一组模拟参数p（第2行）模拟每个数据分区后，第4行构造一个调度程序参数args，num_thread指定每个进程的线程数、chunk_size表示单元块（即，单元元素）的大小、extra_data是用于分析程序的额外数据，num_iter为程序迭代次数。为了最大化分析性能，num_threads应等于模拟程序的线程数。chunk_size是处理单元的大小，在分析程序中通常可以看作是特征向量的长度。当需要一些额外的输入时，使用extra_data，例如在k-means聚类中需要初始k中心点。可以为迭代处理指定num_iter。默认情况下，extra_data和num_iter分别初始化为空指针和1。第5行使用调度程序参数构造派生的Smart调度程序实例Smart。请注意，Smart调度类被定义为模板类，因此Smart可用于将任何数组类型作为输入或输出，而不会使应用程序代码复杂化。在第6行中，Smart以分区数据作为输入启动分析，最终结果将输出到给定的目标。在整个过程中，所有并行化细节都隐藏在顺序编程视图中。请注意，归约对象的定义以及派生的Smart调度程序类是在基于另一个API集的单独文件中实现的，这不会增加原始模拟代码的任何复杂性（请参阅第3.4节）。

在空间共享模式下启动Smart：如Listing 2所示，空间共享模式需要比时间共享模式更多的代码重组，原因为需要部署额外的任务级并行，为并发执行创建了两个OpenMP任务。在模拟程序和Smart初始化之后，一个任务封装模拟代码，然后将其输出传送给Smart（第6-13行），另一个任务运行分析程序（第14-16行）。用于模拟程序的线程数在模拟任务中指定。并且在初始化Smart时指定用于分析程序的线程数。注意，MPI代码隐藏在模拟任务和分析任务中，在这种模式下，MPI函数可以由不同的线程并发调用。因此，为了避免潜在的数据竞争，在初始化MPI环境时，应该将线程支持级别升级到MPI_THREAD_MULTIPLE。

3.4 数据处理机制和用户API实现

接下来，我们将介绍特定于应用程序的数据处理机制，以及可能由程序员实现的API。这组API用于实现前一个API集的run（或run2）函数，相同的实现可用于原位模式和离线处理。这个API集主要包括三个函数：gen_key或gen_keys、accumulate和merge。在归约阶段调用gen_key或gen_keys以及accumulate，在组合阶段调用merge。特别是，run函数调用gen_key为大多数应用程序生成一个给定块的键，run2函数调用gen_keys（类似于Scala中的flatmap函数）为其他分析程序（如基于窗口的应用程序）生成多个给定块的键。此外，程序员还需要定义一个特殊的归约对象作为接口类RedObj的子类。

算法1中的run函数采用分时模式，并给出了Smart的数据处理机制。空间共享模式使用相同的机制，函数签名略有不同。在归约阶段，当一个数据块被划分为多个拆分时，每个线程都会逐块处理每个拆分。在第8行中，为unit元素生成一个键。第9行将元素的派生数据累积到归约对象中，该对象可以通过生成的键在reduction映射中定位。归约对象将在适当的位置更新而不发送或存储中间键值对，因此，在归约期间不需要shuffling。这是我们的API和传统MapReduce之间的一个关键区别。

第11-17行显示了由两个步骤组成的组合阶段-局部组合和全局组合。在本地组合中，由进程上的所有线程维护的归约图合并为本地组合图。特别是，与同一个键关联的两个归约对象合并为一个。在全局组合中，所有计算节点上的局部组合映射进一步组合为保存全局结果的全局组合映射。此全局组合利用用于本地组合的相同合并操作。第18行可以在每次迭代的组合阶段之后更新归约对象，例如，基于求和与计数计算平均值。最后，第20-23行将全局组合图中的所有归约对象转换为所需的输出。

此外，process_extra_data和post_combine通常用于涉及迭代处理的分析。特别是，process_extra_data功能可以帮助使用额外输入初始化组合映射。例如，k-means聚类需要一些初始质心作为输入点之外的额外数据，这些质心可以用来初始化表示聚类的归约对象。组合映射初始化后，将其分发到每个归约映射中（第3-6行）。在合并阶段之后，post_combine函数可以帮助更新归约对象。例如，归约对象中的两个字段sum和size可用于计算此函数中的平均值。另外，对于非迭代应用程序，默认情况下这两个函数实际上不涉及计算，从而导致空的初始组合映射。最后，根据转换函数，将组合映射中的所有归约对象转换为所需的输出。

此外，run函数和run2函数之间的唯一区别在于第8行和第9行。在run2函数中，给定一个块，将生成多个键，块将在循环中累积，循环遍历所有生成的键。

3.5 Smart分析程序示例

现在，我们通过创建两个应用程序——直方图和k-means聚类，分别作为非迭代和迭代应用程序的一个实例，来说明系统API的使用。请注意，特定于应用程序的分析代码是在一个单独的文件中编写的，并且在不同的原位模式下没有区别。

作为第一个例子，Listing 3显示了等宽直方图构造的伪代码。主要分为两步，首先，用户需要定义派生的缩减对象类。在这个示例中，类Bucket表示一个直方图Bucket，由单个字段计数组成。

其次，需要定义一个派生的系统调度器类，例如这里的直方图。请注意，为了便于对不同类型的数据集进行管理，在我们的系统中，派生类可以定义为模板类或特定于输入或输出数组类型的类。对于这种非迭代应用程序，用户通常只需要实现三个功能：gen_key、accumulate和merge。首先，gen_key函数基于输入数据块中的元素值计算bucket ID，bucket ID作为返回的键。例如，如果元素值位于第一个bucket的值范围内，则返回0。为了简单起见，我们假设最小元素值可以作为先验知识或由先前的Smart分析作业检索。注意，在这个应用程序中，由于每个元素都应该单独检查，作为处理单元的每个块只包含一个数组元素。接下来在归约阶段，累加函数累加对应于gen_key函数返回的键的bucket的计数。最后，给定两个归约对象，其中第一个red_obj来自归约映射，第二个com_obj来自组合映射，合并函数在组合阶段合并com_obj中的计数值count。



如Listing 4所示，第二个示例是k-means聚类，它表示一组涉及迭代处理的应用程序。首先，ClusterObj类被定义为一个派生的归约对象类，表示多维空间中的一个簇。在这一类中，形心、求和与大小分别表示形心坐标、每个点到形心的距离和簇中的点数。

接下来，KMeans被定义为派生的系统调度器类。对于这种迭代应用程序，通常应该覆盖大多数虚拟函数。首先，给定一个由输入数据块表示的点，gen_key函数查找最近的中心点ID并返回中心点ID作为键。其次，与前面的例子类似，累加函数累加归约映射中归约对象上的两个分布（或关联和交换）字段sum和size，合并函数累加归约映射中的归约对象。接下来，process_extra_data函数使用指示某些初始质心的额外数据初始化组合映射，post_combine函数通过更新所有簇准备下一次迭代。具体地说，质心坐标是根据求和与大小计算的，然后重置为零。最后，转换函数从每个归约对象中提取质心坐标作为输出结果。要使用此函数，一个限制是，整数键应该从0开始。

从以上两个例子可以看出，Smart为应用程序开发提供了一个顺序编程视图，用户只需要根据声明的归约对象编写一些顺序代码。因此，与传统的MapReduce框架工作一样，我们的系统使并行性对应用程序代码完全透明。注意，与由组合器函数优化的MapReduce作业不同，我们的应用程序代码不会为中间结果发出任何键值对。

4、基于窗口分析的系统优化

4.1 动机

实际上，模拟输出可能包含一些短期波动或过细粒度的结构。在这种情况下，对特定时间步长范围（也称为滑动窗口）执行分析程序非常重要。在其他一些情况下，原位分析可能涉及某些预处理步骤，如去噪和平滑处理，它们也在滑动窗口的基础上执行。这种基于窗口的分析的一个简单例子是移动平均，即计算每个窗口快照中元素的平均值。实现这种基于窗口的分析的一个关键挑战是高内存消耗，我们将在下面详细说明空间复杂性。

利用MapReduce实现的基于窗口的分析的空间复杂度由两个因素决定，即键值对的最大个数和键值对的大小。假设输入大小和窗口大小分别为N和W。就第一个因子而言，由于每个输入元素对应一个输出结果，因此共有N个输出结果，它们是由N个键值对经过归约后形成的。此外，由于每个元素通常在滑动窗口中出现W次，因此每个元素生成W个键值对。因此，在传统的MapReduce实现中，生成了具有N个不同键的N×W键-值对（至少在映射阶段）。Smart可以将最大的键值对数减少到N，因为每个不同的键对应一个单一的归约对象。另一方面，键值对或归约对象的大小取决于特定的应用，并且通常在Θ（1）到Θ（W）之间变化。例如，由于平均值是代数的，并且可以通过求和与计数来计算，所以移动平均值的归约对象的大小只能是Θ（1），而中值是整体的，并且只能通过保留所有元素来计算，所以移动中值的归约对象的大小是Θ（W）。另一个例子是K近邻平滑器，其中归约对象的大小为Θ（K），1≤K≤W。

总的来说，给定一个由Smart实现的基于窗口的应用程序，其空间复杂度为Θ（N×R），其中N和R分别表示归约对象的最大数目和约简对象的大小。不管应用程序是什么，由于N通常太大，无法满足原位场景的内存限制，因此非常希望降低空间复杂性，特别是通过减少最大数量的还原对象。

4.2 优化：归约对象早传送


我们在以下观察的基础上进行了优化。对于大多数元素，所有关联的窗口快照都会被它们各自的本地数据拆分所覆盖。因此，大多数归约对象值已在（局部）归约阶段最终确定，它们将不参与后续的组合阶段。通过捕捉这一观察结果，我们设计了一种机制，可以支持归约阶段归约对象的早期发送，与最初的设计不同，前者将所有归约对象都保存至组合阶段结束。

我们的优化实现如下。首先，我们通过添加一个触发器函数来扩展归约对象类。此触发器评估自定义的发送条件，并确定是否应尽早从归约映射中发送归约对象。默认情况下，函数返回false，因此不会触发早期发送。其次，我们扩展了归约操作的实现，这是智能调度的一个内部步骤。算法2中的第5-7行显示了扩展。一旦在归约对象（第4行）上计算数据元素，添加的触发函数将计算用户定义的发送条件（第5行）。如果满足此条件，归约对象将立即转换为输出结果，然后从归约映射（第6行和第7行）中删除。通过这种优化，将需要维护的最大归约对象数从输入数据大小减少到窗口大小。


为了支持这种优化，用户只需要在派生归约对象类时覆盖触发器函数。Listing 5显示了移动平均值作为基于窗口的应用程序示例的实现。在本例中，归约对象计算窗口覆盖的元素数，并且发送条件可以是计数是否等于窗口大小。注意，由于每个输入元素都有多个窗口快照，这里我们使用gen_keys函数而不是表1中的gen_key来将每个元素映射到多个键。值得注意的是，这种优化不仅适用于基于窗口的原位分析，而且可以广泛应用于其他应用，甚至是离线分析。一个简单的例子可以是矩阵乘法，其中有助于单个输出元素的元素级乘法的数目是固定的。

5、实验结果

在本节中，我们将在多核和多核集群上评估系统的效率和可扩展性。首先，我们与Spark进行比较，Spark是一种流行的MapReduce实现（同时也提供了其他功能），它比Hadoop的性能最高可达100倍。其次，我们与使用低级API（MPI和OpenMP）编写的分析程序进行比较，以测量我们中间件的可编程性和开销。第三，随着节点和核心数量的增加，我们评估了Smart的可扩展性。接下来，我们将重点讨论时间共享和空间共享模式下的性能比较。最后，我们通过和禁用触发机制的实现比较，来评估基于窗口的分析程序优化的效果。

5.1 应用和环境安装

我们试验了9个应用程序，它们代表了6个不同的原位分析类——这些类以前被描述为第2.2节文献中的原位用例。分析和具体应用的类别有：1）可视化：网格聚合将网格中的元素分组为单个元素，以便进行多分辨率可视化；2）统计分析：直方图以等宽度的buckets呈现数据分布；3）相似性分析：反映相似性或两个变量之间的相关性，4）特征分析：logistic回归测量因变量和多个自变量之间的关系；5）聚类分析:k-means跟踪质心在不同时间段的移动；6）基于窗口的分析：在滑动窗口中移动均值和移动中值来计算平均值和均值，使用高斯核绘制高斯核密度估计密度图，Savitzky-Golay滤波器是众所周知的平滑滤波器。

上述分析程序可应用于各种模拟程序。然而，从性能的角度来看，模拟程序只有两个方面对我们很重要——模拟程序的内存需求，以及每次步骤输出或需要分析的数据量。因此，我们选择了两个具有非常不同输出量的开源模拟程序。具体来说，对于我们实验设置中的每个时间步骤，Heat3D都会生成大量数据，例如每个节点400 MB，而Lulesh的输出量适中，每个节点的输出量通常小于100 MB。

我们的实验在两个不同的集群上进行。第一个集群是具有多核节点的传统的集群，每个节点是一个Intel（R）Xeon（R）处理器，带有4个双核CPU（总共8核）。每个核心的时钟频率为2.53GHz，系统有12GB的主存。我们只在这个集群上使用分时模式进行实验，因为可以预期模拟程序将与所有可用的内核一起扩展。我们已经使用了多达512个核心（64个节点），第二个集群在每个节点上都有一个多核加速器，并且使用和比较了时间共享和空间共享模式。这个集群上的每个节点都有一个Intel Xeon Phi SE10P协处理器，有61个内核，时钟频率为1.1 GHz（总共488个内核）。协处理器的内存大小为8GB。

5.2 与Spark的性能比较

尽管Spark可以直接从内存中加载数据，可以解决数据加载不匹配的问题，但它无法克服第2.3节中提到的其他三个不匹配。因此，为了进行公平的比较，我们让Spark通过以下设置绕过所有其他不匹配：1）为了绕过编程视图不匹配，模拟程序被一个简单的模拟器代替——一个输出遵循正态分布的双精度数组元素的序列程序，此外，实验仅在一个8核的单节点上进行，2）使用模拟器也解决了内存约束不匹配问题，几乎不占用任何额外内存，因此分析程序没有严格的内存限制；3）为了避免编程语言不匹配，Spark使用的模拟器是用Java编写的。模拟输出40GB数据，超过800个时间步，用于分析的线程数从1到8不等。使用的Spark版本是1.1.1。

我们使用三个应用程序进行比较，参数如下：1）logistic回归：迭代次数和维数分别为10和15；2）k均值：质心数、迭代次数和维数分别为8、10和64；3）直方图：生成100个桶。特别是在Spark提供的示例代码的基础上，实现了logistic回归和k-均值。由于模拟代码没有并行化，这里我们只报告分析的计算时间。


结果如图5所示。在logistic回归、k均值和直方图分析中，Smart性能分别是Spark的21倍、62倍和92倍。造成如此大的性能差异的原因有三个方面。首先，和其他MapReduce实现一样，Spark在map操作之后会生成大量中间数据，在归约之前需要分组。相比之下，Smart在归约映射的位置执行所有归约，避免生成任何键值对，完全消除了分组的需要。此外，每个Spark转换操作由于其不变性而生成一个新的RDD（弹性分布式数据集）。相比之下，所有Smart操作都是在归约映射和组合映射上执行的，这些映射甚至可以用于迭代处理。此外，Spark序列化rdd并通过网络发送它们，即使在本地模式下也是如此，而Smart通过利用每个计算节点内的共享内存环境，避免将任何归约对象从归约映射复制到组合映射。

除了效率优势外，我们还可以看到，至少在共享内存环境中，Smart的性能要比Spark好得多，特别是在logistic回归、k-means和直方图上分别使用8个线程，Smart的加速比分别达到了7.95、7.71和7.96。这是因为，Spark只能允许用户控制工作线程的数量，而它仍然可以为其他任务（如通信和驱动程序的用户界面）启动额外的线程。特别是，我们可以看到，当8个工作线程被用于Spark执行时，速度增长变得相对较小，因为并非所有8个核心都被用于计算。相比之下，Smart不启动任何额外的线程，而且分析程序在所有线程上都可有效地并行化。

此外，Smart还可以实现比Spark更高的存储效率。事实证明，对于这三种应用程序，Spark始终占总内存（12GB）的90%以上，而Smart的内存消耗只有4.3%（528MB）。由于时间步长已经是512MB，Smart运行的分析程序实际上只消耗大约16MB的内存。注意，时间步长比内存容量小得多，因此Spark不太可能将输入写入到磁盘。

5.3 与低级分析程序的性能比较

在第二个实验中，我们将使用Smart编写的分析程序的可编程性和性能与在OpenMP和MPI中手动实现的分析程序进行了比较。我们使用与第5.2节中参数相同的logistic回归和k-均值。在8到64个不同数量的节点上处理1 TB的数据。


首先，通过降低实现和调试底层并行化细节的开销，Smart在简化应用程序开发方面是有效的。具体来说，对于k均值回归和lo-gistic回归，低层实现中打开的MP/MPI代码行分别有55%和69%被消除或被Smart转换为序列代码。请注意，这些低级代码通常是编程人员最容易出错的部分。

第二，我们希望了解出现的性能开销。图6显示了结果。首先，我们发现k-means的低层代码性能比Smart高9%。这种性能差异主要是由于Smart的全局组合所涉及的额外开销。在手动实现中，同步的数据存储在连续的数组中，全局同步可以通过单个MPI函数调用（MPI _Allreduce）完成。相比之下，Smart将精简对象非连续地存储在map结构中，因此全局组合需要对这些对象进行额外的标准化。请注意，我们遵循这样一种设计，以获得更好的适用性和灵活性，键不必是每个节点上的连续整数，并且可以支持归约对象的早期传送。第二，逻辑回归的性能差异是不明显的，因为在这个应用程序中只维护一个键值对，并且需要简单的序列化。总的来说，由于在实践中，总的处理成本主要由模拟程序控制，因此对比手工编写的低级代码，我们不希望从我们的框架中包含过多额外的开销。

5.4 扩展性评估

下一组实验通过使用Heat3D和Lulesh模拟以及九个分析程序来评估Smart的可伸缩性：1）网格聚合：网格大小为1000；2）直方图：存储桶数为1200；3）相互信息：每个变量的存储桶数为100，因此对二维空间进行了划分最多10000个单元格；4）logistic回归：迭代次数和维数分别为3和15；5）k平均值：质心数、迭代次数和维数分别为8、10和4；6）四个基于窗口的应用程序，包括移动平均值、移动中值，（高斯）核密度估计，以及Savitzky-Golay滤波器：窗口大小都是25。



首先，我们评估Heat3D上的总处理时间，因为我们将计算节点的数量从4个扩展到32个，每个节点上有8个线程用于模拟和分析。Heat3D通过100个时间步输出1TB数据。如图7所示，Smart在所有应用程序中平均可以实现93%的并行效率。特别是，我们甚至可以看到，对于某些使用16个节点的情况，可以实现超线性的可伸缩性。这种额外的加速是由于随着使用更多的计算节点，每个节点的内存需求减少所致。

其次，我们使用Lulesh来评估在64个节点上扩展线程数量的性能。Lulesh在93个时间步内输出1TB数据。每个节点用于模拟和分析的线程数高达8个。图8显示了结果。Smart前五个应用程序和其他四个基于窗口的应用程序的平均并行效率分别为59%和79%。并行效率的差异与这些应用的性质有关。例如，与前五个应用程序相比，基于窗口的应用程序的计算密集度更高，同步开销在总处理成本中所占的比重更小，因此具有更好的可伸缩性。

5.5 内存效率评估

接下来，我们将展示Smart设计（分时模式实现）的一个关键优势——即使没有额外的模拟输出拷贝，也可以支持原位分析。许多模拟程序实际上使用了机器上几乎所有可用的内存，不必要的数据复制会导致严重的性能下降，随着许多最新系统的出现，内存触发的比率已经降低。我们通过将性能与涉及数据拷贝的实现进行比较来评估这种影响。

在这组实验中，Heat3D在4个节点上输出1TB数据，Lulesh在64个节点上输出1TB数据。分别使用逻辑回归和实际信息作为Heat3D和Lulesh的分析程序，参数与第5.4节中的实验相同。改变模拟程序中的内存消耗。我们为每个模拟运行改变了时间步长，如下所示。对于Heat3D，我们可以改变3D问题尺寸的一维长度，从而线性地改变时间步长和内存消耗。特别是，时间步长从0.6GB到1.8GB不等。对于Lulesh，我们可以改变在每个节点上模拟的3D数组立方体的边缘大小，因此通过线性地改变边缘大小，我们可以导致内存消耗的三次增长。特别地，边缘大小在100到233之间变化，相应的时间步长在1.5GB到18.3GB之间变化。


如图9所示，我们可以看到，当我们的系统不涉及任何数据拷贝时，会有显著的性能改进。对于Heat3D，当时间步长大于1.4GB时，我们的系统可以比其他实现的性能高出11%。请注意，1.8 GB的时间步会使系统达到设置中的内存限制，因为2 GB的时间步会导致崩溃。对于边缘尺寸小于220的Lulesh来说，仅能获得高达7%的性能增益。这是因为每个节点上的模拟数据大小只有247MB，与内存容量（12GB）相比非常小。然而，当边缘大小达到233时，卷数据拷贝中的实现的内存消耗变得非常接近物理容量，因此其处理时间大大增加。对于这种情况，我们的系统可以实现5倍的加速。

5.6 时间共享和空间共享模式对比

在空间共享模式下，模拟和分析程序同时运行，在每个节点上使用两组独立的核心。到目前为止，我们所有的实验都只考虑了时间共享模式。现在，我们通过在多核机群上以分时模型和纯模拟程序的性能作为基线，来评估空间共享模式的效率。

在这组实验中，Lulesh在8个Xeon Phi节点上输出1TB数据。由于模拟结果不能从协处理器上的超线程中获益，因此在这种模式下，我们只使用了60个线程进行计算，并预留了1个内核用于调度和通信。直方图、k均值和移动中值被用作分析程序，其参数与第5.4节中的实验相同。除了分时和“纯模拟”版本之外，为了在空间共享模式下改变用于模拟和分析的核心数量，我们使用了5个不同版本，其中用于模拟的核心数量从50个到10个不等，其余的核心用于分析。

结果如图10所示。这里，“n_m”表示一个空间共享方案，n个线程用于模拟，m个线程用于分析。首先，虽然在空间共享模式下，最佳性能是由不同应用的不同方案实现的，但与“仅模拟”性能相比，即使计算量适中（如图10（c）所示），也不会产生太多开销。其次，在空间共享模式下，k均值和移动中值的最佳表现分别为“50_10”和“30_30”，分别比分时模式提高了10%和48%。这是因为当模拟达到其可扩展性瓶颈时，空间共享模式可以更好地利用部分核心。此外，我们还注意到，并非所有应用程序都能从空间共享模式中受益——空间共享模式中直方图的最佳性能（由“50”实现）比时间共享模式的性能低4.4%。这是因为直方图中的同步（或消息传递）成本相对高于其他两个应用程序，并且空间共享模式只能按顺序执行模拟和分析中的消息传递，以避免MPI中潜在的数据竞争，即在并发执行期间，一次只能有一个线程调用MPI函数。因此，我们得出结论，当模拟程序不能随着核数的增加而很好地扩展时，空间共享模式是有利的，但它不适合涉及频繁同步的应用。

5.7 基于窗口的分析程序优化评估

最后一组实验评估了基于窗口分析的优化效果。具体来说，我们将优化后的版本与未设置触发功能、因而无法支持归约目标提前发送的实现进行比较。在第一个实验中，我们使用Heat3D来模拟300GB的数据，并使用移动平均作为4n节点的分析程序。与之前的实验类似，我们在Heat3D中将时间步长从0.5变为1GB，移动平均窗口大小为7。在第二个实验中，Lulesh输出1TB数据，然后在64个节点上移动中值进行分析。在Lulesh中，每个节点的模拟数据大小从5.2到186MB不等，阵列立方体的边缘大小从60到200不等，移动中值的窗口大小为11。


结果如图11所示。我们可以看到，在这两个实验中，优化可以分别达到5.6和5.2的加速，这是因为内存效率。例如，通过这样的优化，对于移动平均应用程序，Smart维护的最大归约对象数可以减少1000000倍。此外，Heat3D中1 GB的时间步长或Lulesh中200的边缘大小可能会导致在没有触发机制的情况的实现下程序崩溃，这是由于极大的内存消耗导致的。

5.8 结论

值得注意的是，我们的系统是专门为科学分析而设计的。因此，虽然传统MapReduce中的字节流数据模型与科学分析中流行的数组数据模型不匹配，但我们的系统没有这样的不匹配。在我们的系统中，用于单元处理的数据块在本地保留阵列位置信息，因此它可以支持原位结构分析[57]，例如网格聚合和移动均值。此外，我们相信，我们的系统可以很好地支持各种科学分析，从适用性和性能角度来看。与通常需要点对点通信且无法融入MapReduce的科学模拟不同，许多复杂的分析程序仍然可以表示为MapReduce作业，甚至是细微差别的MapReduce管道（例如，相互信息）。与低层库中的手动实现相比，我们还证实了系统的高效性。

6、相关工作

近年来，随着I/O和计算能力之间的性能差距越来越大，原位科学分析引起了广泛关注。正如我们在第1节所述，对原位科学分析的研究主要集中在两个领域——应用和平台。对原位应用和算法进行了广泛的研究，包括索引、压缩、可视化和其他分析，如目标跟踪、有限元提取和分形维数分析。另一方面，提供平台形式的原位资源调度研究可分为时间共享和空间共享两类。分时平台的一个例子是GoldRush，它在相同的模拟核心上运行分析。由于模拟和分析是紧密耦合的，周期窃取对于性能优化至关重要。对于空间共享平台，模拟和分析的CPU利用率是去耦合的，而分析上的内存仍然保持不变。测试工作包括功能划分，系统Damaris和CoDS。相比之下，我们的工作在编程模型级别上探索了原位科学分析的机会。广泛地说，通过调整系统API和抽象并行化，原位应用程序可以从Smart中获益，而Smart可以部署在任何原位资源调度平台之上。

在更广泛的在线资源调度平台环境下，除了原位处理外，还研究了其他两种处理模式。第一种是在传输过程中处理，通过利用额外的资源，在线分析可以移动到与运行模拟的节点不同的专用节点。支持这种模式的平台包括PreDatA、GLEAN、JITStager和NESSIE。基于原位模式和在途模式可以互补的观察，第二种模式是混合处理模式。许多平台都支持这种模式，包括ActiveSpaces、DataSpace、FlexIO和其他平台。我们的系统可以集成到这些平台中，以支持在途或混合处理。

我们之前已经比较了各种MapReduce实现对于可能的原位分析的局限性，并且已经广泛地将我们的工作与Spark进行了比较。此外，iMR专门设计用于原位流处理。为了满足原位资源的限制，iMR侧重于有损处理和减载。相比之下，Smart是基于一个独特的API来减少内存需求的。此外，将MapReduce与科学分析相结合是最近一个备受关注的话题。SciHadoop集成了Hadoop和NetCDF库支持，允许使用MapReduce API处理NetCDF数据。SciMATE是一种MapReduce变体，可以透明地处理多种科学格式的科学数据。Zhao等人基于MapReduce实现了NetCDF数据的并行存储和存取方法。Kepler+Hadoop项目集成了MapReduce和Kepler，这是一个科学的工作流平台。Himach扩展了MapReduce以支持分子动力学轨迹数据分析。MARP和KMR是另外两个基于MapReduce的框架，它们可以支持MPI环境中的科学分析。SciHive可以像一些科学数据查询处理引擎一样支持查询科学数据，它是在MapReduce的基础上构建的。相比之下，Smart是为现场处理而设计的，其重点是解决数据加载不匹配、内存限制和其他类似问题。此外，Smart不受任何特定科学数据格式的约束，因为它的输入被认为驻留在（分布式）内存中。

7、结论

本文开发并评估了一个应用MapReduce风格的API开发原位分析程序的系统。我们的工作解决了从一个高效的高级API创建数据分析程序的一些挑战，该API可以与正在进行的模拟程序共享资源。

我们对我们的框架进行了广泛的评估。与Spark的性能比较表明，我们的系统至少比Spark高一个数量级，可以实现高效的原位分析。我们还表明，与低级实现相比，我们的中间件不会增加太多开销（通常小于10%）。此外，我们还通过在多核、多核节点的集群上以不同的现场模式运行不同的模拟和分析程序，展示了系统的功能性和可扩展性。平均并行效率可达93%。最后，我们展示了我们对基于窗口的原位分析的优化可以实现高达5.6的加速。Smart是一个开源软件，可以在https://github.com/sciponeer/Smart.git上访问源代码。

Smart:类MapReduce的原位科学分析框架相关推荐

  1. Hadoop之图解MapReduce与WordCount示例分析

    Hadoop的框架最核心的设计就是:HDFS和MapReduce.HDFS为海量的数据提供了存储,MapReduce则为海量的数据提供了计算. HDFS是Google File System(GFS) ...

  2. 战胜主导设计：一个整合性的分析框架

    文章目录 一.引言 二.相关文献回顾 三.主导设计形成后的新进入企业的SWOT分析 (一)NE的优势分析 (二)NE的劣势分析 (三)NE的机会分析 (四)NE的威胁分析 四.结论 五.参考文献 一. ...

  3. 现象类话题和策论32133框架

    作者:端木赐 链接:https://www.zhihu.com/question/56957544/answer/151420196 来源:知乎 著作权归作者所有.商业转载请联系作者获得授权,非商业转 ...

  4. xmpp协议抓包_开源网络抓包与分析框架学习-Packetbeat篇

    开源简介 packbeat是一个开源的实时网络抓包与分析框架,内置了很多常见的协议捕获及解析,如HTTP.MySQL.Redis等.在实际使用中,通常和Elasticsearch以及kibana联合使 ...

  5. MIT课程笔记①丨因果关系定义及潜在结果分析框架

    本文在MIT在线课程<3.Data Analysis for Social Scientists>中Causality(因果关系)部分课程的课件基础上,补充了相关信息.增加了个人理解,详细 ...

  6. powerdesigner 概念模型_“使用满足”分析框架下社交媒体用户持续使用行为的概念模型研究...

    推文信息 张敏,孟蝶,张艳."使用-满足"分析框架下社交媒体用户持续使用行为的概念模型研究[J].信息资源管理学报,2020,10(01):92-101. "使用-满足& ...

  7. 开源开放 | 图数据交互可视化分析框架 InteractiveGraph v0.3 版本发布

    图数据交互可视化分析框架 InteractiveGraph 日前发布 v0.3 版本,下载地址:https://github.com/grapheco/InteractiveGraph/release ...

  8. 【转】使用 F#、MapReduce 和 Windows Azure 分析日志文件

    http://msdn.microsoft.com/zh-cn/magazine/gg983490.aspx 使用 F#.MapReduce 和 Windows Azure 分析日志文件 Noah G ...

  9. 图数据交互可视化分析框架InteractiveGraph v0.3版本发布

    图数据交互可视化分析框架 InteractiveGraph日前发布v0.3版本,下载地址:https://github.com/grapheco/InteractiveGraph/releases/t ...

最新文章

  1. hbase设计方案1
  2. SQL Server 触发器学习总结
  3. 10代cpu装win7_11代CPU共26款型号全曝光：10核心确定没了
  4. 【Android】 Intent应用详解
  5. 转自： SparkConf 配置的概念和用法
  6. mysql 配置文件在哪_MySQL+MyCat分库分表 读写分离配置
  7. max file descriptors [4096] for elasticsearch process is too low, increase to at least [65535]
  8. 飞秋 包括《java就业培训课程》
  9. 使用go来做系统，如何比java node php 更 简单
  10. S5PV210体系结构与接口06：串口编程
  11. Java动态代理之InvocationHandler最简单的入门教程 1
  12. 离散数学及其应用第1章笔记总结
  13. JavaScript/JS闭包理解
  14. leetcode1055
  15. Win7系统怎么获取administrator权限？获取administrator权限的方法
  16. 共享打印机计算机睡眠时不可用,WIN10从睡眠中唤醒后共享打印机不可用
  17. mye连接mysql数据库_MySQL_如何在Java程序中访问mysql数据库中的数据并进行简单的操作，在上篇文章给大家介绍了Myeclip - phpStudy...
  18. 计算机图形学笔记 || 基本图形的扫描转换
  19. 学校举办朗诵比赛，邀请了10位评委为每一名参赛选手的表现打分，打分由random库中的随机函数进行，打分范围在[80,100]之间，打分的结果存放在列表lst_score中。编写程序，根据以下规则计算
  20. python 科大讯飞XFS5152CE语音合成芯片串口协议测试，机器人说话so easy

热门文章

  1. WXSS、WXML和WXS总结
  2. 关于 ZEGO 支撑 100 亿场高质量直播的秘笈
  3. ZEGO教程：如何快速搭建一个完整的Android直播平台
  4. c语言中学信息比赛常用题,中学生信息学奥赛c++编程
  5. 微信小程序快速提升访问量方法
  6. visio里去掉背景虚线
  7. java报价单_开票与报价或估算
  8. 阻塞队列 — DelayQueue源码分析
  9. 抖音APP揭秘：抖音号怎么从无到有？
  10. 横河川仪压力变送器故障代码_日本横河川仪EJA变送器故障原因及解决办法！