Data Governance, BI and Visualization with Looker

Resumen

Una organización puede tener un data lake, un warehouse serverless y decenas de pipelines, y seguir sin ser data-driven. El punto donde el valor se pierde no suele ser el almacenamiento: es el tramo final del recorrido del dato, donde se decide quién puede consultar qué, con qué definición de las métricas y con cuánta frescura. Este tema cubre ese tramo desde dos frentes que el examen trata de forma conjunta: la gobernanza que hace posible un data journey exitoso, y las capas de consumo y de movimiento que conectan BigQuery con la decisión —Looker por un lado, Pub/Sub y Dataflow por otro.

La gobernanza del dato no es un anexo regulatorio: es la infraestructura que garantiza que cada cifra que llega a un dashboard sea fiable, localizable, trazable y accesible para quien corresponde. Calidad, metadatos, linaje, catálogo, control de acceso y retención son sus seis componentes, y todos ellos tienen un efecto directo sobre la confianza en los informes. A ellos se añade una gobernanza específica que casi nunca se nombran por separado: la gobernanza de las métricas. Tener datos gobernados no evita que dos departamentos publiquen cifras distintas del mismo indicador si no existe una definición canónica y compartida de ese indicador.

Looker es la respuesta de Google Cloud a esa necesidad: una plataforma de business intelligence donde el modelo de datos y las métricas se definen una vez —con LookML, el lenguaje de modelado semántico— y se consumen de forma self-service mediante exploraciones, reportes y dashboards consultados directamente contra BigQuery. La consulta se ejecuta en el momento sobre el warehouse, lo que permite reportes en tiempo real con la frescura que tenga el dato de origen; sobre esa base se construyen entregas programadas, alertas y flujos de trabajo que llevan la métrica al lugar donde se decide.

El frente del movimiento de datos es el que completa el cuadro. Pub/Sub desacopla la generación del evento del procesamiento, y Dataflow ejecuta pipelines unificados de batch y streaming con escalado automático; juntos modernizan la arquitectura de datos de un lote nocturno frágil a una ingesta continua que alimenta BigQuery con minutos de retraso. La combinación completa —evento, pipeline, warehouse, modelo semántico, dashboard— es la arquitectura que sostiene la analítica en tiempo real y su valor de negocio: decisiones sobre lo que está ocurriendo, no sobre lo que ocurrió el mes pasado.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Explicar por qué la gobernanza del dato es una condición de éxito del data journey y enumerar sus componentes: calidad, metadatos, linaje, catálogo, control de acceso y retención.
Distinguir la gobernanza del dato (activos) de la gobernanza de las métricas (definiciones) y justificar por qué una sin la otra no produce decisiones consistentes.
Describir cómo Looker democratiza el acceso a los datos mediante business intelligence self-service sobre un modelo semántico gobernado.
Explicar el flujo de una consulta de Looker contra BigQuery y su efecto sobre la frescura, el coste y la latencia de un reporte en tiempo real.
Diferenciar un reporte consultado en el momento de un informe materializado, e identificar cuándo cada uno responde mejor al caso de negocio.
Argumentar el valor de negocio de la analítica en streaming en tiempo real y seleccionar los casos de uso donde la frescura del dato cambia el resultado.
Explicar el papel de Pub/Sub y Dataflow en la modernización de pipelines de datos y la función de cada uno dentro de la arquitectura de eventos.
Distinguir procesamiento por lotes y procesamiento en streaming en cuanto a latencia, coste, complejidad operativa y tipo de decisión que soportan.
Diseñar y evaluar una arquitectura de extremo a extremo —evento, pipeline, BigQuery, Looker— y proponer métricas para juzgar su efectividad de negocio.

Contenido Principal

Subtema 1: Gobernanza del dato como condición del data journey

Un recorrido de datos (data journey) tiene éxito cuando el dato llega a la decisión íntegro, documentado, protegido y a tiempo. Eso no ocurre por inercia: ocurre porque alguien ha definido quién es responsable de cada conjunto de datos, qué significa cada campo, qué calidad es aceptable, quién puede verlo y cuánto tiempo se conserva. La gobernanza es el conjunto de decisiones, roles y controles que hacen que esas condiciones se cumplan de forma repetible, y por eso se describe como la infraestructura social y técnica que sostiene el resto de la plataforma.

