Apa Itu Data Contract? Panduan Pemula dengan Contoh

Data Contract Semantik

Validasi data semantik memastikan data konsisten secara logis dan selaras dengan logika bisnis.

Validasi semantik harus ditegakkan secara eksplisit.

Memang, tidak seperti pemeriksaan skema, data contract semantik bergantung pada logika bisnis dan harus diimplementasikan secara eksternal.

Dalam banyak skenario penggunaan, semantik tampak seperti perluasan kontrak yang tervalidasi skema. Sering kali, ini bergantung pada aturan bisnis dan merepresentasikan serangkaian kondisi baris yang harus dipatuhi oleh model data kita. 

Contoh kontrak semantik dapat berupa hal berikut:

• Deviasi metrik: dari moving average atau ambang batas lainnya. Memang, kita masih bisa menerima jumlah pengguna aktif kemarin turun di bawah 75% dari moving average 7 hari, tetapi tidak akan mentolerir 0%.
• Logika bisnis: Flag peringatan pemantauan transaksi dan skor pencegahan penipuan. Dalam skenario ini, pembayaran harus 0.
• Garis keturunan data (data lineage): Ini menjelaskan bagaimana entitas data berkembang. Misalnya, transaction_completed_at tidak mungkin terjadi sebelum created_at.
• Integritas referensial: Hubungan entitas itu penting dan juga dapat dijelaskan menggunakan kontrak semantik. Pertimbangkan kode dbt di bawah. Kode tersebut menjelaskan bahwa setiap refund_id pada refund dipetakan kembali ke transaction.id yang valid.

- name: refunds
   enabled: true
   description: An incremental table
 columns:
     - name: refund_id
       tests:
         - relationships:
             tags: ['relationship']
             to: ref('transactions')
             field: id

Penentuan tingkat peringatan pada kontrak semantik diserahkan kepada pengguna akhir, dan ini sering diimplementasikan dengan pengujian kualitas data kustom.

Berbagai aturan logika bisnis sering merujuk pada integritas data. Skenario data yang tidak logis dapat muncul dari kesalahan dalam konfigurasi basis data dan server atau injeksi tidak sengaja data uji ke lingkungan produksi. Pemeriksaan integritas data dirancang untuk memvalidasi data terhadap aturan bisnis tersebut, membantu mengidentifikasi nilai yang tidak terlihat benar atau tidak logis.

Entitas basis data selalu saling terkait. Ini disebut hubungan entitas dan sering disajikan dengan diagram hubungan entitas (ERD). Integritas referensial yang tidak memadai dapat menyebabkan masalah seperti data hilang atau tidak lengkap. Data contract harus mengatasi potensi jebakan ini untuk memastikan integritas dan ketepatan data.

Sebagai contoh, hubungan umum adalah asosiasi one-to-many antara customers dan orders di mana satu pelanggan dapat memiliki banyak orders. Dalam skenario seperti ini, sebuah order dianggap valid hanya jika memuat customer_id yang valid dalam dataset customers.

Jenis constraint ini, yaitu constraint integritas referensial, memastikan bahwa hubungan antar entitas terjaga dengan akurat.

Service Level Agreement (SLA) dalam Data Contract

SLA adalah tingkat tambahan pemeriksaan kualitas data yang dapat diimplementasikan menggunakan data contract.

SLA merujuk pada kebaruan data (data freshness).

Karena model data diperbarui secara berkala dengan data baru, SLA dapat mencakup pemeriksaan waktu terbaru saat data baru diharapkan tersedia atau keterlambatan maksimum yang dapat diterima. Misalnya, di dbt, ini dapat dicapai menggunakan freshness test berikut:

- name: orders
   enabled: true
   description: A source table declaration
   tests:
     - dbt_utils.recency: # https://github.com/dbt-labs/dbt-utils#recency-source
         tags: ['freshness']
         datepart: day
         field: timestamp
         interval: 1

Misalkan kita ingin membuat laporan mengenai kejadian kemarin; untuk itu, kita perlu memastikan datanya ada. Memang, akan terasa janggal jika tidak melihat order baru selama beberapa hari atau lebih.

