Entrevista de ingeniería de datos: ¿Cómo evaluarías las continuous queries de BigQuery?

Planteamiento y alcance

El negocio quiere que los datos escritos en BigQuery activen alertas rápidamente y envíen resultados a una tabla, Pub/Sub, Bigtable o Spanner. Explica si se deben usar continuous queries de BigQuery y cómo manejarías la semántica de entrada, la autorización, el tiempo de ejecución, las regiones, el costo y la recuperación. No limites la respuesta a la sintaxis SQL.

Qué está evaluando el entrevistador

• Si entiendes una continuous query como SQL en ejecución continua y no como un sondeo a intervalos fijos.
• Si puedes posicionarla en relación con Dataflow, Pub/Sub y consultas ordinarias basándote en la latencia y la semántica de los datos.
• Si verificas la edición Enterprise, la reserva CONTINUOUS, la cuenta de servicio y las restricciones regionales.
• Si abordas las salidas duplicadas, la contrapresión (backpressure), el monitoreo, el comportamiento de reinicio y el costo.

Preguntas para clarificar

1. ¿La entrada es de solo anexado (append-only) o se pueden actualizar y eliminar filas existentes? ¿Son aceptables los duplicados?
2. ¿El destino es BigQuery, Pub/Sub, Bigtable o Spanner, y pueden los consumidores reintentar de forma segura?
3. ¿Qué garantías de latencia, tiempo de ejecución y región de datos se requieren? ¿Está el proyecto aprovisionado para ellas?
4. Tras una falla, ¿desde dónde se reanuda el procesamiento y cómo se monitorean el retraso (lag), los errores y el volumen de salida?

Una respuesta de 30 segundos

Primero verificaría que el requerimiento sea genuinamente un procesamiento continuo. Las continuous queries analizan los datos entrantes de BigQuery y escriben o exportan resultados, pero tienen restricciones de edición, capacidad, autorización y regionales. Define claves de idempotencia, elije el destino y prepara una cuenta de servicio, una reserva CONTINUOUS y monitoreo. Valida la latencia, los duplicados, el costo, la detención y la recuperación con tráfico controlado; no trates la funcionalidad como un reemplazo ilimitado y gratuito de Cron.

Diseño paso a paso

1. Definir primero la semántica de los datos

Una continuous query procesa continuamente los datos escritos en las tablas de BigQuery. Las inserciones, los eventos tardíos, las actualizaciones y las eliminaciones tienen significados diferentes. Si el negocio necesita estado complejo, ventanas de tiempo de evento u ordenamiento estricto, confirma el comportamiento de SQL admitido y compáralo con un procesador de flujos como Dataflow.

2. Elegir la ruta de salida

La documentación admite insertar resultados en una tabla de BigQuery o usar EXPORT DATA hacia Pub/Sub, Bigtable o Spanner. Elige según el rendimiento (throughput) posterior, el ordenamiento, la idempotencia y la región. Pub/Sub es útil para otra etapa de procesamiento de eventos; las escrituras directas en tablas necesitan deduplicación y claves de retención.

3. Verificar las restricciones de tiempo de ejecución y autorización

Puedes crear y ejecutar una continuous query con una cuenta de usuario o una cuenta de servicio; exportar a Pub/Sub requiere una cuenta de servicio. Un trabajo con cuenta de usuario puede ejecutarse hasta por dos días, mientras que un trabajo con cuenta de servicio puede ejecutarse hasta por 150 días. Las continuous queries requieren la edición Enterprise o Enterprise Plus y una asignación de reserva de tipo CONTINUOUS.

4. Presupuestar, monitorear y recuperar

Las continuous queries utilizan los precios de cómputo por capacidad de BigQuery, mientras que los servicios receptores tienen costos por separado. Monitorea métricas específicas de la consulta, la latencia de entrada a salida, errores, reinicios y el volumen de salida; define procedimientos de detención, reconstrucción y alertas. Realiza la recuperación a partir de una clave de idempotencia o marca de agua (watermark) y reproduce solo un rango aceptable, para que un reinicio no duplique efectos secundarios.

Respuesta modelo de alta calidad

Evaluaría una continuous query como una restricción operativa de producto de datos. Puede analizar continuamente los datos escritos en BigQuery y escribir o exportar resultados a BigQuery, Pub/Sub, Bigtable o Spanner, pero la semántica de anexado frente a cambios y la tolerancia a duplicados determinan si es adecuada. Verificaría la edición Enterprise, la reserva CONTINUOUS, la cuenta de servicio, el tiempo de ejecución máximo y el límite regional. El contrato de salida definiría la idempotencia, los reintentos y el manejo de mensajes no entregables (dead-letter); la telemetría cubriría el retraso, el backlog, los errores y el costo. Antes del lanzamiento, se probaría la latencia y el comportamiento de reinicio con tráfico controlado, contando con procedimientos explícitos de pausa, reanudación y backfill. Si la carga de trabajo necesita un estado de tiempo de evento enriquecido, ordenamiento estricto o una topología de mayor duración, evaluaría un procesador de flujos dedicado en lugar de forzar cada requerimiento en tiempo real dentro de BigQuery.

Errores comunes

• Tratar una continuous query como una consulta que se ejecuta una vez por minuto.
• Ignorar los requisitos de Enterprise o Enterprise Plus, la reserva CONTINUOUS o la cuenta de servicio.
• Asumir que cada destino tiene una semántica idéntica de ordenamiento y duplicados.
• Omitir marcas de agua o claves de idempotencia para reinicios, duplicados y datos tardíos.
• Medir la latencia de SQL sin presupuestar la capacidad de BigQuery y los servicios posteriores.
• Tratar los límites de tiempo de ejecución de dos días o 150 días como una promesa de ejecución permanente.

Preguntas de seguimiento y respuestas

¿Cuándo elegirías Dataflow?

Compara con Dataflow u otro procesador de flujos cuando la carga de trabajo necesite ventanas complejas de tiempo de evento, gestión de estado, ordenamiento estricto, conectores enriquecidos o una topología de larga duración. El límite es semántico y operativo, no la cantidad de líneas de SQL.

¿Cómo evitas alertas duplicadas después de un reinicio?

Coloca una clave de idempotencia de negocio o de evento en cada salida, deduplica o realiza transacciones downstream, y registra una marca de agua y el lote de procesamiento. Reanuda desde un límite de reproducción seguro y documenta cualquier comportamiento inevitable de duplicados para los consumidores.

¿Cómo decides si el costo es aceptable?

Estima los slots de capacidad, la ingesta y el almacenamiento, además de los cargos de Pub/Sub, Bigtable o Spanner por separado. Realiza pruebas de carga en estado estable, períodos de inactividad y picos, y luego calibra el presupuesto con la latencia observada y el consumo de slots.