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

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.

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 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.

# 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.

# 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.

# 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:

# 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 dönüşümleri, birden fazla araç tarafından tüketilen paylaşılan veri kümeleri için uygundur. dbt + Looker entegrasyonu 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:

# 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.

# 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:

# 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 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 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:

# 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 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 modelleme alıştırmaları için gerçekçi şemalar sağlar.