Google PCA: Almacenamiento de Datos, Bases de Datos y Arquitectura de Analíticas — Guía de estudio

By Laurynas Brazys · 5 September 2026 · #google #PCA #certification #exam-prep #study-guide

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

Resumen

El diseño del almacenamiento de datos, las bases de datos y la analítica en Google Cloud requiere hacer coincidir los patrones de carga de trabajo con los servicios, mientras se planifica la durabilidad, la disponibilidad, el control de acceso, el costo y la resiliencia operativa. Esta sección cubre el almacenamiento de objetos y la gobernanza del ciclo de vida; las bases de datos operativas y las cachés; el almacenamiento y procesamiento analítico; las arquitecturas de ingesta; y las prácticas de gobernanza, protección y rendimiento. Se destacan las decisiones de diseño, el razonamiento operativo y los modos de fallo o contrapartidas comunes.

Arquitectura de almacenamiento y objetos

Diseño de buckets de Cloud Storage

Ubicación: elija una región para cargas de trabajo de baja latencia y sensibles al costo; una región dual para la continuidad del negocio con conmutación por error predecible; una multirregión para el acceso de lectura global. La región dual ofrece replicación turbo opcional para un RPO bajo respaldado por un SLA; de lo contrario, la replicación es asíncrona.
Espacio de nombres y separación: utilice buckets separados para dominios de datos, entornos y niveles de sensibilidad. Emplee el acceso uniforme a nivel de bucket y la prevención del acceso público para obtener permisos consistentes.
Clases de almacenamiento: Standard para datos de acceso frecuente (calientes); Nearline para datos de acceso poco frecuente (mensual); Coldline para acceso trimestral; Archive para retención a largo plazo. Autoclass puede optimizar la ubicación de la clase automáticamente con un trabajo operativo mínimo.
Políticas de ciclo de vida: automatice la transición y la eliminación por antigüedad, clase de almacenamiento o prefijo de objeto. Ejemplo para eliminar objetos con más de 90 días de antigüedad: { “rule”: [ { “action”: {“type”: “Delete”}, “condition”: {“age”: 90} } ] } Aplique con: gsutil lifecycle set lifecycle.json gs://my-bucket
Retención y conservaciones legales: configure políticas de retención de buckets y, opcionalmente, bloquéelas para evitar su reducción (cumplimiento normativo). Las conservaciones basadas en eventos y el control de versiones de objetos permiten la recuperación de eliminaciones o sobrescrituras accidentales.
Replicación: elija la región dual para una semántica de consistencia síncrona en la API con replicación en segundo plano entre dos regiones; utilice la replicación de bucket a bucket (para copias entre proyectos o ubicaciones) para cumplir con RPO/RTO especializados o la separación de funciones.

Modos de fallo y contrapartidas

Un desajuste de clase infla el costo y la latencia. Autoclass reduce esto, pero añade una sobrecarga de gestión por objeto.
El bloqueo de retención es irreversible; pruebe las políticas en entornos de no producción.
La replicación mejora la durabilidad, pero puede aumentar la latencia de escritura y el costo; diseñe las rutas de lectura/escritura para ubicaciones específicas.

Patrones

Data lake: zonas de datos brutos (raw) y curados en Cloud Storage; gobernanza a través de Dataplex; esquemas externalizados en Data Catalog.
Archivado: clase Archive con bloqueo de retención para cumplimiento normativo, con tablas externas de BigQuery o restauración bajo demanda para análisis poco frecuentes.
Lakehouse: utilice BigLake para unificar el acceso a través de Cloud Storage y BigQuery con seguridad consistente.

Almacenes de Datos Operacionales y Caché

Cloud SQL

Alta disponibilidad: HA regional con replicación síncrona a una instancia en espera (standby); la conmutación por error automática (failover) suele tardar de segundos a un par de minutos. El endpoint de la instancia permanece igual, minimizando los cambios en la aplicación.
Réplicas de lectura: dentro de la región o entre regiones, de forma asíncrona; adecuadas para escalar horizontalmente las lecturas y para recuperación ante desastres (DR). Monitorea el retardo (lag); las lecturas de datos obsoletos (stale reads) pueden afectar la correctitud.
Copias de seguridad y PITR: copias de seguridad programadas más recuperación a un punto en el tiempo (point-in-time recovery) usando los registros de transacciones (generalmente una ventana de hasta 7 días, dependiendo del motor). Prueba la restauración regularmente.
Conectividad privada: la IP privada a través de VPC peering reduce la exposición y la latencia; planifica los rangos de IP para evitar solapamientos.
Migración: Database Migration Service permite migraciones con bajo tiempo de inactividad desde entornos on-premise u otras nubes; para enlaces de alto volumen, prefiere Dedicated o Partner Interconnect en lugar de VPN para reducir la pérdida de paquetes y la latencia.

