# 2026'da Looker ve LookML: İş Zekası ve Mülakat Soruları

> Veri analistleri için kapsamlı Looker ve LookML rehberi. Semantik modelleme, uygulama kalıpları, performans optimizasyonu ve sıkça karşılaşılan teknik mülakat soruları.

- Published: 2026-07-20
- Updated: 2026-07-20
- Author: SharpSkill
- Tags: looker, lookml, is-zekasi, veri-analitigi, mulakat-sorulari
- Reading time: 12 min

---

Looker mülakat soruları sürekli olarak LookML modelleme, veri keşfi iş akışları ve semantik katmanın iş mantığını yeniden kullanılabilir tanımlara nasıl dönüştürdüğü konularına odaklanır. Bu eğitim, temel LookML kavramlarını, pratik uygulama kalıplarını ve veri analistlerinin 2026'da Looker odaklı roller için mülakata girdiğinde karşılaştıkları soruları kapsar.

> **Temel LookML Kavramı**
>
> LookML, veri modellemesini veri keşfinden ayırır. Analistler boyutları, ölçüleri ve ilişkileri model katmanında bir kez tanımlar, ardından iş kullanıcıları SQL yazmadan veriyi sorgular — bu kalıp neredeyse her Looker teknik mülakatında karşımıza çıkar.

## LookML Semantik Katmanını Anlamak

LookML, ham veritabanı tabloları ile iş dostu metrikler arasında bir çeviri katmanı görevi görür. Karmaşık SQL birleştirmelerini tekrar tekrar yazmak yerine, analistler ilişkileri model dosyalarında tanımlar ve Looker bunları optimize edilmiş sorgulara derler.

Semantik katman, mülakatçıların sıkça sorduğu üç sorunu çözer:
- **Tutarlılık**: Her kullanıcı aynı metrik tanımlarını görür
- **Yeniden Kullanılabilirlik**: Boyutlar ve ölçüler bir kez tanımlanır, her yerde kullanılır
- **Yönetişim**: Değişiklikler otomatik olarak tüm panolara yayılır

Google Cloud'un [Looker dokümantasyonu](https://cloud.google.com/looker/docs/what-is-lookml) LookML'i "bağımlılık farkında" bir dil olarak tanımlar — bir tanım değiştiğinde, bağımlı referanslar otomatik olarak güncellenir. Bu bağımlılık farkındalığı, kurumsal ölçekli modellerin bakımında kritik hale gelir.

## LookML Views ve Explores: Temel Yapı Taşları

Views, tek bir tablodan veya türetilmiş tablodan kullanılabilir sütunları tanımlar. Explores, views'ları birleştirmeler aracılığıyla birleştirir ve iş kullanıcılarına sunar.

```lookml
# 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
  }
}
```

`dimension_group` bildirimi, tek bir zaman damgası sütunundan birden fazla zamana dayalı boyut oluşturur. Mülakatçılar genellikle adaylara bu kalıbın neden kod tekrarını azalttığını ve model genelinde tutarlı tarih işlemeyi sağladığını açıklamalarını ister.

`drill_fields` parametresi, kullanıcıların bir ölçü değerine tıkladığında ne gördüklerini tanımlar — analistlerin Looker ile gerçekte nasıl etkileşime girdiğini gösteren bir UX detayı.

## LookML'de Birleştirmeler ve İlişkiler

Explores, views'ların SQL birleştirmeleri aracılığıyla nasıl bağlandığını tanımlar. Birleştirme türü ve ilişki bildirimi, sorgu performansını ve toplama doğruluğunu doğrudan etkiler.

```lookml
# models/ecommerce.model.lkml
explore: orders {
  label: "Sipariş Analizi"
  description: "Müşteri ve ürün detayları ile tüm siparişler"

  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
  }
}
```

`relationship` parametresi Looker'a toplamaları nasıl işleyeceğini söyler. `one_to_many` ilişkisi, çift sayımı önlemek için ölçünün "bir" tarafında toplaması gerektiği anlamına gelir. Bunu yanlış yapmak hatalı toplamlara neden olur — mülakatlarda sık karşılaşılan bir hata ayıklama senaryosu.

