Memilih Format Data

Setelah kita memahami delapan format data mulai dari CSV hingga Protobuf, pertanyaan yang tersisa justru yang paling sering muncul di pekerjaan nyata: format mana yang dipakai untuk kebutuhan ini? Pilihan format menentukan biaya storage, kecepatan pipeline, dan kemudahan kolaborasi sekaligus. Chapter ini merangkum seluruh pembahasan sebelumnya menjadi kerangka keputusan yang bisa langsung dipakai saat merancang pipeline.

Tiga Pertanyaan Kunci #

Sebelum memilih format, ajukan tiga pertanyaan berikut secara berurutan. Ketiganya menyaring pilihan dengan cepat sehingga kita tidak perlu membandingkan delapan format setiap kali.

1. Siapa yang membaca datanya? Manusia dan spreadsheet nyaman dengan CSV; mesin dan pipeline nyaman dengan format berschema.
2. Bagaimana data diakses? Dibaca seluruhnya baris demi baris (streaming), atau difilter per kolom (analitik)? Akses per kolom adalah alasan utama format columnar seperti Parquet dan ORC ada.
3. Apakah schema perlu dikawal? Pipeline antar tim atau antar sistem membutuhkan kontrak yang tegas — Avro dan Protobuf unggul di sini karena schema-nya eksplisit dan mendukung evolusi terkendali.

Tabel Perbandingan Cepat #

Tabel berikut merangkum karakteristik kedelapan format yang telah kita bahas. Gunakan tabel ini sebagai peta saat membandingkan kandidat.

Tiga baris pertama adalah format berbasis teks: mudah dibaca manusia tetapi boros ruang dan tidak menjamin tipe data. Lima baris terakhir adalah format biner berschema: hemat ruang, tegas soal tipe, tetapi membutuhkan perkakas khusus untuk membukanya.

Ukuran Nyata: Sama Data, Tiga Format #

Teori terasa abstrak, jadi mari kita ukur langsung. Kode berikut menulis 1.000 baris transaksi toko yang sama ke tiga format lalu membandingkan ukuran berkasnya.

import io
import json
import os

import pyarrow as pa
import pyarrow.parquet as pq

transaksi = [
    {"id": i, "kasir": ["Budi", "Siti", "Dewi"][i % 3],
     "produk": ["Kopi Robusta", "Teh Melati", "Susu UHT 1L"][i % 3],
     "qty": 1 + i % 5, "harga": 15000 + (i % 10) * 1000}
    for i in range(1, 1001)
]

# CSV
with open("transaksi.csv", "w", encoding="utf-8", newline="") as f:
    f.write("id,kasir,produk,qty,harga\n")
    for t in transaksi:
        f.write(f'{t["id"]},{t["kasir"]},{t["produk"]},{t["qty"]},{t["harga"]}\n')

# JSON Lines
with open("transaksi.jsonl", "w", encoding="utf-8") as f:
    for t in transaksi:
        f.write(json.dumps(t, ensure_ascii=False) + "\n")

# Parquet
tabel = pa.Table.from_pylist(transaksi)
pq.write_table(tabel, "transaksi.parquet", compression="snappy")

for nama in ["transaksi.csv", "transaksi.jsonl", "transaksi.parquet"]:
    print(f"{nama:18s} {os.path.getsize(nama):>9,d} byte")

Output yang Dihasilkan:

transaksi.csv         28,918 byte
transaksi.jsonl       79,892 byte
transaksi.parquet      7,077 byte

Mari kita telaah hasilnya:

1. JSON Lines paling besar (79.892 byte): setiap baris mengulang nama kolom ("kasir", "produk") sebagai teks, padahal informasi itu identik di seluruh baris.
2. CSV sepertiga ukuran JSONL (28.918 byte): nama kolom hanya ditulis sekali di header, tetapi nilai numerik tetap disimpan sebagai teks karakter demi karakter.
3. Parquet hanya 7.077 byte — sekitar 11x lebih kecil dari JSONL: orientasi kolom memungkinkan penyimpanan berulang dipadatkan (dictionary encoding menulis “Kopi Robusta” sekali lalu merujuknya), ditambah kompresi Snappy bawaan per kolom.

Pada skala terabyte, selisih seperti ini bukan sekadar hemat disk: berkas yang lebih kecil berarti baca dari object storage lebih cepat dan biaya egress lebih rendah.

Studi Kasus Mini #

Tiga skenario berikut memperlihatkan bagaimana tiga pertanyaan kunci mengarahkan pilihan format yang berbeda.

Skenario 1 — Dashboard analitik penjualan. Data diakses dengan query agregasi yang hanya menyentuh beberapa kolom dari puluhan kolom yang tersedia, dibaca berulang oleh query engine. Pilihan: Parquet dengan partisi per periode. Orientasi kolom memungkinkan column pruning dan predicate pushdown yang telah kita bahas pada Chapter Parquet.

Skenario 2 — Event dari aplikasi mobile ke pipeline. Event dikirim terus-menerus dalam volume kecil, harus bisa ditulis tanpa menunggu batch penuh, dan schema-nya dikawal supaya producer dan consumer tidak saling mengejutkan. Pilihan: Avro (atau Protobuf) dengan schema registry — format biner ringkas, schema tertanam, dan evolusi terkendali seperti pada Chapter Schema Evolution.

Skenario 3 — Ekspor laporan bulanan untuk tim keuangan. Penerima adalah manusia yang membukanya di spreadsheet, sekali sebulan, ukuran kecil. Pilihan: CSV. Keterbacaan universal mengalahkan efisiensi penyimpanan ketika data hanya dikonsumsi sekali oleh manusia.

Diagram Keputusan #

Alur berikut merangkum keseluruhan kerangka. Mulai dari pertanyaan paling atas dan turun mengikuti jawaban sampai menemukan format yang cocok.

Diagram ini menyederhanakan keputusan; kenyataannya boleh kombinasi. Sebuah pipeline yang matang sering memakai JSON Lines atau Avro di zona ingestion, lalu menuliskan hasil transformasi sebagai Parquet di zona analitik. Pola berlapis seperti ini akan kita lihat kembali saat membahas zona raw dan curated pada Section Data Lake dan Lakehouse.

Sebagai pendalaman lanjutan, buka dokumentasi resmi Parquet untuk detail struktur row group, dokumentasi Avro untuk aturan resolusi schema, dan spesifikasi Protobuf untuk panduan encoding wire format. Ketiganya merinci aspek teknis yang kita rangkum di sini pada tingkat spesifikasi penuh.