Data-Driven Business and Transformation

Resumen

Una organización que decide mejor no es, necesariamente, una organización que tiene más datos. Es una que convierte sus datos en decisiones a una velocidad superior a la que se deteriora la oportunidad de negocio. Este tema estudia el marco conceptual que sostiene el segundo dominio de la certificación Google Cloud Digital Leader: por qué el dato es el activo que convierte la nube en capacidad de negocio, cómo se organiza ese dato para que sea consultable, qué pasos tiene que recorrer un dato desde que se recoge hasta que alguien actúa sobre él, y por qué la gobernanza no es un adorno regulatorio sino la condición que hace posible ese recorrido.

El material parte de una distinción que conviene fijar antes de nada: el dato no es lo mismo que la información, ni la información es lo mismo que el conocimiento o la decisión. Un terabyte de registros de acceso a una web es dato; el porcentaje de usuarios que vuelve en 30 días es una métrica; la decisión de rediseñar la campaña de retención es una acción. Casi todos los programas de datos fracasan en el salto intermedio, entre tener el dato y cambiar algo con él, y la causa suele ser de gobernanza y de proceso, no de tecnología.

El tema cubre también los conceptos básicos de gestión de datos que aparecen en el examen: la diferencia entre una base de datos operativa, un data warehouse y un data lake, y por qué la comparación relevante no es "cuál es mejor" sino "cuál responde a qué pregunta y con qué latencia". Recoge el data value chain como marco de referencia para localizar el cuello de botella de una organización, y explica cómo la nube cambia el alcance de lo que se puede analizar: datos estructurados, semiestructurados y no estructurados, datos actuales y datos nuevos capturados en el punto de origen, y fuentes externas de terceros.

Cierra con la gobernanza del dato entendida como infraestructura de negocio (calidad, metadatos, linaje, catálogo, control de acceso y retención) y con el impacto organizativo de la democratización del dato: qué cambia en el trabajo diario de los equipos de datos cuando el acceso se amplía desde un grupo de especialistas hacia toda la organización, y qué riesgos organizativos aparecen en ese mismo movimiento.

Al terminar este contenido serás capaz de explicar en términos de negocio por qué una estrategia de datos falla o funciona, encuadrar un problema de datos dentro de la cadena de valor, recomendar el servicio de Google Cloud adecuado para cada tramo del recorrido del dato y sostener por qué la gobernanza es la inversión que hace posible todo lo demás.

Objetivos de Aprendizaje

Al terminar este contenido, serás capaz de:

Explicar el papel de los datos en la transformación digital: cómo se convierten en insights, cómo esos insights sostienen decisiones y cómo las decisiones generan valor nuevo.
Distinguir base de datos, data warehouse y data lake en términos de esquema, velocidad de escritura, latencia de consulta, coste y caso de uso, y saber cuándo se aplica cada uno.
Enumerar las cuatro fuentes de valor que una organización explota en su dato: datos que ya posee, datos nuevos que recoge, datos generados por sus propios procesos y datos externos de terceros.
Describir la cadena de valor del dato (data value chain) en sus etapas: recogida, almacenamiento, integración, calidad, análisis, visualización, decisión y acción, e identificar dónde se rompe en una organización real.
Argumentar cómo la nube amplía el valor obtenible del dato, en particular sobre datos no estructurados, y conocer los servicios de Google Cloud que sostienen ese argumento (BigQuery, BigLake, Dataplex, Dataflow, Pub/Sub).
Enumerar los componentes de la gobernanza del dato —calidad, metadatos, linaje, catálogo, control de acceso y políticas de retención— y explicar la función de negocio de cada uno.
Analizar cómo la democratización del dato modifica el trabajo de los equipos de datos y de los equipos de negocio, identificando beneficios y nuevos modos de fallo.
Reconocer errores frecuentes en los programas de datos y proponer la corrección correspondiente.

Contenido Principal

Subtema 1: El papel de los datos en la transformación digital

La transformación digital suele describirse como un cambio de herramientas o de arquitectura. La lectura correcta es otra: es un cambio en la calidad y la velocidad de las decisiones de la organización. La nube aporta la capacidad de cómputo elástica y de almacenamiento masiva que hace posible procesar los datos; pero el retorno de negocio no llega por el cómputo en sí, llega por la conversión del dato en una acción concreta y medible.

Esa conversión ocurre en cuatro movimientos encadenados, y es útil pensarlos como una cascada donde cada eslabón puede romper la cadena:

Dato → Insight. El dato bruto se convierte en un hallazgo comprensible: "los clientes que reciben un recordatorio de cita 48 horas antes cancelan menos", no "hay 1.240.000 filas en la tabla de citas".
Insight → Decisión. El hallazgo se traduce en una elección entre alternativas, con criterio explícito sobre coste, riesgo y oportunidad.
Decisión → Acción. La elección se ejecuta en el proceso de negocio: la campaña cambia, el inventario se reordena, la cola de llamadas se reprograma.
Acción → Valor. El resultado de la acción se mide contra el indicador que la justificaba, y ese resultado real vuelve como nuevo dato de entrada.

El cuarto movimiento es el que casi nunca se instrumenta, y es donde se decide si un programa de datos es una inversión o un gasto de moda. Si no se mide el efecto de la acción sobre el indicador de negocio, la organización no puede distinguir una decisión basada en datos de una decisión basada en intuición que resultó acertada por casualidad.

El valor del dato no está solo en el histórico. Una organización puede crear valor usando tres vías distintas que rara vez se separan bien en los proyectos reales:

Explotar datos actuales. Mejorar el rendimiento de una decisión que ya se toma: reducir el abandono de carrito, detectar fraude antes del reembolso, ajustar la previsión de demanda. Es la vía de menor riesgo, porque la decisión ya existe y el dato ya está disponible; el trabajo consiste en mejorar su granularidad, su latencia o su fiabilidad.
Recoger datos nuevos. Instrumentar puntos de contacto que antes no se medían: la interacción con el punto de venta, el uso real de un dispositivo en campo, la razón por la que un cliente cancela. Aquí el valor depende de la instrumentación, y el error frecuente es capturar mucho y usar poco.
Acceder a fuentes externas. Enriquecer el dato propio con datos de terceros —catálogo de productos, benchmarks de mercado, datos de movilidad, datos meteorológicos, señales de contexto económico— para pasar de "qué está pasando en mi operación" a "qué va a pasar en mi operación".

La nube cambia el balance entre estas tres vías. Antes, medir un punto de contacto nuevo o enriquecer con una fuente externa exigía capacidad de almacenamiento y de cómputo que solo estaba disponible en organizaciones grandes. Con almacenamiento por gigabyte y cómputo por consulta, el coste marginal de preguntar una pregunta nueva al histórico completo es mucho menor, y eso es lo que hace viable el modelo de "analítica exploratoria como rutina".

La consecuencia organizativa es que el dato deja de ser un artefacto que un equipo de datos produce para otros, y pasa a ser una infraestructura de la que la organización entera se sirve. Ese cambio es el núcleo del resto del tema.

