Trade-off Arsitektur

Matriks skor pada chapter Memilih Arsitektur Data menghasilkan pemenang, tetapi angka di dalamnya menyembunyikan asumsi: berapa sebenarnya harga yang kita bayar untuk satu menit kesegaran tambahan? Pertanyaan tersebut adalah wujud nyata dari kalimat yang membuka section ini — tidak ada arsitektur yang menang di semua dimensi. Bab penutup ini membedah satu trade-off paling universal, biaya versus kesegaran, dengan perhitungan yang bisa diulang; kemudian menutup perjalanan section dengan keterampilan terpentingnya: menganggap setiap keputusan arsitektur sebagai keputusan yang bisa direvisi.

Kesegaran Itu Berapa Harganya #

Ukuran yang paling jujur untuk kesegaran adalah usia data rata-rata: berapa lama, secara rata-rata, sebuah event sudah berumur ketika angkanya terbaca di dashboard. Untuk pipeline terjadwal, usia tersebut adalah setengah interval (event rata-rata menunggu separuh jadwal sebelum diambil) ditambah durasi run ditambah latensi penyajian. Dashboard operasional TokoKita akan kita bandingkan dalam tiga opsi: batch tiap jam, micro-batch lima menit, dan streaming penuh.

Tiga Opsi, Satu Dashboard #

Asumsi harga diungkapkan terbuka agar mudah diganti: komputasi kluster seharga $0,10 per menit, dan klaster streaming hidup 24/7 dalam ukuran ramping (rata-rata 0,4 core). Skrip berikut menghitung biaya bulanan serta usia data rata-rata ketiganya:

# Asumsi 2026 (diungkap di prosa): harga komputasi kluster $0,10 per menit
HARGA_PER_MENIT = 0.10
HARI = 30
MENIT_PER_BULAN = 60 * 24 * HARI

OPSI = [
    # (nama, interval menit, durasi run menit, latensi hasil detik)
    ("batch tiap jam", 60, 12, 2700),
    ("micro-batch 5 menit", 5, 3, 55),
    ("streaming penuh", None, None, 8),
]


def biaya_bulanan(interval, durasi):
    if interval is None:  # klaster streaming hidup penuh 24/7
        return MENIT_PER_BULAN * HARGA_PER_MENIT * 0.4  # klaster ramping, 0,4 core rata-rata
    run_per_bulan = MENIT_PER_BULAN / interval
    return run_per_bulan * durasi * HARGA_PER_MENIT


def usia_rata(interval, durasi, latensi):
    if interval is None:
        return latensi
    return interval * 60 / 2 + durasi * 60 + latensi  # detik

Penyajian hasilnya mengubah satuan detik menjadi menit secara otomatis agar mudah dibaca:

print("=== Biaya vs kesegaran: dashboard operasional TokoKita ===")
print(f"{'opsi':<22}{'usia data rata-rata':>21}{'biaya per bulan':>17}")
for nama, interval, durasi, latensi in OPSI:
    biaya = biaya_bulanan(interval, durasi)
    usia = usia_rata(interval, durasi, latensi)
    if usia >= 90:
        tampil = f"{usia / 60:.0f} menit"
    else:
        tampil = f"{usia:.0f} detik"
    print(f"{nama:<22}{tampil:>21}{f'${biaya:,.0f}':>17}")

Output yang Dihasilkan:

=== Biaya vs kesegaran: dashboard operasional TokoKita ===
opsi                    usia data rata-rata  biaya per bulan
batch tiap jam                     87 menit             $864
micro-batch 5 menit                 6 menit           $2,592
streaming penuh                     8 detik           $1,728

Batch -> micro-batch : biaya naik 3.0x, usia data turun 14x
Micro-batch -> stream: biaya naik 0.7x, usia data turun 48.1x

Mari kita telaah baris-baris kode di atas:

1. Blok pertama, baris 6-10 (OPSI): tiga opsi masing-masing menyimpan interval, durasi run, dan latensi hasil; streaming penuh memakai None karena tidak mengenal interval terjadwal.
2. Blok pertama, baris 13-17 (biaya_bulanan): biaya batch dihitung dari jumlah run per bulan dikali durasi dikali harga per menit; streaming dihitung sebagai klaster ramping yang hidup sepanjang bulan.
3. Blok pertama, baris 20-24 (usia_rata): usia data rata-rata = setengah interval + durasi run + latensi — komponen “setengah interval” inilah yang membuat batch jam-an selalu tampak tua berapa pun kecepatan mesinnya.
4. Blok kedua, baris 5-8 (konversi satuan): ambang 90 detik memisahkan penyajian menit dan detik sehingga tabel tetap mudah dibaca.

Membaca Angka Trade-off #

Dua baris terakhir output adalah pelajaran bab ini. Dari batch ke micro-batch, biaya naik tiga kali lipat ($864 menjadi $2.592) untuk memangkas usia data 14 kali lipat (87 menit menjadi 6 menit) — pertukaran yang mahal tapi masuk akal. Kejutannya ada di baris berikutnya: dari micro-batch ke streaming penuh, biaya justru turun ($2.592 menjadi $1.728) sementara usia data turun 48 kali lipat menjadi 8 detik.

Bagaimana streaming bisa lebih murah? Micro-batch menyalakan klaster 288 kali sebulan selama tiga menit setiap kalinya, sedangkan streaming memakai klaster ramping yang tidak pernah dimatikan. Trade-off biaya versus kesegaran ternyata tidak monoton — menaikkan kesegaran tidak selalu menaikkan biaya, dan sebaliknya. Kesimpulan semacam ini hanya bisa muncul dari perhitungan, bukan dari intuisi “streaming pasti lebih mahal”.

Arsitektur adalah Keputusan yang Bisa Direvisi #

Section ini dibuka dengan pola tertua dan ditutup dengan siklus yang mengembalikan kita ke awal: kebutuhan berubah, harga cloud berubah, tim bertambah. Karena itu keputusan arsitektur sebaiknya diperlakukan seperti laporan benchmark — didokumentasikan beserta asumsinya, lalu ditinjau ulang pada tanggal yang disepakati.

Sebagai penutup, berikut trade-off inti dari setiap chapter dalam section ini:

Mesin yang dipakai opsi micro-batch dan streaming pada perhitungan di atas adalah engine berkelas produksi seperti Spark Structured Streaming, yang dokumentasinya tersedia di spark.apache.org .

Dengan sepuluh pola arsitektur, satu pohon keputusan, dan kerangka trade-off berbasis angka, bagian konseptual Course Data Engineering ini tuntas. Section berikutnya, Proyek, mengajak kita menerapkan semuanya dengan tangan sendiri: membangun pipeline ETL terjadwal, merancang data warehouse penjualan, menghidupkan pipeline streaming dengan Kafka, hingga memproses data berskala besar dengan Spark — dipandu langkah demi langkah dari nol sampai berjalan.