Looker — LookML, Explores, Dashboards, Persistencia, Seguridad, API y Operación

Q1. ¿Qué es Looker y cómo se diferencia de otras herramientas de BI?

Looker es la plataforma de BI y modelado semántico de Google Cloud. Se diferencia porque el modelo vive en LookML (código versionado) y las consultas se ejecutan en el data warehouse, no en un motor propio. Eso ofrece una definición única de las métricas para dashboards, entregas, embeds y API, con gobierno centralizado y escalabilidad. Frente a herramientas de descubrimiento autoservicio, exige un equipo que modele; a cambio reduce la ambigüedad de métricas y el retrabajo. Se usa para analítica empresarial, analítica embebida y aplicaciones internas de datos.

Q2. ¿Qué es LookML y por qué es importante?

LookML es el lenguaje declarativo de Looker para definir modelos, vistas, explores, dimensiones, medidas, joins y políticas. Es código: se versiona en Git, se revisa en pull requests, se promueve entre entornos y se valida. Describe qué significa un campo y cómo se calcula en SQL, no solo una consulta puntual. Beneficios: reutilización, consistencia, testeo y auditoría. Es la fuente de verdad del semantic layer: los usuarios ven nombres de negocio y no tablas crudas.

Q3. ¿Qué significa que Looker tenga arquitectura in-database?

Significa que Looker traduce el modelo y la consulta a SQL nativo y lo ejecuta en el warehouse (BigQuery, Snowflake, Redshift, etc.). Looker no almacena los datos: solo metadatos, caché y PDTs. Ventajas: se aprovecha el motor y el gobierno del warehouse, no se duplica la data y se escala con el compute. Implicaciones: el rendimiento y el costo dependen del warehouse; se necesitan permisos de base de datos y un esquema temporal para PDTs; la latencia incluye la ejecución SQL.

Q4. ¿Looker y Looker Studio son lo mismo?

No. Looker es la plataforma empresarial con LookML, semantic layer, gobierno, embedding y API; Looker Studio es una herramienta de visualización y reporting autoservicio (antes Data Studio) que se conecta a fuentes y se usa para dashboards ágiles, con menos modelado central. Looker Studio Pro añade gobierno y colaboración de Google Cloud. Se complementan: Looker para métricas gobernadas y aplicaciones; Looker Studio para reportes departamentales o prototipos. No comparten LookML.

Q5. ¿Cómo es el ciclo de vida de una consulta en Looker?

El usuario abre un explore y elige campos y filtros; Looker valida el LookML, genera SQL con los joins y agregaciones necesarios, aplica seguridad (access filters, user attributes) y lo envía al warehouse; el warehouse ejecuta y devuelve filas; Looker aplica table calculations, formato y visualización; el resultado se cachea según la política. Si hay PDTs, primero se materializan o se reutilizan según el datagroup. Finalmente la consulta se registra en System Activity para auditoría y análisis de rendimiento.

Q6. ¿Qué es el semantic layer y qué problemas resuelve?

Es una capa que define métricas, dimensiones, relaciones y reglas de negocio una sola vez, de forma reutilizable y gobernada. Evita que cada analista recalcule «ventas» o «cliente activo» con SQL distinto. En Looker se implementa con LookML: nombres, descripciones, tipos, agregaciones, joins y seguridad. Beneficios: consistencia, menor tiempo de desarrollo, autoservicio seguro, auditoría y una API común para dashboards, embeds y herramientas externas.

Q7. ¿Qué tipos de contenido se crean en Looker?

Los principales son Looks (una consulta y visualización guardada), dashboards (colección de tiles, filtros y textos), explores (interfaz de consulta sobre un modelo), PDTs (tablas persistidas), alerts y scheduled deliveries (entregas programadas), y experiencias embedded o aplicaciones. Los usuarios guardan contenido en carpetas, lo comparten y lo programan. Los developers crean modelos, vistas y explores; los usuarios de negocio consumen y exploran dentro de los límites del modelo.

Q8. ¿Qué roles y responsabilidades existen en un proyecto Looker?

Roles típicos: administrador (usuarios, conexiones, seguridad, releases), developer de LookML (modelado, Git, rendimiento), analytics engineer (semantic layer y calidad de datos), analista/BI developer (dashboards y Looks), data steward u owner de métricas (definiciones y certificación) y usuario de negocio (autoservicio). En equipos pequeños se combinan. La separación de responsabilidades importa: quien modela no debería aprobar producción sin revisión, y el acceso a conexiones y credenciales debe ser restringido.

Q9. ¿Cómo se conecta Looker a un data warehouse?

Se configura una conexión en Looker Admin con el dialecto del warehouse, host o proyecto, base de datos, credenciales y esquema temporal. Looker usa esa conexión para todas las consultas del modelo. Debe tener permisos de lectura sobre las tablas y de escritura/creación en el esquema temporal (scratch) para PDTs. Las credenciales pueden ser una cuenta de servicio, OAuth o un usuario de base de datos; se recomienda una cuenta dedicada, con mínimo privilegio y rotación. La conexión se prueba y se monitorea.

Q10. ¿Qué dialectos y consideraciones de conexión existen?

Looker soporta BigQuery, Snowflake, Redshift, Synapse/SQL Server, PostgreSQL, MySQL, Databricks, Trino/Presto, Oracle y otros. Consideraciones: método de autenticación (service account, key pair, OAuth, IAM), host/región, proyecto/dataset o base de datos, costo y almacenamiento del esquema temporal, límites de concurrencia y timeouts. En BigQuery se suele usar una service account con permisos de lectura y de job user; en Snowflake, un warehouse y rol dedicados. Validar dialecto, driver y versión antes de modelar.

Q11. ¿Cómo se asegura la conectividad de red?

