Guía

Datos continuos y de alto volumen requieren análisis a los pocos minutos de su llegada.

→Pub/Sub para la ingesta -> Dataflow (streaming) para la transformación -> BigQuery con inserciones de streaming o Storage Write API para el análisis.

Por qué: Este es el patrón de streaming serverless y autoescalable canónico. El procesamiento por lotes (p. ej., Dataproc) no cumpliría los requisitos de baja latencia.

La pipeline de datos debe manejar picos de tráfico impredecibles (p. ej., 10 veces el volumen estacional) manteniendo una baja latencia.

→Utilice servicios totalmente gestionados y autoescalables: Pub/Sub para la ingesta, Dataflow con autoescalado habilitado y BigQuery para el almacenamiento.

Por qué: Los servicios gestionados escalan automáticamente los recursos para igualar la carga, evitando costos de sobreaprovisionamiento y asegurando el rendimiento bajo picos de tráfico.

Migrar un gran data warehouse de Hadoop/Hive en las instalaciones a Google Cloud.

→Migrar datos a Cloud Storage, luego cargarlos en BigQuery. Reemplazar Hive/Spark SQL con BigQuery para análisis serverless. Usar Dataproc para trabajos Spark que no se traducen fácilmente a SQL.

Por qué: BigQuery proporciona un reemplazo serverless y de alto rendimiento para los data warehouses de Hadoop, reduciendo la sobrecarga operativa.

Una pipeline de streaming requiere que los mensajes se procesen exactamente una vez y en orden para cada entidad (p. ej., por símbolo bursátil).

→Publicar mensajes en Pub/Sub con una clave de ordenamiento. Procesar con una pipeline de streaming de Dataflow, que garantiza el procesamiento en orden para una clave dada.

Por qué: Las claves de ordenamiento de Pub/Sub combinadas con Dataflow proporcionan procesamiento gestionado, escalable, ordenado y exactamente una vez sin gestión manual de estados.

Referencia↗

Construir un data lake flexible y escalable para soportar cargas de trabajo tanto por lotes como de streaming con gobernanza de datos.

→Utilizar Cloud Storage como capa de almacenamiento. Usar Dataflow para el procesamiento por lotes y de streaming. Usar Dataplex con Data Catalog para la gestión de metadatos, descubrimiento y gobernanza.

Por qué: Esta arquitectura desacopla el almacenamiento y la computación, permitiendo el uso de múltiples motores de procesamiento (Dataflow, Dataproc) en un almacén de datos central con gobernanza unificada.

Una pipeline que procesa datos sensibles (p. ej., PHI, PII) debe cumplir con regulaciones como HIPAA o GDPR.

→Habilitar Cloud Audit Logs para todo el acceso a datos. Implementar VPC Service Controls para crear un perímetro de seguridad que impida la exfiltración de datos.

Por qué: El registro de auditoría es crítico para rastrear el acceso a datos para el cumplimiento. VPC Service Controls proporciona una fuerte defensa contra la exfiltración de datos, un requisito clave para datos sensibles.

Una arquitectura lambda con capas separadas de lotes y velocidad necesita presentar una vista unificada de los datos.

→Usar BigQuery para la capa de servicio. Usar una declaración `MERGE` para actualizar/insertar datos procesados por lotes en una tabla maestra, sobrescribiendo los datos de streaming para el mismo período. Exponer una vista que `UNION`e datos históricos por lotes con datos de streaming en tiempo real para el período actual.

Por qué: Este patrón proporciona vistas en tiempo real de baja latencia y precisión histórica corregida por lotes sin requerir lógica de reconciliación del lado del cliente.

Implementar una arquitectura de data mesh descentralizada donde los dominios son propietarios de sus productos de datos.

→Usar Dataplex para la gobernanza federada sobre "lagos" y "zonas" específicos de dominio. Usar conjuntos de datos de BigQuery por dominio. Usar Analytics Hub para compartir productos de datos entre dominios.

