Looker en LookML in 2026: Business Intelligence Gids en Sollicitatievragen

Looker-sollicitatiegesprekken focussen consequent op LookML-modellering, data-exploratieworkflows en hoe de semantische laag bedrijfslogica vertaalt naar herbruikbare definities. Deze tutorial behandelt de kern LookML-concepten, praktische implementatiepatronen en de exacte vragen waar data-analisten mee te maken krijgen tijdens sollicitatiegesprekken voor Looker-gerichte functies in 2026.

De LookML Semantische Laag Begrijpen

LookML fungeert als vertaallaag tussen ruwe databasetabellen en bedrijfsvriendelijke metrieken. In plaats van herhaaldelijk complexe SQL-joins te schrijven, definiëren analisten relaties in modelbestanden die Looker compileert naar geoptimaliseerde queries.

De semantische laag lost drie problemen op waar interviewers regelmatig naar vragen:

• Consistentie: Elke gebruiker ziet dezelfde metriekdefinities
• Herbruikbaarheid: Dimensies en metingen bestaan eenmaal, worden overal gerefereerd
• Governance: Wijzigingen propageren automatisch over alle dashboards

De Looker-documentatie van Google Cloud beschrijft LookML als een "dependency-aware" taal — wanneer één definitie verandert, worden downstream referenties automatisch bijgewerkt. Dit afhankelijkheidsbewustzijn wordt kritiek bij het onderhouden van enterprise-schaal modellen.

LookML Views en Explores: De Bouwstenen

Views definiëren de kolommen die beschikbaar zijn vanuit een enkele tabel of afgeleide tabel. Explores combineren views via joins en stellen ze beschikbaar aan zakelijke gebruikers.

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

De dimension_group-declaratie genereert meerdere tijdgebaseerde dimensies vanuit een enkele timestamp-kolom. Interviewers vragen kandidaten vaak te verklaren waarom dit patroon codeduplicatie vermindert en consistente datumafhandeling in het hele model garandeert.

De drill_fields-parameter definieert wat gebruikers zien wanneer ze op een meetwaarde klikken — een UX-detail dat begrip aantoont van hoe analisten daadwerkelijk met Looker werken.

Joins en Relaties in LookML

Explores definiëren hoe views verbinden via SQL-joins. Het jointype en de relatiedeclaratie hebben directe impact op queryprestaties en aggregatienauwkeurigheid.

# models/ecommerce.model.lkml
explore: orders {
  label: "Orderanalyse"
  description: "Alle orders met klant- en productdetails"

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

De relationship-parameter vertelt Looker hoe aggregaties behandeld moeten worden. Een one_to_many-relatie betekent dat de meting aan de "één"-kant geaggregeerd moet worden om dubbeltelling te voorkomen. Een verkeerde configuratie veroorzaakt incorrecte totalen — een veelvoorkomend debuggingscenario in interviews.

Symmetrische aggregaten lossen het fanout-probleem automatisch op. Bij het joinen van tabellen met verschillende granulariteiten genereert Looker SQL die metingen op het correcte niveau berekent voordat gejoind wordt.

Afgeleide Tabellen voor Complexe Transformaties

Afgeleide tabellen creëren virtuele tabellen vanuit SQL-queries of LookML-gedefinieerde aggregaties. Native afgeleide tabellen gebruiken LookML-syntax; SQL-afgeleide tabellen embedden ruwe SQL.

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

De datagroup_trigger bepaalt wanneer Looker de afgeleide tabel herbouwt — typisch nadat de upstream ETL is voltooid. Persistente afgeleide tabellen (PDTs) materialiseren in de database, waarbij opslagruimte wordt geruild voor querysnelheid.

Interviewers vragen naar PDT-herbouwstrategieën. De sql_trigger_value-parameter voert een SQL-query uit; wanneer het resultaat verandert, herbouwt Looker de PDT. Een veelgebruikt patroon gebruikt SELECT MAX(updated_at) FROM source_table.

Looker Sollicitatievragen: Modelontwerp

Technische interviews voor Looker-functies focussen sterk op LookML-modelleringsbeslissingen. Deze vragen beoordelen of kandidaten de afwegingen tussen flexibiliteit en prestaties begrijpen.

Vraag: Hoe zou je een feitentabel met meerdere datumdimensies modelleren?

Het antwoord omvat het maken van aparte dimensiegroepen en expliciet benoemen van de 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) ;;
  }
}

Vraag: Wanneer zou je een PDT gebruiken versus een dbt-model?

PDTs werken goed voor Looker-specifieke aggregaties die veranderen met het model. dbt-transformaties zijn geschikt voor gedeelde datasets die door meerdere tools worden geconsumeerd. Het dbt + Looker-integratie-patroon gebruikt dbt voor zware transformaties en PDTs voor last-mile metrieken.

