Semana 6 · Módulo 6 de 12

Procesamiento de datos y analítica

Aprenderás a diseñar canalizaciones de datos por lotes y en streaming con Pub/Sub, Dataflow, Spark gestionado, Airflow y Datastream, y a sacar partido de BigQuery (particionado, clustering, precios, BigLake, BigQuery ML, compartición y seguridad fina). El examen pregunta tanto qué servicio elegir como cómo abaratar y gobernar la analítica.

Reparto de la semana

Por qué importa

El apartado 1.3 incluye «elegir soluciones de procesamiento de datos» y el 1.1 habla de «movimiento de datos» y de patrones de integración. Los cuatro casos de estudio tienen un componente de datos: ingesta de telemetría de vehículos, analítica de ventas en tiempo real, datos clínicos con requisitos de cumplimiento o catálogos de medios. Las preguntas suelen tener esta forma:

• «Los datos llegan en streaming desde miles de dispositivos, hay que agregarlos por ventanas de 5 minutos y cargarlos en el data warehouse» → Pub/Sub + Dataflow + BigQuery.
• «La empresa tiene cientos de jobs Spark on-premises y quiere migrarlos con cambios mínimos» → Managed Service for Apache Spark (antes Dataproc).
• «Las consultas de BigQuery son caras» → particionado, clustering, evitar SELECT *, ediciones con reservas.

Este módulo te da el mapa completo para responder con criterio.

Ciclo de vida de los datos

Cualquier canalización tiene cuatro etapas. Memoriza qué servicio encaja en cada una:

Y dos distinciones básicas:

• Lotes (batch) frente a streaming. Un proceso por lotes trabaja sobre un conjunto de datos acotado (el fichero de ventas de ayer) y termina. Un proceso en streaming trabaja sobre datos no acotados que llegan continuamente y se ejecuta sin fin; su dificultad está en el tiempo (datos que llegan tarde o desordenados). Dataflow hace ambas cosas con el mismo modelo de programación.
• ETL frente a ELT. En ETL transformas antes de cargar (Dataflow, Data Fusion, Spark). En ELT cargas los datos en bruto en BigQuery y transformas con SQL dentro de él (con Dataform o consultas programadas). Con BigQuery, ELT suele ser más simple y barato.

Pub/Sub

Pub/Sub es el servicio de mensajería asíncrona global y serverless de Google Cloud. Desacopla a quien produce eventos (publicadores) de quien los consume (suscriptores), absorbe picos y escala automáticamente sin aprovisionar nada.

Conceptos

• Tema (topic): recurso al que los publicadores envían mensajes.
• Suscripción: recurso asociado a un tema que representa un flujo de mensajes para un consumidor. Cada suscripción recibe una copia de cada mensaje (patrón fan-out): si tres sistemas necesitan los mismos eventos, creas tres suscripciones.
• Acuse de recibo (ack): el suscriptor confirma que ha procesado el mensaje. Si no lo confirma antes del plazo de ack (por defecto 10 s, configurable hasta 600 s), Pub/Sub lo vuelve a entregar.
• Retención: los mensajes no confirmados se guardan por defecto 7 días en la suscripción (configurable de 10 minutos a 31 días). El tema también puede retener mensajes (hasta 31 días) para reprocesarlos con seek a un momento o a una snapshot.
• La entrega por defecto es al menos una vez (at-least-once) y sin orden garantizado: el consumidor debe ser idempotente.

Tipos de suscripción

La suscripción BigQuery puede usar el esquema del tema, el esquema de la tabla o escribir el mensaje en una columna data, y opcionalmente los metadatos (message_id, publish_time, atributos…). La cuenta de servicio de Pub/Sub necesita permiso de escritura en la tabla (roles/bigquery.dataEditor). Lo practicarás en lab-12-pubsub-bigquery.

Orden, exactamente una vez, reintentos y dead letter