Por qué: Dataplex proporciona el plano de gobernanza central mientras permite la autonomía del dominio, un principio fundamental del data mesh.

Combinar un data lake y un data warehouse, permitiendo trabajos de Spark en datos crudos y SQL rápido en datos curados.

→Almacenar datos en formatos abiertos (Iceberg, Delta Lake) en Cloud Storage. Usar BigLake para proporcionar una capa unificada de gobernanza y acceso. Consultar datos tanto desde Dataproc (Spark) como desde BigQuery.

Por qué: BigLake permite consultar datos in situ en Cloud Storage con el rendimiento de BigQuery y seguridad granular, unificando el lago y el almacén.

Diseñar una estrategia de recuperación ante desastres para un data warehouse crítico de BigQuery con un RPO bajo (p. ej., 1 hora).

→Configurar la replicación de conjuntos de datos de BigQuery entre regiones para conjuntos de datos críticos. Usar Terraform o Dataform para gestionar definiciones de esquemas y vistas. Orquestrar la conmutación por error con Cloud Functions activadas por alertas de Cloud Monitoring.

Por qué: La replicación entre regiones proporciona una copia continuamente actualizada y consultable en una región de DR, cumpliendo los requisitos de bajo RPO/RTO para datos críticos.

Replicar continuamente cambios de una base de datos OLTP (p. ej., Oracle, PostgreSQL, MySQL) a BigQuery con baja latencia.

→Usar Datastream para realizar Change Data Capture (CDC). Configurar para transmitir cambios directamente a BigQuery, que los aplica utilizando su capacidad `MERGE`.

Por qué: Datastream es un servicio CDC gestionado y serverless que simplifica la replicación de bases de datos en tiempo real sin requerir pipelines personalizados o una carga significativa en la base de datos de origen.

Referencia↗

Una pipeline de streaming de Dataflow debe producir resultados precisos con ventanas de tiempo de evento a pesar de que algunos eventos lleguen horas tarde.

→Configurar ventanas de tiempo de evento con `allowedLateness` para acomodar el retraso. Usar triggers con activaciones tempranas para resultados preliminares y acumular paneles activados para incluir datos tardíos.

Por qué: El modelo de Dataflow de marcas de agua (watermarks), triggers y latencia permitida proporciona un marco robusto para equilibrar la completitud y la latencia al tratar con datos fuera de orden.

Una pipeline de Dataflow que escribe en BigQuery experimenta duplicados después de reinicios o fallas transitorias.

→Usar el sink de BigQuery Storage Write API (`STORAGE_WRITE_API`) con el método configurado en `at-least-once` (predeterminado, anteriormente `STREAMING_INSERTS`) o `exactly-once` (modo `COMMITTED`).

Por qué: La Storage Write API en modo `COMMITTED` proporciona semántica exactamente una vez incorporada para streaming, eliminando la necesidad de lógica de deduplicación personalizada.

Ingestar datos de una REST API paginada y con límite de tasa usando Dataflow.

→Usar un `SplittableDoFn` para procesar la fuente paginada en paralelo. Implementar lógica de límite de tasa (p. ej., usando un Guava RateLimiter) y retroceso exponencial para reintentos dentro del DoFn.

Por qué: Un `SplittableDoFn` permite el reequilibrio dinámico del trabajo. Combinarlo con el límite de tasa y la lógica de reintento crea un patrón resistente y eficiente para manejar APIs externas.

Un único flujo de datos necesita ser escrito en múltiples destinos (p. ej., BigQuery, Bigtable, Cloud Storage).

→En una única pipeline de Dataflow, después del procesamiento inicial, aplicar múltiples escritores `PTransform` a la misma `PCollection` final.

Por qué: El patrón de fan-out es altamente eficiente ya que los datos se procesan solo una vez. Evita el costo y la complejidad de ejecutar múltiples pipelines separadas leyendo de la misma fuente.

