Konsep Data Ingestion

Toko online kita sudah memiliki database operasional untuk pesanan, file ekspor CSV dari penyedia jasa pengiriman, dan data pembayaran yang hanya bisa diambil lewat API payment gateway. Ketiga data tersebut tersebar di sistem berbeda dengan format berbeda, sementara tim analitik membutuhkan semuanya di satu tempat yang siap diquery. Pekerjaan memindahkan data dari sumber ke sistem analitik inilah yang diselesaikan oleh ingestion — tahap pertama dari setiap pipeline data. Sebelum masuk ke implementasi per jenis sumber, kita petakan dulu konsep, pola, dan tantangan ingestion secara menyeluruh.

Apa Itu Data Ingestion #

Data ingestion adalah proses memindahkan data dari satu atau banyak sumber ke sistem tujuan — biasanya staging area, data lake, atau data warehouse — agar data siap dibersihkan dan ditransformasi lebih lanjut. Batasnya perlu dipahami sejak awal: ingestion memindahkan data dengan perubahan seminimal mungkin, sementara pembersihan, penyeragaman format, dan penggabungan antar tabel adalah pekerjaan tahap transformasi. Membebani tahap ingestion dengan logika bisnis yang berat membuat pipeline sulit diuji dan diperbaiki karena dua masalah berbeda bercampur dalam satu kode.

Posisi Ingestion dalam Pipeline Data #

Dalam arsitektur umum, ingestion berdiri di antara sumber data dan sistem penyimpanan analitik. Diagram berikut memperlihatkan posisi tersebut:

Semua data dari sumber melewati satu gerbang ingestion menuju staging, baru kemudian ditransformasi dan dimuat ke data warehouse. Penempatan ingestion sebagai gerbang tunggal memiliki konsekuensi penting: ketika data yang masuk salah — kolom tertukar, baris ganda, baris terpotong — kesalahan tersebut menular ke seluruh tahap sesudahnya. Karena itu kualitas pipeline ditentukan paling awal di tahap ingestion, bukan di tahap analitik.

Pola Push dan Pull #

Dari sisi siapa memulai pemindahan, ingestion terbagi menjadi dua pola. Pola pull berarti sistem ingestion kita yang aktif mengambil data dari sumber secara berkala — membaca file ekspor, menjalankan SELECT, atau memanggil API. Pola push berarti sumber yang mengirim data begitu data tersedia, misalnya webhook dari payment gateway atau event yang ditulis ke message queue.

Kedua pola tidak saling menggantikan. Praktik umum: data inti yang berubah perlahan ditarik lewat pull terjadwal, sedangkan event yang bergerak cepat seperti notifikasi pembayaran didorong lewat push.

Sumber Data yang Umum #

Empat kelompok sumber berikut menutup hampir semua kasus ingestion di dunia nyata:

• File: ekspor CSV atau JSON dari sistem POS, laporan harian mitra, file log aplikasi. Termurah dan paling umum, tetapi tanpa kontrak skema yang ketat.
• Database operasional: tabel pelanggan, produk, dan pesanan di database OLTP toko. Terstruktur, tetapi harus diekstraksi hati-hati agar tidak mengganggu beban transaksi.
• API: payment gateway dan layanan pengiriman menyediakan endpoint REST yang mengembalikan JSON. Perlu autentikasi, penanganan galat, dan pagination.
• Stream dan message queue: event klik pengunjung atau status pembayaran yang mengalir terus, biasanya lewat Kafka . Ingestion untuk sumber jenis ini berjalan tanpa henti, bukan sekali jalan.

Empat sumber tersebut tidak saling meniadakan dalam satu perusahaan. Toko online kita menarik tabel pesanan dari database operasional tiap malam, membaca ekspor CSV jasa pengiriman tiap pagi, memanggil API payment gateway untuk rekonsiliasi mingguan, dan menerima webhook untuk setiap pembayaran yang berhasil. Section ini membedah tiap pola satu per satu: batch dan incremental sebagai strategi jendela waktu, lalu file, database, API, dan webhook sebagai jenis sumber, sebelum ditutup dengan message queue dan change data capture untuk kebutuhan yang menuntut kebaruan lebih tinggi.

Tantangan Utama Ingestion #

Tiga tantangan muncul hampir di setiap proyek. Pertama, heterogenitas: satu pipeline bisa menampung CSV tanpa skema, JSON bertingkat, dan tabel relasional sekaligus, sehingga penyeragaman format harus dirancang sejak awal. Kedua, volume: tabel pesanan yang hari ini berisi satu juta baris bisa tumbuh puluhan ribu baris per bulan, sehingga strategi menyalin seluruh tabel setiap hari cepat menjadi mahal. Ketiga, keandalan: jaringan terputus di tengah run, file terkirim setengah jadi, dan pengiriman ulang yang memicu baris ganda adalah kejadian normal — bukan pengecualian — dan wajib ditangani oleh desain.

Pemahaman konsep ini menjadi landasan untuk keputusan berikutnya: seberapa sering data diambil dan berapa banyak data yang dipindahkan per run. Kita mulai dari pola paling sederhana dan paling banyak dipakai di chapter Batch Ingestion.