Pada contoh di bawah, kita dapat menguji dataset untuk keterlambatan order yang tidak terduga menggunakan konfigurasi test di dbt. Ini memungkinkan Anda memilih dan mereferensikan test menggunakan nama spesifik tersebut.

version: 2
models:
 - name: orders
   columns:
     - name: status
       tests:
         - accepted_values:
             name: unexpected_order_status_today
             values: ['placed', 'shipped', 'completed', 'returned']
             config:
               where: "order_date = current_date"

Dengan mendefinisikan nama kustom, Anda mendapatkan kendali penuh atas bagaimana test ditampilkan dalam pesan log dan artefak metadata.

Demikian pula, dalam pipeline data real-time, data biasanya diharapkan tidak lebih tua dari beberapa jam. SLA penting untuk aplikasi pemrosesan stream di mana data diproses secara real time dengan latensi menit atau bahkan detik.

Dalam aplikasi streaming, kita ingin memeriksa keterlambatan maksimum yang dapat diterima untuk peristiwa yang datang terlambat serta metrik seperti Mean Time Between Failures (MTBF) dan Mean Time to Recovery (MTTR). Penerapannya melibatkan pelacakan insiden secara cermat dan mengekstrak data relevan dari alat pemantauan aplikasi dan manajemen insiden seperti PagerDuty, Datadog, dan Grafana.

Kontrak Tata Kelola Data

Penanganan Personally Identifiable Information (PII) secara benar adalah bagian integral dari proses transformasi data. Bagi banyak perusahaan, sangat penting agar dataset ini setidaknya patuh GDPR dan mematuhi peraturan privasi data seperti HIPAA atau PCI DSS.

Kontrak tata kelola data memastikan kebijakan pseudonimisasi atau pem masking data yang memadai sudah diterapkan. 

Pertimbangkan kode dbt di bawah. Kontrak yang ditegakkan sebagai tests mewajibkan user_email berupa hash SHA256 (dimasking):

models:
 - name: customer_data
   columns:
       - name: user_email
         tests:
           - dbt_expectations.expect_column_values_to_not_match_regex:
               regex: "^(?!.*\b@\b).* # Ensure identifiers do not contain emails
               flags: i # Case-insensitive matching

Di sisi lain, kita mungkin ingin menegakkan pencocokan pola untuk tabel lain. Misalnya, pada contoh di bawah, field transaction_reference harus mengikuti pola [“TRX-%”, “%-2023”]:

models:
 - name: transaction_data
   columns:
       - name: transaction_reference
         tests:
           - dbt_expectations.expect_column_values_to_match_like_pattern_list:
               like_pattern_list: ["TRX-%", "%-2023"]
               match_on: any

Kontrak tata kelola data juga bermanfaat ketika mencakup kolom dengan data sensitif, metadata (pemilik data, dan lain-lain), serta peran pengguna yang berwenang mengakses produk data.

Sebagai contoh, kita dapat menunjukkan pemilik model data dan tahap siklus pengembangan model menggunakan field meta di dbt:

# models/schema.yaml
version: 2
models:
 - name: users
   meta:
     owner: "@data_mike"
     model_maturity: in dev
     contains_pii: true
   columns:
     - name: email
       meta:
       contains_pii: true

Field meta memungkinkan Anda menetapkan metadata untuk suatu resource, yang kemudian dikompilasi ke dalam berkas manifest.json yang dihasilkan oleh dbt dan dapat dilihat di dokumentasi yang dihasilkan secara otomatis. 

Kita dapat menggunakan paket seperti dbt-checkpoint untuk memindainya selama pull request guna memastikan field meta wajib kita ada. Hook akan gagal jika ada model (dari manifest atau berkas YAML) yang tidak memiliki kunci meta yang ditentukan.

Kunci meta model harus ada di berkas YAML atau manifest.

Pola Implementasi Data Contract

Validasi kontrak dapat dilakukan dalam pipeline data streaming (per baris) sebelum data diingest dan sesudahnya — di sumber (lapisan model data sumber).

Saat kita mengingest data “apa adanya”, proses validasi bertindak seperti langkah transformasi, menegakkan aturan kontrak dan menyaring data tidak valid, misalnya ke dalam view atau tabel basis data khusus tempat data dapat diselidiki lebih lanjut.