En Looker hospedado por Google, el tráfico a un warehouse privado requiere Private IP/Private Service Connect, VPC peering o allowlists, según el proveedor. En customer-hosted, Looker se despliega en la VPC del cliente y se controlan red, cifrado y acceso. Además se restringen IPs de salida, se usa TLS y se revisan reglas de firewall y DNS privado. Para BigQuery se usa Private Google Access o PSC. Documentar rangos y probar la conectividad desde la instancia, no solo desde una laptop.

Q12. ¿Cómo se estructura un proyecto LookML?

Un proyecto es la unidad de desarrollo versionada en Git y contiene archivos .model.lkml, .view.lkml, .explore.lkml, dashboards LookML, el manifiesto y documentación. El manifest.lkml declara el proyecto y constantes; los include traen archivos; el modelo define conexión, datagroups, explores y vistas; las vistas definen campos. Se organiza por dominio (ventas, finanzas), con nombres claros, carpetas y un README. El proyecto se valida en el IDE y se despliega a producción desde Git.

Q13. ¿Cómo se gestionan los entornos de desarrollo y producción?

Looker separa Development Mode y Production. En Development cada developer trabaja en su rama con cambios aislados; en Production se sirve a los usuarios la versión desplegada. Se promueve mediante commit, revisión y deploy del proyecto o modelo a producción. Los usuarios no ven cambios sin desplegar. Las PDTs y la caché se comportan distinto en cada entorno. Un buen flujo incluye validación, pruebas y aprobación antes del deploy.

Q14. ¿Cómo se integra Looker con Git y qué flujo de ramas se usa?

Looker se integra con GitHub, GitLab, Bitbucket o Azure DevOps a nivel de proyecto. Flujo recomendado: rama feature desde main, commits pequeños, pull request con revisión y validación de LookML, merge a main y deploy a producción desde main. Proteger main, exigir revisión y checks. Evitar editar directamente en producción o hacer force push. El historial de Git es la auditoría del modelo; cada cambio debe tener descripción y contexto. Para un hotfix, rama corta y revisión expresa.

Q15. ¿Qué es el esquema temporal y para qué sirve?

Looker necesita un esquema temporal (scratch/temp schema) en el warehouse para PDTs, tablas temporales y algunos procesos. El usuario de la conexión debe poder crear y borrar objetos allí. Se configura por conexión, con retención y limpieza. No debe ser un esquema de producción ni compartirse con otras aplicaciones. El connection pooling administra conexiones concurrentes a la base y se ajusta según los límites del warehouse. Monitorear espacio y permisos del scratch evita fallos de PDTs.

Q16. ¿Looker hospedado por Google o customer-hosted?

Looker hospedado por Google es gestionado por el proveedor: infraestructura, parches y releases; el cliente configura conexiones, red y seguridad. Customer-hosted se instala en la nube o VPC del cliente y este opera la instancia, versiones y backups. Implicaciones: costo, control, cumplimiento, latencia, esfuerzo operativo y responsabilidad de actualizaciones. En ambos casos hay que gestionar usuarios, conexiones, proyectos, releases y monitoreo. La elección depende de requisitos regulatorios, red y equipo de plataforma.

Q17. ¿Qué es un model y qué contiene?

Un model es el archivo que define una conexión y agrupa explores, vistas, datagroups y reglas. Declara connection, include, explore, datagroup, access_grant, etc. Puede haber varios modelos (ventas, marketing) para separar dominios y permisos. El model set controla qué modelos ve cada rol. Un modelo bien diseñado expone solo los explores necesarios, con nombres de negocio y documentación; no es un volcado de todas las tablas.

Q18. ¿Qué es una view y cómo se define?

Una view representa una tabla o consulta y define sus campos: dimensiones, medidas, dimension_groups, sets, parámetros, filtros y tests. Se declara con view: nombre { sql_table_name: ... } o con SQL derivado. Cada campo tiene nombre, tipo, SQL, etiqueta y descripción. La view es reutilizable en varios explores y debe tener una clave primaria para que funcionen bien los symmetric aggregates y los joins. Convención: una view por tabla lógica, con nombres en snake_case.

Q19. ¿Qué es un explore y cómo se relaciona con las views?

Un explore es la interfaz de consulta que ve el usuario: define la view base, los joins permitidos, filtros, orden, límites y campos expuestos. Se declara con explore: ventas { from: view_ventas; join: ... }. Los usuarios eligen dimensiones y medidas y Looker genera SQL. Un explore debe responder a un caso de uso concreto (ventas por cliente, inventario); demasiados joins o campos lo vuelven lento y confuso. Se agrupan por modelo y se controlan con model sets.

Q20. ¿Qué es una dimension y qué tipos existen?

Una dimension es un atributo descriptivo o una expresión que se agrupa o filtra: texto, número, fecha, booleano, tier. Tipos comunes: string, number, yesno, date, date_time, time, tier, duration, location. Se define con dimension: nombre { type: string; sql: ${TABLE}.columna;; }. Puede ser calculada con SQL, CASE, concat, etc. Debe tener label y descripción; los tipos correctos habilitan filtros, formatos y drills adecuados. Las dimensiones no se agregan.

Q21. ¿Qué es una measure y qué tipos principales existen?

Una measure es una métrica agregada: count, count_distinct, sum, average, min, max, median, percentile, list, sum_distinct, average_distinct, percent_of_total, running_total. Se define con measure: total_ventas { type: sum; sql: ${TABLE}.monto;; }. La elección depende de la pregunta y del grano; sumar ratios o promedios de promedios es un error clásico. Las measures se calculan en el warehouse y se benefician de symmetric aggregates. Documentar la definición y la fuente es clave para la confianza.

Q22. ¿Qué son los dimension_group y para qué sirven?

