Belajar Data Analyst - Data Governance & Data Quality

#Pendahuluan

Di episode 17 kalian memproduksi data lewat dbt. Sekarang muncul pertanyaan yang jauh lebih strategis: bagaimana orang tahu data ini bisa dipercaya? Di perusahaan besar, analis menghabiskan waktu berjam-jam untuk hal yang tidak ada kaitannya dengan analisis: "angka ini benar tidak ya?", "definisi revenue yang mana?", "ini data siapa?".

Data governance dan data quality menjawab tiga pertanyaan itu: apakah data benar, apa artinya, dan dari mana asalnya? Episode ini membangun tiga pilar: data quality checks, data catalog & lineage, dan dokumentasi metrik — dengan pendekatan praktis yang tidak tenggelam dalam birokrasi.

#Dimensi Data Quality

Kualitas data bukan satu hal, melainkan banyak dimensi. Tujuh dimensi yang paling umum:

Analis tidak wajib mengotomasi semuanya sekaligus — tapi wajib tahu dimensi mana yang paling berisiko untuk dataset yang ditanganinya.

#Data Quality Tests di dbt

Kerangka schema.yml di dbt mengotomasi sebagian besar dimensi di atas:

version: 2
 
models:
  - name: stg_orders
    description: "Order mentah yang sudah dibersihkan"
    columns:
      - name: order_id
        description: "Primary key order"
        tests:
          - unique
          - not_null
      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('stg_customers')
              field: customer_id
      - name: status
        tests:
          - accepted_values:
              values: ['completed', 'pending', 'refunded', 'cancelled']
      - name: amount
        tests:
          - not_null

Empat test di atas sudah mengamankan empat dimensi: uniqueness, completeness, integrity (via relationships), dan validity (via accepted_values). Dijalankan otomatis di setiap dbt build.

dbt test

#Test Khusus dengan SQL: Beyond Generic Tests

Untuk validasi yang lebih spesifik — misal "tidak boleh ada revenue negatif" — dbt punya singular tests:

SELECT order_date, SUM(amount) AS revenue
FROM {{ ref('stg_orders') }}
WHERE status = 'completed'
GROUP BY order_date
HAVING revenue < 0

Jika query ini mengembalikan baris apa pun, dbt test gagal. Inilah cara menerjemahkan aturan bisnis menjadi guardrail otomatis.

#Data Catalog dan Lineage: Menemukan dan Memercayai Data

Data catalog menjawab "data apa saja yang ada?" — daftar tabel, kolom, pemilik, dan deskripsi. Lineage menjawab "dari mana data ini berasal?" — alur dari source ke model ke dashboard.

Cara paling sederhana memulai catalog: descriptions di schema.yml:

version: 2
 
models:
  - name: fct_orders_daily
    description: "Ringkasan order harian untuk dashboard revenue"
    columns:
      - name: revenue
        description: "Total amount order status completed, dalam IDR"

Kemudian dbt docs generate dan dbt docs serve — tim kalian sekarang punya catalog yang hidup, bukan dokumen Word yang basi.

#Dokumentasi Metrik: Satu Bahasa untuk Semua

Penyebab konflik lintas tim nomor satu di dunia data adalah definisi metrik yang berbeda. Dua orang melaporkan "revenue" dengan angka berbeda karena definisi yang berbeda. Solusinya: dokumentasi metrik yang tunggal.

metrics:
  - name: revenue
    label: "Revenue"
    description: >
      Total amount dari order berstatus completed,
      tidak termasuk refund, dalam IDR.
    filters:
      - status = 'completed'

Setiap metrik harus bisa menjawab: definisi, sumber data, filter, satuan, pemilik, dan periode update. Format ini bisa berupa dokumentasi di dbt, halaman wiki, atau metadata di BI tool — yang penting satu sumber kebenaran, bukan lima.

#Praktik: Setup Data Quality untuk Dataset Kalian

Alur praktis untuk project pribadi atau tim kecil:

1. Pilih tabel paling penting (misal stg_orders).
2. Tulis test minimal: unique + not_null pada key, accepted_values pada status.
3. Tambahkan satu singular test untuk aturan bisnis (misal revenue non-negatif).
4. Dokumentasikan kolom inti di schema.yml.
5. Jalankan dbt build dan jadikan bagian rutinitas.

Lima langkah ini memakan waktu satu jam tetapi menyelamatkan puluhan jam investigasi data rusak di kemudian hari.

#Kesalahan Umum

• Test tanpa dipantau. Test yang tidak dijalankan rutin = tidak ada.
• Mendokumentasikan hanya di memo. Definisi metrik di kepala analis adalah bom waktu.
• Governance sebagai birokrasi. Mulai dari data quality & definisi metrik; policy menyusul.
• Catalog yang basi. Catalog harus diperbarui otomatis (dbt docs) atau ia kehilangan kepercayaan.

#Penutup

Inti yang harus dibawa pulang:

• Tujuh dimensi quality: completeness, uniqueness, timeliness, validity, accuracy, consistency, integrity.
• dbt mengotomasi test: unique, not_null, relationships, accepted_values, plus singular tests.
• Catalog + lineage menjawab "apa, artinya apa, dari mana".
• Satu definisi metrik terdokumentasi menyelamatkan tim dari konflik lintas departemen.

Di episode 19 selanjutnya kita membahas sisi yang tidak boleh kalian abaikan: Data Privacy & Security — PII, regulasi seperti GDPR, role-based access, dan anonymization, lengkap dengan praktik menangani data sensitif dengan benar. Data kalian sekarang terpercaya; saatnya memastikan ia juga aman dan etis!