• Orden: activa --enable-message-ordering en la suscripción y publica con una clave de orden (ordering key). Pub/Sub entrega en orden los mensajes con la misma clave publicados en la misma región. El orden es por clave, no global, y reduce el rendimiento por clave.
• Exactamente una vez (exactly-once delivery): solo en suscripciones pull y cuando los suscriptores se conectan a la misma región. Push y las suscripciones de exportación no lo admiten.
• Política de reintentos: reintento inmediato o con retroceso exponencial (retardo mínimo y máximo entre 0 y 600 s).
• Dead letter topic (tema de mensajes fallidos): tras un número de intentos (entre 5 y 100, por defecto 5), el mensaje se reenvía a otro tema para analizarlo aparte en lugar de reintentarse sin fin (poison message).
• Filtros: la suscripción recibe solo los mensajes cuyos atributos cumplen un filtro.
• Esquemas (Avro o Protocol Buffers) para validar los mensajes al publicar.

gcloud pubsub topics create pedidos
gcloud pubsub topics create pedidos-dlq
gcloud pubsub subscriptions create pedidos-facturacion \
  --topic=pedidos \
  --ack-deadline=60 \
  --enable-message-ordering \
  --dead-letter-topic=pedidos-dlq \
  --max-delivery-attempts=10 \
  --min-retry-delay=10s --max-retry-delay=600s

Dataflow y Apache Beam

Dataflow es el servicio gestionado y serverless para ejecutar canalizaciones de Apache Beam, tanto por lotes como en streaming. Tú escribes la lógica con el SDK de Beam (Java, Python, Go) o usas una plantilla, y Dataflow aprovisiona los workers, los autoescala, reequilibra el trabajo y ofrece por defecto procesamiento exactamente una vez de cada registro.

Conceptos de Beam

• Pipeline: el grafo completo de la canalización.
• PCollection: conjunto de datos distribuido (acotado en lotes, no acotado en streaming).
• PTransform: operación sobre una PCollection (ParDo, GroupByKey, Combine, lecturas y escrituras con I/O connectors).
• Runner: dónde se ejecuta (Dataflow, Spark, Flink o local). La portabilidad es un argumento de Beam: el mismo código puede ejecutarse fuera de Google Cloud.

Ventanas, marcas de agua y disparadores

En streaming no puedes «agrupar todo»: necesitas ventanas que corten el flujo por tiempo del evento (cuando ocurrió), no por tiempo de proceso (cuando llegó).

• La marca de agua (watermark) es la estimación de Dataflow de hasta qué momento del tiempo del evento ya han llegado todos los datos.
• Los disparadores (triggers) deciden cuándo emitir resultados de una ventana (al pasar la marca de agua, antes con resultados parciales, o al llegar datos tardíos).
• Allowed lateness: cuánto tiempo aceptar datos que llegan tarde tras cerrar la ventana.

Funciones del servicio

• Autoescalado horizontal de workers y, con Dataflow Prime, también vertical (memoria), facturado en Data Compute Units (DCU).
• Streaming Engine y Dataflow Shuffle: sacan el estado y el shuffle de los workers al servicio, lo que permite workers más pequeños y autoescalado más rápido.
• FlexRS: descuento en jobs por lotes que toleran un retraso en el arranque (usa una mezcla de VMs estándar y preemptibles).
• Actualizar un job en streaming sin perder estado, o pararlo con drain (termina de procesar lo que tiene en vuelo) en lugar de cancel (lo detiene de inmediato y puede perder datos en vuelo).
• Plantillas: classic templates y Flex Templates (empaquetadas como imagen de contenedor, más flexibles). Google ofrece plantillas ya hechas (Pub/Sub a BigQuery, Cloud Storage Text a BigQuery, Kafka a BigQuery, WordCount…) que se lanzan sin escribir código, y el job builder permite crear canalizaciones desde la consola. Según la documentación, desde agosto de 2025 las plantillas gestionadas por Google se ejecutan por defecto con Dataflow Prime.

