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. การเปรียบเทียบแบบหัวต่อหัว: ตัวชี้วัดหลัก

3. ประสิทธิภาพการจัดเก็บและเกณฑ์ขนาดไฟล์

เมื่อขยายจากหลายพันเป็นหลายล้านระเบียน ความแตกต่างด้านการจัดเก็บจะขยายออกอย่างมาก.

ในการทดสอบมาตรฐานโดยใช้ระเบียนเชิงพื้นที่เปิดจากโลกจริง (เช่น รูปแบบอาคารจาก OpenStreetMap, ขอบเขต TIGER ของสำมะโนประชากรสหรัฐ, และบันทึก AIS ของเรือทั่วโลก) GeoParquet มักจะบรรลุ การลดพื้นที่จัดเก็บ 70% ถึง 85% เมื่อเทียบกับ GeoJSON ดิบ, และเหนือกว่า .geojson.gz อีก 20% ถึง 40%.

ทำไม GeoParquet ถึงเล็กกว่ามากขนาดนี้?

1. Dictionary Encoding: คุณลักษณะสตริงที่ซ้ำกัน (เช่น รหัสรัฐ, การจัดประเภทการใช้ที่ดิน) จะถูกทำดัชนีเป็นตัวชี้จำนวนเต็มขนาดเล็กแทนที่จะเก็บซ้ำเป็นสตริงยาว
2. Compact Binary Coordinates: จุด 2 มิติใน GeoJSON ใช้ประมาณ 30 ถึง 45 ไบต์ของข้อความ ASCII ([-122.4194155, 37.7749295]). ใน WKB, คู่พิกัดเดียวกันต้องใช้เพียง 16 ไบต์เท่านั้น
3. 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

5 รูปแบบไฟล์ GIS ชั้นนำสำหรับ Google Maps

ข่าวรูปแบบไฟล์

ฟอรั่มรูปแบบไฟล์