BigQuery and Enterprise Data Warehousing

Resumen

BigQuery es el data warehouse serverless de Google Cloud: un motor de analítica gestionado en el que no se administran clústeres, no se dimensionan servidores y no se negocia con el plano de datos, sino que se escriben consultas SQL y se cobraron por el uso que esas consultas producen. Este tema estudia su arquitectura y, sobre todo, sus consecuencias de negocio: por qué la separación entre almacenamiento y cómputo cambia el modelo de coste y de capacidad, cómo se extiende el analítica a datos que viven en otras nubes o en un data lake, cómo se entrenan y ejecutan modelos de machine learning con SQL estándar, cómo se gobiernan los datos dentro de la plataforma y qué perfiles de usuario conviven sobre el mismo dataset con permisos distintos.

El argumento de negocio que sostiene todo el tema es que BigQuery no sustituye a la base de datos transaccional, sino que libera a la organización del histórico. Cuando el histórico se puede consultar con la misma facilidad con la que se inserta, el número de preguntas que el negocio le hace al dato deja de estar limitado por la capacidad de un warehouse tradicional, y eso es lo que convierte la analítica en un ciclo habitual en lugar de un proyecto anual.

Se cubren además los casos de uso que aparecen de forma recurrente en los escenarios del examen: reporting operativo, análisis de ingresos, customer 360, detección de fraude y previsión de demanda, cada uno con su patrón de consulta, su latencia objetivo y su coste dominante.

Objetivos de Aprendizaje

Explicar qué significa que BigQuery sea un data warehouse serverless y en qué se diferencia de un warehouse autohospedado o de un servicio gestionado con nodos visibles.
Describir la separación entre almacenamiento y cómputo, y por qué cambia el modelo de coste (on-demand frente a slots por edición) y el modelo de capacidad de una organización de datos.
Identificar las opciones de analítica multicloud: tablas externas, BigLake y el Data Lake de Google Cloud, y cuándo conviene consultar datos sin moverlos.
Describir BigQuery ML: cómo se crean, entrenan y evaluan modelos de machine learning con SQL estándar, y qué tipos de modelo admite.
Enumerar los mecanismos de gobernanza del dato en BigQuery: datasets, particionado, clustering, vistas materializadas, row access policies, seguridad a nivel de columna y residencia de datos.
Diferenciar los roles de analista, ingeniero de datos y consumidor de negocio, y asociar a cada uno un conjunto de permisos, tareas y resultados en BigQuery.
Resolver un escenario de negocio (reporting, revenue analysis, customer 360, fraude o forecasting) seleccionando el enfoque de BigQuery adecuado y justificando coste, latencia y gobierno.

Contenido Principal

Subtema 1: BigQuery como data warehouse serverless

La diferencia estructural entre BigQuery y un data warehouse clásico no está en el lenguaje SQL ni en la capacidad de agregación: está en quién se ocupa del plan de ejecución y del hardware. Un warehouse tradicional —propio o en un servicio gestionado tradicional— expone un clúster. Sobre ese clúster hay que decidir cuántas máquinas, con cuánta CPU, cuánta memoria y qué disco, y esa decisión se toma con antelación, normalmente por el equipo que proyecta la carga del trimestre siguiente. Cada pregunta nueva que llega a la cola de un clúster saturado compite por los mismos recursos que ya están comprometidos con el reporting de la semana anterior.

BigQuery elimina el plano de control del cliente. El servicio se encarga del almacenamiento, del escalado del cómputo, de la distribución de los datos y de la ejecución de las consultas. El usuario escribe SQL y recibe un resultado. No hay nodos que dimensionar, ni particiones que redistribuir, ni un mantenimiento que programar, ni un clúster que quede por debajo de su capacidad justo en el mes de cierre contable.

Esa es la definición operativa de "serverless" en este contexto: no significa que el cómputo no exista, significa que el cómputo se aprovisiona just-in-time, se factura por el trabajo realmente realizado y desaparece cuando la consulta termina. La consecuencia práctica es doble. La primera es de capacidad: la organización no tiene que anticipar la demanda, porque la capacidad disponible se ajusta al tamaño de la consulta en curso. La segunda es de coste: la factura sigue al uso, no al inventario de infraestructura, de modo que una organización que hace pocas consultas grandes paga por esas consultas y no por un warehouse sobredimensionado que espera.

Sobre esta base, BigQuery se posiciona como motor de analítica gestionado con un conjunto de capacidades que lo separan de una simple base de datos SQL. Trabaja con almacenamiento columnar: los datos se comprimen por columna, no por fila, y una consulta que necesita tres columnas de una tabla de doscientos solo lee esas tres columnas. Esa es la razón técnica por la que el modelo de facturación por bytes escaneados es razonable: lo que se cobra es lo que realmente se necesita leer.

El motor ofrece además un dialecto SQL estándar con funciones de ventana, arrays, structs y funciones de fecha que cubren el 95 % de la analítica de negocio, y un modelo de esquema opcional y flexible que evita el ciclo de tickets de migración cada vez que la fuente de datos añade una columna. BigQuery también admite streaming: un INSERT o una MERGE desde una herramienta de eventos entra en la tabla sin necesidad de un proceso por lotes intermedio, lo que permite pasar de un reporting por lotes a un panel casi en tiempo real sin cambiar de motor.

Conviene encuadrar qué es BigQuery y qué no es. No es la base de datos transaccional de la aplicación: la latencia por consulta, el modelo de coste y la ausencia de índices secundarios apuntales lo hacen inadecuado para leer y escribir registros individuales en el camino crítico de un checkout. Tampoco es un lago de datos: BigQuery no sustituye a Cloud Storage como almacén barato de histórico bruto, sino que lo consume. Su territorio es el data warehouse analítico: preguntas sobre agregados, histórico, cohortes y joins a escala.

La escala real es otro elemento que conviene tener presente. BigQuery está diseñado para consultar tablas con miles de millones de filas y, en la modalidad Enterprise, petabytes. Ese salto de escala no es un dato de marketing: es lo que hace viable el patrón de "no filtrar el histórico en la ingestión, filtrar en la consulta". La consecuencia es que el diseño de la ingested data cambia: en lugar de decidir de antemano qué resúmenes guardar, se guarda el detalle y cada pregunta se resuelve con una agregación. El coste de esa flexibilidad es que la disciplina de particionado y clustering pasa a ser la palanca de control de gasto.

Subtema 2: Separación de almacenamiento y cómputo, on-demand, slots y el modelo de precio

