Data Engineering

Building a Self-Healing MongoDB-to-BigQuery ETL Engine in Spring Batch

Bagaimana saya merekayasa pipeline ETL yang sangat tangguh dan adaptif terhadap evolusi skema menggunakan Spring Batch untuk mereplikasi dokumen MongoDB bebas-skema ke BigQuery dalam mode Full dan Incremental.

#Spring Boot #Spring Batch #MongoDB #BigQuery #ETL #Schema Evolution #Self-Healing

Ringkasan Eksekutif

Dalam mereplikasi data transaksional terdistribusi dari MongoDB (database no-SQL yang bebas skema) ke BigQuery (data warehouse relasional berskema ketat), kendala terbesar adalah perubahan struktur data di hulu (dynamic schemas) serta konflik tipe data (polymorphic fields, misalnya kolom userId yang kadang berupa string dan kadang berupa objek). Di sistem sebelumnya, setiap ada perubahan field di MongoDB, pipeline ETL akan macet dan membutuhkan konfigurasi pemetaan kolom secara manual.

Untuk mengatasi ini, saya merancang dan membangun mesin ETL MongoDB-to-BigQuery cerdas berbasis Spring Boot & Spring Batch yang dikontrol secara asinkron dengan penanda watermark hulu, mendukung mode Full Load dan Incremental, serta memperbaiki dirinya sendiri saat mendeteksi bentrok tipe data (polymorphic self-healing).

Fitur Utama & Keunggulan Arsitektur

  1. Dynamic Schema Observation & Evolution: Mesin ETL secara aktif menganalisis struktur dokumen MongoDB yang masuk menggunakan ItemReader Spring Batch yang dinamis. Jika terdeteksi kolom baru yang belum ada di tabel BigQuery tujuan, ETL akan langsung menjalankan perintah DDL ALTER TABLE ADD COLUMN ke BigQuery secara asinkron sebelum memuat data baru. Pengguna tidak perlu mengonfigurasi skema kolom secara manual lagi.
  2. Polymorphic Type Self-Healing: Masalah klasik MongoDB adalah data yang tidak konsisten di field yang sama. Mesin ETL mengimplementasikan deteksi bentrok tipe data di dalam ItemProcessor Spring Batch. Jika tipe data hulu bentrok (misal: String vs Object), mesin secara otomatis melakukan normalisasi tipe (misal: mengonversi objek menjadi representasi JSON String atau memisahkan kolom ke format varian terstruktur) untuk mencegah kegagalan loading di BigQuery.
  3. Double Ingestion Modes (Full & Incremental):
    • Full Load Mode: Replikasi penuh seluruh dokumen MongoDB untuk memulihkan atau me-refresh tabel BigQuery dari awal.
    • Incremental Mode (Watermark-based): Replikasi hemat komputasi dengan membaca log penanda waktu terupdate (updated_at watermark) hulu sehingga hanya memproses data delta terbaru.
  4. MoEngage & GCS Integration: Pipeline ini juga melayani otomatisasi segmentasi tim CRM. Mengintegrasikan BigQuery, GCS, dan MoEngage untuk memperbarui data segmen harian secara otomatis, yang mengeliminasi proses manual unggah CSV dan menghemat waktu tim hingga 24 jam kerja per siklus sinkronisasi.

Dampak Bisnis & Metrik Keberhasilan

  • Zero Maintenance Overhead: Menghilangkan total kebutuhan intervensi manual tim data engineer setiap kali tim produk memperbarui berkas dokumen MongoDB.
  • Keandalan Ingestion Tinggi: Mengurangi tingkat error gagal load data dari yang sebelumnya sering macet menjadi hampir 0% akibat penanganan bentrok tipe data yang adaptif.