Palanca de valor	Qué cambia respecto al modelo tradicional	Requisito de plataforma	Indicador de negocio típico
Explotar datos actuales	Se mejora la decisión existente sin cambiar el proceso	Almacenamiento económico y consultas ad hoc	Margen, conversión, coste de servicio
Recoger datos nuevos	Se instrumentan puntos de contacto antes invisibles	Ingesta continua y pipelines gestionados	Cobertura de medición, tasa de respuesta
Acceder a fuentes externas	Se enriquece el dato propio con contexto de mercado	Integración y catálogo de fuentes	Precisión de previsión, time-to-market
Accionar el dato	El análisis se inyecta en el proceso operativo	Integración con aplicaciones y eventos	Tiempo de ciclo de decisión, tasa de ejecución

Ejemplo Práctico

El siguiente bloque no es un ejercicio de sintaxis: es una forma de auditar qué datos usa realmente la organización y en qué estado de madurez se encuentra cada tramo.

# 1. Qué datos estructurados existen y qué datasets están disponibles
gcloud bigquery datasets list --project=PROJECT_ID
gcloud bigquery tables list --project=PROJECT_ID --dataset=retail --max-results=20

# 2. Qué datos no estructurados están acumulados (ficheros, exports, backups)
gcloud storage buckets list --project=PROJECT_ID
gcloud storage ls gs://raw-retail-landing/ --recursive --limit=50

# 3. Qué procesos automáticos están ya generando datos
gcloud pubsub topics list --project=PROJECT_ID
gcloud dataflow jobs list --project=PROJECT_ID --region=us-central1 --state=JOB_STATE_RUNNING

# 4. Tamaño y antigüedad del dato disponible para analítica
gcloud bigquery datasets describe retail --project=PROJECT_ID

Lectura de la salida en términos de negocio. Si gcloud bigquery datasets list devuelve un solo dataset (por ejemplo, retail_legacy) mientras gcloud storage buckets list muestra varios buckets con zonas de aterrizaje y archivos brutos, la organización tiene el dato pero no lo ha convertido en capacidad analítica: existe un coste de almacenamiento que no está produciendo decisiones. Si gcloud pubsub topics list no devuelve topics, no hay captura de eventos en tiempo real, y cualquier pregunta sobre "qué está pasando ahora" se responderá mañana. Si gcloud dataflow jobs list no muestra jobs en estado JOB_STATE_RUNNING, no existe un pipeline gestionado, sino procesos por lotes que se ejecutan cuando alguien se acuerda; eso explica una parte importante de los informes que llegan tarde, y la causa es de diseño, no de rendimiento.

Temas relacionados: Google Cloud Data and Databases Solutions

Subtema 2: Conceptos básicos de gestión de datos: database, warehouse y lake

Tres familias de almacenamiento se confunden con frecuencia porque comparten el mismo objetivo de fondo —guardar y recuperar información—, pero resuelven problemas con restricciones opuestas. El error conceptual más común consiste en elegir la familia por la escala de los datos, cuando lo que debe determinarla es el patrón de acceso.

Base de datos operativa (relacional o NoSQL). Está optimizada para leer y escribir registros individuales y con baja latencia, con el foco en la integridad transaccional: una venta, un saldo, el estado de una reserva. El esquema se diseña pensando en las consultas de la aplicación, y la prioridad es que la escritura funcione de forma consistente bajo concurrencia. En Google Cloud, esta familia incluye Cloud SQL (MySQL y PostgreSQL), AlloyDB, Cloud Spanner, Cloud Bigtable y Firestore. Su dependencia del modelo relacional estricto es lo que las hace necesarias para la fuente de verdad, no un capricho arquitectónico.

Data warehouse. Está optimizado para leer muchos registros agregados con respuestas rápidas, y para responder preguntas de negocio que ya se sabe que se van a hacer: ventas por región y trimestre, cohortes de retención, margen por línea de producto. Se modela con esquemas como estrella o copo de nieve, con columnas tipadas y agregados precalculados; el diseño asume que las consultas se conocen de antemano y que los datos se ingestan por lotes. BigQuery es el ejemplo canónico en Google Cloud, y su modelo serverless (separación entre almacenamiento y cómputo, facturación por bytes escaneados) es lo que permite que una organización sin infraestructura de data warehousing pueda tener uno.

Data lake. Almacena datos en su forma original, con o sin estructura, y aplica el esquema en el momento de la lectura. La ventaja es la flexibilidad: nada se descarta en el momento de la ingestión, porque el caso de uso del dato dentro de dos años es desconocido. La contrapartida es que sin disciplina de catálogo, calidad y linaje, un data lake se convierte en un vertedero: hay datos pero nadie sabe si son fiables, de dónde vienen ni quién los usa.

La comparación relevante, por tanto, no es jerárquica: son tres respuestas distintas a tres preguntas distintas.

Criterio	Database operativa	Data warehouse	Data lake
Pregunta que responde	¿Cuál es el estado actual?	¿Cómo ha ido el negocio?	¿Qué se puede aprender de este dato?
Patrón de acceso	Lectura/escritura por registro	Lectura analítica agregada	Lectura exploratoria, escaneo amplio
Esquema	Definido y estricto, con restricciones	Definido y star schema	Flexible o fijo, aplicado en lectura
Latencia	Milisegundos	Segundos	Segundos a minutos según motor
Ingesta	Una fila a la vez	Por lotes (o streaming)	Por lotes, con retención de histórico
Optimizado para	Escritura concurrente	Lecturas analíticas repetidas	Amplitud y conservación de todo
Riesgo principal	Saturación por analítica pesada	Rigidez ante preguntas nuevas	Datos huérfanos y sin fiabilidad
Servicios de referencia	Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore	BigQuery	Cloud Storage + BigQuery (BigLake), Dataplex

Las tres conviven. Un mismo minorista puede tener su fuente de verdad en Cloud SQL (pedidos y stock), su histórico consolidado en BigQuery (ventas por producto y por periodo) y su cruda en Cloud Storage (recepción de ficheros de proveedores, audio de atención al cliente, exportaciones de la web). La pregunta no es "qué uso", sino "qué etapa del dato estoy resolviendo aquí".

Existe una cuarta variante que conviene conocer: el lakehouse, un data lake al que se le añade la capacidad transaccional y de aplicación de esquema de un warehouse. BigQuery lakehouse y BigLake son la forma en que Google Cloud materializa este patrón: los datos residen en Cloud Storage con coste de almacenamiento bajo, y BigQuery aporta la potencia de consulta y la gestión de tablas. Esto no elimina el data warehouse tradicional, pero sí hace que la frontera entre lake y warehouse se difumine cuando el volumen o la retención lo justifican.

Ejemplo Práctico

# Inventario de las tres familias en el proyecto
gcloud sql instances list --project=PROJECT_ID
gcloud spanner instances list --project=PROJECT_ID
gcloud bigtable instances list --project=PROJECT_ID

# Capas de almacenamiento y analítica
gcloud storage buckets list --project=PROJECT_ID
gcloud bigquery datasets list --project=PROJECT_ID --format="table(datasetId,labels)"