Vraag: Hoe ga je om met langzaam veranderende dimensies in LookML?

Type 2 SCD-tabellen vereisen filtering op de huidige record. Een dimensie toevoegen die rijen filtert en always_filter gebruiken in de explore:

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

# In de 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 voor Dynamische Modellen

Liquid-templating maakt conditionele logica mogelijk in LookML-definities. Gebruikersattributen, filterwaarden en permissies kunnen de gegenereerde SQL wijzigen.

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

Gebruikersattributen sturen row-level security en dynamische tabelselectie aan. Het _user_attributes-object geeft toegang tot waarden die in het Looker-adminpaneel zijn toegewezen.

De html-parameter past aan hoe waarden worden gerenderd in tabellen en visualisaties — conditionele opmaak die vaak voorkomt in interview take-home projecten.

Prestatieoptimalisatiepatronen

Looker genereert SQL vanuit LookML-definities. Optimalisatie vereist begrip van zowel de modellaag als de onderliggende database.

Aggregate awareness berekent veelvoorkomende aggregaties op verschillende granulariteitsniveaus vooraf:

# 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 routeert queries automatisch naar de kleinste aggregaattabel die aan het verzoek voldoet. Een maandelijkse dashboardquery leest van monthly_orders in plaats van de hele feitentabel te scannen.

Verbindingsniveau-instellingen beïnvloeden de prestaties aanzienlijk. BigQuery-verbindingen moeten query-caching inschakelen en geschikte timeouts instellen. De max_connections-parameter bepaalt het aantal gelijktijdige queryslots.

Voor data-analisten die zich voorbereiden op interviews, behandelt de SQL Window Functions-gids querypatronen die LookML-modelleringsvaardigheden aanvullen.

Toegangscontroles en Contentbeheer

Row-level security, modelpermissies en contentorganisatie komen voor in senior-level Looker-interviews. Het access_grant-mechanisme bepaalt de beschikbaarheid van functies:

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

De access_filter voegt dynamisch WHERE-clausules toe op basis van gebruikersattributen. Een salesmanager ziet alleen de data van zijn regio. De required_access_grants-parameter verbergt dimensies voor gebruikers die de opgegeven grant niet hebben.

Contentorganisatie volgt een mappenhiërarchie. Productiedashboards bevinden zich in gedeelde spaces; ontwikkelwerk blijft in persoonlijke mappen totdat het is gevalideerd. De LookML-validator vangt syntaxfouten op vóór deployment.

Veelvoorkomende Interviewfouten Vermijden

Technische Looker-interviews onthullen veelvoorkomende misvattingen:

Incorrecte relatiedeclaraties veroorzaken metriekinflatie. Een one_to_one-relatie op een one_to_many-join produceert verkeerde aggregaten. Verifieer kardinaliteit altijd met SELECT COUNT(*), COUNT(DISTINCT key)-queries.

Te veel vertrouwen op SQL-afgeleide tabellen in plaats van native afgeleide tabellen. Native afgeleide tabellen integreren met Lookers dependency-tracking; SQL-afgeleide tabellen vereisen handmatig beheer.

Datagroup-caching negeren. Zonder goede cache-invalidatie tonen dashboards verouderde data. Definieer datagroups die aansluiten bij ETL-schema's en wijs ze toe aan explores.

Voor uitgebreide interviewvoorbereiding over datamodellering en analytics-concepten behandelt de Data Analytics Interview Questions-gids bredere onderwerpen dan alleen Looker-specifieke kennis.

Conclusie

Succes in Looker-interviews vereist het demonstreren van zowel LookML-syntaxkennis als begrip van waarom de semantische laagarchitectuur organisaties ten goede komt:

• LookML-views definiëren dimensies en metingen; explores combineren views via gedeclareerde joins met expliciete relatietypen
• Afgeleide tabellen materialiseren complexe transformaties; datagroups bepalen cache-invalidatie en PDT-herbouwschema's
• Liquid-templating maakt dynamische SQL-generatie mogelijk op basis van gebruikersattributen en filterselecties
• Aggregate awareness berekent metrieken vooraf op meerdere granulariteiten en routeert queries automatisch naar de optimale tabel
• Toegangscontroles combineren row-level filters, access grants en contentpermissies voor beheerde self-service
• Prestatieoptimalisatie vereist afstemming van LookML-patronen met databasespecifieke tuning (BigQuery-slots, Snowflake-warehouses)

Oefen het bouwen van LookML-modellen tegen voorbeelddatasets vóór interviews. De BigQuery Public Datasets bieden realistische schema's voor modelleringsoefeningen.