Sistem sumber

Topik ini mengenalkan empat jenis sistem sumber data yang paling sering ditemui pada pekerjaan data engineering, yaitu basis data OLTP, API, log kejadian, dan alat SaaS. Setiap jenis dibahas dari karakteristik penyimpanan dan aksesnya, kemudian dipetakan ke pola ekstraksi yang sesuai. Karakteristik log kejadian juga dibuktikan dengan contoh kode yang membaca berkas JSON Lines dan merangkum isinya. Setelah membaca topik ini, jenis sumber pada proyek berikutnya dapat diidentifikasi bersama tantangan ekstraksi yang menyertainya.

Empat jenis sistem sumber#

Sistem sumber (source system) adalah sistem tempat data berada sebelum dipindahkan oleh pipeline data, yakni rangkaian proses yang mengekstrak, mengubah, dan memuat data menuju tempat analisis. Reis dan Housley dalam Fundamentals of Data Engineering menegaskan bahwa sistem sumber tidak diciptakan untuk kebutuhan analitik, melainkan untuk kebutuhan operasionalnya sendiri. Konsekuensinya, bentuk data, skema, dan cara aksesnya ditentukan oleh sistem sumber, sedangkan tugas data engineering adalah menarik data itu tanpa mengganggu sistem yang memilikinya.

Empat jenis sumber berikut mencakup sebagian besar kasus yang ditemui sehari-hari.

Karakteristik yang paling menentukan pola ekstraksi ada tiga. Pertama, apakah data boleh dikueri langsung atau hanya dapat diakses lewat kontrak tertentu. Kedua, apakah datanya bersifat tambah-terus (append-only), yakni baris baru hanya ditambahkan di akhir dan baris lama tidak pernah diubah. Ketiga, siapa yang mengendalikan skemanya, karena skema yang berubah di tangan pihak lain menuntut skrip ekstraksi yang terus menyesuaikan. Basis data memberi kebebasan kueri penuh, API memberi kontrak yang diatur penyedia, sedangkan log kejadian memberi aliran yang hanya bertambah, dan kombinasi sifat-sifat itulah yang menentukan bentuk ekstraksinya.

Basis data OLTP: sumber transaksional#

Basis data OLTP (Online Transaction Processing) dioptimalkan untuk banyak transaksi kecil yang cepat, seperti menyimpan pesanan baru atau memperbarui stok. Skemanya dinormalisasi demi konsistensi penulisan, indeksnya dipilih untuk kecepatan transaksi, dan penulisannya berlangsung terus-menerus dari banyak pengguna. Bentuk ini ideal untuk operasional aplikasi, tetapi tidak ideal untuk agregasi besar yang menyapu jutaan baris dalam sekali jalan. Kueri analitik yang berat pada basis data produksi berpotensi menunda transaksi pengguna, sehingga pola ekstraksinya dirancang untuk menjaga beban tetap kecil.

Ekstraksi dari basis data OLTP mengikuti dua pola utama. Pola pertama adalah kueri inkremental, yaitu kueri yang hanya mengambil baris baru atau yang berubah sejak ekstraksi terakhir dengan menyimpan penanda posisi (watermark), misalnya nilai terbesar kolom updated_at. Pola kedua adalah change data capture (CDC), yakni pembacaan log replikasi bawaan basis data sehingga setiap penulisan ditangkap tanpa kueri berat ke tabelnya. Kedua pola berangkat dari tujuan yang sama, yaitu memindahkan data sambil membiarkan transaksi produksi berjalan seperti biasa.

API: kontrak permintaan dan respons#

API (Application Programming Interface) mengekspos data melalui endpoint, yaitu alamat permintaan HTTP yang dijawab dengan data terstruktur, sehingga ekstraksi berbentuk rangkaian permintaan dan bukan kueri langsung ke basis data. Skema respons, batas ukurannya, dan aturan aksesnya seluruhnya diatur penyedia API, sedangkan pengambil data menyesuaikan diri dengan kontrak tersebut. Ketergantungan pada pihak lain inilah yang membedakan API dari basis data milik sendiri.

