Panduan Komprehensif tentang Uji dbt untuk Menjaga Kualitas Data

dbt semakin populer di bidang analitik berkat fungsi transformasi data dan pengujiannya. Dalam artikel ini, kami akan membahas apa itu dbt dan bagaimana Anda dapat menjalankan beberapa uji dbt untuk memastikan kualitas data. Jika Anda baru memulai dengan dbt, pastikan untuk melihat kursus Introduction to dbt kami untuk mempelajari lebih lanjut. 

Apa itu dbt?

Seperti yang kami bahas dalam panduan terpisah, dbt (data build tool) adalah alat open-source populer yang digunakan tim data untuk mentransformasikan data mentah di gudang data mereka menjadi set data yang bersih, teruji, terdokumentasi, dan siap analitik. 

Berbeda dengan alat ETL, dbt hanya berfokus pada komponen "T" (Transform) dalam pipeline data dan berjalan di atas gudang data cloud modern seperti BigQuery, Snowflake, Redshift, dan Databricks.

Salah satu fitur paling kuat dari dbt adalah kerangka kerja pengujian data bawaan, yang memungkinkan praktisi data menulis uji untuk memvalidasi asumsi tentang data mereka. Kerangka pengujian ini tidak hanya membantu menangkap masalah lebih awal tetapi juga krusial untuk menjaga kualitas dan kepercayaan data dalam basis kode analitik yang modular dan terus bertumbuh.

Mengapa Menguji di dbt?

Pengujian adalah bagian mendasar dari rekayasa analitik. Seiring pertumbuhan dataset dan semakin banyak pemangku kepentingan yang bergantung pada data, biaya dari isu data yang tidak terdeteksi akan meningkat. Kapabilitas pengujian dbt membantu Anda:

• Mendeteksi masalah data lebih awal: Sebelum dasbor dan laporan hilir terdampak.
• Mengotomatiskan pemeriksaan kualitas: Menghindari pekerjaan validasi manual.
• Mendorong praktik pemodelan data yang baik: Memajukan transformasi yang modular dan dapat diuji.
• Mendukung praktik CI/CD: Terintegrasi mulus ke alur kerja otomatis.
• Menegakkan kontrak data: Memvalidasi bahwa kendala kunci (misalnya, tanpa duplikat) tetap terpenuhi dari waktu ke waktu.

Jenis-Jenis Uji dbt

Di dbt, uji adalah asersi berbasis SQL yang memvalidasi asumsi data. Uji di dbt terbagi menjadi dua kategori utama:

1. Uji generik (bawaan)

Uji ini telah ditentukan oleh dbt dan diterapkan secara deklaratif dalam berkas YAML. Uji generik mencakup kendala umum yang biasanya ada dalam pemodelan data dan pergudangan data. 

Ciri-cirinya:

• Mudah dikonfigurasi
• Dapat digunakan ulang lintas kolom dan model
• Sangat efisien untuk pemeriksaan sederhana

Empat jenis uji generik bawaan meliputi:

• not_null: Memastikan sebuah kolom tidak berisi nilai NULL.
• unique: Memastikan nilai sebuah kolom berbeda antar baris (umumnya untuk kunci utama).
• accepted_values: Membatasi sebuah kolom pada himpunan nilai yang diizinkan sebelumnya.
• relationships: Memvalidasi integritas referensial antar tabel, memastikan kunci asing cocok dengan nilai di tabel lain.

Uji-uji ini ideal untuk menegakkan integritas data dasar, khususnya terkait kunci, field kategorikal, dan relasi inti tabel.

Uji generik bekerja dengan secara otomatis menghasilkan SQL di balik layar. 

Sebagai contoh, uji not_null pada kolom customer_id akan menghasilkan SQL serupa:

SELECT *
FROM {{ ref('customers') }}
WHERE customer_id IS NULL

Jika kueri ini mengembalikan baris apa pun, uji dinyatakan gagal.

2. Uji kustom (tunggal)

Uji kustom atau tunggal adalah kueri SQL yang ditentukan pengguna dan disimpan sebagai berkas .sql di direktori tests/. Ini digunakan untuk:

• Validasi kompleks yang tidak dapat diekspresikan oleh uji generik
• Penegakan aturan bisnis
• Logika lintas model
• Ambang statistik atau kondisional

