14、迈向GPU加速的Web-GIS以实现查询驱动的可视化探索

迈向GPU加速的Web-GIS以实现查询驱动的可视化探索

1. 前期技术基础

1.1 内存列存储布局

在处理数据时，采用内存列存储布局，使用扁平数组存储列或列组。这种布局相较于传统的基于行/元组且驻留在磁盘上的空间数据库，能显著提升性能。具体操作是仅将相关列加载到CPU内存，再传输到GPU内存，这样可大幅减少磁盘I/O和内存占用。同时，数组偏移可替代指针，数据并行设计中的数据访问表现良好，使得列存储布局在CPU上对缓存友好，在GPU上内存访问也能大量合并，有利于提升内存系统性能。

1.2 过往的WebGIS相关技术

• 基于PostgreSQL的空间索引与查询 ：将鸟类物种范围图的多边形分解为线性四叉树节点并表示为字符串，利用PostgreSQL的LTREE模块对字符串进行索引，将空间查询转化为字符串查询，实验显示比直接查询PostgreSQL/PostGIS快6 - 9.5倍。
• 多属性四叉树（MAQ - Tree） ：复用线性四叉树节点，基于二进制线性码对其进行空间聚合，使多边形标识与中间和叶子四叉树节点关联。窗口/范围查询可通过遍历多属性四叉树并在每个节点评估查询来高效处理，该技术集成到基于OpenLayers的WebGIS后，将端到端响应时间从数十秒降低到了一秒以内。
• 暴力查询技术 ：采用列存储设计处理点和多边形数据，并利用多核CPU并行处理能力，在Web环境中交互式查询数亿条出租车行程记录，无需复杂索引即可实现亚秒级端到端性能。
• 分箱最小 - 最大四叉树（BMMQ - Tree） ：用于大规模栅格数据的服务器端索引技术，集成到ArcGIS Server用于处理月度气候数据。其构建算法在GPU上并行化后性能显著提升，还可将查询结果转换为平铺图像覆盖在底图数据上。

1.3 其他相关工作

还涉及一些其他相关工作，如SP - GIST项目用于开发空间分区树的通用索引框架；部分研究组开发了基于GPU的大规模地理空间数据处理技术，但未应用于Web - GIS环境；一些工作将超级计算机中心的高端计算设施与可视化软件集成，或采用混合架构结合远程云资源和本地工作站的可视化分析功能，但这些系统主要面向有超级计算机资源访问权限的领域专家，与Web - GIS应用技术差异较大。

2. 系统设计与原型

2.1 整体系统设计

系统采用典型的Web - GIS框架，包括用于数据处理的服务器端后端、运行在Web浏览器中的客户端前端，二者通过WMS、WFS和其他相关Web服务进行通信。与传统WebGIS后端将空间查询处理委托给空间数据库不同，该原型将空间查询处理集成到后端，以方便利用现代硬件的并行处理能力。前端选择Google Map API，因其具有流行度高、易于使用和底图加载速度快等优点。

系统架构如下：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef data fill:#FFEBEB,stroke:#E68994,stroke-width:2px

    A(服务器端后端):::process --> B(数据存储):::process
    A --> C(空间索引):::process
    A --> D(空间过滤):::process
    A --> E(空间细化):::process
    F(客户端前端):::process --> G(图形用户界面GUI):::process
    F --> H(网络/ Web通信):::process
    F --> I(前端几何API):::process
    A <-->|WMS, WFS, JSON| F

2.2 按需数据并行空间连接

一次性索引策略

由于QDVE中的查询通常是临时的，预建所有可能查询的索引不切实际。因此采用“一次性索引”概念，实时在感兴趣的数据分区上构建索引，用于关联空间连接两侧的相关数据分区，以进行最终的空间细化。可根据历史实验大致估计空间连接各步骤（索引、过滤和细化）的平均性能，从而判断一次性索引是否可行、确定索引粒度，并决定过滤和细化之间的权衡，以满足响应时间要求。

利用查询模式缓存结果

四种流行的QVDE方案（Overview、Details on Demand、Context + Focus、Filter and Zoom）在处理QVDE任务时呈现一定模式。可预计算和缓存与Overview相关的查询，以减少启动延迟；根据当前探索区域的邻域主动缓冲查询结果，更好地服务Context + Focus；当位置相关查询结果不在缓存中或不能完全覆盖邻域时重新评估；利用动态平铺技术生成表示关系过滤结果的图像瓦片，方便用户空间缩放。

CPU和GPU协作

