从 TB 到 PB 级：国产化时空大数据平台的存储、计算与可视化全栈实践

引言

随着数字政府、智慧城市、自然资源数字化转型的全面推进，时空数据已成为继政务数据、业务数据之后的第三大核心数据资产。从国土空间规划的全域土地管控，到智慧城市的人流热力实时监测，再到连锁零售的智能选址分析，时空大数据正在千行百业释放核心价值。

与此同时，时空数据的规模正从 TB 级快速向 PB 级跃迁：单地级市的国土空间矢量数据可达数十 TB，城市级摄像头、车辆轨迹、物联网传感器的时空流数据日增量可达 TB 级，传统基于文件型 GIS（如 Shapefile、GeoTIFF）+ 关系型数据库的架构已彻底无法承载海量并发访问与复杂空间计算需求。叠加国产化信创替代的政策要求，自主可控、分布式、高性能的全栈时空大数据平台，已成为政企数字化建设的刚需。

本文将基于我们在多个省级、市级国土空间与智慧城市项目中的落地实践，从架构选型、分布式存储优化、空间计算引擎实现、服务化接口设计、BI 可视化融合五个维度，完整拆解国产化时空大数据平台的技术落地路径，同时给出真实项目中的性能实测数据与踩坑经验，为同领域技术从业者提供可复用的工程化参考。

一、时空大数据的核心技术挑战与全栈架构选型

1.1 时空数据的独有技术特性

时空数据区别于传统业务数据的核心在于其双重维度属性 与多源异构性，这也是其技术复杂度的根源：

海量性与高增速：单类空间要素（如建筑、道路、水系）的矢量数据可达千万级面片，城市级实时轨迹数据每秒新增数十万条点位，栅格遥感影像单景可达 GB 级，年增量轻松突破 PB 级。
空间维度的计算复杂性：传统 SQL 仅需处理数值、字符串的逻辑运算，而空间计算需处理点、线、面的拓扑关系判断（相交、包含、邻接）、缓冲区分析、叠加分析、距离计算，单次计算的复杂度远高于普通查询。
多源异构性：数据格式涵盖矢量（SHP、GeoJSON、GDB）、栅格（TIFF、IMG）、轨迹数据、三维倾斜摄影数据，来源涵盖卫星遥感、地面测绘、物联网传感器、业务系统上报，数据标准不统一、质量参差不齐。
并发访问的极端性：政务场景下，全域空间数据查询需支撑数百名规划人员同时在线分析；应急场景下，灾害监测系统需承受峰值数万 QPS 的实时空间查询请求。

1.2 传统技术架构的瓶颈

当前行业内大量存量系统仍采用 "文件存储 + 单体 GIS 服务器 + 关系型数据库" 的传统架构，在 PB 级数据场景下已暴露不可逾越的瓶颈：

文件 IO 瓶颈：以 Shapefile、文件 GDB 为代表的文件型数据，仅支持单线程读写，无法分布式并行计算，数据量超过 100GB 后读写性能呈断崖式下降。
数据库空间能力不足：传统 MySQL、PostgreSQL 单机数据库的空间函数性能有限，无法支撑千万级面片的叠加分析，且单机存储容量存在物理上限，扩容成本极高。
计算与存储耦合：传统 GIS 引擎（如 ArcGIS Server）采用单体架构，计算与存储绑定，无法按需弹性扩缩容，高并发场景下极易出现服务宕机。
国产化适配困难：大量国外 GIS 软件与信创环境兼容性差，无法满足政务项目的安全可控要求，且授权成本居高不下。

1.3 国产化全栈分布式架构选型

针对上述痛点，我们经过多轮技术验证与压测，最终选型了一套全栈国产化、存算分离、云原生的时空大数据架构，自底向上分为五层：

基础设施层：基于鲲鹏 920 芯片服务器 + 麒麟 V10 / 统信 UOS 操作系统，支持物理机、虚拟机、容器化多种部署模式，完全满足信创三级等保要求。
分布式存储层：以 TiDB 分布式数据库为核心底座，承载结构化空间属性数据与矢量空间数据；MinIO 分布式对象存储承载栅格影像、三维模型等非结构化大文件，实现存算分离。
空间计算引擎层：自研分布式空间计算内核，兼容 OGC 标准空间函数，支持离线批量计算与实时流计算双引擎；离线计算基于 Spark 分布式框架，实时计算基于 Flink 流处理引擎，直接对接 TiDB 与 MinIO 数据源。
服务接口层：基于 FastAPI 构建高性能 RESTful 地理服务接口，提供要素查询、空间分析、地图瓦片、数据管理等标准化接口，支持千级 QPS 并发访问。
可视化应用层：对接有数 BI 等国产 BI 工具，实现 GIS 地图与业务数据的深度融合，支持拖拽式搭建时空看板、热力分析、选址模型等业务应用，降低数据使用门槛。