Un flujo de alto volumen debe ser enriquecido uniéndolo con una tabla de dimensiones de cambio lento (p. ej., perfiles de usuario) que se actualiza periódicamente.

→Usar el patrón de entrada lateral (side input) en Dataflow. Cargar la tabla de dimensiones como una `PCollectionView`. Configurar un trigger periódico para refrescar la entrada lateral según un horario, evitando reinicios de la pipeline.

Por qué: Las entradas laterales transmiten los datos de la dimensión a todos los workers para búsquedas rápidas en memoria, evitando llamadas a API/DB por elemento. La actualización periódica maneja las actualizaciones de manera eficiente.

Las cargas de trabajo del clúster de Dataproc varían significativamente, lo que lleva a un sobreaprovisionamiento o un rendimiento insuficiente.

→Crear un clúster de Dataproc con una política de autoescalado. Definir los recuentos mínimos/máximos de workers primarios y secundarios. La política escalará el clúster basándose en métricas de YARN.

Por qué: El autoescalado optimiza los costos al adaptar los recursos del clúster a la demanda del trabajo, escalando para cargas pesadas y reduciendo durante períodos de inactividad.

Una pipeline de Dataflow requiere binarios personalizados, librerías propietarias o versiones específicas no incluidas en las imágenes de worker estándar, y debe ejecutarse en una VPC sin internet.

→Construir una imagen de contenedor personalizada con todas las dependencias preinstaladas. Subir la imagen a Artifact Registry. Desplegar la pipeline usando una Flex Template que haga referencia al contenedor personalizado.

Por qué: Las Flex Templates con contenedores personalizados proporcionan control total sobre el entorno de ejecución y las dependencias, crucial para entornos offline o especializados.

Un trabajo de Dataflow o Spark que realiza un `GroupByKey` es lento porque algunas claves tienen un número desproporcionado de valores (una "clave caliente").

→Implementar una agregación en dos etapas (key salting). Primero, añadir un sufijo aleatorio a la clave para dividir la clave caliente entre múltiples workers. Agregación parcial. Segundo, eliminar el sufijo y agregar los resultados parciales.

Por qué: Esta técnica de fan-out divide manualmente el trabajo para la clave caliente, permitiendo que se procese en paralelo y superando el cuello de botella.

Una pipeline de streaming no debe fallar debido a registros mal formados. Los registros inválidos deben aislarse para su análisis sin detener el procesamiento.

→En un `DoFn`, usar un bloque try-catch para el parsing. Usar un DoFn de múltiples salidas con `TupleTag` para enrutar los registros válidos a la salida principal y los registros inválidos (con contexto de error) a una salida de error separada. Enviar la PCollection de error a un destino de dead-letter como un tema de Pub/Sub o una tabla de BigQuery.

Por qué: Este patrón proporciona resiliencia al aislar datos erróneos, prevenir fallos en la pipeline y asegurar que los registros fallidos sean capturados para depuración y reprocesamiento.

Las consultas de BigQuery son lentas y costosas, típicamente filtrando por una columna de fecha/hora y otras columnas de alta cardinalidad (p. ej., `customer_id`).

→Particionar la tabla por la columna de fecha/hora (p. ej., particiones diarias). Agrupar la tabla por hasta cuatro columnas frecuentemente filtradas (p. ej., `customer_id`, `product_category`).

Por qué: El particionamiento poda los datos escaneados a solo los períodos de tiempo relevantes. La agrupación (clustering) ordena aún más los datos dentro de las particiones, minimizando los datos escaneados para filtros en columnas agrupadas. Este es el patrón principal de optimización de rendimiento de BQ.

Referencia↗

La aplicación requiere lecturas y escrituras de baja latencia (menos de 10ms) para conjuntos de datos masivos (miles de millones de filas), como para personalización en tiempo real o un feature store de IoT.

