并行处理

原文发布时间：2017-05-26 11:32:24

原文地址

下载：

ParallelProcessTINGenerator.fmwt

ParallelProcessRasterDEMGenerator.fmwt

介绍

FME利用多核处理器，提高PC电脑的并行计算。同时，它还利用了超线程，一种在一个实体核中，提供两个逻辑线程的技术。更多信息，请看：Parallel Processing documentation。

并行处理示例

所有的示例均在4核（8虚拟处理器），RAM 4GB和Windows XP Professional x64 版上测试。

RasterDEMGenerator

因为表面模型构建是一个繁复的过程，所以，使用并行处理是有益的。以下提供两个示例——点云生成DEM和TIN。

RasterDEMGenerator转换器输出端口是SurfaceModeller的一个子集。它能够根据输入的点/线和断裂线（breaklines）生成DEM栅格。

第一个模板生成DEM数据：

 

测试一，我们假设目标DEM栅格跟源LAS文件有相同的范围。因此，我们需要设置“Group By”（同时扮演“Process By”角色）为fme_basename，而SubstringExtractor转换器在该转换过程中无实际作用。

    我们使用不同的并行程度，结果如下（结果会因你的软/硬件配置而不同）：

No parallelism – 1m10s  Minimal – 44s  Moderate – 33s  Aggressive – 37s  Extreme – 37s

如上看来，Minimal没有将可用的处理能力完全发挥出来。最快的Moderate模式使用的时间大约是No parallelism的一半，而Aggressive和Extreme模式比Moderate消耗更多的资源，却没有取得更好的结果。

测试二，让DEM切片由2或3个LAS文件组成。因此，不能按照fme_basename分组，而是需要其他属性来处理分组。在这个例子中，LAS文件名的首字母代表了行号，故可以用它作为目标DEM的名字，同时，也可作为“Process By”的属性。我们用SubstringExtractor转换器提取首字母，并命名为_tile_id.

在RasterDEMGenerator转换器中，将“Group By”属性由fme_basename变更为_tile_id。运行结果如下：

No parallelism – 1m52s  Minimal – 1m01s  Moderate – 42s

在此例中，Aggressive和Extreme程度的并行与Moderate结果一样。出现此结果的原因为：处理个数为5，而可用的虚拟处理器为8.

从结果可知，Moderate级别的并行效率几乎是“No parallelism”的3倍。

对于更大的数据量（640个LAS文件，共3GB），结果如下：

No parallelism – 2h20m  Minimal – 54m 下载示例

TINGenerator

TINGenerator的输出同样是SurfaceModeller的一个子集。它接收点和断裂线，并输出TIN edges，triangles，TIN surface和TIN vertices.

当工作空间只连接一个TINGenerator生成表面时，其运行时间超过5分钟。这里，在执行并行前，我们如此设计工作空间——先用TINGenerator生成小的表面（为每个LAS文件生成表面），然后连接另一个TINGenerator转换器，将这些小的表面合并成一个表面。这样做，不仅能够移除切片边界的不规则表面，也让处理速度变得更快。

 

 

 

 

当我们将这两个TINGenerator连接起来之后，应用并行处理，可以获得优于之前10倍的效率：

No parallelism - 5m01s  2个TINGenerator: No parallelism – 55s  Minimal - 30s  Moderate – 28s  Aggressive - 26s Extreme – 28s

根据前面的测试结果，我们可以确定地说：并行处理允许更快地表面建模，并能应用在支持多线程的电脑上。下载示例

Buffering

现在，我们考虑将并行处理应用到矢量变换中。

在测试中，我们需要一个相当大的数据集。否则，启动FME实例的时间，在工作空间和用户间传输要素的时间，会把并行处理显示出的优势淹没掉。这里，我们读入一个包含美国道路主干道的Shape文件，并实现生成缓冲区的应用：我们希望对每条道路设置25米的缓冲值。

为了使用并行处理，我们需要找到一个合理的属性，来设置“Group By”分组。同时，需要考虑的是，在Bufferer中“Group By”的要素可能会按分组融合后输出。比如说，如果我们选择STATEFIPS作为Group-By属性，不仅会为每个州单独执行一个进程，还会为每个州单独输出一个缓冲区。显然，我们不希望出现这样的情况。并且，我们也几乎没见过在缓冲时，使用某个属性作为“Group By”和“Process By”的情况。

为了避免此类冲突，我们可以将转换器Bufferer封装在某个自定义转换器之中，并把它的并行处理参数（“Parallel Process By”和“Parallel Processing Level”）发布出来。在这种情况下，即使需要对每个组的要素单独缓冲，我们仍然可以将“Group By”应用到转换器Bufferer上。此外，我们完全可以不使用属性STATEFIPS，而选择一个不同的属性用于并行处理。

下述处理就能很好地说明为什么我们需要新的属性用于“Process By”。如果我们使用STATEFIPS属性，我们得到50个分组，也就意味着50个进程，这明显超出了我们“最快转换”的要求。对于这样的数据集，（如后面所述），其最优的分组数在8到16之间。

