Pengalaman Mengadopsi Flink SQL

Latar belakang adopsi Flink SQL

• Ada aplikasi legacy berbasis Flink yang berat dan menggunakan 96 CPU, yang dikelola oleh Azar Matching Dev Team
• Aplikasi ini mengimplementasikan beberapa fitur dalam struktur monolitik sehingga sulit dipelihara
• Ketika node eksekusi diubah karena pekerjaan infrastruktur, muncul masalah sehingga aplikasi tidak berjalan normal
• Perlu diputuskan apakah pemeliharaan akan tetap dilakukan dengan menanggung tingginya kelelahan operasional, atau digantikan dengan cara lain

Opsi yang bisa dipilih

• Fitur-fitur penting dari aplikasi yang ada sebenarnya sudah diimplementasikan di aplikasi Flink yang baru
• Dipikirkan cara untuk menggantikan bagian publikasi event bersyarat dan eksekusi logika
  1. Diimplementasikan sebagai satu Flink App
     • Kelebihan: operasional lebih sederhana
     • Kekurangan: kemungkinan besar aplikasi akan membesar, dan jika satu bagian gagal maka fitur lain juga mudah terdampak
  2. Diimplementasikan sebagai beberapa Flink App
     • Kelebihan: dapat dikelola secara independen
     • Kekurangan: beban meningkat jika jumlah aplikasi bertambah
  3. Menggunakan Flink SQL
     • Kelebihan: logika dapat didefinisikan dengan kueri, dan cukup mengelola satu klaster
     • Kekurangan: sulit mengekspresikan logika yang kompleks, dan bisa sulit jika belum terbiasa mengelola klaster

Alasan memilih Flink SQL dan perbandingan dengan teknologi alternatif

• Sebelum mengadopsi Flink SQL, ksqlDB dan Spark Structured Streaming juga ditinjau
• Alasan memilih Flink SQL:
  1. High Availability
     • Status aplikasi dapat disimpan dan dipulihkan secara stabil melalui Checkpoint dan Savepoint
     • JobManager dapat dikonfigurasi dalam mode HA
  2. Dukungan fitur streaming tingkat lanjut
     • Berbagai fitur pemrosesan streaming didukung dengan sintaks SQL
     • Mendukung window, join, pemrosesan event time, watermark, dan lain-lain
  3. Ekstensibilitas melalui UDF dan Custom Connector
     • Dapat menghubungkan fungsi buatan pengguna serta berbagai data source dan sink

vs ksqlDB

• Walaupun termasuk dalam platform Confluent, operasi HA untuk pemrosesan streaming stateful kurang efisien

vs Spark Structured Streaming

• Diimplementasikan berbasis mesin Spark SQL, dan memungkinkan penulisan UDF serta Custom Sink
• Karena berjalan dalam satuan micro-batch, ini bisa kurang menguntungkan untuk pemrosesan real-time

Membangun lingkungan klaster dan cara deployment kueri

Menguji secara sederhana di lokal

• Diperkenalkan cara menjalankan Flink Cluster di lokal dan mengirimkan kueri SQL

Arsitektur klaster di lingkungan produksi

• Membangun Flink SQL Cluster di atas Kubernetes
• Perbandingan antara Application mode dan Session mode

Deployment kueri dengan pendekatan GitOps

• Menggunakan GitHub Actions untuk deployment kueri dan penghentian Job

Contoh operation utama dan pengalaman troubleshooting

Jika JobManager atau TaskManager mengalami fail

• JobManager dapat terus menjalankan pekerjaan meskipun terjadi fail berkat pengaturan HA
• Jika TaskManager fail, pekerjaan akan didistribusikan ulang dan tetap berjalan

Jika kueri mengalami fail

• Dapat terjadi saat data abnormal masuk atau saat sumber daya komputasi kurang
• Tersedia pengaturan untuk mengabaikan error format JSON dan menetapkan nilai default

Jika sebagian Job mengalami fail saat klaster di-restart

• Perlu mengubah pengaturan timeout dan retry

Jika ingin mengubah satu kondisi kueri lalu melakukan deployment ulang

• Pemulihan state menggunakan savepoint hanya dimungkinkan untuk perubahan sederhana

Poin pemantauan utama

• Periksa metrik seperti numRunningJobs, taskmanager.cpu.load, taskmanager.memory.used, dan lainnya

Penutup

• Adopsi Flink SQL meningkatkan produktivitas dan efisiensi operasional
• Sangat andal, dan ada rencana untuk mengimplementasikan pola GitOps Controller

[flgkselql98]

Sistem terdistribusi seperti Flink perlu mempertahankan 2–3 rack untuk menjaga HA, dan tampaknya dengan mengintegrasikan Kubernetes, HA berhasil dijamin. Namun pada akhirnya tetap perlu memikirkan resource untuk kube slave node, jadi saya jadi bertanya-tanya apakah mereka membangun node yang hanya menjalankan Flink saja (sepertinya bisa ada isu slave node down saat beban Flink tinggi).
Dari sudut pandang itu, apakah ada keuntungan menggunakan Kubernetes?

Selain itu, ketika memakai window function di Flink, data di antaranya akan dipertahankan di memori sehingga pernyataan SQL join bisa berjalan. Jika dilihat dari sudut pandang trade-off, apakah Flink benar-benar pilihan yang baik? Jika seiring waktu SQL + job makin besar lalu job-nya mati, akibatnya akan sangat besar..

Saya juga sedang memikirkan, saat join diperlukan di data source paling atas, alih-alih memakai Flink, dengan cara seperti apa pemrosesannya bisa diturunkan ke level application.