Uji tunggal menawarkan fleksibilitas maksimum. Anda dapat memvalidasi data dengan hampir cara apa pun, selama kueri SQL Anda hanya mengembalikan baris yang melanggar ekspektasi.

Sebagai contoh:

• Memastikan tanggal peluncuran suatu produk tidak setelah tanggal pensiunnya
• Mendeteksi nilai yang sangat tinggi atau rendah (deteksi outlier)
• Memvalidasi bahwa nilai teragregasi selaras dengan total bisnis

Berkat fleksibilitasnya, uji kustom ideal bagi tim analitik yang ingin menegakkan kontrak kualitas data yang bernuansa di lingkungan produksi.

Makro yang disertakan dalam dbt juga dapat digunakan untuk pengujian, seperti paket dbt-utils.

Singkatnya:

Mengombinasikan keduanya memberi Anda yang terbaik dari dua dunia: konsistensi dan cakupan dari uji generik, serta ketepatan dari uji kustom. Mari kita telusuri masing-masing jenis lebih lanjut. 

1. Uji Generik (Bawaan)

Uji generik telah ditentukan oleh dbt dan digunakan secara deklaratif dengan menambahkannya ke berkas schema.yml model Anda. 

Uji ini biasanya memvalidasi kendala seperti keunikan, non-null, integritas referensial, atau nilai dalam himpunan yang ditentukan.

Mari kita telusuri tutorial sederhana untuk mencoba uji generik di dbt.

Cara mendeklarasikan uji generik

Di berkas schema.yml yang sesuai dengan model Anda, definisikan uji di bawah bagian columns::

version: 2

models:
  - name: customers
    description: "Customer dimension table"
    columns:
      - name: customer_id
        description: "Unique customer identifier"
        tests:
          - not_null
          - unique
      - name: email
        tests:
          - not_null

Contoh: not_null dan unique

yaml
columns:
  - name: customer_id
    tests:
      - not_null
      - unique

Uji di atas memastikan bahwa customer_id selalu ada di setiap baris dan bersifat unik. Ini biasa digunakan untuk menegakkan asumsi bahwa customer_id adalah kunci utama tabel.

Contoh: accepted_values

columns:
  - name: customer_type
    tests:
      - accepted_values:
          values: ['new', 'returning', 'vip']

Ini memeriksa bahwa field customer_type hanya berisi salah satu dari tiga string yang diizinkan: new, returning, atau vip. Uji ini sering digunakan untuk field kategorikal yang harus mematuhi himpunan nilai yang diketahui, seperti enum atau status.

Contoh: relationships

columns:
  - name: customer_id
    tests:
      - relationships:
          to: ref('customers')
          field: id

Ini menegakkan kendala integritas referensial dengan memverifikasi bahwa setiap customer_id dalam model saat ini ada sebagai id di tabel customers. Ini meniru kendala kunci asing di SQL, tetapi pada lapisan analitik.

2. Uji Kustom (Tunggal)

Ketika uji bawaan tidak memadai untuk kasus Anda, misalnya Anda ingin memvalidasi logika bisnis yang kompleks, Anda dapat menulis uji kustom menggunakan SQL. Ini dikenal sebagai uji tunggal.

Cara membuat uji kustom

1. Buat berkas .sql di dalam direktori tests/ pada proyek dbt Anda.

2. Tulis kueri SQL yang mengembalikan baris yang gagal dalam uji.

Contoh: Tidak ada tanggal masa depan di orders

Di folder tests, buat berkas bernama no_future_dates.sql.

SELECT *
FROM {{ ref('orders') }}
WHERE order_date > current_date

Uji ini memeriksa apakah ada catatan di tabel orders yang memiliki order_date di masa depan. Jika ada baris yang dikembalikan, uji gagal, memberi tahu Anda data tidak valid yang mungkin disebabkan oleh kesalahan zona waktu, bug ETL, atau entri sistem sumber yang salah.

Contoh: Duplikasi email per wilayah

-- Berkas: tests/duplicate_emails_per_region.sql

SELECT email, region, COUNT(*) as occurrences
FROM {{ ref('customers') }}
GROUP BY email, region
HAVING COUNT(*) > 1

Uji ini memastikan setiap email unik dalam suatu wilayah. Ini dapat mencerminkan aturan bisnis bahwa orang yang sama tidak dapat mendaftar dua kali di wilayah yang sama. Baris apa pun yang dikembalikan menunjukkan pelanggaran kualitas data.

