Belajar Apache Flink - Konsep Dasar & Arsitektur Apache Flink

#Pendahuluan

Episode 1 sudah menjawab mengapa Flink ada. Episode 2 ini membangun jembatan konsep: sebelum menulis kode, kalian harus paham cara Flink memandang dunia. Tiga konsep akan kita bedah: apa itu stream dan lapisan API-nya, bagaimana Flink memahami waktu, dan bagaimana komputasi stateful serta arsitektur eksekusinya bekerja.

Konsep-konsep ini bukan sekadar teori — setiap keputusan desain di episode berikutnya (windowing, checkpointing, tuning) berakar dari bab ini. Jika kalian menguasai episode 2, bagian teknis lain akan terasa seperti variasi dari satu cerita yang sama. Mari kita mulai.

#Stream dan Lapisan API

#Model Stream yang Unbounded

Di Flink, semua data dipandang sebagai stream. Ada dua jenis: bounded stream (data terbatas, seperti file yang sudah lengkap) dan unbounded stream (data yang terus mengalir tanpa akhir, seperti log Kafka). Konsep ini penting karena Flink memperlakukan batch sebagai kasus khusus dari streaming.

#DataStream API, Table API, dan SQL

Flink menyediakan beberapa lapisan API dengan tingkat abstraksi berbeda:

• DataStream API: API imperatif berbasis Java/Scala untuk kontrol penuh atas state, waktu, dan transformasi.
• Table API: API deklaratif ala SQL dengan pipeline berbasis tabel dinamis.
• Flink SQL: bahasa SQL penuh untuk query streaming, paling ringkas dan paling dekat dengan kebutuhan analitik.
• DataSet API: API batch lama yang kini didepresiasi dan diarahkan ke Table API.

Lapisan-lapisan ini bisa dicampur dalam satu aplikasi. Misalnya, kalian bisa membuat source dengan DataStream API, lalu menganalisisnya dengan Flink SQL.

Flink SQL dan Table API
        ↑
DataStream API (V1 dan V2)
        ↑
Runtime dan State Management

#Alur Pipeline Dasar

Setiap aplikasi Flink mengikuti pola yang sama: source → transformasi → sink. Source memasok data, transformasi mengubahnya, dan sink menuliskannya ke tujuan. Kita akan mengisi detail setiap tahap ini sepanjang series.

#Konsep Waktu: Event, Processing, dan Ingestion

#Tiga Definisi Waktu

Flink membedakan tiga jenis waktu yang sering membingungkan pemula:

• Event time: waktu ketika event benar-benar terjadi di sumber (timestamp di dalam data). Ini yang paling akurat.
• Ingestion time: waktu ketika event masuk ke sistem Flink.
• Processing time: waktu ketika event diproses oleh sebuah operator, yaitu waktu mesin lokal.

Perbedaan ini krusial. Bayangkan log dikirim dengan delay 5 menit: event time menunjuk momen kejadian sebenarnya, sedangkan processing time menunjuk saat data baru diproses. Untuk analitik yang akurat, hampir selalu gunakan event time.

#Watermark sebagai Penanda Kemajuan

Karena event bisa datang terlambat, Flink memakai watermark untuk menandai "sejauh mana waktu event yang sudah aman untuk diproses". Watermark akan kita bedah mendalam di episode 5. Untuk sekarang, anggap saja ia sebagai jam dinding yang bergerak mengikuti data, bukan jam dinding sistem.

{"event": "order_created", "ts": "2026-08-10T10:15:30Z", "amount": 120000}

Baris di atas adalah contoh event berformat JSON dengan kolom ts sebagai event time. Kolom semacam inilah yang akan dipakai Flink untuk windowing di episode 5 dan 9.

#Stateful Computation

#Mengapa State Diperlukan

Banyak analitik tidak bisa dilakukan event-per-event: menghitung total transaksi per pengguna, mendeteksi pola berurutan, atau menghitung metrik berjalan semuanya butuh mengingat sesuatu dari masa lalu. Memori inilah yang disebut state.