El detalle técnico que explica casi todo lo demás de BigQuery es que el almacenamiento de datos y el cómputo de consultas son recursos separados y facturados de forma separada. Las columnas de la tabla se guardan en almacenamiento gestionado, con un coste asociado al volumen almacenado y a su antigüedad, independientemente de si se consultan. El cómputo, en cambio, se paga por el trabajo de la consulta. Nadie mantiene un warehouse encendido esperando que alguien pregunte algo, y nadie paga por un warehouse apagado que no se enciende.

Sobre esa separación se construyen dos modos de facturación, y entenderlos es indispensable para el examen y para cualquier conversación de presupuesto con un director financiero.

Modo on-demand (pay as you go). Se factura por el trabajo realizado: principalmente los bytes escaneados por la consulta, con precios diferenciados según la región y con una pequeña componente por T bytes procesados en las primeras filas de cada consulta, más el coste de los servicios auxiliares que la consulta use (por ejemplo, funciones de usuario definidas o ML). No hay commitment ni capacidad reservada. Es el modo por defecto, el adecuado para la organización que todavía no conoce su carga —el propio caso de uso del examen— y el modo en el que el coste de una consulta se puede anticipar razonablemente: se sabe qué columnas se van a escanear y, por tanto, qué volumen se va a procesar.

Modo de capacidad (ediciones con slots). Se reserva una capacidad fija de cómputo —medida en slots, donde un slot representa una cantidad determinada de capacidad de vCPU y memoria— y se paga por esa capacidad reservada, con opción de pago por uso dentro de lo reservado y con compromiso de pago anual o mensual. BigQuery ofrece ediciones con características distintas —Standard, Enterprise y Enterprise Plus—, que difieren en rendimiento de la gestión de recursos y en capacidades disponibles como la ejecución de inferencias de machine learning dentro de la propia consulta. La edición Enterprise Plus se posiciona para cargas de machine learning y analítica en tiempo real donde el entrenamiento y la inferencia comparten el mismo motor.

Dimensión	On-demand (pay as you go)	Capacidad reservada (ediciones con slots)
Unidad de facturación	Bytes escaneados y trabajo ejecutado	Slots de cómputo reservados por periodo
Compromiso	Ninguno	Mensual o anual, con descuento por compromiso
Previsibilidad de la factura	Alta por consulta, variable en el agregado	Alta y fija, con coste por capacidad reservada
Riesgo principal	Sorpresa de coste si las consultas escanean mucho	Capacidad pagada y no usada
Encaje típico	Carga irregular, estacional o en fase de adopción	Carga estable y sostenida, con un pico también estable
BigQuery ML	Disponible	Disponible, con capacidad reforzada en Enterprise Plus
Criterio de decisión	Empezar aquí, medir y luego decidir	Migrar cuando el gasto on-demand es estable y alto y hay commitment

El precio concreto del slot, el coste por TiB escaneado y los umbrales de coste libre cambian por región y por periodo, de modo que cualquier cifra concreta debe verificarse contra la página oficial de precios. Lo que sí es estable y conceptual es la forma de razonar: el on-demand factura por trabajo, el modelo de slots factura por capacidad, y la decisión de negocio es pasar del primero al segundo cuando la demanda se ha estabilizado y el gasto ya se conoce, porque en ese punto el compromiso anual compra un descuento que el on-demand no puede igualar.

Lo relevante para el examen es la consecuencia, no el número. La separación almacenamiento-cómputo transforma la capacidad de un almacén de datos en algo elástico: la organización puede pasar de veinte a doscientas consultas concurrentes sin comprar hardware, y paga solo por las que ejecuta. Transforma también el coste de la retención: guardar histórico en Cloud Storage y consultarlo mediante BigLake o tablas externas permite mantener el dato barato y, al mismo tiempo, recuperarlo con potencia analítica. Y transforma la conversación con el equipo de infraestructura: no hay un proyecto de ampliación de warehouse, porque no hay un warehouse que ampliar.

Un segundo efecto, menos evidente, es sobre el diseño de la organización de datos. Cuando el cómputo es marginal y el almacenamiento se paga por volumen, la práctica cambia: se conservan más datos crudos (y se acepta el coste de almacenamiento, que es el más barato de los dos), se particionan las tablas para que cada consulta toque solo lo necesario, y se evita la proliferación de tablas resumen precalculadas que en un warehouse tradicional era la forma de "no pagar" cómputo. Esa última consecuencia conecta directamente con las vistas materializadas, que en BigQuery funcionan como un mecanismo de rendimiento y de precio, no como un sustituto del particionado.

Subtema 3: Analítica multicloud: tablas externas, BigLake y el Data Lake de Google Cloud

La mayoría de las organizaciones no tiene todo su dato en un solo sitio. Parte está en Google Cloud, parte en AWS o Azure, parte en un sistema de archivos corporativo o en un lago de datos en el que conviven formatos columnales. BigQuery no exige que esa realidad desaparezca: puede consultarla directamente mediante tablas externas, sin mover los archivos.

Una tabla externa es una definición que apunta a datos que BigQuery no almacena. La tabla guarda solo el esquema y los metadatos; los bytes permanecen en el origen, que puede ser un bucket de Cloud Storage, un bucket de Amazon S3, un blob de Azure Storage o incluso un archivo local en un nodo autoalojado. BigQuery lee esos bytes en el momento de la consulta, aplica los filtros y las proyecciones, y devuelve el resultado. La diferencia con una tabla nativa es conceptual y económica: el almacenamiento se paga al proveedor del origen, al precio de su almacenamiento de objetos, y BigQuery cobra por el trabajo de la consulta, no por el volumen retenido.

-- Tabla externa sobre datos en AWS S3, con conexión gestionada
CREATE EXTERNAL TABLE `sales_analytics.events`
WITH CONNECTION `aws.us-east1.connection`
OPTIONS (
  format = 'PARQUET',
  uris = ['s3://acme-events/events/*']
);

-- Consulta sobre el dato externo, combinada con datos nativos
SELECT event_date, COUNT(*) AS eventos, COUNT(DISTINCT user_id) AS usuarios
FROM `sales_analytics.events`
WHERE event_date >= DATE_SUB(CURRENT_DATE(), INTERVAL 30 DAY)
GROUP BY event_date
ORDER BY event_date;

La salida de esa segunda consulta son, fila a fila, el volumen de eventos diarios y los usuarios activos de los últimos treinta días: el dato de negocio que alimenta el panel de uso del producto sin que ningún evento haya salido de su bucket de origen.