Simetrik toplamalar fanout sorununu otomatik olarak çözer. Farklı granülaritelere sahip tabloları birleştirirken, Looker birleştirmeden önce ölçüleri doğru seviyede hesaplayan SQL üretir.

## Karmaşık Dönüşümler için Türetilmiş Tablolar

Türetilmiş tablolar, SQL sorgularından veya LookML tanımlı toplamalardan sanal tablolar oluşturur. Native türetilmiş tablolar LookML sözdizimi kullanır; SQL türetilmiş tablolar ham SQL gömer.

```lookml
# 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` parametresi, Looker'ın türetilmiş tabloyu ne zaman yeniden oluşturacağını kontrol eder — genellikle upstream ETL tamamlandıktan sonra. Kalıcı türetilmiş tablolar (PDT'ler) veritabanında somutlaşır ve depolamayı sorgu hızı için takas eder.

Mülakatçılar PDT yeniden oluşturma stratejileri hakkında soru sorar. `sql_trigger_value` parametresi bir SQL sorgusu çalıştırır; sonuç değiştiğinde Looker PDT'yi yeniden oluşturur. Yaygın bir kalıp `SELECT MAX(updated_at) FROM source_table` kullanır.

## Looker Mülakat Soruları: Model Tasarımı

Looker rolleri için teknik mülakatlar ağırlıklı olarak LookML modelleme kararlarına odaklanır. Bu sorular, adayların esneklik ve performans arasındaki ödünleşimleri anlayıp anlamadığını değerlendirir.

**Soru: Birden fazla tarih boyutu olan bir fact tablosunu nasıl modellersiniz?**

Cevap, ayrı boyut grupları oluşturmayı ve birleştirmeleri açıkça adlandırmayı içerir:

```lookml
# 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) ;;
  }
}
```

**Soru: PDT'yi dbt modeli yerine ne zaman kullanırsınız?**

PDT'ler, modelle birlikte değişen Looker'a özgü toplamalar için iyi çalışır. [dbt](https://docs.getdbt.com/docs/introduction) dönüşümleri, birden fazla araç tarafından tüketilen paylaşılan veri kümeleri için uygundur. [dbt + Looker entegrasyonu](https://cloud.google.com/looker/docs/db-config-dbt) kalıbı, ağır dönüşümler için dbt ve son mil metrikleri için PDT'ler kullanır.

**Soru: LookML'de yavaş değişen boyutları nasıl işlersiniz?**

Tip 2 SCD tabloları geçerli kayda filtreleme gerektirir. Satırları filtreleyen bir boyut ekleyin ve explore'da `always_filter` kullanın:

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

# Explore'da
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"]
  }
}
```

## Dinamik Modeller için Liquid Şablonlama

Liquid şablonlama, LookML tanımlarında koşullu mantığı etkinleştirir. Kullanıcı özellikleri, filtre değerleri ve izinler üretilen SQL'i değiştirebilir.

```lookml
# 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 %}
    ;;
  }
}
```

Kullanıcı özellikleri satır düzeyinde güvenlik ve dinamik tablo seçimini yönlendirir. `_user_attributes` nesnesi, Looker yönetici panelinde atanan değerlere erişim sağlar.

`html` parametresi, değerlerin tablolarda ve görselleştirmelerde nasıl işlendiğini özelleştirir — mülakat eve götürme projelerinde sıkça görülen koşullu biçimlendirme.

## Performans Optimizasyonu Kalıpları

Looker, LookML tanımlarından SQL üretir. Optimizasyon, hem model katmanını hem de temel veritabanını anlamayı gerektirir.

**Toplama farkındalığı** yaygın toplamaları farklı granülarite seviyelerinde önceden hesaplar:

```lookml
# 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, sorguları isteği karşılayan en küçük toplama tablosuna otomatik olarak yönlendirir. Aylık bir pano sorgusu, tüm fact tablosunu taramak yerine `monthly_orders`'dan okur.

