Appendix A: Serialization and Compression
2 min readRow-Based vs Columnar
| Format | จุดเด่น | จุดอ่อน |
|---|---|---|
| CSV | ง่าย, universal | error-prone, ไม่มี schema จริง — ควรหลีกเลี่ยงใน pipelines |
| JSON/JSONL | มาตรฐาน API, native support ใน DB สมัยใหม่ | performance ต่ำกว่า columnar มาก |
| Avro | Row-oriented, binary, schema ใน JSON | ไม่เหมาะกับ analytical workloads |
| Parquet | Columnar, schema, nested data, portable | update records ยาก |
| ORC | คล้าย Parquet, นิยมใน Hive | support น้อยกว่า Parquet |
| Apache Arrow | In-memory columnar, ข้ามภาษา | ไม่ใช่ storage format — ใช้ใน processing |
วิธีเลือก Format
| Use Case | แนะนำ |
|---|---|
| Data exchange ผ่าน API | JSON |
| Bulk storage ใน data lake | Parquet |
| RPC / Kafka messages | Avro |
| In-memory processing ข้ามภาษา | Arrow |
| CDC + analytics table | Hudi / Iceberg |
Hybrid serialization (Hudi/Iceberg) คืออะไร:
- Hudi (Hadoop Update Delete Incremental): ผสม row-oriented (เก็บ CDC stream ที่เข้ามาต่อเนื่อง) กับ columnar (เก็บ bulk table) ไว้ด้วยกัน แล้วรัน repacking process เป็นระยะเพื่อรวมเป็น columnar file — ได้ทั้ง transactional update และ analytics query performance
- Iceberg: table format ที่ track ทุกไฟล์ในตารางรวมถึง snapshot ย้อนหลัง — รองรับ time travel, schema evolution, และจัดการตารางระดับ petabyte ได้
Compression
- Traditional (gzip, bzip2): compression ratio สูง (มักได้ 10:1) แต่ช้ากว่า — เหมาะกับ text-based format อย่าง JSON/JSONL/XML/CSV
- Speed-optimized (Snappy, Zstandard, LZ4, LZFSE): เน้น speed/CPU efficiency มากกว่า ratio — นิยมคู่กับ Parquet และ columnar database ในการ optimize query performance
- Columnar + compression = maximize disk/network bandwidth
- Compression ratio 10:1 → effective scan speed 200 MB/s → 2 GB/s