Google PDE: Arquitectura y Diseño de Ingeniería de Datos — Guía de estudio

By Laurynas Brazys · 21 August 2026 · #google #PDE #certification #exam-prep #study-guide

Forma parte de la Google Professional Data Engineer — Guía de estudio. Practica con respuestas verificadas en el centro de exámenes de Google, o realiza tests cronometrados en ExamRoll.io.

Descripción general

La arquitectura y el diseño de ingeniería de datos en Google Cloud equilibra los límites de dominio, los patrones de procesamiento y las capacidades de los servicios para ofrecer plataformas de datos fiables, escalables y rentables. Los diseños eficaces hacen que el almacenamiento, el cómputo, la orquestación y el servicio sean escalables de forma independiente; codifican contratos para que los dominios interoperen; y validan los riesgos de forma temprana con objetivos de nivel de servicio (SLO) medibles. Esta sección resume los estilos arquitectónicos canónicos (data mesh, data lake, data warehouse, lakehouse, almacenes operacionales), los modos de procesamiento (batch, micro-batch, streaming, orientado a eventos, lambda) y las compensaciones entre escalabilidad, latencia, disponibilidad, consistencia y costo. También cubre la ubicación regional y multicloud, la evolución de esquemas, el ciclo de vida de los datos de extremo a extremo, la selección de servicios basada en la carga de trabajo y las prácticas de validación basadas en el riesgo adaptadas a Google Cloud.

Paradigmas Arquitectónicos y Patrones de Procesamiento

• Data mesh, dominios y productos de datos:
  • Empoderar a los equipos de dominio para que publiquen “productos de datos” con una propiedad clara, SLO, políticas de acceso y documentación. Usar Dataplex para definir dominios, gobernar los metadatos y aplicar políticas consistentes en BigQuery y Cloud Storage. Los productos pueden exponer datasets de BigQuery, temas de Pub/Sub o rutas de Cloud Storage con contratos aplicados mediante esquemas de Pub/Sub y esquemas de tablas de BigQuery.
• Data lake:
  • Almacenamiento en formato abierto y sin procesar (Parquet/Avro) en Cloud Storage con ciclo de vida y versionado. Adecuado para cargas de trabajo heterogéneas (Spark en Dataproc, Dataflow, Presto/Trino) y portabilidad multicloud. Compensación: semántica de consistencia eventual en los almacenes de objetos; diseñar para la idempotencia y la deduplicación basada en metadatos.
• Data warehouse:
  • Análisis curado y gobernado en BigQuery. Optimizado para ANSI SQL, separación de almacenamiento y cómputo, y seguridad de grano fino. Compensaciones: las inserciones en streaming presentan una breve obsolescencia en el momento de la consulta; preferir cargas por lotes o inserciones con consultas en búfer para SLA de frescura estrictos.
• Lakehouse:
  • Combina el almacenamiento de data lake abierto con las capacidades de un data warehouse. En Google Cloud, almacene Parquet/Avro en Cloud Storage; utilice tablas externas de BigQuery por economía y tablas administradas de BigQuery para rendimiento y gobernanza. Dataflow o Dataproc mantiene una semántica de fusión similar a ACID con estrategias de particionamiento y clustering.
• Arquitectura de almacén operacional:
  • Almacenes transaccionales o de clave-valor de baja latencia que respaldan aplicaciones. Elija Cloud SQL para OLTP tradicional, Cloud Spanner para SQL globalmente consistente con escalabilidad horizontal, y Bigtable para patrones de acceso de columna ancha y muy alto rendimiento. Separar los almacenes operacionales de los analíticos; utilizar CDC (Datastream) para capturar cambios en Pub/Sub, Cloud Storage o BigQuery.

Patrones de procesamiento y cuándo usarlos:

• Batch: Transformaciones periódicas a gran escala (p. ej., generación nocturna de características). Herramientas: Dataflow batch, Dataproc. Modos de fallo: timeouts en trabajos de larga duración, desbalanceo (skew); mitigar con autoescalado y reparticionamiento.
• Micro-batch: Lotes pequeños y frecuentes (p. ej., cada minuto) para equilibrar la frescura con la estabilidad y el costo. En BigQuery, use consultas programadas o Dataflow con ventanas fijas.
• Streaming: Latencia de milisegundos a segundos en datos no acotados. Use Pub/Sub + Dataflow. Manejar eventos tardíos o desordenados con ventanas de tiempo de evento y marcas de agua (watermarks); asegurar la idempotencia para evitar duplicados.
• Orientado a eventos: Desencadenado por cambios (finalización en GCS, mensajes de Pub/Sub). Use Cloud Functions o Cloud Run para reacciones sin estado y Dataflow para procesamiento con estado. Compensación: costos por evento frente a rendimiento (throughput).
• Patrón Lambda: Mantener rutas tanto de streaming como de batch para precisión y reprocesamiento. La complejidad se duplica; considerar una simplificación tipo Kappa donde todo es reproducible desde un log inmutable (archivado de Pub/Sub a Cloud Storage).