Compensaciones y modos de fallo

Las conmutaciones por error de HA reinician las conexiones; las aplicaciones deben reintentar con un retardo exponencial (backoff). Las ventanas de mantenimiento pueden degradar brevemente el rendimiento.
Las transacciones de larga duración aumentan el retardo de replicación y el tiempo de recuperación de PITR.
El almacenamiento sobreaprovisionado es un seguro barato; un IOPS infraaprovisionado causa fallos latentes bajo picos de carga.

Cloud Spanner

Escala y consistencia globales: lecturas/escrituras fuertemente consistentes entre regiones usando TrueTime y confirmación en dos fases (two-phase commit). Elige regional para la latencia de escritura más baja; multirregional para mayor disponibilidad y lecturas globales.
Transacciones: consistencia externa y totalmente ACID entre filas y tablas; las transacciones de solo lectura escalan entre las réplicas.
Diseño del esquema: elige claves primarias que eviten puntos calientes (hotspots); usa tablas intercaladas (interleaved tables) para la localidad de los datos; considera la amplificación de escritura y el comportamiento de relleno (backfill) de los índices secundarios.
Regionalidad: la ubicación de la región líder (leader) determina la latencia de escritura; la configuración multirregional añade costos de quórum y latencia de confirmación (commit).

Compensaciones

La latencia de escritura aumenta con la dispersión geográfica; evita la configuración multirregional a menos que la disponibilidad y la distribución global lo justifiquen.
El costo base es más alto que el de las bases de datos en una VM de un solo nodo; la planificación de capacidad debe alinearse con los SLO y el crecimiento.

Firestore, Bigtable, Memorystore y selección

Firestore: base de datos de documentos para backends móviles/web; consistencia fuerte para documentos individuales; seguridad de grano fino; indexación automática. Cuidado con la contención en documentos actualizados con frecuencia; usa contadores distribuidos y escrituras por lotes (batched writes).
Bigtable: de columna ancha, a escala de petabytes, para series temporales e IoT con latencia ultrabaja; diseña las claves de fila (row keys) para evitar hotspots (p. ej., con hash o salting); escala por nodos y clústeres; enrutamiento multiclúster para la disponibilidad. La replicación es asíncrona; la consistencia fuerte es por clúster.
Memorystore for Redis: caché en memoria; el nivel Básico es una instancia única (sin HA); el nivel Estándar proporciona una réplica y conmutación por error automática (posibles desconexiones breves). Trátalo como una caché, no como la fuente de verdad; las características de persistencia reducen la volatilidad pero no reemplazan las copias de seguridad de la base de datos.

Selección según la carga de trabajo

Carga de trabajo	Servicio recomendado
Relacional con joins/ACID y escala moderada	Cloud SQL
Relacional global con escala horizontal y consistencia externa	Cloud Spanner
Series temporales/telemetría de alto rendimiento o clave-valor muy grande	Bigtable
Modelos de documentos centrados en la aplicación con consultas jerárquicas	Firestore
Aceleración efímera y limitación de velocidad (rate limiting)	Memorystore

Analítica, Ingesta y Procesamiento

BigQuery

Datasets: límites lógicos de seguridad y facturación; adopta convenciones de nomenclatura por dominio y etapa del ciclo de vida.
Particionamiento: por tiempo de ingesta o por columna para filtrado temporal; también particionamiento por rango de enteros. Usa el particionamiento por unidad de tiempo para event_ts para podar escaneos (prune scans).
Clustering: hasta cuatro columnas para coubicar datos relacionados en el almacenamiento; mejora el rendimiento y el costo de las consultas selectivas.
Reservations: gestiona slots dedicados mediante reservas y asignaciones; usa flex slots para experimentos con picos de carga (bursty); aísla las cargas de trabajo críticas para evitar la inanición (starvation).
Control de acceso: IAM a nivel de proyecto y dataset; control de tablas/columnas con políticas a nivel de fila (row-level policies) y etiquetas de política (policy tags); comparte datos curados a través de vistas y rutinas autorizadas.

Ejemplo útil:

undefined

Compensaciones y modos de fallo

Un mal particionamiento conduce a escaneos de tabla completos y costos descontrolados.
El clustering solo ayuda cuando los filtros o joins incluyen las columnas clusterizadas; las reorganizaciones frecuentes pueden reducir el beneficio.
El infraaprovisionamiento de slots pone los trabajos en cola; el sobreaprovisionamiento aumenta el costo. Monitorea la utilización de slots y el spilled shuffle.

Ingesta y procesamiento de datos