BigLake es la extensión que convierte la tabla externa en un mecanismo operativo a escala. BigLake permite conectar BigQuery directamente con el almacenamiento de objetos de Google Cloud, con almacenamiento de objetos de otras nubes y con sistemas de archivos, y lo hace con un plano de control de datos (el metastore) que BigQuery gestiona, de modo que ya no hace falta mantener un catálogo de Hive externo. BigLake añade capacidades que una tabla externa simple no da: unificación de metadatos y control de acceso, es decir, los permisos se aplican sobre el catálogo central de BigQuery y no sobre permisos de bucket; actualizaciones de datos in situ, que permiten modificar o borrar filas en el archivo de origen sin reescribir el conjunto; y mejora del rendimiento de la consulta mediante la gestión automática de archivos, que compacte y optimiza los ficheros en segundo plano.

El Data Lake de Google Cloud es el nombre del patrón de arquitectura, no de un producto único: la combinación de Cloud Storage como almacenamiento barato de histórico en formatos columnales, BigQuery como motor de consulta serverless sobre esos datos mediante BigLake, Dataflow para la ingesta y la transformación, Pub/Sub para la captura de eventos y Dataplex para el catálogo y la linaje. La propiedad interesante de este patrón es que el data lake no es un archivo muerto esperando a un data scientist: es el mismo conjunto de datos que BigQuery consulta con SQL, y por tanto es accesible para el equipo de reporting sin la fricción de un clúster de Spark.

Hay una decisión de negocio escondida en este diseño, y es la comparación entre copiar y consultar en el sitio. Traer el dato a BigQuery significa copiarlo, pagar su almacenamiento dos veces (una en el origen, otra en el warehouse) y asumir el coste y la latencia de la ingesta. Consultarlo en el sitio significa no moverlo, pero pagar por cada lectura. La respuesta cambia según la frecuencia: si el dato se lee una vez al mes, la copia fija puede salir más barata; si se lee a diario o por varias équipes a la vez, la lectura en el sitio evita duplicar el almacenamiento y mantiene una única copia, que es también la posición de gobernanza.

Además, el acceso multicloud de BigQuery tiene una variante práctica que conviene distinguir: BigQuery Omni, que permite ejecutar consultas BigQuery directamente contra réplicas de datos en Regions y Zones de otros proveedores cloud (por ejemplo, en servicios de AWS o Azure), con el motor de ejecuciónymp cerca del dato. La diferencia con la tabla externa es de naturaleza: la tabla externa lee objetos desde Cloud Storage o desde el bucket del otro proveedor, mientras que BigQuery Omni consulta directamente la base de datos analítica del proveedor, sin necesidad de mover los datos previamente. La utilidad de negocio es la reducción de la latencia de la salida de datos transfronteriza y la posibilidad de mantener la residencia del dato donde la regulación lo exige, sin renunciar a un único estándar de SQL para el análisis.

Subtema 4: BigQuery ML: machine learning dentro del warehouse

BigQuery ML elimina el salto que obliga a exportar el dataset a un entorno externo, escribir un entorno de Python, entrenar el modelo fuera de la plataforma y volver a importar las predicciones. Con BigQuery ML, la creación, el entrenamiento y la evaluación de un modelo se expresan en sentencias SQL estándar que se ejecutan dentro del propio warehouse, y el resultado es un modelo almacenado en el proyecto que se invoca desde una consulta con la misma sintaxis SELECT.

-- Entrenamiento de un modelo de regresión logística directamente en SQL
CREATE OR REPLACE MODEL `sales_analytics.churn_model`
OPTIONS (
  model_type = 'LOGISTIC_REGRESSION',
  input_label_cols = ['churned'],
  data_split_method = 'AUTO_SPLIT'
) AS
SELECT
  tenure_months,
  monthly_spend,
  support_tickets,
  churned
FROM `sales_analytics.customers_train`;

-- Uso del modelo: scoring en la misma consulta de reporting
SELECT
  customer_id,
  churned AS Probabilidad_actual,
  predicted_churned AS Probabilidad_predicha
FROM ML.PREDICT(MODEL `sales_analytics.churn_model`,
  (SELECT * FROM `sales_analytics.customers_scoring`));

La primera sentencia crea el modelo, lo entrena sobre los datos de entrenamiento con partición automática de train/validación y lo deja disponible en el catálogo. La segunda sentencia aplica el modelo entrenado a un conjunto de clientes y devuelve la probabilidad predicha de abandono junto a la probabilidad observada, que es exactamente la comparación que un director de negocio necesita para decidir si el modelo aporta valor.

La familia de modelos que admite BigQuery ML cubre los casos de uso habituales del analítico de negocio. Los modelos de regresión (regresión lineal y logística) resuelven scoring de riesgo, propensión a la compra y detección de fraude mediante umbrales. Los modelos de clasificación (K-Means, k-NN) resuelven segmentación de clientes y agrupamiento de comportamientos. Los modelos de árboles de decisión (boosting con XGBoost, LightGBM, sklearn) resuelven problemas tabulares con interacciones complejas. Los modelos de series temporales resuelven previsión de demanda. Los modelos de embeddings (Vertex AI) permiten indexar contenido y buscar por similitud semántica, que es la base de la búsqueda por significado en catálogos o documentos. BigQuery ML también se integra con modelos alojados en Vertex AI, lo que permite que un modelo de Vertex AI se invoque desde una consulta de BigQuery y que sus resultados se exploren con SQL.

Lo importante para el examen es la consecuencia de negocio, no la sintaxis. BigQuery ML reduce el tiempo entre el dato y el modelo y, sobre todo, reduce el número de personas distintas que intervienen. Un analista de negocio que sabe SQL puede construir un modelo de propensión o un segmentador sin depender de un equipo de ciencia de datos que tenga que preparar el entorno. Eso no significa que BigQuery ML sustituya a Vertex AI: Vertex AI es la plataforma para modelos de deep learning a escala, entrenamiento distribuido y despliegue de modelos en servicio; BigQuery ML es la vía para modelos tabulares y analítica cercana al dato, con la ventaja operativa de que el modelo vive junto al dato y se actualiza con la misma agilidad con la que se actualiza la tabla.

Hay un segundo beneficio, más silencioso: la reproducibilidad. Un modelo creado con una sentencia SQL versionada en el repositorio del equipo se puede reconstruir exactamente, y la inferencia se hace sobre la misma definición de datos que la consulta de reporting. Si el modelo vive en un notebook de Python con dependencias no declaradas, la reproducibilidad depende de que alguien se acuerde de guardar el entorno.

Subtema 5: Gobernanza del dato dentro de BigQuery

