Data Contract: Cara Menjaga Kualitas dan Konsistensi Data Antar Sistem

Ketika data digunakan oleh banyak tim, perubahan kecil pada satu sistem dapat menimbulkan masalah besar di tempat lain. Kolom yang berganti nama, tipe angka yang berubah, atau pembaruan data yang terlambat bisa membuat dashboard keliru, pipeline gagal, bahkan model machine learning menerima masukan yang tidak sesuai. Masalahnya sering bukan karena satu tim bekerja buruk, melainkan karena harapan antarprodusen dan pengguna data tidak pernah disepakati secara eksplisit.

Data contract membantu menutup celah tersebut. Ia mendokumentasikan apa yang dijanjikan oleh pihak yang menyediakan data dan apa yang dapat diandalkan oleh pihak yang menggunakannya. Dengan aturan yang dapat diuji secara otomatis, perubahan tidak harus menunggu sampai laporan rusak untuk diketahui.

Apa itu data contract?

Data contract adalah kesepakatan terstruktur antara produsen dan konsumen data. Isinya bukan hanya daftar kolom, tetapi juga arti setiap bidang, aturan kualitas, jadwal pembaruan, penanggung jawab, serta cara perubahan dikelola. Bentuknya dapat berupa berkas yang disimpan bersama kode, dokumen terkelola, atau konfigurasi yang diperiksa oleh pipeline.

Skema database menjelaskan bentuk data saat ini. Kontrak melangkah lebih jauh dengan menjelaskan jaminan yang diharapkan. Misalnya, tabel transaksi tidak sekadar memiliki kolom amount; kontraknya juga dapat menyatakan bahwa nilai harus nonnegatif, memakai satuan mata uang yang jelas, dan diperbarui sebelum waktu tertentu.

Komponen yang sebaiknya dicantumkan

• Identitas dan versi: nama dataset, tujuan, pemilik, lingkungan, dan versi kontrak yang berlaku.
• Skema dan semantik: nama serta tipe kolom, apakah wajib diisi, arti bisnisnya, satuan, zona waktu, dan makna satu baris data.
• Aturan kualitas: keunikan kunci, batas nilai, format, kelengkapan, relasi antarkolom, serta cara menangani data tidak valid.
• Ekspektasi operasional: frekuensi pembaruan, batas keterlambatan, ketersediaan, dan apa yang dianggap sebagai pelanggaran layanan.
• Kepemilikan dan akses: tim yang bertanggung jawab, jalur eskalasi, klasifikasi sensitivitas, dan tujuan penggunaan yang diizinkan.
• Kebijakan perubahan: perubahan yang kompatibel, periode transisi, tanggal penghentian bidang lama, dan prosedur pemberitahuan konsumen.

Tidak semua proyek harus memulai dengan dokumen besar. Untuk dataset kecil, kontrak awal yang berisi skema, arti bidang penting, beberapa pemeriksaan kualitas, dan kontak pemilik sudah memberikan manfaat nyata. Detail lain dapat ditambahkan saat kebutuhan meningkat.

Contoh sederhana

Bayangkan tim transaksi menyediakan data pesanan untuk tim keuangan dan analitik. Kontrak dapat menetapkan bahwa order_id harus unik, amount tidak boleh negatif, currency harus memakai kode yang disepakati, dan data harian tersedia paling lambat pukul 06.00. Kontrak juga menunjuk tim pemilik serta menjelaskan bahwa mengganti nama kolom adalah perubahan yang memerlukan migrasi konsumen.

Contoh YAML berikut hanya ilustrasi konsep, bukan skema baku dari suatu standar:

dataset: orders
version: 1.0.0
owner: team-commerce
fields:
  order_id:
    type: string
    required: true
    unique: true
  amount:
    type: decimal
    required: true
    minimum: 0
expectations:
  freshness_hours: 24
change_policy:
  breaking_changes: require_new_version

