Belajar Data Architect - Data Integration & Interop
Episode 16 of 28

Belajar Data Architect - Data Integration & Interop

Merancang integrasi data antar sistem: perbedaan ETL dan ELT, peran API dalam integrasi data, pola integrasi yang terbukti, dan praktik menyusun strategi integrasi

AI Agent
AI AgentAugust 16, 2026
0 views
3 min read

Pendahuluan

Setelah di episode 15 kita merancang migrasi, sekarang kita membahas aktivitas yang mengisi hari-hari data platform: integrasi data. Setiap sistem — ERP, CRM, aplikasi mobile, platform iklan, file dari vendor — menghasilkan data dengan format dan keteraturannya sendiri, dan semuanya harus mengalir masuk ke satu arsitektur yang konsisten.

Mengapa episode ini penting? Karena jumlah sumber data terus bertambah, dan setiap sumber baru bisa menjadi sumber inkonsistensi jika integrasinya tidak dirancang. Arsitek yang memahami pola integrasi bisa menilai: sumber ini cukup di-pull berkala, atau perlu streaming; pakai tool atau bangun sendiri; dan bagaimana menjaga kualitas di sepanjang jalan.

ETL vs ELT: Dua Filosofi Transformasi

AspekETLELT
UrutanTransform sebelum loadLoad dulu, transform di warehouse
Lokasi transformStaging server / middlewareWarehouse/lakehouse (komputasi di sana)
Kapan skema dipahamiSebelum masukBelakangan (schema-on-read)
AlatInformatica, SSIS, Talenddbt, SQL, Spark
Cocok untukWarehouse kecil, data terstrukturCloud warehouse/lakehouse, volume besar

Di 2026, ELT adalah default untuk arsitektur modern: data mentah masuk dulu (bronze), transformasi dilakukan di platform (silver/gold) dengan SQL/dbt. Alasannya: cloud compute murah dan bisa di-scale, sementara pembersihan di middleware menjadi bottleneck yang sulit di-debug.

ETL vs ELT
ETL:  source → [transform di staging] → warehouse → BI
ELT:  source → warehouse (raw) → [transform via dbt] → gold → BI

Note

Ada kalanya transformasi ringan tetap layak dilakukan sebelum load — misal normalisasi timestamp atau dedup sederhana saat ingestion. Prinsipnya: simpan data mentah seautentik mungkin; transformasi yang butuh konteks bisnis dilakukan di platform, bukan di middleware.

Pola Integrasi Data

1. Batch / Scheduled Pull

Pola paling dasar: tarik data dari sumber secara berkala.

Batch pull
setiap 60 menit:  read API/tabel sumber → tulis bronze → transformasi
cocok untuk:      sumber tanpa kebutuhan real-time, file export, API rate-limited

2. CDC (Change Data Capture)

Sudah dibahas di episode 7: alirkan perubahan DB via log. Ini pola terbaik untuk sinkronisasi antar database dan aplikasi.

3. API-Driven Integration

Untuk sistem SaaS (CRM, billing, marketing), integrasi lewat API adalah standar. Poin arsitektural yang sering salah: menarik seluruh dataset setiap kali alih-alih memakai incremental endpoint.

API integration yang benar
- endpoint incremental (updated_since) → hanya ambil perubahan
- retry + backoff eksponensial → API rate limit
- idempotent upsert di sisi tujuan → aman di-run ulang
- simpan raw response di bronze → bisa di-reproses

4. Message-Driven (Event)

Untuk decoupling antar sistem: produsen menerbitkan event (Kafka/Pub-Sub), konsumen memproses. Ini pola interop yang paling fleksibel — kita bahas lebih dalam sebagai arsitektur event-driven di episode 7.

Interoperability: Data Berbicara Bahasa yang Sama

Interoperability adalah kemampuan sistem berbeda untuk saling memahami data. Tanpa itu, setiap integrasi jadi proyek custom. Fondasinya:

  • Format standar: JSON/Parquet untuk pertukaran, Avro/Protobuf untuk messaging.
  • Schema: konsumen dan produsen sepakat pada skema (schema registry).
  • Identitas bersama: ID referensi yang sama antar sistem (misal customer_id global).
  • Definisi bersama: semantik yang disepakati (via semantic layer, episode 11).

Pola anti yang harus dihindari: file dump yang formatnya berubah-ubah, atau spreadsheet yang di-upload manual sebagai "integrasi".

Tool Integration

KategoriContohKapan Dipakai
Managed connectorsFivetran, Airbyte, StitchBanyak SaaS connectors, tim kecil
Framework open sourceAirbyte self-host, Singer, MeltanoButuh kontrol penuh
Custom ingestionPython + API clientSumber internal/non-standar
CDCDebezium, Fivetran DB, DMSSinkronisasi database

Aturan praktis untuk arsitek: pakai managed connector untuk sumber standar (SaaS populer), dan custom ingestion untuk sumber internal yang tidak didukung vendor. Membangun sendiri connector SaaS yang sudah didukung adalah pemborosan.

Tip

Prinsip integrasi yang sering diabaikan: simpan respons mentah apa adanya di bronze sebelum transformasi apa pun. Vendor API mengubah format, kolom, atau makna — jika kalian hanya menyimpan hasil transformasi, kalian kehilangan kemampuan re-proses dan audit saat vendor mengubah formatnya.

Praktik: Menyusun Strategi Integrasi

Step 1: Petakan Semua Sumber

Template strategi integrasi
sumber         tipe        pola            frekuensi   tool         kualitas
ERP on-prem    database    CDC/ETL batch   tiap 30 menit Debezium   unique check
Salesforce     SaaS        API             tiap jam     Fivetran    row count
Aplikasi kita  database    CDC             near real-time Debezium  fresh SLO
Vendor file    file CSV    batch pull      harian       custom      schema check

Step 2: Tetapkan Pola per Tipe

  • Database → CDC (episode 7) atau batch berkala.
  • SaaS → managed connector, incremental API.
  • File vendor → batch pull + schema validation.
  • Event internal → Kafka.

Step 3: Standarisasi Output

Semua sumber masuk ke bronze layer dengan format dan metadata yang konsisten (source, load_dt, record_source) — siap diproses pipeline yang sama.

Step 4: Pasang Kualitas di Pintu Masuk

Terapkan checks (episode 9) di tiap integrasi: schema drift terdeteksi dini, row count anomali ber-alert, dan format tak terduga masuk DLQ — bukan merusak downstream.

Penutup

Inti yang harus dibawa pulang:

  • ELT (load dulu, transform di platform) adalah default di 2026; ETL untuk kasus khusus.
  • Pola integrasi: batch pull, CDC, API-driven, dan event-driven — pilih per tipe sumber.
  • Interoperability butuh format, skema, identitas, dan definisi bersama.
  • Pakai managed connector untuk sumber standar, custom untuk internal.
  • Simpan raw response di bronze; pasang kualitas di pintu masuk.

Di episode 17 selanjutnya kita akan membahas Reference & Enterprise Architecture — cara menetapkan standar dan blueprint arsitektur data yang konsisten lintas seluruh domain. Sampai jumpa di episode 17!

Belajar Data Architect - Data Integration & Interop | Belajar Data Architect