La gobernanza no es un añadido de BigQuery: es lo que hace que un warehouse compartido por toda la organización pueda existir sin convertirse en un riesgo. Los mecanismos se aplican en capas, desde la organización de los datos hasta el control de la última fila.

Datasets como unidad de gobierno. Un dataset es el contenedor lógico de tablas, vistas y funciones, y es también la unidad de permisos y de facturación. La convención de nombres —projecto, entorno, dominio, granularidad— es la forma más barata de gobierno que existe: un dataset llamado prod_sales_curated comunica el propósito, el entorno y el nivel de madurez de los datos a cualquiera que abra el catálogo. En las organizaciones grandes, el dataset se convierte en la frontera de propiedad: cada dataset tiene un equipo dueño, y ese equipo es responsable de la calidad, del esquema y de la documentación de sus tablas.

Particionado. BigQuery divide las tablas en particiones —por defecto por fecha de ingestión, pero también por un campo fecha propio de la tabla— y una consulta con filtro de partición solo lee las particiones implicadas. El efecto es directo: una consulta sobre un histórico de dos años filtrada por las últimas 24 horas lee horas de datos, no dos años. El particionado es, por tanto, la primera palanca de coste y de latencia, y su ausencia es el error más caro que se puede cometer en una tabla grande.

Clustering. El clustering ordena los datos por una o más columnas de alta cardinalidad, de forma que las filas con valores cercanos quedan en el mismo bloque. Reduce el número de bloques que hay que leer cuando la consulta filtra o agrupa por esas columnas. No sustituye al particionado: el particionado decide qué particiones se abren y el clustering decide qué bloques se leen dentro de ellas. La combinación de particionado por fecha y clustering por cliente, por ejemplo, hace que la consulta "pedidos de un cliente en un mes" lea una partición y muy pocos bloques.

Vistas materializadas. Una vista materializada es un resultado precalculado y almacenado, que se actualiza de forma explícita o mediante actualización incremental. Su función en BigQuery no es la de sustituir al modelo estrella, sino la de acelerar un cálculo caro que se repite: agregados de varios join, métricas de negocio calculadas sobre millones de filas. En un warehouse tradicional, ese cálculo se materializaba en una tabla resumen; en BigQuery, la vista materializada ofrece la misma velocidad de lectura con menos gestión, y además reduce el número de bytes que la consulta de reporting tiene que escanear, con impacto directo en la factura. Su coste es que ocupa almacenamiento y que, si se actualiza sin control, puede devolver un dato desactualizado respecto a la tabla base.

Row access policies. Una row access policy filtra filas a nivel de tabla por usuario o grupo, sin que el usuario tenga que escribir la condición en la consulta y sin necesidad de duplicar la tabla. Es la respuesta al caso de negocio más habitual en entornos con datos sensibles: un analista regional solo puede ver las filas de su región; un equipo de atención al cliente solo ve las cuentas que tiene asignadas; un comité de auditoría ve todo pero solo un subconjunto de columnas. La política se define en SQL DDL, es un objeto versionable y auditable, y se aplica junto a los permisos de dataset, de modo que el usuario no puede esquivarla escribiendo una consulta con filtro distinto: la política se aplica después de los permisos y de forma vinculante.

Seguridad a nivel de columna y protección de datos sensibles. BigQuery permite ocultar columnas sensibles a ciertos usuarios mediante column-level security y aplicar políticas de enmascarado dinámico (dynamic data masking), que sustituyen el valor real por un enmascarado o tokenización determinista en el momento de la consulta según quién la ejecuta. Esto permite que el mismo dataset sirva a un equipo de analítica y a un conjunto de informes compartidos con terceros sin duplicar los datos ni ocultar la columna a los que sí la necesitan. En la práctica, este mecanismo se combina con la clasificación del dato y con políticas de retención: la parte superior del dato con PII tiene una fecha de expiración, y la organización no tiene que reconstruir el histórico manualmente cuando vence el plazo legal.

Data residency. BigQuery permite elegir la ubicación de los datos al crear el dataset, y el procesamiento de los datos in situ o mediante su extracción a otra región. Esto importa cuando una regulación exige que determinados datos residan en una jurisdicción concreta, y tiene un efecto arquitectónico: la decisión de residencia se toma por dataset, de modo que conviven datasets en distintas regiones y las consultas que los cruzan deben tener en cuenta la transferencia de datos. Conviene distinguir dos conceptos que se confunden: residency (dónde se almacenan los datos) y procesamiento (dónde se ejecuta la consulta). BigQuery permite tanto fijar la ubicación del dataset como elegir dónde se ejecuta el procesamiento, y en algunos escenarios, como la UE, los datos en tránsito entre regiones se cifran de forma adicional.

El catálogo y la linaje. La integración con Dataplex y con Data Catalog da un punto de descubrimiento con metadatos, linaje de tablas, vistas y consultas, y clasificación automática de datos sensibles. Su valor para el examen es argumental: sin catálogo, el warehouse se convierte en un grupo de datasets sin dueño; con catálogo, el dato se puede descubrir, su propietario se puede localizar y su retención se puede auditar.

Mecanismo	Dónde se aplica	Qué protege o resuelve	Coste operativo
Dataset con convención de nombre	Organización del proyecto	Propiedad, entorno y granularidad del dato	Nulo, pero exige disciplina desde el día uno
Particionado	Tabla	Coste y latencia de la consulta	Bajo, si se define con el esquema
Clustering	Tabla	Bloques leídos dentro de cada partición	Bajo, con un coste de escritura pequeño
Vista materializada	Dataset	Reutilización de cálculos caros y estabilidad de reporting	Almacenamiento y riesgo de dato obsoleto
Row access policy	Tabla o vista	Segmentación de filas por usuario o grupo	Mantenimiento de políticas y pruebas
Column-level security y dynamic masking	Columna	Ocultación de PII y tokenización en consulta	Modelo de acceso por rol
Data residency	Dataset	Ubicación física y jurisdiction del dato	Restringe joins y consultas entre regiones
Dataplex y Data Catalog	Metadatos	Descubrimiento, linaje y clasificación	Curación continua del catálogo

Subtema 6: Roles de los usuarios de datos y casos de negocio

Sobre el mismo dataset de BigQuery conviven personas con intenciones distintas, y confundirlas es un error frecuente tanto en la vida real como en las preguntas del examen. Distinguirlas permite asignar permisos mínimos y, sobre todo, entender qué resultado de negocio produce cada una.

