Google PDE: Analítica de BigQuery e Ingeniería de Almacenes 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

BigQuery es un almacén de análisis de datos MPP (procesamiento masivamente paralelo), columnar y sin servidor que separa el almacenamiento del cómputo, proporcionando escalabilidad casi infinita, SQL ANSI y gobernanza integrada. La ingeniería del almacén de datos en BigQuery equilibra el diseño de esquemas (particionamiento, clustering, desnormalización vs. normalización, registros anidados), los patrones de ingesta (cargas por lotes, streaming, Storage Write API) y la gestión de cargas de trabajo (ediciones bajo demanda vs. basadas en capacidad y reservaciones). Una seguridad robusta (vistas autorizadas, políticas de fila/columna, etiquetas de política) coexiste con controles de costos y herramientas de rendimiento para minimizar los bytes escaneados y reducir la latencia. Esta sección cubre el diseño central, las operaciones y los modos de fallo que debes anticipar en producción.

Almacenamiento y semántica: Conjuntos de datos, tablas, vistas y acceso al lago de datos

• Conjuntos de datos, tablas, vistas:

  • Los conjuntos de datos definen el alcance de IAM y la gobernanza. Mantén conjuntos de datos por inquilino para el aislamiento y la claridad en la facturación.
  • Las tablas estándar almacenan datos de forma nativa; las particiones y el clustering rigen el diseño y la poda (pruning).
  • Las vistas encapsulan la lógica SQL sin almacenar datos. Las vistas autorizadas permiten al propietario de una vista exponer subconjuntos restringidos a otros proyectos o inquilinos mientras oculta las tablas subyacentes.
  • Las vistas materializadas (MVs) persisten resultados precalculados y se actualizan automáticamente. La reescritura de consultas (query rewrite) utiliza las MVs de forma transparente cuando son compatibles; los predicados o funciones incompatibles las omiten.
  • Las tablas externas hacen referencia a datos en Cloud Storage, Google Drive o Google Sheets. Evitan la ingesta, pero sacrifican rendimiento (throughput) y soporte de funciones a cambio de conveniencia. Para análisis repetidos, ingiere los datos en tablas nativas.

• Particionamiento, clustering y registros anidados:

  • Particiona por tiempo de ingesta, DATE/TIMESTAMP/DATETIME o rango de enteros para podar (prune) los escaneos. Usa filtros WHERE en la columna de partición o decoradores como _PARTITIONDATE para habilitar la poda.
  • Realiza clustering en columnas de alta cardinalidad, filtradas o unidas con frecuencia (hasta 8). BigQuery realiza el reclustering automáticamente; operaciones DML pequeñas y repetidas pueden degradar temporalmente la calidad del clustering.
  • Los registros anidados y repetidos (STRUCT, ARRAY) modelan relaciones de uno a muchos sin la sobrecarga de los joins. Usa UNNEST con prudencia; un UNNEST repetido en arrays grandes puede provocar una expansión dramática (fan out).

• Desnormalización vs. normalización:

  • Desnormaliza los atributos de las dimensiones en las tablas de hechos para minimizar los joins y aprovechar los escaneos columnares; esto es ideal para análisis de lectura intensiva.
  • Normaliza cuando la amplificación de escritura, los puntos calientes (hotspots) de actualización o los self-joins causan contención o complejidad (por ejemplo, separando las tablas maestras de pacientes y de visitas para evitar explosiones por self-joins). Considera un híbrido: entidades centrales normalizadas con tablas de hechos anchas y desnormalizadas o hijos anidados.

• Vistas materializadas: consideraciones de diseño

  • Ideales para agregados estables e incrementales sobre tablas base particionadas. La actualización de las MV es asíncrona; los usuarios posteriores deben tolerar ventanas de obsolescencia (staleness) o consultar las tablas base como alternativa.
  • Filtra y agrupa por la columna de partición para una actualización incremental. Funciones no deterministas, joins no soportados o UDFs pueden descalificar a las MVs para la reescritura de consultas.