Un dimension_group agrupa dimensiones de fecha u hora derivadas de una sola columna: date, week, month, quarter, year, day_of_week, hour, etc. Se define con dimension_group: created { type: time; timeframes: [date, week, month, quarter, year]; sql: ${TABLE}.created_at;; }. Evita duplicar campos y estandariza el análisis temporal. Se pueden añadir timeframes personalizados y convert_tz. Cuidado con zonas horarias y con el grano: definir si la fecha es local o UTC.

Q23. ¿Cómo se usan sql, sql_table_name y sql_on?

sql_table_name indica la tabla física de una view; sql define la expresión de un campo; sql_on define la condición de join entre views. Ejemplo: join: clientes { sql_on: ${ventas.cliente_id} = ${clientes.id};; relationship: many_to_one; }. sql_on es flexible para joins complejos; foreign_key es una alternativa declarativa cuando existe una FK. Usar referencias ${view.campo} para que Looker resuelva nombres y dialectos. Evitar SQL hardcodeado específico del dialecto cuando se pueda.

Q24. ¿Qué son include, extends y refinements?

include trae archivos al proyecto (vistas, modelos, dashboards). extends hereda y especializa una view o explore (por ejemplo, una view base y variantes por país). refinements permite modificar una view o explore existente sin editarla, útil para customizaciones por cliente o entorno. Sirven para DRY y reutilización, pero abusar de extends y refinements hace el modelo difícil de seguir: documentar la jerarquía y validar el resultado. Preferir composición clara a cadenas largas de herencia.

Q25. ¿Qué son los parameters y Liquid en LookML?

Los parameters permiten que el usuario elija un valor (por ejemplo, una métrica o una fecha de corte) y se usa en Liquid ({% parameter %}) o en filtros. Liquid permite lógica condicional y variables en LookML ({% if %}, {{ }}). Casos: columnas dinámicas, filtros opcionales, cálculos que cambian según el parámetro. Riesgos: inyección SQL si se interpola entrada no validada, complejidad y planes de consulta variables. Validar valores permitidos (allowed_value) y documentar. No usar Liquid para lógica de negocio que debería ser una measure.

Q26. ¿Cómo funcionan los joins en Looker?

Los joins se declaran dentro de un explore con join: view { sql_on: ...; relationship: ...; type: left_outer; }. Looker genera el SQL con el orden y tipo definidos; por defecto left_outer. La relación debe reflejar la cardinalidad real para que las agregaciones sean correctas. Se pueden limitar campos (fields), añadir required_joins y usar always_join. Los joins innecesarios degradan el rendimiento y pueden duplicar filas; modelar explores por caso de uso y revisar el SQL generado.

Q27. ¿Qué significan las relaciones one_to_one, many_to_one, one_to_many y many_to_many?

one_to_one: una fila de cada lado. many_to_one: muchas filas de la view base apuntan a una de la view unida (por ejemplo, ventas → cliente). one_to_many: una fila base tiene muchas hijas (por ejemplo, pedido → líneas). many_to_many: cardinalidad N:M. La relación correcta es crítica: si se declara mal, Looker puede agregar incorrectamente o duplicar. En muchos casos many_to_one es la relación típica de una dimensión; one_to_many requiere cuidado con medidas y fan-out. Validar con conteos y primary keys.

Q28. ¿Qué es el fan-out y cómo lo resuelve Looker?

Fan-out ocurre cuando un join one_to_many multiplica las filas de la base y una suma se duplica. Looker evita esto con symmetric aggregates: si la view base tiene primary key y la relación está bien declarada, calcula la medida en una subconsulta sobre las claves distintas antes de agregar. Requisitos: primary key en las views involucradas, relación correcta y medidas definidas como agregaciones (no SQL manual que agregue). Si falta la PK o se usa SQL custom, el resultado puede ser incorrecto.

Q29. ¿Qué son los symmetric aggregates y qué requisitos tienen?

Es el mecanismo de Looker para calcular medidas correctamente cuando los joins multiplican filas. Genera subconsultas que agregan por la clave primaria de la view base y luego combinan, en lugar de sumar filas duplicadas. Requiere que cada view tenga primary_key: yes en la dimensión correcta y que las relaciones sean correctas. No aplica si la medida usa SQL agregado manual o si el grano es ambiguo. Es una razón clave para modelar claves y relaciones con cuidado.

Q30. ¿Qué es un chasm trap y cómo se evita?

Un chasm trap ocurre cuando dos joins one_to_many desde una misma base (por ejemplo, ventas con líneas y con pagos) generan un producto cartesiano y duplican métricas. Soluciones: usar explores separados, declarar correctamente la relación, preagregar con derived tables por grano o aplicar aggregate awareness. También ayuda declarar many_to_one cuando corresponda y evitar medir a través de dos ramas one_to_many. Detectar con conteos manuales y comparar totales; documentar el grano de cada explore.

Q31. ¿Cuándo usar foreign_key y cuándo sql_on?

foreign_key es declarativo: indica la columna FK en la view base y Looker infiere la condición con la primary key de la view unida; es simple y legible. sql_on permite condiciones complejas (rangos, múltiples columnas, lógica adicional). Usar foreign_key cuando el join es una FK estándar; sql_on para casos no triviales (fechas entre rangos, claves compuestas, filtros). En ambos, declarar relationship y type. Revisar el SQL generado y el plan del warehouse.

Q32. ¿Qué son required_joins, always_join y los joins condicionales?

required_joins en una view fuerza que ciertos joins se incluyan cuando se usan campos de esa view. always_join en un explore hace que un join se aplique siempre, aunque no se usen sus campos; es útil para filtros de seguridad o deduplicación, pero puede encarecer las consultas. Los joins condicionales con Liquid permiten incluir tablas según parámetros, pero complican el plan y el mantenimiento. Preferir required_joins o always_join solo cuando la semántica lo exige y documentarlo.

