Looker e LookML em 2026: Guia Completo de Business Intelligence e Perguntas de Entrevista
Domine Looker e LookML para entrevistas de data analyst. Este guia aborda conceitos fundamentais, melhores práticas de modelagem e as perguntas de entrevista de Business Intelligence mais frequentes em 2026.

A demanda por profissionais que dominam Looker e LookML continua crescendo em 2026. Com a integração ao Google Cloud e as novas funcionalidades de inteligência artificial, o Looker se consolida como uma plataforma essencial de Business Intelligence. Este guia completo prepara candidatos para entrevistas técnicas enquanto oferece uma base sólida para analistas em atividade.
O Looker se diferencia de outras ferramentas de BI pela abordagem "modeling layer first". Compreender o LookML antes de explorar a interface permite captar a filosofia da plataforma e responder eficazmente às perguntas de entrevista.
Compreendendo a Arquitetura do Looker
O Looker funciona sobre uma arquitetura única que separa a camada semântica da visualização. Essa abordagem permite que equipes definam uma única fonte de verdade para as métricas, evitando inconsistências entre relatórios.
A arquitetura é composta por três camadas principais:
- Camada de dados: conexão direta com data warehouses (BigQuery, Snowflake, Redshift)
- Camada semântica: definições LookML que modelam relacionamentos e cálculos
- Camada de apresentação: Explores, Looks e Dashboards para usuários finais
# Exemplo de conexão em looker.ini
[database]
host: your-project.region.bigquery.googleapis.com
port: 443
ssl: true
database: your_dataset
schema: analyticsFundamentos do LookML
O LookML utiliza uma sintaxe declarativa para definir modelos de dados. Os quatro elementos fundamentais são projects, models, views e explores.
Estrutura de um Projeto LookML
Cada projeto contém arquivos organizados hierarquicamente. As convenções de nomenclatura e a estrutura de pastas facilitam a manutenção a longo prazo.
# model: ecommerce.model.lkml
connection: "bigquery_production"
include: "/views/**/*.view.lkml"
include: "/explores/**/*.explore.lkml"
explore: orders {
label: "Sales Analysis"
description: "Explore orders with customer and product details"
join: customers {
type: left_outer
sql_on: ${orders.customer_id} = ${customers.id} ;;
relationship: many_to_one
}
join: products {
type: left_outer
sql_on: ${order_items.product_id} = ${products.id} ;;
relationship: many_to_one
}
}Definição de Views
As views representam tabelas ou consultas derivadas. Cada view contém dimensões e medidas que definem como os dados podem ser analisados.
# view: orders.view.lkml
view: orders {
sql_table_name: `analytics.orders` ;;
dimension: 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 ;;
}
dimension: total_amount {
type: number
sql: ${TABLE}.total_amount ;;
value_format_name: usd
}
measure: count {
type: count
drill_fields: [id, created_date, status, total_amount]
}
measure: total_revenue {
type: sum
sql: ${total_amount} ;;
value_format_name: usd
}
measure: average_order_value {
type: average
sql: ${total_amount} ;;
value_format_name: usd
}
}Técnicas Avançadas de Modelagem
As entrevistas técnicas frequentemente avaliam a capacidade de resolver problemas complexos de modelagem. As derived tables e os parâmetros dinâmicos são temas recorrentes.
Derived Tables e PDTs
As derived tables permitem criar tabelas intermediárias para otimizar o desempenho ou simplificar consultas complexas.
view: daily_sales_summary {
derived_table: {
sql:
SELECT
DATE(created_at) as sale_date,
COUNT(DISTINCT order_id) as order_count,
SUM(total_amount) as daily_revenue,
COUNT(DISTINCT customer_id) as unique_customers
FROM ${orders.SQL_TABLE_NAME}
WHERE status = 'completed'
GROUP BY 1
;;
datagroup_trigger: daily_refresh
indexes: ["sale_date"]
}
dimension: sale_date {
type: date
sql: ${TABLE}.sale_date ;;
}
measure: total_orders {
type: sum
sql: ${TABLE}.order_count ;;
}
measure: revenue {
type: sum
sql: ${TABLE}.daily_revenue ;;
value_format_name: usd
}
}Parâmetros e Filtros Templados
Os parâmetros permitem que usuários controlem dinamicamente as consultas SQL geradas.
view: orders_with_params {
parameter: date_granularity {
type: unquoted
allowed_values: {
label: "Day"
value: "day"
}
allowed_values: {
label: "Week"
value: "week"
}
allowed_values: {
label: "Month"
value: "month"
}
}
dimension: dynamic_date {
type: string
sql:
{% if date_granularity._parameter_value == 'day' %}
DATE(${created_raw})
{% elsif date_granularity._parameter_value == 'week' %}
DATE_TRUNC(${created_raw}, WEEK)
{% else %}
DATE_TRUNC(${created_raw}, MONTH)
{% endif %}
;;
}
}Perguntas Comuns de Entrevista Looker
Os recrutadores avaliam a compreensão teórica e prática dos candidatos. Esta seção apresenta as perguntas mais frequentes com respostas detalhadas.
Pergunta: Qual é a diferença entre uma dimensão e uma medida?
As dimensões são atributos qualitativos utilizados para agrupar ou filtrar dados (categorias, datas, identificadores). As medidas são cálculos agregados sobre os dados (somas, médias, contagens). Uma dimensão corresponde a uma coluna em um GROUP BY, enquanto uma medida aplica uma função de agregação.
Pergunta: Como otimizar o desempenho de um Explore lento?
Várias estratégias permitem melhorar o desempenho:
# 1. Usar PDTs para pré-agregar dados
view: monthly_metrics {
derived_table: {
sql:
SELECT
DATE_TRUNC(created_at, MONTH) as month,
category,
SUM(revenue) as total_revenue
FROM orders
GROUP BY 1, 2
;;
datagroup_trigger: monthly_refresh
indexes: ["month", "category"]
}
}
# 2. Implementar always_filter para limitar os scans
explore: large_transactions {
always_filter: {
filters: [created_date: "last 90 days"]
}
}
# 3. Usar sql_always_where para restrições permanentes
explore: active_customers {
sql_always_where: ${customers.status} = 'active' ;;
}Pergunta: Explique os diferentes tipos de joins em LookML
O Looker suporta quatro tipos de junções com implicações em desempenho e resultados:
explore: orders {
# LEFT OUTER: mantém todos os registros de orders
join: customers {
type: left_outer
sql_on: ${orders.customer_id} = ${customers.id} ;;
relationship: many_to_one
}
# INNER: apenas as correspondências
join: payments {
type: inner
sql_on: ${orders.id} = ${payments.order_id} ;;
relationship: one_to_many
}
# FULL OUTER: todos os registros de ambas as tabelas
join: returns {
type: full_outer
sql_on: ${orders.id} = ${returns.order_id} ;;
relationship: one_to_one
}
# CROSS: produto cartesiano (raramente utilizado)
join: date_spine {
type: cross
relationship: many_to_many
}
}Pronto para mandar bem nas entrevistas de Data Analytics?
Pratique com nossos simuladores interativos, flashcards e testes tecnicos.
Melhores Práticas de Desenvolvimento LookML
As equipes de alto desempenho adotam convenções e práticas que facilitam a colaboração e a manutenção do código.
Organização do Código
# Estrutura recomendada para um projeto empresarial
# /models
# └── ecommerce.model.lkml
# /views
# └── /core
# ├── orders.view.lkml
# ├── customers.view.lkml
# └── products.view.lkml
# └── /derived
# └── daily_summary.view.lkml
# /explores
# └── sales.explore.lkml
# /dashboards
# └── executive_summary.dashboard.lookml
# Uso de extends para reutilização
view: base_order_metrics {
extension: required
measure: total_revenue {
type: sum
sql: ${amount} ;;
}
measure: order_count {
type: count_distinct
sql: ${id} ;;
}
}
view: orders {
extends: [base_order_metrics]
sql_table_name: analytics.orders ;;
}Gestão de Versões e Testes
O Looker se integra com Git para controle de versões. Os testes de dados validam a coerência das definições.
# Testes de validação de dados
test: orders_have_positive_amounts {
explore_source: orders {
column: order_count { field: orders.count }
filters: [orders.total_amount: "<0"]
}
assert: order_count {
expression: ${orders.count} = 0 ;;
}
}
test: customer_ids_are_unique {
explore_source: customers {
column: duplicate_count {
field: customers.count
}
column: id_count {
field: customers.id_count
}
}
assert: no_duplicates {
expression: ${duplicate_count} = ${id_count} ;;
}
}Integração com o Ecossistema Google Cloud
Desde a aquisição pelo Google, o Looker se integra profundamente com os serviços GCP. Essa sinergia oferece vantagens significativas para empresas que utilizam BigQuery.
# Uso de BigQuery ML diretamente em LookML
view: customer_predictions {
derived_table: {
sql:
SELECT
customer_id,
predicted_ltv,
predicted_churn_probability
FROM ML.PREDICT(
MODEL `project.dataset.customer_ltv_model`,
(SELECT * FROM ${customers.SQL_TABLE_NAME})
)
;;
datagroup_trigger: weekly_predictions
}
}
# Conexão otimizada para BigQuery
# Looker utiliza sessões BigQuery para reduzir custos
connection: "bigquery_optimized" {
host: "bigquery.googleapis.com"
maximum_billing_gigabytes: 100
query_timeout: 3600
}Preparação para Entrevistas Técnicas
Os candidatos devem demonstrar capacidade de resolver problemas concretos. Os exercícios práticos a seguir representam cenários típicos de entrevista.
Exercício: Modelar uma Análise de Coortes
view: cohort_analysis {
derived_table: {
sql:
WITH first_purchase AS (
SELECT
customer_id,
DATE_TRUNC(MIN(created_at), MONTH) as cohort_month
FROM ${orders.SQL_TABLE_NAME}
GROUP BY 1
)
SELECT
fp.cohort_month,
DATE_DIFF(
DATE_TRUNC(o.created_at, MONTH),
fp.cohort_month,
MONTH
) as months_since_first,
COUNT(DISTINCT o.customer_id) as customers,
SUM(o.total_amount) as revenue
FROM ${orders.SQL_TABLE_NAME} o
JOIN first_purchase fp ON o.customer_id = fp.customer_id
GROUP BY 1, 2
;;
datagroup_trigger: daily_refresh
}
dimension: cohort_month {
type: date
sql: ${TABLE}.cohort_month ;;
}
dimension: months_since_first {
type: number
sql: ${TABLE}.months_since_first ;;
}
measure: customer_count {
type: sum
sql: ${TABLE}.customers ;;
}
measure: cohort_revenue {
type: sum
sql: ${TABLE}.revenue ;;
value_format_name: usd
}
}Conclusão
O domínio de Looker e LookML representa uma vantagem competitiva significativa para profissionais de dados em 2026. A abordagem única do Looker, centrada na camada semântica, permite criar análises reproduzíveis e confiáveis. Os candidatos que compreendem a arquitetura subjacente, dominam as técnicas de modelagem avançadas e conhecem as melhores práticas de desenvolvimento se destacam nas entrevistas técnicas. A prática regular com projetos concretos continua sendo a melhor forma de consolidar essas habilidades e se preparar para os desafios do papel de analista de BI.
Tags
Compartilhar
Artigos relacionados

Apache Superset em 2026: Dashboards, SQL Lab e Perguntas de Entrevista
Um mergulho profundo no Apache Superset: como construir dashboards de data analytics, SQL Lab e templates Jinja, como ele se compara ao Tableau e as perguntas de entrevista que importam.

Power BI vs Tableau em 2026: Qual Ferramenta de BI Aprender?
Comparativo completo entre Power BI e Tableau em 2026. Preços, recursos de IA, visualizações e mercado de trabalho.

dbt para Analistas de Dados em 2026: Modelagem SQL, Testes Automatizados e Perguntas de Entrevista
Guia completo de dbt para analistas de dados: estrutura de projeto em camadas, materializacoes, testes de qualidade, macros Jinja e perguntas frequentes em entrevistas tecnicas com exemplos praticos.