# ¿Existe ya un lakehouse? BigLake muestra tablas externas y tablas gestionadas
gcloud bigquery tables list --project=PROJECT_ID --dataset=lakehouse \
  --format="table(tableId,type,creationTime)"

# Coste de almacenamiento del dato "dormido" frente a su coste analítico
gcloud storage buckets describe gs://raw-retail-landing --project=PROJECT_ID \
  --format="value(name,location,storageClass,labels)"

Lectura de la salida en términos de negocio. Si el bucket raw-retail-landing acumula objetos de hace meses sin que ninguna tabla de lakehouse los referencie, hay capital de datos inmovilizado: la organización está pagando almacenamiento y, más importante, ha acumulado un coste de oportunidad. La decisión de negocio no es "borrar" (el dato puede tener valor regulatorio o futuro) sino "promover a consultable" o "definir una política de retención" — y esa decisión requiere un dueño, no un ticket de TI. En cambio, si gcloud sql instances list devuelve una instancia con CPU al límite y consultas analíticas ejecutándose sobre ella, la recomendación es separar cargas: mover la analítica a BigQuery. El diagnóstico se confirma mirando el tipo de almacenamiento de las tablas del dataset lakehouse: si la mayoría son MANAGED_TABLE sin particionamiento ni clustering, el gasto escaneado crecerá de forma no lineal con el volumen, y eso es un problema de coste anticipable.

Subtema 3: La cadena de valor del dato (data value chain)

El data value chain describe el recorrido que sigue un dato desde que se recoge hasta que alguien lo usa para actuar. Su utilidad no es descriptiva, sino diagnóstica: permite localizar exactamente dónde se pierde el valor, porque cada etapa tiene un modo de fallo característico.

Etapa 1. Recogida (collect). El dato nace en el punto de origen: un sensor, un formulario, una transacción, una llamada, un fichero de un tercero. Los errores típicos aquí son la instrumentación incompleta (no todo lo que ocurre se registra), la pérdida del contexto en la captura (un evento sin identificador de cliente no se puede enriquecer después) y la recolección de duplicados.

Etapa 2. Ingesta y almacenamiento (ingest & store). El dato entra en la plataforma y se conserva en una zona cruda. El error típico es la curación temprana: descartar en la entrada un dato que hoy no tiene caso de uso pero que dentro de un año dé soporte a una pregunta nueva. La zona cruda existe precisamente para no tener que decidir ahora.

Etapa 3. Integración y preparación (prepare). Se combinan fuentes, se resuelven entidades duplicadas, se normalizan esquemas, se calculan métricas derivadas. Es la etapa más costosa en tiempo de ingeniería y la que más se subestima. El error típico es duplicar esta lógica en cada consulta, en lugar de construir modelos y métricas reutilizables; la consecuencia es que dos equipos reportan cifras distintas para el mismo indicador, y la organización pierde confianza en sus datos.

Etapa 4. Calidad y confianza (assure). Aquí es donde la gobernanza se hace tangible: reglas de validación, completitud, frescura, consistencia. El error típico es tratar la calidad como un problema de IT cuando es un problema de proceso: si el dato no se usa para decidir, nadie va a reportar que viene incompleto.

Etapa 5. Análisis e insight (analyze). Se exploran, se segmenta, se responde la pregunta. El error típico es quedarse en la analítica descriptiva ("así ha ido") y no pasar a la prescriptiva ("esto es lo que hay que hacer").

Etapa 6. Visualización y consumo (visualize). El insight llega a quien decide, en un formato que ese interlocutor usa. El error típico es entregar un dashboard a un comité ejecutivo sin contexto de decisión asociado; la tasa de uso real de un informe que no está ligado a una reunión ni a una acción tiende a cero.

Etapa 7. Decisión y acción (act). El dato cambia una decisión operativa y la decisión se ejecuta. El error típico —y el más caro— es el loop de solo lectura: se pide análisis, se entrega análisis, nunca se cierra el círculo con la ejecución y la medición del resultado. Sin ese cierre, la cadena se puede repetir indefinidamente sin producir valor.

Etapa 8. Medición del resultado (measure). Se mide el efecto de la acción, y el resultado real vuelve como dato nuevo. Cerrar el círculo con esta etapa es lo que convierte un programa de datos en un sistema de mejora continua y es, a la vez, lo que suele faltar.

El diagnóstico correcto ante una organización que "tiene datos pero no obtiene valor" consiste en identificar la primera etapa donde el dato se degrada y arreglar solo esa. Solucionar un problema de visualización cuando el fallo real está en la captura de datos produce un dashboard bonito y vacío.

Etapa	Entrada	Salida	Error característico	Señal de fallo en negocio
Recogida	Eventos y ficheros de origen	Registro instrumentado	Contexto perdido en la captura	Métricas que no cuadran entre sistemas
Ingesta	Registros crudos	Zona cruda inmutable	Curación prematura	No se puede reconstruir un histórico
Preparación	Múltiples fuentes	Modelos y métricas	Lógica duplicada por consulta	Dos cifras para el mismo indicador
Calidad	Modelos preparados	Datos con niveles de confianza	Calidad como tarea de IT	Informes que nadie se cree
Análisis	Datos fiables	Insight accionable	Quedarse en lo descriptivo	Informes con lectura pero sin propuesta
Visualización	Insights	Vista para el decisor	Informe sin decisión asociada	Uso del dashboard casi nulo
Decisión y acción	Insight y contexto	Cambio ejecutado	Bucle de solo lectura	Ningún proceso cambia por el dato
Medición	Resultado de la acción	Métrica de impacto	No medir el contrafactual	ROI del programa no demostrable

Ejemplo Práctico

# Etapas 1-2: puntos de origen y zona cruda
gcloud pubsub topics list --project=PROJECT_ID
gcloud storage ls gs://raw-retail-landing/ --recursive --limit=30

# Etapa 3: preparación (modelos, no consultas ad hoc)
gcloud bigquery tables list --project=PROJECT_ID --dataset=staging \
  --format="table(tableId,type,description,lastModifiedTime)"

# Etapa 4: calidad — jobs programados de validación
gcloud dataflow jobs list --project=PROJECT_ID --region=us-central1 \
  --format="table(name,state,createTime)"

# Etapas 5-8: consumo y retroalimentación
gcloud bigquery jobs list --project=PROJECT_ID --max-results=20 \
  --format="table(jobReference.jobId,state,totalBytesProcessed,creationTime)"

Lectura de la salida en términos de negocio. Si gcloud bigquery tables list --dataset=staging devuelve tablas sin descripción (description vacía) o sin fecha de modificación reciente, la etapa de preparación es manual y la etapa de calidad no existe: eso explica la desconfianza en los informes. Si gcloud bigquery jobs list muestra totalBytesProcessed alto en consultas puntuales sobre tablas sin particionamiento, hay dos problemas encadenados: coste y latencia. Y si gcloud dataflow jobs list no devuelve ningún job programado, la única forma de "refrescar" los datos es que alguien lance las consultas a mano, lo que en la práctica significa que el dato del comité tiene una antigüedad no declarada. La pregunta que hay que hacerle al responsable no es "¿cuánto cuesta?" sino "¿cuánto tiempo lleva el comité tomando decisiones con datos de hace tres semanas?".

