Looker dan LookML di Tahun 2026: Panduan Business Intelligence dan Pertanyaan Wawancara

Pertanyaan wawancara Looker secara konsisten berfokus pada pemodelan LookML, alur eksplorasi data, dan bagaimana semantic layer menerjemahkan logika bisnis menjadi definisi yang dapat digunakan kembali. Tutorial ini membahas konsep inti LookML, pola implementasi praktis, dan pertanyaan-pertanyaan yang dihadapi data analyst saat wawancara untuk posisi yang berfokus pada Looker di tahun 2026.

Memahami Semantic Layer LookML

LookML berperan sebagai lapisan translasi antara tabel database mentah dan metrik yang ramah bisnis. Daripada menulis SQL join yang kompleks berulang kali, analyst mendefinisikan relationship dalam file model yang dikompilasi Looker menjadi query yang teroptimasi.

Semantic layer memecahkan tiga masalah yang sering ditanyakan interviewer:

• Konsistensi: Setiap pengguna melihat definisi metrik yang sama
• Reusability: Dimension dan measure ada sekali, direferensikan di mana saja
• Governance: Perubahan menyebar secara otomatis ke semua dashboard

Dokumentasi Looker dari Google Cloud mendeskripsikan LookML sebagai bahasa yang "dependency-aware"—ketika satu definisi berubah, referensi downstream ikut terupdate secara otomatis. Dependency awareness ini menjadi kritis saat memelihara model skala enterprise.

Views dan Explores LookML: Building Blocks Utama

Views mendefinisikan kolom yang tersedia dari tabel tunggal atau derived table. Explores menggabungkan views melalui join dan mengeksposnya ke pengguna bisnis.

# views/orders.view.lkml
view: orders {
  sql_table_name: `analytics.orders` ;;

  dimension: order_id {
    primary_key: yes
    type: number
    sql: ${TABLE}.order_id ;;
  }

  dimension_group: created {
    type: time
    timeframes: [raw, date, week, month, quarter, year]
    sql: ${TABLE}.created_at ;;
  }

  dimension: status {
    type: string
    sql: ${TABLE}.status ;;
  }

  measure: total_orders {
    type: count
    drill_fields: [order_id, created_date, status]
  }

  measure: total_revenue {
    type: sum
    sql: ${TABLE}.amount ;;
    value_format_name: usd
  }
}

Deklarasi dimension_group menghasilkan beberapa dimension berbasis waktu dari satu kolom timestamp. Interviewer sering meminta kandidat menjelaskan mengapa pola ini mengurangi duplikasi kode dan memastikan penanganan tanggal yang konsisten di seluruh model.

Parameter drill_fields mendefinisikan apa yang dilihat pengguna saat mengklik nilai measure—detail UX yang menunjukkan pemahaman tentang bagaimana analyst sebenarnya berinteraksi dengan Looker.

Joins dan Relationships dalam LookML

Explores mendefinisikan bagaimana views terhubung melalui SQL join. Tipe join dan deklarasi relationship secara langsung mempengaruhi performa query dan akurasi agregasi.

# models/ecommerce.model.lkml
explore: orders {
  label: "Order Analysis"
  description: "All orders with customer and product details"

  join: customers {
    type: left_outer
    sql_on: ${orders.customer_id} = ${customers.customer_id} ;;
    relationship: many_to_one
  }

  join: order_items {
    type: left_outer
    sql_on: ${orders.order_id} = ${order_items.order_id} ;;
    relationship: one_to_many
  }

  join: products {
    type: left_outer
    sql_on: ${order_items.product_id} = ${products.product_id} ;;
    relationship: many_to_one
  }
}

Parameter relationship memberitahu Looker bagaimana menangani agregasi. Relationship one_to_many berarti measure harus diagregasi di sisi "one" untuk menghindari penghitungan ganda. Kesalahan dalam hal ini menyebabkan total yang salah—skenario debugging umum dalam wawancara.

Symmetric aggregates memecahkan masalah fanout secara otomatis. Saat menggabungkan tabel dengan granularitas berbeda, Looker menghasilkan SQL yang menghitung measure pada level yang benar sebelum melakukan join.

Derived Tables untuk Transformasi Kompleks

Derived tables membuat tabel virtual dari query SQL atau agregasi yang didefinisikan LookML. Native derived tables menggunakan sintaks LookML; SQL-derived tables menyematkan SQL mentah.