Pub/Sub: entrega global, duradera y de al menos una vez (at-least-once); las claves de ordenamiento (ordering keys) garantizan el orden por clave con compensaciones de rendimiento. Diseña consumidores idempotentes.
Dataflow: procesamiento unificado por lotes (batch) y en tiempo real (streaming) con autoescalado, procesamiento con estado y semántica de exactamente una vez (exactly-once), ventanas (windowing) y disparadores (triggers); Streaming Engine descarga el estado. Usa temas de mensajes fallidos (dead-letter topics) y fuentes reproducibles (replayable sources).
Dataproc: Spark/Hadoop gestionado para código y ecosistemas existentes; clústeres efímeros o con autoescalado; úsalo para librerías de ML o cuando la migración de código es costosa.

Compensaciones entre batch y streaming

El streaming reduce la latencia y soporta el tiempo real, pero aumenta la complejidad (estado, marcas de agua, datos tardíos) y los costos operativos.
El procesamiento por lotes (batch) simplifica la correctitud y el control de costos; es aceptable cuando los SLA toleran la demora.
Patrones híbridos: almacena eventos crudos en Cloud Storage, transmite KPIs agregados a BigQuery en tiempo real y ejecuta recálculos nocturnos por lotes para mayor precisión.

Patrones de Warehouse

Warehouse: BigQuery como el sistema de análisis; vistas materializadas y consultas programadas para servir a BI.
Lakehouse: gestiona datos en Cloud Storage con formatos abiertos; exponlos a través de BigLake a BigQuery con seguridad consistente.

Gobernanza, protección y rendimiento

Gobernanza y seguridad de los datos

Metadatos y linaje: usar Data Catalog para metadatos técnicos y de negocio; habilitar la captura de linaje desde Dataflow, BigQuery y Dataproc para rastrear dependencias.
Calidad: aplicar reglas con la calidad de datos de Dataplex y orquestar verificaciones en Composer o Dataform; poner en cuarentena los registros incorrectos.
Límites de acceso: VPC Service Controls alrededor de BigQuery y Cloud Storage para reducir el riesgo de exfiltración; Condiciones de IAM para acceso sensible al contexto; CMEK para control criptográfico; etiquetas de políticas (policy tags) para restricciones a nivel de columna.
Retención: alinear la retención de buckets de Cloud Storage, el time travel de tablas de BigQuery (configurable hasta 7 días) y la expiración de datasets/tablas con los requisitos legales.

Backup, PITR y protección contra borrado

Validar backups: restaurar periódicamente los backups de Cloud SQL y Spanner en entornos aislados y ejecutar checksums y validaciones a nivel de aplicación.
Bigtable: habilitar PITR para recuperar a un punto en el tiempo dentro de una retención configurada; probar restauraciones a nivel de tabla o clúster.
Spanner: usar backups para recuperación ante desastres; aprovechar las lecturas inactivas (stale reads) dentro de la retención de versiones para consultas de auditoría.
Cloud Storage: habilitar el versionado de objetos y el bloqueo de retención de buckets para proteger contra borrados accidentales; replicar a un proyecto separado para aislar errores de operador.
BigQuery: usar time travel y snapshots de tablas; evitar eliminaciones (drops) en datasets de producción con aprobaciones requeridas y protección contra borrado a nivel de dataset.

Rendimiento de datos y control de costos

Evitar claves calientes (hot keys): distribuir las claves de fila de Bigtable (prefijos hash), elegir claves primarias de Spanner que aleatoricen las elecciones de líder, fragmentar (shard) los contadores de Firestore.
Índices: mantener los índices SQL y NoSQL necesarios; en BigQuery, clusterizar por filtros comunes; en Cloud SQL, monitorear consultas lentas y ejecutar vacuum/analyze en Postgres regularmente.
Planificación de capacidad: establecer una línea base con pruebas de carga; definir SLOs y presupuestos de error; monitorear la utilización de slots de BigQuery, las latencias de CPU/lectura-modificación-escritura de Bigtable, la CPU/IOPS de Cloud SQL y el backlog de Pub/Sub.
Controles de costos: usar compromisos de slots de BigQuery para cargas de trabajo estables, Autoclass para Cloud Storage, compactar tablas de Bigtable y ajustar los filtros de Bloom, expirar particiones y datasets antiguos e implementar presupuestos y alertas por equipo.

Escenario de problema práctico

Acme Retail Group necesita una plataforma unificada de analítica de clickstream y pedidos de baja latencia. Requisitos: KPIs en tiempo real en menos de 10 segundos, análisis histórico de más de cinco años con SQL, objetivos de recuperación de menos de una hora, residencia estricta de datos en EE. UU. y prevención de la pérdida accidental de datos.

Aterrizar eventos sin procesar e implementar una ingesta duradera

Crear buckets de Cloud Storage de doble región us-central1/us-east1 para zonas de datos crudos (raw) y curados; habilitar Autoclass y el versionado de objetos en la zona de crudos.
Justificación: la doble región cumple con la durabilidad y la residencia; el versionado protege contra backfills incorrectos; Autoclass optimiza el costo de almacenamiento automáticamente.