• Consultas federadas, BigLake y empuje de predicados (pushdown):

  • Las consultas federadas leen sistemas externos (por ejemplo, Cloud SQL) directamente con SQL. Son convenientes para joins ligeros o exploraciones puntuales, pero tienen mayor latencia y cuotas más estrictas; extrae los datos a BigQuery para análisis intensivos.
  • Las tablas de BigLake unifican la gobernanza del lago de datos (lake) y del almacén (warehouse) con controles a nivel de columna y fila sobre datos en Cloud Storage o formatos de tabla abiertos (como Parquet). El empuje de predicados (predicate pushdown) y de proyecciones (projection pushdown) reduce los bytes descargados; los escaneos grandes aún favorecen la ingesta en tablas nativas para un rendimiento máximo.

• Tablas con comodines y fragmentos heredados:

  • Las consultas con comodines (wildcard) son un patrón heredado para tablas fragmentadas (sharded) por fecha. Prefiere el particionamiento nativo, pero cuando sea necesario:

undefined

.

Optimización de Consultas y Gestión de la Carga de Trabajo

• Poda de particiones y clustering:

  • Filtra siempre por la columna de partición para evitar escanear particiones frías. Usa BETWEEN con ventanas estrechas.
  • Ordena las claves de clustering por selectividad; las claves iniciales deben coincidir con los filtros y joins frecuentes. Evita el clustering en columnas con una cardinalidad muy baja.

• Optimización del plan de consulta:

  • Usa EXPLAIN y los detalles de ejecución para encontrar joins sesgados, shuffles grandes o escaneos no podados.
  • Reduce las columnas de forma temprana con listas SELECT y subconsultas; BigQuery es columnar y descarta las columnas no utilizadas de manera eficiente.
  • Prefiere las agregaciones aproximadas (por ejemplo, APPROX_QUANTILES) para equilibrar velocidad y coste en grandes volúmenes de datos.
  • Aplica la deduplicación con funciones de ventana cuando las fuentes de ingesta puedan repetir eventos:
    • SELECT * EXCEPT(rn) FROM (SELECT t.*, ROW_NUMBER() OVER (PARTITION BY unique_id ORDER BY event_ts DESC) rn FROM my_table t) WHERE rn = 1;

• Joins y desnormalización:

  • Co-ubica las claves de join como claves de clúster para reducir el shuffle. Los filtros de Bloom o la preagregación pueden ayudar con sesgos extremos.
  • Desnormaliza las dimensiones pequeñas y de cambio lento en las tablas de hechos para evitar joins intensivos. Para dimensiones muy anchas con actualizaciones frecuentes, normaliza y apóyate en las claves de clúster y los joins materializados.

• Gestión de la carga de trabajo, slots, ediciones y autoescalado:

  • Bajo demanda (On-demand): BigQuery escala el cómputo elásticamente por consulta; pagas por TB escaneado. Controla el coste con el máximo de bytes facturados y la poda de particiones.
  • Basado en capacidad con las ediciones de BigQuery (Standard, Enterprise, Enterprise Plus) utiliza reservas de slots. Compra compromisos base, crea reservas y asigna proyectos o carpetas. El autoescalado puede añadir slots durante los picos y liberarlos cuando la demanda baja; usa reservas separadas para ETL y BI para evitar interferencias.
  • Prioridad de trabajos: interactiva (por defecto) para baja latencia; por lotes (batch) para backfills y consultas programadas. Los trabajos por lotes se encolan hasta que haya capacidad inactiva disponible en la reserva o en el servicio, y luego se ejecutan al coste normal.

• Concurrencia y cuotas:

  • Usa reservas y asignaciones para aislar las cargas de trabajo críticas. Para entornos con múltiples inquilinos (multi-tenant), colócalos en reservas o proyectos distintos con límites de concurrencia personalizados.
  • Etiqueta los trabajos para la atribución; monitoriza INFORMATION_SCHEMA.JOBS y las métricas de Cloud Monitoring para ver la utilización de slots y los retrasos por encolamiento.

• Caché de BI y frescura de los datos:

  • La caché de resultados de consulta mejora la latencia y el coste para consultas idénticas; desactívala en clientes que necesiten una frescura de datos inferior a una hora. Algunas herramientas de BI almacenan datos en caché de forma independiente: desactiva la caché de informes para mostrar los resultados más recientes.

Ingesta, Federación y Recuperación