Subtema 4: La nube como habilitador de valor sobre todo tipo de dato

La afirmación de valor de la nube tiene un componente específicamente ligado al dato: la nube permite analizar todo tipo de dato, incluidos los no estructurados, a una escala y un coste que antes no eran viables. Es importante entender por qué, porque es lo que separa una propuesta de "guardamos todo en la nube" de una propuesta con argumento técnico.

En el modelo tradicional, cada tipo de dato exigía una tecnología y un equipo distinto. El estructurado iba a un warehouse relacional; los documentos, a un motor de búsqueda con sus propios indexadores; los logs, a un sistema de observabilidad; el audio y el video, a transcripción por lotes en un clúster dedicado. Cada sistema tenía su propio formato de ingestión, su propio ciclo de actualización y su propio modelo de permisos, lo que hacía que cruzar datos de dos dominios fuera un proyecto.

En Google Cloud, la convergencia se apoya en Cloud Storage como capa de almacenamiento de objetos de propósito general (con clases de almacenamiento que ajustan coste y latencia según la frecuencia de acceso), en BigQuery como motor de analítica serverless que consulta datos externos sin moverlos, y en Dataplex como capa de gestión del lake que ofrece zonas para activos, calidad de datos y catálogo.

El componente no estructurado es donde el argumento es más fuerte, porque es donde la diferencia de coste entre el modelo tradicional y el de nube es mayor. Un corpus de contratos en PDF, un histórico de llamadas de atención al cliente, miles de imágenes de producto o los logs de aplicación no se pueden "tabular" para meterlos en un warehouse; sin embargo se pueden consultar desde BigQuery con funciones que leen el contenido de los ficheros y con BigQuery ML para extraer señales. Datos que antes no se explotaban pasan a estar disponibles para el mismo tipo de análisis que el dato transaccional.

La segunda palanca habilitadora es el almacenamiento económico a escala y con retención larga. La retención de siete años de eventos a coste de acceso bajo es lo que permite reentrenar un modelo o auditar un histórico años después; en un modelo on-premises, esos datos se borraban por el coste de guardarlos.

La tercera es la hibridación de datos sin moverlos: BigQuery permite consultar datos en Cloud Storage, en otra nube, en sistemas de bases de datos mediante external tables y funciones de Bigtable, y Dataflow permite ejecutar transformaciones entre sistemas con gestión de estado y escalado automático. Esto reduce la fricción de la modernización: no hay que mover todo el histórico antes de empezar a obtener valor.

La cuarta palanca es la desacoplamiento de la captura y el análisis: Pub/Sub desacopla el sistema de negocio del pipeline de datos, y Dataflow aporta streaming y batch unificados con escalado automático. El dato llega cuando ocurre, no cuando alguien procesa un fichero.

Conviene ser honesto sobre los límites: la nube no arregla una estrategia de datos mala. Si el problema es que la organización no tiene definidos sus indicadores, o que no hay un dueño del dato, cambiar el almacenamiento no lo resuelve; lo que hace es escalar el problema. La nube amplifica tanto la buena como la mala gestión de los datos.

Capacidad de la nube	Problema que resuelve	Servicios de referencia	Valor de negocio observable
Almacenamiento de objetos a escala	Coste de conservar histórico y datos no estructurados	Cloud Storage (Standard, Nearline, Coldline, Archive)	Retención larga a coste bajo; datos previamente descartados disponibles
Analítica serverless sobre datos externos	Mover todo a un warehouse antes de analizar	BigQuery, external tables, BigLake	Time-to-insight sin proyecto de migración previo
Catálogo y zonas de lake	Saber qué dato existe y en qué calidad	Dataplex (zonas, activos, calidad)	Menos tiempo buscando "qué datos tengo"
Captura desacoplada y streaming	Dato disponible en minutos, no en el siguiente batch	Pub/Sub, Dataflow	Decisiones sobre el día, no sobre el mes
Analítica de no estructurado	Extraer señal de documentos, audio, imagen	BigQuery (funciones de archivo, ML), Document AI, Vision AI	Casos de uso antes inviables por coste
Analítica multimotor	Mantener el motor adecuado por tipo de carga	BigQuery, AlloyDB, Bigtable, Spanner	Optimización de coste y de latencia por carga

Ejemplo Práctico

# Vista del lake gestionado y de sus zonas (dónde vive cada tipo de dato)
gcloud dataplex lakes list --project=PROJECT_ID --location=-
gcloud dataplex zones list --project=PROJECT_ID --location=us-central1 \
  --lake=retail-lake
gcloud dataplex assets list --project=PROJECT_ID --location=us-central1 \
  --lake=retail-lake --zone=raw-zone

# Metadatos de los objetos en Cloud Storage (tamaño, clase, fecha de última modificación)
gcloud storage ls gs://raw-retail-landing/ --recursive \
  --format="table(name,size,storageClass,updateTime)"

# Consulta sobre una external table: el dato no se mueve del bucket
gcloud bigquery tables list --project=PROJECT_ID --dataset=lakehouse \
  --filter="type=EXTERNAL" --format="table(tableId,type,description)"

# Catálogo: buscar activos por lenguaje natural
gcloud dataplex entries search "ventas por region" --project=PROJECT_ID --semantic-search

Lectura de la salida en términos de negocio. gcloud storage ls ... --format="table(name,size,storageClass,updateTime)" es, en la práctica, un informe de valor dormido: si aparecen objetos de tamaño relevante con updateTime antigua, ese es el volumen que la organización tiene y no está explotando, y a la vez la factura que se está pagando sin retorno. El filtro --filter="type=EXTERNAL" sobre las tablas de lakehouse revela cuántos datasets se consultan directamente sobre el bucket sin duplicar el almacenamiento: cada external table evitada o creada cambia el perfil de coste de forma medible. Y gcloud dataplex entries search es la prueba de que la democratización del dato depende de un catálogo: si esa búsqueda devuelve "no entries found" o resultados irrelevantes, el problema no es de permisos de acceso, es de que nadie ha descrito qué significa cada activo.

Subtema 5: La gobernanza del dato como requisito del recorrido de datos

Un recorrido de datos exitoso necesita que el dato sea fiable, localizable, trazable y correctamente protegido. Eso es la gobernanza, y no es un añadido posterior: es la infraestructura que permite que el dato llegue a la decisión. Sin ella, el efecto típico es el inverso — más datos accesibles pero menos decisiones confiables.

Los seis componentes que un líder de datos debe reconocer:

Calidad (data quality). Se define con reglas explícitas: completitud (todos los campos obligatorios presentes), validez (los valores cumplen dominio y rango), consistencia (la misma magnitud significa lo mismo en todos los sistemas), frescura (el dato está dentro del umbral de actualización acordado) y unicidad (sin duplicados). La calidad se gestiona con umbrales y monitorización, y con un data steward responsable por área de negocio. En la práctica, un 95% de completitud en un campo que dispara una decisión de crédito es un problema crítico aunque la métrica global de calidad del dataset sea alta.