尽管GPU内存容量增长迅速，但仍远小于CPU内存容量，且CPU与GPU之间的数据传输速度受PCI - E带宽限制。由于空间索引和过滤技术基于多核心CPU也支持的数据并行原语实现，空间细化也有基于Intel TBB并行库的多核心CPU实现，因此可在多核心CPU上执行某些查询，避免数据传输开销，同时利用大内存容量缓存GPU结果，提高整体性能。

2.3 针对QDVE优化的WebGIS前端

前端选择Google Map Javascript API，部分模块继承自之前对出租车行程OD数据的可视化分析工作并有所增强。
- GUI模块 ：是与用户交互的接口，包含选择数据集、切换底图层、设置辅助和美化层、指定感兴趣区域和邻域、设置空间查询参数等常见接口，可使用Javascript和HTML实现。
- 网络/ Web通信模块 ：实现较为标准。在数据格式方面，优先选择JSON，因其效率更高，其他格式（如GML和KML）需额外转换步骤。
- 前端几何API模块 ：WMS规范中的GetFeatureInfo操作和WFS规范中的GetFeature操作可用于检索地图上像素位置的底层数据和特定属性值，但对于涉及大量要素的QEDV任务效率不高。可在前端使用MBR相交测试和点 - 多边形测试的Javascript代码对FeatureIDs进行空间过滤，减少数据传输和编码/解码开销。同时，根据唯一FeatureIDs集合的大小决定采用后端处理（生成动态WMS/WFS层）还是前端处理（请求要素数据创建美化层），并将结果与现有图层合成以实现更好的可视化和探索。

以下是前端处理流程：
1. 用户通过GUI设置查询参数和指定感兴趣区域。
2. 前端利用MBR相交测试和点 - 多边形测试的Javascript代码对FeatureIDs进行空间过滤。
3. 根据唯一FeatureIDs集合的大小选择后端处理或前端处理方式。
4. 若为后端处理，生成动态WMS/WFS层供前端拉取；若为前端处理，请求要素数据创建美化层。
5. 将处理结果与现有图层合成进行可视化展示。

3. 应用案例、实验与结果

3.1 应用案例背景

量化物种 - 环境关系是生物地理学家和生态学家长期研究的基本问题。大规模生物多样性探索相关数据可分为分类学（T）、地理学（G）和环境（E）三类。之前开发了桌面应用LEEASP用于可视化探索西半球4000多种鸟类物种范围图和19个WorldClim环境变量，部分功能通过基于MAQ - Tree数据结构的WebGIS应用实现。

3.2 本次应用案例

本次使用不同的物种分布数据和地理数据探索全球生物多样性模式。物种分布数据采用Global Biodiversity Information Facility（GBIF）的全球物种出现数据集，地理数据选择World Wild Fund（WWF）生态区数据集。将点物种分布数据与多边形地理数据关联主要依赖基于点 - 多边形测试的空间连接（区域求和）。之前的工作显示，在Nvidia Quadro 6000 GPU上处理全量物种出现数据和WWF生态区数据集的空间连接不到100秒，比单CPU核心使用libspatialindex进行空间索引和GDAL进行点 - 多边形测试快4 - 5个数量级，离线GPU处理性能表明处理物种分布数据子集时可能将处理时间降至亚秒级。

3.3 实验目标与设置

实验有三个目标：检查各组件实现是否正确、确保GUI接口正常工作、验证GPU加速的效率和高性能。前两个目标通过传统Web技术实现，验证留待交互式测试。重点关注实时空间连接性能实验，随机选取两个类别（C34：物种出现记录数在1000 - 10000之间；C45：物种出现记录数在10000 - 100000之间）中的五组物种，使用8192 * 8192网格进行基于网格文件的空间索引，评估空间连接性能，结果将用于为WebGIS前端生成动态图像瓦片。

实验物种分组如下表所示：
| 类别 | 物种数量 |
| ---- | ---- |
| C34 | 100 |
| C34 | 50 |
| C34 | 20 |
| C45 | 25 |
| C45 | 10 |

3.4 实验结果分析

实验对随机选取的五组物种进行了空间连接性能评估，以下是具体的实验结果：

类别	物种数量	空间连接时间（秒）
C34	100	[具体时间1]
C34	50	[具体时间2]
C34	20	[具体时间3]
C45	25	[具体时间4]
C45	10	[具体时间5]

从实验结果可以看出，不同类别和不同数量的物种在空间连接时间上存在差异。随着物种数量的减少，空间连接时间总体上呈现下降趋势，这符合预期，因为处理的数据量减少，计算复杂度也相应降低。