Sus seis componentes y la función de negocio de cada uno son los mismos que se estudian en Negocios basados en datos, pero conviene mirarlos desde la perspectiva del consumo analítico, que es donde este tema se apoya:

Componente	Pregunta de negocio que responde	Señal de fallo visible en BI
Calidad	¿Me puedo fiar de esta cifra?	Dos dashboards distintos para el mismo KPI
Metadatos	¿Qué significa este campo?	Cada equipo interpreta la columna a su manera
Linaje	¿De dónde viene y qué afecta si cambia?	Un cambio rompe informes sin explicación aparente
Catálogo	¿Qué datos existen y quién los usa?	Búsquedas por correo, dependencia de personas clave
Control de acceso	¿Quién puede ver qué, y bajo qué condiciones?	Datos personales visibles para usuarios que no los necesitan
Retención	¿Cuánto tiempo y a qué coste se conserva?	Tablas que nadie consulta y facturas que nadie explica

Sobre esa base aparece la gobernanza de las métricas, que es el puente entre la plataforma y la BI. Un indicador como "cliente activo", "venta neta" o "abandono" tiene que tener una única definición canónica, un dueño y un lugar donde quede escrita. En Google Cloud ese lugar material es la capa semántica: vistas y modelos con descripción en BigQuery, y modelos LookML en Looker. Cuando la definición vive en el modelo, todos los consumidores —expertos en SQL, analistas de negocio, dashboards ejecutivos— parten de la misma cifra; cuando vive en cada informe, la organización acumula versiones divergentes y pierde confianza en sus propios datos.

Un matiz que el examen explota: la gobernanza no frena la democratización, la hace posible. Restringir el acceso a las tablas crudas y publicar en su lugar un modelo gobernado con permisos granulares amplía el número de personas que pueden analizar sin ampliar el riesgo. El orden correcto es primero modelo y definiciones, después acceso masivo.

Temas relacionados: Data-Driven Business and Transformation, BigQuery and Enterprise Data Warehousing

Subtema 2: Looker: business intelligence self-service sobre un modelo gobernado

Looker es la plataforma de business intelligence y de aplicaciones de datos de Google Cloud. Su diferencia estructural frente a las herramientas de BI tradicionales es que el modelo de datos no vive dentro de cada informe, sino en un repositorio versionado descrito con LookML (Looker Modeling Language). LookML define las vistas (qué campos hay), los joins (cómo se relacionan las tablas), los dimensions (las columnas de análisis) y los measures (las agregaciones: sumas, medias, recuentos), y Looker traduce la exploración del usuario en SQL que se ejecuta contra el almacén, que en el caso de Google Cloud es normalmente BigQuery.

El flujo de consumo tiene cuatro piezas, de menor a mayor complejidad:

Explore: el punto de partida. Es un área temática sobre la que el usuario puede filtrar, agregar, pivotar y segmentar sin escribir SQL, porque las opciones disponibles son las que el modelo permite.
Look: un reporte guardado sobre un Explore, con campos, filtros y visualización definidos.
Dashboard: una composición de widgets —tablas, gráficos, texto— con filtros compartidos que se lee como una vista única de negocio.
Entregas y alertas: la programación que convierte el artefacto en parte de un flujo de trabajo: envío por correo, mensajería o webhook en una frecuencia dada, y alertas cuando una métrica cruza un umbral.

La autoridad del modelo se gestiona con permisos de Looker sobre el contenido y, sobre los datos, con los permisos heredados del almacén: la consulta se ejecuta con la identidad que conecta, de modo que los controles de BigQuery (roles de IAM, políticas de fila y de columna) siguen vigentes detrás de cada dashboard. A eso se suma el control propio de Looker: atributos de usuario para restricciones por región o canal, access grants para habilitar campos a perfiles concretos y filtros de acceso a nivel de fila en el modelo. La consecuencia de negocio es que democratizar el acceso no exige elegir entre velocidad y control.