Q33. ¿Qué son sql_always_where y conditionally_filter?

sql_always_where aplica una condición fija al explore (por ejemplo, excluir borrados o limitar por seguridad); sql_always_having hace lo análogo sobre agregados. conditionally_filter obliga al usuario a filtrar por un campo si no aplica otro, y evita consultas masivas. access_filter aplica seguridad por user attribute. Los filtros always se combinan con los del usuario y afectan todos los Looks y dashboards; usarlos con cuidado para no sorprender ni degradar el rendimiento. Documentar su efecto.

Q34. ¿Se pueden hacer joins dinámicos con parámetros?

Sí: se puede usar Liquid o un parameter dentro de sql_on para cambiar la condición (por ejemplo, unir por id o por email según el parámetro). Es potente pero riesgoso: el SQL generado varía, el plan puede ser malo, la validación es más difícil y aumentan los errores. Alternativas: crear explores separados, usar una derived table que unifique claves o resolver la lógica aguas arriba (dbt). Si se usa, validar valores permitidos y probar cada variante.

Q35. ¿Cuándo usar una measure y cuándo un table calculation?

Measure: se define en LookML, se calcula en el warehouse, es reutilizable y consistente para todos los usuarios; puede aprovechar symmetric aggregates y aggregate awareness. Table calculation: se calcula en el navegador sobre el resultado de la consulta, es flexible y rápida de crear, pero no es gobernada ni reutilizable y puede ser costosa con muchos datos. Regla: métricas de negocio centrales → measure; análisis ad hoc o cálculos sobre el resultado visible → table calculation. Si un cálculo se repite, moverlo al modelo.

Q36. ¿Qué medidas permiten porcentajes, totales acumulados y listas?

percent_of_total calcula el porcentaje sobre el total del resultado; running_total acumula; list concatena valores; median y percentile devuelven estadísticos; count_distinct cuenta únicos; sum_distinct y average_distinct agregan valores distintos. Se combinan con filtros y granularidad. Cuidado: percent_of_total depende del conjunto de filas y de los filtros; running_total requiere orden. Documentar la semántica y validar contra SQL. Para cálculos muy específicos, evaluar table calculations o una PDT.

Q37. ¿Cómo se crean dimensiones derivadas y tiers?

Los tiers agrupan valores numéricos en rangos (por ejemplo, edad: 0–17, 18–34, 35–54, 55+). Se definen con dimension: rango_edad { type: tier; tiers: [0, 18, 35, 55, 100]; sql: ${TABLE}.edad;; } o con CASE. Las dimensiones derivadas usan SQL: concat, CASE, date_diff, regexp, etc. Mantener la lógica en el modelo para reutilizarla; evitar duplicar CASE en cada dashboard. Probar límites y valores nulos.

Q38. ¿Cómo se implementan parámetros interactivos en LookML?

Un parameter define una opción seleccionable por el usuario; se referencia en Liquid ({% parameter nombre %}) o como filtro. Casos: elegir una columna, un periodo de comparación o un modo de cálculo. Se declaran type, allowed_value y default_value; validar para evitar inyección. Ejemplo: parameter: metrica { type: unquoted; allowed_value: { label: "Ventas" value: "ventas" } }. Para cálculos más complejos, combinar con measures condicionales o PDTs. Documentar y probar cada combinación.

Q39. ¿Qué son las derived tables y cuándo usarlas?

Una derived table es una subconsulta definida en LookML que se usa como una view. Puede ser SQL derived table (escribes el SQL) o native derived table (defines el explore y los campos; Looker genera el SQL). Sirve para preagregar, unir fuentes complejas, aplicar lógica reutilizable o mejorar el rendimiento. Si se persiste, es una PDT. No abusar: cada derived table añade complejidad y puede duplicar lógica. Preferir vistas sobre tablas del warehouse cuando sea posible y documentar el grano.

Q40. ¿Qué es una native derived table y cómo se diferencia de una SQL derived table?

Una NDT se define con derived_table: { explore_source: ...; column: ... } y Looker genera el SQL a partir de un explore existente; es declarativa, reutiliza la lógica del modelo y es más fácil de mantener. Una SQL derived table usa sql: SELECT ... y da control total, pero duplica lógica y dialecto. La NDT es ideal para preagregar métricas gobernadas; la SQL DT para casos que el modelo no cubre. Ambas pueden persistirse con datagroup o persist_for.

Q41. ¿Cómo se formatean valores, etiquetas y descripciones?

value_format_name aplica formatos estándar (usd, eur, percent, decimal, etc.) o value_format con formato custom; label es el nombre visible; description documenta el campo y aparece en el tooltip; group_label agrupa campos en la UI; hidden: yes oculta campos técnicos. Una buena documentación y nombres de negocio mejoran el autoservicio y reducen preguntas. Mantener consistencia de formato por tipo de métrica y revisar que los porcentajes no se muestren como decimales.

Q42. ¿Cómo se implementan campos calculados reutilizables y yesno?

Campos reutilizables: definir dimensiones y measures en la view base y extenderlos; usar extends o refinements para variantes; evitar duplicar SQL. yesno convierte una condición en booleano (por ejemplo, type: yesno; sql: ${TABLE}.activo = 1;;) y se puede usar para filtros y conteos condicionales. Para etiquetas legibles, combinar CASE y html con cuidado. Los cálculos condicionales se pueden expresar como measures con filters o CASE WHEN, manteniendo la lógica centralizada y testeada.

Q43. ¿Cómo se evita duplicar lógica entre explores y dashboards?