Metadatos (metadata). Describen el dato: qué contiene, quién lo produce, con qué frecuencia se actualiza, definiciones de campos, unidades, datos sensibles. Los metadatos técnicos (esquema, formato, ubicación) los genera la plataforma; los metadatos de negocio (qué significa, para quién sirve) los tiene que escribir la organización, y esa parte es la que casi siempre falta. Sin metadatos de negocio, cada consumidor interpreta los campos por su cuenta y las cifras divergen.

Linaje (data lineage). De dónde viene cada campo y quién lo consume. Su valor es doble: hacia atrás, para explicar por qué una cifra cambió; hacia adelante, para medir el impacto de un cambio en el modelo o en el pipeline antes de propagarlo. El linaje reduce el tiempo de diagnóstico de incidentes de datos y permite automatizar tests de impacto.

Catálogo (catalog). Es el índice de todo el activo de datos de la organización: qué datasets existen, qué contienen, quién es el dueño, qué calidad tienen, en qué estado de soporte están. Un catálogo sin dueño asignado es una lista de archivos; un catálogo con stewardship es lo que hace que un nuevo analista pueda encontrar el dato correcto en minutos en lugar de en semanas. En Google Cloud, el catálogo de Dataplex (Knowledge Catalog) y las funciones de catálogo de BigQuery dan el plano de gestión; el plano de consumo se resuelve con Looker o Looker Studio.

Control de acceso (access control). No todo el mundo ve todo. El control de acceso se define en dos niveles: quién puede ver qué (IAM a nivel de recurso, con roles como roles/bigquery.dataViewer o roles/dataplex.catalogViewer) y bajo qué condiciones (VPC Service Controls para proteger datos frente a exfiltración, VPC-SC perimeter; condiciones de IAM como la IP de origen). El error típico es dar permisos de conjunto "proyecto completo" por comodidad, lo que hace imposible retirar acceso a una persona que deja la organización sin revisar permisos uno a uno.

Retención y ciclo de vida (retention). Cada conjunto de datos tiene una política: cuánto tiempo se conserva, en qué clase de almacenamiento, cuándo se archiva y cuándo se elimina de forma verificable. Las políticas de retención tienen una razón de negocio (cumplimiento, trazabilidad de una transacción, capacidad de auditoría) y una razón económica (lo que no se usa, no se paga). En Cloud Storage, las clases de almacenamiento y las políticas de lifecycle son el mecanismo; en BigQuery, las tablas particionadas con caducidad de partición (partition expiration) resuelven el mismo problema en la capa analítica.

La gobernanza rara falla por falta de herramienta; falla por modelo operativo. El patrón que funciona es: propiedad del dato asignada a un área de negocio, un conjunto mínimo de políticas transversales (acceso, retención, datos sensibles), y un catálogo que se mantiene como parte del trabajo de los equipos, no como un proyecto paralelo. Cuando la gobernanza se aborda como un proyecto con fecha de fin, se convierte en un documento que nadie actualiza.

Componente	Pregunta que responde	Riesgo si falta	Señal en Google Cloud
Calidad	¿Me puedo fiar de esta cifra?	Decisiones sobre datos defectuosos	Reglas de validación en Dataflow / Dataplex
Metadatos	¿Qué significa este campo?	Interpretaciones divergentes	Descripciones en BigQuery, catálogo Dataplex
Linaje	¿De dónde viene y a quién afecta?	Incidentes sin causa, cambios con impacto oculto	Linaje en BigQuery, grafos en Dataflow
Catálogo	¿Qué datos tengo y quién los usa?	Búsqueda manual, dependencia de personas	Catálogo de Dataplex (Knowledge Catalog)
Control de acceso	¿Quién puede ver qué?	Fuga de datos, acceso que no se puede revocar	IAM, VPC Service Controls
Retención	¿Cuánto tiempo y con qué coste?	Coste descontrolado, riesgo de no retención	Lifecycle en Storage, caducidad de particiones en BigQuery

Ejemplo Práctico

# Quién tiene acceso al proyecto y con qué rol (control de acceso)
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" --format="table(bindings.role,bindings.members)"

# Inventario de activos: base para el catálogo y para el inventario regulatorio
gcloud asset search-all-resources --project=PROJECT_ID \
  --scope=project --format="table(assetType,displayName,location)"

# Política de retención y coste en la capa de objetos
gcloud storage buckets describe gs://raw-retail-landing --project=PROJECT_ID \
  --format="yaml(lifecycle,lifecycleRule,storageClass,labels)"

# Retención en la capa analítica (caducidad de particiones)
gcloud bigquery tables describe retail.events --project=PROJECT_ID \
  --format="yaml(timePartitioning,description,labels)"

# Calidad y catalogación de los activos de datos
gcloud dataplex assets list --project=PROJECT_ID --location=us-central1 \
  --lake=retail-lake --zone=curated-zone \
  --format="table(assetId,assetType,updateTime)"

Lectura de la salida en términos de negocio. gcloud projects get-iam-policy con --flatten="bindings[].members" es el comando que permite responder a la pregunta que siempre hace el responsable de seguridad: ¿quién accede a los datos de clientes y cómo lo revocamos si se van? Si la salida muestra miembros de tipo user: con roles amplios como roles/owner o roles/bigquery.dataEditor concedidos de forma individual, la organización tiene un problema de rotación y de bajas de personal, además de un problema de auditoría. gcloud asset search-all-resources da el inventario que un auditor pide y que la organización normalmente no tiene: cada activo con su tipo y ubicación, lo que permite asignar un propietario y detectar recursos huérfanos. Y la comparación entre la política de lifecycle del bucket y la caducidad de particiones de la tabla revela la incoherencia clásica: el dato analítico se conserva dos años, pero su fuente cruda se conserva cinco, y nadie sabe por qué; eso no es un error técnico, es una política de retención que nunca se escribió.

Subtema 6: Democratización del dato y el cambio en el trabajo de los equipos de datos

La democratización del dato describe el movimiento por el cual el acceso a la analítica se amplía desde un grupo de especialistas hacia la organización completa. Es una consecuencia directa de la nube: si el almacén es un clúster que hay que dimensionar y cablear, el acceso es un problema de capacidad; si el almacén escala solo y se paga por lo consultado, el acceso es un problema de permisos y de catálogo, que es un problema mucho mejor.

El efecto en el trabajo de los equipos de datos es profundo y en dos direcciones. Por un lado, la demanda se desplaza desde "construir la consulta" hacia "garantizar que la consulta sea correcta". El equipo de datos deja de ser una fábrica de informes y pasa a ser el dueño de la capa semántica: métricas canónicas, modelos de datos reutilizables, catálogo, políticas de calidad. Es un trabajo de producto, no de producción de peticiones.

Por otro lado, el perfil de las personas que consume datos cambia. Deja de ser el analista que sabe SQL y el responsable de negocio que espera el informe, y pasa a ser el business user que formula la pregunta en lenguaje natural sobre un modelo ya definido. Herramientas como Looker (y Looker Studio) hacen que esa pregunta se traduzca automáticamente a una consulta sobre el modelo canónico, en lugar de a SQL libre ejecutado contra tablas crudas. El beneficio para la organización es directo —el tiempo entre pregunta y respuesta se reduce— y el riesgo también: si el modelo no está bien diseñado, el error se propaga a todos los usuarios a la vez.