Spark gestionado, Data Fusion y Datastream

Managed Service for Apache Spark (antes Dataproc)

Desde abril de 2026, Managed Service for Apache Spark es el nombre que agrupa lo que antes eran Dataproc (clústeres en Compute Engine) y Google Cloud Serverless for Apache Spark (antes Dataproc Serverless). Las APIs, los comandos (gcloud dataproc …) y los roles de IAM mantienen el nombre Dataproc, y en muchos materiales de examen verás todavía «Dataproc».

Buenas prácticas con clústeres (muy preguntadas):

• Clústeres efímeros: crea el clúster para un job (o un flujo con workflow templates), ejecútalo y bórralo. No mantengas clústeres encendidos 24 h para jobs diarios.
• Datos en Cloud Storage, no en HDFS (conector de Cloud Storage): así el clúster puede desaparecer sin perder datos y varios clústeres comparten los mismos datos.
• Workers secundarios con VMs Spot o preemptibles para abaratar, y políticas de autoescalado.
• Dataproc Metastore (Hive Metastore gestionado) para compartir metadatos entre clústeres efímeros.

Cloud Data Fusion

Servicio de integración de datos visual y sin código basado en el proyecto open source CDAP. Diseñas canalizaciones ETL arrastrando conectores y transformaciones, y Data Fusion las ejecuta en clústeres de Spark efímeros. Tiene ediciones Developer, Basic y Enterprise. Palabras clave: «analistas sin programar», «interfaz gráfica», «muchos conectores a sistemas empresariales».

Datastream

Servicio serverless de captura de cambios (change data capture, CDC) y replicación. Lee los logs de cambios de bases de datos operacionales (MySQL, PostgreSQL incluida AlloyDB, Oracle, SQL Server, MongoDB, Spanner, además de fuentes como Salesforce) y los replica con baja latencia en BigQuery, Cloud Storage o tablas Apache Iceberg vía BigLake. Hace la carga inicial (backfill) y después los cambios continuos, sin tocar la aplicación.

Palabras clave: «replicar en tiempo casi real una base de datos Oracle/MySQL en BigQuery para analítica», «sin impactar en la base de datos de producción», «CDC».

Orquestación: Airflow gestionado y Workflows

Una canalización real tiene pasos con dependencias: esperar a que llegue un fichero, lanzar un job de Spark, cargar en BigQuery, ejecutar comprobaciones de calidad, avisar. Eso es orquestación.

El cambio de nombre de Cloud Composer a Managed Service for Apache Airflow se anunció el 15 de abril de 2026, junto con la disponibilidad general de Airflow 3. Los comandos (gcloud composer), la API y los roles mantienen el nombre Composer. El entorno de Airflow tiene un coste fijo mientras existe; Workflows no.

BigQuery a fondo

Arquitectura

BigQuery separa almacenamiento y cómputo:

• Los datos se guardan en formato columnar comprimido sobre el sistema de ficheros distribuido de Google. Leer una columna no obliga a leer las demás: por eso SELECT * es caro y seleccionar solo las columnas necesarias es barato.
• El cómputo se mide en slots (CPU virtual) que el motor reparte entre las etapas de cada consulta. No hay servidores que dimensionar.
• La jerarquía es proyecto → dataset (con ubicación fija: región o multirregión, como EU) → tablas, vistas, vistas materializadas, funciones y modelos.
• Time travel: puedes consultar o restaurar una tabla tal como estaba en los últimos días (7 por defecto) con FOR SYSTEM_TIME AS OF, y existe además un periodo de fail-safe gestionado por Google.

Ingesta:

• Cargas por lotes (bq load desde Cloud Storage): no se cobran en el modelo bajo demanda, porque usan un grupo compartido de slots.
• Streaming con la Storage Write API (recomendada) o la antigua API de inserción en streaming, que sí se cobran.
• Suscripciones BigQuery de Pub/Sub, Datastream, BigQuery Data Transfer Service y consultas federadas.