Looker se acompaña de Looker Studio, una herramienta de visualización y exploración más ligera, orientada a creación rápida de gráficos y dashboards con conectores a múltiples fuentes. La distinción práctica es de grado de gobernanza y de profundidad de modelado: Looker aporta el modelo semántico versionado, la reutilización rigurosa de métricas y las capacidades de operación empresarial; Looker Studio aporta rapidez de composición visual. En una organización madura conviven: el modelo canónico y los dashboards críticos viven en Looker; la exploración preliminar y los informes de alcance acotado pueden vivir en Looker Studio.

Concepto LookML	Qué define	Ejemplo de uso de negocio
View	Tabla o consulta base y sus campos	`view: pedidos { sql_table_name:` proyecto.datos.pedidos `}`
Dimension	Columna de análisis (cualidad, categoría)	región, canal, estado del pedido
Measure	Agregación de negocio calculada	ingreso neto, tasa de devolución, pedidos únicos
Explore	Área temática navegable con joins resueltos	"Pedidos por cliente y región"
Model	Conjunto de vistas y explores de un dominio	modelo `comercio` con pedidos, clientes, devoluciones
Access grant	Habilitación de campos según perfil	coste unitario visible solo para finanzas

Ejemplo Práctico

Antes de abrir Looker a la organización, conviene comprobar con la consola de BigQuery quién consulta y cuánto consume, porque el modelo semántico debe publicarse sobre lo que realmente se usa:

# Definiciones y dueño de los datasets candidatos a ser modelo canónico
gcloud bigquery datasets list --project=PROJECT_ID \
  --format="table(datasetId,lastModifiedTime,labels)"

# Quién consulta, con qué frecuencia y con qué coste (base de la gobernanza de BI)
gcloud bigquery jobs list --project=PROJECT_ID --max-results=50 \
  --format="table(user_email,state,totalBytesBilled,creationTime)"

# Descripción de la tabla que servirá de modelo: metadatos escritos antes de modelar
bq show --format=prettyjson PROJECT_ID:comercio.pedidos | head -40

Lectura de la salida en términos de negocio. Si gcloud bigquery jobs list muestra a un solo usuario ejecutando la mayoría de las consultas con decenas de gigabytes escaneados, la organización tiene un cuello de botella de persona: la analítica depende de un especialista y el acceso self-service no existe todavía; ese es exactamente el problema que el modelo de Looker resuelve, porque trasladar la lógica al modelo permite que el negocio se autoatienda sin reescribir SQL. Si bq show devuelve una tabla sin description, sin etiquetas y con campos cuyo significado no está documentado, el trabajo previo a publicar el dashboard es escribir metadatos y asignar dueño: modelar sobre una tabla sin definiciones solo propaga la ambigüedad a todos los usuarios a la vez.

Subtema 3: Analizar y visualizar datos de BigQuery en Looker: reportes en tiempo real y workflows

La integración entre Looker y BigQuery es directa: Looker se conecta como cliente SQL del warehouse y genera las consultas a partir del modelo. Tres consecuencias merecen atención desde el punto de vista de negocio.

Reportes en tiempo real, con la frescura del origen. Un dashboard consultado en el momento refleja el estado de la tabla en BigQuery en ese instante. Si la ingesta es continua, el dashboard es continuo; si la tabla se actualiza por lotes a las 02:00, el dashboard muestra con precisión lo que sabíamos a las 02:00. La lectura correcta, por tanto, es que Looker no crea frescura: la expone. La frescura se gana en la capa de ingesta, que es donde entran Pub/Sub y Dataflow. Looker gestiona una caché de resultados con un periodo de invalidación configurable y técnicas de agregación precalculada que reducen el coste de las consultas repetidas; el efecto observable es que la cifra se actualiza al refrescar o al caducar la caché, y esa es la perilla que hay que ajustar cuando el negocio exige minutos en lugar de horas.