Aparecen, por tanto, nuevos modos de fallo específicos de la democratización:

La brecha de salida de habilidades. Si el acceso se amplía sin un modelo semántico detrás, cada usuario escribe su propia consulta y la organización termina con decenas de versiones de la misma métrica. Esto es exactamente el fracaso que la gobernanza de métricas evita.
La desconexión entre el dato y la decisión. Un dashboard con mucho uso puede seguir sin producir ninguna decisión si no está asociado a un proceso, a un responsable y a un calendario de revisión.
El coste oculto del acceso amplio. La analítica ad hoc sobre datasets brutos puede multiplicar la factura sin que nadie lo note. BigQuery, por ejemplo, factura por bytes escaneados: una consulta mal planificada sobre una tabla de terabytes puede costar más que la infraestructura del mes. El control de coste es parte del trabajo de los equipos de datos.
La erosión de la propiedad del dato. Cuando muchos leen, la pregunta "¿de quién es este dato?" pierde fuerza y las definiciones se degradan.

El trabajo de los equipos de datos tampoco desaparece: cambia de objeto. Antes gestionaban infraestructura y consultas; ahora gestionan confianza. Su entregable no es un informe, es un modelo de datos con dueño, con definiciones, con controles de calidad, con linaje y con control de coste, sobre el que las decisiones se toman de forma repetible. Y esa es exactamente la razón por la que la gobernanza, lejos de ser un obstáculo a la democratización, es su condición necesaria: el acceso masivo a datos no gobernados no produce una organización data-driven, produce una organización con opiniones.

Antes de la democratización	Después de la democratización	Qué debe cambiar para que funcione
El equipo de datos entrega informes	El equipo de datos entrega un modelo canónico	Métricas definidas una vez y reutilizadas
El consumo depende de SQL	El consumo se hace desde el modelo, en lenguaje natural	Capa semántica bien diseñada y versionada
Acceso por capacidad de clúster	Acceso por permisos	IAM granular y catálogo navegable
Calidad asumida por confianza personal	Calidad verificada por reglas y monitorización	Calidad del dato como servicio del equipo de datos
Coste invisible y asignado a un departamento	Coste por dataset y por usuario	Etiquetado, cuotas y analítica de gasto
Pregunta → informe en días o semanas	Pregunta → respuesta en minutos	Modelos precalculados y rendimiento del motor
El dato se usa para reportar	El dato se usa para decidir y actuar	Proceso de decisión explícito y medido

Ejemplo Práctico

# Detectar el patrón "consulta ad hoc sobre datos crudos" y su coste
gcloud bigquery jobs list --project=PROJECT_ID --max-results=50 \
  --format="table(jobReference.jobId,state,totalBytesBilled,creationTime,user_email)" \
  | sort -k4 -r

# Consumo por dataset: qué se usa de verdad y qué es carga dormida
gcloud bigquery datasets list --project=PROJECT_ID \
  --format="table(datasetId,lastModifiedTime,labels)"

# Usuarios con acceso al dato: verificar quién puede democratizar y con qué límites
# (filtrar por rol en la salida: bindings.role = roles/bigquery.dataViewer, etc.)
gcloud projects get-iam-policy PROJECT_ID \
  --flatten="bindings[].members" \
  --format="table(bindings.role,bindings.members)"

# Activos que sí tienen dueño y calidad registrada en el catálogo
gcloud dataplex assets list --project=PROJECT_ID --location=us-central1 \
  --lake=retail-lake --format="table(assetId,assetType,updateTime,labels)"

Lectura de la salida en términos de negocio. La columna totalBytesBilled de gcloud bigquery jobs list es el indicador que conecta la democratización con el coste: si las diez consultas más caras del mes son exploraciones sobre la misma tabla cruda y ninguna es una consulta de negocio concreta, el gasto está financiando curiosidad no canalizada, y la respuesta organizativa es publicar modelos y vistas de uso frecuente en lugar de castigar el acceso con límites. La columna user_email permite además separar el uso legítimo del ruido: un mismo usuario con decenas de jobs diarios y cientos de gigabytes escaneados es, casi siempre, un job programado mal acotado, no una persona analizando. Y la diferencia entre gcloud bigquery datasets list y gcloud dataplex assets list es la métrica de madurez de la democratización: datasets con fecha de modificación reciente y activos catalogados con dueño significa que hay un uso compartido del dato; datasets modificados hace meses significa que existe una plataforma de datos sin usuarios, y el presupuesto que la sostiene debería justificarse en función de los casos de uso que sí la usan.

Temas relacionados: Data Governance, BI and Visualization with Looker · BigQuery and Enterprise Data Warehousing · AI, Machine Learning and Generative AI Fundamentals

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
Data value chain	Cadena que recorre el dato desde la recogida hasta la decisión y la acción, con la medición del resultado como cierre	Al diagnosticar por qué una organización con mucho dato no obtiene valor, o al diseñar un pipeline end-to-end
Insight	Hallazgo comprensible derivado del análisis del dato, formulado de forma que alguien pueda actuar sobre él	En la fase de análisis, como criterio de calidad de un entregable analítico
Base de datos operativa	Almacén optimizado para lectura y escritura de registros individuales con baja latencia y garantías transaccionales	Como fuente de verdad de la aplicación en curso; no para analítica
Data warehouse	Almacén analítico con esquema definido, optimizado para consultas agregadas de respuesta rápida sobre datos históricos	Informes recurrentes, KPIs y BI; cuando las preguntas de negocio ya son conocidas
Data lake	Repositorio de datos en bruto, con o sin estructura, donde el esquema se aplica en el momento de la lectura	Cuando se requiere conservar todo el dato, incluidos formatos no estructurados y semiestructurados
Lakehouse	Data lake con capacidades transaccionales y de aplicación de esquema mediante un motor analítico gestionado	Cuando se necesita la flexibilidad del lake con el rendimiento y el control del warehouse
Curación de datos	Proceso de integrar, normalizar y modelar fuentes heterogéneas en métricas y entidades reutilizables	Como etapa formal del pipeline, en lugar de lógica duplicada en cada consulta
Metadatos de negocio	Descripción del significado, el propósito, la definición y el dueño de un dato o campo	Siempre; son la base para que distintos equipos no interpreten el mismo campo de forma diferente
Data lineage	Trazabilidad del origen y del destino de cada campo y activo	Al depurar discrepancias entre informes y al evaluar el impacto de un cambio de modelo
Data catalog	Índice centralizado de los activos de datos con descripción, propietario, calidad y estado	Cuando la búsqueda de datos es un cuello de botella, y como habilitante de la democratización
Data quality	Conjunto de dimensiones de fiabilidad de un dato: completitud, validez, consistencia, frescura y unicidad	En los puntos de ingestión y antes de exponer un dato a decisión, con umbrales y alertas
Data democratization	Ampliación del acceso a la analítica desde especialistas hacia toda la organización	Cuando la capacidad de la plataforma ya no limita el acceso y el catálogo y la semántica están maduros
Capa semántica	Modelo de datos canónico que traduce preguntas de negocio en consultas consistentes	Antes de permitir acceso amplio; es lo que evita la proliferación de métricas divergentes
Retención de datos	Política que define cuánto tiempo se conserva cada conjunto de datos y a qué coste	Cuando hay requisitos regulatorios, de auditoría o de reconstrucción de histórico
BigQuery	Data warehouse serverless de Google Cloud, con separación entre almacenamiento y cómputo y analítica sobre datos externos	Analítica de negocio, BI y exploración sobre terabytes sin gestionar clúster
BigLake	Capacidad de BigQuery para consultar y gestionar tablas sobre datos en Cloud Storage con control de acceso	Volumen alto o retención larga, donde el coste de almacenamiento importa
Dataplex	Plataforma de gestión del lake: zonas, activos, calidad de datos y catálogo	Cuando el lake deja de ser un bucket y hay que operarlo como producto de datos
Pub/Sub	Servicio de mensajería asíncrona que desacopla productores y consumidores de eventos	Captura en tiempo real de eventos de negocio sin acoplar la aplicación al pipeline
Dataflow	Servicio gestionado de procesamiento de datos en streaming y por lotes, con escalado automático	Pipelines de ingestión, transformación y carga analítica sin gestionar infraestructura
Looker	Plataforma de BI donde las decisiones de negocio se modelan una vez y se reutilizan en todas las visualizaciones	Business intelligence self-service sobre un modelo canónico, con control de acceso heredado del modelo