因此，我们可以利用已有属性，创建一个新的Process-By属性。比如，我们可以使用SubstringExtractor转换器提取STATEFIPS的第一个数字（6个分组）或第二个数字（10个分组）。

另外一个方法是使用ModuloCounter转换器，它在设置分组数方面的灵活性更大，我们可以通过参数“Count Maximum”来控制分组数。

 

缓冲450,000条道路线段的时间如下：

No parallelism – 2m51s  Moderate(4组) – 1m29s  Moderate(8组) – 1m30s  Moderate(16组) – 1m33s  Moderate(24组) – 1m36s  Moderate(50组) – 1m54s

    如上所示，最后测试的组，其每个组的要素量最少，但无法弥补多线程的开销（启动FME会话和在FME实例间传输要素）。如果我们加大每个组的要素数量，那么，这种开销就不那么明显了。 下载示例

Line Joining

我们还可以使用其他的转换器做并行处理。上面的工作空间包含了转换器LineJoiner。当我用这个转换器，对同样的数据集，测试并行处理时（封装在自定义转换器中），得到如下结果：

No parallelism – 1m11s  Moderate – 1m14s

我们可以得出结论：并行处理在通常的线连接上没有任何优势。但是，当数据集扩大到当前数据的5倍大时，结果就完全不同了：

No parallelism – 10m23s  Minimal – 6m06s  Moderate – 5m11s  Aggressive – 5m09s

除此之外，没有并行时，由于需要优化内存资源，电脑几乎瘫痪了一小会，而在并行处理时，优化过程并没有发生。因为分组要素越少，每组单独处理就不会达到阀值。该阀值是FME开始把数据从内存存储到磁盘的一个值。它能够保证其他的进程（比如网页浏览）不被影响太多。

Clipping

裁剪同样可以通过多进程优化效率。在下面的例子中，我们读入美国道路主干道数据（已经按照州分组连接好），然后将用县边界裁剪它们。这里，我们使用FIPS编号的第二个数字做分组：

 

    结果并不十分明显，但是，如果源数据集足够大，我们看到，在与LineJoiner相同的模式下，其多线程处理的效果更好：

～450,000个要素：

No parallelism – 1m44s  Minimal – 1m17s  Moderate – 1m17s  Aggressive – 1m18s

～2,250,000

No parallelism – 27m01s  Moderate – 7m33s 下载示例

点云操作

3D Clipping

在三维层面裁剪点云是过滤表面的一种简单方法。在FME2012之前，我们通过坐标转换（CoordinateSwapper）实现这种过滤（详情）——转换Y、Z坐标再做切片，允许按照最大点密度将它从点云的其他部分分离出来。

根据FME2012的3D裁剪介绍，我们可以裁剪点云。虽然介绍并不直观，但是主体思想与上述方法是相同的——将点云切成许多小的点云切片，然后分析落在每个切片里的点云数量：

 

 

一个小的点云示例结果如下：

No parallelism – 1m45s  Aggressive – 1m12s 下载示例

颜色反转

在FME2013之前，如果我们需要对点云的单个点做计算，必须将点云变成点。完成操作之后，又需要将点重新转变成点云。

处理每个单独的点是很慢的，但是通过并行处理，我们可以将效率提高3到5倍。我们需要做的是，将点云切成许多小的切片，以构造“process-by”分组。

这里，我们以反转点云颜色作为示例。注意，自定义转换器中不止有一个转换器——下图显示的不是整个工作空间，而是自定义转换器的内容：

 

处理效率显而易见：

No parallelism – 25m01s  Moderate – 5m20s

FME2013以及更高版本可以通过转换器PointCloudExpressionEvaluator对单个点云做计算，其性能有了更大的飞跃：

No parallelism – 3.1secs

只是，这里我们只考虑在自定义转换器中使用并行处理。下图是输入、输出：

 

 

下载示例

使用并行处理的几点建议

l  确保你有分组——如果没有在转换器的Group By处设置属性，则无法并行处理。

l  确保分组是独立的——如果要素之间相互依赖，分开处理会产生错误的结果。

l  保持较低的分组数——分组太多，导致执行的FME实例增多，则会将并行处理的优势消耗掉

l  当数据量足够大时，并行处理才有意义——对较小的数据集，运行多个FME的开销使得其效率低于单进程。

l  多个并行处理一起运行并不意味着更快——使用“Aggressive”需谨慎，使用“Extreme”更需谨慎。

l  对大部分转换过程来说，将“group by”和“process by”在功能上区分开是有意义的。这意味着我们需要为每个参数设置不同的属性。这可以通过将转换器（加上Group By）封装在自定义转换器中，并将“process by”提供出来而实现。

l  作并行处理的自定义转换器不一定只能包含一个转换器——你可以使用多个转换器。

l  设置“process-by”分组可以通过下述方式实现：转换器ExpressionEvaluator——当存在一个数字属性；转换器SubstringExtractor——根据字符串属性的某个子串分组；或者转换器ModuloCounter——当要素没有合适的属性。当然，也可以有其他的方法实现分组。