并行处理
原文發布時間：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——當要素沒有合適的屬性。當然，也可以有其他的方法實現分組。
總結
- 上一篇： java 持续交付_【Java架构：持续
- 下一篇： java文件损坏_java – 损坏的文