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

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.
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:
Ketiganya bukan proyek sekali jadi, melainkan lapisan yang dibangun bertahap. Mulai dari catalog dan lineage — dua fondasi yang paling cepat memberikan nilai.
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:
| Aspek | DataHub | OpenMetadata |
|---|---|---|
| Lisensi | Apache 2.0 | Apache 2.0 |
| Kekuatan | Lineage mendalam, integrasi streaming | UI rapi, ekosistem connectors luas |
| Source metadata | 50+ connectors | 70+ connectors |
| Profiling | Otomatis | Otomatis |
Menjalankan OpenMetadata di Docker:
docker run -d -p 8585:8585 \
-e AIRFLOW_HOST=airflow \
-e DB_HOST=postgres \
openmetadata/server:1.5Setelah 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.
Catalog yang baik mengumpulkan tiga lapis metadata:
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 | cancelledMetadata inilah yang mengubah sekumpulan tabel menjadi aset yang bisa dipercaya — dan dasar dari budaya data as a product di episode 24.
Lineage menjawab pertanyaan yang paling sering muncul di tim data: angka ini dari mana? Ini peta aliran data:
Nilai lineage dalam empat situasi nyata:
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:
dbt docs generate # menghasilkan manifest.json & catalog.json
# lalu ingest ke DataHub/OpenMetadata lewat connector dbtIni contoh governance yang "gratis": kalian tidak mencatat lineage manual — ia lahir dari cara menulis kode yang benar.
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):
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;Workflow setup yang realistis untuk tim kecil-menengah:
manifest.json).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.
Catalog tanpa ownership. Tabel tanpa pemilik tidak ada yang bertanggung jawab atas kualitasnya. Tetapkan owner sejak awal.
Lineage hanya untuk dbt. Pipeline Python/ingestion yang tidak tercatat membuat lineage putus di tengah — ikuti jejak hingga sumber.
Metadata "mengisi formulir". Deskripsi kosong atau generik tidak membantu siapa pun. Mulai kecil: kolom kunci per tabel inti.
Akses terlalu terbuka. Governance tanpa access control hanyalah dokumentasi. Batasi akses sesuai kebutuhan peran.
Di episode 15 ini kalian telah membangun pilar governance:
ref() dbt, dan menjadi alat debugging & impact analysis.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!