Centralizar la lógica en LookML: una definición de métrica, una view por entidad, explores por caso de uso y campos documentados. Reutilizar con extends y refinements, no copiando SQL en cada dashboard. Los dashboards deben usar campos del modelo, no table calculations que redefinan métricas. Para variantes por país o cliente, usar refinements o parámetros controlados. Revisar duplicados con búsquedas de nombres y mantener un glosario de métricas con owner y definición.

Q44. ¿Qué diferencia hay entre un Look y un dashboard?

Un Look es una consulta guardada con una visualización (tabla, gráfico) y sus filtros; es simple y reutilizable. Un dashboard agrupa varios tiles (Looks, queries, texto) con filtros comunes, layout y programación. Los dashboards cuentan una historia y permiten monitorear; los Looks responden una pregunta concreta. Ambos consumen el modelo y heredan su seguridad. Se organizan en carpetas y se comparten con roles o grupos. Para productos embebidos se usan dashboards y Looks vía embed.

Q45. ¿Cómo funcionan los filtros de dashboard?

Los filtros de dashboard se aplican a varios tiles y pueden ser field filters (se mapean a un campo del explore) o filtros por tile. Al cambiar un filtro, Looker reejecuta las consultas afectadas. Los field filters permiten valores sugeridos y condiciones; los filtros de fecha tienen opciones relativas. Diseñar filtros con campos comunes y evitar duplicarlos. Cuidado con filtros que obligan a escanear tablas enormes; usar particiones y valores por defecto razonables.

Q46. ¿Qué es el cross-filtering y cómo se configura?

Cross-filtering permite hacer clic en un valor de un tile (por ejemplo, país) y filtrar los demás tiles del dashboard. Se configura en el tile o la visualización, eligiendo el campo y el comportamiento; requiere que los demás tiles tengan un campo compatible y que el dashboard esté en modo edición. Es potente para exploración, pero puede confundir si no se indica el filtro activo. Documentar y probar; en dashboards muy grandes puede aumentar el número de consultas.

Q47. ¿Qué son los merged results y cuándo usarlos?

Merged results combinan los resultados de dos o más explores en una sola tabla o visualización, uniendo por campos comunes (join en memoria). Sirven cuando las fuentes no se pueden unir en el warehouse o para comparar métricas de modelos distintos. Limitaciones: se ejecutan consultas separadas, el join ocurre en Looker, no hay symmetric aggregates entre ellas y el rendimiento depende del volumen. Para datos grandes, preferir una PDT o una tabla unificada en el warehouse.

Q48. ¿Cómo funcionan los drills y los links?

Los drills permiten navegar desde un valor a otro contenido: ver registros, abrir otro dashboard o Look, o una URL personalizada. Se configuran con drill_fields, link y drill en LookML; los usuarios también pueden crear drills ad hoc si tienen permiso. Los links pueden incluir parámetros y filtros. Son clave para pasar de una métrica a la acción. Cuidado con URLs que expongan información o con links a contenido no gobernado; validar permisos y parámetros.

Q49. ¿Cómo se comparten y programan entregas y alertas?

Las scheduled deliveries envían Looks o dashboards por email, Slack, webhook o almacenamiento, con formato y filtros; las alerts notifican cuando una métrica cruza un umbral. Se configuran por contenido, con destinatarios, frecuencia, zona horaria y condiciones. Requieren permisos y pueden consumir recursos si son muy frecuentes. Monitorear fallos, límites y datos vacíos. Para integraciones, preferir API y webhooks y documentar el contrato; evitar duplicar entregas.

Q50. ¿Cómo se diseñan dashboards performantes y usables?

Una pregunta por dashboard, jerarquía visual clara, títulos y descripciones, filtros necesarios (no todos), valores por defecto útiles, colores consistentes y unidades visibles. Limitar el número de tiles y filas; usar agregaciones y filtros que aprovechen particiones. Probar en el tamaño real y con datos representativos; incluir fecha de actualización y definiciones. Evitar gráficos 3D, exceso de decimales y tablas gigantes. Medir el uso y retirar contenido obsoleto.

Q51. ¿Qué son los dashboards definidos por el usuario y los LookML dashboards?

Los user-defined dashboards se crean en la UI, son editables por usuarios con permiso y viven como contenido. Los LookML dashboards se definen en archivos .dashboard.lkml (o en el modelo) y se versionan y despliegan con el proyecto. Los LookML dashboards son útiles para contenido estándar, embebido o reproducible; los user-defined para autoservicio. Ambos pueden compartirse y programarse. Elegir según gobierno y ciclo de vida; no duplicar el mismo dashboard en ambos formatos.

Q52. ¿Cómo se gobierna el contenido y se evita la proliferación de dashboards?

Carpetas y convenciones de nombres, ownership, certificación de dashboards y Looks, revisión antes de publicar, descripciones y fecha de actualización, y limpieza periódica del contenido sin uso (System Activity). Evitar que cada usuario cree su versión de la misma métrica; ofrecer un catálogo de dashboards aprobados y un proceso para solicitar cambios. Roles y grupos controlan la edición. La proliferación se combate con autoservicio gobernado, no solo con restricciones.

Q53. ¿Qué es una PDT y cuándo usarla?

Una PDT (persistent derived table) es una derived table materializada en el warehouse (esquema temporal o tabla persistente) que se reutiliza entre consultas y usuarios. Se usa para preagregar, unir fuentes costosas, aplicar lógica compleja o mejorar la latencia. Se define en una view con derived_table y un trigger (datagroup_trigger, sql_trigger_value o persist_for). Beneficios: rendimiento y consistencia; costos: almacenamiento, tiempo de rebuild y complejidad. No reemplaza un buen modelo de datos.

Q54. ¿Cómo se decide cuándo refrescar una PDT?

