Belajar BI Analyst - Looker & LookML

#Pendahuluan

Setelah di episode 8 dan 9 kalian mengenal Power BI dan Tableau, pada episode ini kita membahas tool ketiga yang mengusung filosofi berbeda: Looker. Jika Power BI dan Tableau menyimpan logika di dalam file dashboard, Looker menyimpan logika metrik di kode bernama LookML yang tersimpan di git.

Mengapa ini penting? Karena Looker memisahkan dua hal yang sering tercampur: definisi data (kode LookML) dan presentasi (dashboard). Satu definisi dipakai ribuan pengguna — inilah fondasi semantic layer enterprise yang akan kita dalami di episode 12. Memahami Looker berarti memahami cara enterprise BI menjaga metrik tetap konsisten di skala besar.

#Paradigma Looker: Model Sebagai Kode

Looker tidak mengimpor data ke dirinya — ia mengirim SQL yang dihasilkan dari LookML ke database/warehouse, lalu menampilkan hasilnya. Konsekuensinya:

Karena definisi ada di kode, review code, audit perubahan, dan konsistensi metrik menjadi jauh lebih mudah. Inilah mengapa Looker disebut "semantic layer as a product".

#Komponen LookML: View, Explore, Dimension, Measure

Empat komponen dasar LookML:

Alur pembangunan: definisikan views → hubungkan lewat explores → pengguna mengeksplorasi lewat UI.

#Membangun Explore Pertama

Buat file model untuk Superstore di direktori Looker project:

connection: "bi_lab_postgres"
 
explore: orders {
    view_name: orders
    join: customer {
        type: left_outer
        sql_on: ${orders.customer_id} = ${customer.customer_id} ;;
        relationship: many_to_one
    }
    join: product {
        type: left_outer
        sql_on: ${orders.product_id} = ${product.product_id} ;;
        relationship: many_to_one
    }
}

Di sini orders adalah explore utama, dan kita menghubungkannya ke customer serta product lewat join. Format ${view.field} adalah sintaks referensi field LookML — dibaca sebagai "field dari view tertentu".

#View dengan Dimension dan Measure

Definisikan view orders dengan dimension dan measure untuk metrik kita:

view: orders {
    dimension: order_id {
        type: string
        sql: ${TABLE}.order_id ;;
    }
    dimension: order_date {
        type: date
        sql: ${TABLE}.order_date ;;
    }
    dimension: region {
        type: string
        sql: ${TABLE}.region ;;
    }
 
    measure: revenue {
        type: sum
        sql: ${TABLE}.sales ;;
        value_format_name: usd
    }
    measure: profit {
        type: sum
        sql: ${TABLE}.profit ;;
    }
    measure: total_orders {
        type: count_distinct
        sql: ${TABLE}.order_id ;;
    }
    measure: margin {
        type: number
        sql: (${profit} / NULLIF(${revenue}, 0)) ;;
        value_format_name: percent_2
    }
}

Perhatikan keindahannya: margin dihitung dari measure lain (${profit} dan ${revenue}) — definisi ini hidup satu tempat dan otomatis dipakai ulang di semua dashboard, laporan, dan explore. Inilah yang kita sebut konsistensi metrik.

Setelah file disimpan, klik "Validate" di Looker IDE untuk memastikan sintaks benar, lalu commit ke git.

#Mengeksplorasi di UI

Buka Explore di UI Looker:

1. Pilih explore orders.
2. Seret region (dimension) ke area baris.
3. Seret revenue, profit, margin (measures) ke area nilai.
4. Tambahkan filter order_date untuk rentang waktu.
5. Looker mengirim query SQL ke warehouse dan menampilkan hasilnya — dan pengguna bisa beralih ke mode visual (chart) tanpa meninggalkan halaman.

Keuntungan besar bagi BI Analyst: pengguna akhir bisa bereksplorasi sendiri tanpa tahu SQL, sementara kalian cukup mengatur apa yang boleh dilihat (field mana yang ditampilkan, di-filter, atau disembunyikan). Inilah self-service BI yang akan kita bahas di episode 13.

#Common Pitfalls Looker

• Menghitung di UI, bukan di LookML: kalau logika ada di UI, definisi tersebar dan tidak bisa diaudit — pindahkan ke measure.
• Join many-to-many tanpa sadar: menghasilkan duplikasi; gunakan relationship yang benar di definisi join.
• Mengabaikan izin field: membiarkan semua field terlihat membuat pengguna salah paham — sembunyikan field teknis.
• Tanpa version control: Looker kuat karena berbasis git; jangan mengubah model tanpa commit yang bisa ditelusuri.
• LookML tanpa validasi: selalu klik Validate sebelum menyimpan — error sintaks menghentikan semua explore.

#Penutup

Inti yang harus dibawa pulang:

• Looker menempatkan definisi data sebagai kode (LookML) — konsisten dan bisa diaudit di skala besar.
• Empat komponen: view, dimension, measure, explore.
• Measure margin dihitung dari measure lain → satu sumber kebenaran metrik.
• Explore memberi pengguna kebebasan eksplorasi tanpa tahu SQL.
• Praktik: explore orders Superstore berhasil dibangun dan dieksplorasi.

Di episode 11 selanjutnya kita akan membahas dashboard UX & storytelling data — bagaimana menyusun layout, hierarki, dan narasi sehingga dashboard bukan sekadar kumpulan chart, melainkan cerita yang mendorong keputusan. Prinsip ini berlaku untuk Power BI, Tableau, Looker, dan tool apa pun. Pastikan tetap semangat!