Belajar BI Analyst - Semantic Layer & Metrics Store

#Pendahuluan

Di episode-episode sebelumnya kalian menghitung metrik yang sama berulang kali: Revenue di Power BI (DAX), di Tableau (calculated field), dan di Looker (LookML). Sekarang bayangkan definisinya berubah — misalnya "revenue" kini harus mengecualikan refund. Kalian harus mengubah tiga tempat, dan kalau satu terlewat, muncullah inkonsistensi klasik: dashboard satu bilang 10 miliar, dashboard lain bilang 9,8 miliar.

Episode ini menyelesaikan masalah itu dengan semantic layer dan Metrics Store: definisi metrik ditulis satu kali di satu tempat, lalu dipakai ulang oleh semua tool dan semua dashboard.

#Masalah yang Diselesaikan: Definisi Tersebar

Tanpa semantic layer, setiap tool punya definisi metriknya sendiri:

Hasilnya: revenue di tiga dashboard berbeda, tim saling menyalahkan, dan kepercayaan pada data runtuh. Semantic layer memecahkan ini dengan memindahkan definisi ke satu lapisan di tengah.

#Semantic Layer dan Metrics Store

Dua istilah yang sering dipakai bergantian:

• Semantic layer: lapisan abstraksi antara data mentah dan konsumen data — menerjemahkan tabel teknis menjadi konsep bisnis (fact_orders.sales → Revenue).
• Metrics Store: katalog terpusat berisi definisi metrik yang bisa dikonsumsi banyak tool — pada dasarnya semantic layer yang terstandarkan dan ber-API.

Dengan keduanya, alurnya menjadi:

Satu definisi, semua konsumen — kalau Revenue berubah definisinya, hanya satu tempat yang diedit.

#Pendekatan Semantic Layer di Market

Beberapa pendekatan yang ada di dunia nyata:

Pendekatan terbaik di 2026: definisikan metrik sebagai kode (di dbt atau tool semantic layer khusus), lalu konsumsi dari semua tool. Inilah arah enterprise BI — dan kalian akan membangunnya sekarang.

#Praktik: Definisikan Metrik dengan dbt

Pakai dbt (yang sudah kalian kenal di episode 6) untuk mendefinisikan metrik Superstore. Buat file definisi metrik di project dbt:

semantic_models:
  - name: fact_orders
    model: ref('fact_orders')
    entities:
      - name: order
        type: foreign
        expr: order_id
    dimensions:
      - name: order_date
        type: time
        type_params:
          time_granularity: day
      - name: region
        type: categorical
        expr: dim_customer_region
    measures:
      - name: revenue
        type: sum
        expr: sales
      - name: profit
        type: sum
        expr: profit
      - name: total_orders
        type: count_distinct
        expr: order_id
 
metrics:
  - name: revenue
    description: "Total nilai penjualan (sum of sales) per periode"
    type: simple
    label: Revenue
    type_params:
      measure: revenue
    filters:
      - where: "{{ Dimension('order_date') }} >= '2024-01-01'"
 
  - name: profit_margin
    description: "Persentase keuntungan dari setiap penjualan"
    type: ratio
    label: Profit Margin
    type_params:
      numerator: profit
      denominator: revenue
      denominator_metric: revenue

Di sini:

• semantic_models mendeskripsikan tabel fact_orders sebagai model semantik: entity, dimensi, dan measure.
• metrics mendefinisikan metrik yang bisa dipakai banyak tool — revenue simple, profit_margin ratio.
• Perhatikan description yang dimasukkan ke dalam definisi — dokumentasi hidup yang akan muncul di katalog metrik.

Jalankan validasi untuk memastikan definisi benar:

dbt parse
dbt list --resource-type metric

#Semua Kembali ke Konsistensi

Mari kita cek dampaknya pada masalah awal di episode ini:

• Perubahan definisi revenue → satu edit di metrics.yml → semua dashboard (Power BI, Tableau, Looker, Excel) ikut.
• Onboarding analyst baru → membaca katalog metrik di semantic layer → langsung paham definisi.
• Audit → setiap metrik punya description dan riwayat perubahan di git → bisa dipertanggungjawabkan.
• AI copilot → menjawab pertanyaan dengan metrik yang sudah didefinisikan → tidak "menebak" formula.

#Kesalahan Umum Semantic Layer

• Menyalin definisi ke tool tanpa API: meng-konsumi semantic layer lewat ekspor manual = definisi tersebar lagi.
• Metrik tanpa deskripsi: katalog metrik tanpa dokumentasi hanya berguna untuk pembuatnya.
• Terlalu banyak metrik: katalog 500 metrik sama buruknya dengan nol metrik — kurasi adalah bagian dari pekerjaan.
• Mengabaikan dimensi standar: region, tanggal, dan kategori harus distandarkan juga, bukan hanya measure.
• Semantic layer tanpa ownership: tanpa pemilik yang jelas, definisi diam-diam melenceng dari bisnis.

#Penutup

Inti yang harus dibawa pulang:

• Masalah inti BI: definisi metrik tersebar di banyak tool → angka berbeda antar dashboard.
• Semantic layer menerjemahkan data teknis jadi konsep bisnis; Metrics Store membuatnya terstandar dan ber-API.
• dbt Semantic Layer mendefinisikan metrik sebagai kode yang bisa dikonsumsi semua tool.
• Konsistensi = satu sumber kebenaran, diubah sekali, dipakai semua.
• Praktik: metrik revenue dan profit_margin Superstore didefinisikan dan tervalidasi di dbt.

Di episode 13 selanjutnya kita akan membahas self-service BI — bagaimana membuka akses data untuk seluruh perusahaan tanpa mengorbankan konsistensi dan keamanan, plus praktik membangun portal self-service. Definisi metrik kalian sudah terpusat, sekarang waktunya memberdayakan pengguna. Pastikan tetap semangat!