• Trabajos de carga:

  • Las cargas por lotes desde Cloud Storage (preferiblemente Avro/Parquet) son fiables y rentables. Establece el esquema y la codificación explícitamente; las codificaciones de CSV no coincidentes son una causa común de discrepancias byte por byte.
  • Usa decoradores de partición o carga en tablas particionadas para evitar operaciones de merge. Para cargas grandes, paraleliza por partición.

• Ingesta en streaming y la Storage Write API:

  • Las inserciones en streaming heredadas (legacy) son simples pero tienen cuotas más estrictas y pueden presentar consistencia eventual durante unos segundos; el time travel sobre datos muy recientes puede tener retrasos.
  • La Storage Write API es la ruta recomendada para escrituras de alto rendimiento y baja latencia con mejores controles de deduplicación. Usa la idempotencia (offsets del stream) para evitar duplicados.
  • El diseño de la aplicación debe tolerar eventos en tránsito: retrasa las consultas interactivas según la disponibilidad esperada (por ejemplo, 2× la latencia observada) o usa marcas de agua (watermarks) en las particiones por tiempo de ingesta.

• Dataflow y diseño de colas de mensajes fallidos (dead-letter):

  • Para CSVs entregados por socios con filas mal formadas, usa Dataflow para analizar y validar, escribir los registros válidos en BigQuery a través de la Storage Write API y enrutar los errores a una tabla de mensajes fallidos (dead-letter) para su inspección.
  • Al leer desde BigQuery a escala, prefiere las lecturas basadas en consultas (fromQuery) para seleccionar solo los campos necesarios y reducir el shuffle.

• Consultas programadas y transformaciones:

  • Usa consultas programadas para transformaciones ELT, rollups incrementales y mantenimiento de tablas. Prefiere escribir en destinos particionados y en clúster. Las consultas programadas tienen por defecto prioridad de lote (batch) y se integran con las reservas.

• Notificaciones y observabilidad:

  • Exporta los registros de auditoría de BigQuery con un receptor de registros (log sink) a Pub/Sub para activar alertas sobre trabajos de inserción en tablas específicas:
    • Ejemplo de filtro: resource.type=“bigquery_resource” AND protoPayload.methodName=“jobservice.jobCompleted” AND jsonPayload.jobChange.job.jobConfiguration.load.destinationTable.tableId=“target_table”
  • Usa los registros de auditoría de Cloud Logging y las vistas de INFORMATION_SCHEMA para descubrir patrones de uso y aplicar la gobernanza.

• Time travel, snapshots y clones:

  • Time travel te permite consultar una tabla en un momento anterior (por defecto, 7 días). Usa FOR SYSTEM_TIME AS OF para leer estados pasados.
  • Los snapshots de tabla capturan una vista en un punto en el tiempo con copia en escritura (copy-on-write); úsalos para backfills consistentes o para recuperación. Los clones de tabla proporcionan copias de metadatos casi instantáneas para desarrollo o análisis hipotéticos (what-if) con un almacenamiento mínimo hasta que divergen.
  • Opciones de recuperación:
    • Errores pequeños: consulta usando time travel y restaura con INSERT…SELECT.
    • Restauración grande: crea a partir de un snapshot o un clon, y luego intercámbialos.
  • Establece la expiración de tablas y particiones para aplicar la retención; verifica que la retención se alinee con las necesidades de time travel.

• Fuentes federadas:

  • Usa la federación con Cloud SQL para joins ligeros; para análisis sostenidos o escaneos grandes, programa la extracción y carga (extract-load) en tablas nativas.
  • Las tablas de BigLake sobre Parquet/ORC en Cloud Storage pueden aplicar etiquetas de políticas (policy tags) y delegar filtros (push down) y proyecciones de columnas; aun así, espera una latencia mayor que con el almacenamiento nativo.

Seguridad, Gobernanza y Control de Costos

• IAM y privilegio mínimo:

  • Otorga roles a nivel de conjunto de datos mínimamente (BigQuery Data Viewer, Data Editor) solo a usuarios aprobados; restringe el acceso a la API a cuentas de servicio y grupos seleccionados.
  • Separa clientes y entornos por conjunto de datos y proyecto para lograr aislamiento. Asigna reservas por proyecto o carpeta para evitar vecinos ruidosos.