El refresco se controla con persist_for (tiempo desde la creación), datagroup_trigger (un datagroup con sql_trigger y max_cache_age) o sql_trigger_value (consulta que devuelve un valor; si cambia, se reconstruye). Elegir según la fuente: si hay un updated_at fiable, usar trigger; si no, datagroup por tiempo. Evitar persist_for muy corto (rebuilods constantes) o muy largo (datos obsoletos). Monitorear fallos y duración; alinear con el SLA de datos.

Q55. ¿Qué es un datagroup?

Un datagroup agrupa políticas de caché y refresco para PDTs y consultas. Se define en el modelo con datagroup: nombre { sql_trigger: SELECT max(updated_at) FROM ...;; max_cache_age: "1 hour" }; las PDTs lo referencian con datagroup_trigger. Si el trigger cambia o se supera max_cache_age, se invalida. Permite coordinar varias PDTs y evitar reconstrucciones innecesarias. Debe basarse en una fuente fiable y barata; documentar la frecuencia y el impacto.

Q56. ¿Qué son las PDTs incrementales?

Las PDTs incrementales solo procesan datos nuevos o modificados, en lugar de reconstruir todo. Se configuran con incremental: yes, increment_key (columna de fecha o ID) e incremental_start; Looker inserta o actualiza según la clave. Requieren que la fuente tenga una marca fiable y que el SQL sea idempotente para el rango. No sirven para cambios retroactivos o borrados sin lógica adicional. Reducen costo y tiempo en tablas grandes, pero añaden complejidad y riesgo de duplicados; probar y monitorear.

Q57. ¿Cómo funciona la caché de consultas y cómo se controla?

Looker cachea resultados de consultas para acelerar y reducir costo. La política se define por datagroup (max_cache_age) o por configuración de la conexión o del explore; también hay caché de PDTs. Un cambio en el modelo o un deploy invalida caché; los usuarios pueden forzar refresh si tienen permiso. La caché no debe ocultar la frescura: documentar el SLA y usar datagroups alineados. En dashboards muy consultados, la caché y las PDTs bien diseñadas son la diferencia de costo y latencia.

Q58. ¿Qué es aggregate awareness y cómo mejora el rendimiento?

Aggregate awareness permite que Looker use una tabla agregada (aggregate_table) cuando la consulta coincide con sus dimensiones y medidas, en lugar de escanear la tabla base. Se define con aggregate_table y materialization en la view, con dimensiones, medidas y claves. Looker reescribe la consulta si puede; si no, usa la base. Reduce costo y latencia en exploraciones repetidas. Requiere mantener la tabla y sus agregaciones, validar que los resultados coincidan y que las políticas de acceso se respeten.

Q59. ¿Cómo se diagnostican consultas lentas en Looker?

Revisar System Activity (Query History, Performance, User Activity) para ver consultas lentas, usuarios, explores y patrones; usar el SQL Runner para ejecutar el SQL generado y el EXPLAIN o plan del warehouse; comparar con la misma consulta fuera de Looker. Revisar joins innecesarios, filtros no aplicados, PDTs desactualizadas, falta de particiones o clustering y cálculos en el navegador. Medir antes y después; priorizar por impacto y costo. Documentar hallazgos y cerrar el ciclo con cambios en el modelo.

Q60. ¿Qué buenas prácticas de modelado y SQL mejoran el rendimiento?

Modelado: una view por entidad, claves primarias, relaciones correctas, evitar joins one_to_many innecesarios y usar symmetric aggregates. SQL: filtrar por particiones, evitar SELECT *, limitar columnas, preagregar con PDTs o aggregate tables, usar WHERE en lugar de filtros posteriores cuando sea posible y revisar funciones no deterministas. UI: limitar filas, usar filtros por defecto y evitar table calculations costosas. Medir con System Activity y con el plan del warehouse.

Q61. ¿Cómo afectan las particiones, el clustering y BI Engine?

Particiones y clustering reducen el escaneo: en BigQuery, particionar por fecha y agrupar por columnas de filtro; en Snowflake, clustering keys; en Redshift, sort/dist keys. Looker debe generar filtros que permitan pruning (por ejemplo, filtros de fecha sobre la columna particionada). BI Engine acelera consultas en BigQuery para ciertos patrones, pero no sustituye un buen modelo. Revisar el plan y el costo por query; coordinar el modelado con el equipo de datos.

Q62. ¿Qué métodos de autenticación soporta Looker?

Looker soporta Google OAuth, SAML 2.0, LDAP, OIDC y autenticación embebida con SSO (JWT). La elección depende del IdP y del caso: SAML u OIDC para SSO corporativo, Google OAuth para Workspace, LDAP para directorios existentes, embed SSO para usuarios externos. Configurar MFA en el IdP, mapear grupos y atributos y definir roles. Mantener una cuenta de admin de emergencia y revisar el aprovisionamiento y desaprovisionamiento. La autenticación no sustituye la autorización por roles y model sets.

Q63. ¿Cómo funcionan roles, permisos y model sets?

Los roles agrupan permisos (ver, crear o editar contenido, administrar usuarios, conexiones, etc.); los model sets definen qué modelos ve un rol. Se asignan roles a usuarios o grupos; el principio es mínimo privilegio. Roles comunes: Admin, Developer y User; se pueden crear roles personalizados combinando permisos. Revisar periódicamente quién tiene Admin y acceso a conexiones. La separación entre desarrollo y producción también se refleja en permisos. Documentar la matriz rol-permiso y auditarla.

Q64. ¿Qué son los grupos y cómo se usan para administrar acceso?

Los grupos (de Looker o del IdP sincronizados) simplifican la administración: se asignan roles, model sets, carpetas y acceso a contenido al grupo, no usuario por usuario. Se sincronizan vía SAML, OIDC o API. Buenas prácticas: grupos por función o equipo, nombres claros, owner, revisión periódica y evitar grupos gigantes con privilegios amplios. Los grupos también se usan en access filters y user attributes. La gestión por grupos reduce errores y facilita altas y bajas.