El ingeniero de datos es el dueño de la tubería. Construye las tablas, define los esquemas, decide el particionado y el clustering, ingestiona desde Cloud SQL, bases de datos de terceros o eventos de Pub/Sub mediante Dataflow, y es responsable de la calidad y de la documentación. Su superficie de permisos es amplia: necesita crear y modificar tablas, ejecutar procesos de carga y gestionar la configuración del dataset. En la organización, es el puente entre el sistema transaccional y el analítico, y su entregable es un dato fiable y disponible.

El analista de datos es el consumidor experto. Escribe SQL, construye consultas y dashboards, responde preguntas de negocio y da soporte analítico a las áreas comerciales y de marketing. Necesita leer datos de negocio y, en muchos casos, escribir en tablas de trabajo o vistas de análisis, pero no debería poder alterar las tablas de producción analítica. Su entregable es el insight y la respuesta documentada.

El consumidor de negocio no escribe SQL. Consume dashboards, informes y respuestas ya preparadas a través de herramientas de BI como Looker, Looker Studio o conectores nativos. En BigQuery su presencia es indirecta: no necesita un rol con permisos de datos si la capa de visualización consulta con una identidad de servicio (service account) que los tiene, y ese es el patrón recomendado. Su entregable es la decisión.

El scientist de datos y el ingeniero de ML se sitúan entre el analista y la infraestructura: construyen modelos, en la mayoría de los casos apoyándose en BigQuery ML o en Vertex AI, y son los usuarios de la plataforma a nivel de búsqueda de que un modelo se puede desplegar sin salir de la plataforma de datos.

Esta taxonomía tiene una consecuencia práctica de seguridad: otorgar permisos de BigQuery a toda la organización es un error de diseño, aunque parezca estaría bien. Cada rol necesita un conjunto distinto de permisos, y el modelo de la plataforma separa la vista de datos (roles/bigquery.dataViewer), la edición de datos (roles/bigquery.dataEditor), la gestión de datasets (roles/bigquery.dataOwner), la administración del servicio (roles/bigquery.admin) y el acceso al contenido (ejecución de jobs, que es lo que hace un usuario de BI). BigQuery aplica los permisos de lectura junto con la row access policy de la tabla, de modo que un dataViewer ve el conjunto de filas que la política le permite.

Los casos de negocio que aparecen de forma recurrente son el vertebral del examen, porque la pregunta casi nunca es "¿qué comando uso?" sino "qué hace esta organización con sus datos y con qué servicio lo resuelve". Conviene tenerlos ordenados:

Caso de negocio	Pregunta que responde	Patrón típico en BigQuery	Consideración dominante
Reporting operativo	¿Cómo van las ventas del mes frente al objetivo?	Agregados por región, canal y periodo sobre una vista materializada	Coste de bytes escaneados; vistas materializadas para el dashboard recurrente
Revenue analysis	¿De dónde viene el ingreso y qué margen deja cada línea?	Join de ventas, descuentos, costes y devoluciones, con métricas derivadas	Join de varias tablas: particionado y preagregación
Customer 360	¿Cuál es el valor, el riesgo y la situación completa de un cliente?	Unificación de pedidos, soporte, uso, pagos y marketing por `customer_id`	Amplios joins y datos de múltiples dominios; control de acceso por fila sensible
Detección de fraude	¿Qué transacciones son anómalas y deben bloquearse?	Union de señales (importe, geolocalización, dispositivo, frecuencia) y modelo de propensión	Latencia de la decisión y necesidad de modelo disponible en la misma plataforma
Forecasting	¿Cuánto se venderá y con qué Existencias?	Series temporales por SKU y punto de venta, con modelo de series temporales	Calidad de la historia: la granularidad y el trabajo de limpieza pesan más que el motor

El reporting operativo es el caso de volumen: muchas consultas pequeñas y frecuentes sobre un conjunto estrecho de métricas. Aquí el problema no es el rendimiento de una consulta aislada, sino la factura acumulada. La respuesta es precalcular en una vista materializada y filtrar siempre por partición, de modo que el coste de cada refresco de panel se estabilice.

El revenue analysis es el caso de complejidad relacional: el ingreso neto no está en la tabla de pedidos, sino que resulta de restar descuentos, devoluciones, impuestos y costes logísticos, y suele requerir uniones con varias fuentes de la misma granularidad temporal. Aquí la palanca es el modelo de datos (una tabla de hechos única y conforms) más que el motor.

El customer 360 es el caso de gobernanza: es la vista que la dirección quiere y que ninguna organización puede construir sin limpiar duplicados, unificar identificadores y decidir qué datos personales se pueden exponer y a quién. BigQuery resuelve la parte analítica; la parte difícil, la resolución de identidades y el control de acceso por fila, es donde se decide si el caso es un éxito.

La detección de fraude es el caso de latencia y de scoring en línea. Dos variantes: puntuación por lotes de las transacciones para revisión posterior, o puntuación en el momento de la transacción si el dato se sirve desde una vista materializada que se actualiza con frecuencia. En ambos casos, la ventaja de tener el modelo dentro de BigQuery es que la regla de decisión (bloquear, revisar, permitir) se escribe en SQL y se audita con el mismo rigor que el resto de la lógica de negocio.

El forecasting es el caso donde la calidad del dato manda sobre la elección de herramienta: una serie temporal con huecos, con estacionalidad mal capturada o con devoluciones mal clasificadas produce un modelo impecable sobre un histórico equivocado. BigQuery ML cubre los modelos de series temporales, pero el trabajo de preparación —limpieza de la serie, tratamiento de la estacionalidad y construcción de las variables de entrada: es SQL ordinario, y ahí es donde se decide la calidad de la previsión.

Ejemplo Práctico

El siguiente bloque muestra el recorrido completo: crear un dataset gobernado, construir una tabla particionada y clusterizada, comprobar el coste de una consulta antes de ejecutarla, reservar capacidad y definir una row access policy. Los tres primeros comandos son de gcloud; el cuarto usa el cliente bq porque las sentencias DDL de BigQuery se ejecutan como consultas SQL.

# 1. Crear el dataset con la convención de gobierno: entorno, dominio, madurez
gcloud bigquery datasets create prod_sales_curated \
  --location=US \
  --description="Capa curada de ventas en produccion" \
  --labels=domain=sales,env=prod,layer=curated

# 2. Crear la tabla con particionado por fecha y clustering por cliente
gcloud bigquery tables create prod_sales_curated.orders \
  --schema=order_id:STRING,order_date:DATE,customer_id:STRING,channel:STRING,net_amount:FLOAT \
  --time_partitioning=order_date \
  --time_partitioning_type=DAY \
  --clustering_fields=customer_id,channel \
  --description="Pedidos con importe neto en euros"