Particionado y clustering

Son las dos herramientas principales para reducir el coste y acelerar las consultas.

Particionado: divide la tabla en segmentos por una columna. Si la consulta filtra por esa columna, BigQuery solo lee las particiones necesarias (partition pruning) y solo pagas por ellas.

• Por columna de fecha/hora (DATE, TIMESTAMP, DATETIME), con granularidad horaria, diaria (por defecto), mensual o anual.
• Por tiempo de ingesta (pseudocolumna _PARTITIONTIME).
• Por rango de enteros.
• Solo una columna de partición por tabla, y un máximo de 10.000 particiones por tabla.
• Opciones útiles: exigir filtro de partición (require_partition_filter) para impedir consultas que escaneen toda la tabla, y expiración de particiones para borrar datos antiguos automáticamente.

Clustering: ordena los datos dentro de cada partición (o de la tabla) por hasta 4 columnas. Las consultas que filtran o agregan por esas columnas leen menos bloques. BigQuery mantiene el orden automáticamente y sin coste.

CREATE TABLE ventas.pedidos
(
  pedido_id STRING,
  tienda_id STRING,
  cliente_id STRING,
  importe NUMERIC,
  creado TIMESTAMP
)
PARTITION BY DATE(creado)
CLUSTER BY tienda_id, cliente_id
OPTIONS (require_partition_filter = TRUE, partition_expiration_days = 730);

Modelos de precios

BigQuery cobra por separado almacenamiento y cómputo.

Almacenamiento:

• Precio por GiB al mes, con almacenamiento a largo plazo (aproximadamente la mitad) para tablas o particiones que no se modifican en 90 días consecutivos. No cambia el rendimiento.
• Facturación lógica (bytes sin comprimir, por defecto) o física (bytes comprimidos, incluye time travel), elegible por dataset.
• Los primeros 10 GiB al mes son gratuitos.

Cómputo (consultas, incluidas DML, DDL y BigQuery ML):

Diferencias de las ediciones que el examen puede usar: Standard no incluye BigQuery ML, seguridad de filas y columnas, CMEK ni BI Engine; Enterprise sí, y añade BigQuery Omni; Enterprise Plus añade controles de cumplimiento (Assured Workloads) y recuperación ante desastres gestionada. Consulta los precios por slot-hora de cada edición y región en la página de precios.

Controles de coste:

• Dry run (bq query --dry_run) o el validador de la consola: te dice cuántos bytes escanearía una consulta sin ejecutarla ni cobrarla.
• Máximo de bytes facturados (--maximum_bytes_billed): la consulta falla si superaría el límite.
• Cuotas personalizadas por proyecto o usuario (bytes consultados al día).
• Particionado, clustering, evitar SELECT *, vistas materializadas y caché de resultados (las consultas repetidas que devuelven resultados de la caché no se cobran).

Tablas externas, BigLake y lakehouse

• Tabla externa: BigQuery consulta ficheros que siguen en Cloud Storage (CSV, JSON, Avro, Parquet, ORC) o en otros sistemas (consultas federadas a Cloud SQL, Spanner, AlloyDB). No hay que cargarlos, pero el rendimiento es menor y el usuario necesita acceso al bucket.
• Tabla BigLake: tabla externa con delegación de acceso: BigQuery accede a los ficheros con la cuenta de servicio de una conexión, así que el usuario solo necesita permiso sobre la tabla, no sobre el bucket. Permite seguridad de filas y columnas y caché de metadatos. Funciona sobre Cloud Storage y, con BigQuery Omni, sobre Amazon S3 y Azure Blob Storage.
• Apache Iceberg: formato de tabla abierto que BigQuery, Spark y otros motores leen y escriben. Con tablas Iceberg gestionadas y el metastore de BigLake construyes un lakehouse: datos en formato abierto en Cloud Storage, consultables desde BigQuery y desde Spark con el mismo gobierno.