Ejemplo corto de configuración de streaming en Dataflow para datos tardíos:

events
  .apply(Window.into(FixedWindows.of(Duration.standardMinutes(5)))
    .withAllowedLateness(Duration.standardMinutes(10))
    .accumulatingFiredPanes());

Propiedad de Dominio, Productos de Datos y Contratos

• Propiedad y SLO:
  • Cada equipo de dominio define y opera sus productos de datos con SLO de disponibilidad, latencia y calidad de datos. Publicar los SLO a través de los catálogos de Dataplex y monitorearlos con SLI de Cloud Monitoring (p. ej., completitud de particiones a tiempo).
• Contratos e interoperabilidad:
  • Hacer cumplir los esquemas con Pub/Sub Schema Registry (Avro/Proto) y los esquemas de tablas de BigQuery. Para la ingesta de CSV, validar en Dataflow y enrutar las filas con formato incorrecto a una tabla de “dead-letter” para su análisis. Interoperar con formatos abiertos en Cloud Storage y tablas externas de BigQuery cuando múltiples motores deben leer los mismos datos.
• Evolución de esquemas:
  • Favorecer cambios retrocompatibles: añadir columnas que acepten nulos, añadir campos opcionales en Avro/Proto, evitar renombramientos o eliminaciones sin ventanas de obsolescencia. Comunicar los cambios a través de contratos versionados y cronogramas de obsolescencia.
  • Ejemplo de BigQuery (adición de columna retrocompatible):

ALTER TABLE sales.orders
ADD COLUMN coupon_code STRING;

• Impacto en el consumidor:
  • Mantener un versionado semántico de los esquemas; publicar tanto v1 como v2 durante la migración. Para el streaming, enrutar a temas versionados o incluir un campo de versión de esquema. Proporcionar vistas autorizadas en BigQuery para aislar a los consumidores de los cambios físicos.
• Gobernanza y linaje:
  • Usar Dataplex y Data Catalog para metadatos, etiquetas (p. ej., PII) y linaje de datos. Aplicar seguridad a nivel de fila y columna en BigQuery. Para la prevención de pérdida de datos, integrar Cloud DLP en la ingesta (p. ej., transformaciones en Cloud Run o Dataflow) para tokenizar o redactar campos sensibles antes de su almacenamiento.

Compromisos no funcionales y topología de despliegue

• Escalabilidad:
  • BigQuery escala elásticamente para el análisis de datos; Bigtable escala linealmente con el número de nodos, pero requiere un diseño cuidadoso de la clave de fila (p. ej., prefijos con hash o rotados) para evitar el hotspotting. El autoescalado de Dataflow responde a los trabajos acumulados (backlogs); diseña para la contrapresión (backpressure) aprovechando el control de flujo de Pub/Sub.
• Latencia:
  • El streaming a BigQuery ofrece inserciones de baja latencia, pero las consultas pueden experimentar un ligero retraso; diseña consultas con un búfer de actualidad (freshness buffer) o ventanas basadas en marcas de agua (watermarks). Para lecturas a escala por debajo de los 100 ms, precalcula y sirve los datos desde Bigtable o Memorystore.
• Disponibilidad y consistencia:
  • Cloud Spanner proporciona SQL fuertemente consistente y distribuido globalmente. Bigtable ofrece alta disponibilidad con consistencia eventual entre clústeres. La disponibilidad de BigQuery es regional o multirregional; materializa los conjuntos de datos críticos en una multirregión para mayor resiliencia.
• Costo:
  • Optimiza BigQuery con particionamiento y agrupamiento en clústeres (clustering) para reducir los bytes escaneados. Para archivos pequeños en enlaces de red limitados, agrúpalos en lotes o paquetes para reducir la sobrecarga de las RPC. Usa BigQuery BI Engine para dashboards interactivos y almacenados en caché cuando sea apropiado.
