Google PDE: Almacenamiento de Datos, Lagos y Formatos de Archivo — 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

El almacenamiento de datos en Google Cloud abarca desde el almacenamiento de objetos sin procesar hasta los data lakes curados y los formatos optimizados para el análisis. Construir lagos de datos fiables, gobernados y de alto rendimiento requiere elecciones cuidadosas en cuanto a clases de almacenamiento, configuración de buckets, ubicaciones, formatos de archivo, diseño de tablas y ciclo de vida. Esta sección detalla las compensaciones de diseño, los modos de fallo que se deben evitar y los patrones que se alinean con BigQuery, Spark y las canalizaciones de streaming a escala.

Fundamentos de Cloud Storage: clases, buckets, consistencia y ciclo de vida

Cloud Storage es la base duradera y de alta disponibilidad para archivos sin procesar y curados.

Clases de almacenamiento
- Standard (acceso frecuente): acceso frecuente, latencia más baja. Sin duración mínima de almacenamiento.
- Nearline (acceso poco frecuente): acceso poco frecuente (~mensual). Mínimo de 30 días; se aplican tarifas de recuperación.
- Coldline (acceso esporádico): acceso poco frecuente (~trimestral). Mínimo de 90 días; tarifas de recuperación más altas.
- Archive (archivado a largo plazo): retención a largo plazo (~anual). Mínimo de 365 días; tarifas de recuperación más altas.
- Autoclass puede realizar transiciones automáticas entre clases; verifique que las tarifas por eliminación anticipada y los patrones de acceso no reduzcan los ahorros.
Ubicaciones y replicación de buckets
- Región: ideal para la localidad de los datos y el cumplimiento normativo dentro de una única geografía.
- Doble región: dos regiones emparejadas con replicación automática; la replicación turbo confirma las réplicas rápidamente con un RPO medido en minutos; ideal para recuperación ante desastres (DR) con bajo RPO.
- Multirregión: distribuida geográficamente dentro de un continente para una amplia disponibilidad, distribución de contenido y análisis que abarcan un área extensa.
- Elija las ubicaciones para cumplir con las leyes de residencia de datos y para minimizar el egreso/latencia hacia los servicios de cómputo (Dataproc, Dataflow, tablas externas de BigQuery).
Consistencia y semántica
- Cloud Storage proporciona una consistencia global sólida de lectura tras escritura, lectura tras actualización de metadatos y listado tras escritura.
- Las escrituras de objetos son atómicas e inmutables; «renombrar» es un patrón de copiar y eliminar. Diseñe para copias idempotentes y verifique las sumas de comprobación (checksums) para evitar migraciones parciales.
Patrones de acceso y rendimiento
- Las cargas compuestas en paralelo y las cargas reanudables mejoran el rendimiento para archivos grandes.
- Las lecturas de rango (range reads) permiten pies de página columnares eficientes y lecturas selectivas.
- Evite tener muchos archivos pequeños (<8 MB) que inflan la sobrecarga de metadatos/listado; agrúpelos o compáctelos en objetos más grandes.
- GZIP no es divisible (splittable) para lecturas distribuidas; prefiera Parquet/ORC/Avro+Snappy para un procesamiento escalable.
Ciclo de vida, retención y control de versiones
- Las políticas de retención a nivel de bucket y las retenciones de objetos (basadas en eventos o temporales) garantizan la inmutabilidad para el cumplimiento normativo y para reducir eliminaciones accidentales.
- El control de versiones de objetos conserva las generaciones anteriores; es útil para la recuperación de sobrescrituras/eliminaciones. Supervise el crecimiento del costo de almacenamiento.
- Las reglas de ciclo de vida automatizan las transiciones y eliminaciones. Ejemplo (JSON) para mover datos más antiguos a clases más frías y eliminarlos después de un año: { “rule”: [ {“action”: {“type”: “SetStorageClass”, “storageClass”: “COLDLINE”}, “condition”: {“age”: 30}}, {“action”: {“type”: “Delete”}, “condition”: {“age”: 365}} ] }
- Modos de fallo: cargos por eliminación anticipada si realiza la transición de forma demasiado agresiva; los bloqueos de retención no se pueden acortar; el control de versiones sin compactación puede aumentar los costos.
Transferencias y migración
- Use Storage Transfer Service para traslados paralelizados y con puntos de control desde entornos locales (on-prem) u otras nubes; Transfer Appliance para petabytes sin conexión.
- Valide la integridad con CRC32C/MD5 y precondiciones de coincidencia de generación para evitar condiciones de carrera (race conditions).
- Prefiera gsutil/gcloud storage con -m (paralelo) y sumas de comprobación; evite los cuellos de botella de SFTP para la ingesta de alto volumen.