Tiga perilaku API wajib diantisipasi sebelum skrip ekstraksi ditulis. Pertama, paginasi (pagination), yaitu pembagian hasil menjadi halaman-halaman kecil sehingga satu permintaan tidak pernah memuat seluruh data, dan skripnya wajib mengikuti penanda halaman sampai halaman terakhir. Kedua, pembatasan laju (rate limit), yakni batas jumlah permintaan dalam selang waktu tertentu yang dijawab dengan error apabila dilanggar. Ketiga, evolusi skema, karena penyedia dapat menambah atau mengubah kolom respons, sehingga pembacaan kolom sebaiknya menoleransi kolom baru tanpa membuat skrip error.

Dokumentasi resmi API selalu menjadi bacaan pertama sebelum kode ekstraksi ditulis. Sebagai contoh, dokumentasi paginasi milik REST API GitHub menjelaskan pola nomor halaman dan tautan menuju halaman berikutnya lewat header respons. Bacalah halaman dokumentasi semacam itu untuk mengetahui batas permintaan dan bentuk paginasinya, karena dua penyedia API tidak selalu memakai kontrak yang sama.

Log kejadian: berkas tambah-terus#

Log kejadian (event log) mencatat peristiwa yang terjadi pada sistem sebagai entri baru yang ditambahkan di akhir berkas, tanpa pernah mengubah entri lama. Format yang lazim untuk log kejadian terstruktur adalah JSON Lines, yakni satu objek JSON per baris, sehingga berkasnya dapat dibaca baris demi baris tanpa memuat seluruhnya ke memori. Format ini juga memudahkan evolusi skema, karena baris baru boleh memuat kolom tambahan tanpa merusak baris lama.

Perhatikan berkas kejadian berikut yang berisi aktivitas sebuah aplikasi catatan selama dua hari.

{"waktu": "2026-01-12T08:02:00", "pengguna": "ali", "jenis": "login"}
{"waktu": "2026-01-12T08:05:00", "pengguna": "ali", "jenis": "catatan_dibuat"}
{"waktu": "2026-01-12T09:14:00", "pengguna": "budi", "jenis": "login"}
{"waktu": "2026-01-12T09:20:00", "pengguna": "budi", "jenis": "catatan_dibuat"}
{"waktu": "2026-01-12T10:01:00", "pengguna": "citra", "jenis": "login"}
{"waktu": "2026-01-13T08:10:00", "pengguna": "ali", "jenis": "catatan_diedit"}
{"waktu": "2026-01-13T09:00:00", "pengguna": "budi", "jenis": "login"}
{"waktu": "2026-01-13T09:30:00", "pengguna": "citra", "jenis": "catatan_dibuat"}

Skrip berikut membaca berkas itu baris demi baris, mengurai JSON pada setiap baris, lalu merangkum jumlah kejadian per jenis dan per hari. Baris yang tidak terurai dicetak sebagai error dan dilewati, sehingga satu baris rusak tidak menghentikan pembacaan seluruh berkas. Jalankan skripnya dari direktori yang memuat kedua berkas.

"""Membaca log kejadian JSON Lines dan merangkumnya per jenis dan per hari."""

import json
from collections import Counter

per_jenis: Counter[str] = Counter()
per_hari: Counter[str] = Counter()

with open("kejadian.jsonl", encoding="utf-8") as berkas:
    for nomor, baris in enumerate(berkas, start=1):
        baris = baris.strip()
        if not baris:
            continue
        try:
            kejadian = json.loads(baris)
        except json.JSONDecodeError:
            print(f"Baris {nomor} dilewati: JSON tidak sah")
            continue
        per_jenis[kejadian["jenis"]] += 1
        per_hari[kejadian["waktu"][:10]] += 1

print("Rekap per jenis:")
for jenis, jumlah in sorted(per_jenis.items()):
    print(f"  {jenis:<16} {jumlah}")
print("Rekap per hari:")
for hari, jumlah in sorted(per_hari.items()):
    print(f"  {hari}  {jumlah}")