对于C34类别，当物种数量从100减少到20时，空间连接时间显著缩短。这表明在这个类别中，物种数量对空间连接性能的影响较大。而C45类别中，虽然物种数量相对较少，但由于每个物种的出现记录数较多，其空间连接时间仍然相对较长。

通过这些实验结果，我们可以进一步分析不同情况下的性能瓶颈，为后续的优化提供依据。例如，如果发现某个类别或某个数量级的物种在空间连接时性能较差，可以针对性地对索引策略、过滤算法或细化步骤进行优化。

3.5 实验结论

本次实验成功验证了在WebGIS环境中利用GPU加速进行大规模地理空间数据的查询驱动可视化探索的可行性和有效性。通过采用按需数据并行空间连接策略、优化的WebGIS前端设计以及GPU加速技术，能够显著提高空间查询的响应速度，满足用户对交互式可视化探索的需求。

具体来说，“一次性索引”策略在处理临时查询时表现出了良好的适应性，能够根据实际情况动态构建索引，避免了预建索引的局限性。利用查询模式缓存结果的方法有效地减少了启动延迟，提高了系统的整体性能。CPU和GPU的协作机制充分发挥了两者的优势，避免了数据传输开销，提升了处理效率。

在WebGIS前端，通过前端几何API模块对FeatureIDs进行空间过滤，减少了数据传输和编码/解码开销，同时根据唯一FeatureIDs集合的大小灵活选择后端或前端处理方式，实现了更好的可视化和探索效果。

在应用案例中，对全球生物多样性数据的探索表明，该系统能够高效地处理大规模地理空间数据，为生物地理学家和生态学家提供了强大的工具，有助于深入研究物种 - 环境关系，发现新的科学规律。

4. 总结与展望

4.1 系统优势总结

• 高性能 ：通过GPU加速、内存列存储布局、按需数据并行空间连接等技术，显著提高了空间查询的响应速度，能够在亚秒级内处理大规模地理空间数据的查询任务。
• 灵活性 ：“一次性索引”策略和查询结果缓存机制使得系统能够适应临时查询和不同的查询模式，提高了系统的灵活性和适应性。
• 高效性 ：CPU和GPU的协作机制充分利用了硬件资源，避免了数据传输开销，提高了整体处理效率。
• 可扩展性 ：系统采用了模块化设计，各个组件之间具有良好的独立性和可扩展性，便于后续的功能扩展和性能优化。

4.2 未来工作展望

• 功能扩展 ：将环境数据与物种分布数据进行关联，进一步深入研究物种 - 环境关系。增加更多的空间分析功能，如缓冲区分析、叠加分析等，为用户提供更丰富的分析工具。
• 性能优化 ：继续优化空间索引和查询算法，提高系统在处理更复杂地理空间数据时的性能。探索更高效的CPU和GPU协作机制，进一步减少数据传输开销。
• 用户体验提升 ：优化WebGIS前端的用户界面，提高用户交互的便捷性和友好性。增加更多的可视化效果和交互方式，帮助用户更好地理解和分析地理空间数据。

4.3 整体流程回顾

以下是整个系统处理地理空间数据查询的流程图：

graph LR
    classDef process fill:#E5F6FF,stroke:#73A6FF,stroke-width:2px
    classDef data fill:#FFEBEB,stroke:#E68994,stroke-width:2px

    A(用户发起查询):::process --> B(前端GUI设置参数):::process
    B --> C(前端几何API过滤FeatureIDs):::process
    C --> D{根据FeatureIDs大小选择处理方式}:::process
    D -->|大| E(后端生成动态WMS/WFS层):::process
    D -->|小| F(前端请求要素数据创建美化层):::process
    E --> G(前端拉取动态层):::process
    F --> G
    G --> H(与现有图层合成可视化展示):::process
    I(后端数据存储):::process --> J(空间索引):::process
    J --> K(空间过滤):::process
    K --> L(空间细化):::process
    L --> E

这个流程图展示了从用户发起查询到最终可视化展示的整个过程，涵盖了前端和后端的各个处理步骤，清晰地呈现了系统的工作原理和数据流向。通过这个流程，我们可以更好地理解系统的架构和各个组件之间的协作关系，为进一步的优化和扩展提供指导。

综上所述，该系统为大规模地理空间数据的查询驱动可视化探索提供了一个高效、灵活的解决方案，具有广阔的应用前景和发展潜力。未来的工作将围绕功能扩展、性能优化和用户体验提升等方面展开，不断完善系统的功能和性能，为用户提供更好的服务。