Dashboards como interfaz de decisión. Un dashboard útil no maximiza el número de gráficos: maximiza la claridad de la decisión. Filtros comunes (periodo, región, canal), drill-down desde el agregado hasta el detalle, comparación contra objetivo o contra periodo anterior y una jerarquía visual que lea primero el indicador y después el detalle. La disciplina de gobernanza se materializa aquí: los campos disponibles son los del modelo, de modo que no es posible "inventar" una variante de la métrica desde la interfaz.

Integración en flujos de trabajo. El valor de un informe aparece cuando se sincroniza con el ritmo de negocio. Looker entrega reportes y dashboards programados por correo, a sistemas de mensajería o vía webhook; dispara alertas cuando una métrica cruza un umbral; expone una API para incorporar datos a otras aplicaciones; y permite embeber contenido en portales internos o en productos para clientes. Con ello, la BI deja de ser un sitio al que se va a mirar y pasa a ser un disparador dentro del proceso: la alerta de caída de conversión abre el ticket, el informe semanal alimenta la reunión de gestión, el dashboard embebido acompaña la operación en la misma pantalla donde se trabaja.

El coste merece una regla explícita. BigQuery factura por los bytes que cada consulta escanea, de modo que un dashboard con decenas de widgets que escanea tablas amplias a cada refresco multiplica el gasto sin que nadie lo note. Las palancas son el particionamiento y el clustering de las tablas, el uso de vistas o tablas agregadas para las métricas de alta frecuencia, y el dimensionamiento del refresh al ritmo real de la decisión.

Ejemplo Práctico

# Coste y frecuencia de las consultas que alimentan dashboards
gcloud bigquery jobs list --project=PROJECT_ID --max-results=100 \
  --format="table(user_email,statistics.query.totalBytesBilled,statistics.startTime)" \
  | sort -k2 -r

# Agregado rápido para validar una métrica antes de llevarla a Looker
bq query --use_legacy_sql=false '
SELECT
  canal,
  COUNT(DISTINCT id_cliente) AS clientes,
  SUM(importe_net) AS ingreso_net
FROM `PROJECT_ID.comercio.pedidos`
WHERE fecha >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY canal
ORDER BY ingreso_net DESC'

# Verificar la frescura real de la tabla que sostiene el dashboard
bq show --format=prettyjson PROJECT_ID:comercio.pedidos \
  | grep -E "lastModifiedTime|numBytes|streamingBuffer" -A2

Lectura de la salida en términos de negocio. La primera consulta es el informe de coste de la BI: si las consultas más caras son las del mismo dashboard y se repiten cada pocos minutos, hay que reevaluar el intervalo de refresco o publicar una tabla agregada, porque se está pagando frescura que nadie consume. El bq query de agregación es la prueba de humildad previa al modelado: si la definición de "ingreso neto" no está acordada antes de escribirla, el dashboard la fijará por defecto y será más difícil corregirla después. Y lastModifiedTime frente a la hora de la reunión responde la pregunta que ningún indicador de uso contesta: ¿la cifra que se discute es de hoy o del último lote?

Subtema 4: Analítica en streaming y su valor de negocio

La analítica en streaming procesa el dato a medida que se genera, con latencias del orden de segundos o minutos en lugar de horas o días. Su valor de negocio no es técnico, sino de ventana de decisión: hay problemas donde el insight pierde valor con el tiempo y otros donde no. Detectar un intento de fraude después de autorizar el pago no es detección; recomendar un producto cuando el cliente ya ha abandonado la sesión no es recomendación; ajustar el precio cuando la campaña ha terminado no es optimización. En esos casos la frescura es el producto.

El valor se puede expresar en cuatro palancas concretas:

Prevención de pérdidas: fraude, abuso de promociones, intrusiones y fallos de calidad detectados antes de que el coste se materialice.
Experiencia en el momento: recomendación, búsqueda y soporte adaptados a lo que el usuario está haciendo ahora, con efecto directo sobre conversión y satisfacción.
Operación en tiempo real: monitorización de sensores, logística, disponibilidad de inventario y trabajos de campo, donde la respuesta correcta es inmediata (reprogramar, reasignar, detener).
Precios y oferta dinámicos: ajuste de tarifas, disponibilidad y promociones según demanda, competencia y existencias observadas.

