Belajar Data Engineer - Data Mesh & Data Product

#Pendahuluan

Selama episode 1-23, kita mengasumsikan model organisasi data yang terpusat: satu tim data platform melayani seluruh perusahaan. Di episode 24 kita membalik asumsi itu. Data mesh adalah paradigma yang menyebarkan kepemilikan data ke domain bisnis — dan menuntut data engineer berpikir dengan cara yang berbeda.

Mengapa penting? Karena di skala tertentu, tim data pusat menjadi bottleneck: antrean pembangunan pipeline berbulan-bulan, dan tim bisnis frustrasi. Data mesh menawarkan jalan keluar — tetapi hanya jika fondasinya benar. Episode ini membedah empat prinsip data mesh dan elemen kunci yang membuatnya berhasil: data product contract.

#Empat Prinsip Data Mesh

Data mesh (dipopulerkan Zhamak Dehghani) berdiri di atas empat prinsip:

1. Domain ownership — data dimiliki oleh tim yang paling paham domainnya (marketing punya data marketing, supply chain punya data supply chain).
2. Data as a product — setiap dataset adalah produk yang harus memenuhi standar: dapat ditemukan, berkualitas, dan mudah dikonsumsi.
3. Self-serve data platform — platform menyediakan infrastruktur yang memudahkan domain membangun pipeline sendiri.
4. Federated computational governance — aturan bersama (standard) ditetapkan bersama, bukan diturunkan dari satu tim pusat.

Pergeseran kunci yang harus dipahami: tim data platform tidak lagi "membangunkan pipeline untuk semua orang", melainkan menyediakan platform agar setiap domain bisa membangun dan memiliki data mereka sendiri.

#Data as a Product

Ide sentral data mesh: perlakukan data seperti produk konsumen — lengkap dengan pemilik, standar kualitas, dan kontrak. Sebuah data product yang baik memiliki:

• Discoverable — terdaftar di catalog (episode 15), dengan deskripsi dan owner.
• Addressable — alamat unik yang bisa direferensikan (misal marketing.campaign_metrics).
• Trustworthy — quality gates terpasang (episode 14), SLA jelas.
• Self-explaining — dokumentasi yang menjelaskan isi dan semantik.
• Accessible — akses mudah lewat standar (SQL/API) dengan kontrol yang benar.
• Interoperable — standar schema dan format yang bisa dipakai tim lain.

Jika kalian membangun dataset yang tidak bisa ditemukan, tidak ada owner, dan kualitasnya tidak jelas — kalian sedang membangun data dump, bukan data product.

#Self-Serve Data Platform

Peran data engineer platform bergeser: dari membangun pipeline menjadi membangun jalan raya. Platform self-serve menyediakan:

• Templat pipeline (dbt + Airflow + quality gates) yang tinggal dipakai domain.
• Akses provisioning otomatis (IaC) ke storage, warehouse, dan catalog.
• Standar observability yang terpasang sejak awal (episode 20).
• Dokumentasi & contoh yang membuat pengguna mandiri.

Tujuan akhirnya: domain bisa membangun data product tanpa menunggu tim pusat — tapi tetap dalam standar yang sama, berkat governance federated.

#Data Product Contract

Data product contract adalah kesepakatan eksplisit antara pemilik dan konsumen data. Inilah elemen yang membuat data mesh berfungsi: tanpa kontrak, "kepemilikan domain" berubah menjadi "setiap orang melakukan apa saja". Kontrak menjawab empat pertanyaan:

1. What — skema apa yang dijamin? Kolom apa saja, tipe apa?
2. When — kapan data diperbarui? SLA-nya apa?
3. How good — kualitas minimum apa yang dijamin?
4. How — bagaimana konsumen mengaksesnya?

#Praktik: Merancang Data Product Contract

Mari rancang kontrak untuk data product marketing.campaign_metrics:

product: marketing.campaign_metrics
owner: tim-marketing
version: "1.4"
 
schema:
  - column: campaign_id
    type: string
    nullable: false
  - column: spend
    type: decimal(12,2)
    nullable: false
  - column: clicks
    type: int64
    nullable: false
  - column: conversions
    type: int64
    nullable: true
 
freshness:
  sla: 30 menit setelah jam-jam-selesai
  check: max(updated_at) < now() - 35 minutes
 
quality:
  checks:
    - "spend >= 0"
    - "clicks >= 0"
    - "conversions <= clicks"
 
access:
  readers:
    - role: analytics-team
      level: read_only
  table: lakehouse.gold.campaign_metrics
 
support:
  owner_slack: #data-marketing
  docs: https://catalog.example/campaign_metrics

Kontrak ini membuat aturan main eksplisit: konsumen tahu persis apa yang dijamin, dan pemilik tahu persis apa tanggung jawabnya. Ketika kontrak dilanggar (freshness meleset, schema berubah), jelas siapa yang harus diperbaiki dan siapa yang terdampak.

#Peran Data Engineer di Dunia Data Mesh

Pertanyaan yang wajar: apakah data engineer masih relevan di data mesh? Jawabannya: relevan, tapi perannya berubah:

• Data engineer platform — membangun self-serve platform, templat, governance automation.
• Data engineer domain — tertanam di domain bisnis, membangun pipeline dan data product mereka.
• Keduanya — menjaga standar bersama, sehingga "decentralized ownership" tidak menjadi "chaos".

Justru di data mesh, keterampilan yang kalian kumpulkan di 23 episode sebelumnya — pipeline, quality, governance, observability, security — menjadi semakin berharga, karena standar itu harus diautomasi agar diikuti semua domain.

#Kesalahan Umum (Common Pitfalls)

1. Data mesh = desentralisasi tanpa standar. Tanpa governance federated dan kontrak, "kepemilikan domain" berubah jadi kekacauan. Platform & kontrak adalah syarat, bukan opsional.

2. Data product tanpa owner. Setiap data product harus punya pemilik yang menjawab kualitas dan dukungan.

3. Menerapkan data mesh untuk organisasi kecil. Untuk tim data 3 orang, data mesh adalah birokrasi. Ini pola untuk skala di mana tim pusat menjadi bottleneck — bukan solusi universal.

4. Kontrak hanya dokumen. Kontrak yang tidak dijalankan mesin (test, schema check) akan diabaikan. Automatisasi kontrak.

#Penutup

Di episode 24 ini kalian telah memahami paradigma data mesh:

• Empat prinsip: domain ownership, data as a product, self-serve platform, federated governance.
• Data product harus discoverable, trustworthy, dan self-explaining — bukan sekadar dataset.
• Self-serve platform menggeser peran data engineer dari membangun pipeline menjadi membangun jalan raya.
• Data product contract menjawab what/when/how-good/how — dan harus diwujudkan dalam test yang berjalan.
• Praktik: merancang kontrak campaign_metrics yang lengkap.

Di episode 25 selanjutnya kita menghubungkan semua ke dunia AI: data for AI/ML pipelines — feature pipelines, training data versioning, inference data infrastructure, dan pipeline data untuk LLM fine-tuning. Sampai jumpa di episode 25!