# views/customer_order_facts.view.lkml
view: customer_order_facts {
  derived_table: {
    explore_source: orders {
      column: customer_id { field: customers.customer_id }
      column: first_order_date { field: orders.created_date }
      column: lifetime_orders { field: orders.total_orders }
      column: lifetime_revenue { field: orders.total_revenue }
      derived_column: customer_tenure_days {
        sql: DATE_DIFF(CURRENT_DATE(), first_order_date, DAY) ;;
      }
    }
    datagroup_trigger: daily_etl
    indexes: ["customer_id"]
  }

  dimension: customer_id {
    primary_key: yes
    hidden: yes
    type: number
  }

  dimension: first_order_date {
    type: date
    sql: ${TABLE}.first_order_date ;;
  }

  dimension: lifetime_orders {
    type: number
    sql: ${TABLE}.lifetime_orders ;;
  }

  dimension: customer_tier {
    type: string
    sql: CASE
      WHEN ${lifetime_orders} >= 10 THEN 'Gold'
      WHEN ${lifetime_orders} >= 5 THEN 'Silver'
      ELSE 'Bronze'
    END ;;
  }
}

datagroup_trigger mengontrol kapan Looker membangun ulang derived table—biasanya setelah ETL upstream selesai. Persistent derived tables (PDTs) dimaterialisasi di database, menukar storage untuk kecepatan query.

Interviewer bertanya tentang strategi rebuild PDT. Parameter sql_trigger_value menjalankan query SQL; ketika hasilnya berubah, Looker membangun ulang PDT. Pola umum menggunakan SELECT MAX(updated_at) FROM source_table.

Pertanyaan Wawancara Looker: Desain Model

Wawancara teknis untuk posisi Looker sangat fokus pada keputusan pemodelan LookML. Pertanyaan-pertanyaan ini menilai apakah kandidat memahami tradeoff antara fleksibilitas dan performa.

Pertanyaan: Bagaimana Anda memodelkan fact table dengan multiple date dimensions?

Jawabannya melibatkan pembuatan dimension groups terpisah dan penamaan join secara eksplisit:

# views/orders.view.lkml
view: orders {
  dimension_group: order_created {
    type: time
    timeframes: [date, week, month, year]
    sql: ${TABLE}.created_at ;;
  }

  dimension_group: order_shipped {
    type: time
    timeframes: [date, week, month, year]
    sql: ${TABLE}.shipped_at ;;
  }

  dimension: days_to_ship {
    type: number
    sql: DATE_DIFF(${order_shipped_date}, ${order_created_date}, DAY) ;;
  }
}

Pertanyaan: Kapan menggunakan PDT versus dbt model?

PDTs cocok untuk agregasi spesifik Looker yang berubah seiring model. Transformasi dbt cocok untuk dataset bersama yang dikonsumsi oleh multiple tools. Pola integrasi dbt + Looker menggunakan dbt untuk transformasi berat dan PDTs untuk metrik last-mile.

Pertanyaan: Bagaimana menangani slowly changing dimensions di LookML?

Tabel SCD Type 2 memerlukan filtering ke record saat ini. Tambahkan dimension yang memfilter baris dan gunakan always_filter di explore:

# views/customer_history.view.lkml
view: customer_history {
  dimension: is_current {
    type: yesno
    sql: ${TABLE}.end_date IS NULL ;;
  }
}

# In the explore
explore: orders {
  join: customer_history {
    sql_on: ${orders.customer_id} = ${customer_history.customer_id} ;;
    relationship: many_to_one
  }
  always_filter: {
    filters: [customer_history.is_current: "Yes"]
  }
}

Liquid Templating untuk Model Dinamis

Liquid templating memungkinkan logika kondisional dalam definisi LookML. User attributes, nilai filter, dan permissions dapat memodifikasi SQL yang dihasilkan.

# views/regional_orders.view.lkml
view: regional_orders {
  sql_table_name: 
    {% if _user_attributes['region'] == 'EMEA' %}
      analytics.orders_emea
    {% elsif _user_attributes['region'] == 'APAC' %}
      analytics.orders_apac
    {% else %}
      analytics.orders_us
    {% endif %}
  ;;

  dimension: amount {
    type: number
    sql: ${TABLE}.amount ;;
    html: 
      {% if value > 1000 %}
        <span style="color: green;">{{ rendered_value }}</span>
      {% else %}
        {{ rendered_value }}
      {% endif %}
    ;;
  }
}

User attributes menggerakkan row-level security dan pemilihan tabel dinamis. Objek _user_attributes menyediakan akses ke nilai yang ditetapkan di panel admin Looker.