• Regional, multirregional, híbrido y multinube:
  • Un diseño regional reduce la latencia y el costo; el almacenamiento multirregional (p. ej., la multirregión US/EU de BigQuery, las regiones duales/múltiples de Cloud Storage) aumenta la durabilidad y las opciones de localidad. Para la recuperación ante desastres (DR), define el RPO/RTO y replica los conjuntos de datos críticos. En escenarios híbridos, usa Datastream para la captura de datos de cambios (CDC) y Transfer Appliances o Storage Transfer Service para la migración masiva. Para entornos multinube (multi-cloud), estandariza con formatos abiertos en Cloud Storage y usa cómputo portable (Apache Beam/Dataflow, Spark on Dataproc), sin olvidar la sobrecarga operativa y de egreso de datos.

Capas, ciclo de vida y selección de servicios

• Separación de capas:
  • Almacenamiento: Cloud Storage para datos crudos/bronce y de archivo; BigQuery para analíticas curadas/de servicio; Bigtable para acceso por clave de baja latencia; Spanner/Cloud SQL para OLTP.
  • Cómputo: Dataflow para streaming/lotes sin servidor; Dataproc para ecosistemas Spark/Hadoop; BigQuery para ELT dentro del data warehouse; Cloud Run/Functions para microservicios de eventos.
  • Orquestación: Cloud Composer (Airflow) o Workflows para DAGs y coreografía de APIs; Scheduler para disparadores tipo cron.
  • Servicio: Bigtable o Spanner para lecturas en línea; BigQuery para BI; Looker/BI Engine para paneles de control; Memorystore para almacenamiento en caché.
• Ciclo de vida de los datos:
  • Ingesta: Pub/Sub para flujos de datos; Storage Transfer o gsutil para archivos; Data Transfer Service para SaaS. Validar, deduplicar y depositar datos crudos inmutables en Cloud Storage con el versionado de objetos.
  • Procesamiento: Usar Dataflow o BigQuery para transformar de crudo a plata (limpios, conformados), y luego a oro (marts listos para el negocio).
  • Servicio: Publicar vistas/tablas de BigQuery para analíticas; precalcular características o predicciones en Bigtable para APIs.
  • Retención y archivo: Aplicar reglas de ciclo de vida de Cloud Storage para transicionar a los niveles Coldline/Archive; usar particionamiento por tiempo de BigQuery con expiración de particiones para la retención. Habilitar CMEK donde sea necesario y VPC Service Controls para la protección contra la exfiltración de datos.
• Selección de servicios basada en las características de la carga de trabajo:
  • Series temporales de alto rendimiento con filas anchas y baja latencia: Bigtable.
  • OLTP global fuertemente consistente con SQL ANSI: Cloud Spanner.
  • Transacciones relacionales tradicionales con una escala modesta: Cloud SQL.
  • Analíticas a escala de petabytes con SQL ANSI y separación de almacenamiento/cómputo: BigQuery.
  • Ingesta y procesamiento en tiempo real: Pub/Sub + Dataflow.
  • Procesos por lotes de Spark/Hadoop o herramientas específicas de librerías: Dataproc.

Ejemplo corto de particionamiento en BigQuery:

CREATE TABLE ops.events
PARTITION BY DATE(event_ts)
CLUSTER BY device_id AS
SELECT * FROM staging.events_clean;

Escenario de problema práctico

Contoso Mobility opera una flota global de patinetes eléctricos y necesita ingesta, procesamiento, almacenamiento y analíticas en tiempo real para la telemetría de viajes y la facturación. Deben soportar millones de eventos por minuto, reglas de fraude en menos de un segundo, paneles de control actualizados, controles de privacidad y operaciones multirregionales resilientes.

Enfoque:

1. Establecer la ingesta de eventos con Cloud Pub/Sub.

• Justificación: Pub/Sub proporciona un único punto de conexión global, almacenamiento en búfer duradero y escalado horizontal para el tráfico de dispositivos en ráfagas. Usar claves ordenadas por patinete para preservar el orden dentro del dispositivo para ventanas de 1 hora.

2. Implementar el procesamiento en streaming con Cloud Dataflow (Apache Beam).

