Belajar Data Architect - Data Lineage & Audit

#Pendahuluan

Setelah di episode 19 kita menyiapkan compliance mapping, sekarang kita membahas teknologi yang menjadi tulang punggungnya: data lineage dan audit. Jika governance (episode 8) adalah kerangka organisasi, lineage adalah peta jejak data — dan audit trail adalah rekaman siapa melakukan apa.

Mengapa episode ini penting? Karena hampir semua masalah serius di tim data berujung pada dua pertanyaan yang sama: "angka ini dari mana?" dan "siapa yang mengubah ini?". Lineage menjawab yang pertama, audit trail menjawab yang kedua. Tanpa keduanya, tim data hanya bisa menebak — dan menebak di data produksi itu mahal.

#Lineage End-to-End

Lineage adalah peta lengkap perjalanan data: dari sumber asli, melewati setiap transformasi, sampai ke konsumen akhir (dashboard, model, API).

100%

Tingkat ketelitian lineage:

Level	Skala	Kegunaan
Table-level	Tabel → tabel	Gambaran alur kasar
Column-level	Kolom → kolom	Impact analysis presisi
Row-level	Filter & transformasi	Debugging detail (mahal)

Untuk arsitek, column-level lineage adalah sweet spot: cukup presisi untuk impact analysis, cukup murah untuk dijalankan otomatis.

#Impact Analysis

Kegunaan utama lineage #1: impact analysis — sebelum mengubah apa pun, tahu siapa yang terdampak.

Pertanyaan impact analysis

"Kalau saya ganti tipe kolom revenue di silver.orders, siapa yang rusak?"
→ jawab: gold.fact_orders (via join), dashboard revenue, ML feature,
  dan 3 pipeline downstream

Flow kerja yang benar:

Flow impact analysis

1. pilih kolom/tabel yang akan diubah
2. lineage menampilkan semua downstream
3. hitung blast radius: berapa dashboard, model, API
4. beri notifikasi ke pemilik downstream sebelum perubahan
5. jalankan perubahan dengan grace period + validasi

Ini menyelesaikan masalah klasik "pipeline berubah diam-diam, dashboard semua salah": perubahan ditelusuri dan dikomunikasikan lebih dulu.

#Root Cause Analysis

Kegunaan utama lineage #2: root cause — saat angka salah, menelusuri dari mana kesalahan berasal.

Alur debugging dengan lineage

dashboard revenue salah
  → lineage naik: gold.fact_orders
  → lineage naik: silver.orders_vault
  → lineage naik: bronze.orders
  → ditemukan: kolom qty di bronze berubah tipe karena CDC baru

Tanpa lineage, debugging seperti mencari jarum di tumpukan pipeline. Dengan lineage, jalur bisa dilacak langkah demi langkah dalam hitungan menit.

#Audit Trail

Audit trail adalah rekaman siapa mengakses/mengubah apa, kapan, dan dengan hasil apa. Dua jenis yang harus dipisahkan:

Jenis	Merekam	Contoh
Data access log	Akses ke data	User X baca tabel Y jam 14:02, 200 baris
Data change log	Perubahan pada data/pipeline	Pipeline Z load 100k baris, versi model W

Persyaratan audit trail yang baik:

Immutability: log tidak bisa diubah oleh pelaku.
Completeness: akses yang berhasil dan gagal dicatat (kegagalan justru sinyal mencurigakan).
Retention: tersimpan sesuai aturan (misal 12 bulan, sesuai episode 19).
Searchable: bisa di-query per user, per dataset, per waktu.

Contoh struktur audit log (konsep)

id | user | action | resource     | context     | result | ts
1  | andi | SELECT | sales.orders | role=analyst | allow  | 14:02
2  | bot  | INSERT | bronze.orders| pipeline=daily | allow | 02:00
3  | adi  | SELECT | sales.orders | region=null  | deny   | 09:13

#Praktik: Menyiapkan Lineage

#Step 1: Mulai dari Tool yang Sudah Ada

Lineage sebaiknya dikumpulkan otomatis dari tool yang dipakai, bukan ditulis manual:

Sumber lineage otomatis

dbt      → manifest.json (model ke model, kolom ke kolom)
Airflow  → DAG dependencies (task ke task)
Platform → query history / audit log (BI query lineage)
CDC      → source connector lineage

#Step 2: Kumpulkan di Satu Tempat

Agar menjadi satu peta utuh, kumpulkan di OpenLineage (standar terbuka) atau platform catalog yang mendukungnya (OpenMetadata/DataHub). Satu tempat = satu kebenaran.

#Step 3: Tetapkan Standar

Aturan lineage yang dipaksakan

- setiap tabel punya lineage yang jelas dari sumbernya
- dbt manifest wajib di-publish ke catalog tiap rilis
- model tanpa lineage → ditandai "untrusted" di katalog
- konsumen dashboard hanya boleh pakai data ber-lineage

#Step 4: Gunakan di Proses Nyata

Lineage tidak berguna kalau tidak dipakai: jadikan impact analysis langkah wajib sebelum perubahan model (episode 24 ADR), dan gunakan untuk root cause saat insiden kualitas.

Note

Lineage manual (tulis tangan di spreadsheet) selalu usang dan tidak dipercaya. Harga lineage otomatis adalah disiplin: setiap transformasi harus lewat tool yang mencatat lineage (dbt, Spark, orchestrator). Arsitek menetapkan aturan ini, bukan melukis peta manual.

Tip

Mulai dengan critical data elements (episode 8): pastikan lineage lengkap untuk data yang paling berpengaruh, bukan semua dataset. Sepuluh jalur data kritis dengan lineage yang benar lebih berharga daripada seratus tabel dengan lineage parsial.

#Penutup

Inti yang harus dibawa pulang:

Lineage end-to-end memetakan data dari sumber sampai konsumen.
Impact analysis (sebelum perubahan) dan root cause (saat insiden) adalah dua kegunaan utama.
Audit trail = data access log + data change log yang immutable, lengkap, dan bisa di-query.
Lineage dikumpulkan otomatis dari dbt/Airflow/platform, dikumpulkan di satu katalog.
Terapkan pada data kritis dulu, dan jadikan impact analysis wajib sebelum perubahan.

Di episode 21 selanjutnya kita akan membahas AI-Ready Data Architecture — feature store, vector database, dan data untuk LLM/RAG sebagai arah baru arsitektur data. Sampai jumpa di episode 21!