Palabras clave: «consultar los ficheros del data lake sin cargarlos» → tabla externa/BigLake; «control de acceso fino sobre datos en Cloud Storage» → BigLake; «datos en S3 que no se pueden mover» → BigQuery Omni; «formato abierto compartido con Spark» → Iceberg.

BigQuery ML

BigQuery ML permite crear, entrenar y usar modelos de machine learning con SQL, sin mover los datos fuera de BigQuery:

CREATE OR REPLACE MODEL ventas.prevision_demanda
OPTIONS (model_type = 'ARIMA_PLUS', time_series_timestamp_col = 'dia', time_series_data_col = 'unidades')
AS SELECT dia, unidades FROM ventas.demanda_diaria;

SELECT * FROM ML.FORECAST(MODEL ventas.prevision_demanda, STRUCT(30 AS horizon));

Incluye regresión lineal y logística, k-means, árboles potenciados, series temporales (ARIMA_PLUS), factorización de matrices (recomendaciones), importación de modelos y modelos remotos que llaman a Gemini y a otros modelos de Gemini Enterprise Agent Platform desde SQL. Palabras clave: «analistas que saben SQL», «predicción sin mover los datos», «prototipo rápido de ML». Para entrenamientos a medida y MLOps completo, la semana 8 cubre Agent Platform.

Compartir datos: BigQuery sharing (antes Analytics Hub)

• Vistas autorizadas y datasets autorizados: compartes el resultado de una vista sin dar acceso a las tablas de origen.
• BigQuery sharing (antes Analytics Hub): plataforma de intercambio. El publicador crea exchanges y listings; el suscriptor obtiene un dataset enlazado (linked dataset) de solo lectura en su proyecto, sin copiar los datos. Admite también compartir flujos de Pub/Sub, publicar en Google Cloud Marketplace y data clean rooms (colaboración sobre datos sensibles sin exponer las filas).

«Compartir datos con otras organizaciones o filiales sin copiarlos ni duplicar el almacenamiento» → BigQuery sharing.

Seguridad a nivel de fila y columna

• IAM a nivel de proyecto, dataset, tabla o vista (roles/bigquery.dataViewer, dataEditor, jobUser…). Recuerda que ejecutar consultas requiere bigquery.jobs.create en el proyecto que paga.
• Seguridad a nivel de fila (row-level security): políticas de acceso a filas con un filtro por grupo o usuario («el equipo de España solo ve filas con pais = 'ES'»).
• Seguridad a nivel de columna: se etiquetan columnas sensibles con policy tags (taxonomías); solo quien tiene el rol Fine-Grained Reader sobre la etiqueta ve la columna.
• Enmascaramiento dinámico de datos (dynamic data masking): sobre las mismas policy tags, muestra la columna con hash, nula o parcialmente oculta según quién consulte.
• CMEK, VPC Service Controls para evitar exfiltración y Sensitive Data Protection para descubrir datos sensibles (semanas 7 y 8).

Gobierno y catálogo de datos: Knowledge Catalog

El producto de gobierno de datos ha cambiado de nombre varias veces, así que conviene tenerlo claro:

• Dataplex pasó a llamarse Dataplex Universal Catalog y, desde el 10 de abril de 2026, Knowledge Catalog. La API, el CLI y los roles mantienen el nombre dataplex.
• El antiguo Data Catalog está obsoleto y su servicio terminó el 1 de junio de 2026; su función la asume Knowledge Catalog.

Qué hace Knowledge Catalog:

• Catálogo de metadatos que indexa automáticamente BigQuery, Cloud Storage y otras fuentes, con búsqueda para encontrar datos.
• Calidad de datos (reglas y escaneos automáticos) y perfilado (data profiling).
• Linaje de datos a nivel de columna a través de las canalizaciones.
• Glosario de negocio que enlaza términos de negocio con activos técnicos.
• Contexto verificado para agentes de IA (por ejemplo, mediante MCP).

