Data Lineage: Melacak Angka Dashboard Sampai ke Tabel Sumbernya

Data lineage adalah catatan jalur sebuah angka, mulai dari tabel mentah tempat dia lahir, lewat semua transformasi, sampai nongol di kotak dashboard yang dilihat manajer.

Gunanya satu: waktu ada yang nanya "angka omzet ini dari mana", kamu bisa jawab dalam lima menit sambil nunjuk tabelnya. Bukan janji "nanti aku cek dulu ya" yang berakhir jadi setengah hari kerja.

Di bawah ini aku bahas apa isinya, levelnya apa aja, cara mulai pakai SQL biasa tanpa beli tool, plus kesalahan yang paling sering bikin angka meleset.

Apa itu data lineage?

Data lineage adalah peta hubungan antar objek data yang nunjukin dari mana sebuah kolom atau tabel berasal dan ke mana dia mengalir. Isinya minimal tiga hal: sumbernya apa, transformasinya apa, dan hasil akhirnya dipakai di mana. Dengan lineage, kamu bisa telusuri satu angka dashboard mundur sampai ke baris transaksi aslinya.

Contoh paling sederhana. Angka Omzet Bersih Bulan Ini di dashboard ternyata berasal dari view v_omzet_harian. View itu ambil dari tabel stg_transaksi. Tabel staging itu sendiri hasil bersih-bersih dari transaksi_mentah.

Tiga lompatan. Kalau ada satu yang berubah diam-diam, angkanya ikut geser.

Konsep ini nempel erat sama ETL, proses mindahin dan ngerapihin data antar tempat. Lineage itu dokumentasi hasil dari proses itu.

Kenapa analis butuh data lineage?

Alasan utamanya kecepatan waktu ada yang salah. Tanpa lineage, ngelacak satu angka nyasar berarti buka satu per satu query, view, dan job sampai ketemu titik belokannya. Dengan lineage, kamu langsung lihat rantainya dan cek dari yang paling mencurigakan.

Ada tiga situasi yang paling sering aku temuin:

1. Angka dua dashboard beda. Lineage nunjukin ternyata satu narik dari view lama, satunya dari view baru.
2. Mau hapus tabel tapi takut. Lineage jawab siapa aja yang masih pakai tabel itu sebelum kamu DROP.
3. Kolom sumber berubah tipe. Lineage bilang berapa dashboard yang bakal ikut rusak sore ini.

Poin ketiga itu yang paling mahal. Perubahan kecil di hulu bisa numpuk jadi angka salah di hilir tanpa ada yang sadar sampai laporan bulanan dicetak.

Apa saja level data lineage?

Ada dua level yang perlu kamu bedakan, dan keduanya kepakai di situasi berbeda.

Level	Yang dicatat	Cocok buat	Ongkos bikinnya
Table-level	Tabel A dipakai bikin tabel B	Cek dampak sebelum hapus atau ubah tabel	Murah, bisa otomatis
Column-level	Kolom transaksi.total jadi bahan kolom omzet_bersih	Debug angka yang meleset	Lebih mahal, sering perlu catatan manual

Saran praktisku: mulai dari table-level buat semua, terus naikin ke column-level cuma buat metrik yang sering ditanya. Sepuluh metrik biasanya udah cukup buat tim yang isinya lima orang.

Gimana cara bikin data lineage tanpa tool mahal?

Kamu bisa mulai hari ini pakai isi database sendiri. PostgreSQL nyimpen relasi antara view dan tabel sumbernya di information_schema, jadi sebagian peta itu udah ada tanpa kamu tulis apa-apa.

Empat langkah yang aku pakai:

1. Tarik peta view ke tabel

SELECT
    view_schema,
    view_name,
    table_schema AS sumber_schema,
    table_name   AS sumber_tabel
FROM information_schema.view_table_usage
WHERE view_schema = 'analitik'
ORDER BY view_name, table_name;