Bağlantı düzeyindeki ayarlar performansı önemli ölçüde etkiler. BigQuery bağlantıları [sorgu önbelleğini](https://cloud.google.com/bigquery/docs/cached-results) etkinleştirmeli ve uygun zaman aşımları ayarlamalıdır. `max_connections` parametresi eşzamanlı sorgu yuvalarını kontrol eder.

Mülakatlara hazırlanan veri analistleri için, [SQL pencere fonksiyonları rehberi](/blog/data-analytics/sql-window-functions-ctes-advanced-queries) LookML modelleme becerilerini tamamlayan sorgu kalıplarını kapsar.

## Erişim Kontrolleri ve İçerik Yönetimi

Satır düzeyinde güvenlik, model izinleri ve içerik organizasyonu, kıdemli seviye Looker mülakatlarında karşımıza çıkar. access_grant mekanizması özellik kullanılabilirliğini kontrol eder:

```lookml
# 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` kullanıcı özelliklerine dayalı olarak dinamik WHERE cümleleri ekler. Bir satış müdürü yalnızca kendi bölgesinin verilerini görür. `required_access_grants` parametresi, belirtilen izne sahip olmayan kullanıcılardan boyutları gizler.

İçerik organizasyonu bir klasör hiyerarşisi izler. Üretim panoları paylaşılan alanlarda bulunur; geliştirme çalışmaları doğrulanana kadar kişisel klasörlerde kalır. LookML doğrulayıcı, dağıtımdan önce sözdizimi hatalarını yakalar.

## Kaçınılması Gereken Yaygın Mülakat Hataları

Teknik Looker mülakatları yaygın yanlış anlamaları ortaya çıkarır:

**Yanlış ilişki bildirimleri** metrik şişmesine neden olur. `one_to_many` birleştirmede `one_to_one` ilişkisi yanlış toplamlar üretir. Her zaman `SELECT COUNT(*), COUNT(DISTINCT key)` sorgularıyla kardinaliteyi doğrulayın.

**Native türetilmiş tablolar yerine SQL türetilmiş tablolara aşırı güvenmek.** Native türetilmiş tablolar Looker'ın bağımlılık izlemesiyle entegre olur; SQL türetilmiş tablolar manuel yönetim gerektirir.

**Datagroup önbelleğini görmezden gelmek.** Uygun önbellek geçersiz kılma olmadan panolar eski verileri gösterir. ETL zamanlamalarıyla uyumlu datagroup'lar tanımlayın ve bunları explore'lara atayın.

Veri modelleme ve analitik kavramları hakkında kapsamlı mülakat hazırlığı için, [veri analitiği mülakat soruları rehberi](/blog/data-analytics/data-analytics-interview-questions-2026) Looker'a özgü bilginin ötesinde daha geniş konuları kapsar.

## Sonuç

Looker mülakatlarında başarılı olmak, hem LookML sözdizimi bilgisi hem de semantik katman mimarisinin organizasyonlara neden fayda sağladığını anlama göstermeyi gerektirir:

- LookML views boyutları ve ölçüleri tanımlar; explores views'ları açık ilişki türleriyle bildirilmiş birleştirmeler aracılığıyla birleştirir
- Türetilmiş tablolar karmaşık dönüşümleri somutlaştırır; datagroup'lar önbellek geçersiz kılma ve PDT yeniden oluşturma zamanlamalarını kontrol eder
- Liquid şablonlama, kullanıcı özelliklerine ve filtre seçimlerine dayalı dinamik SQL üretimi sağlar
- Toplama farkındalığı metrikleri birden fazla granülarite düzeyinde önceden hesaplar ve sorguları otomatik olarak optimal tabloya yönlendirir
- Erişim kontrolleri satır düzeyinde filtreler, erişim izinleri ve içerik izinlerini yönetilen self-servis için birleştirir
- Performans optimizasyonu LookML kalıplarını veritabanına özgü ayarlama ile (BigQuery yuvaları, Snowflake ambarları) uyumlu hale getirmeyi gerektirir

Mülakatlardan önce örnek veri kümeleri üzerinde LookML modelleri oluşturma pratiği yapın. [BigQuery genel veri kümeleri](https://cloud.google.com/bigquery/public-data) modelleme alıştırmaları için gerçekçi şemalar sağlar.

---

Source: SharpSkill (https://sharpskill.dev), tech interview preparation for your real stack.
HTML version of this page: https://sharpskill.dev/tr/blog/data-analytics/looker-lookml-business-intelligence-interview-2026