La analítica en streaming también modifica la arquitectura de datos, y el examen lo explota: si el dato se procesa en movimiento, la separación entre "sistema operativo" y "sistema analítico" se vuelve porosa, porque el warehouse se alimenta en continuo y el dashboard se convierte en un espejo de la operación. La consecuencia organizativa es que hay que definir de antemano qué decisiones se automatizan y cuáles siguen requiriendo una persona, porque una métrica en tiempo real sin protocolo de acción es únicamente una pantalla más animada.

No todo requiere streaming, y esa distinción es una de las mejores preguntas de caso: la analítica por lotes sigue siendo la respuesta correcta para cerrar contables, informes regulatorios, planificación de demanda a meses y cualquier decisión cuyo coste de error no dependa de minutos. La regla de decisión es el coste de la demora frente al coste de la complejidad: el streaming añade operación (esquemas que evolucionan, deduplicación, manejo de reintentos, métricas de latencia) y solo se justifica cuando la demora destruye valor.

Dimensión	Batch (por lotes)	Streaming
Latencia del dato a la decisión	Horas a días	Segundos a minutos
Patrón de procesamiento	Ventana programada, reprocesable	Continuo, estado mantenido
Modelo de errores	Se corrige en el siguiente lote	Hay que manejar duplicados y reintentos
Coste y complejidad operativa	Menor, ciclo predecible	Mayor, requiere supervisión continua
Decisión que soporta	Reporte, cierre, planificación	Prevención, personalización, operación

Subtema 5: Modernizar pipelines con Pub/Sub y Dataflow

Los productos que Google Cloud sitúa en el tramo de modernización de pipelines son Pub/Sub y Dataflow, y cumplen funciones distintas que conviene no confundir.

Pub/Sub es el servicio de mensajería asíncrona: el sistema de origen publica un evento en un topic y los suscriptores reciben ese evento de forma independiente, sin que el productor conozca ni espere al consumidor. Ese desacoplamiento es el valor de arquitectura: cuando la aplicación de pedidos publica "pedido_creado", la analítica, el fraude y la notificación pueden consumirlo a su ritmo, y añadir un consumidor nuevo deja de ser un proyecto de integración. Pub/Sub ofrece entrega al menos una vez de forma nativa, con entrega exacta disponible cuando las partes la soportan, claves de orden para conservar el orden dentro de una entidad y suscripciones push o pull con retención configurable de mensajes (del orden de días por defecto, ampliable).

Dataflow es el servicio gestionado de procesamiento de datos, heredero del modelo de programación de Apache Beam: un mismo pipeline describe la lógica y se ejecuta en modo batch o streaming sin reescritura. De él interesan cuatro capacidades: procesamiento unificado (una sola base de código para el histórico y para el evento), escalado automático de trabajadores según la carga, abstracción de la complejidad de ventana (windowing), disparadores y marcas de agua (watermark), y plantillas listas para usar que conectan fuentes y destinos sin programar nada — la más habitual para este tema es la plantilla de Pub/Sub a BigQuery.

Juntos componen la referencia de ingesta moderna: el origen publica eventos, Pub/Sub los almacena con seguridad temporal, Dataflow transforma, valida, deduplica y enriquece, BigQuery recibe el resultado particionado, y Looker lo sirve gobernado. El efecto de negocio sobre el pipeline tradicional es triple: se elimina el lote nocturno como punto único de fallo, se reduce el tiempo entre hecho y decisión de días a minutos, y se separa el ritmo del negocio del ritmo del equipo de datos.

Ejemplo Práctico

# 1. Canal de eventos: topic y suscripción
gcloud pubsub topics create pedidos-web --project=PROJECT_ID
gcloud pubsub subscriptions create pedidos-a-bq --topic=pedidos-web --project=PROJECT_ID

