Konsep Big Data Processing

Pipeline batch harian TokoKita pada Chapter Pipeline Batch mengolah belasan ribu baris pesanan per hari, dan SQLite menangani beban tersebut tanpa keluhan. Beberapa tahun kemudian, situs TokoKita mencatat jutaan event klik dan pencarian setiap harinya, ditambah ratusan juta baris riwayat transaksi. Skrip pandas yang dulu selesai dalam satu menit kini membuat laptop dengan RAM 16 GB berhenti merespons. Pada chapter ini kita perjelas pertanyaan dasarnya: kapan sebuah data layak disebut “big”, apa yang membuat mesin tunggal menyerah, dan bagaimana komputasi terdistribusi menjawab masalah tersebut.

Kapan Data Disebut “Big” #

Istilah big data paling sering dipetakan ke tiga karakteristik yang dikenal sebagai tiga V:

Definisi yang lebih berguna untuk praktisi bersifat relatif: data disebut “big” ketika beban kerja melebihi sumber daya satu mesin yang tersedia. Data 50 GB hanyalah rutinitas bagi server dengan RAM 128 GB, tetapi menjadi masalah serius pada laptop 16 GB. Jadi, yang menentukan adalah hubungan antara ukuran data, kecepatan datangnya, dan sumber daya satu mesin — bukan angka mutlaknya.

Batas Mesin Tunggal #

Mesin tunggal menabrak tiga batas hampir sekaligus ketika data tumbuh. Pertama, RAM: pemrosesan cepat menuntut data berada di memori, dan ketika data melampaui RAM, sistem operasi mulai memakai swap di disk sehingga kinerja turun drastis. Kedua, CPU: jumlah core satu mesin terbatas, sehingga paralelisasi juga terbatas. Ketiga, I/O disk: membaca ratusan gigabyte dari satu disk memakan waktu puluhan menit sebelum komputasi pertama pun dimulai.

Kita bisa mengukur batas pertama dengan skrip Python murni berikut, yang mengestimasi kebutuhan memori untuk 500 juta baris event TokoKita.

"""Estimasi kebutuhan memori untuk 500 juta baris event di mesin tunggal."""
import sys

baris = {
    "waktu": "2026-01-15T08:23:41",
    "pelanggan": "Budi",
    "halaman": "/produk/laptop-123",
    "durasi_ms": 340,
    "perangkat": "mobile",
}

# Ukuran sebagai objek Python: dict + semua key dan value di dalamnya
ukuran_objek = sys.getsizeof(baris)
ukuran_objek += sum(sys.getsizeof(k) + sys.getsizeof(v) for k, v in baris.items())

# Ukuran sebagai satu baris CSV teks (lebih ringkas dari objek Python)
teks = ",".join(str(v) for v in baris.values())
ukuran_teks = len(teks.encode("utf-8")) + 1  # +1 byte untuk newline

total_objek = ukuran_objek * 500_000_000
total_teks = ukuran_teks * 500_000_000

print(f"Satu baris sebagai objek Python : {ukuran_objek} byte")
print(f"Satu baris sebagai teks CSV     : {ukuran_teks} byte")
print(f"500 juta baris (objek Python)   : {total_objek / 1024**3:.1f} GB")
print(f"500 juta baris (teks CSV)       : {total_teks / 1024**3:.1f} GB")
print(f"Muat di RAM 16 GB?              : {'ya' if total_objek < 16 * 1024**3 else 'tidak'}")

Output yang Dihasilkan:

Satu baris sebagai objek Python : 667 byte
Satu baris sebagai teks CSV     : 55 byte
500 juta baris (objek Python)   : 310.6 GB
500 juta baris (teks CSV)       : 25.6 GB
Muat di RAM 16 GB?              : tidak

Mari kita telaah baris-baris kode di atas:

1. Baris 1 (docstring): deskripsi singkat tujuan skrip — mengestimasi memori sebelum kita memutuskan membeli mesin baru.
2. Baris 4-10 (baris = {...}): satu baris event TokoKita dalam bentuk dict Python, representasi yang paling sering dipakai skrip pandas murni.
3. Baris 13-14 (ukuran_objek ...): sys.getsizeof() mengukur dict beserta seluruh key dan value di dalamnya. Hasilnya 667 byte — overhead objek Python membuat satu baris 12 kali lebih gemuk dibanding teksnya.
4. Baris 17-18 (teks = ...): baris yang sama diringkas jadi satu baris CSV; 55 byte termasuk newline. Format kolumnar seperti Parquet memampatkan lebih efisien lagi, tetapi urutan besarannya tidak berubah.
5. Baris 20-21 (total_objek ...): kedua ukuran dikalikan 500 juta baris — 310,6 GB sebagai objek Python, 25,6 GB sebagai teks CSV.
6. Baris 27 (print(... RAM 16 GB ...)): estimasi objek Python dibandingkan terhadap RAM 16 GB dan jawaban yang tercetak adalah tidak — bahkan representasi paling ringkas sekalipun tidak muat.

Scale-Up atau Scale-Out #

Ada dua arah menambah kapasitas. Scale-up menaikkan spesifikasi satu mesin: RAM lebih besar, prosesor lebih banyak. Scale-out menambah jumlah mesin murah yang bekerja bersama sebagai satu cluster.

Perkiraan 310,6 GB di atas memaksa TokoKita ke arah scale-out — tetapi sekumpulan mesin tidak otomatis bekerja sama, dan itulah pokok bahasan dua bagian berikutnya.

Pindahkan Komputasi ke Data #

Solusi naif untuk masalah di atas adalah menarik seluruh data ke satu mesin besar. Pendekatan tersebut cepat menabrak batas praktis: pada jaringan 1 Gbps, memindahkan 1 TB data membutuhkan lebih dari dua jam dalam kondisi ideal, jauh lebih lama pada kondisi nyata. Cluster computing membalik arahnya: karena kode program berukuran kilobyte sementara data berukuran terabyte, jauh lebih murah mengirim kode ke mesin-mesin tempat data tersimpan daripada menarik data ke satu titik. Prinsip ini disebut data locality — fondasi sistem pemrosesan data terdistribusi sejak era Hadoop MapReduce.

Model Cluster Computing #

Dalam model cluster, data besar dipecah menjadi partition yang tersebar di banyak worker node. Sebuah proses driver memecah pekerjaan menjadi task, lalu setiap executor di worker memproses partition yang berada di mesinnya secara paralel. Ketika satu worker gagal, task miliknya dijadwalkan ulang ke worker lain dan dihitung ulang dari sumber data, sehingga kegagalan satu mesin tidak menghentikan pekerjaan. Kita akan bedah arsitektur driver, executor, dan cluster manager secara rinci pada chapter berikutnya.

Ekosistem Data dan Posisi Spark #

Spark bukan pengganti database maupun storage; Apache Spark adalah mesin komputasi yang membaca data dari storage terdistribusi dan menulis hasilnya kembali. Diagram berikut memetakan posisi Spark dalam ekosistem data TokoKita:

Satu mesin Spark yang sama dapat menjalankan pipeline batch malam hari, query SQL interaktif untuk analis, dan pemrosesan stream mendekati real-time. Kesatuan inilah yang membuat Spark menjadi standar de facto pemrosesan data berskala besar.

Dengan konsep volume, batas mesin tunggal, dan model cluster yang sudah mapan, kita siap membedah mesin yang paling banyak dipakai untuk model tersebut: Apache Spark.