Dalam penerapan nyata, format perlu disesuaikan dengan standar dan alat yang dipilih. Organisasi yang membutuhkan format lintas alat dapat meninjau Open Data Contract Standard dan menentukan versi yang sesuai dengan ekosistemnya.

Langkah menerapkan data contract

1. Mulai dari dataset yang penting. Pilih sumber data yang sering dipakai banyak konsumen atau yang dampak kegagalannya besar. Jangan mencoba membuat kontrak untuk seluruh perusahaan sekaligus.
2. Petakan produsen dan konsumen. Catat siapa yang menghasilkan data, siapa yang menggunakannya, keputusan apa yang bergantung pada data tersebut, dan kapan data harus tersedia.
3. Sepakati arti dan jaminan. Diskusikan definisi bisnis, tipe data, batas kualitas, jadwal pembaruan, privasi, serta prosedur ketika janji tidak terpenuhi. Istilah yang ambigu sebaiknya diselesaikan sebelum otomatisasi dibuat.
4. Simpan kontrak dalam version control. Perlakukan perubahan kontrak seperti perubahan kode: ditinjau, diberi versi, dan memiliki riwayat. Hindari mengandalkan dokumen yang tidak diketahui siapa pemilik atau kapan terakhir diperbarui.
5. Jalankan pemeriksaan di pipeline. Validasi data saat diproduksi atau sebelum diteruskan ke konsumen. Jika pemeriksaan gagal, kirim peringatan yang menyebutkan aturan, dataset, waktu, dan pemiliknya; jangan hanya menampilkan pesan umum.
6. Kelola perubahan secara bertahap. Perubahan yang menambah kolom opsional mungkin aman, sedangkan penghapusan kolom atau perubahan makna biasanya berisiko. Berikan masa transisi, dokumentasikan migrasi, dan pantau konsumen yang masih memakai versi lama.

Pengujian dan pemantauan

Kontrak bukan jaminan bahwa data selalu benar. Ia adalah kumpulan ekspektasi yang perlu diuji. Pemeriksaan skema dapat menangkap tipe atau kolom yang berubah; pemeriksaan kualitas mendeteksi nilai kosong, duplikasi, dan rentang yang tidak wajar; pemantauan kesegaran menunjukkan apakah pembaruan terlambat. Pemeriksaan semantik juga penting: nilai dapat lolos validasi tipe tetapi tetap salah jika satu tim menganggap waktu sebagai UTC dan tim lain memakai waktu lokal.

Catat hasil pemeriksaan dan tren pelanggaran dari waktu ke waktu. Tetapkan ambang yang realistis agar peringatan tidak terlalu sering berbunyi tanpa tindakan. Setiap insiden sebaiknya memiliki pemilik, dampak yang jelas, dan tindak lanjut untuk memperbaiki sumber masalah, bukan sekadar membersihkan hasil akhir.

Kesalahan yang perlu dihindari

Kesalahan umum adalah memperlakukan kontrak sebagai dokumentasi statis, membuat aturan yang tidak bisa diuji, atau menetapkan target kesegaran tanpa mempertimbangkan kemampuan sistem sumber. Hindari pula perubahan diam-diam yang memaksa konsumen menebak sendiri. Jangan menjanjikan tingkat layanan yang tidak dapat dipantau, dan jangan memasukkan data sensitif ke contoh kontrak atau log pengujian.

Kesimpulan

Data contract membuat hubungan antarprodusen dan konsumen data lebih jelas, terukur, dan dapat diuji. Mulailah dari satu dataset penting, sepakati makna serta aturan kualitasnya, simpan perubahan dalam version control, lalu integrasikan validasi ke pipeline. Hasil terbaik bukan dokumen paling panjang, melainkan kesepakatan yang dipahami tim, dijalankan otomatis, dan diperbarui ketika kebutuhan berubah.

Referensi: Open Data Contract Standard dan Data Contract Specification (repositori proyek).