• Vistas autorizadas y seguridad a nivel de fila:

  • Las vistas autorizadas exponen solo columnas/filas seleccionadas a proyectos externos mientras que el proyecto de la vista retiene el acceso a la tabla. Mantén la vista y la fuente en el mismo conjunto de datos o usa autorización a nivel de conjunto de datos para el proyecto de destino.
  • La seguridad a nivel de fila con políticas de acceso a filas filtra las filas por usuario o grupo en el momento de la consulta; combínala con vistas autorizadas para un control por capas.

• Seguridad a nivel de columna y etiquetas de política:

  • Usa etiquetas de política de Data Catalog para proteger columnas sensibles y habilitar el enmascaramiento de datos. Asigna acceso a las etiquetas (no a las tablas) para alinearlo con la clasificación de datos. Para el acceso de socios, enmascara o deniega columnas con PII mediante etiquetas.

• BigQuery ML y análisis dentro del almacén de datos:

  • Entrena y sirve modelos directamente en BigQuery (por ejemplo, regresión lineal/logística, XGBoost, K-means, series temporales) con CREATE MODEL y ML.PREDICT. Almacena las características en tablas particionadas y utiliza reentrenamiento programado.
  • Los modelos remotos te permiten invocar Vertex AI o endpoints externos desde SQL para realizar puntuaciones dentro de una gobernanza federada. Almacena en caché las salidas en tablas para amortizar la latencia en consultas repetidas.

• Controles de costos y solución de problemas de rendimiento:

  • Reduce los bytes escaneados:
    • Particiona y clusteriza; filtra siempre por estas claves.
    • Usa SELECT solo para las columnas necesarias; evita SELECT *.
    • Usa vistas materializadas y almacenamiento en caché de resultados cuando sea aplicable.
    • Establece maximum_bytes_billed para limitar el costo.
  • Soluciona problemas de rendimiento:
    • Inspecciona los detalles de ejecución del trabajo en busca de sesgos, particiones no podadas o puntos calientes de shuffle. Reasigna las claves de los joins o pre-agrega para reducir el shuffle.
    • Valida las reescrituras de MV; asegúrate de que los predicados y las funciones deterministas sean compatibles.
    • Para paneles a los que les faltan datos de streaming recientes, ten en cuenta el retraso de consistencia o deshabilita el almacenamiento en caché del lado del cliente.
  • Visibilidad de la gobernanza: audita con Cloud Logging, INFORMATION_SCHEMA y etiquetas de trabajo detalladas para imputar costos e identificar valores atípicos.

Escenario de un Problema Práctico

NovaCare Health opera una plataforma regional de telemedicina. Un diseño de tabla única, patient_and_visit, sirvió para un piloto, pero a una escala 100 veces mayor, los informes agotan el tiempo de espera, aparecen duplicados por los upserts de streaming y los socios requieren un aislamiento de datos estricto.

Enfoque:

1. Rediseñar el esquema y la disposición

   • Crear tablas principales normalizadas: patients(patient_id, demographics, updated_at) y visits(visit_id, patient_id, visit_ts, metrics, updated_at).
   • Convertir visits en una tabla particionada por DATE(visit_ts), clusterizada por patient_id y visit_id. Mantener las dimensiones de referencia pequeñas desnormalizadas dentro de visits para acelerar los paneles.
   • Justificación: La normalización evita self-joins costosos y actualizaciones pesadas de filas en una única tabla activa (hot table). La partición poda los escaneos históricos; la clusterización coubica los joins y filtros en patient_id, reduciendo el shuffle.

2. Ingerir con la Storage Write API y forzar la idempotencia

   • Usar una canalización de Dataflow para analizar eventos entrantes, validarlos y escribirlos en flujos con nombre en la Storage Write API con offsets idempotentes.
   • Dirigir los eventos malformados a una tabla de mensajes fallidos (dead-letter) en BigQuery para su clasificación.
   • Justificación: La Storage Write API ofrece mayor rendimiento, menor latencia y mejores garantías de deduplicación que el streaming heredado. El mecanismo de dead-lettering preserva la visibilidad sobre los problemas de calidad de los datos de los socios.