Parameter html mengkustomisasi bagaimana nilai dirender dalam tabel dan visualisasi—conditional formatting yang sering muncul dalam proyek take-home interview.

Pola Optimisasi Performa

Looker menghasilkan SQL dari definisi LookML. Optimisasi memerlukan pemahaman baik model layer maupun database yang mendasarinya.

Aggregate awareness melakukan pre-compute agregasi umum pada berbagai level grain:

# views/orders.view.lkml
view: orders {
  aggregate_table: daily_orders {
    query: {
      dimensions: [created_date]
      measures: [total_orders, total_revenue]
    }
    materialization: {
      datagroup_trigger: daily_etl
    }
  }

  aggregate_table: monthly_orders {
    query: {
      dimensions: [created_month]
      measures: [total_orders, total_revenue]
    }
    materialization: {
      datagroup_trigger: daily_etl
    }
  }
}

Looker secara otomatis mengarahkan query ke aggregate table terkecil yang memenuhi permintaan. Query dashboard bulanan membaca dari monthly_orders daripada memindai seluruh fact table.

Pengaturan level koneksi mempengaruhi performa secara signifikan. Koneksi BigQuery harus mengaktifkan query caching dan mengatur timeout yang sesuai. Parameter max_connections mengontrol concurrent query slots.

Untuk data analyst yang mempersiapkan wawancara, panduan SQL window functions membahas pola query yang melengkapi keterampilan pemodelan LookML.

Access Controls dan Content Management

Row-level security, model permissions, dan organisasi konten muncul dalam wawancara Looker level senior. Mekanisme access_grant mengontrol ketersediaan fitur:

# models/ecommerce.model.lkml
access_grant: can_view_pii {
  user_attribute: department
  allowed_values: ["data_team", "compliance"]
}

explore: customers {
  access_filter: {
    field: customers.region
    user_attribute: allowed_regions
  }
}

view: customers {
  dimension: email {
    type: string
    sql: ${TABLE}.email ;;
    required_access_grants: [can_view_pii]
  }
}

access_filter secara dinamis menambahkan klausa WHERE berdasarkan user attributes. Seorang sales manager hanya melihat data region mereka. Parameter required_access_grants menyembunyikan dimension dari pengguna yang tidak memiliki grant yang ditentukan.

Organisasi konten mengikuti hierarki folder. Dashboard produksi berada di shared spaces; pekerjaan development tetap di folder personal hingga divalidasi. LookML validator menangkap kesalahan sintaks sebelum deployment.

Kesalahan Wawancara Umum yang Harus Dihindari

Wawancara teknis Looker mengungkapkan kesalahpahaman umum:

Deklarasi relationship yang salah menyebabkan inflasi metrik. Relationship one_to_one pada join one_to_many menghasilkan agregat yang salah. Selalu verifikasi kardinalitas dengan query SELECT COUNT(*), COUNT(DISTINCT key).

Terlalu bergantung pada SQL-derived tables daripada native derives. Native derived tables terintegrasi dengan dependency tracking Looker; SQL-derived tables memerlukan manajemen manual.

Mengabaikan datagroup caching. Tanpa cache invalidation yang tepat, dashboard menampilkan data basi. Definisikan datagroups yang selaras dengan jadwal ETL dan tetapkan ke explores.

Untuk persiapan wawancara komprehensif tentang konsep pemodelan data dan analytics, panduan pertanyaan wawancara data analytics membahas topik yang lebih luas di luar pengetahuan spesifik Looker.

Kesimpulan

Berhasil dalam wawancara Looker memerlukan demonstrasi pengetahuan sintaks LookML dan pemahaman mengapa arsitektur semantic layer menguntungkan organisasi:

• LookML views mendefinisikan dimension dan measure; explores menggabungkan views melalui join yang dideklarasikan dengan tipe relationship eksplisit
• Derived tables mematerialisasi transformasi kompleks; datagroups mengontrol cache invalidation dan jadwal rebuild PDT
• Liquid templating memungkinkan generasi SQL dinamis berdasarkan user attributes dan seleksi filter
• Aggregate awareness melakukan pre-compute metrik pada multiple grains, mengarahkan query ke tabel optimal secara otomatis
• Access controls menggabungkan row-level filters, access grants, dan content permissions untuk governed self-service
• Optimisasi performa memerlukan penyelarasan pola LookML dengan tuning spesifik database (BigQuery slots, Snowflake warehouses)

Latih membangun model LookML terhadap sample datasets sebelum wawancara. BigQuery public datasets menyediakan skema realistis untuk latihan pemodelan.