该架构的核心优势在于：完全自主可控、存储与计算均可水平扩展、单集群可无缝支撑 PB 级时空数据，同时兼容主流 GIS 标准，可平滑替代国外同类产品。

二、分布式存储层：TiDB 支撑 PB 级时空数据的优化实践

存储层是时空大数据平台的基石，其性能直接决定了整个平台的查询与计算效率。我们选择 TiDB 作为核心存储底座，核心原因在于其兼容 MySQL 协议、支持分布式事务、可水平扩展、国产化适配完善，且 7.0 以上版本对空间索引与空间函数做了深度优化，完全满足空间数据的存储与查询需求。

2.1 时空数据模型设计

针对不同类型的时空数据，我们设计了差异化的存储模型，避免一刀切导致的性能浪费：

（1）矢量要素数据模型

矢量数据（点、线、面）是最核心的空间数据，采用 "空间字段 + 属性字段" 的宽表设计，直接存储于 TiDB 行存表中：

sql 复制代码

CREATE TABLE `land_use` (
  `id` bigint NOT NULL COMMENT '要素唯一ID',
  `geom` geometry NOT NULL COMMENT '空间几何字段',
  `land_code` varchar(32) DEFAULT NULL COMMENT '用地分类编码',
  `land_name` varchar(64) DEFAULT NULL COMMENT '用地分类名称',
  `area` decimal(18,2) DEFAULT NULL COMMENT '用地面积',
  `city_code` varchar(16) DEFAULT NULL COMMENT '所属行政区划编码',
  `update_time` datetime DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
  SPATIAL INDEX `idx_geom` (`geom`),
  INDEX `idx_city_code` (`city_code`),
  INDEX `idx_land_code` (`land_code`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='国土空间用地分类表';

核心设计要点：

采用 Geometry 类型存储空间几何，直接支持 OGC 标准的 ST_系列空间函数；
行政区划编码作为分区键，按地市进行表分区，实现查询时的分区裁剪，大幅提升地域类查询性能；
空间索引与业务属性索引分离，避免索引膨胀影响写入性能。

（2）时空轨迹数据模型

车辆、人员、物联网设备的轨迹数据具有时序性强、写入量大、查询按时间 + 空间范围筛选的特点，采用 TiDB 的时序表设计，结合 Geohash 编码实现快速空间筛选：

sql 复制代码

CREATE TABLE `vehicle_track` (
  `id` bigint NOT NULL,
  `vehicle_id` varchar(32) NOT NULL COMMENT '车辆ID',
  `lng` double NOT NULL COMMENT '经度',
  `lat` double NOT NULL COMMENT '纬度',
  `geohash` varchar(12) NOT NULL COMMENT '空间Geohash编码',
  `speed` decimal(8,2) DEFAULT NULL COMMENT '车速',
  `time` datetime NOT NULL COMMENT '定位时间',
  PRIMARY KEY (`time`, `id`),
  INDEX `idx_vehicle_time` (`vehicle_id`, `time`),
  INDEX `idx_geohash_time` (`geohash`, `time`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4
PARTITION BY RANGE (TO_DAYS(`time`)) (
  PARTITION p202606 VALUES LESS THAN (TO_DAYS('2026-07-01')),
  PARTITION p202607 VALUES LESS THAN (TO_DAYS('2026-08-01'))
) COMMENT='车辆轨迹表';

核心优化思路：

按时间按月分区，历史冷数据可直接归档删除，无需昂贵的删表操作；
用 Geohash 字符串替代原生空间索引，写入性能提升 40% 以上，且满足按矩形范围的快速筛选需求；
主键采用时间 + ID 的聚簇索引，保证时序数据写入的顺序性，避免随机 IO。

（3）栅格与大文件数据模型

遥感影像、倾斜摄影模型等大文件，采用 "MinIO 对象存储 + TiDB 元数据表" 的分离存储方案：TiDB 仅存储文件路径、空间范围、分辨率、拍摄时间等元数据，文件本体存储于 MinIO 中，通过 S3 协议访问。该方案既利用了对象存储的低成本、高扩展性优势，又通过 TiDB 的空间索引实现了按空间范围快速检索影像文件。

2.2 空间索引的优化与踩坑

TiDB 的空间索引基于 R 树实现，在实际项目中我们踩过不少坑，总结出以下优化经验：

控制几何对象复杂度：单个几何对象的顶点数不宜超过 1000 个，复杂面要素（如行政边界）需提前进行简化处理，否则空间索引的查询效率会大幅下降，甚至出现索引失效。
避免全表空间查询：所有空间查询必须叠加行政区划、时间范围等二级索引条件，先通过属性索引裁剪数据范围，再进行空间计算，否则会触发全表扫描，查询耗时从毫秒级升至分钟级。
批量写入时关闭索引：千万级以上的矢量数据批量导入时，先删除空间索引，数据写入完成后再重建索引，导入速度可提升 3-5 倍；同时采用 TiDB 的 Lightning 工具进行批量物理导入，比常规 SQL 写入快 10 倍以上。
合理设置空间索引精度：根据业务场景选择合适的空间分辨率，城市级场景用 7 位 Geohash（精度约 150 米）即可，无需追求过高精度，避免索引体积过大。

2.3 国产化环境下的性能调优

在鲲鹏芯片 + 麒麟操作系统的信创环境中，我们通过以下调优手段，将 TiDB 集群的整体性能提升了 35%：

硬件适配调优：开启鲲鹏芯片的 NUMA 亲和性绑定，将 TiDB、TiKV 进程与 CPU 核一一绑定，避免跨 NUMA 节点访问带来的性能损耗；配置大页内存，减少内存碎片。
TiKV 参数调优：针对空间数据写入多、范围查询多的特点，调高 raftstore 的线程数，将 rocksdb 的块大小调整为 64KB，适配空间数据的大范围扫描场景；开启异步 IO，提升磁盘读写效率。
存储介质选型：热数据采用 NVMe SSD 存储，冷数据采用 SATA HDD 存储，通过 TiDB 的冷热数据分离功能自动调度，在保证性能的同时降低 30% 以上的存储成本。

三、空间计算引擎：高性能时空分析的核心实现

存储解决了数据存放的问题，而空间计算引擎则决定了平台的数据分析能力。传统 GIS 引擎的计算能力受限于单机架构，无法支撑海量数据的批量空间分析，我们基于分布式计算框架，自研了一套兼容 OGC 标准的分布式空间计算引擎，支持离线批量分析与实时流计算双场景。

3.1 离线分布式空间计算

离线计算主要面向国土空间规划、土地利用分析、批量热力图生成等场景，数据规模大、计算复杂度高，基于 Spark 分布式框架实现。

（1）核心计算算子实现

我们基于 JTS 拓扑计算库，封装了全套分布式空间计算算子，支持在 Spark 集群中并行执行：

拓扑关系算子：相交、包含、邻接、相离等 9 种拓扑关系判断，支持千万级要素两两叠加计算；
空间分析算子：缓冲区分析、叠加分析、裁剪、融合、联合分析等经典 GIS 分析功能；
统计分析算子：空间聚合统计、密度分析、热力图计算、选址评分模型等业务型算子。

（2）分布式空间连接优化

空间连接（Spatial Join）是空间计算中最耗时的操作，传统笛卡尔积计算的时间复杂度为 O (n²)，在海量数据下完全不可用。我们采用空间分区过滤 + 索引裁剪的两级优化方案，将计算效率提升了两个数量级：

第一级：空间分区过滤 采用 K-Means 空间聚类算法，将全域数据划分为若干个空间分区，保证每个分区的数据量均匀；进行空间连接时，仅对位于同一分区的要素进行计算，过滤掉 90% 以上的不相关要素。
第二级：索引裁剪 在每个分区内部，基于 STR 树构建本地空间索引，先通过索引快速筛选出可能相交的要素候选集，再进行精确的拓扑计算，进一步减少计算量。

通过该优化方案，在 1000 万建筑面要素与 5000 万宗地面要素的叠加分析场景中，10 节点 Spark 集群仅需 8 分钟即可完成计算，而传统单体 GIS 引擎需要耗时 12 小时以上，性能提升超 90 倍。

3.2 实时流空间计算

实时计算主要面向人流热力监测、车辆轨迹分析、应急事件定位等场景，要求毫秒级延迟，基于 Flink 流处理引擎实现。

（1）实时热力图计算架构

以城市人流实时热力图为例，整体计算流程如下：

数据接入：手机信令、WiFi 探针、摄像头识别的人流数据，通过 Kafka 消息队列实时接入 Flink 计算引擎；
实时清洗：对原始点位数据进行去重、纠偏、坐标转换，过滤异常点位；
窗口聚合：采用 5 分钟滚动窗口，按 Geohash 网格对点位进行聚合统计，计算每个网格的人流数量；
结果下沉：聚合结果实时写入 TiDB，同时更新地图瓦片缓存，供前端可视化调用。

该架构支持单城市每秒 50 万条点位的实时处理，端到端延迟低于 10 秒，完全满足城市实时监测的业务需求。

（2）时空轨迹实时围栏判断

电子围栏判断是轨迹场景的核心需求，我们在 Flink 中实现了广播流状态的围栏判断方案：将围栏面要素作为广播流分发到所有计算节点，本地构建 R 树索引；轨迹数据流逐条流入时，先通过 R 树快速匹配候选围栏，再进行精确的包含判断，单节点每秒可处理 10 万 + 条轨迹的围栏判断，延迟低于 1 毫秒。

3.3 AI 与空间计算的融合落地

随着 AI 技术的发展，传统空间计算正在向智能空间计算演进，我们在平台中融入了 AI 能力，实现了两类核心场景的落地：

时空预测：基于历史人流、车流时序数据，结合 LSTM 时序预测模型，实现未来 24 小时的城市人流热力预测，为交通调度、商业运营提供决策支撑；
智能选址：融合 POI 数据、交通数据、人口数据，通过 XGBoost 模型构建门店选址评分模型，自动输出最优选址区域，替代传统的人工经验分析，选址效率提升 80% 以上。

四、服务与可视化层：从数据到业务价值的最后一公里

数据与计算能力最终需要通过服务与可视化交付给业务用户，这一层的核心目标是：高性能、标准化、低门槛。

4.1 基于 FastAPI 的高性能地理服务接口

我们采用 FastAPI 构建了全套 RESTful 地理服务接口，替代传统的 GeoServer 等单体 GIS 服务，性能提升显著，且更易扩展。

（1）核心接口体系

接口完全遵循 OGC API 标准，分为四大类：

要素服务接口：支持按 ID、属性、空间范围查询矢量要素，支持分页、排序、属性过滤，返回 GeoJSON 格式；
地图瓦片接口：支持矢量瓦片（MVT）与栅格瓦片，实时从 TiDB 中渲染生成，支持自定义样式；
空间分析接口：提供缓冲区、叠加分析、热力图等常用分析功能的 API 接口，业务系统可直接调用；
数据管理接口：支持数据上传、编辑、删除、版本管理，实现空间数据的全生命周期管理。

（2）接口性能优化

为了支撑高并发访问，我们做了多层优化：

连接池优化：采用 SQLAlchemy 连接池管理 TiDB 数据库连接，避免频繁创建销毁连接，接口响应速度提升 30%；
多级缓存：热点瓦片、常用查询结果存入 Redis 缓存，缓存命中率可达 70% 以上，大幅降低数据库压力；
异步并发：利用 FastAPI 的异步特性，IO 密集型接口采用异步处理，单节点可支撑上千并发连接，远超传统同步架构。

4.2 GIS 与 BI 的深度融合方案

传统 GIS 平台与 BI 系统相互割裂，空间数据无法与业务数据联动分析，这是很多政企客户的核心痛点。我们实现了空间数据与有数 BI 的深度打通，打造了 "地图 + 看板" 一体化的时空分析能力。

（1）数据层打通

TiDB 中的空间数据与业务数据统一建模，通过行政区划编码、空间 ID 进行关联，BI 工具可直接读取同一份数据，无需数据同步与导出，保证数据一致性。

（2）可视化层联动

实现了地图组件与 BI 图表组件的双向联动：点击地图上的某个区域，所有业务图表自动筛选对应区域的数据；点击业务图表中的某个分类，地图自动高亮对应空间要素。该能力大幅提升了数据分析效率，用户无需在多个系统间切换，在一个看板中即可完成时空一体化分析。

（3）低代码搭建

支持用户通过拖拽方式自主搭建时空看板，无需代码开发：从组件库中拖拽地图、柱状图、饼图、表格等组件，配置数据来源与联动关系，几分钟即可生成一个业务分析看板，大幅降低了时空数据的使用门槛。

4.3 前端海量数据渲染优化

当浏览器端需要展示百万级以上的空间要素时，传统 Canvas 渲染会出现严重的卡顿，我们采用 WebGL 渲染技术，结合矢量瓦片、分层加载策略，实现了千万级要素的流畅渲染：

矢量瓦片分层加载：低缩放级别加载聚合后的概览数据，高缩放级别加载详细要素，避免一次性加载全量数据；
WebGL 硬件加速：基于 MapLibre GL JS 渲染引擎，利用 GPU 进行图形渲染，百万级点要素渲染帧率可达 60FPS；
样式优化：采用分层样式、避让算法，避免高缩放级别下图层重叠杂乱，保证可视化效果的同时兼顾性能。

五、落地案例与性能实测

5.1 项目背景

我们在某地级市国土空间 "一张图" 项目中落地了上述全栈架构，项目承载了全市全域土地利用、规划、矿产、生态等 200 + 类空间数据，总数据量超 300TB，矢量要素总量超 2 亿条，服务全市自然资源局、规划院、各区县分局近千名工作人员。

5.2 核心性能实测数据

项目上线前我们进行了全面的压力测试，核心性能指标如下：

测试场景	数据规模	性能指标	传统架构对比
空间范围查询	1000 万面要素，矩形范围查询	平均响应时间 120ms	传统架构约 1.5s，提升 92%
批量叠加分析	500 万面要素叠加计算	10 节点集群耗时 4.2 分钟	传统 GIS 单机耗时 8 小时，提升 99%
瓦片接口并发	矢量瓦片接口	单节点支持 800QPS，响应时间 < 50ms	传统 GeoServer 约 150QPS，提升 430%
批量数据导入	2000 万条矢量要素	Lightning 导入耗时 28 分钟	传统 SQL 导入约 5 小时，提升 89%

5.3 客户价值

该平台上线后，为客户带来了显著的业务价值：

分析效率大幅提升：原本需要数天的国土空间规划叠加分析，现在仅需几分钟即可完成，规划编制效率提升 80% 以上；
数据统一管控：解决了过去数据分散在各个科室、标准不统一、重复建设的问题，实现了全市空间数据的统一管理与共享；
成本显著降低：全栈国产化方案替代国外 GIS 软件，软件授权成本降低 70%，分布式架构相比小型机存储方案，硬件成本降低 40%；
安全可控：全栈信创适配，满足政务数据安全要求，实现了空间数据的自主可控。

六、未来展望与总结

6.1 技术演进展望

当前时空大数据技术仍在快速演进，未来我们将重点布局三个方向：

生成式 AI 融合（AI GEO）：将大语言模型与空间计算深度融合，用户通过自然语言即可完成空间查询、分析、制图，彻底降低时空数据的使用门槛，实现 "一句话生成分析报告"。
云原生化与 Serverless：进一步深化存算分离架构，实现空间计算的 Serverless 化，用户按需申请计算资源，按使用量付费，大幅降低使用成本。
三维时空数据支撑：从二维空间向三维全空间拓展，支撑倾斜摄影、BIM、点云等三维海量数据的存储、计算与可视化，打造真正的三维数字孪生底座。

6.2 总结

PB 级时空大数据的治理与应用，是数字政府与智慧城市建设的核心难题，没有一蹴而就的银弹方案，需要从存储、计算、服务、可视化全栈进行体系化设计与优化。国产化分布式架构不仅解决了安全可控的问题，更在性能、扩展性、成本上展现出了显著优势，正在成为行业的主流选择。

本文所分享的技术实践，均来自真实项目的落地沉淀，希望能为从事时空大数据、GIS、智慧城市领域的技术同仁提供一些参考。也欢迎大家共同交流，一起推动国产化时空大数据技术的持续发展。

CLup6.x产品手册：CLup简介CLup软件是专为PostgreSQL、PolarDB等数据库实现了高可用(包括读写分离)集群功能和基础监控管理以及备份恢复平台软件，本章介绍：CLup简介https://www.csudata.com/clup/manual