Cara Menerapkan Uji di dbt

Bagian ini menjabarkan langkah-langkah praktis untuk menerapkan, mengonfigurasi, dan menjalankan uji dbt dalam proyek serta pipeline penempatan Anda.

Langkah 1: Menyiapkan dbt

Sebelum mulai menulis uji atau model, Anda perlu memasang dbt dan menginisialisasi proyek baru.

Instruksi langkah demi langkah:

1. Buat folder proyek:

Buat folder di lokasi pilihan Anda.

2. Masuk ke folder proyek:

cd dbt-test-project

3. Buat lingkungan virtual Python:

python3 -m venv dbt-env

Selanjutnya, aktifkan lingkungan tersebut setelah dibuat.

dbt-venv\Scripts\activate

4. Pasang dbt

pip dbt install

5. Buat folder .dbt

mkdir $home\.dbt

6. Inisialisasi dbt

dbt init

7. Buat berkas profiles.yml

Buat berkas baru di folder .dbt Anda dengan konten berikut:

austi:
  target: dev
  outputs:
    dev:
      type: sqlite
      threads: 1
      database: ./dbt_project.db
      schema: main
      schema_directory: ./schemas
      schemas_and_paths:
        main: ./dbt_project.db

Anda dapat mengganti “austi” dengan nama profil pengguna di komputer Windows Anda.

8. Buat berkas dbt_project.yml

Selanjutnya, Anda perlu membuat berkas konfigurasi lain di folder .dbt dengan konten berikut.

name: dbt_test_project
version: '1.0'
profile: austi

seeds:
  dbt_test_project:
    +quote_columns: false

Sekali lagi, ganti “austi” dengan nama profil pengguna Anda.

9. Verifikasi proyek berfungsi:

dbt debug

Setelah penyiapan selesai, Anda siap mulai membuat dataset dan membangun model dbt.

Langkah 2: Membuat dataset

Jika Anda bekerja tanpa akses ke gudang data, Anda dapat mensimulasikan uji dbt secara lokal menggunakan berkas CSV dan fungsionalitas seed dbt.

Instruksi langkah demi langkah:

1. Buat berkas CSV: Letakkan berkas ini di dalam folder /seeds baru pada proyek dbt Anda.

Berikut penamaan yang sebaiknya digunakan:

seeds/customers.csv

customer_id,name,email,customer_type
1,Alice Smith,alice@example.com,new
2,Bob Jones,bob@example.com,returning
3,Carol Lee,carol@example.com,vip
4,David Wu,david@example.com,new

2. Buat berkas lain di direktori yang sama:

Gunakan konvensi penamaan ini:

seeds/orders.csv

order_id,customer_id,order_date,order_total,order_status
1001,1,2023-12-01,150.00,shipped
1002,2,2023-12-03,200.00,delivered
1003,1,2023-12-05,175.00,cancelled
1004,3,2024-01-01,225.00,pending

3. Buat berkas konfigurasi untuk mengidentifikasi seed:

Selanjutnya, Anda perlu membuat berkas konfigurasi bernama dbt_project.yml.

Tempel konten berikut ke dalam berkas konfigurasi. 

name: dbt_test_project
version: '1.0'
profile: austi

seeds:
  dbt_test_project:
    +quote_columns: false

Ubah field profile agar sesuai dengan nama profil pengguna di komputer Windows Anda.

4. Muat data seed:

dbt seed

Perintah ini membuat tabel main.customers dan main.orders dari berkas CSV. Inilah seed yang diperlukan untuk menggantikan basis data.

Seperti terlihat pada gambar di atas, dua seed telah ditemukan dan dimuat.

Langkah 3: Mengimpor ke dbt

Sekarang, kita akan membuat model staging untuk mentransformasikan dan menguji data mentah Anda.

Instruksi langkah demi langkah:

1. Buat model staging:

Buat folder baru bernama models di folder proyek Anda. Di folder tersebut, buat berkas bernama stg_customers.sql.

Tempelkan kode berikut ke dalam berkas:

SELECT
  *
FROM {{ ref('customers') }}

Di berkas lain bernama stg_orders.sql, tempelkan kode berikut:

SELECT
  *
FROM {{ ref('orders') }}

2. Definisikan uji skema:

Buat berkas baru di lokasi berikut:

models/schema.yml

Tempel yang berikut ini ke dalam berkas

version: 2