Comparaciones

Database, warehouse y lake: la comparación que decide la arquitectura del dato

Eje	Database operativa	Data warehouse	Data lake
Optimización principal	Escritura y lectura por registro	Lectura analítica de agregados	Amplitud y retención
Modelo de datos	Relacional o clave-valor, esquema estricto	Star schema, tipado y agregado	Flexible, aplicado en lectura
Interacción típica	CRUD desde la aplicación	Consultas SQL sobre modelos	Exploración y preparación de datos
Latencia objetivo	Milisegundos	Segundos	Segundos a minutos
Perfil de coste	Por instancia y por IOPS	Por bytes escaneados y almacenamiento	Por almacenamiento y por consulta
Relación con la fuente	Es la fuente de verdad	Es una copia derivada y consolidada	Es la copia cruda y original
Consecuencia de la ausencia	Se rompe la aplicación	Faltan datos en el histórico	Se pierde el histórico: es irrecuperable
Ejemplo en Google Cloud	Cloud SQL, AlloyDB, Spanner, Bigtable, Firestore	BigQuery	Cloud Storage con BigLake, Dataplex
Cuándo no usarlo	Cuando la consulta es analítica masiva	Cuando se necesita conservar todo en bruto y el esquema es cambiante	Cuando se requiere transaccionalidad y latencia mínima

Tres vías de creación de valor con datos

VÍA	Qué habilita	Esfuerzo de instrumentación	Valor esperado	Riesgo principal
Explotar datos actuales	Mejorar decisiones ya existentes con más granularidad o frescura	Bajo: el dato ya existe	Rápido y predecible	Subestimar el valor: se busca una nueva fuente en vez de profundizar en la actual
Recoger datos nuevos	Instrumentar puntos de contacto antes no medidos	Medio: instrumentación y eventos	Alto si el dato es accionable	Capturar mucho sin usar nada
Acceder a fuentes externas	Enriquecer con contexto de mercado o de terceros	Medio: integración y licencias	Alto, con dependencia contractual	Coste de licencia y disponibilidad del proveedor

Lakehouse frente a warehouse y frente a lake puro

Eje	Warehouse	Lakehouse	Lake puro
Dónde vive el dato	En el motor analítico	En almacenamiento de objetos	En almacenamiento de objetos
Coste de almacenamiento	Alto por TB	Bajo por TB	Bajo por TB
Coste de consulta	Solo cómputo	Cómputo más metadatos	Cómputo más metadatos
Transaccionalidad	Sí	Creciente, variable por motor	No
Madurez operativa	Alta	Media-alta, dependiente del motor	Baja: exige gobernanza activa para ser usable
Riesgo principal	Rigidez ante preguntas nuevas	Complejidad de configuración de permisos y metadatos	Obsolescencia del dato por desuso

Errores Comunes

Error: Confundir el data lake con un almacén de archivos donde "guardar" ya es "tener el dato", y dar por cerrada la etapa de datos. → Solución: Tratar el lake como una zona de aterrizaje, no como un destino final. Cada activo necesita dueño, descripción, calidad medida, política de retención y un caso de uso identificado; sin esos atributos, el bucket es un archivo muerto que genera coste y riesgo regulatorio sin producir ninguna decisión.
Error: Llevar las consultas analíticas a la base de datos operativa porque es "el sistema que ya tenemos", saturando la instancia y degradando la aplicación. → Solución: Separar el camino transaccional del camino analítico desde el diseño: la base de datos operativa sigue siendo la fuente de verdad para la aplicación, y BigQuery se alimenta desde ella (o desde el lake) mediante extracciones o streaming. La señal de alarma es clara: latencia de consulta en la instancia de producción correlacionada con la presencia de jobs analíticos.
Error: Entregar dashboards y análisis sin cerrar el ciclo de decisión, o peor, medir el éxito del programa por el número de informes publicados. → Solución: Asociar cada entregable analítico a un proceso de negocio, un responsable y un indicador, y registrar el resultado de la acción para poder comparar contra la línea base. Un informe sin decisión asociada es una hipótesis sin verificar, y el valor real de un programa de datos solo se demuestra en la etapa de medición de la cadena de valor.
Error: Ampliar el acceso a los datos sin un modelo semántico ni un catálogo, confiando en que "si lo ven, lo usarán bien". → Solución: Publicar primero las métricas canónicas y la capa semántica (vistas y modelos en BigQuery, modelos en Looker), con definiciones escritas y acceso restringido a los datos de referencia; después ampliar el consumo en modo self-service sobre esa capa. Si se abre el acceso a las tablas crudas primero, el resultado predecible es la proliferación de versiones divergentes de la misma métrica y la pérdida de confianza en el dato.
Error: Tratar la gobernanza como un proyecto documental con fecha de cierre, o como un control que se aplica al final sobre datos ya publicados. → Solución: Incorporar los controles de calidad, el linaje y las políticas de acceso en la propia línea de producción de datos (reglas en Dataflow, descripciones y expiración en BigQuery, IAM y lifecycle en Cloud Storage, catálogo en Dataplex). La gobernanza que no está automatizada se erosiona; y un catálogo sin dueño asignado es una lista de archivos en lugar de un mecanismo de confianza.

Puntos para el Examen

🎯 Punto clave 1: La cadena de valor del dato (data value chain) es el marco que ordena todo el dominio: recogida, almacenamiento, preparación, calidad, análisis, visualización, decisión y acción, cerrada por la medición del resultado. En el examen, el tipo de pregunta habitual presenta un escenario de una organización con datos pero sin valor y pide identificar dónde está el fallo. Sabe razonar por etapa, no memorizar la lista: el cuello de botella casi nunca está en el almacenamiento.