→Usar Bigtable. Diseñar una clave de fila que soporte el patrón de acceso primario. Para series temporales, usar `entity_id#reverse_timestamp`.

Por qué: Bigtable es un almacén de columnas anchas NoSQL optimizado para cargas de trabajo de alto rendimiento y baja latencia a escala. BigQuery es para análisis y tiene una latencia de búsqueda puntual más alta.

Una aplicación transaccional requiere distribución global, escalabilidad horizontal y fuerte consistencia con una interfaz SQL.

→Usar Cloud Spanner con una configuración multirregión.

Por qué: Spanner es el único servicio que proporciona todas estas capacidades: distribuido globalmente, transacciones ACID y un esquema relacional. Cloud SQL es regional; Bigtable no es relacional y tiene consistencia eventual entre clústeres.

Un data warehouse de BigQuery tiene grandes cantidades de datos históricos que se consultan con poca frecuencia pero deben retenerse, lo que genera altos costos de almacenamiento.

→No se requiere ninguna acción para particiones/tablas no modificadas durante 90 días consecutivos. BigQuery aplica automáticamente precios de almacenamiento a largo plazo, una reducción de costos de aproximadamente el 50%.

Por qué: Esta es una optimización automática e integrada. Mover datos manualmente a GCS (a menos que sea para la capa de Archivo) a menudo es innecesario y añade complejidad.

Los datos en un bucket de Cloud Storage tienen un patrón de acceso predecible: frecuente durante 30 días, ocasional durante 90 días y luego raro.

→Configurar una política de ciclo de vida del bucket para la transición de objetos: Standard -> Nearline (a los 30 días) -> Coldline (a los 90 días).

Por qué: Las políticas de ciclo de vida automatizan la optimización de costos al mover datos a clases de almacenamiento más baratas a medida que se accede a ellos con menos frecuencia.

Una tabla de BigQuery debe aplicar una restricción de clave única.

→Aplicar la unicidad en la pipeline de carga. Usar una declaración `MERGE` con lógica que solo inserta cuando la clave no existe. Alternativamente, usar un DoFn con estado en Dataflow para deduplicar.

Por qué: BigQuery no aplica las restricciones `PRIMARY KEY` o `UNIQUE`. La unicidad debe gestionarse mediante el proceso de carga de datos.

Una tabla de dimensiones en BigQuery necesita mantener un historial completo de cambios para análisis en un momento dado (SCD Tipo 2).

→Añadir columnas de marca de tiempo `valid_from` y `valid_to`. Cuando ocurre un cambio, usar una declaración `MERGE` para actualizar el `valid_to` en el registro antiguo e insertar un nuevo registro.

Por qué: Este es el patrón estándar para implementar SCD Tipo 2 en un data warehouse. `MERGE` proporciona una forma eficiente y atómica de realizar las operaciones de actualización e inserción requeridas.

Una aplicación requiere una base de datos gestionada y escalable para documentos JSON de esquema flexible con soporte transaccional y necesidades de consulta complejas.

→Usar Firestore en modo nativo. Utilizar colecciones, documentos y subcolecciones para modelar los datos. Crear índices compuestos para consultas complejas.

Por qué: Firestore es una base de datos de documentos NoSQL serverless optimizada para cargas de trabajo transaccionales con ricas capacidades de consulta, a diferencia de Bigtable (clave-valor) o BigQuery (analítica).

Necesidad de consultar datos en Cloud Storage (Parquet, Avro, etc.) a través de BigQuery mientras se aplica seguridad granular (a nivel de fila/columna).

→Crear tablas de BigLake sobre los datos de Cloud Storage. Aplicar políticas de seguridad a nivel de fila y columna de BigQuery a las tablas de BigLake.

Por qué: BigLake extiende la gobernanza de BigQuery a datos de formato abierto en Cloud Storage, habilitando una arquitectura de data lakehouse segura y unificada.

