Transformasi Data yang Teruji dengan dbt

Ini artikel contoh untuk pembelajaran. Tanggal publikasi dan catatan transaksi bersifat ilustratif.

Transformasi bisa selesai tanpa error tetapi tetap menghasilkan transaksi ganda. Model dbt menjelaskan transformasi; data test memeriksa apakah hasilnya memenuhi kontrak. Contoh mengasumsikan proyek dbt, adapter, dan model stg_transactions sudah tersedia. Sintaks data_tests mengikuti dokumentasi dbt saat penulisan. Konfigurasi adapter berada di luar latihan.

Nyatakan dependensi model

Buat models/transactions.sql. Input sudah memiliki amount numerik dan satu baris per transaksi terkini:

select
    transaction_id,
    transaction_date,
    amount
from {{ ref('stg_transactions') }}
where transaction_id is not null
  and amount is not null

ref menentukan relasi model sumber sekaligus mencatat dependensi. Gunakan ref agar nama database dan schema mengikuti lingkungan. Membuang kolom wajib yang kosong hanya dapat dibenarkan jika baris penolakan dihitung dan diselidiki pada tahap sebelumnya.

Uji kunci yang dimaksud

Buat models/transactions.yml:

version: 2
models:
  - name: transactions
    columns:
      - name: transaction_id
        data_tests:
          - not_null
          - unique

Jalankan model dan pengujiannya melalui perintah dbt build pada proyek:

dbt build --select +transactions

Tanda plus di depan menyertakan dependensi hulu. Test unique melaporkan nilai kunci ganda, bukan menghapusnya. Test not_null memeriksa hasil model, bukan apakah sumber telah membuang banyak baris. Tambahkan hitungan penolakan hulu dan pernyataan khusus domain jika keduanya termasuk kontrak.

Tinjau perubahan inkremental secara terpisah

Materialisasi incremental membawa kontrak tambahan. Konfigurasi unique_key memberi tahu strategi adapter yang mendukungnya cara mencocokkan baris tujuan. Konfigurasi itu bukan constraint keunikan maupun deduplikasi sumber. Validasi kunci sumber sebelum merge.

Filter yang hanya membaca timestamp lebih besar dari nilai maksimum tujuan dapat melewatkan koreksi terlambat. Tentukan apakah perlu membaca ulang jendela waktu, memakai change log sumber, atau membangun ulang partisi terkait. Uji koreksi setelah kejadian awal serta pengulangan batch yang sama. Jumlah baris dan nilainya harus tetap sesuai hasil yang diharapkan.

Keunikan yang lolos tidak membuktikan ketepatan kurs, kelengkapan data, atau definisi bisnis yang tetap sama. Tulis asumsi di dekat model dan cocokkan hasil dengan fixture kecil yang dihitung manual sebelum menganggap build berhasil sebagai rilis.