Gobernanza unificada del lago de datos con BigLake y Dataplex

BigLake y Dataplex estandarizan la seguridad y la gobernanza en archivos y tablas.

BigLake
- Expone los datos de Cloud Storage como tablas gestionadas por BigQuery (externas) con controles de acceso detallados y uniformes, incluyendo políticas de acceso a nivel de fila y etiquetas de políticas a nivel de columna.
- Habilita la poda de columnas (column pruning) y el empuje de predicados (predicate pushdown) para Parquet/ORC, reduciendo los bytes escaneados y el egreso hacia motores como BigQuery, Spark en Dataproc y Dataflow.
- Centraliza la auditoría a través de Cloud Logging y la aplicación de políticas centralizadas; un único plano de control para los archivos del lago de datos y las tablas del data warehouse.
Dataplex
- Organiza los datos en lagos, zonas (sin procesar, curada, de confianza) y activos (buckets, conjuntos de datos); gestiona metadatos, linaje y reglas de calidad de datos.
- Se integra con etiquetas de políticas para columnas sensibles y admite el principio de privilegio mínimo a través de IAM en los ámbitos de lago/zona/activo.
- Fomenta la estandarización de nombres, particiones y gestión de esquemas en entornos de múltiples equipos para evitar los «cajones de sastre».
Patrones de gobernanza
- Implemente patrones de un conjunto de datos por inquilino (dataset-per-tenant) y un bucket por zona; evite la fuga de datos entre inquilinos.
- Use políticas de acceso a nivel de fila y etiquetas de políticas de columna para la PII (información de identificación personal). Restrinja el acceso a la API a identidades aprobadas.
- Audite el acceso con Cloud Logging; dirija los registros filtrados a Pub/Sub para una supervisión en tiempo real.

Formatos de archivo, compresión y comportamiento de las consultas

Elegir el formato correcto tiene efectos de primer orden en el costo y el rendimiento.

