อัปเดตล่าสุด: 2026-11-04
GeoParquet vs. GeoJSON: ฟอร์แมต GIS ใดดีกว่าสำหรับชุดข้อมูลขนาดใหญ่?
หากคุณเคยลองเปิดไฟล์ GeoJSON ขนาด 2 GB ใน QGIS หรือโหลดไฟล์ขอบเขตโพลิกอนหลายล้านแถวเข้าสู่แผนที่เชิงโต้ตอบ คุณคงคุ้นเคยกับความรู้สึกที่หน้าจอค้างและการพังจากหน่วยความจำเต็ม.
เป็นเวลามากกว่าทศวรรษ, GeoJSON ได้ทำหน้าที่เป็นภาษากลางสากลของการทำแผนที่บนเว็บ มันโปร่งใส, อ่านได้โดยมนุษย์, และได้รับการสนับสนุนโดยอัตโนมัติจากเกือบทุกไลบรารีการทำแผนที่บนเว็บและ REST API บนอินเทอร์เน็ต.
อย่างไรก็ตาม, กระบวนการทำงาน GIS สมัยใหม่ดูแตกต่างอย่างสิ้นเชิงเมื่อเทียบกับปี 2008 ผู้เชี่ยวชาญด้านภูมิสารสนเทศในปัจจุบันมักจะรับข้อมูลกิกะไบต์ (หรือเทราไบต์) ของข้อมูลการเคลื่อนที่ IoT, รอยเท้าตึกทั่วประเทศ, มาสก์การแบ่งส่วนที่ได้จากดาวเทียม, และกริดสภาพอากาศความถี่สูงเป็นประจำ.
เมื่อใช้กับชุดข้อมูลในระดับนี้, GeoJSON ไม่ได้แค่ทำให้ช้าลงเท่านั้น—มันกลายเป็นคอขวดอย่างสมบูรณ์ของสถาปัตยกรรมข้อมูล.
ขอแนะนำ GeoParquet, ส่วนขยายเชิงภูมิสารสนเทศที่เปิดและมาตรฐานสำหรับ Apache Parquet ที่กำลังพัฒนาอยู่ภายใน Open Geospatial Consortium (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"...) เป็นจำนวนทศนิยมแบบ IEEE 64-bit ดับเบิลพรีซิชัน ก่อนที่จะทำการดำเนินการเชิงพื้นที่ใด ๆ - ข้อกำหนดการอ่านแบบโมโนลิธิก: พาร์เซอร์ JSON มาตรฐานต้องโหลดไฟล์ทั้งหมดเข้าสู่หน่วยความจำเพื่อสร้าง Document Object Model (DOM) การอ่านแอตทริบิวต์หนึ่งต้องทำการพาร์เซอร์ทุกฟีเจอร์
GeoParquet: แนวคอลัมน์, ข้อมูลที่เข้ารหัสเป็นไบนารี
GeoParquet สร้างขึ้นโดยตรงบน Apache Parquet, เก็บตารางเชิงพื้นที่แบบคอลัมน์ต่อคอลัมน์แทนการเก็บแบบแถวต่อแถว.
คุณลักษณะเช่น county จะถูกเก็บในบล็อกต่อเนื่อง ทำให้สามารถใช้เทคนิคการบีบอัดขั้นสูงเช่น run-length encoding (RLE), bit-packing, และ dictionary compression ได้ ข้อมูลเรขาคณิตถูกมาตรฐานเป็น Well-Known Binary (WKB) พร้อมด้วยเมตาดาต้า JSON ที่ฝังอยู่ซึ่งระบุระบบอ้างอิงเชิงพื้นที่ (CRS), กล่องขอบเขต, และประเภทของเรขาคณิต
เนื่องจาก GeoParquet เป็นแบบไบนารีและคอลัมน์:
- ศูนย์ค่าใช้จ่ายในการแปลงพิกัด: เรขาคณิตถูกเก็บโดยตรงในรูปแบบไบนารี, ข้ามการแปลงจากสตริงเป็นจำนวนทศนิยมที่มีค่าใช้จ่ายสูง
- Projection Pushdown: หากกระบวนการทำงานต่อจากของคุณต้องการเพียงคอลัมน์
countyและpop_densityเท่านั้น, ตัวอ่านจะดึง เฉพาะ ไบต์ออฟเซ็ตเหล่านั้นจากดิสก์หรือ S3, ข้ามคอลัมน์เรขาคณิตโดยสมบูรณ์ - การแบ่งกลุ่มแถว (Row-Group Partitioning): ไฟล์ 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 มักจะบรรลุ การลดพื้นที่จัดเก็บ 70% ถึง 85% เมื่อเทียบกับ GeoJSON ดิบ, และเหนือกว่า .geojson.gz อีก 20% ถึง 40%.
ทำไม GeoParquet ถึงเล็กกว่ามากขนาดนี้?
- Dictionary Encoding: คุณลักษณะสตริงที่ซ้ำกัน (เช่น รหัสรัฐ, การจัดประเภทการใช้ที่ดิน) จะถูกทำดัชนีเป็นตัวชี้จำนวนเต็มขนาดเล็กแทนที่จะเก็บซ้ำเป็นสตริงยาว
- Compact Binary Coordinates: จุด 2 มิติใน GeoJSON ใช้ประมาณ 30 ถึง 45 ไบต์ของข้อความ ASCII (
[-122.4194155, 37.7749295]). ใน WKB, คู่พิกัดเดียวกันต้องใช้เพียง 16 ไบต์เท่านั้น - Modern Compression Algorithms: Zstandard (
Zstd) และ Snappy บีบอัดอาร์เรย์ไบต์แบบคอลัมน์ได้อย่างมีประสิทธิภาพมากกว่าที่ Gzip มาตรฐานสามารถบีบอัดข้อความแบบแถวที่สลับกันได้
4. ประสิทธิภาพการสืบค้นและกระบวนการทำงานแบบคลาวด์เนทีฟ
สิ่งที่แตกต่างที่สุดสำหรับชุดข้อมูลขนาดใหญ่ไม่ได้เป็นเพียงการจัดเก็บ—แต่เป็น ความหน่วงของการสอบถามและการใช้หน่วยความจำ.
1. การอ่านแบบเลือกสรรผ่านการฉายคอลัมน์
ลองจินตนาการถึงชุดข้อมูลพัสดุระดับชาติขนาด 15 GB ที่มี 60 คุณลักษณะ (ชื่อเจ้าของ, หมายเลขประจำตัวผู้เสียภาษี, ประวัติการโอนกรรมสิทธิ์, รหัสการจัดโซน, และขอบเขตหลายหลายเหลี่ยมที่ซับซ้อน).
- ใน GeoJSON: หากคุณต้องการคำนวณค่าเฉลี่ยของมูลค่าทรัพย์สินที่ประเมินต่อรหัสไปรษณีย์ เครื่องมือวิเคราะห์ของคุณต้องดาวน์โหลดและแยกวิเคราะห์ทั้งหมด 15 GB รวมถึงล้านๆ จุดขอบเขตที่ซับซ้อน.
- ใน GeoParquet: เครื่องมือวิเคราะห์เช่น DuckDB, Apache Sedona, Polars หรือ AWS Athena จะอ่าน เฉพาะ คอลัมน์
zip_codeและassessed_valueเท่านั้น. แทนการโอนย้าย 15 GB, เครื่องมือของคุณจะดาวน์โหลดและสแกนน้อยกว่า 80 MB.
2. คำขอ HTTP Range บนคลาวด์สตอเรจ
GeoParquet ทำงานอย่างราบรื่นในฐานะ รูปแบบภูมิสารสนเทศแบบคลาวด์เนทีฟ.
เนื่องจากไฟล์ Parquet เก็บออฟเซ็ตภายในและเมตาดาต้าในส่วนท้ายของไฟล์, ไลบรารีไคลเอนต์สามารถส่งคำขอ HTTP GET Range: bytes=... ไปยังที่เก็บวัตถุคลาวด์เช่น Amazon S3, Google Cloud Storage หรือ Azure Blob Storage. แทนการดาวน์โหลดไฟล์หลายกิกะไบต์ทั้งหมด, ไคลเอนต์จะอ่านส่วนท้าย, ระบุตำแหน่งออฟเซ็ตไบต์ที่แน่นอนของบันทึกที่เกี่ยวข้อง, และดาวน์โหลดเฉพาะส่วนย่อยที่ต้องการ.
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 ได้พัฒนาอย่างรวดเร็ว:
- Desktop GIS: การสนับสนุนการอ่าน/เขียนแบบเนทีฟใน QGIS 3.28+, ArcGIS Pro, และ GDAL/OGR 3.5+.
- Analytical Engines & Languages: ความสามารถในการอ่าน/เขียนแบบเวกเตอร์ที่เร็วผ่าน Python (
GeoPandas,pyarrow), R (sf), DuckDB (ผ่านส่วนขยาย spatial), Apache Sedona, และ Snowflake. - Big Data Pipelines: การบูรณาการแบบเนทีฟผ่าน Apache Spark, Trino, Presto, และ Databricks.
- Client-Side Web Maps: ไลบรารี WebAssembly ที่มีน้ำหนักเบา (เช่น
parquet-wasmและduckdb-wasm) ตอนนี้ทำให้เว็บเบราว์เซอร์สามารถสอบถามไฟล์ GeoParquet โดยตรงบนอุปกรณ์ของผู้ใช้โดยไม่ต้องใช้เซิร์ฟเวอร์ GIS middleware ที่แยกออกมา.
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.
- คุณกำลังส่งคืนการตอบสนอง payload ที่มีน้ำหนักเบาจาก REST API ไปยังไคลเอนต์ฝั่งหน้า.
- คุณกำลังสร้างเว็บแมพที่มีน้ำหนักเบาโดยใช้ Leaflet, MapLibre หรือ Mapbox GL JS โดยไม่ต้องมีชั้นแปลกลาง.
- คุณต้องการการแก้ไขหรือการตรวจสอบด้วยมืออย่างรวดเร็วในโปรแกรมแก้ไขโค้ดหรือข้อความมาตรฐาน
เลือก GeoParquet หาก:
- ชุดข้อมูลของคุณมีขนาดเกิน 100 MB หรือมีคุณลักษณะเชิงพื้นที่ซับซ้อนหลายแสนรายการ
- คุณกำลังเก็บสินทรัพย์เวกเตอร์ในคลาวด์ออบเจ็กต์สตอเรจ (S3, GCS, MinIO, Azure Blob)
- คุณดำเนินการวิเคราะห์ SQL เชิงพื้นที่, การสร้างคุณลักษณะ, หรือไพป์ไลน์แมชชีนเลิร์นนิงโดยใช้ Python, DuckDB, Spark หรือ Databricks
- คุณต้องการลดค่าใช้จ่ายในการจัดเก็บ, หลีกเลี่ยงค่าธรรมเนียมการส่งออกเครือข่าย, และขจัดการล่มของหน่วยความจำ
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. สรุป: คำตัดสินเกี่ยวกับชุดข้อมูลขนาดใหญ่
สำหรับชุดข้อมูลขนาดเล็กและจุดเชื่อมต่อเว็บโดยตรง, GeoJSON ยังคงเป็นรูปแบบยูทิลิตี้ที่เชื่อถือได้และไม่มีความยุ่งยาก
อย่างไรก็ตาม, สำหรับชุดข้อมูลขนาดใหญ่, GeoParquet มีความเหนือกว่าอย่างเป็นวัตถุประสงค์ในทุกหมวดหมู่การดำเนินงาน. มันให้ไฟล์ที่มีขนาดเล็กลง, ค่าใช้จ่ายการจัดเก็บที่ต่ำกว่ามาก, การอ่านเชิงพื้นที่ที่เกือบทันที, และการผสานรวมแบบเนทีฟกับคลังข้อมูลคลาวด์สมัยใหม่
หากระบบการประมวลผลเชิงพื้นที่ของคุณกำลังบิดเบือนจากน้ำหนักของไฟล์ GeoJSON ขนาดใหญ่ การเปลี่ยนไปใช้ GeoParquet เป็นหนึ่งในการอัปเกรดโครงสร้างพื้นฐานที่มีประสิทธิภาพที่สุดที่คุณสามารถทำได้.
คำถามที่พบบ่อย (FAQ)
Q1. GeoParquet เป็นมาตรฐาน GIS ที่ได้รับการยอมรับอย่างเป็นทางการหรือไม่? ใช่, GeoParquet เป็นมาตรฐานเปิดอย่างเป็นทางการที่ได้รับการดูแลภายใต้การแนะนำของ Open Geospatial Consortium (OGC).
Q2. ฉันสามารถเรนเดอร์ไฟล์ GeoParquet โดยตรงในไลบรารีการทำแผนที่บนเว็บเช่น Leaflet หรือ Mapbox GL JS ได้หรือไม่? แม้ว่าจะไม่สามารถแยกวิเคราะห์โดยตรงเช่น GeoJSON, คุณสามารถเรนเดอร์ GeoParquet ในเบราว์เซอร์โดยใช้แพ็กเกจ WebAssembly เช่น parquet-wasm หรือโดยการแปลงไฟล์เป็น Vector Tiles (PMTiles/MVT) ในขั้นตอนการนำเข้า.
Q3. GeoParquet รองรับระบบอ้างอิงพิกัดหลายระบบ (CRS) หรือไม่? ใช่, แตกต่างจาก GeoJSON (ซึ่งถูกจำกัดอย่างเคร่งครัดให้ใช้ WGS 84 / EPSG:4328 ตาม RFC 7946), GeoParquet อนุญาตให้กำหนด CRS แบบกำหนดเองได้โดยตรงในเมตาดาต้าไฟล์ที่ฝังอยู่.
Q4. GeoParquet เปรียบเทียบกับ FlatGeobuf อย่างไรสำหรับชุดข้อมูลเชิงพื้นที่ขนาดใหญ่? FlatGeobuf ถูกออกแบบให้เหมาะกับการสตรีมฟีเจอร์เชิงพื้นที่โดยตรงไปยังเว็บแผนที่แบบโต้ตอบโดยใช้การจัดทำดัชนีเชิงพื้นที่แบบ R-Tree ในขณะที่ GeoParquet ถูกออกแบบมาสำหรับการวิเคราะห์เชิงคอลัมน์ประสิทธิภาพสูง การบีบอัด และการจัดเก็บข้อมูลขนาดใหญ่ใน data lake.
Q5. ฉันสามารถเปิดไฟล์ GeoParquet ในซอฟต์แวร์ GIS บนเดสก์ท็อปเช่น QGIS ได้หรือไม่? ใช่, เวอร์ชันสมัยใหม่ของ QGIS (เวอร์ชัน 3.28 ขึ้นไป) รองรับการลากและวาง, การดู, และการจัดสไตล์ไฟล์ GeoParquet โดยไม่ต้องใช้ปลั๊กอินของบุคคลที่สาม.
ดูเพิ่มเติม
รูปแบบไฟล์ GIS ที่ FileFormat.com