# 2. Pipeline gestionado sin programar: plantilla Pub/Sub -> BigQuery
gcloud dataflow jobs run pubsub-a-bq \
  --gcs-location=gs://dataflow-templates/latest/PubSub_to_BigQuery \
  --region=us-central1 \
  --parameters=inputTopic=projects/PROJECT_ID/topics/pedidos-web,outputTable=PROJECT_ID:realtime.pedidos

# 3. Publicar un evento de prueba y verificar que llega al warehouse
gcloud pubsub topics publish pedidos-web --project=PROJECT_ID \
  --message='{"pedido":"p-88231","canal":"web","importe_net":129.90}'
bq query --use_legacy_sql=false 'SELECT COUNT(*) FROM `PROJECT_ID.realtime.pedidos`'

# 4. Estado del pipeline (frescura real del dato en streaming)
gcloud dataflow jobs list --region=us-central1 --status=active \
  --format="table(name,state,createTime)"

Lectura de la salida en términos de negocio. El intervalo entre gcloud pubsub topics publish y el COUNT(*) en BigQuery es la métrica de frescura del sistema: si es de segundos, el dashboard de Looker sobre esa tabla es genuinamente operativo; si el job de Dataflow no aparece como activo, el evento se está acumulando sin procesar y la organización creerá tener tiempo real cuando solo tiene una cola creciente. Además, gcloud dataflow jobs list devuelve trabajadores escalados según la carga: ese estado es la evidencia de que la plataforma absorbe picos de campaña sin compra de infraestructura, argumento que forma parte del caso de negocio de la modernización.

Temas relacionados: Data-Driven Business and Transformation, BigQuery and Enterprise Data Warehousing, Google Cloud Data and Databases Solutions

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
Data governance	Decisiones, roles y controles que hacen fiable, trazable y accesible el dato (calidad, metadatos, linaje, catálogo, acceso, retención)	Siempre que se amplíe el acceso al dato o se dependa de una cifra para decidir
Gobernanza de métricas	Definición canónica, con dueño, de cada indicador de negocio	Cuando dos equipos reportan cifras distintas del mismo indicador
Capa semántica	Traducción del modelo de datos a conceptos de negocio reutilizables (vistas en BigQuery, modelos LookML)	Antes de abrir el acceso self-service
Looker	Plataforma de BI con modelado semántico versionado en LookML y consultas generadas contra el warehouse	BI empresarial gobernada, métricas críticas y flujos de trabajo
LookML	Lenguaje de modelado de Looker: vistas, joins, dimensions y measures	Para definir una única fuente de verdad de métricas
Explore	Área temática navegable sobre la que el usuario analiza sin SQL	Punto de entrada del análisis self-service
Looker Studio	Herramienta de visualización y exploración ágil con conectores múltiples	Exploración preliminar e informes de alcance acotado
Dashboard	Composición de indicadores, gráficos y filtros que soporta una decisión concreta	Cuando existe un proceso de revisión que lo consume
Reporte en tiempo real	Consulta ejecutada en el momento contra BigQuery, con la frescura del dato de origen	Decisiones operativas; depende de la ingesta, no de la herramienta
Pub/Sub	Mensajería asíncrona que desacopla productores y consumidores de eventos	Captura de eventos de negocio sin acoplar sistemas
Dataflow	Procesamiento gestionado, unificado batch y streaming, con escalado automático	Ingesta, transformación y validación continua de datos
Plantilla de Dataflow	Pipeline preconfigurado (por ejemplo, Pub/Sub a BigQuery) que se ejecuta sin programar	Para modernizar pipelines en días, no en meses
Streaming analytics	Proceso de datos a medida que se generan, con latencia de segundos o minutos	Cuando el coste de la demora supera el coste de la operación continua
Freshness (frescura)	Retraso entre la ocurrencia del hecho y su disponibilidad para decidir	Como métrica de diseño de toda arquitectura analítica

Comparaciones

Eje	Looker	Looker Studio
Modelo de datos	LookML versionado, central y reutilizable	Definición por informe o conectores de datos
Gobernanza de métricas	Nativa: una definición, todos los consumidores	Depende de la disciplina de cada autor
Consulta	SQL generado contra BigQuery en el momento	Consultas según conector y configuración
Operación empresarial	Permisos, entregas, alertas, API y embebido	Composición rápida, menor profundidad de operación
Caso típico	Métricas críticas, dashboards ejecutivos, producto embebido	Exploración, gráficos puntuales, difusión ligera