Un equipo de ciencia de datos necesita entrenar modelos de ML en grandes conjuntos de datos de BigQuery sin mover ni exportar datos.

→Usar BigQuery ML. Escribir declaraciones `CREATE MODEL` en SQL para entrenar, evaluar y predecir directamente dentro de BigQuery.

Por qué: BQML elimina el movimiento de datos, simplifica el flujo de trabajo de ML y aprovecha la potencia de procesamiento de BigQuery, acelerando la iteración.

Referencia↗

Los modelos de ML requieren características tanto para el entrenamiento por lotes como para la inferencia en línea de baja latencia, con consistencia entre ellos para evitar sesgos.

→Usar Vertex AI Feature Store. Ingestar características a través de lotes o streaming. Proporciona un almacén offline (BigQuery) para el entrenamiento y un almacén online (Bigtable) para el servicio de baja latencia.

Por qué: Este es un servicio gestionado y diseñado específicamente que resuelve el complejo problema de la consistencia de las características, la corrección en un momento dado y los requisitos de doble servicio.

Los usuarios de negocio necesitan BI de autoservicio, pero crean métricas e informes inconsistentes al consultar directamente el data warehouse.

→Implementar una capa semántica de Looker usando LookML. Definir dimensiones, medidas y uniones una vez. Los usuarios exploran el modelo gobernado en lugar de tablas crudas.

Por qué: LookML proporciona una "única fuente de verdad" para la lógica de negocio, asegurando informes consistentes y precisos mientras permite la exploración de autoservicio.

Necesidad de implementar controles de calidad de datos automatizados (nulos, unicidad, rangos de valores) y monitoreo para datos en BigQuery y Cloud Storage.

→Usar Dataplex Data Quality. Definir reglas en YAML o usar reglas autogeneradas a partir del perfilado. Programar escaneos para monitorear la calidad a lo largo del tiempo.

Por qué: Dataplex proporciona una solución de calidad de datos gestionada e integrada que es más escalable y mantenible que las comprobaciones o scripts SQL personalizados.

Descubrir agrupaciones o segmentos naturales dentro de un conjunto de datos de clientes sin etiquetas predefinidas.

→Usar BigQuery ML para entrenar un modelo de clustering `KMEANS` directamente sobre los datos del cliente.

Por qué: K-means es un algoritmo de aprendizaje no supervisado ideal para la segmentación. BQML lo hace accesible vía SQL sin exportación de datos.

Habilitar búsqueda semántica (basada en el significado, no en palabras clave) sobre datos de texto almacenados en BigQuery.

→Usar la función `ML.GENERATE_EMBEDDING` con un modelo fundacional de Vertex AI para crear embeddings vectoriales. Almacenarlos y usar la función `VECTOR_SEARCH` para búsqueda de similitud.

Por qué: Este patrón integra potentes capacidades de búsqueda semántica directamente en BigQuery, evitando la necesidad de índices de búsqueda externos como Elasticsearch.

Integrar capacidades de Large Language Model (LLM) como resumen de texto o clasificación directamente en un flujo de trabajo de análisis de BigQuery.

→Crear un modelo remoto de BigQuery ML que apunte a un endpoint LLM de Vertex AI. Usar la función `ML.GENERATE_TEXT` dentro de una consulta SQL para procesar datos de texto.

Por qué: Esto integra estrechamente la IA generativa en SQL, permitiendo a los analistas aprovechar los LLM en sus datos sin salir del entorno de BigQuery ni escribir código de aplicación complejo.

Una pipeline de datos de varios pasos implica dependencias complejas, reintentos y tareas en diferentes servicios de GCP (p. ej., Dataflow, BigQuery, Dataproc).

→Usar Cloud Composer (Apache Airflow gestionado). Definir el flujo de trabajo como un Grafo Acíclico Dirigido (DAG) usando Python.

