Google Cloud Associate Data Practitioner
Última revisión: mayo de 2026
Una referencia escaneable de patrones arquitectónicos que evalúa el examen ADP. Lee de arriba a abajo o salta a una sección.
Cargar archivos por lotes grandes (CSV, Parquet, Avro) desde Cloud Storage a BigQuery.
Utilizar un trabajo de carga de BigQuery. Especificar un URI comodín (por ejemplo, `gs://bucket/path/*`) para cargar múltiples archivos en un solo trabajo.
Por qué: Este es el método más rápido y rentable para la ingesta por lotes. Los trabajos de carga son gratuitos. Evita los costos por fila del streaming.
Ingerir datos en tiempo real y de alto volumen (IoT, clickstream) con potencial de transformación.
Pub/Sub -> Dataflow -> BigQuery.
Por qué: Patrón de streaming escalable canónico. Pub/Sub proporciona un búfer duradero y escalable. Dataflow permite transformaciones complejas, ventanas y procesamiento exactamente una vez.
Replicar una base de datos operativa (MySQL, PostgreSQL, Oracle) a BigQuery con baja latencia, capturando todos los cambios (inserciones, actualizaciones, eliminaciones).
Usar Datastream para la Captura de Datos Cambiados (CDC).
Por qué: Diseñado específicamente para CDC en tiempo real y de bajo impacto. Maneja la carga inicial y transmite los cambios continuos directamente a BigQuery.
Realizar validación, enriquecimiento o transformación compleja de datos (por ejemplo, aplanar JSON/XML anidado) antes de cargarlos en BigQuery.
Utilizar un pipeline de Dataflow con transformaciones personalizadas de Apache Beam (por ejemplo, ParDo).
Por qué: Dataflow proporciona máxima flexibilidad para código personalizado (Python/Java), lógica compleja y enrutamiento de registros inválidos a una cola de mensajes no entregados (dead-letter queue).
Transferir terabytes o petabytes de datos desde otra nube (por ejemplo, S3) o un centro de datos local a Cloud Storage.
Para transferencias de nube a nube, usar Storage Transfer Service. Para entornos locales con ancho de banda de red limitado, usar Transfer Appliance.
Por qué: STS es un servicio gestionado de alto rendimiento para transferencias en línea. Transfer Appliance es para transferencias fuera de línea (envío físico) cuando la red es el cuello de botella.
Consultar datos que residen en Cloud Storage o Amazon S3 directamente desde BigQuery sin cargarlos.
Crear una tabla externa de BigQuery. Para una gobernanza unificada con Spark, usar una tabla BigLake.
Por qué: Evita la duplicación de datos y los costos de almacenamiento en BigQuery. BigLake añade seguridad granular (a nivel de fila/columna) y gobernanza sobre los datos de almacenamiento de objetos.
Un pipeline de ingesta debe adaptarse automáticamente cuando se añaden nuevas columnas a los archivos de origen (JSON, Avro).
Configurar el trabajo de carga de BigQuery con `schemaUpdateOptions` establecido en `ALLOW_FIELD_ADDITION`.
Por qué: Automatiza la evolución del esquema. BigQuery añade las nuevas columnas al esquema de la tabla sin que el trabajo de carga falle.
Transmitir datos de alto volumen a BigQuery con semántica de "exactamente una vez" a un costo menor que la API de streaming legada.
Usar la API de escritura de almacenamiento de BigQuery.
Por qué: Proporciona un mayor rendimiento y menores costos que la API `insertAll` anterior, con garantías sólidas como la entrega exactamente una vez dentro de un flujo.
Orquestar un flujo de trabajo complejo con múltiples tareas dependientes (por ejemplo, Dataflow, BigQuery, Cloud Functions) según un cronograma.
Usar Cloud Composer (Apache Airflow gestionado).
Por qué: El estándar para la orquestación de flujos de trabajo complejos. Proporciona DAGs para definir dependencias, programación, reintentos, alertas y un rico ecosistema de operadores.
Un DAG de Cloud Composer necesita pausarse y esperar a que un archivo específico aparezca en un bucket de Cloud Storage antes de continuar.
Usar el `GCSObjectExistenceSensor` en el DAG de Airflow.
Por qué: Este es el patrón idiomático de "sensor" de Airflow para esperar condiciones externas. Es más eficiente que un bucle de sondeo personalizado en un PythonOperator.
Un pipeline de streaming de Dataflow necesita agregar correctamente eventos por marca de tiempo, incluso si los eventos llegan fuera de orden o con retraso.
Usar ventanas de tiempo de evento (event-time windowing) con marcas de agua (watermarks) y configurar `allowedLateness`.
Por qué: Esta característica central de Dataflow/Beam agrupa correctamente los datos basándose en cuándo ocurrió el evento, no cuándo fue procesado. `allowedLateness` evita que los datos tardíos sean descartados.
Ejecutar trabajos de Apache Spark a gran escala y no interactivos para procesamiento por lotes o ML.
Usar un clúster de Dataproc. Para el máximo ahorro de costos, usar un clúster efímero con Spot VMs (anteriormente VMs preemptivas).
Por qué: Dataproc es el servicio gestionado de Spark/Hadoop. Los clústeres efímeros existen solo durante la duración del trabajo, y las Spot VMs ofrecen grandes descuentos para cargas de trabajo tolerantes a fallos.
Crear un pipeline de Dataflow estandarizado que pueda ser ejecutado por diferentes equipos con parámetros variables (por ejemplo, rutas de entrada/salida).
Empaquetar el pipeline como una plantilla flexible de Dataflow (Dataflow Flex Template).
Por qué: Las plantillas flexibles son el estándar moderno para trabajos de Dataflow reutilizables. Se basan en contenedores, admiten dependencias personalizadas y aceptan parámetros en tiempo de ejecución.
Una tarea en un DAG de Cloud Composer falla intermitentemente debido a problemas externos temporales (por ejemplo, limitación de tasa de API, contención de recursos).
Configurar `retries` y `retry_delay` con `retry_exponential_backoff=True` para la tarea.
Por qué: Esto hace que el pipeline sea resiliente al reintentar automáticamente las tareas fallidas con demoras crecientes, a menudo resolviendo problemas transitorios sin intervención manual.
Un pipeline de streaming de Dataflow se está quedando atrás, mostrando un alto retraso del sistema o una baja frescura de los datos.
Investigar las métricas de monitoreo de Dataflow. Verificar si el autoescalado está alcanzando el límite de `maxNumWorkers`. Aumentar `maxNumWorkers` o cambiar a un tipo de máquina más grande.
Por qué: Un alto retraso del sistema es un indicador principal de capacidad de procesamiento insuficiente. El pipeline necesita más o más grandes workers para mantenerse al día con la afluencia de datos.
Optimizar una tabla grande de BigQuery para el costo y el rendimiento de las consultas.
Particionar la tabla por una columna de unidad de tiempo frecuentemente filtrada (por ejemplo, fecha de transacción). Agrupar la tabla por otras columnas de alta cardinalidad y frecuentemente filtradas (por ejemplo, `customer_id`).
Por qué: El particionamiento es la forma más efectiva de reducir el costo y la latencia al podar la cantidad de datos escaneados. El agrupamiento mejora aún más el rendimiento al ordenar los datos dentro de las particiones.
Prevenir que los datos de un conjunto de datos sensible de BigQuery sean copiados a un destino no autorizado (por ejemplo, un bucket público de GCS), incluso por un usuario con credenciales válidas.
Usar Controles de Servicio de VPC (VPC Service Controls) para crear un perímetro de servicio alrededor del proyecto que contiene el conjunto de datos de BigQuery.
Por qué: Los Controles de Servicio de VPC actúan como un "cortafuegos virtual" para los servicios de GCP, evitando que los datos salgan del perímetro. Este es un control crítico de defensa en profundidad contra la exfiltración de datos.
Restringir el acceso a columnas sensibles (por ejemplo, PII) en una tabla de BigQuery a grupos autorizados, mientras se permite a otros consultar las columnas restantes.
Usar Data Catalog para crear una taxonomía y etiquetas de política. Aplicar etiquetas de política a columnas sensibles y otorgar el rol de "Lector de Granularidad Fina" (Fine-Grained Reader) a grupos autorizados.
Por qué: Este es el método nativo y escalable para la seguridad a nivel de columna en BigQuery. Proporciona gobernanza centralizada sin necesidad de crear y gestionar vistas separadas.
Filtrar una tabla para que los usuarios solo puedan ver las filas que les corresponden (por ejemplo, los gerentes de ventas solo ven los datos de su propia región).
Crear una política de seguridad a nivel de fila (Row-Level Security Policy) en la tabla que filtra las filas basándose en `SESSION_USER()`.
Por qué: Proporciona filtrado dinámico basado en predicados en tiempo de consulta. Esto es más seguro y manejable que crear una vista autorizada para cada usuario o rol.
Eliminar automáticamente datos de una tabla de BigQuery después de un período de retención especificado para cumplir con las regulaciones (por ejemplo, eliminar datos de más de 7 años).
Para datos de series temporales, establecer una caducidad de partición en la tabla particionada por tiempo. Para otras tablas, establecer la caducidad predeterminada de la tabla.
Por qué: Esta es una característica incorporada, de "configurar y olvidar", que garantiza el cumplimiento sin scripts de limpieza manuales u orquestación externa.
Una tabla de BigQuery fue modificada o eliminada accidentalmente.
Usar BigQuery Time Travel para consultar la tabla tal como existía en un punto en el tiempo antes del incidente, utilizando `FOR SYSTEM_TIME AS OF`.
Por qué: BigQuery mantiene automáticamente un historial de 7 días de los datos de la tabla. Esto permite una recuperación instantánea dentro de la ventana de Time Travel sin necesidad de restaurar desde copias de seguridad.
Descubrir, gestionar, proteger y monitorear activos de datos (BigQuery, GCS) en toda una organización.
Usar Dataplex.
Por qué: Dataplex actúa como un tejido de datos inteligente, proporcionando un panel unificado para la gobernanza, calidad, linaje, descubrimiento y gestión del ciclo de vida de los datos a través de silos de datos dispares.
Comprender y visualizar cómo fluyen los datos desde los sistemas de origen, a través de trabajos de transformación, hasta las tablas de informes finales.
Usar Dataplex Data Lineage.
Por qué: Captura automáticamente la información de linaje de BigQuery, Data Fusion y los registros de Composer para proporcionar una vista interactiva basada en gráficos de las dependencias de datos para análisis de impacto y auditorías.
Asegurar un rendimiento y costo de consulta predecibles para cargas de trabajo críticas, evitando la "contención de slots" de otros usuarios.
Comprar ediciones de BigQuery (precios basados en capacidad). Crear reservas para dedicar un conjunto de slots a proyectos o carpetas específicos.
Por qué: Cambia de un grupo compartido bajo demanda a una capacidad de cómputo dedicada, garantizando recursos para trabajos críticos y proporcionando una facturación predecible.
Escanear todos los activos de datos en BigQuery y Cloud Storage para identificar y clasificar automáticamente PII y otros datos sensibles.
Configurar un trabajo de escaneo de descubrimiento de Cloud Data Loss Prevention (DLP).
Por qué: Cloud DLP utiliza cientos de detectores predefinidos para encontrar datos sensibles a escala. Puede integrarse con Data Catalog para aplicar automáticamente etiquetas de política para la gobernanza.
Una aplicación en contenedores (en GKE o Cloud Run) necesita autenticarse de forma segura en BigQuery sin gestionar claves de cuenta de servicio.
Usar Workload Identity.
Por qué: La mejor práctica recomendada para la autenticación de servicio a servicio. Asigna una cuenta de servicio de Kubernetes a una cuenta de servicio de GCP IAM, utilizando tokens de corta duración y rotados automáticamente.
Para cumplir con normativas, generar un informe de todos los usuarios que han consultado una tabla sensible de BigQuery en los últimos 90 días.
Habilitar y consultar los registros de auditoría de acceso a datos de BigQuery, que pueden ser enrutados a un conjunto de datos de BigQuery para su análisis.
Por qué: Los registros de acceso a datos proporcionan un registro inmutable de quién accedió a qué datos y cuándo. Son esenciales para las auditorías de seguridad y cumplimiento, pero deben habilitarse explícitamente.
Identificar qué usuarios o consultas son responsables de los altos costos de BigQuery.
Consultar la vista `INFORMATION_SCHEMA.JOBS`.
Por qué: Esta vista de metadatos contiene información detallada para cada consulta ejecutada, incluyendo el usuario, los bytes facturados y los slots consumidos, lo que permite una atribución y análisis preciso de los costos.
Realizar cálculos analíticos complejos como totales acumulados, clasificación dentro de grupos (por ejemplo, top N por categoría) o comparar una fila con una fila precedente.
Usar funciones de ventana SQL de BigQuery (`SUM() OVER (...)`, `RANK() OVER (...)`, `LAG() OVER (...)`).
Por qué: El método SQL estándar y más eficiente para realizar cálculos a través de un conjunto de filas de una tabla que están de alguna manera relacionadas con la fila actual.
Crear y compartir paneles interactivos y de auto-actualización sobre datos de BigQuery para usuarios de negocio que no escriben SQL.
Usar Looker Studio.
Por qué: La herramienta de visualización nativa y gratuita de GCP. Se conecta directamente a BigQuery y permite compartir a través de un enlace simple, gestionando las credenciales de la fuente de datos separadamente del acceso del usuario.
Permitir a los analistas de negocio usar herramientas de hoja de cálculo familiares (tablas dinámicas, gráficos, fórmulas) para analizar terabytes de datos en BigQuery.
Usar Hojas Conectadas (Connected Sheets).
Por qué: Proporciona una conexión en vivo desde Google Sheets a BigQuery. Todo el procesamiento y cálculo ocurre en BigQuery, omitiendo los límites de tamaño y rendimiento de una hoja de cálculo tradicional.
Un panel de Looker Studio que consulta agregaciones grandes y complejas es lento y costoso.
Crear una vista materializada de BigQuery (BigQuery Materialized View) para precalcular las agregaciones. Apuntar la fuente de datos de Looker Studio a la vista materializada.
Por qué: Las vistas materializadas precalculan y almacenan en caché resultados de consultas costosas. Esto mejora drásticamente el rendimiento del panel y reduce los costos de consulta para cargas de trabajo repetitivas.
Construir, entrenar y servir un modelo de machine learning (por ejemplo, para clasificación, regresión o pronóstico) utilizando datos que residen en BigQuery.
Usar BigQuery ML (BQML).
Por qué: Democratiza el ML al permitir a los usuarios entrenar modelos con la sintaxis estándar SQL `CREATE MODEL`. El modelo reside y se ejecuta dentro de BigQuery, simplificando el despliegue y la predicción.
Pronosticar métricas de negocio futuras (por ejemplo, ventas, demanda) basándose en datos históricos de series de tiempo.
Usar BigQuery ML con el tipo de modelo `ARIMA_PLUS`.
Por qué: `ARIMA_PLUS` es un modelo BQML construido específicamente para la previsión de series temporales que maneja automáticamente tendencias, estacionalidad, festivos y detección de anomalías.
Una consulta de BigQuery que une una tabla de hechos muy grande (TBs) con una tabla de dimensiones pequeña (<100MB) es lenta.
Asegurarse de que BigQuery esté utilizando un broadcast join. Aunque a menudo es automático, se puede verificar el plan de consulta o usar una pista `JOIN` si es necesario.
Por qué: Un broadcast join envía toda la tabla pequeña a cada slot de procesamiento, evitando una costosa y lenta redistribución de datos (data shuffle) de la tabla grande a través de la red.
Un modelo de BigQuery ML necesita ser reentrenado regularmente (por ejemplo, semanalmente) con nuevos datos para prevenir la deriva del modelo.
Usar una consulta programada de BigQuery (BigQuery Scheduled Query) para ejecutar una declaración `CREATE OR REPLACE MODEL`.
Por qué: Esta es la forma más simple y más integrada de automatizar el reentrenamiento de BQML. No requiere servicios externos como Composer o Cloud Functions.
Construir un sistema de recomendación de filtrado colaborativo (por ejemplo, "usuarios que compraron X también compraron Y").
Usar BigQuery ML con el tipo de modelo `MATRIX_FACTORIZATION`.
Por qué: Este modelo está diseñado específicamente para tareas de recomendación basadas en datos de interacción usuario-ítem.