Hasilnya satu baris per pasangan view dan tabel sumber. Kalau v_omzet_harian narik dari dua tabel, dia muncul dua baris.

2. Turunkan ke level kolom

SELECT
    view_name,
    table_name AS sumber_tabel,
    column_name AS sumber_kolom
FROM information_schema.view_column_usage
WHERE view_schema = 'analitik'
  AND view_name = 'v_omzet_harian';

View ini ngasih tau kolom mana aja yang kesentuh view tersebut. Detail rumusnya belum kelihatan, tapi lingkup pencarianmu udah menyempit drastis. Penjelasan resminya ada di dokumentasi PostgreSQL.

3. Catat jalur yang nggak kebaca database

Script Python, job Airflow, dan copy manual ke spreadsheet nggak kecatat di information_schema. Bikin satu tabel kecil buat itu.

CREATE TABLE lineage_manual (
    id            SERIAL PRIMARY KEY,
    sumber        TEXT NOT NULL,
    tujuan        TEXT NOT NULL,
    cara          TEXT NOT NULL,   -- 'python', 'airflow', 'manual'
    pemilik       TEXT NOT NULL,
    terakhir_cek  DATE NOT NULL
);

INSERT INTO lineage_manual (sumber, tujuan, cara, pemilik, terakhir_cek)
VALUES
  ('transaksi_mentah', 'stg_transaksi', 'airflow', 'tim data', '2025-11-01'),
  ('stg_transaksi', 'v_omzet_harian', 'view sql', 'bima', '2025-11-01');

4. Gabungkan jadi satu tampilan

Satu view gabungan bikin kamu punya satu tempat buat nyari, bukan dua.

CREATE VIEW v_lineage AS
SELECT table_name AS sumber, view_name AS tujuan, 'view sql' AS cara
FROM information_schema.view_table_usage
WHERE view_schema = 'analitik'
UNION ALL
SELECT sumber, tujuan, cara
FROM lineage_manual;

Mau tau siapa aja yang kena kalau stg_transaksi diubah? Query v_lineage pakai filter sumber = 'stg_transaksi'. Kalau kamu belum akrab sama view, ada penjelasan lengkapnya di artikel VIEW di SQL.

Contoh kasus: angka omzet toko_berkah yang meleset Rp 4.180.000

Ini dari dataset latihan toko_berkah yang aku pakai di kelas. Ceritanya dashboard nunjukin omzet Oktober Rp 61.340.000, sementara rekap kasir bilang Rp 57.160.000. Selisihnya Rp 4.180.000.

Lineage-nya kelihatan begini setelah ditarik dari v_lineage:

Lompatan	Dari	Ke	Yang terjadi
1	transaksi_mentah	stg_transaksi	buang baris tes, rapihin tanggal
2	stg_transaksi	v_omzet_harian	jumlahin total per tanggal
3	v_omzet_harian	dashboard	filter bulan berjalan

Ketemunya di lompatan 2. View v_omzet_harian nggak pasang filter status <> 'batal', jadi 37 transaksi batal ikut kejumlah. Nilainya pas Rp 4.180.000.

Tanpa peta itu, nyari penyebabnya berarti baca ulang tiga query panjang. Dengan peta itu, cek pertama langsung kena. Kalau kamu mau latihan cari cacat semacam ini, artikel cek kualitas data pakai SQL ngasih query siap pakai.

Prinsipnya sama kayak yang dijaga di data quality: yang bikin angka salah jarang rumus rumit, lebih sering filter yang kelewat.

Kesalahan umum waktu bikin data lineage

