Entrevista de ingeniería de datos: ¿Cómo evaluaría las dynamic tables CUSTOM_INCREMENTAL de Snowflake?

Consigna y contexto

El equipo ya cuenta con un flujo de cambios (change stream) y desea mantener una dynamic table que admita soft deletes, joins entre streams y tablas estáticas o agregaciones con estado. Explique cómo decidiría si CUSTOM_INCREMENTAL es adecuado, definiría la lógica incremental, validaría los resultados y prepararía el rollback. No se limite a repetir las notas de la versión de Snowflake.

Qué evalúa el entrevistador

• Comprensión de que el desarrollador define la lógica MERGE o INSERT mientras que la plataforma proporciona la programación, los reintentos y las garantías transaccionales.
• Capacidad para distinguir entre actualización incremental, actualización completa (full refresh) y orquestación con streams/Tasks.
• Manejo de claves, ordenamiento de cambios, eventos duplicados, soft deletes y el backfill inicial.
• Razonamiento completo sobre el retraso de actualización (lag), los reintentos, el costo, la observabilidad y el rollback.

Preguntas de clarificación que se deben hacer

1. ¿El origen es de solo anexado (append-only), CDC o capaz de corregir el historial? ¿Debería una eliminación dejar una marca de borrado (tombstone) en el destino?
2. ¿Cuál es la clave única de la tabla de destino? ¿Cómo se ordenan las actualizaciones duplicadas, tardías y repetidas?
3. ¿Puede expresarse la lógica de forma incremental o debe recalcularlo todo periódicamente? ¿Qué lag es aceptable?
4. ¿Quién concilia los resultados y genera alertas durante la creación inicial, los reintentos, los cambios de esquema y el rollback?

Marco de respuesta en 30 segundos

Primero verificaría que los cambios puedan representarse mediante claves estables y una marca de agua (watermark), y luego probaría si la lógica incremental personalizada puede mantener el destino de manera segura. Si es adecuada, especificaría el rango de cambios, las condiciones idempotentes de MERGE/INSERT, el comportamiento de soft delete y la política para eventos tardíos en cada actualización. Conciliaría la salida incremental con resultados muestreados de una actualización completa. La programación, los reintentos y las transacciones de la plataforma no definen el orden de negocio ni la semántica de eliminación. Antes del lanzamiento, establecería métricas y controles para el lag, los fallos, la reversión a la actualización estándar y las reconstrucciones completas.

Análisis detallado paso a paso

1. Definir el límite incremental

Separe la proyección, el filtrado, los joins, la agregación y la semántica de eliminación. La lógica incremental tiene un límite comprobable solo cuando se pueden identificar las filas de entrada afectadas y las claves de destino. Mantenga una opción de actualización completa para ordenamientos globales o lógica no determinista cuyo impacto no se pueda delimitar.

2. Diseñar el contrato de aplicación de cambios

Asigne a cada cambio una clave de negocio, versión o tiempo de evento, y defina el ganador para los conflictos en una misma clave. La coincidencia del MERGE debe ser idempotente. Un soft delete necesita un marcador de eliminación o tombstone para que un evento antiguo y tardío no pueda recrear una fila eliminada.

3. Gestionar la primera ejecución y los fallos

Comience con un conjunto de datos controlado y compare la salida incremental personalizada con una línea base de actualización completa antes de ampliar el alcance. Los reintentos deben poder repetirse de forma segura sin generar filas duplicadas. Pause la publicación y recurra a una actualización completa o reconstrucción verificable cuando aparezca un cambio de esquema, una desviación no explicada o una marca de agua dañada.

4. Monitorear la corrección y el costo

Monitoree el lag de actualización, el recuento de filas afectadas, los fallos, los reintentos y la marca de agua de origen; concilie periódicamente los resultados incrementales y completos. Estime los costos de cómputo del warehouse, almacenamiento, reconstrucción y consultas posteriores de forma independiente, en lugar de observar únicamente la duración de una sola actualización.

Respuesta modelo

Trataría a CUSTOM_INCREMENTAL como un contrato de mantenimiento incremental cuya corrección debe demostrarse. Primero exigiría una clave de negocio estable, versión o marca de agua para cada cambio, con reglas explícitas para soft deletes, eventos tardíos y conflictos; si las filas de destino afectadas no se pueden delimitar, mantendría la actualización completa. Luego implementaría una lógica MERGE/INSERT idempotente, conciliaría muestras controladas con una línea base completa y probaría repeticiones, reintentos, el backfill inicial y cambios de esquema. La plataforma de dynamic tables proporciona programación, reintentos y garantías transaccionales, pero no decide el orden de los eventos ni la semántica de eliminación. En producción monitorearía marcas de agua, lag, filas afectadas, desviaciones y costos, con rutas de pausa, reconstrucción y reversión a actualización estándar.

Errores comunes

• Asumir que CUSTOM_INCREMENTAL puede convertir en incremental cualquier SQL arbitrario de forma automática.
• Escribir MERGE sin claves estables, versiones o reglas para eventos duplicados.
• Ignorar soft deletes, datos tardíos o el backfill completo inicial.
• Tratar las transacciones de la plataforma como prueba de que los resultados de negocio son correctos.
• Omitir la conciliación entre lo incremental y lo completo, las alertas de desviación o el rollback.
• Comparar solo la latencia ignorando los costos de actualización continua y de reconstrucción.

Preguntas de seguimiento y respuestas

¿Cuándo debería insistir en una actualización completa?

Prefiera una actualización completa cuando el alcance del impacto no se pueda delimitar, la lógica contenga ordenamiento global o funciones no deterministas, o la conciliación no pueda demostrar el resultado incremental. Acote el rango de datos y la frecuencia antes de decidir si vale la pena la incrementalización.

¿Cómo maneja un evento tardío para la misma clave?

Incluya una versión monotónica o un tiempo de evento comparable y acepte solo versiones más nuevas en la condición del MERGE. Si no se puede confiar en el orden, aísle el conflicto y genere una alerta en lugar de sobrescribir silenciosamente.

¿Cómo demuestra que el resultado incremental no se ha desviado?

Recalcule periódicamente una línea base completa por partición o rango de claves, compare recuentos de filas, sumas de verificación (checksums) y métricas de negocio, y conserve muestras de diferencias en una tabla de auditoría. Pause la publicación o reconstruya cuando la diferencia supere un umbral.