Looker y LookML en 2026: Guía Completa de Business Intelligence y Preguntas de Entrevista
Domina Looker y LookML para entrevistas de data analyst. Esta guía cubre conceptos fundamentales, mejores prácticas de modelado y las preguntas de entrevista de Business Intelligence más frecuentes en 2026.

La demanda de profesionales que dominan Looker y LookML continúa creciendo en 2026. Con la integración de Google Cloud y las nuevas funcionalidades de inteligencia artificial, Looker se consolida como una plataforma esencial de Business Intelligence. Esta guía completa prepara a los candidatos para entrevistas técnicas mientras ofrece una base sólida para los analistas en ejercicio.
Looker se diferencia de otras herramientas BI por su enfoque "modeling layer first". Comprender LookML antes de explorar la interfaz permite captar la filosofía de la plataforma y responder eficazmente a las preguntas de entrevista.
Comprendiendo la Arquitectura de Looker
Looker funciona sobre una arquitectura única que separa la capa semántica de la visualización. Este enfoque permite a los equipos definir una única fuente de verdad para las métricas, evitando inconsistencias entre reportes.
La arquitectura se compone de tres capas principales:
- La capa de datos: conexión directa a data warehouses (BigQuery, Snowflake, Redshift)
- La capa semántica: definiciones LookML que modelan relaciones y cálculos
- La capa de presentación: Explores, Looks y Dashboards para usuarios finales
# Ejemplo de conexión en looker.ini
[database]
host: your-project.region.bigquery.googleapis.com
port: 443
ssl: true
database: your_dataset
schema: analyticsFundamentos de LookML
LookML utiliza una sintaxis declarativa para definir modelos de datos. Los cuatro elementos fundamentales son los projects, models, views y explores.
Estructura de un Proyecto LookML
Cada proyecto contiene archivos organizados jerárquicamente. Las convenciones de nomenclatura y la estructura de carpetas facilitan el mantenimiento a largo plazo.
# 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
}
}Definición de Views
Las views representan tablas o consultas derivadas. Cada view contiene dimensiones y medidas que definen cómo se pueden analizar los datos.
# 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 Avanzadas de Modelado
Las entrevistas técnicas frecuentemente evalúan la capacidad de resolver problemas complejos de modelado. Las derived tables y los parámetros dinámicos son temas recurrentes.
Derived Tables y PDTs
Las derived tables permiten crear tablas intermedias para optimizar el rendimiento o simplificar consultas complejas.
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 y Filtros Templados
Los parámetros permiten a los usuarios controlar dinámicamente las consultas SQL generadas.
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 %}
;;
}
}Preguntas Comunes de Entrevista Looker
Los reclutadores evalúan la comprensión teórica y práctica de los candidatos. Esta sección presenta las preguntas más frecuentes con respuestas detalladas.
Pregunta: ¿Cuál es la diferencia entre una dimensión y una medida?
Las dimensiones son atributos cualitativos utilizados para agrupar o filtrar datos (categorías, fechas, identificadores). Las medidas son cálculos agregados sobre los datos (sumas, promedios, conteos). Una dimensión corresponde a una columna en un GROUP BY, mientras que una medida aplica una función de agregación.
Pregunta: ¿Cómo optimizar el rendimiento de un Explore lento?
Varias estrategias permiten mejorar el rendimiento:
# 1. Usar PDTs para pre-agregar datos
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 los scans
explore: large_transactions {
always_filter: {
filters: [created_date: "last 90 days"]
}
}
# 3. Usar sql_always_where para restricciones permanentes
explore: active_customers {
sql_always_where: ${customers.status} = 'active' ;;
}Pregunta: Explique los diferentes tipos de joins en LookML
Looker soporta cuatro tipos de uniones con implicaciones en rendimiento y resultados:
explore: orders {
# LEFT OUTER: mantiene todos los registros de orders
join: customers {
type: left_outer
sql_on: ${orders.customer_id} = ${customers.id} ;;
relationship: many_to_one
}
# INNER: únicamente las coincidencias
join: payments {
type: inner
sql_on: ${orders.id} = ${payments.order_id} ;;
relationship: one_to_many
}
# FULL OUTER: todos los registros de ambas tablas
join: returns {
type: full_outer
sql_on: ${orders.id} = ${returns.order_id} ;;
relationship: one_to_one
}
# CROSS: producto cartesiano (raramente utilizado)
join: date_spine {
type: cross
relationship: many_to_many
}
}¿Listo para aprobar tus entrevistas de Data Analytics?
Practica con nuestros simuladores interactivos, flashcards y tests técnicos.
Mejores Prácticas de Desarrollo LookML
Los equipos de alto rendimiento adoptan convenciones y prácticas que facilitan la colaboración y el mantenimiento del código.
Organización del Código
# Estructura recomendada para un proyecto 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 reutilización
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 ;;
}Gestión de Versiones y Tests
Looker se integra con Git para control de versiones. Los tests de datos validan la coherencia de las definiciones.
# Tests de validación de datos
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} ;;
}
}Integración con el Ecosistema Google Cloud
Desde la adquisición por Google, Looker se integra profundamente con los servicios GCP. Esta sinergia ofrece ventajas significativas para las empresas que utilizan BigQuery.
# Uso de BigQuery ML directamente en 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
}
}
# Conexión optimizada para BigQuery
# Looker utiliza sesiones BigQuery para reducir costos
connection: "bigquery_optimized" {
host: "bigquery.googleapis.com"
maximum_billing_gigabytes: 100
query_timeout: 3600
}Preparación para Entrevistas Técnicas
Los candidatos deben demostrar su capacidad para resolver problemas concretos. Los siguientes ejercicios prácticos representan escenarios típicos de entrevista.
Ejercicio: Modelar un Análisis de Cohortes
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
}
}Conclusión
El dominio de Looker y LookML representa una ventaja competitiva significativa para los profesionales de datos en 2026. El enfoque único de Looker, centrado en la capa semántica, permite crear análisis reproducibles y confiables. Los candidatos que comprenden la arquitectura subyacente, dominan las técnicas de modelado avanzadas y conocen las mejores prácticas de desarrollo se destacan en las entrevistas técnicas. La práctica regular con proyectos concretos sigue siendo la mejor forma de consolidar estas habilidades y prepararse para los desafíos del rol de analista BI.
Etiquetas
Compartir
Artículos relacionados

Apache Superset en 2026: dashboards, SQL Lab y preguntas de entrevista
Análisis a fondo de Apache Superset: cómo construir dashboards de análisis de datos, SQL Lab y las plantillas Jinja, cómo se compara con Tableau y las preguntas de entrevista que importan.

Power BI vs Tableau en 2026: Cual Herramienta de BI Conviene Aprender
Comparativa completa entre Power BI y Tableau en 2026. Analisis de precios, capacidades de IA, visualizacion y mercado laboral.

dbt para Analistas de Datos en 2026: Modelado SQL, Testing Automatizado y Preguntas de Entrevista
Guia practica de dbt para analistas de datos: arquitectura de proyectos por capas, materializaciones, testing de calidad, macros Jinja y preguntas de entrevista con ejemplos de codigo reales.