Eje	Informe materializado	Consulta en el momento (Looker + BigQuery)
Frescura	La del último procesamiento	La del dato en origen, con caché configurable
Coste de consulta	Prepagado en la generación	Se paga por bytes escaneados a cada acceso
Interactividad	Fija, salvo regeneración	Filtros, drill-down y pivotes bajo demanda
Complejidad de operación	Hay que mantener el proceso	Hay que gobernar coste y rendimiento
Cuándo elegirlo	Volúmenes muy grandes con acceso masivo	La mayoría de dashboards de negocio

Errores Comunes

Error: Publicar dashboards abiertos a toda la organización sin modelo semántico previo, con acceso directo a las tablas crudas. → Solución: Modelar primero y publicar después: métricas canónicas y descripciones en el modelo (vistas de BigQuery, LookML en Looker), permisos granular sobre esa capa y solo entonces acceso masivo. El síntoma que confirma el error es la proliferación de versiones distintas del mismo indicador.
Error: Interpretar "tiempo real" como una propiedad de la herramienta de BI y creer que cambiar el dashboard añade frescura. → Solución: Tratar la frescura como atributo de la ingesta: si la tabla se actualiza por lotes, ningún dashboard será operativo. Auditar el intervalo entre la ocurrencia del hecho y su disponibilidad en BigQuery, y llevar la ingesta a Pub/Sub y Dataflow cuando ese intervalo supere el que la decisión admite.
Error: Llevar analítica en streaming a procesos que funcionan bien por lotes, por moda o por "estrategia de tiempo real". → Solución: Evaluar el coste de la demora frente al coste de operación continua. Cierres, informes regulatorios y planificación a meses se quedan en batch; fraude, experiencia en el momento y operación en vivo justifican el streaming.
Error: Construir el dashboard antes de acordar la definición de la métrica, fijando por defecto una interpretación que después nadie cuestiona abiertamente. → Solución: Escribir la definición, el dueño y la fuente del cálculo en el modelo antes de visualizar, y versionar los cambios. Una métrica sin definición escrita no es gobernada aunque esté en un catálogo.
Error: Programar refrescos cada pocos minutos sobre tablas amplias sin revisar el coste, asumiendo que la BI no genera gasto. → Solución: Revisar totalBytesBilled de BigQuery con regularidad, particionar y agrupar las tablas de alta frecuencia, y publicar agregados para los widgets que no necesitan detalle. El refresco debe ajustarse al ritmo real de la decisión, no al máximo técnicamente posible.

Puntos para el Examen

🎯 Punto clave 1: La gobernanza del dato es condición de un data journey exitoso, no un complemento. Calidad, metadatos, linaje, catálogo, control de acceso y retención son los seis componentes que aparecen en las preguntas de caso; la respuesta esperada identifica el componente ausente —dueño, definición, permiso o retención— y no propone comprar más capacidad.

🎯 Punto clave 2: Looker democratiza el acceso con business intelligence self-service sobre un modelo gobernado. El modelo LookML define una sola vez dimensiones y medidas, y cada usuario explora sin SQL; el control no se pierde porque la consulta se ejecuta sobre los permisos del almacén. Si una pregunta presenta "varios equipos midiendo el mismo indicador de forma distinta", la respuesta es la capa semántica.

🎯 Punto clave 3: Un reporte de Looker consultado contra BigQuery refleja la frescura del dato de origen. Para analizar y visualizar datos en tiempo real, el examen espera la cadena completa: ingesta continua, warehouse actualizado y consulta en el momento. Separar la herramienta de BI de la ingesta es la distinción que resuelve la mayoría de los escenarios.

🎯 Punto clave 4: Pub/Sub y Dataflow modernizan pipelines con funciones distintas — desacoplamiento de eventos y procesamiento unificado batch/streaming con escalado automático—. Reconocer cada uno en un diagrama de arquitectura o en un caso de "necesitamos dejar el lote nocturno" es la respuesta de alto valor.