Q65. ¿Qué son los user attributes?

Son pares clave-valor asociados a usuarios o grupos que LookML puede usar para seguridad y personalización: región, país, departamento, cliente, idioma. Se referencian en access_filter, sql_always_where, Liquid y embed. Se pueden definir a nivel de usuario o grupo y sincronizar desde el IdP. Son la base de row-level security y de experiencias personalizadas. Cuidado con valores no confiables y con la consistencia entre atributos y datos.

Q66. ¿Cómo se implementa row-level security con access filters?

Definir un access_filter en el explore que compare un campo con un user attribute, por ejemplo access_filter: { field: ventas.pais user_attribute: pais }. Looker añade la condición a toda consulta del usuario, incluidos dashboards y API. Alternativas: sql_always_where con Liquid o conditionally_filter. Requiere atributos poblados y consistentes; probar con usuarios de prueba y auditar. No confundir con permisos de contenido: el access filter protege filas aunque el usuario vea el dashboard.

Q67. ¿Cómo se ocultan campos o explores (field-level security)?

Ocultar campos con hidden: yes (no accesibles en la UI, pero cuidado con la API), restringir explores y campos con required_access_grants y access grants, o usar fields en joins para limitar lo expuesto. Para ocultar datos sensibles, es mejor no exponer el campo o aplicar una medida segura; hidden no es un control de seguridad fuerte si el usuario tiene API. Combinar con permisos, model sets y auditoría. Probar que un usuario sin acceso no pueda consultar el campo ni el explore.

Q68. ¿Cómo se protege la conexión a la base de datos?

La conexión debe usar una cuenta de servicio dedicada con permisos mínimos: lectura de las tablas necesarias, escritura en el scratch schema y nada más. Rotar credenciales, almacenarlas de forma segura (no en Git), restringir quién puede ver o editar la conexión (Admin) y usar redes privadas y TLS. En el warehouse, aplicar roles y row policies adicionales si existen. Revisar logs de acceso y queries. La seguridad de Looker no reemplaza la del warehouse: ambas capas deben alinearse.

Q69. ¿Qué auditoría y monitoreo de accesos ofrece Looker?

System Activity ofrece historial de consultas, accesos a contenido, usuarios, dashboards y rendimiento; los audit logs de la plataforma o de Google Cloud registran eventos administrativos y de autenticación; la API permite extraer datos. Configurar retención y monitoreo de accesos anómalos, cambios de permisos y consultas costosas. Revisar quién exporta datos y a dónde. Para cumplimiento, documentar controles y evidencias. Las alertas de uso y costo complementan la revisión periódica.

Q70. ¿Qué ofrece la API de Looker y cómo se autentica?

La API REST de Looker (API 4.0) permite administrar usuarios, grupos, roles, conexiones, proyectos, contenido y ejecutar consultas. Autenticación: API keys (client_id y client_secret) u OAuth; para integraciones se recomienda una cuenta de servicio con permisos mínimos y rotación. Los SDKs oficiales (Python, JavaScript, etc.) y el API Explorer facilitan el desarrollo. Respetar los rate limits, manejar errores y versionar el cliente. La API es la base de automatizaciones, embeds y CI/CD.

Q71. ¿Cómo se ejecutan consultas, Looks y dashboards vía API?

Flujo típico: create_query define la consulta (modelo, explore, campos, filtros, sorts, limit); run_query la ejecuta y devuelve resultados; run_inline_query ejecuta una consulta ad hoc sin guardarla; para consultas largas, create_query_task y polling. run_look ejecuta un Look guardado; run_dashboard o run_dashboard_element para dashboards. Usar el result_format adecuado (json, csv, etc.), manejar paginación y cachear cuando aplique. Respetar los permisos del usuario o de la API key.

Q72. ¿Qué es el Embed SDK y cómo funciona el signed embedding?

El Embed SDK permite insertar dashboards, Looks y explores en una aplicación propia con controles (filtros, navegación, eventos). El signed embedding genera una URL firmada con el secreto de embed, con parámetros y tiempo de expiración; el SSO embed usa JWT para autenticar al usuario y pasar atributos. Se configura el dominio permitido, los permisos de embed y los user attributes. Es ideal para productizar analítica; requiere gestionar sesiones, seguridad y experiencia. Probar expiración y aislamiento.

Q73. ¿Cómo se implementa SSO embed y qué atributos se pasan?

La aplicación genera un JWT firmado con el embed secret que incluye usuario, permisos, modelos, user attributes y expiración; Looker valida la firma y crea la sesión. Se usa para usuarios externos sin cuenta Looker. Hay que sincronizar altas y bajas, limitar atributos y validar el dominio. El token no debe exponerse ni reutilizarse indefinidamente. Combinar con access filters para row-level security. Documentar el flujo y rotar el secreto.

Q74. ¿Qué es el Extension Framework y cuándo usarlo?

El Extension Framework permite construir aplicaciones y extensiones dentro de Looker con React y TypeScript, usando la API y componentes de Looker. Sirve para workflows personalizados, herramientas internas y experiencias integradas. Se despliega como un proyecto de extensión y se controla con permisos. Alternativas: una app externa con Embed SDK y API. Elegir según dónde vive la experiencia y el gobierno. Requiere desarrollo frontend y mantenimiento; no es necesario para dashboards estándar.

Q75. ¿Cómo se automatizan entregas, alertas y webhooks?

Entregas: schedules de Looks y dashboards por email, Slack, webhook o almacenamiento, con filtros y formato. Alertas: condiciones sobre métricas con notificación. Webhooks: Looker puede llamar a un endpoint ante eventos (por ejemplo, un schedule o una query) según configuración; también se puede orquestar con la API. Para integraciones robustas, usar colas, reintentos e idempotencia. Documentar destinatarios, frecuencia y manejo de fallos; evitar bucles y cargas excesivas.