# 3. Auditar el coste estimado de la consulta ANTES de ejecutarla
gcloud bq query --use_legacy_sql=false --dry_run --nouse_legacy_sql \
  'SELECT order_date, SUM(net_amount) AS revenue
   FROM `prod_sales_curated.orders`
   WHERE order_date BETWEEN DATE("2026-09-01") AND DATE("2026-09-30")
   GROUP BY order_date'

# 4. Comprobar el uso real de slots de la organización
gcloud bigquery slots list --project=PROJECT_ID --format="table(reservation.name,edition,slot_capacity)"

# 5. Reservar capacidad cuando la carga ya es estable
gcloud bigquery reservations create \
  --project=PROJECT_ID \
  --location=US \
  --reservation=analytics-baseline \
  --edition=enterprise \
  --slots=100

La salida del paso 3 es la que importa: un dry_run no ejecuta la consulta, devuelve el número de bytes que se leerían. Si la tabla está particionada y el filtro de fecha se escribe sobre la columna de particionado, ese número será una fracción del tamaño total de la tabla; si el filtro se omite o se aplica a una columna no particionada, la consulta escaneará la tabla completa, y esa cifra es literalmente el coste de la factura. Ejecutar el dry_run antes de cada consulta cara es la práctica que convierte el control de gasto en un hábito en lugar de una sorpresa.

El paso 4 y el 5 expresan la decisión de modelo de coste: mientras la carga sea irregular, la organización opera en on-demand y mide; cuando el uso de slots es sostenido y conocido, se compromete capacidad con una reserva y se benefician del compromiso anual. Los pasos 1 y 2, por su parte, son la forma barata de gobierno: una tabla particionada y clusterizada desde el día uno cuesta unos segundos de diseño y evita meses de facturas infladas.

# 6. Row access policy: cada analista ve solo las filas de su region
bq query --use_legacy_sql=false <<'EOF'
CREATE OR REPLACE ROW ACCESS POLICY `region_filter`
ON `prod_sales_curated.orders`
GRANT TO ("group:analysts-spain@acme.com")
FILTER USING (region = "ES");

EOF

# 7. Verificar las politicas de acceso a la tabla
gcloud bigquery tables describe prod_sales_curated.orders \
  --format="yaml(rowAccessPolicies,iamPolicy)"

La fila access policy del paso 6 se aplica a nivel de motor, después de resolver los permisos del dataset: un analista con permiso de lectura sobre el dataset ve, de todas formas, únicamente las filas que su política le permite. Eso significa que la segmentación regional no depende de que cada analista recuerde añadir un WHERE region = ... a su consulta, y por tanto no se rompe por error. El paso 7 confirma qué políticas y qué enlaces de IAM hay realmente sobre la tabla, que es la operación que un auditor pide antes de aprobar el acceso a datos personales.

Temas relacionados: Data-Driven Business and Transformation, Google Cloud Data and Databases Solutions, Operational Databases and Cloud Migration, Data Governance, BI and Visualization with Looker, AI and ML Fundamentals

Conceptos Clave

Concepto	Descripción	Cuándo usarlo
Data warehouse serverless	Motor analítico sin clústeres visibles, con almacenamiento y cómputo gestionados por el proveedor	Reporting, KPIs, BI y analítica exploratoria sobre histórico
Separación almacenamiento-cómputo	El almacenamiento y el cómputo de consultas son recursos y costes independientes	Razonar por qué no hay que aprovisionar capacidad ni dimensionar nada
On-demand (pay as you go)	Facturación por bytes escaneados y trabajo ejecutado, sin compromiso	Carga irregular, estacional o fase de adopción inicial
Slots y ediciones	Capacidad de cómputo reservada (Standard, Enterprise, Enterprise Plus) facturada por periodo	Carga estable y sostenida, con compromiso anual o mensual
Particionado	División de la tabla en particiones para que la consulta solo lea las necesarias	Toda tabla de gran volumen; primera palanca de coste y latencia
Clustering	Ordenación de filas por columnas de alta cardinalidad para reducir bloques leídos	Combinar con particionado cuando se filtra por cliente, canal o ID
Vista materializada	Cálculo precalculado y almacenado, reutilizable y actualizable	Métricas de reporting recurrentes y caras de recalcular
Tabla externa	Definición de esquema que apunta a datos que siguen en su sistema de origen	Consultar datos en otra nube o en un lago sin moverlos
BigLake	Plano de control de datos gestionado para consultar almacenamiento de objetos con metadatos unificados	Data lake sobre Cloud Storage o sobre el almacenamiento de otra nube
BigQuery ML	Creación, entrenamiento y evaluación de modelos con sentencias SQL estándar	Propensión, scoring, segmentación y previsión sin salir del warehouse
Row access policy	Filtro de filas a nivel de tabla aplicado por el motor, no por la consulta	Segmentar datos sensibles por usuario, grupo o región
Column-level security y dynamic masking	Ocultación de columnas y enmascarado de valores según el ejecutor	Proteger PII manteniendo un único dataset compartido
Data residency	Ubicación física del dataset y de sus datos por región o frontera	Requisitos regulatorios de jurisdicción del dato

Comparaciones

Modelos de facturación de BigQuery

Criterio	On-demand (pay as you go)	Capacidad reservada (ediciones con slots)
Unidad de cobro	Bytes escaneados y trabajo de la consulta	Slot de cómputo por periodo reservado
Compromiso	Ninguno	Mensual o anual, con descuento por compromiso
Cuándo aparece gasto	Solo cuando alguien consulta	También cuando nadie consulta, porque la capacidad está reservada
Previsibilidad	Depende del comportamiento de consulta	Alta: coste esencialmente fijo
Punto de riesgo	Consulta que escanea de más sin filtro	Capacidad reservada y no utilizada
Punto de equilibrio	Fase inicial y cargas estacionales	Carga estable, conocida y de volumen alto

BigQuery frente a otras opciones de data warehouse

Criterio	BigQuery	Warehouse autohospedado (p. ej. en VMs)	Servicio de BI sobre base de datos relacional
Administración	Ninguna, serverless	Clúster, dimensionado, mantenimiento, actualizaciones	Alta, la del motor de base de datos
Modelo de coste	Por uso (on-demand) o por capacidad (slots)	Por infraestructura, fija o por los nodos restantes	Por instancia y almacenamiento
Escalado	Elástico, por consulta	Manual, por incorporación de nodos	Vertical, con techo
Camino del dato	Separado del transaccional por diseño	Suele acabo mezclándose con el OLTP	Suele acabar mezclándose con el OLTP
Formatos externos	Tablas externas y BigLake sobre Parquet, ORC, CSV	Carga previa al clúster	Carga previa al servidor