🎯 Punto clave 5: La analítica en streaming se justifica por el valor de la ventana de decisión (prevención, experiencia en el momento, operación y precio dinámico), no por prestigio técnico. El examen valora saber cuándo no usarla: batch sigue siendo correcto para cierre, cumplimiento y planificación.

Recursos Externos

Looker documentation — Documentación de la plataforma: modelado, exploración, dashboards, entregas y administración.
Introduction to LookML — Cómo LookML describe dimensiones, medidas y relaciones para generar SQL consistente.
Pub/Sub documentation — Topics, suscripciones, semánticas de entrega, orden y retención de mensajes.
Dataflow templates — Plantillas gestionadas, incluida Pub/Sub a BigQuery, para modernizar pipelines sin programar.
Streaming data into BigQuery — Ingesta continua, buffers de streaming y consideraciones de frescura y coste.

Autoevaluación Rápida

Pregunta: Dos departamentos publican cifras distintas de "ingresos netos del mes" en dashboards diferentes, aunque ambos usan BigQuery. ¿Cuál es el problema y cómo se resuelve? Respuesta: No es un problema de plataforma ni de permisos: es ausencia de gobernanza de métricas. La definición de la medida vive en cada informe en lugar de en una capa semántica. La solución es acordar la definición canónica con su dueño, modelarla una vez (vista o modelo LookML) y hacer que todos los dashboards consuman esa medida; los datos ya estaban gobernados, lo que faltaba era la gobernanza de la definición.
Pregunta: Un directivo pregunta si su dashboard de operaciones es "en tiempo real" porque se refresca cada minuto. ¿Qué hay que responder? Respuesta: Que la frecuencia de refresco no determina la frescura: la determina la ingesta. Si la tabla de origen se actualiza cada hora, un refresco minuto a minuto solo consulta con más frecuencia un dato viejo. Lo que hay que medir es el retraso entre la ocurrencia del hecho y su disponibilidad en BigQuery; si ese retraso supera lo que la decisión admite, hay que modernizar la ingesta con Pub/Sub y Dataflow, y solo entonces el dashboard será realmente operativo.
Pregunta: ¿Por qué se dice que Looker democratiza el acceso sin perder control? Respuesta: Porque el acceso self-service se hace sobre un modelo semántico que decide qué campos existen y cómo se calculan, y porque la consulta se ejecuta sobre los permisos del almacén: los roles de IAM, las políticas de fila y de columna de BigQuery siguen aplicándose detrás de cada dashboard. El usuario obtiene autonomía dentro de un espacio definido, en lugar de acceso crudo a las tablas, que produciría cifras divergentes y riesgo de fuga.
Pregunta: La dirección quiere "pasar todo a streaming" para tener decisiones inmediatas. ¿Qué argumento presentas? Respuesta: Que la decisión se toma comparando el coste de la demora con el coste de la operación continua. Fraudes, personalización y operación en vivo justifican streaming porque el valor del insight decae en minutos; los cierres contables, los informes regulatorios y la planificación a meses no, y ahí el lote es más barato, reprocesable y simple. La recomendación correcta es clasificar los casos de uso por ventana de decisión, no migrar la plataforma completa, y empezar por el proceso cuyo retraso ya está costando dinero.
Pregunta: Se ejecuta la plantilla de Pub/Sub a BigQuery y el dashboard de Looker no muestra los nuevos eventos. ¿Cómo diagnosticas? Respuesta: Separo las tres capas. Primero verifico que los eventos lleguen al topic y que exista una suscripción activa (gcloud pubsub subscriptions list); después compruebo que el job de Dataflow está en estado activo y sin errores (gcloud dataflow jobs list --status=active); por último mido la tabla de destino con bq show para confirmar si se han escrito filas y cuándo fue la última modificación. El fallo típico está en el pipeline —job caído o parámetros de destino incorrectos—, no en Looker: si la tabla tiene datos y el dashboard no, entonces reviso la caché y el filtro de fechas del propio dashboard.