3. Diseñar para la actualidad y la deduplicación en las consultas

   • Para análisis interactivos, añade un watermark corto (por ejemplo, 2 veces la disponibilidad observada) antes de consultar la partición más reciente; o filtra por _PARTITIONDATE donde partition_date <= CURRENT_DATE() para excluir filas en tránsito.
   • Usa ROW_NUMBER() OVER (PARTITION BY visit_id ORDER BY event_ts DESC) = 1 en vistas que deban tolerar reintentos en el origen.
   • Justificación: El streaming es eventualmente consistente durante un breve intervalo. El uso de watermarks y la deduplicación basada en ventanas protegen los paneles de brechas y duplicados transitorios.

4. Acelerar agregados comunes con vistas materializadas

   • Crear MVs alineadas con la partición sobre visits para KPIs diarios agrupados por DATE(visit_ts) y cohortes de pacientes. Asegurarse de que los predicados sean compatibles con la reescritura.
   • Justificación: Las MVs reducen la latencia y los bytes escaneados para informes recurrentes; BigQuery reescribe las consultas para usar la MV de forma transparente.

5. Forzar el aislamiento de tenants y la seguridad detallada

   • Ubicar a cada socio en un conjunto de datos dedicado. Otorgar roles de conjunto de datos con privilegio mínimo a los grupos de socios.
   • Publicar vistas autorizadas para benchmarks compartidos entre socios sin revelar las tablas sin procesar.
   • Aplicar etiquetas de política a las columnas con PII y añadir políticas de acceso a filas a visits para restringir el acceso por partner_id para análisis internos multi-tenant.
   • Justificación: La segmentación por conjunto de datos por tenant, junto con las vistas autorizadas y las etiquetas de política, impone el privilegio mínimo al tiempo que permite el uso compartido curado.

6. Gestionar cargas de trabajo con ediciones, reservas y autoescalado

   • Adquirir capacidad en las ediciones de BigQuery y crear dos reservas: etl (receptores de Dataflow, transformaciones programadas) y bi (ad hoc/informes). Asignar los proyectos correspondientemente y habilitar el autoescalado para absorber los picos.
   • Programar consultas ELT como lote con SLAs claros; establecer maximum_bytes_billed para proyectos interactivos.
   • Justificación: Las reservas separadas evitan que el ETL consuma los recursos del BI. El autoescalado se adapta a las cargas en ráfagas sin sobreaprovisionar.

7. Gobernar el costo y observar el uso

   • Requerir filtros en visit_ts; rechazar SELECT * en las vistas compartidas. Usar INFORMATION_SCHEMA.JOBS para detectar escaneos no podados y joins desequilibrados.
   • Exportar los registros de auditoría de BigQuery a Pub/Sub con un receptor de registros filtrado para trabajos de inserción en visits para activar alertas de monitoreo ante aumentos inesperados.
   • Justificación: La poda de bytes y la proyección de columnas controlan el costo; los registros de auditoría revelan patrones de acceso y anomalías casi en tiempo real.

8. Planificar la recuperación y los backfills

   • Habilitar políticas de vencimiento de tablas predeterminadas que se alineen con el cumplimiento y las necesidades de viaje en el tiempo (time-travel). Para ediciones grandes, crear un snapshot, ejecutar los cambios y revertir rápidamente si es necesario. Usar clones de tabla para análisis de hipótesis (what-if) de desarrollo/prueba sin duplicar el almacenamiento.
   • Justificación: Los snapshots y los clones proporcionan redes de seguridad rápidas y eficientes en espacio; el viaje en el tiempo (time-travel) cubre pequeñas restauraciones correctivas.

9. Integrar ML dentro del almacén de datos

   • Almacenar engineered features en tablas particionadas y entrenar modelos de clasificación de BigQuery ML para el riesgo de readmisión. Para modelos externos alojados en Vertex AI, crear modelos remotos y almacenar en caché las predicciones en una tabla clusterizada para joins de baja latencia.
   • Justificación: Mantener el ML cerca de los datos reduce el movimiento y la complejidad de la gobernanza; almacenar en caché la inferencia remota amortiza la latencia y el costo.

Con este diseño, NovaCare logra un rendimiento predecible bajo una carga 100 veces mayor, un fuerte aislamiento de tenants y costos gobernados, al tiempo que preserva análisis de baja latencia y una recuperación reproducible.

← Almacenamiento de Datos · Todos los dominios · Procesamiento de Flujos con Dataflow y Apache Beam →

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

Explorar Google →