Tabla nativa frente a tabla externa

Criterio	Tabla nativa	Tabla externa (con BigLake)
Dónde están los datos	En el almacenamiento de BigQuery	En el bucket o sistema de origen
Coste de almacenamiento	Se paga en BigQuery	Se paga al proveedor del origen
Copias del dato	Una	Una, salvo que se materialice
Rendimiento de consulta	Optimizado, con datos en formato columnar propio	Correcto, con mejora progresiva de BigLake
Control de acceso	IAM de BigQuery más row access policies	Unificado con el catálogo de BigQuery
Modificación del dato	INSERT, UPDATE, DELETE	Actualización in situ con BigLake
Caso típico	Analítica recurrente y estable	Histórico amplio, dato multicloud, data lake

Enfoques de gobierno del dato en BigQuery

Enfoque	Herramienta	Aporta	Riesgo si se omite
Gobierno por estructura	Datasets con convención de nombre y propiedad	Trazabilidad de quién responde por qué	Datasets huérfanos y datos sin dueño
Gobierno por coste	Particionado y clustering	Control del gasto por consulta	Facturas unpredictables y latencia alta
Gobierno por rendimiento	Vistas materializadas	Reporting recurrente y barato	Recálculos caros en cada actualización de panel
Gobierno por acceso	Row access policies y column-level security	Segregación de datos sensibles	Fuga de datos personales o financieros
Gobierno por catálogo	Dataplex y Data Catalog	Descubrimiento, linaje y clasificación	El warehouse se vuelve un archivo sin búsqueda

Errores Comunes

Error: Tratar BigQuery como la base de datos de la aplicación y migrar a ella el tráfico transaccional, o usarla como sustituto de la base de datos relacional. → Solución: BigQuery es un data warehouse analítico. Su latencia por consulta, su modelo de coste y su ausencia de índices secundarios lo hacen inadecuado para lecturas y escrituras individuales en el camino crítico. La arquitectura correcta mantiene la base de datos operativa (Cloud SQL, AlloyDB, Spanner) como fuente de verdad, y BigQuery como capa de analítica alimentada por extracción por lotes o por streaming con Dataflow y Pub/Sub. En un escenario del examen, la respuesta esperada casi siempre incluye esa separación de caminos.
Error: Preguntar el precio de BigQuery "por máquina" o razonar con clústeres, nodos y aprovisionamiento, como si el servicio fuera un warehouse tradicional. → Solución: Razonar en los dos ejes reales del servicio: on-demand factura por bytes escaneados y trabajo ejecutado, y el modelo de slots factura por capacidad reservada. Ninguna cifra concreta de precio debe darse por sabida sin verificarla contra la página oficial de precios, porque cambia por región, por edición y por periodo. El error grave en un examen no es la cifra: es quedarse sin argumento para explicar por qué el coste escala con el uso, que es la idea que el examinador quiere evaluar.
Error: Escribir consultas sin filtro de partición ni filtro de columna, y descubrir el coste en la factura en lugar de en el dry_run. → Solución: Ejecutar siempre la consulta en modo dry_run antes de costearla, particionar la tabla por fecha desde el diseño y usar el clustering para las columnas de filtrado habitual. Recordar que SELECT * sobre una tabla grande es un error de coste, no unabrevidad de código, y que el particionado solo funciona si el filtro se aplica sobre la columna de particionado, no sobre un campo derivado que obligue a leer todas las particiones.
Error: Copiar masivamente datos de otras nubes a BigQuery "porque se puede", duplicando el almacenamiento y acelerando la vía de ingesta, en lugar de consultar el dato donde está. → Solución: Evaluar primero la frecuencia de lectura. Para dato de lectura ocasional, la copia puede ser más barata; para dato leído a diario o por varios equipos, las tablas externas y BigLake evitan duplicar el almacenamiento y mantienen una única copia, que además simplifica la gobernanza. Cuando el volumen o la latencia lo justifiquen, considerar BigQuery Omni para consultar directamente la plataforma analítica del otro proveedor. Lo que no corresponde es la copia indiscriminada, que consume presupuesto de red e ingesta sin un caso de negocio detrás.
Error: Dar a toda la organización el rol de lectura completo sobre el dataset de negocio y confiar en que cada usuario aplique sus propios filtros de confidencialidad. → Solución: Aplicar la gobernanza en la plataforma, no en el comportamiento. Usar datasets separados para separar dominios y entornos, row access policies para la segmentación de filas por región, rol o equipo, y column-level security con dynamic masking para la protección de datos personales sensibles. Los permisos se conceden por rol (dataViewer, dataEditor, dataOwner) y se combinan con las políticas de fila, que el motor aplica después de los permisos y de forma vinculante. Un dato personal se protege en el modelo de permisos y en las políticas de retención, no en la formación del equipo.

Puntos para el Examen

🎯 Punto clave 1: BigQuery es un data warehouse serverless: sin clústeres que dimensionar, sin mantenimiento que programar y con capacidad elástica. Su valor no está en el SQL, sino en lo que libera: la organización puede preguntar cosas nuevas al histórico sin convertir una pregunta en un proyecto de infraestructura, porque el coste marginal de la pregunta se ha desplomado. La consecuencia de negocio que hay que articulate es la reducción del tiempo entre pregunta y decisión.

🎯 Punto clave 2: La arquitectura de costes tiene dos ejes, no uno. BigQuery separa almacenamiento y cómputo, y factura el cómputo de dos formas: on-demand por bytes escaneados y trabajo ejecutado, o por slots de capacidad reservada en las ediciones Standard, Enterprise y Enterprise Plus. La decisión de modelado es pasar del on-demand al compromiso cuando la carga se ha estabilizado. Cualquier cifra concreta de precio debe verificarse contra la página oficial, y se evalúa la explicación del modelo de coste, no el número.

🎯 Punto clave 3: La analítica multicloud no exige mover el dato. Las tablas externas consultan objetos en Cloud Storage, S3 o Azure Storage; BigLake añade plano de control, metadatos unificados, control de acceso y actualización in situ; BigQuery Omni ejecuta la consulta directamente sobre la plataforma analítica de otro proveedor. La comparación de la respuesta esperada es copia frente a consulta en el sitio, y el criterio es la frecuencia de lectura y el coste duplicado del almacenamiento.

🎯 Punto clave 4: BigQuery ML permite crear, entrenar y evaluar modelos con SQL estándar dentro del warehouse, y reduce el tiempo entre el dato y el modelo predictivo al democratizar el modelado tabular para los perfiles de analista. No sustituye a Vertex AI en deep learning a escala: BigQuery ML es la vía para modelos tabulares, series temporales, segmentación y propensión; Vertex AI es la plataforma para modelos de deep learning, entrenamiento distribuido y despliegue en servicio.

