Distributed Tiling mechanism |
Traditional stand-alone caching technology is usually time-consuming, and the failure during tiling cannot recovery. SuperMap iServer proposes the distributed tiles generating and scheduling technology, and builds a distributed map tiles system with a TileMaster and multiple TileWorkers. Through the real-time communication with TileWorkers, TileMasters realize the dynamic allocation and real-time monitoring of the tiling task. In addition, SuperMap iServer supports distributed storage management of map tiles (presently FastDFS is supported) and a variety of distributed file systems.
One of the most important problems for the distributed tiling technology is how to completely divide the maps into several tasks, and let multiple computers work together. There are many ways of splitting tasks, e.g., a single tile is regarded as a task unit; every computer gets an average amount of tasks. However, these ways cannot meet with the parallel tiling requirements of high performance, dynamic extending, stability, etc. If a single tile is a tiling unit, because the granularity is too small, it will cause high frequency of communication and read&write among nodes, in this case, the efficiency of tiling will be sharply reducing. If the task unit is too big, it will take too long time to finish it, and it will be difficult to discover the problem occurred. Then the cost of re-tiling is too high, and the low-performance node will be a bottleneck for the tiling. So, the efficiency of tiling will also be affected.
The Distributed Map Tiling service provides an automated task-splitting strategy. According to the scale, geographic extent, tile size, and map complexity, iServer can divide big tiling task into proper grained task units. The principle of task-splitting is that: in a scale, on the basis of tile size, iServer can calculate the total tile number of row and column, then starting from the top-left corner, every N*N tiles is regarded as a task unit, in this case, most of task units can get the same workload. Yet, N is determined by the map complexity and tile size (including pixel size, file size). If the map complexity and tile size are bigger, the tile size will be smaller, and vise versa. By default, the tile format is PNG with 235*256; the reference value of N is 20, which means that there are 400 tiles in a task unit.
It is shown below. Every cell is a tile. If the task unit is 20*20, starting from the top-left corner, every 20*20 is regarded as a unit. If the final parts cannot be divided into 20*20 (e.g., in this sample, there remains 10 rows), in this case, the unit will be divided as 10*n≤400. So, in this sample, the 7th and 8th units are 10*30.
After splitting, the task units are stored in the task unit pool. TileMaster will dispatch task units to the idle TileWorkers. In general, the task splitting mechanism has following features:
1. Task units are separate and independent, so it is easier to dispatch task units to different TileWorkers.
2. The entire task are splitted automatically, even you don't need to set any parameters.
3. Task units are dispatched to TileWorkers automatically. Meanwhile, the TileMaster can monitor the status of TileWorkers.
For the Distributed Map Tiling system, there are one TileMaster and multiple TileWorkers. According to the map scale and geographic extent, TileMaster divides the tiling task into multiple fine-grained task units, and dispatches task units to proper TileWorkers. Every TileWorker executes the task units and report its working status to TileMaster.
The module design of TileMaster and TileWorker:
The real-time messaging between TilerMaster and TileWorkers makes the tiling task dynamically dispatched and monitored. The workflow of the Distributed Map Tiling system can be described as:
1. Users send the request on tiling to TileMaster. The request parameters include map service, map name, geographic extent, scale set, tile size, tile type, etc.
2. TileMaster generate a tiling task according to the request from users.
3. According to the task splitting mechanism, TileMaster splits the task into proper grained task units, and put them to the task pool.
4. TileWorker messages to TileMaster, reporting the status of TileWorker.
5. TileWorker fetches the task unit from the task pool from TileMaster.
6. TileMaster marks that this task unit is received by TileWorker.
7. TileWorker executes the task unit, and reports to TileMaster about the execution status, and place the tiles into a specified path.
8. TileMster receives the status information from TileWorker, and displays the status information to users in real time.
9. After the task unit is finished, TileWorker sends a report to TileMaster.
10. TileMaster verifies the tiling results from TileWorkder, and marks it as task finished.
11. After TileWorker is in idle status, it reports its status to TileMaster immediately, and repeat the steps from 4 to 10.
12. If TileMaster detects that a task unit is severely delayed, TileMaster re-marks this task unit as undispatched. Then, this task unit is received by another idle TileWorker, and follow the steps from 4 to 10.
13. After all task units are finished, TileMaster shows the task completed status and tile results information on its interface.
The dispatching and executing task units can be shown as the picture below. First, the TileWorker1 give a report to TileMaster about the idle status; As TileMaster receives the message, TileMaster dispatches the TaskUnit2 to this TileWorker1; TileWorker 1 executes the TaskUnit2, and outputs result tiles to the specified path. When TileWorker1 finishes TaskUnit2, TileWorker1 reports to TileMaster, and TileMaster checks TaskUnit2 and marks it, and dispatches TileWorker1 the next task unit.
During tiling, TileMaster monitors each TileWorkers in real time. Once TileMaster finds a task unit is pending or failed, TileMaster will dispatch this task unit to another TileWorker, which can avoid the influence on the entire tiling work due to one of TileWorkers' failure. In addition, in the Distributed Map Tiling syste, TileWorker node is flexible. That is to say, if a TileWorker is idle, it can apply for itself participating to the tiling task; Meanwhile, TileWorker can also request to cancel its tiling task.