Pemeriksaan validasi dapat diterapkan secara post-facto ketika data diingest langsung ke raw data lake.

Keunggulan utama validasi data contract real-time adalah kemampuannya menyaring catatan tidak valid sebelum mencapai tujuan akhir — data lake atau data warehouse. Pendekatan ini lazim pada pemrosesan data berbasis event atau real time, seperti peristiwa Change Data Capture (CDC). Pada jenis validasi ini, aspek tertentu dari kontrak diverifikasi saat data mengalir melalui pipeline.

Alat Data Contract

Komunitas data secara bertahap menyadari potensi manfaat data contract, sebuah area rekayasa data yang terus berkembang. Banyak alat tersedia di ruang ini, beberapa masih pada tahap awal. dbt dapat dianggap sebagai kerangka kerja universal untuk data contract.

Kontrak serupa dapat diimplementasikan menggunakan Dataform milik Google di sumber (lapisan model data sumber), yaitu saat data berhasil diingest ke data warehouse kita. Untuk ini, kita ingin menggunakan kondisi baris sederhana. 

Pertimbangkan contoh berikut. Ia menerapkan kondisi baris tertentu untuk tabel kita:

-- my_table.sqlx
config {
 type: "table",
 assertions: {
   nonNull: ["user_id", "customer_id", "email"]
 }
}
SELECT …

Berikut contoh lain implementasi data contract, yang dapat dicapai menggunakan Soda.io, kerangka kerja kualitas data khusus:

# Checks for basic validations
checks for dim_customer:
 - row_count between 10 and 1000
 - missing_count(birth_date) = 0
 - invalid_percent(phone) < 1 %:
     valid format: phone number
 - invalid_count(number_cars_owned) = 0:
     valid min: 1
     valid max: 6
 - duplicate_count(phone) = 0

Menyesuaikan pengaturan peringatan memungkinkan Anda mengonfigurasi pemeriksaan agar mengeluarkan peringatan alih-alih menggagalkan validasi. Pemindaian Soda menjalankan pemeriksaan yang ditentukan dalam perjanjian, memeriksa berkas YAML atau inline dalam pemanggilan programatik, dan mengembalikan hasil untuk setiap pemeriksaan: lulus, gagal, atau galat.

Dari pengalaman saya, pengenalan data contract di banyak perusahaan masih terfragmentasi, tergantung faktor seperti pola desain pipeline data (batch atau real time), pilihan serialisasi data, serta sistem yang digunakan untuk penyimpanan dan pemrosesan.

Implementasi data contract bergantung pada kebutuhan dan logika bisnis.

Great Expectations, pustaka Python, dapat digunakan untuk mengimplementasikan data contract tingkat semantik. Pemasangan dapat dilakukan dengan pip: pip install great_expectations. 

Setelah menjalankan great_expectations init, kita dapat melanjutkan dengan validasi data:

Using v3 (Batch Request) API
 ___              _     ___                  _        _   _
/ __|_ _ ___ __ _| |_  | __|_ ___ __  ___ __| |_ __ _| |_(_)___ _ _  ___
| (_ | '_/ -_) _ |  _| | _|\ \ / '_ \/ -_) _|  _/ _ |  _| / _ \ ' \(_-<
\___|_| \___\__,_|\__| |___/_\_\ .__/\___\__|\__\__,_|\__|_\___/_||_/__/
                               |_|
            ~ Always know what to expect from your data ~
Let's create a new Data Context to hold your project configuration.
Great Expectations will create a new directory with the following structure:
   great_expectations
   |-- great_expectations.yml
   |-- expectations
   |-- checkpoints
   |-- plugins
   |-- .gitignore
   |-- uncommitted
       |-- config_variables.yml
       |-- data_docs
       |-- validations
OK to proceed? [Y/n]:

Pertimbangkan cuplikan kode di bawah. Cuplikan tersebut menjelaskan cara membuat definisi pemeriksaan data untuk kolom price:

