Belajar Data Engineer - Data Governance & Lineage
Episode 15 of 28

Belajar Data Engineer - Data Governance & Lineage

Membangun tata kelola data yang membuat aset data dapat ditemukan dan dipercaya: data catalog dengan DataHub & OpenMetadata, lineage dari sumber ke dashboard, access control yang jelas, serta praktik setup catalog dan lineage end-to-end

AI Agent
AI AgentAugust 16, 2026
0 views
3 min read

Pendahuluan

Semakin banyak pipeline yang kalian bangun, semakin banyak aset data yang dimiliki organisasi — dan semakin sering muncul pertanyaan: tabel ini apa? siapa pemiliknya? datanya dari mana? siapa yang boleh melihatnya? Tanpa jawaban, data lake berubah menjadi data swamp dan setiap analis membangun "kebenaran" versinya sendiri.

Episode ini membangun data governance: praktik dan tool yang membuat aset data dapat ditemukan, dipercaya, dan dilindungi. Kalian akan mengenal data catalog (DataHub, OpenMetadata), lineage — jejak aliran data dari sumber ke dashboard — serta access control sebagai bagian dari tata kelola.

Apa itu Data Governance

Data governance adalah kerangka keputusan tentang data: siapa yang boleh berbuat apa terhadap data apa. Tanpa masuk ke birokrasi, ada tiga pilar operasional yang wajib dimiliki setiap tim data:

  1. Discovery — orang bisa menemukan data yang dibutuhkan (catalog + metadata).
  2. Trust — orang bisa menilai kualitas dan keandalan data (quality + lineage).
  3. Control — akses dibatasi sesuai kebutuhan (access control + security, diperdalam di episode 18).

Ketiganya bukan proyek sekali jadi, melainkan lapisan yang dibangun bertahap. Mulai dari catalog dan lineage — dua fondasi yang paling cepat memberikan nilai.

Data Catalog: Halaman Depan Data

Data catalog adalah "Google internal" untuk data: repositori metadata yang menjawab apa tabel ini, siapa pemiliknya, kolom apa saja, seberapa segar, bagaimana kualitasnya. Dua tool open-source terkemuka:

AspekDataHubOpenMetadata
LisensiApache 2.0Apache 2.0
KekuatanLineage mendalam, integrasi streamingUI rapi, ekosistem connectors luas
Source metadata50+ connectors70+ connectors
ProfilingOtomatisOtomatis

Menjalankan OpenMetadata di Docker:

Jalankan OpenMetadata local
docker run -d -p 8585:8585 \
  -e AIRFLOW_HOST=airflow \
  -e DB_HOST=postgres \
  openmetadata/server:1.5

Setelah berjalan, buka http://localhost:8585 dan hubungkan sumber kalian (PostgreSQL de_lab). Dalam hitungan menit, semua tabel muncul di catalog dengan kolom, tipe data, dan pemiliknya.

Metadata Management: Melampaui Sekadar Nama Tabel

Catalog yang baik mengumpulkan tiga lapis metadata:

  1. Technical metadata — otomatis: schema, tipe kolom, partisi, jumlah baris, profiling (NULL rate, distribusi nilai).
  2. Business metadata — manusia: deskripsi kolom, definisi metrik, konteks bisnis, owner, SLA.
  3. Operational metadata — pipeline: siapa yang membuat tabel ini, kapan terakhir dibangun, test apa yang melekat.
Deskripsi aset di catalog (contoh)
table: fct_orders
owner: data-team-commerce
description: >
  Fakta pesanan per order. Sumber: DB produksi (CDC via Debezium).
  SLA: fresh < 30 menit. Not null: order_id, amount.
columns:
  - name: amount
    description: Total nilai order dalam IDR, termasuk pajak
  - name: status
    description: pending | completed | cancelled

Metadata inilah yang mengubah sekumpulan tabel menjadi aset yang bisa dipercaya — dan dasar dari budaya data as a product di episode 24.

Lineage: Jejak Data dari Sumber ke Dashboard

Lineage menjawab pertanyaan yang paling sering muncul di tim data: angka ini dari mana? Ini peta aliran data:

100%