🎯 Punto clave 5: La gobernanza en BigQuery se implementa en el motor, no en la confianza: datasets con propiedad explícita, particionado y clustering como palancas de coste, vistas materializadas para el reporting recurrente, row access policies para la segregación de filas, column-level security y dynamic masking para la protección de datos sensibles, y data residency para los requisitos de jurisdicción. En un escenario que menciona PII, datos financieros o una restricción regulatoria, la respuesta esperada es siempre un mecanismo de la plataforma, con un argumento de por qué el control del motor es preferible a un filtro en la consulta.

Recursos Externos

BigQuery: overview del producto — Qué es BigQuery, sus modos de consumo y cómo se separa el almacenamiento del cómputo.
BigQuery: precios y modelos de facturación — Referencia de los modos on-demand y de capacidad reservada, y de los factores que determinan la factura.
BigQuery: tablas externas y BigLake — Creación de tablas externas sobre Cloud Storage y sobre otras nubes, y funcionamiento de BigLake.
BigQuery ML: introduction — Creación, entrenamiento y evaluación de modelos de machine learning con sentencias SQL estándar.
BigQuery: seguridad a nivel de fila y de columna — Row access policies, column-level security y dynamic data masking para la protección de datos sensibles.

Autoevaluación Rápida

Pregunta: Una empresa tiene una demanda de reporting estable de unas 200 consultas diarias sobre una tabla de 40 TB, y su gasto en BigQuery ha subido de forma constante durante seis meses. ¿Qué recomiendas y por qué no agrandar la tabla ni el clúster? Respuesta: Evaluar el paso del modelo on-demand al modelo de capacidad. Con una carga estable y conocida, reservar slots en una edición que cubra la línea base de demanda permite obtener un descuento por compromiso y convertir una factura variable en un coste esencialmente fijo y previsible, que es lo que un director financiero puede presupuestar. No se "agranda la tabla": en BigQuery no hay clúster que dimensionar, y la capacidad de cómputo se ajusta sola a cada consulta. Lo que sí hay que hacer antes es optimizing el coste por consulta —particionado, clustering y vistas materializadas para el reporting recurrente—, porque partir de un consumo inflado y luego comprometer capacidad es la forma más cara de equivocarse. Solo después de esa limpieza se evalúa el compromiso.
Pregunta: Un minorista tiene sus datos de ventas en Snowflake, sus contratos en una base de datos de Azure y su histórico de eventos en S3. El negocio quiere analítica unificada sin una migración de dos años. ¿Qué propones y qué descartas? Respuesta: Analítica multicloud sin migración. Tablas externas para consultar los objetos de S3 y los datos que se puedan exponer de los otros sistemas, BigLake como plano de control sobre el almacenamiento de objetos con metadatos y permisos unificados, y BigQuery Omni si el volumen y la latencia justifican consultar directamente la plataforma analítica del otro proveedor. Lo que se descarta es la migración masiva: dos años de proyecto, presupuesto duplicado y riesgo de que el dato quede desactualizado en el momento de terminar. La única actividad de migración que sí tiene sentido es la capa analítica consolidada en BigQuery, que se construye con las mismas herramientas de ingesta (Dataflow, Pub/Sub) y es incremental.
Pregunta: Un equipo de marketing quiere predecir qué clientes van a abandonar, pero no tiene ciencia de datos en la plantilla. ¿Qué se le puede ofrecer y con qué límites? Respuesta: BigQuery ML. Con SQL estándar puede crear un modelo de regresión logística o de árboles de decisión sobre la tabla histórica de clientes, entrenarlo con partición automática y aplicarlo con ML.PREDICT en la misma consulta que genera el informe, obteniendo una probabilidad de abandono por cliente sin salir de la plataforma de datos. Los límites hay que enunciarlos: BigQuery ML cubre modelos tabulares, series temporales, segmentación y embeddings; para deep learning a escala, entrenamiento distribuido o despliegue de modelos en servicio, la vía es Vertex AI, con la que BigQuery se integra. El argumento de negocio es que el tiempo entre el dato y la predicción se reduce de semanas a minutos, y que la inferencia queda disponible dentro del mismo SQL que el resto del reporting, lo que hace que el scoring se use de verdad y no se quede en un modelo Huérfano.
Pregunta: Una aseguradora tiene una tabla con datos personales de asegurados y un equipo regional que solo debe ver su propia cartera. ¿Qué mecanismo de BigQuery recomiendas y por qué no basta con un WHERE region = ... en la consulta? Respución: Una row access policy sobre la tabla, con el filtro a nivel de motor, más un rol de lectura limitado en IAM para el equipo de análisis. La policy vincula el filtro al usuario o grupo, de modo que el analista ve únicamente su cartera sin tener que escribir el filtro, y no puede esquivarlo: la política se aplica después de resolver los permisos, de forma que quitar el WHERE de la consulta no amplía el resultado. Un filtro en la consulta es frágil por dos razones: depende de que cada persona recuerde escribirlo, y se puede olvidar en un tablero, un informe o una copia pegada en una presentación. Como complemento, column-level security con dynamic masking para los campos más sensibles (número de documento, datos de salud) y una regla de retención sobre el dataset, porque la PII también tiene fecha de expiración.
Pregunta: En una pregunta de opción múltiple aparece "empresa necesita consolidar datos de varios proveedores cloud sin moverlos y con control de acceso unificado". ¿Qué dos mecanismos de BigQuery son la respuesta y en qué se diferencian? Respuesta: Tablas externas y BigLake. Una tabla externa es la definición de esquema que apunta a datos que siguen en su origen (un bucket de S3, de Azure o de Cloud Storage) y permite consultarlos con SQL, con el coste de almacenamiento en el proveedor de origen. BigLake es la evolución operativa: gestiona el plano de control de datos —el metastore—, de modo que los metadatos y el control de acceso se unifican con el catálogo de BigQuery, sin mantener un Hive externo; además permite actualizar datos in situ y mejora el rendimiento de la consulta automáticamente. Si la pregunta incluyera además la ejecución de la consulta directamente sobre la plataforma analítica del otro proveedor, la tercera pieza sería BigQuery Omni. La diferencia que hay que saber explicar es dónde vive el dato (en el origen, en ambos casos, salvo materialización) y quién lo gobierna (el proveedor del bucket, en una tabla externa simple; BigQuery, con BigLake).