Palabras clave: «descubrir qué datos existen en la organización», «linaje», «calidad de datos», «gobierno centralizado del data lake y el data warehouse». En preguntas antiguas verás Dataplex o Data Catalog: la idea es la misma.

Visualización: Looker y Data Studio

• Looker: plataforma de BI empresarial con una capa semántica (modelos en LookML) que define una sola vez métricas y dimensiones de negocio gobernadas y las sirve a paneles, aplicaciones embebidas y otras herramientas.
• Data Studio (se llamó Looker Studio entre 2022 y abril de 2026): herramienta gratuita de informes y paneles de autoservicio; Data Studio Pro añade gestión empresarial.
• Connected Sheets: analizar tablas de BigQuery desde Google Sheets.

«Métricas gobernadas y consistentes para toda la empresa» → Looker. «Panel rápido y gratuito sobre BigQuery» → Data Studio.

Arquitecturas de referencia

Ingesta IoT y telemetría

flowchart LR
  D["Dispositivos y vehículos"] --> GW["Pasarela o broker MQTT (partner o GKE)"]
  GW --> PS["Pub/Sub"]
  PS --> DF["Dataflow (ventanas, limpieza, enriquecimiento)"]
  DF --> BT["Bigtable (últimas lecturas, baja latencia)"]
  DF --> BQ["BigQuery (analítica histórica)"]
  PS --> GCS["Cloud Storage (datos en bruto, suscripción Cloud Storage)"]
  BQ --> BI["Looker / Data Studio"]
  BQ --> ML["BigQuery ML (mantenimiento predictivo)"]

Claves: Pub/Sub absorbe los picos; Dataflow agrega por ventanas y gestiona datos tardíos; Bigtable sirve lecturas de baja latencia por dispositivo; BigQuery guarda el histórico para analítica; Cloud Storage conserva el dato en bruto para reprocesar. (IoT Core, el antiguo servicio de Google para conectar dispositivos, se retiró en 2023: hoy se usa un broker de un partner o autogestionado.)

Data lake y lakehouse

flowchart LR
  SRC["Fuentes: ficheros, SaaS, bases de datos"] -->|"Storage Transfer / Datastream / cargas"| RAW["Cloud Storage: zona en bruto"]
  RAW -->|"Spark gestionado o Dataflow"| CUR["Cloud Storage: zona curada (Iceberg / Parquet)"]
  CUR --> BL["Tablas BigLake e Iceberg"]
  BL --> BQ["BigQuery (SQL, BigQuery ML)"]
  BL --> SP["Spark (ciencia de datos)"]
  KC["Knowledge Catalog: catálogo, calidad y linaje"] -.-> RAW
  KC -.-> CUR
  KC -.-> BQ

Claves: los datos viven en formato abierto en Cloud Storage; BigQuery y Spark los consultan con el mismo control de acceso gracias a BigLake; Knowledge Catalog aporta gobierno transversal; orquesta todo con Airflow gestionado.

Analítica en tiempo real

flowchart LR
  WEB["Web y app (clics, compras)"] --> PS["Pub/Sub"]
  PS -->|"suscripción BigQuery (sin transformación)"| BQ["BigQuery"]
  PS -->|"transformación en streaming"| DF["Dataflow"] --> BQ
  OLTP["Base de datos operacional (Cloud SQL, Oracle)"] -->|"CDC"| DS["Datastream"] --> BQ
  BQ --> DASH["Data Studio / Looker (paneles casi en tiempo real)"]

Claves: si los eventos ya vienen limpios, la suscripción BigQuery evita pagar y operar Dataflow; si hay que transformar, agregar o enriquecer, Dataflow. Los datos operacionales llegan por Datastream sin cargar la base de datos de origen.

Tabla de decisión de servicios de datos

