光速批处理——FME 2018的隐藏更新
原文链接：https://blog.safe.com/2018/03/batch-processing-2018-evangelist172/
批处理是数据转换和变换工具（如FME）非常重要的一个能力。所以当我们实现新的功能并忘记给批处理更多报道……好吧，我唯一的借口只能是我预计每个FME版本需要超过20人一年的工作来完成，且很难将所有的内容包含在一个小时的网络视频中！
在这个案例中被遗忘的更新是WorkspaceRunner转换器中的一个新参数。虽然很容易忘记，在正确的场景中正确的处理，它真的可以让FME批处理以光速飞行。
在我开始解释这个新参数之前，让我们先来看看WorkspaceRunner转换器，它做什么，以及如何做……
WorkspaceRunner：它是做什么的？
WorkspaceRuner只是一个转换器，它的作用是执行第二个工作空间：
这是将多个工作空间链接到一起的绝佳工具。工作空间A运行，然后调用工作空间B，运行后再调用工作空间C，依此类推。WorkspaceRunner甚至可以让你将值传递给链接中下一个工作空间的发布参数。这个对于很多场景来说非常有用，我们现在不需要这样做。
这是因为我们更关注它启动多个进程的参数：
正如我们在这个例子看到的一样，Concurrent Processes参数使转换器在批处理方面表现出色。
WorkspaceRunner: 批处理例子
我有一个包含多个文件的文件夹，我需要转换后上传到数据库。这里我将使用Shapefile格式进行读取，然后写入到PostGIS数据库。我可以读取所有的源数据，进行转换，并使用一个FME工作空间将其发送到一个数据库，如下所示：
但试图同时处理所有源数据有明显的缺点，这也是为什么我们更愿意使用WorkspaceRunner转换器来应用批处理。这个转换器允许批处理，该转换器允许批处理，因为它可以多次启动上述工作空间，每次处理不同的数据集。使用Concurrent Processes参数，甚至可以有多个并行运行的进程（每个进程一个CPU核为最优）。
该设置是“父-子”安排。这里父工作空间从文件夹中读取Shapefiles的名称（使用不太知名的Directory and File Pathnames读模块），然后将信息传递给WorkspaceRunner。
WorkspaceRunner转换器启动子工作空间（如上图所示），将Shapefile名称通过发布参数进行传递：
它甚至有一个已发布的参数，允许使用Shapefile名称来设置日志文件，所以我们可以获取每个子进程单独的日志。
在我的计算机上，如果WorkspaceRunner设置为使用4个并发进程，则主工作区将在三分钟内运行：
这通常不是运行的所有时间，因为子工作空间可能仍在运行。如果我查看子工作空间日志，将看到：
所以总的时间为3分29秒，这看起来还不错。
尽管如此，这个技术并不适用于较小的任务，比如子工作空间只需要1到2秒来运行的情况。而每个运行都将单独初始化一个FME进程：
启动和停止新的FME进程都需要时间，对于小的转换来说，启动子工作空间可能比运行它的时间还长！
因此这也是为什么我们在FME2018中创建一个新的参数……
WorkspaceRunner 2018: 新的参数
2018 WorkspaceRunner 有一个叫做Number of Workspaces per FME Process 的新参数(在之前的截图中我藏了起来):
这个参数允许我将多个子工作空间分配到一个进程。例如，如果我设置它为5，每个进程在停止并启动新进程之前将处理5个子工作空间。
在我的例子中我要读取80个Shapefile。有4个进程则每个进程20个文件。那样我只需要启动4个进程！没有更多的停止/开始。
如果参数设置为20，这时主日志提示：
显然所有进程在5秒内并没有结束，这只是启动子工作空间的时间。那些进程仍然在运行，这次每个需要做更多的任务。子工作空间的日志仍然显示：
总共花费1分钟53秒，比之前快多了。这是因为我们只启动了4个进程，而不是80个。
什么时候使用
例如，如果每个子进程需要10分钟运行，那么显然1.25秒并不是一个巨大的数量。在这种情况下，开始/停止时间不会太大。
当我使用运行上面的流程，使用WorkspaceRunner一次发送一个地址进行地理编码，每分钟运行19个要素，我所拥有的要素数量需要近12个小时。这还是使用4个并行处理的情况！
但是如果我使用Workspaces per Precess参数，效率变成每分钟225个要素！将我的处理时间下降至1个小时！也许“光速”的标题有一点过分了，但是……就我而言，12倍的速度时相当惊人的。
获得的经验是当你有许多小型任务，而不是大型任务时，这个参数最有用。
但是有一些需要考虑的其他方面……
WorkspaceRunner: 思考与局限
主要的思考是我了解了每个进程允许的工作空间数量。如果在我的Shapefile例子中，我设置参数为80，然后我得到一个处理所有80个任务的进程，我认为整个批处理概念无效！
所以Workspaces per Precess设置不能高于 任务÷进程（例如，80个任务÷4个进程=20）的值。
那它更小一点？也许你会像我一样担心，一个进程执行过多的子工作空间可能导致进程的数据过载；例如，数据累加。谢天谢地，情况似乎并非如此。实验表明，无论参数设置为20或10，每个过程都达到大致相同的水平。
但是我仍然担心，所以进行了一个在批量开始时就有大数据集的测试。一个进程如预期（如上PID4784）增加大小，但是一旦数据写出到数据库，内存就被释放。它并没有如我担心的那样在批处理的持续时间内保留该内存。
所以我的担心是不必要的。似乎理想值正好是 任务÷进程。当然你需要提前知道需要创建多少任务。如果你不这样做，你必须进行估计，因为Workspaces/Process参数不允许使用属性。我想我会提出一个增强请求，where the first feature sets the parameter.
但是我认为你需要了解你的数据集，它们的大小和组成，以及使用什么转换器。我的地理编码例子比较小而且没有数据写出，因此它不使用批处理运行会更快！所以你必须考虑是否需要批处理。
限制
其中一个限制是难以告知批处理什么时候结束，由于父工作空间在子工作空间之前完成。可以通过任务管理器查看FME是否还在运行。但是它确实意味着主工作空间被更快的使用并可以用于处理另外一个任务。
我找到的第二个限制是，同时处理的进程会锁定对方写出到相同的文件。因此如果每个进程添加到相同的数据集（如Geodatabase，GeoPackage或Excel等）那么一个进程可能会发现它被另一个进程锁定在数据集之外：
当然，这并不适用于写出单独的文件或数据集，也不适用于控制自己的锁定的数据库。例如，我能写出到PostGIS，一点问题也没有。
WorkspaceRunner: 结论
我不确定我们错过了如何在2018个版本的演示中给予更多的关注。但是我注意到Dale在一个2017校内网络研讨会中预览了它，如果你知道在哪里查看，它就一直在那里。
我希望如果你在FME中使用WorkspaceRunner转换器，你会发现它很有用。或者如果你没有尝试过使用WorkspaceRunner进行批处理进程，请尝试一下。在konwledgebase中有一个很好的例子，FME Q+A论坛上的优秀的人总是在那里帮助。