Rekap per jenis:
  catatan_dibuat   3
  catatan_diedit   1
  login            4
Rekap per hari:
  2026-01-12  5
  2026-01-13  3

Keluarannya menunjukkan delapan kejadian dari tiga pengguna, yaitu empat login, tiga pembuatan catatan, dan satu penyuntingan catatan. Rekap per hari mencatat lima kejadian pada hari pertama dan tiga kejadian pada hari kedua. Sifat tambah-terus membuat berkas semacam ini nyaman dibaca bertahap, misalnya dengan mencatat posisi byte terakhir yang sudah diproses. Sifat yang sama menjadikan log kejadian bentuk data yang paling alami untuk diproses secara streaming, yaitu pemrosesan kejadian begitu kejadian itu tiba.

Alat SaaS: API terkelola dan ekspor berkas#

Alat SaaS (Software as a Service) menyimpan data organisasi pada sistem milik penyedia, misalnya aplikasi formulir daring atau aplikasi penjadwalan tim, sehingga datanya tidak dapat diakses langsung dari basis datanya. Pintu akses yang ditawarkan umumnya ada dua, yaitu API terkelola milik penyedia dan fitur ekspor berkas. Kedua pintu itu menentukan bentuk ekstraksi yang mungkin dilakukan.

Ekstraksi lewat API terkelola mengikuti seluruh aturan API pada bagian sebelumnya, ditambah satu kendala khas, yaitu kuota permintaan yang mengikat pada paket langganan. Karena itu penjadwalan ekstraksi SaaS perlu menghitung jumlah permintaan halaman terhadap kuota yang tersedia, bukan sekadar seberapa sering data dibutuhkan. Pintu kedua, fitur ekspor berkas, menghasilkan unduhan CSV secara berkala yang lebih lambat tetapi bebas dari kuota permintaan. Pilihan antara keduanya kembali ke pertimbangan yang sama dengan pola lain, yaitu seberapa segar data yang benar-benar dibutuhkan konsumen datanya.

Kesalahan umum#

Tiga kesalahan berikut paling sering muncul ketika ekstraksi dari sebuah sumber diprakarsai.

1. Menjalankan kueri agregasi berat langsung pada basis data OLTP produksi. Penyebabnya, kueri analitik menyita sumber daya yang seharusnya digunakan transaksi pengguna. Perbaikannya, gunakan kueri inkremental yang sempit atau replikasikan data ke salinan terpisah sebelum dianalisis.
2. Mengambil data API tanpa menangani paginasi. Penyebabnya, respons pertama hanya memuat satu halaman sehingga data yang tiba terpotong tanpa pesan error apa pun. Perbaikannya, ikuti penanda halaman sampai halaman kosong, kemudian bandingkan jumlah baris yang tiba dengan perkiraan jumlah data sumber.
3. Mengurai log kejadian yang masih ditulis saat ekstraksi berjalan. Penyebabnya, baris terakhir bisa terpotong sehingga JSON-nya tidak sah. Perbaikannya, proses hanya baris yang terurai sempurna, simpan posisinya, dan lanjutkan pada putaran ekstraksi berikutnya.

Ringkasan#

• Jenis sistem sumber menentukan pola ekstraksinya, sehingga identifikasi sumber selalu mendahului penulisan pipeline.
• Basis data OLTP diekstrak lewat kueri inkremental atau CDC agar transaksi produksi tidak terganggu.
• API diekstrak lewat permintaan berurut yang menghormati paginasi, pembatasan laju, dan skema milik penyedia.
• Log kejadian berbentuk berkas tambah-terus yang mudah dibaca bertahap, sedangkan alat SaaS diekstrak lewat API terkelola atau ekspor berkas.

Referensi#

• Fundamentals of Data Engineering — O’Reilly — Buku Reis dan Housley yang mengelompokkan sistem sumber beserta karakteristik ekstraksinya.
• Using pagination in the REST API — GitHub Docs — Dokumentasi resmi pola paginasi pada REST API.
• An overview of HTTP — MDN Web Docs — Dasar permintaan dan respons HTTP yang mendasari ekstraksi API.