Por qué: Composer es la herramienta designada de GCP para la orquestación de flujos de trabajo complejos, proporcionando una gestión robusta de dependencias, programación, lógica de reintentos y monitoreo que herramientas más simples como Cloud Scheduler no tienen.

Una tarea DAG de Airflow que llama a una API externa falla con frecuencia debido a problemas de red transitorios.

→Configurar reintentos a nivel de tarea en el DAG con `retry_exponential_backoff=True`. Esto aumenta el retraso entre reintentos, dando tiempo al sistema externo para recuperarse.

Por qué: El retroceso exponencial es una buena práctica para reintentar fallas transitorias, ya que evita sobrecargar un sistema posterior con dificultades con solicitudes rápidas y repetidas.

Gestionar, versionar, probar y programar un conjunto complejo de transformaciones SQL interdependientes en BigQuery.

→Usar Dataform. Definir tablas y dependencias en archivos SQLX, usar Git para control de versiones, escribir aserciones de calidad de datos y programar flujos de trabajo de ejecución.

Por qué: Dataform es la solución nativa de Google Cloud para ELT, proporcionando gestión de dependencias, pruebas y control de versiones para transformaciones de BigQuery, promoviendo las mejores prácticas de DataOps.

Necesidad de comprender y visualizar cómo fluyen los datos desde la fuente hasta el informe final a través de múltiples servicios como BigQuery y Dataflow.

→Usar Dataplex, que captura y muestra automáticamente el linaje de datos de los servicios de Google Cloud compatibles en la UI de Data Catalog.

Por qué: El seguimiento automatizado del linaje es crucial para el análisis de impacto, la depuración y la gobernanza. Dataplex lo proporciona de forma predeterminada para los servicios integrados.

Un trabajo de streaming de Dataflow en ejecución necesita ser actualizado con nueva lógica sin perder datos ni estado.

→Lanzar la nueva versión de la pipeline usando la opción de línea de comandos `--update` y especificando el ID del trabajo de la pipeline en ejecución. Usar el modo `drain` para permitir que el trabajo antiguo termine de procesar los datos en tránsito.

Por qué: El mecanismo de actualización in-place de Dataflow proporciona una forma de desplegar cambios en pipelines de streaming sin tiempo de inactividad, preservando el estado y garantizando el procesamiento exactamente una vez.

Para cumplimiento, todo acceso de lectura y escritura a datos sensibles en BigQuery y Cloud Storage debe ser registrado y auditable.

→Habilitar Cloud Audit Logs, específicamente los registros de Acceso a Datos, para los servicios relevantes. Crear un sink de logs para exportar estos registros a BigQuery para retención y análisis a largo plazo.

Por qué: Cloud Audit Logs proporcionan un registro a prueba de manipulaciones y completo del acceso a los datos. Enviar logs a BigQuery permite una auditoría y generación de informes potentes basados en SQL.

Los conjuntos de datos, tablas y controles de acceso de BigQuery necesitan ser gestionados como código para repetibilidad y versionado (Infraestructura como Código).

→Definir todos los recursos de BigQuery (conjuntos de datos, tablas, políticas de IAM) en archivos de configuración de Terraform (`.tf`). Gestionar los despliegues a través de una pipeline de CI/CD.

Por qué: Terraform es el estándar para IaC en GCP, permitiendo una gestión auditada, versionada y consistente de la infraestructura de datos, previniendo la deriva de configuración manual.

Un modelo de ML en producción muestra un rendimiento degradado con el tiempo.

→Implementar Vertex AI Model Monitoring. Configurar un trabajo de monitoreo para detectar el sesgo de entrenamiento-servicio y la deriva de predicción comparando el tráfico de producción con una línea base. Configurar alertas para activar una investigación o un reentrenamiento automatizado.

Por qué: El rendimiento del modelo se degrada debido a la deriva de datos. El monitoreo proactivo es esencial para detectarla y mantener la precisión del modelo, justificando el reentrenamiento.