#State Backend dan Checkpointing

State disimpan di state backend — ada yang di memory (HashMap) dan ada yang di disk (RocksDB). Agar state tidak hilang saat proses mati, Flink membuat checkpoint secara periodik — snapshot state dan posisi konsumsi source. Dengan checkpoint, Flink bisa memberikan jaminan exactly-once: setiap event diproses tepat satu kali, bahkan saat terjadi kegagalan.

#Savepoint vs Checkpoint

Selain checkpoint otomatis, ada savepoint — snapshot yang dibuat secara manual dan dipakai untuk upgrade, migrasi, atau recovery terkontrol. Kita akan membedah perbedaannya di episode 7 dan 16.

execution.checkpointing.interval: 1min
execution.checkpointing.mode: exactly-once
state.backend.type: rocksdb

Cuplikan konfigurasi di atas mengaktifkan checkpoint tiap menit dengan mode exactly-once dan state backend RocksDB. Detail setiap baris akan kita bahas di episode 6.

#Arsitektur Eksekusi

#JobManager: Otak Cluster

JobManager adalah proses koordinator: menerima job, mengelola checkpoint, menjadwalkan task, dan memulihkan kegagalan. Ia menyimpan metadata tetapi bukan data hasil proses. Ada dua mode: session mode (satu cluster dipakai banyak job) dan application mode (satu cluster per aplikasi).

#TaskManager dan Task Slots

TaskManager adalah pekerja: menjalankan task dari job dan menyimpan state serta buffer. Setiap TaskManager punya sejumlah task slots — unit sumber daya (memory dan CPU) untuk menjalankan subtask. Jumlah slot menentukan seberapa banyak subtask yang bisa berjalan bersamaan di satu proses.

#Parallelism dan Subtask

Setiap operator punya parallelism: berapa banyak subtask paralel yang menjalankannya. Satu subtask memakai satu slot. Misalnya, operator dengan parallelism 4 menjalankan 4 subtask di 4 slot. Hubungan antara sumber daya dan parallelism ini menjadi kunci tuning performa di episode 14 dan 15.

JobManager (1)
  ├── checkpoint coordinator
  └── scheduler
TaskManager (2 proses)
  ├── slot 1 → subtask map [0]
  ├── slot 2 → subtask map [1]
  ├── slot 3 → subtask window [0]
  └── slot 4 → subtask window [1]

Struktur di atas menggambarkan sebuah job dengan dua operator (map dan window), masing-masing parallelism 2, yang berjalan di dua TaskManager dengan total empat slot. Pahami bahwa parallelism menentukan berapa banyak subtask, dan slot menentukan kapasitas menjalankannya.

#Penutup

Episode 2 membangun kerangka berpikir Flink: semua data adalah stream, dikelola lewat DataStream API, Table API, atau SQL; waktu dipahami lewat event time, processing time, dan ingestion time; komputasi stateful dijalankan di atas state backend dengan checkpointing dan savepoints; dan eksekusi diorkestrasi oleh JobManager serta TaskManager dengan slot dan parallelism.

Inti yang harus dibawa pulang:

• Batch adalah kasus khusus dari streaming: Flink memandang semua data sebagai stream.
• Gunakan event time untuk analitik yang akurat, dan pahami tiga definisi waktu Flink.
• State memungkinkan komputasi stateful; checkpointing menjamin exactly-once.
• Savepoint dipakai untuk upgrade dan migrasi terkontrol, berbeda dari checkpoint otomatis.
• JobManager mengkoordinasikan, TaskManager mengeksekusi, slot adalah unit sumber daya, dan parallelism menentukan jumlah subtask.

Di episode 3 selanjutnya kita akan membahas instalasi dan menjalankan job Flink — struktur direktori Flink, konfigurasi di config.yaml dan flink-conf.yaml, menjalankan aplikasi dengan flink run, memahami lifecycle job, dan membaca web dashboard. Kita akan mempraktikkan apa yang baru kalian pahami di episode 2.