models:
  - name: stg_customers
    description: "Customer staging table"
    columns:
      - name: customer_id
        description: "Unique identifier for each customer"
        tests:
          - not_null:
              tags: [critical]
          - unique:
              tags: [critical]

      - name: email
        description: "Email address of the customer"
        tests:
          - not_null

  - name: stg_orders
    description: "Orders staging table"
    columns:
      - name: order_id
        description: "Unique identifier for each order"
        tests:
          - not_null:
              tags: [critical]
          - unique:
              tags: [critical]

      - name: customer_id
        description: "Foreign key to stg_customers"
        tests:
          - not_null:
              tags: [critical]

3. Jalankan dbt untuk membangun model staging:

dbt run --select stg_customers stg_orders

Model staging ini sekarang menjadi fondasi untuk menerapkan uji dbt menggunakan data hasil seed lokal Anda.

Contoh keluaran yang mungkin:

Langkah 4: Membuat uji pertama Anda

Sekarang data Anda sudah di-staging, mari terapkan uji dbt pertama menggunakan kerangka uji bawaan yang generik.

Instruksi langkah demi langkah:

1. Buka berkas schema.yml tempat model staging Anda didefinisikan.

2. Di bawah bagian columns: pada model Anda, definisikan uji seperti not_null atau unique.

Contoh:

models:

  - name: stg_customers

    columns:

      - name: customer_id

        tests:

          - not_null

          - unique

3. Jalankan uji menggunakan CLI:

dbt test --select stg_customers

Berikut hasil yang diharapkan:

Langkah 5: Mengembangkan uji kustom dan tunggal

Ketika kebutuhan Anda melampaui uji bawaan, Anda dapat membuat uji kustom menggunakan SQL.

Instruksi langkah demi langkah:

1. Buat berkas baru di folder tests/, misalnya: tests/no_future_orders.sql

2. Tambahkan logika SQL yang mengembalikan baris yang gagal:

SELECT *
FROM {{ ref('stg_orders') }}
WHERE order_date > current_date

3. Jalankan uji:

dbt test --select no_future_orders

Uji ini akan gagal jika ada pesanan yang memiliki nilai order_date di masa depan.

Berikut hasil yang diharapkan:

Langkah 6: Menjalankan uji di pipeline CI/CD

Untuk memastikan eksekusi uji yang konsisten, integrasikan uji dbt ke dalam pipeline pengembangan Anda.

Instruksi langkah demi langkah:

1. Gunakan tag untuk memprioritaskan atau mengisolasi uji:

Anda dapat memodifikasi skema model apa pun untuk menyertakan tag berikut dalam format ini:

columns:
  - name: customer_id
    tests:
      - not_null:
          tags: [critical]

2. Jalankan uji selektif secara lokal:

dbt test --select tag:critical

Jika uji berjalan dengan benar, Anda dapat mengharapkan keluaran ini:

3. Konfigurasikan alur kerja CI Anda untuk menjalankan uji dbt secara otomatis. Anda dapat menghubungkannya ke platform CI seperti GitHub Actions. 

Praktik Terbaik untuk Uji dbt

Menerapkan uji dbt secara efektif bukan hanya tentang menulisnya; ini tentang mengintegrasikan pengujian ke dalam siklus pengembangan dan budaya tim Anda. Berikut beberapa praktik terbaik sebagai panduan:

1. Mulai dengan kunci utama

Selalu terapkan uji not_null dan unique pada kolom kunci utama di tabel dimensi dan fakta. Kedua kendala ini adalah fondasi join yang andal dan logika deduplikasi pada kueri hilir.

2. Validasi kunci asing dengan relationships

Kunci asing krusial untuk menjaga integritas referensial. Gunakan uji relationships untuk meniru kendala kunci asing, terutama di gudang data yang tidak menegakkannya secara native.

3. Gunakan accepted_values untuk kolom kategorikal

Kendalikan konsistensi dimensi dengan menegakkan nilai spesifik pada kolom seperti status, region, atau product_type. Ini mengurangi risiko salah ketik atau perluasan enum yang tidak tertangani.

4. Tulis uji kustom untuk logika bisnis

Logika bisnis tidak selalu selaras dengan aturan generik. Contoh logika yang sebaiknya Anda tulis uji kustomnya meliputi:

• Penjualan harus bernilai non-negatif
• Tanggal pesanan tidak boleh di masa depan
• Seorang pengguna tidak boleh memiliki beberapa langganan aktif

