Belajar Data Architect - Semantic Layer & Metrics Store

#Pendahuluan

Setelah di episode 10 kita mengamankan data, sekarang kita membahas masalah yang sangat nyata di hampir semua organisasi: "kenapa revenue di dashboard sales berbeda dengan di dashboard finance?" Penyebabnya hampir selalu sama — setiap tim mendefinisikan sendiri metrik yang sama dengan cara berbeda.

Mengapa episode ini penting? Karena perbedaan definisi metrik adalah salah satu sumber konflik dan distorsi keputusan terbesar. Dua angka revenue yang berbeda membuat manajemen ragu, tim saling menyalahkan, dan data kehilangan otoritas. Semantic layer adalah solusi arsitektural untuk masalah yang terlihat seperti masalah politik ini.

#Masalah yang Ingin Diselesaikan

Tanpa semantic layer, setiap konsumen mendefinisikan metrik sendiri:

Tim Sales:    revenue = SUM(total_amount) WHERE status != 'canceled'
Tim Finance:  revenue = SUM(amount - discount) WHERE status = 'done'
Tim Marketing: revenue = SUM(total_amount) WHERE channel = 'paid'
Tim Ops:      revenue = SUM(paid_amount)

Empat angka berbeda untuk "revenue" yang sama. Dashboard mana yang benar? Jawaban seharusnya: satu, yang didefinisikan sekali di semantic layer.

#Semantic Layer

Semantic layer adalah lapisan antara data fisik (gold layer) dan konsumen (dashboard/BI/API) yang menyimpan definisi bisnis metrik dan logika pemakaian dalam satu tempat. Konsumen tidak perlu tahu struktur tabel — mereka cukup memakai metrik bernama.

Manfaat untuk arsitek:

• Satu definisi metrik — semua konsumen memakai logika yang sama.
• Query yang optimal — logika ditulis sekali, dioptimasi sekali.
• Self-service lebih aman — konsumen memakai metrik yang sudah divalidasi, bukan meracik sendiri.
• Perubahan terpusat — mengubah definisi metrik cukup sekali, semua dashboard ikut.

#Metrics Store

Metrics store adalah penyimpanan dan API untuk definisi metrik — dan sering dipakai bergantian dengan semantic layer. Secara praktik:

Di 2026, istilah-istilah ini saling tumpang tindih; yang penting bagi arsitek adalah kapabilitas: definisi terpusat, versioning, query execution, dan integrasi dengan BI.

#dbt Semantic Layer

dbt semantic layer adalah implementasi paling populer untuk SQL-first stack: metrik didefinisikan di dbt (kode, versionable, ter-review), lalu disajikan lewat API (GraphQL) ke berbagai BI tool. Konsumen BI tidak menulis SQL ke tabel, tapi memanggil metrik.

#Mendefinisikan Metrik

semantic_models:
  - name: orders
    model: ref('fact_sales')
    defaults:
      agg_time_dimension: order_date
    entities:
      - name: order
        type: primary
        expr: order_id
    dimensions:
      - name: order_date
        type: time
      - name: status
        type: categorical
      - name: channel
        type: categorical
    measures:
      - name: total_amount
        agg: sum
 
metrics:
  - name: revenue
    description: "Pendapatan bersih dari pesanan yang selesai"
    type: simple
    type_params:
      measure: total_amount
    filter: "{{ Dimension('status') }} = 'done'"

Perhatikan: definisi revenue sekarang tunggal — SUM(total_amount) dengan filter status = 'done'. Siapa pun yang memakai metrik revenue mendapat angka yang sama persis.

#Memakai Metrik

Konsumen BI memakai metrik lewat API:

query {
  metric(metric: "revenue") {
    measure(grains: [day]) {
      grain
      endTime
      value
    }
    dimensions {
      name
      values
    }
  }
}

Hasilnya selalu konsisten — tidak peduli konsumennya Looker, Tableau, atau notebook Python.

#Desain Semantic Layer yang Baik

#1. Metrik Berasal dari Gold Layer

Semantic layer memakai model gold (star schema, episode 3-4) sebagai sumber — bukan langsung dari silver. Konsistensi dimulai dari sini: definisi bisnis sudah dirapikan sebelum metrik dibangun.

#2. Definisi Menggunakan Bahasa Bisnis

Nama metrik (revenue, active_customers, gross_margin) harus bisa dipahami konsumen bisnis, bukan sum_col_7. Setiap metrik punya deskripsi dan owner.

#3. Setiap Metrik Punya Owner

Metrik tanpa owner akan jadi "milik semua, dijaga tidak ada". Tetapkan steward per metrik (hubungkan ke governance di episode 8).

#4. Versioning dan Review

Definisi metrik berubah seiring aturan bisnis. Simpan perubahan sebagai kode (Git history) dengan proses review — bukan diubah langsung di BI tool.

#5. Jangan Masukkan Semua Metrik

Semantic layer bukan tempat menampung ratusan metrik yang tidak dipakai. Mulai dari metrik kritis yang paling sering menimbulkan konflik (revenue, margin, customer count), lalu perluas.

#Praktik: Desain Semantic Layer

1. Identifikasi 5-10 metrik kritis yang paling sering bertabrakan definisi
2. Amankan satu definisi per metrik bersama stakeholder (bukan sendiri)
3. Bangun semantic model di dbt atas gold layer (measure + dimension + entity)
4. Definisikan metrik dengan filter dan agregasi yang jelas
5. Hubungkan ke BI via API; blokir akses SQL langsung ke tabel gold
6. Uji: jalankan metrik yang sama di dua BI tool → angka harus identik

#Penutup

Inti yang harus dibawa pulang:

• Konflik metrik terjadi karena definisi tersebar di setiap konsumen.
• Semantic layer = satu definisi metrik di satu tempat, dipakai semua konsumen.
• dbt semantic layer mendefinisikan metrik sebagai kode dengan API untuk BI.
• Desain yang baik: berasal dari gold layer, berbahasa bisnis, punya owner, dan di-version.
• Arsitek menjadikan semantic layer satu-satunya jalan menuju data analitis.

Di episode 12 selanjutnya kita akan membahas Data Mesh & Decentralization — membalik model terpusat menjadi domain ownership, data products, dan federated governance. Sampai jumpa di episode 12!