• Justificación: El autoescalado de Dataflow maneja los picos y ofrece receptores (sinks) de tipo “exactly-once” cuando se combina con claves idempotentes. Usar ventanas de tiempo de evento y marcas de agua (watermarks) para manejar telemetría tardía o desordenada. Emitir una salida principal hacia los flujos de datos curados y una salida secundaria para registros en cola de mensajes fallidos (dead-letter).
• Configuración:

.withAllowedLateness(Duration.standardMinutes(15))
.discardingFiredPanes();

3. Persistir datos crudos y curados en Cloud Storage y BigQuery, respectivamente.

• Justificación: Depositar archivos Avro crudos (bronce) en un bucket de Cloud Storage de doble región para repetición y auditoría. Escribir flujos de datos curados (plata) en tablas particionadas de BigQuery para analíticas, con clustering por scooter_id para búsquedas puntuales eficientes. Aplicar un pequeño búfer de actualidad en las consultas del panel para evitar la obsolescencia transitoria del streaming.

4. Servir búsquedas operativas y verificaciones de fraude desde Cloud Bigtable.

• Justificación: La evaluación de reglas en menos de 100 ms necesita acceso aleatorio de baja latencia. Precalcular agregados (p. ej., viajes por dispositivo por ventana de 5 minutos) en Dataflow y escribirlos en Bigtable usando una clave de fila con prefijo hasheado (p. ej., h(prefijo)+id_dispositivo+inicio_ventana) para evitar el hotspotting y paralelizar las lecturas entre las tabletas.

5. Gestionar la facturación transaccional en Cloud Spanner.

• Justificación: La facturación requiere SQL globalmente consistente, consistencia fuerte y alta disponibilidad. Usar un líder en la geografía principal con réplicas de solo lectura en regiones secundarias para reducir las latencias de lectura para los portales de clientes.

6. Aplicar la gobernanza con Dataplex, Data Catalog y Cloud DLP.

• Justificación: Clasificar campos de PII, etiquetar conjuntos de datos y aplicar seguridad a nivel de columna en BigQuery. Integrar Cloud DLP en el pipeline de Dataflow para tokenizar atributos sensibles antes del almacenamiento. Los dominios de Dataplex reflejan la propiedad organizacional; cada dominio publica productos de datos documentados con SLOs.

7. Orquestar y operar con Cloud Composer y Cloud Monitoring.

• Justificación: Composer coordina rellenados de datos por lotes (backfills), compactaciones y materialización de características de ML. Monitoring observa los SLIs de extremo a extremo: backlog de Pub/Sub, retraso de la marca de agua (watermark lag) de Dataflow, completitud de la partición de BigQuery y latencias de cola de Bigtable. Alertar sobre violaciones de SLO; autoescalar Dataflow según el crecimiento del backlog.

8. Optimizar costos y ciclo de vida con particionamiento y niveles de almacenamiento.

• Justificación: Las tablas de BigQuery están particionadas por event_ts con una retención de 90 días, y clusterizadas por scooter_id. Cloud Storage usa reglas de ciclo de vida para transicionar los datos crudos a Coldline después de 30 días y a Archive después de 180 días. Trabajos programados de BigQuery compactan pequeños archivos de microlotes en objetos parquet más grandes para reducir la sobrecarga por cantidad de archivos para los trabajos de Spark posteriores.

9. Validar riesgos y resiliencia.

• Justificación: Realizar pruebas de carga al doble del pico esperado para validar las cuotas de Pub/Sub y el autoescalado de Dataflow. Realizar un ejercicio de conmutación por error (failover) regional: los conjuntos de datos multirregionales de BigQuery y los buckets de doble región mantienen la disponibilidad; la instancia multirregional de Spanner mantiene un RPO=0 y el RTO configurado mediante la conmutación por error automática. Usar Infraestructura como Código (Terraform) con validación de políticas para aplicar CMEK y VPC Service Controls.

Esta arquitectura separa claramente las responsabilidades: Pub/Sub actúa como búfer para la ingesta, Dataflow realiza el cómputo, Cloud Storage y BigQuery almacenan y sirven analíticas, Bigtable acelera las lecturas operativas y Spanner garantiza transacciones consistentes. Equilibra la escalabilidad y la latencia mientras controla los costos a través del particionamiento, el clustering, las políticas de ciclo de vida y el autoescalado, e incorpora gobernanza y fiabilidad a través de productos de datos documentados, contratos y validación continua.

Todos los dominios · Almacenamiento de Datos →

Practica estas preguntas → · Práctica cronometrada en ExamRoll.io →

Explorar Google →