5. Susun uji dengan jelas

Jika Anda memiliki banyak uji, semuanya bisa cepat menjadi berantakan. Pertimbangkan praktik terbaik berikut agar tetap tertata:

• Tempatkan uji kustom di folder tests/ dan berikan nama yang deskriptif.
• Hindari SQL yang terlalu kompleks dalam uji—jaga logika tetap fokus dan mudah dibaca.
• Kelompokkan uji berdasarkan model atau domain jika memungkinkan.

6. Gagal secepatnya dan integrasikan dengan CI/CD

Jalankan dbt test sebagai bagian dari pipeline CI Anda. Ini memastikan kode tidak dapat digabungkan kecuali kendala kualitas data lulus. Mengintegrasikan uji ke CI/CD memperkuat akuntabilitas dan kepercayaan pada pipeline data.

7. Hindari pengujian berlebihan

Pengujian yang berlebihan atau tidak perlu (terutama pada volume data besar) dapat memperlambat penempatan. Fokus pada uji yang:

• Kritis bagi bisnis
• Berpotensi gagal karena isu hulu
• Membantu proses debug saat terjadi kegagalan

Hindari menguji field terhitung kecuali jika merupakan bagian dari SLA kontraktual.

Contoh Lanjutan: Deteksi Outlier

Untuk contoh uji lanjutan, kita dapat melakukan uji deteksi outlier.

Buat berkas SQL di folder tests Anda dengan kode berikut:

SELECT *
FROM {{ ref('orders') }}
WHERE order_total > 100000

Ini adalah uji deteksi outlier dasar. Jika bisnis Anda umumnya melihat pesanan di bawah $10.000, Anda dapat menandai pesanan di atas $100.000 untuk ditinjau secara manual. Meskipun bukan pelanggaran kualitas data yang ketat, ini dapat berguna untuk deteksi penipuan atau pemantauan operasional.

Pertimbangan Kinerja

Seiring skala proyek dbt Anda dan pertumbuhan cakupan uji, kinerja menjadi semakin penting. Bagian ini menguraikan teknik dan strategi untuk menjaga efisiensi uji dan mengendalikan biaya komputasi.

Teknik optimasi uji

Untuk pengujian, coba teknik berikut untuk mengoptimalkan kinerja:

• Pengujian inkremental: Fokuskan uji hanya pada data yang baru ditambahkan atau diubah dengan menggunakan struktur model inkremental dbt. Ini mengurangi pemindaian yang tidak perlu atas keseluruhan dataset.
• Paralelisasi kueri: Gunakan eksekusi paralel bawaan dbt dengan mengonfigurasi parameter threads: di dbt_project.yml untuk menjalankan banyak uji secara bersamaan.
• Eksekusi uji selektif: Gunakan flag seperti --select dan --exclude untuk menjalankan hanya uji yang relevan, terutama selama pengembangan. Contoh:

dbt test --select customers
dbt test --exclude tag:slow

Strategi pengelolaan biaya

Menerapkan strategi pengelolaan biaya memastikan uji dbt tetap berkinerja baik dan efisien biaya, terutama di lingkungan di mana penagihan komputasi terkait dengan kompleksitas dan frekuensi kueri.

Beberapa strategi antara lain:

• Eksekusi uji berbasis tag: Tetapkan tag pada uji yang intensif sumber daya atau opsional sehingga dapat dikecualikan dari run standar kecuali diperlukan secara eksplisit.
• Caching hasil: Manfaatkan fitur spesifik gudang (misalnya, caching hasil di BigQuery atau Snowflake) untuk menghindari komputasi berulang jika memungkinkan. Susun uji untuk memanfaatkan hasil cache dari kueri yang dieksekusi sebelumnya.
• Pengelompokan uji terjadwal: Jadwalkan suite uji yang lebih berat pada jam non-puncak atau di luar jendela produksi untuk meminimalkan dampak pada beban kerja gudang data.

Kesimpulan

Uji dbt adalah cara ampuh untuk memastikan kualitas data yang tinggi, mengotomatiskan pemeriksaan validasi, dan menangkap masalah lebih awal di pipeline transformasi Anda. Uji generik dan kustom dapat digunakan untuk membangun alur kerja data yang tangguh dan mudah dirawat.

Pelajari lebih lanjut tentang dbt di kursus Introduction to dbt kami atau tutorial dbt kami.