Q76. ¿Cómo se integra Looker con CI/CD y testing?

El proyecto vive en Git; se trabaja en ramas, se valida LookML en el IDE o vía API y se revisa en un pull request. Al mergear, se despliega a producción (manual o automatizado con la API) y se ejecuta el Content Validator para detectar referencias rotas. Se pueden correr tests de datos y validaciones de campos. Para automatizar, usar la API o el SDK desde GitHub Actions o GitLab CI con credenciales mínimas; promover el mismo commit. Monitorear el deploy y tener rollback (revertir commit y redeploy).

Q77. ¿Cómo se integra Looker con orquestadores y herramientas de datos?

Orquestadores como Airflow, dbt Cloud o Cloud Composer pueden refrescar PDTs o disparar consultas vía API; dbt construye tablas y Looker modela encima. Reverse ETL y activación suelen hacerse con herramientas externas que consumen la API o el warehouse. Para eventos, webhooks. Definir contratos, credenciales, límites y monitoreo. Evitar que Looker sea el orquestador principal de pipelines; su rol es semantic layer y consumo. Coordinar horarios de refresh con las PDTs y los SLA.

Q78. ¿Cómo se monitorea el uso y la adopción de Looker?

System Activity y los dashboards de Usage muestran usuarios activos, consultas, contenido más visto, adopción por grupo, errores y rendimiento. Se complementa con auditoría y encuestas. Definir KPIs de adopción (usuarios activos, explores usados, dashboards certificados, tiempo de respuesta) y revisarlos mensualmente. Identificar contenido sin uso para retirarlo y oportunidades de formación. La adopción no es solo número de logins: importa el uso recurrente y la confianza en las métricas.

Q79. ¿Cómo se administra una instancia de Looker?

Gestionar usuarios, grupos y roles, conexiones, proyectos, schedules, alerts, API keys y ajustes de la instancia. Revisar releases y mantenimiento (Looker hospedado sigue un calendario; customer-hosted requiere planificar upgrades), backups y configuración, límites de consulta y cuotas. Monitorear salud, latencia y errores. Documentar runbooks para altas y bajas, incidentes y cambios. Mantener una instancia de desarrollo o pruebas para validar releases y cambios de modelo.

Q80. ¿Cómo se controlan los costos en Looker y el warehouse?

Costos: licencias y edición, usuarios y, sobre todo, el warehouse (bytes escaneados, slots, créditos). Medir consultas costosas en System Activity, usar caché, datagroups, PDTs y aggregate awareness, particiones y clustering, limitar filas y evitar exploraciones masivas. Revisar schedules y alertas frecuentes y dashboards con muchas queries. Etiquetar cargas en el warehouse para allocation. Optimizar no es solo Looker: el modelo de datos y las tablas del warehouse importan. Revisar costo por equipo y por caso de uso.

Q81. ¿Cómo se migra de otra herramienta de BI a Looker?

Inventariar reportes, métricas, fuentes y usuarios; definir el modelo semántico y el glosario; priorizar casos de alto valor; construir LookML (vistas, explores, medidas), validar contra los reportes originales, migrar contenido y capacitar. Ejecutar en paralelo y comparar resultados; documentar diferencias. Planificar permisos, embeds y entregas. Evitar replicar el desorden de la herramienta anterior: aprovechar para estandarizar métricas y retirar reportes obsoletos. Trabajar por fases con hitos y feedback.

Q82. ¿Cómo se migra entre Looker Studio y Looker?

De Looker Studio a Looker: Looker Studio es autoservicio y visual; Looker requiere modelado LookML y gobierno. Migrar implica reconstruir fuentes y modelo, no solo copiar dashboards; priorizar métricas gobernadas y casos empresariales. De Looker a Looker Studio: es útil para reportes simples o prototipos, pero se pierde el semantic layer y parte del gobierno. Pueden convivir: Looker como fuente de métricas gobernadas (API o export) y Looker Studio para presentación. Definir el estándar y evitar duplicidad.

Q83. ¿Cómo se gobiernan los datos y se documenta el modelo?

Glosario de métricas con definición, owner, fuente y fórmula; descripciones en LookML; convenciones de nombres; revisión de cambios; certificación de contenido; control de acceso por grupos y atributos; auditoría. Mantener un catálogo de explores y dashboards y un proceso para nuevas métricas. Documentar limitaciones y frescura. La documentación debe vivir cerca del modelo (LookML) y actualizarse con el código, no en un documento aparte desactualizado.

Q84. ¿Cuáles son los antipatrones más comunes en Looker?

Un explore gigante con todos los joins; duplicar métricas en table calculations; no declarar primary keys ni relaciones; usar SQL manual agregado y romper symmetric aggregates; PDTs sin trigger o con refresh excesivo; campos sin documentación; acceso Admin para todos; usar hidden como única seguridad; contenido duplicado; schedules masivos; no versionar ni validar LookML; ignorar costos y rendimiento. También usar Looker como ETL o motor de datos. Detectar y corregir con revisión y métricas.

Q85. ¿Qué buenas prácticas y checklist de producción recomiendas?

Checklist: modelo versionado y validado; claves y relaciones correctas; medidas documentadas; seguridad por grupos, user attributes y access filters; entornos dev y prod; CI/CD con revisión; PDTs y datagroups monitoreados; caché y aggregate awareness; rendimiento revisado; contenido certificado y con owner; alertas y schedules controlados; backups y runbooks; costos monitoreados; formación y adopción. Antes de producción: probar con datos reales, validar métricas contra la fuente, revisar permisos y tener plan de rollback. Medir e iterar.