Trampas típicas del examen

• Pub/Sub entrega al menos una vez y sin orden: si el enunciado exige orden, ordering keys; si exige no duplicar, consumidores idempotentes o exactly-once (solo pull).
• Push no sirve para exactly-once y necesita un endpoint HTTPS accesible.
• Suscripción BigQuery frente a Dataflow: sin transformación → suscripción BigQuery (más simple y barata); con transformación, agregación o ventanas → Dataflow.
• Drain frente a cancel al parar un job en streaming: drain no pierde los datos en vuelo.
• Ventanas de sesión para actividad de usuario con huecos; fijas para agregados periódicos; deslizantes para medias móviles.
• Clústeres de Spark permanentes para jobs diarios son un error de coste: clúster efímero + datos en Cloud Storage + workers Spot, o serverless.
• HDFS en el clúster hace que los datos mueran con él: guarda en Cloud Storage.
• Airflow gestionado no procesa datos: orquesta. El trabajo pesado lo hacen Dataflow, Spark o BigQuery.
• LIMIT no abarata una consulta en BigQuery; SELECT de columnas concretas, particiones y clustering sí.
• Particionado por una sola columna; clustering hasta 4 columnas.
• Bajo demanda frente a capacidad: gasto alto y estable, o necesidad de coste predecible → ediciones con reservas; uso esporádico → bajo demanda.
• BigQuery no es OLTP: para una aplicación con lecturas y escrituras de filas sueltas, Cloud SQL, Spanner o Bigtable.
• Nombres nuevos: Knowledge Catalog (antes Dataplex/Dataplex Universal Catalog; Data Catalog retirado), Managed Service for Apache Spark (antes Dataproc), Managed Service for Apache Airflow (antes Cloud Composer), Data Studio (antes Looker Studio), BigQuery sharing (antes Analytics Hub). En el examen pueden aparecer con cualquiera de los dos nombres.

Resumen

• Distingue lotes (datos acotados) y streaming (no acotados) y ETL frente a ELT; con BigQuery, ELT suele ser lo más simple.
• Pub/Sub desacopla y absorbe picos: pull, push, BigQuery y Cloud Storage; retención de 7 días por defecto; orden por clave; exactly-once solo en pull; dead letter tras 5-100 intentos.
• Dataflow ejecuta Apache Beam en lotes y streaming, con ventanas fijas, deslizantes y de sesión, marcas de agua, autoescalado y plantillas listas para usar.
• Spark gestionado para migrar Hadoop/Spark: clústeres efímeros con datos en Cloud Storage, o serverless para Spark nuevo. Data Fusion para ETL visual; Datastream para CDC hacia BigQuery.
• Airflow gestionado para orquestar canalizaciones complejas; Workflows para encadenar APIs de forma serverless.
• BigQuery: columnar y serverless; particiona por fecha, agrupa por columnas de filtro; bajo demanda (6,25 USD/TiB, 1 TiB gratis al mes) o capacidad con ediciones; dry run y máximo de bytes facturados para controlar el gasto.
• BigLake e Iceberg para el lakehouse; BigQuery ML para ML con SQL; BigQuery sharing para compartir sin copiar; seguridad de filas, columnas (policy tags) y enmascaramiento.
• Knowledge Catalog para catálogo, calidad y linaje; Looker para BI gobernado y Data Studio para paneles de autoservicio.

Practica lo aprendido

Documentación oficial para ampliar

• Pub/Sub – Subscription overview
• Pub/Sub – BigQuery subscriptions
• Dataflow overview
• Google-provided Dataflow templates
• Managed Service for Apache Spark – serverless vs clusters
• Managed Service for Apache Airflow (Cloud Composer) overview
• Datastream overview
• BigQuery – Partitioned tables
• BigQuery editions
• BigQuery pricing
• BigLake tables
• BigQuery sharing (antes Analytics Hub)
• Knowledge Catalog overview