• Mulai dari semua tabel sekaligus. Database dengan 400 tabel bikin kamu berhenti di hari kedua. Ambil lima metrik yang paling sering ditanya bos, petain itu dulu.
• Catatan manual tanpa tanggal cek. Lineage yang kamu tulis Maret dan nggak pernah diverifikasi lagi lebih bahaya dari nggak punya catatan, soalnya orang percaya sama isinya.
• Cuma nyatet tabel, nggak nyatet rumus. Tau omzet_bersih asalnya dari stg_transaksi nggak nolong kalau kamu nggak tau diskon udah dipotong di mana.
• Nganggep dashboard sebagai ujung. Banyak angka lanjut ke spreadsheet, terus ke slide rapat, terus dikutip di grup WhatsApp. Titik akhir lineage yang jujur itu tempat angkanya dipakai buat ambil keputusan.
• Nunggu beli tool dulu. Tool lineage otomatis enak, tapi tabel lineage_manual berisi 30 baris hari ini lebih berguna dari tool sempurna kuartal depan.

FAQ

Data lineage sama data catalog itu sama nggak?

Beda kerjaan. Data catalog itu daftar isi gudang datamu: tabel apa aja yang ada, siapa pemiliknya, kolomnya artinya apa. Data lineage itu jalurnya: tabel A dipakai buat bikin tabel B, terus B dipakai di dashboard C. Banyak tool ngasih keduanya sekaligus, tapi kalau kamu cuma punya waktu buat satu, lineage yang lebih cepat kepakai pas angka dashboard dipertanyakan.

Bisa nggak bikin data lineage tanpa tool berbayar?

Bisa. Di PostgreSQL, view information_schema.view_table_usage dan view_column_usage udah ngasih kamu peta view ke tabel sumbernya secara otomatis. Sisanya, yang lewat script Python atau job manual, kamu catat sendiri di satu tabel kecil berisi kolom sumber, tujuan, dan pemilik. Dua sumber ini digabung udah nutup sebagian besar kebutuhan tim kecil.

Kenapa kolom lineage lebih berguna dari tabel lineage?

Tabel lineage cuma bilang "dashboard ini narik dari 6 tabel". Kamu masih harus buka satu-satu buat tau omzet_bersih dihitungnya gimana. Kolom lineage langsung nunjuk: omzet_bersih berasal dari transaksi.total dikurangi transaksi.diskon, dan filter status batal dipasang di layer staging. Waktu debug angka meleset, level kolom yang bikin kamu berhenti nebak.

Seberapa sering lineage harus diperbarui?

Yang otomatis dari information_schema selalu ikut kondisi database saat kamu query, jadi nggak perlu diurus. Yang manual, catatannya gampang basi. Aku biasanya ngecek ulang tiap kali ada perubahan skema atau tiap akhir bulan, mana yang lebih dulu datang. Kalau tabel catatanmu udah lebih dari sebulan nggak disentuh, anggap isinya perlu diverifikasi dulu sebelum dipakai.

Apa tanda paling awal kalau lineage di timku berantakan?

Pertanyaan "angka ini dari mana ya" dijawab pakai kata "kayaknya". Tanda kedua, ada dua dashboard yang nyebut metrik sama tapi angkanya beda, dan nggak ada yang tau versi mana yang benar. Kalau dua hal ini muncul lebih dari sekali dalam sebulan, tulis lineage buat lima metrik paling sering ditanya. Itu udah ngurangin sebagian besar keributannya.

Penutup

Tiga hal yang perlu kamu bawa dari sini:

1. Data lineage jawab satu pertanyaan mahal: angka ini datangnya dari mana.
2. Kamu bisa mulai gratis, information_schema plus satu tabel catatan manual udah cukup.
3. Petain lima metrik yang paling sering ditanya dulu, bukan seluruh database.

Buka database kerjaanmu sekarang, jalanin query view_table_usage di atas, dan lihat berapa banyak view yang narik dari tabel yang kamu kira udah nggak dipakai. Biasanya ada satu dua yang bikin kaget.

Habis itu, baca data contract buat tau cara bikin kolom nggak berubah diam-diam, dan definisi metric supaya nama angkanya seragam di seluruh tim.