Belajar Data Architect - Data Quality & Observability

#Pendahuluan

Setelah di episode 8 kita menetapkan governance — siapa pemilik data dan bagaimana data diatur — sekarang kita masuk ke lapisan yang paling sering dirasakan konsumen: kualitas data. Dashboard yang salah, angka yang berubah-ubah, dan data yang muncul di waktu tak menentu adalah penyebab terbesar hilangnya kepercayaan pada tim data.

Mengapa episode ini penting? Karena kepercayaan adalah mata uang tim data. Sekali konsumen menemukan angka yang salah, semua output kalian diragukan. Kualitas bukan sekadar "benar atau salah" — ia adalah sistem pengukuran dan peringatan dini yang membuat data buruk tertangkap sebelum sempat merusak keputusan.

#Dimensi Kualitas Data

Kualitas data tidak bisa dirangkum satu angka. Ada beberapa dimensi yang masing-masing diukur terpisah:

Dimensi	Pertanyaan	Contoh Check
Akurasi	Apakah nilai benar?	Validasi dengan sumber kebenaran
Kelengkapan	Adakah nilai hilang?	% kolom null per partisi
Konsistensi	Apakah konsisten antar sistem?	Definisi revenue sama di semua dashboard
Ketepatan waktu	Apakah datang tepat waktu?	Freshness: selisih load vs jadwal
Uniqueness	Adakah duplikat?	Duplikat business key
Validitas	Apakah sesuai aturan?	Format tanggal, enum status valid

#SLO Data dan SLA Data

Sama seperti SRE menetapkan SLO untuk layanan, tim data menetapkan SLO (Service Level Objective) untuk data — target kualitas yang bisa diukur.

Contoh SLO data

SLO-1 freshness:  data silver.sales 100% dimuat ≤ 30 menit setelah jadwal
SLO-2 completeness: row count partisi hari ini ≥ 95% dari median 30 hari
SLO-3 uniqueness: 0 duplikat pada business key fact_sales
SLO-4 validity:  ≥ 99.5% baris lolos validasi schema & enum

SLA (Service Level Agreement) adalah versi kontrak: kesepakatan tertulis dengan konsumen bahwa tim data menjamin SLO tertentu. Jika dilanggar, ada konsekuensi (kompensasi layanan, prioritas perbaikan). SLO adalah target internal; SLA adalah janji eksternal. Kita bahas SLA untuk data product lebih dalam di episode 13.

#Data Quality Testing di Pipeline

Kualitas harus dicek di dalam pipeline, bukan setelah konsumen mengeluh. Dua lapis utama:

#1. dbt Tests

dbt menyediakan testing bawaan yang berjalan di setiap pipeline:

dbt tests di schema.yml

version: 2
 
models:
  - name: fact_sales
    columns:
      - name: sale_id
        tests:
          - not_null
          - unique
      - name: revenue
        tests:
          - not_null
          - accepted_values: { values: ["created", "paid", "shipped", "done", "canceled"] }

Tambahkan test custom untuk threshold relatif — misal perubahan drastis row count:

Test row count vs median 30 hari

SELECT *
FROM fact_sales
WHERE row_count < (SELECT median(row_count) OVER () * 0.95)

#2. Data Quality Framework

Untuk kebutuhan lebih luas, gunakan framework khusus seperti Great Expectations atau Soda Core yang bisa dicek di berbagai sumber (bukan hanya dbt model). Prinsipnya sama: definisikan expectation, jalankan di schedule, alert saat gagal.

#Data Observability

Data observability adalah penerapan prinsip observability (logs, metrics, traces) pada sistem data: memantau kesehatan pipeline dan data secara proaktif, bukan menunggu keluhan.

Lima pilar observability data:

Lima pilar observability data

FRESHNESS   → apakah data datang tepat waktu? (lag dari schedule)
DISTRIBUTION→ apakah distribusi nilai wajar? (spike/drop anomali)
VOLUME      → apakah jumlah data normal? (row count drop)
SCHEMA      → apakah struktur berubah? (kolom baru/hilang)
LINEAGE     → apa dampak perubahan terhadap downstream?

Implementasi praktis:

Metrics yang di-publish tiap pipeline

- duration_pipeline_seconds
- rows_processed
- null_ratio per kolom kritis
- error_count per tahap
- lag_minutes (selisih selesai vs jadwal)

Semua metrics masuk ke monitoring (Prometheus/Grafana atau tool data observability seperti Monte Carlo, Bigeye, Elementary), dengan alert threshold:

Alert threshold observability

freshness > 30 menit              → warning
row_count < 95% median 30 hari    → critical (pipeline kemungkinan salah)
null_ratio sales.revenue > 1%     → warning (source bermasalah)
schema drift terdeteksi           → critical (butuh review arsitek)

Warning

Alert tanpa aksi adalah noise. Setiap alert harus punya runbook: siapa yang bertanggung jawab, langkah diagnosa pertama, dan SLA respons. Alert yang selalu mengganggu tapi tidak pernah ditindaklanjuti akan diabaikan — lalu data buruk lolos diam-diam.

#Praktik: Membangun Framework Kualitas

#Step 1: Pilih Data Kritis

Mulai dari critical data elements yang sudah diidentifikasi di episode 8 — bukan semua dataset.

#Step 2: Tetapkan SLO

Tulis SLO dalam bentuk terukur (seperti contoh di atas) dan masukkan ke contract dengan konsumen.

#Step 3: Implementasikan Checks di Pipeline

Alur check kualitas di tiap DAG

pipeline selesai
   → dbt test (not_null, unique, accepted_values)
   → custom test (row_count vs median, fresh check)
   → publish metrics ke monitoring
   → gagal? → alert + notifikasi ke steward domain

#Step 4: Triage dan Eskalasi

Buat SLA internal untuk perbaikan: kualitas kritis diperbaiki dalam 4 jam kerja, SLO dilanggar lebih dari 3 hari berturut → eskalasi ke arsitek.

Tip

Mulai dengan freshness dan volume check — dua dimensi termurah untuk diukur dan paling sering menyelamatkan tim. Anomali volume hampir selalu menandakan pipeline yang gagal diam-diam. Setelah stabil, tambah dimensi lain bertahap.

#Penutup

Inti yang harus dibawa pulang:

Kualitas = akurasi, kelengkapan, konsistensi, ketepatan waktu, uniqueness, validitas.
SLO adalah target terukur; SLA adalah janji kontraktual pada konsumen.
Checks berjalan di dalam pipeline (dbt test / framework kualitas), bukan menunggu keluhan.
Observability data: freshness, distribution, volume, schema, lineage.
Mulai dari data kritis, tetapkan SLO, dan jadikan alert punya runbook.

Di episode 10 selanjutnya kita akan membahas Security & Privacy Data — enkripsi, masking, RBAC, dan compliance seperti GDPR sebagai bagian dari desain arsitektur, bukan tempelan. Sampai jumpa di episode 10!