Looker und LookML 2026: Business Intelligence Leitfaden und Interview-Fragen

Looker-Interviews konzentrieren sich konsequent auf LookML-Modellierung, Datenexplorations-Workflows und die Art und Weise, wie die semantische Schicht Geschäftslogik in wiederverwendbare Definitionen übersetzt. Dieses Tutorial behandelt die grundlegenden LookML-Konzepte, praktische Implementierungsmuster und die typischen Fragen, denen Datenanalysten bei Vorstellungsgesprächen für Looker-fokussierte Positionen im Jahr 2026 begegnen.

Die LookML Semantische Schicht verstehen

LookML fungiert als Übersetzungsschicht zwischen rohen Datenbanktabellen und geschäftsfreundlichen Metriken. Anstatt wiederholt komplexe SQL-Joins zu schreiben, definieren Analysten Beziehungen in Modelldateien, die Looker zu optimierten Abfragen kompiliert.

Die semantische Schicht löst drei Probleme, nach denen Interviewer häufig fragen:

• Konsistenz: Jeder Benutzer sieht dieselben Metrikdefinitionen
• Wiederverwendbarkeit: Dimensionen und Kennzahlen existieren einmal, werden überall referenziert
• Governance: Änderungen propagieren automatisch über alle Dashboards

Die Looker-Dokumentation von Google Cloud beschreibt LookML als eine "abhängigkeitsbewusste" Sprache – wenn sich eine Definition ändert, aktualisieren sich nachgelagerte Referenzen automatisch. Dieses Abhängigkeitsbewusstsein wird bei der Pflege von Enterprise-Modellen kritisch.

LookML Views und Explores: Die Bausteine

Views definieren die verfügbaren Spalten aus einer einzelnen Tabelle oder abgeleiteten Tabelle. Explores kombinieren Views durch Joins und stellen sie Geschäftsanwendern zur Verfügung.

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

Die dimension_group-Deklaration generiert mehrere zeitbasierte Dimensionen aus einer einzelnen Zeitstempel-Spalte. Interviewer fragen Kandidaten oft, warum dieses Muster Code-Duplizierung reduziert und eine konsistente Datumsverarbeitung im gesamten Modell gewährleistet.

Der drill_fields-Parameter definiert, was Benutzer sehen, wenn sie auf einen Kennzahlenwert klicken – ein UX-Detail, das das Verständnis davon demonstriert, wie Analysten tatsächlich mit Looker interagieren.

Joins und Beziehungen in LookML

Explores definieren, wie sich Views durch SQL-Joins verbinden. Der Join-Typ und die Beziehungsdeklaration wirken sich direkt auf die Abfrageleistung und Aggregationsgenauigkeit aus.

# models/ecommerce.model.lkml
explore: orders {
  label: "Bestellungsanalyse"
  description: "Alle Bestellungen mit Kunden- und Produktdetails"

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

Der relationship-Parameter teilt Looker mit, wie Aggregationen gehandhabt werden sollen. Eine one_to_many-Beziehung bedeutet, dass die Kennzahl auf der "einen" Seite aggregiert werden sollte, um Doppelzählungen zu vermeiden. Eine falsche Konfiguration verursacht inkorrekte Summen – ein häufiges Debugging-Szenario in Interviews.

Symmetrische Aggregate lösen das Fanout-Problem automatisch. Beim Joinen von Tabellen mit unterschiedlichen Granularitäten generiert Looker SQL, das Kennzahlen auf der korrekten Ebene berechnet, bevor gejoint wird.

Abgeleitete Tabellen für komplexe Transformationen

Abgeleitete Tabellen erstellen virtuelle Tabellen aus SQL-Abfragen oder LookML-definierten Aggregationen. Native abgeleitete Tabellen verwenden LookML-Syntax; SQL-abgeleitete Tabellen betten rohes SQL ein.

# 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 ;;
  }
}

Der datagroup_trigger steuert, wann Looker die abgeleitete Tabelle neu aufbaut – typischerweise nachdem die vorgelagerte ETL abgeschlossen ist. Persistente abgeleitete Tabellen (PDTs) materialisieren in der Datenbank und tauschen Speicherplatz gegen Abfragegeschwindigkeit.

Interviewer fragen nach PDT-Neuaufbau-Strategien. Der sql_trigger_value-Parameter führt eine SQL-Abfrage aus; wenn sich das Ergebnis ändert, baut Looker die PDT neu auf. Ein gängiges Muster verwendet SELECT MAX(updated_at) FROM source_table.

Looker Interview-Fragen: Modell-Design

Technische Interviews für Looker-Positionen konzentrieren sich stark auf LookML-Modellierungsentscheidungen. Diese Fragen bewerten, ob Kandidaten die Abwägungen zwischen Flexibilität und Performance verstehen.

Frage: Wie würden Sie eine Faktentabelle mit mehreren Datumsdimensionen modellieren?

Die Antwort beinhaltet das Erstellen separater Dimensionsgruppen und explizites Benennen der Joins:

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

Frage: Wann würden Sie eine PDT anstelle eines dbt-Modells verwenden?

PDTs funktionieren gut für Looker-spezifische Aggregationen, die sich mit dem Modell ändern. dbt-Transformationen eignen sich für gemeinsam genutzte Datensätze, die von mehreren Tools konsumiert werden. Das dbt + Looker-Integrations-Muster verwendet dbt für schwere Transformationen und PDTs für Last-Mile-Metriken.