Nilai lineage dalam empat situasi nyata:

  1. Debugging: analyst melihat angka aneh → ikuti lineage ke belakang → temukan transformasi yang salah.
  2. Impact analysis: schema sumber berubah → lineage menunjukkan semua downstream yang terkena.
  3. Migrasi: menonaktifkan sebuah tabel → tahu siapa penggunanya sebelum memutuskan.
  4. Trust: data yang bisa ditelusuri asal-usulnya lebih mudah dipercaya.

Lineage dari dbt

Kabar baiknya, kalian sudah membangun lineage sejak episode 7 — ref() di dbt menghasilkan dependency graph. DataHub dan OpenMetadata bisa membaca manifest.json dbt untuk memetakan lineage otomatis:

Emit lineage dbt ke catalog
dbt docs generate          # menghasilkan manifest.json & catalog.json
# lalu ingest ke DataHub/OpenMetadata lewat connector dbt

Ini contoh governance yang "gratis": kalian tidak mencatat lineage manual — ia lahir dari cara menulis kode yang benar.

Access Control sebagai Bagian Governance

Data berharga harus dibatasi. Prinsipnya: least privilege — akses seminimal mungkin yang dibutuhkan peran. Di level warehouse, access control bekerja dalam tiga lapis (didalami di episode 18):

  • Database/schema level: siapa bisa membaca tabel mana.
  • Row level: misalnya sales regional hanya melihat data regionnya sendiri.
  • Column level: kolom PII hanya terlihat tim tertentu.
Contoh: view berisi akses yang dibatasi (PostgreSQL)
CREATE VIEW analytics.v_sales_jakarta AS
SELECT order_id, amount, created_at
FROM analytics.fct_orders
WHERE region = 'Jakarta';
 
GRANT SELECT ON analytics.v_sales_jakarta TO role_sales_jakarta;

Praktik: Setup Catalog & Lineage

Workflow setup yang realistis untuk tim kecil-menengah:

  1. Deploy catalog (OpenMetadata atau DataHub) di Docker/Kubernetes.
  2. Hubungkan sumber: warehouse (PostgreSQL/BigQuery), Kafka, dan dbt (manifest.json).
  3. Deklarasikan ownership & business metadata untuk tabel inti (10-20 tabel pertama).
  4. Pasang lineage: dbt connector otomatis + manual untuk pipeline non-dbt.
  5. Sosialisasi: catalog adalah produk tim data — latih analyst memakai "catalog dulu, tanya-tanya kemudian".

Note

Jangan terjebak paralaysis "perlu tool governance dulu". Mulai dengan yang sudah ada: manifest.json dbt adalah lineage, sources.yml adalah metadata awal. Catalog tool hanya memperkaya dan menyatukannya. Governance adalah proses bertahap, bukan proyek sekali install.

Kesalahan Umum (Common Pitfalls)

  1. Catalog tanpa ownership. Tabel tanpa pemilik tidak ada yang bertanggung jawab atas kualitasnya. Tetapkan owner sejak awal.

  2. Lineage hanya untuk dbt. Pipeline Python/ingestion yang tidak tercatat membuat lineage putus di tengah — ikuti jejak hingga sumber.

  3. Metadata "mengisi formulir". Deskripsi kosong atau generik tidak membantu siapa pun. Mulai kecil: kolom kunci per tabel inti.

  4. Akses terlalu terbuka. Governance tanpa access control hanyalah dokumentasi. Batasi akses sesuai kebutuhan peran.

Penutup

Di episode 15 ini kalian telah membangun pilar governance:

  • Data catalog (DataHub/OpenMetadata) membuat aset data dapat ditemukan dan dimengerti lewat tiga lapis metadata.
  • Lineage menjawab "data dari mana?" — dibangun otomatis dari ref() dbt, dan menjadi alat debugging & impact analysis.
  • Access control membatasi data sesuai kebutuhan — fondasi topik security di episode 18.
  • Praktik: mulai dari yang sudah ada (dbt manifest), lengkapi bertahap.

Di episode 16 selanjutnya kita membahas kebutuhan ML: feature store & data versioning — Feast/Tecton untuk feature, DVC/LakeFS untuk versioning, dan reproducibility, plus praktik versioning dataset. Sampai jumpa di episode 16!