最后更新: 2026-11-04
GeoParquet 与 GeoJSON：哪种 GIS 格式更适合大型数据集？
如果你曾尝试在 QGIS 中打开一个 2 GB 的 GeoJSON 文件，或将一个包含数百万行多边形边界的文件加载到交互式地图中，你已经体会到屏幕冻结和内存不足崩溃的那种沉重感。
十多年来，GeoJSON 一直是网络制图的通用语言。它透明、易于阅读，并且几乎所有网络制图库和 REST API 都开箱即用地支持它。
然而，现代 GIS 工作流与 2008 年时截然不同。如今的地理空间从业者常规性地摄取数 GB（甚至 TB）级的物联网移动遥测数据、全国建筑轮廓、卫星衍生的分割掩膜以及高频率的气候网格。
在如此规模的数据集上使用时，GeoJSON 不仅仅是变慢——它会彻底成为数据架构的瓶颈。
引入 GeoParquet，它是一个开放、标准化的地理空间扩展，基于 Apache Parquet，并在开放地理空间联盟（OGC）内部孵化。
在本综合指南中，我们比较 GeoParquet 和 GeoJSON 在架构、存储效率、读写吞吐量、云就绪性和开发者体验方面，以回答一个关键问题：对于大型数据集，应该选择哪种格式？
1. 结构架构：文本 vs. 二进制列式
要了解为何这些格式在大规模下表现差异如此显著，必须深入查看它们各自如何表示坐标值和表格元数据。
+--------------------------------------------------------------+
| 评估指标 |
| **数据格式** |
| **几何表示** |
| **压缩比** |
| **列投影** |
+--------------------------------------------------------------+
VS
+--------------------------------------------------------------+
| **空间谓词下推** |
| **云对象存储 (S3/GCS)** |
| **人类可读性** |
| **网页浏览器支持** |
| **标准化组织** |
+--------------------------------------------------------------+
GeoJSON：面向行的文本编码 JSON
GeoJSON 将数据表示为 JSON 对象数组。每个特征都会显式重复属性键，并伴随一个字符串编码的浮点数数组：
{
"type": "FeatureCollection",
"features": [
{
"type": "Feature",
"properties": { "county": "Travis", "state": "TX", "pop_density": 1845.2 },
"geometry": {
"type": "Point",
"coordinates": [-97.74306, 30.26715]
}
}
]
}
因为 GeoJSON 基于文本：
- 重复的模式： 像
\"properties\"、\"type\"和\"coordinates\"这样的字段名会被重复数百万次，导致原始文件大小膨胀。 - 昂贵的字符串转浮点转换： 在执行任何空间操作之前，CPU 必须将文本字符（
\"-\", \"9\", \"7\", \".\", \"7\"...）解析为 64 位 IEEE 双精度浮点数。 - 单体读取需求： 标准 JSON 解析器必须将整个文件加载到内存中以构建文档对象模型（DOM）。读取单个属性需要解析每一个特征。
GeoParquet：面向列的二进制编码数据
GeoParquet 直接基于 Apache Parquet 构建，以列式而非行式方式存储空间表。
类似 county 的属性存储在连续块中，支持高级压缩技术，如行程长度编码（RLE）、位打包和字典压缩。几何数据采用 Well-Known Binary (WKB) 标准，并附带嵌入的 JSON 元数据，详细说明空间参考系统（CRS）、边界框和几何类型。
因为 GeoParquet 是二进制且列式的：
- 零坐标解析成本: 几何体直接以二进制形式存储，绕过昂贵的字符串转浮点转换。
- 投影下推: 如果下游工作流仅需要
county和pop_density列，读取器只会从磁盘或 S3 中获取 仅 那些字节偏移，完全跳过几何列。 - 行组分区: Parquet 文件将记录拆分为自包含的 “Row Groups”（通常每组 100,000 到 1,000,000 行），并为每列提供最小/最大统计信息。
2. 正面对比：核心指标
| Evaluation Metric | GeoJSON | GeoParquet |
|---|---|---|
| Data Format | Plain-text JSON (UTF-8) | Binary columnar (Apache Parquet) |
| Geometry Representation | Nested arrays of coordinate strings | Standardized Well-Known Binary (WKB) |
| Compression Ratio | Poor (requires gzip/bzip2 to reduce) | Exceptional (native Zstd, Snappy, Gzip) |
| Column Projection | ❌ No (entire record must be parsed) | ✅ Yes (fetch only the columns you need) |
| Spatial Predicate Pushdown | ❌ No (requires full scan) | ✅ Yes (using bounding box metadata) |
| Cloud Object Storage (S3/GCS) | ❌ Poor (must download full file) | ✅ Cloud-native (supports HTTP range requests) |
| Human Readability | ✅ Direct viewing in text editors | ❌ Requires CLI, GIS app, or code |
| Web Browser Support | Native JavaScript (JSON.parse) | Requires WebAssembly (e.g., duckdb-wasm, parquet-wasm) |
| Standardization Body | IETF (RFC 7946) | OGC (Open Geospatial Consortium standard) |
3. 存储效率与文件大小基准
当规模从数千条记录扩展到数百万条记录时，存储差异会显著扩大。
在使用真实的开放空间记录（如 OpenStreetMap 建筑轮廓、美国人口普查 TIGER 边界和全球船舶 AIS 日志）的标准基准测试中，GeoParquet 相较于原始 GeoJSON 通常实现 70% 到 85% 的存储减少，并且比 .geojson.gz 额外提升 20% 到 40%。
为什么 GeoParquet 会小这么多？
- 字典编码: 重复的字符串属性（例如，州代码、土地使用分类）被索引为小整数指针，而不是反复存储为长字符串。
- 紧凑二进制坐标: GeoJSON 中的二维点大约占用 30 到 45 字节的 ASCII 文本（
[-122.4194155, 37.7749295]）。在 WKB 中，同一坐标对恰好需要 16 字节。 - 现代压缩算法: Zstandard（
Zstd）和 Snappy 对列式字节数组的压缩效果远优于标准 Gzip 对交错行文本的压缩。
4. 查询性能与云原生工作流
对于大型数据集来说，最大的区别不仅在于存储——而在于 查询延迟和内存利用率。
1. 通过列投影进行选择性读取
想象一个包含 60 个属性（业主姓名、税号、契约历史、分区代码以及复杂的多多边形边界）的 15 GB 全国地块数据集。
- In GeoJSON: 如果您想计算每个邮政编码的平均评估物业价值，您的分析引擎必须下载并解析全部 15 GB，包括数百万个复杂的边界顶点。
- In GeoParquet: 像 DuckDB、Apache Sedona、Polars 或 AWS Athena 这样的分析引擎仅读取
zip_code和assessed_value列。无需传输 15 GB，您的引擎只下载并扫描不到 80 MB 的数据。
2. 云存储上的 HTTP 范围请求
GeoParquet 作为一种 云原生地理空间格式，可无缝运行。
由于 Parquet 文件在文件尾部存储内部偏移量和元数据，客户端库可以向 Amazon S3、Google Cloud Storage 或 Azure Blob Storage 等云对象存储发出 HTTP GET Range: bytes=... 请求。客户端无需下载整个多千兆字节的文件，而是读取文件尾部，确定相关记录所在的精确字节偏移，然后仅下载所需的子集。
Client (DuckDB / Python / QGIS)
│
├── 1. Read footer metadata (HTTP Range Request) ───► Cloud Storage (S3 / GCS)
│ │
◄── 2. Returns column offsets & row-group stats ───────────────┘
│
├── 3. Read ONLY requested column chunks & ranges ─────────────►
│ │
◄── 4. Fast binary stream (minimal I/O & egress) ──────────────┘
5. 软件生态系统与工具支持
从历史上看，GeoJSON 的主要优势是拥有通用的工具支持。虽然这在浏览器环境中仍然成立，但 GeoParquet 的生态系统已经快速成熟：
- 桌面 GIS： 在 QGIS 3.28+、ArcGIS Pro 和 GDAL/OGR 3.5+ 中提供原生读写支持。
- 分析引擎与语言： 在 Python（
GeoPandas、pyarrow）、R（sf）、DuckDB（通过空间扩展）、Apache Sedona 和 Snowflake 中提供快速向量化的读写能力。 - 大数据管道： 在 Apache Spark、Trino、Presto 和 Databricks 之间实现原生集成。
- 客户端网页地图： 轻量级 WebAssembly 库（如
parquet-wasm和duckdb-wasm）现在允许网页浏览器直接在客户端设备上查询 GeoParquet 文件，无需专用的 GIS 中间件服务器。
6. 实用决策矩阵：何时使用哪种？
Dataset Size & Use Case
│
┌─────────────────────────────┴─────────────────────────────┐
▼ ▼
Under 50–100 MB Over 100 MB
(API payloads, simple maps) (Data warehousing, big data)
│ │
▼ ▼
Use **GeoJSON** Use **GeoParquet**
• Direct Mapbox/Leaflet integration • High compression ratios
• Human-readable inspection • Sub-second analytical queries
• Standard REST API responses • Direct S3/GCS HTTP range reads
如果选择 GeoJSON：
- 您的数据集大小在 50 MB 到 100 MB 之间。
- 您正从 REST API 向前端客户端返回轻量级负载响应。
- 您正在使用 Leaflet、MapLibre 或 Mapbox GL JS 构建轻量级网页地图，无需中间转换层。
- 您需要在标准代码或文本编辑器中进行快速的手动编辑或检查。
如果选择 GeoParquet：
- 您的数据集超过 100 MB，或包含数十万条复杂的空间要素。
- 您正在将矢量资产存储在云对象存储中（S3、GCS、MinIO、Azure Blob）。
- 您使用 Python、DuckDB、Spark 或 Databricks 运行空间 SQL 分析、特征工程或机器学习流水线。
- 您希望降低存储成本，避免网络出站费用，并消除内存崩溃。
7. 迁移示例：将 GeoJSON 转换为 GeoParquet
将现有空间资产转换为 GeoParquet 只需几行代码。
使用 Python（GeoPandas）
import geopandas as gpd
# 1. Read the legacy GeoJSON file
gdf = gpd.read_file("large_boundaries.geojson")
# 2. Write directly to GeoParquet using modern Zstandard compression
gdf.to_parquet("large_boundaries.parquet", compression="zstd")
使用 GDAL / OGR（CLI）
ogr2ogr -f Parquet \
-oo LCO:COMPRESSION=ZSTD \
large_boundaries.parquet \
large_boundaries.geojson
使用 DuckDB
INSTALL spatial;
LOAD spatial;
-- Direct convert via SQL
COPY (
SELECT * FROM ST_Read('large_boundaries.geojson')
) TO 'large_boundaries.parquet'
WITH (FORMAT PARQUET, COMPRESSION 'ZSTD');
8. 总结：大数据集的结论
对于小型数据集和直接的 Web 端点，GeoJSON 仍然是可靠、免烦恼的实用格式。
然而，对于大型数据集，GeoParquet 在每个运营类别中客观上都更优。它提供更小的文件体积、显著降低的存储开销、近乎即时的空间读取，以及与现代云数据仓库的原生集成。
如果您的地理空间管道因超大 GeoJSON 文件的负担而喘不过气来，切换到 GeoParquet 是您可以进行的最有效的基础设施升级之一。
常见问题解答（FAQ）
Q1. GeoParquet 是官方认可的 GIS 标准吗？ 是的，GeoParquet 是在开放地理空间联盟（OGC）指导下维护的官方开放标准。
Q2. 我可以在 Leaflet 或 Mapbox GL JS 等网络制图库中直接渲染 GeoParquet 文件吗？ 虽然不像 GeoJSON 那样原生解析，但您可以使用 WebAssembly 包（如 parquet-wasm）在浏览器中渲染 GeoParquet，或在导入时将文件转换为矢量瓦片（PMTiles/MVT）。
Q3. GeoParquet 支持多坐标参考系统（CRS）吗？ 是的，与严格限制为 WGS 84 / EPSG:4326（RFC 7946）的 GeoJSON 不同，GeoParquet 允许在其嵌入的文件元数据中直接定义自定义 CRS。
Q4. GeoParquet 与 FlatGeobuf 在大型空间数据集方面如何比较？ FlatGeobuf 针对使用 R-Tree 空间索引直接流式传输空间要素到交互式网络地图进行了优化，而 GeoParquet 则旨在实现高性能列式分析、压缩以及大规模数据湖仓储。
Q5. 我可以在桌面 GIS 软件如 QGIS 中打开 GeoParquet 文件吗？ 是的，现代版本的 QGIS（3.28 及以上）支持拖拽、查看和样式化 GeoParquet 文件，无需第三方插件。