Frage: Wie handhaben Sie langsam ändernde Dimensionen in LookML?

Typ-2-SCD-Tabellen erfordern eine Filterung auf den aktuellen Datensatz. Eine Dimension hinzufügen, die Zeilen filtert, und always_filter im Explore verwenden:

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

# Im 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 für dynamische Modelle

Liquid-Templating ermöglicht bedingte Logik in LookML-Definitionen. Benutzerattribute, Filterwerte und Berechtigungen können das generierte SQL modifizieren.

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

Benutzerattribute steuern Row-Level-Security und dynamische Tabellenauswahl. Das _user_attributes-Objekt bietet Zugriff auf Werte, die im Looker-Admin-Panel zugewiesen wurden.

Der html-Parameter passt an, wie Werte in Tabellen und Visualisierungen gerendert werden – bedingte Formatierung, die häufig in Interview-Take-Home-Projekten erscheint.

Performance-Optimierungsmuster

Looker generiert SQL aus LookML-Definitionen. Optimierung erfordert das Verständnis sowohl der Modellschicht als auch der zugrunde liegenden Datenbank.

Aggregate Awareness berechnet häufige Aggregationen auf verschiedenen Granularitätsebenen vor:

# 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 leitet Abfragen automatisch an die kleinste Aggregattabelle weiter, die die Anforderung erfüllt. Eine monatliche Dashboard-Abfrage liest aus monthly_orders anstatt die gesamte Faktentabelle zu scannen.

Verbindungsebenen-Einstellungen beeinflussen die Leistung erheblich. BigQuery-Verbindungen sollten Query-Caching aktivieren und geeignete Timeouts setzen. Der max_connections-Parameter steuert gleichzeitige Abfrage-Slots.

Für Datenanalysten, die sich auf Interviews vorbereiten, behandelt der SQL Window Functions Guide Abfragemuster, die LookML-Modellierungsfähigkeiten ergänzen.

Zugriffskontrollen und Content-Management

Row-Level-Security, Modellberechtigungen und Content-Organisation erscheinen in Interviews für Senior-Level Looker-Positionen. Der access_grant-Mechanismus kontrolliert Feature-Verfügbarkeit:

# 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]
  }
}

Der access_filter fügt dynamisch WHERE-Klauseln basierend auf Benutzerattributen hinzu. Ein Vertriebsleiter sieht nur die Daten seiner Region. Der required_access_grants-Parameter verbirgt Dimensionen vor Benutzern, denen der spezifizierte Grant fehlt.

Die Content-Organisation folgt einer Ordnerhierarchie. Produktions-Dashboards befinden sich in gemeinsamen Spaces; Entwicklungsarbeit bleibt in persönlichen Ordnern, bis sie validiert ist. Der LookML-Validator fängt Syntaxfehler vor dem Deployment ab.

Häufige Interview-Fehler vermeiden

Technische Looker-Interviews offenbaren häufige Missverständnisse:

Falsche Beziehungsdeklarationen verursachen Metrik-Inflation. Eine one_to_one-Beziehung bei einem one_to_many-Join produziert falsche Aggregate. Die Kardinalität immer mit SELECT COUNT(*), COUNT(DISTINCT key)-Abfragen verifizieren.

Übermäßiges Verlassen auf SQL-abgeleitete Tabellen anstelle von nativen Derivaten. Native abgeleitete Tabellen integrieren sich in Lookers Abhängigkeitsverfolgung; SQL-abgeleitete Tabellen erfordern manuelle Verwaltung.

Ignorieren von Datagroup-Caching. Ohne ordnungsgemäße Cache-Invalidierung zeigen Dashboards veraltete Daten. Datagroups definieren, die mit ETL-Zeitplänen übereinstimmen, und sie Explores zuweisen.

Für eine umfassende Interview-Vorbereitung zu Datenmodellierungs- und Analysekonzepten behandelt der Data Analytics Interview Questions Guide breitere Themen jenseits von Looker-spezifischem Wissen.

Fazit

Erfolg in Looker-Interviews erfordert die Demonstration sowohl von LookML-Syntax-Kenntnissen als auch des Verständnisses, warum die semantische Schicht-Architektur Organisationen nutzt:

• LookML-Views definieren Dimensionen und Kennzahlen; Explores kombinieren Views durch deklarierte Joins mit expliziten Beziehungstypen
• Abgeleitete Tabellen materialisieren komplexe Transformationen; Datagroups steuern Cache-Invalidierung und PDT-Neuaufbau-Zeitpläne
• Liquid-Templating ermöglicht dynamische SQL-Generierung basierend auf Benutzerattributen und Filterauswahlen
• Aggregate Awareness berechnet Metriken auf mehreren Granularitäten vor und leitet Abfragen automatisch zur optimalen Tabelle
• Zugriffskontrollen kombinieren Row-Level-Filter, Access Grants und Content-Berechtigungen für gesteuerten Self-Service
• Performance-Optimierung erfordert die Abstimmung von LookML-Mustern mit datenbankspezifischem Tuning (BigQuery-Slots, Snowflake-Warehouses)

Vor Interviews das Erstellen von LookML-Modellen gegen Beispieldatensätze üben. Die BigQuery Public Datasets bieten realistische Schemas für Modellierungsübungen.