🎯 Punto clave 2: La comparación database, warehouse y lake debe resolverse por patrón de acceso, no por volumen. Base de datos operativa = fuente de verdad transaccional de baja latencia; data warehouse = analítica agregada de esquema definido sobre histórico; data lake = conservación amplia de datos crudos, estructurados y no estructurados, con esquema aplicado en lectura. Dominar esta distinción te permite responder sin ambigüedad a las preguntas que presentan cuatro o cinco servicios de Google Cloud y te pide encajar el servicio con el tipo de dato y el caso de uso.

🎯 Punto clave 3: La gobernanza del dato no es un tema de cumplimiento accesorio, es un requisito de funcionamiento: calidad, metadatos, linaje, catálogo, control de acceso y retención. En un escenario, el error de gobernanza (acceso demasiado amplio, catálogo vacío, ausencia de dueño del dato) es tan diagnosticable como el error técnico, y la respuesta esperada es la que identifica el componente de gobernanza y propone el control concreto en la plataforma.

🎯 Punto clave 4: La nube habilita valor sobre todo tipo de dato, incluidos los no estructurados, mediante almacenamiento económico a escala, analítica serverless sobre datos externos sin moverlos, captura desacoplada con Pub/Sub y Dataflow, y la convergencia de lake y warehouse en lakehouse. El argumento de negocio es que el coste marginal de explorar datos antiguos o no estructurados baja de forma que hace viable preguntar cosas nuevas con frecuencia.

🎯 Punto clave 5: La democratización del dato cambia el trabajo de los equipos de datos: de producir consultas a gestionar un modelo canónico, un catálogo y la confianza en las cifras. Sus riesgos característicos son la proliferación de métricas divergentes cuando no hay capa semántica, el crecimiento del coste de consulta sin control, y la desconexión entre el dato y la decisión. En el examen, saber que democratizar exige gobierno previo es lo que distingue una respuesta sólida de una respuesta genérica.

Recursos Externos

Big data and analytics resources (Cloud Architecture Center) — Punto de entrada a los recursos de arquitectura de datos: data mesh, plataformas de autoservicio e ingesta segura en BigQuery.
BigQuery: overview del data warehouse serverless — Cómo separa almacenamiento y cómputo BigQuery, cómo factura y qué significa operar sin clúster.
BigQuery: external tables y BigLake — Cómo consultar datos en Cloud Storage, otra nube o bases de datos sin moverlos, base técnica del lakehouse.
Dataplex: catálogo de datos (Knowledge Catalog) — Metadatos, linaje, glosarios, calidad y búsqueda de activos: el plano de gestión de la gobernanza.
Cloud Storage: clases de almacenamiento — Referencia para las políticas de retención y coste del dato en la capa de objetos.

Autoevaluación Rápida

Pregunta: Una empresa tiene su ERP en Cloud SQL, unos 12 TB de exportaciones históricas en un bucket de Cloud Storage y unos dashboards construidos sobre BigQuery. No hay nadie que pueda decir qué datos existen. ¿Cuál es el problema de negocio y qué lo resolvería? Respuesta: El problema no es la falta de datos ni la falta de motor; es la ausencia de un catálogo y de la propiedad del dato. Un bucket sin descripción es un coste dormido y un riesgo: nadie sabe qué contiene, quién lo usa ni si se puede eliminar, y el resultado típico es que se acumula sin explotarse o que se duplica en cada equipo. Lo resolvería un catálogo sobre Dataplex que registre activo, descripción, dueño, calidad y retención, acompañado de un trabajo de catalogación priorizado por los datasets que alimentan decisiones reales, y de una revisión de lifecycle en el bucket para lo que nadie usa. La conclusión relevante aquí es que añadir BigQuery o más capacidad no habría cambiado nada.
Pregunta: El comité pide "las ventas por categoría los últimos tres años" y el equipo tarda dos semanas. ¿Dónde está, con más probabilidad, el cuello de botella de la cadena de valor? Respuesta: En la etapa de preparación o en la de calidad, no en el almacenamiento. Dos semanas para una consulta sobre histórico que ya está en un motor serverless indica que el modelo no existe: cada petición implica reconstruir la lógica a mano, resolver duplicados entre sistemas y validar cifras a posteriori. La corrección es invertir en la capa de preparación —modelos de datos reutilizables, métricas canónicas y reglas de calidad automatizadas— y publicar esa capa para que el tiempo de respuesta caiga a minutos. La pregunta que hay que devolver al negocio es si esas dos semanas se traduzcan en una decisión distinta o en el mismo informe de siempre.
Pregunta: Un director de negocio pide acceso a la tabla de clientes para "analizar por su cuenta". ¿Qué recommendas? Respuesta: No abrir la tabla cruda; publicar el modelo. Conceder acceso directo a la base de clientes además de generar riesgo regulatorio (datos personales, decisiones de crédito o marketing que se explican mal) y ruido analítico: se producirán versiones divergentes de la misma métrica. Lo correcto es definir las métricas canónicas de cliente en una vista o un modelo con descripciones, conceder acceso de lectura sobre esa capa, y habilitar el consumo self-service con Looker sobre el modelo. Además, hay que etiquetar los datos sensibles y limitar el acceso con IAM por rol, porque "el director de negocio" es un rol, no una persona: la política debe depender del rol, no del individuo.
Pregunta: ¿Qué distingue un data lake de un lakehouse, y por qué importa la distinción para el coste? Respuesta: El lake guarda datos crudos sin modelo fijo y sin control transaccional; el lakehouse añade al almacenamiento de objetos la capacidad de aplicar esquema, indexar y servir consultas analíticas con semántica transaccional, típicamente mediante BigQuery y BigLake. La distinción importa porque el coste se desplaza: en un lake puro, el coste dominante es el almacenamiento y la penalización por escaneo mal planificado; en un lakehouse bien configurado, con particionamiento y clustering, se paga por las columnas consultadas. En la práctica, la elección es de negocio: lakehouse es más caro en complejidad de configuración pero mucho más barato en coste de consulta cuando el volumen es alto y la analítica es recurrente.
Pregunta: Una organización lleva dos años usando un dashboard de ventas en Looker. Se publica cada semana y casi todos lo miran, pero ningún proceso ha cambiado desde que existe. ¿Qué le dirías a la dirección? Respuesta: Que tiene el tramo final de la cadena de valor (visualización) pero no el tramo de decisión y acción, y que el programa de datos no puede demostrar retorno por eso. La señal no es el uso del dashboard, sino la ausencia de decisión documentada y ejecutada a partir de él. El plan de acción es asociar cada vista a una decisión recurrente con responsable, revisar las decisiones que se han tomado y si el dato influyó, y medir el resultado contra la línea base. Si tras ese ejercicio las decisiones siguen sin cambiar, la conclusión honesta es que el dashboard sobra: sustituirlo por una métrica concreta y un proceso de gestión es más valioso que mantener la infraestructura.