Formatos columnares (Parquet, ORC)
- Fortalezas: poda de columnas (column pruning), empuje de predicados (predicate pushdown), codificación y compresión por columna, estadísticas y archivos divisibles (splittable).
- Desventajas: mayor uso de CPU en el tiempo de escritura; la evolución del esquema debe gestionarse con cuidado (p. ej., AÑADIR columnas es seguro; los cambios de tipo son arriesgados).
- Compresión: Snappy para velocidad, ZSTD para mejores ratios de compresión donde sea compatible. Evita GZIP para formatos columnares a menos que lo requieran restricciones de interoperabilidad.
Avro, orientado a filas
- Fortalezas: evolución del esquema con tipado fuerte, compresión a nivel de bloque, divisible (splittable); excelente para zonas de aterrizaje (landing zones) de streaming e intercambio de datos.
- Desventajas: menos eficiente para el escaneo en analítica que los formatos columnares; convertir a Parquet/ORC en zonas curadas (curated zones).
CSV y JSON (semiestructurados)
- CSV: legible por humanos, la sobrecarga más pequeña cuando los valores son simples; carece de esquema, tipos y consistencia en los caracteres de escape; costoso de analizar a escala.
- JSON: autodescriptivo y flexible; se requiere JSON delimitado por nueva línea para lecturas distribuidas escalables; verboso y de alto consumo de CPU para analizar.
- Donde sea posible, aterriza los datos en CSV/JSON crudos, luego valida y convierte a Avro/Parquet para la analítica.
Tablas externas de BigQuery y BigLake
- Las tablas externas en Parquet/ORC se benefician del pushdown y la poda de columnas; las de CSV/JSON generalmente no, lo que lleva a un mayor número de bytes escaneados.
- Las tablas externas de CSV comprimido (GZIP) no se pueden dividir entre workers; espera lecturas más lentas.
- Ejemplo: creación de una tabla BigLake en formato Parquet con particiones estilo Hive: CREATE EXTERNAL TABLE lake.sales WITH CONNECTION us.biglake_conn OPTIONS ( format = ‘PARQUET’, hive_partitioning_mode = ‘AUTO’, hive_partitioning_source_uri_prefix = ‘gs://corp-raw/sales/’, uris = [‘gs://corp-raw/sales/date=/region=/part-*.parquet’] );

Disposición, particionamiento, ingeniería de rendimiento, residencia y migración

Disposición y particionamiento de objetos
- Adopta rutas estilo Hive para particiones y claves de clúster: gs://bucket/dataset/table/date=YYYY-MM-DD/hour=HH/region=us/part-00001.parquet
- Mantén los tamaños de archivo individuales en el rango de 128 a 1024 MB para un paralelismo equilibrado y una sobrecarga de tareas. Evita tener millones de archivos por partición.
- Mitiga los problemas de archivos pequeños mediante:
  - La agrupación de cargas en el lado del cliente.
  - El uso de trabajos de compactación de Dataflow/Spark para fusionar archivos pequeños fuera de las horas pico.
  - El archivado de los archivos pequeños originales y la exposición únicamente de los datos compactados a la analítica.
Particionamiento y agrupamiento en clústeres de BigQuery
- Particiona por tiempo de ingesta o por una columna de filtro de alta cardinalidad (p. ej., event_date). Evita el sobreparticionamiento (p. ej., por minuto) que dispara el tamaño de los metadatos.
- Agrupa en clústeres por dimensiones comúnmente filtradas u ordenadas (hasta cuatro). La agrupación en clústeres aumenta la localidad de los datos y reduce los bytes escaneados.
- Prefiere las tablas nativas de BigQuery para analítica interactiva pesada; usa BigLake/externas para el acceso gobernado al lago de datos, el uso compartido entre motores y el aislamiento de costos.
Implicaciones en el rendimiento de las consultas
- Los formatos columnares reducen materialmente los costos de escaneo externo; las tablas externas CSV/JSON a menudo requieren escaneos de archivos completos.
- Las garantías de consistencia eliminan la necesidad de retrasos artificiales en las lecturas de Cloud Storage, pero los sistemas posteriores (p. ej., inserciones por streaming en BigQuery) pueden exhibir un breve retraso en la visibilidad de los datos; diseña con marcas de agua (watermarks) o retrasos de lectura donde sea necesario.
Residencia, durabilidad y recuperación
- Selecciona las ubicaciones de los buckets/conjuntos de datos para cumplir con las restricciones de residencia de datos; coubica el cómputo para reducir el egreso y la latencia.
- Usa una doble región con replicación turbo para un RPO bajo; versionamiento más políticas de retención para la recuperabilidad frente a errores humanos y ransomware.
- Para la recuperación ante desastres (DR), replica los buckets a un proyecto/región separado usando la replicación de buckets y protégelos con límites de IAM separados.
Migración y validación seguras
- Planifica en múltiples fases: siembra (transferencia masiva), sincronización incremental (copia por mtime/ventana de tiempo), transición (fuente en modo de solo lectura) y validación posterior a la transición.
- Valida con sumas de verificación (checksums), recuentos, totales de bytes y decodificación de muestras. Para datos tabulares, compara recuentos de filas y agregados de hash: SELECT COUNT(*) c, ANY_VALUE(FARM_FINGERPRINT(TO_JSON_STRING(t))) h FROM proj.dst.dataset.table t;
- Usa precondiciones (ifGenerationMatch) para evitar sobrescrituras durante la copia en paralelo. Mantén una ventana de reversión (rollback) con versionamiento o conservando la fuente.
- Después de la migración, habilita el ciclo de vida y Autoclass según el nuevo perfil de acceso; evita habilitar el bloqueo de retención (retention lock) hasta que las validaciones se completen.

Escenario de un problema práctico

Acme Retail recibe entregas diarias de archivos CSV de un socio logístico en un bucket regional de Cloud Storage. Ocasionalmente, los archivos contienen filas con formato incorrecto. Acme debe recibir, validar, convertir a un formato listo para analítica y cargar en BigQuery para paneles de control casi en tiempo real, mientras conserva las filas erróneas para su inspección y aplica la gobernanza.

Enfoque:

Recibir y gobernar datos crudos en Dataplex
- Crear un lago de datos (lake) en Dataplex con un activo de zona cruda (raw zone) mapeado a gs://acme-raw/logistics/.
- Justificación: Gobernanza, metadatos y linaje de datos centralizados. Aplicar IAM a nivel de zona y etiquetar los campos sensibles con etiquetas de política (policy tags) para su aplicación en sistemas posteriores.
Aplicar ciclo de vida y retención
- Aplicar una política de retención de 30 días al bucket y habilitar el versionamiento de objetos en acme-raw.
- Justificación: Protege contra sobrescrituras/eliminaciones accidentales por parte del socio; una retención corta equilibra el costo y la recuperabilidad. El versionamiento facilita la reversión de entregas defectuosas.
Validar e ingerir con una canalización (pipeline) de lotes de Dataflow
- Disparar un trabajo diario de Dataflow mediante notificaciones de finalización de objeto. Leer el CSV con un esquema y validación por registro; escribir los registros válidos en un área de preparación (staging) de BigQuery (particionada por event_date) y enrutar los errores de análisis/validación a una tabla de BigQuery de mensajes fallidos (dead-letter).
- Justificación: Dataflow proporciona un análisis paralelo escalable y un manejo robusto de mensajes fallidos para que los analistas puedan inspeccionar las filas erróneas. Esto refleja las mejores prácticas para calidades heterogéneas de CSV.
Compactar y convertir a Parquet en una zona curada
- La misma canalización escribe los datos validados en gs://acme-curated/logistics/date=YYYY-MM-DD/ como archivos Parquet con un tamaño de ~256–512 MB.
- Justificación: Parquet permite la poda de columnas (column pruning) y el empuje de predicados (predicate pushdown) en BigQuery y Spark, reduciendo los bytes escaneados y mejorando la latencia; la compactación mitiga la sobrecarga de los archivos pequeños proveniente del patrón de entrega del socio.
Exponer analítica gobernada a través de BigLake
- Crear una tabla externa de BigLake sobre la ruta de Parquet curada con auto-particionamiento de Hive; aplicar etiquetas de política a nivel de columna y políticas de acceso a nivel de fila para filtros específicos del socio.
- Justificación: Acceso uniforme y de grano fino a través de BigQuery y Spark con auditoría centralizada. La poda de particiones (partition pruning) reduce los costos de escaneo en los filtros de fecha.
Cargar agregados críticos a BigQuery nativo
- Para paneles de control de alta demanda (hot), ejecutar un trabajo programado de BigQuery que ingiera los últimos N días desde la tabla externa de Parquet curada a una tabla nativa particionada y en clúster.
- Justificación: El almacenamiento nativo acelera la BI de alta concurrencia, mientras que la tabla externa de BigLake permanece como el sistema de registro gobernado para un acceso más amplio.
Monitorear y alertar con Cloud Logging y Pub/Sub
- Crear un receptor de registros (log sink) que filtre los resultados de los trabajos de carga de Dataflow y BigQuery hacia Pub/Sub; integrarlo con la herramienta de monitoreo para alertas instantáneas sobre fallos o tasas elevadas de filas erróneas.
- Justificación: Visibilidad operativa dirigida y específica de la tabla sin sondeo (polling); apoya las prácticas de SRE.
Optimizar la clase de almacenamiento y la residencia de datos
- Mantener el Parquet curado en Standard durante 14 días, transferirlo a Coldline después de 30 días mediante una regla de ciclo de vida; almacenar los buckets crudos y curados en la misma región que los conjuntos de datos de BigQuery para evitar el egreso.
- Justificación: Equilibra el rendimiento de lectura frecuente (hot) con el costo. La coubicación mantiene el cumplimiento y minimiza la latencia y las tarifas de egreso.
Validar la calidad de extremo a extremo
- Después de cada ejecución, comparar recuentos y agregados de hash entre las tablas de preparación (staging), externa curada y nativa de BigQuery; poner en cuarentena las anomalías.
- Justificación: Detección temprana de derivas de esquema o regresiones en la ingesta; los hashes criptográficos o de huella digital (fingerprint) proporcionan una garantía ligera sin necesidad de re-escaneos completos.

Este diseño proporciona una ingesta resiliente con análisis de mensajes fallidos, Parquet listo para analítica para consultas eficientes, gobernanza centralizada a través de Dataplex y BigLake, y políticas de ciclo de vida optimizadas en costos, todo mientras se adhiere al acceso de mínimo privilegio y a operaciones auditables.

← Arquitectura y Diseño de Ingeniería de Datos · Todos los dominios · Analítica de BigQuery e Ingeniería de Almacenes de Datos →

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