Transmitir eventos de forma fiable con Pub/Sub y Dataflow

Publicar eventos de clickstream y pedidos en temas de Pub/Sub con claves de ordenamiento (ordering keys) por user_id; implementar un pipeline de streaming de Dataflow para validar, deduplicar, enriquecer y bifurcar la salida hacia BigQuery (KPIs calientes) y Cloud Storage (parquet en la zona curada).
Justificación: Pub/Sub proporciona entrega global, duradera y al menos una vez (at-least-once); Dataflow ofrece estado exactamente una vez (exactly-once) y autoescalado; la bifurcación mantiene un patrón de lakehouse para el reprocesamiento.

Servir características en tiempo real en Bigtable y Redis

Escribir un subconjunto de eventos enriquecidos en Bigtable con una clave de fila user_id#timestamp con sal (salted); usar Memorystore for Redis como caché frontal para las sesiones más recientes.
Justificación: Bigtable ofrece escrituras de baja latencia y alto rendimiento para series temporales; el salting evita hotspots; Redis reduce la latencia de cola (tail latency) para la personalización en vivo.

Almacenar y optimizar consultas en BigQuery

Crear datasets particionados por event_date y clusterizados por user_id, channel. Usar vistas materializadas para KPIs y compactaciones programadas para cargas de archivos pequeños; comprar una reserva de slots base con un pequeño búfer de slots flexibles para picos de carga.
Justificación: la partición y la clusterización podan los escaneos (prune scans) y reducen el costo; las vistas materializadas aceleran los dashboards; las reservas limitan el costo y protegen las cargas de trabajo críticas de las colas.

Gobernar el acceso y prevenir la exfiltración

Aplicar IAM a nivel de dataset para grupos de analistas; usar etiquetas de políticas (policy tags) para restringir columnas con PII y vistas autorizadas para el acceso de proveedores. Forzar VPC Service Controls alrededor de BigQuery y Cloud Storage; usar CMEK para datasets regulados.
Justificación: mínimo privilegio a nivel de dataset y columna; VPC SC reduce el riesgo de exfiltración de datos; CMEK satisface los requisitos de control criptográfico.

Implementar backups, PITR y pruebas de restauración

Habilitar PITR de Bigtable durante 7-14 días; crear backups semanales de Spanner o Cloud SQL para los almacenes de pedidos transaccionales; crear snapshots diarios de las tablas críticas de BigQuery y confiar en el time travel para errores. Ejecutar simulacros de restauración trimestrales en un proyecto aislado.
Justificación: las opciones de recuperación por capas abordan errores lógicos y desastres; los simulacros regulares validan el RPO/RTO y los runbooks.

Controlar la retención y el ciclo de vida de los datos

Aplicar una regla de ciclo de vida para purgar objetos crudos después de 30 días y curados después de cinco años; bloquear una política de retención a nivel de bucket que cumpla con la normativa. Establecer la expiración predeterminada de datasets/tablas de BigQuery para datasets transitorios.
Justificación: la aplicación automática reduce el riesgo operativo; el bloqueo de retención previene el debilitamiento accidental o no autorizado de la política.

Monitorear el rendimiento y el costo, y mitigar los hotspots

Seguir la utilización de slots de BigQuery, los bytes escaneados y la concurrencia de consultas de BI; monitorear la CPU de Bigtable y la latencia de lectura-modificación-escritura; alertar sobre el backlog de Pub/Sub. Si surgen hotspots de user_id, aumentar el ancho del sal (salt) y hacer un backfill de las claves a través de Dataflow.
Justificación: la telemetría continua encuentra cuellos de botella temprano; los cambios proactivos en la estrategia de claves preservan los SLOs sin una rearquitectura completa.

Proporcionar conectividad privada y aislamiento

Para dependencias híbridas, usar Partner o Dedicated Interconnect con Cloud Router; asegurar rangos de IP que no se superpongan; usar Private Service Connect para los endpoints de servicios gestionados.
Justificación: las rutas privadas reducen la latencia y la pérdida de paquetes; una planificación clara de IP y PSC refuerzan el aislamiento y el enrutamiento predecible.

Operacionalizar la fiabilidad

Habilitar pipelines canary de Dataflow y vistas blue/green de BigQuery; forzar la evolución del esquema mediante aprobaciones en Data Catalog; integrar las colas de mensajes fallidos (dead-letter queues) con la respuesta a incidentes.
Justificación: los despliegues controlados limitan el radio de impacto (blast radius); los cambios de esquema gobernados mantienen la calidad de los datos; las DLQ aseguran que no se pierdan datos durante los incidentes.

← Cómputo · Todos los dominios · Redes →

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