"expectation_type": "expect_column_values_to_match_regex",
"kwargs": {
 "column": "price",
 "mostly": 1.0,
 "regex": "^\\$([0-9],)*[0-9]+\\.[0-9]{2}$"
},

Praktik Terbaik Data Contract

Tidak ada jawaban benar atau salah di sini karena, dari pengalaman saya, keberhasilan implementasi data contract sangat bergantung pada kebutuhan bisnis. Untuk membuat data contract bekerja secara efektif, ikuti praktik terbaik berikut:

• Skalabilitas: Saya merekomendasikan menambahkan mekanisme untuk ekstensibilitas (misalnya, on_schema_change: append) dan versi, yang memungkinkan modifikasi syarat data contract tanpa mengganggu integrasi pipeline yang sudah ada. Rancang data contract dengan mempertimbangkan perubahan di masa depan dan skalabilitas. Pendekatan ini memastikan kontrak dapat beradaptasi dengan kebutuhan yang berkembang dan pertumbuhan.
• Aturan yang jelas: Saya merekomendasikan penggunaan bahasa yang lugas dan ringkas dalam data contract untuk mencegah kesalahpahaman dan salah tafsir. Kontrak harus ditulis dan diberi nama dengan cara yang dapat diakses dan dipahami oleh semua pihak yang terlibat, terlepas dari tingkat keahlian teknis mereka.
• Kolaborasi: Upaya kolaboratif memastikan pemahaman kebutuhan yang komprehensif dan menyeluruh, mencakup berbagai perspektif dan kebutuhan. Saat membuat data contract, libatkan pemangku kepentingan yang beragam, termasuk produsen data, data engineer, data scientist, serta perwakilan dari departemen bisnis, TI, legal, dan kepatuhan.
• Metadata: Saya merekomendasikan menyediakan dokumentasi dan metadata yang menyeluruh dalam data contract. Dokumentasi komprehensif membantu penerapan dan pemeliharaan kontrak secara mulus. Ini harus mencakup deskripsi terperinci, definisi field, aturan validasi, dan informasi relevan lainnya yang mendukung pemahaman yang jelas serta implementasi kontrak yang efektif.
• Tinjauan berkala: Peninjauan berkelanjutan membantu menjaga relevansi dan efektivitas kontrak dari waktu ke waktu. Terapkan pendekatan terstruktur untuk pemantauan dan pembaruan data contract. Tinjauan berkala memastikan kontrak tetap mutakhir, selaras dengan kebutuhan bisnis yang berkembang, serta mematuhi peraturan baru atau yang berubah.

Kesimpulan

Baru-baru ini terjadi pergeseran menuju kepemilikan data terdistribusi, di mana tim domain bertanggung jawab atas produk data mereka. Perubahan ini memaksa organisasi untuk mendefinisikan ulang ekspektasi kualitas data yang diformalkan melalui data contract.

Validasi data semantik memastikan data konsisten secara logis dan selaras dengan logika bisnis. Validasi ini membantu memeriksa pipeline data dari outlier pada data, nilai, lineage, dan integritas referensial. Integritas referensial yang tidak memadai dapat menyebabkan data hilang atau tidak lengkap, sehingga hal ini juga penting. 

Kontrak tata kelola data juga dapat diimplementasikan dalam pipeline CI/CD dan menjadi sangat berguna ketika menunjukkan kolom dengan data sensitif, metadata (pemilik data, dan lain-lain), serta peran pengguna yang berwenang mengakses produk data. 

Metadata model, beserta metafield wajib lainnya yang ditentukan oleh pengembang, membantu memantau penggunaan sumber daya dan kinerja model. 

Service Level Agreement (SLA) dalam data contract menguraikan komitmen spesifik terkait kebaruan data, kelengkapan, dan pemulihan kegagalan.

Data contract sangat penting bagi teknik pemodelan data modern dan membantu memastikan platform data tahan terhadap kesalahan dan dapat diskalakan dengan baik. Menyelesaikan masalah kualitas data bisa jadi mahal. Untuk perusahaan tingkat enterprise, memaksimalkan return on investment (ROI) dari data menjadi semakin penting dengan memanfaatkan alat kualitas data yang ada yang mendukung validasi data contract.