Consigna y contexto
Un equipo lee archivos de cambios en formato Parquet con DuckDB y mantiene una dimensión de clientes y un historial de precios de forma local. Explica cuándo usar MERGE INTO y cómo manejar claves duplicadas, eliminaciones, SCD Tipo 2, reejecuciones y recuperación.
Qué evalúa el entrevistador
Evalúan tu comprensión de los predicados de coincidencia, el orden de las acciones, la unicidad del origen y los límites de las transacciones, además de tu capacidad para convertir la conveniencia de SQL en una canalización reejecutable con calidad, auditoría y reversión (rollback).
Preguntas para clarificar
Pregunta por la clave de negocio, el ordenamiento por tiempo del evento (event-time) y si se requiere historial. Clarifica los registros duplicados, tardíos y de eliminación, y si el destino se puede reconstruir tras una falla. No trates MERGE como un CDC con semántica de exactamente una vez (exactly-once) automático.
Respuesta de 30 segundos
“Deduplicaría en staging por clave de negocio y tiempo de evento, verificaría como máximo un cambio aplicable por clave de destino y ejecutaría MERGE dentro de una transacción. Una tabla de estado actual utiliza actualizaciones en coincidencias e inserciones en no coincidencias; una tabla SCD Tipo 2 cierra la versión anterior e inserta una nueva. Las eliminaciones y reejecuciones necesitan una semántica explícita. Cada lote registra su instantánea de entrada y verificaciones, y una falla revierte los cambios y reintenta la misma instantánea”.
Análisis detallado paso a paso
Definir la semántica del destino
Separa una instantánea actual del historial. La tabla actual requiere el estado más reciente; SCD Tipo 2 necesita valid_from, valid_to, is_current y restricciones de versión.
Construir primero un staging auditable
Conserva el archivo de origen, el ID de lote, la hora de lectura y el hash de fila. Deduplica por clave de negocio, tiempo de evento y prioridad de origen; pon en cuarentena los empates que no se puedan resolver.
Diseñar coincidencias y acciones
Usa una clave de negocio estable en el predicado de coincidencia, no atributos mutables. Especifica actualizaciones para coincidencias, inserciones para no coincidencias y cualquier política de eliminación para registros no coincidentes por el origen, de modo que los datos tardíos no se eliminen accidentalmente.
Manejar SCD Tipo 2
Cierra la fila actual antes de insertar una versión modificada; el contenido idéntico no debe crear una versión. Garantiza que cada clave tenga una sola fila actual mediante una restricción o una consulta de calidad.
Garantizar reejecuciones y transacciones
El ID de lote y una instantánea de entrada congelada hacen que una ejecución sea repetible. Coloca MERGE, la auditoría y el estado del lote en una sola transacción; reintenta los mismos datos de staging en lugar de volver a leer archivos en constante cambio.
Monitorear y revertir
Compara los recuentos de inserción, actualización y eliminación de origen y destino; verifica claves huérfanas, filas actuales duplicadas y tiempos invertidos. Mantén una instantánea previa o una ruta de reconstrucción y revierte por lote ante cualquier anomalía.
Respuesta modelo
Llevaría los archivos Parquet a staging con metadatos de lote, deduplicaría por clave de negocio y tiempo de evento, y aplicaría filtros según recuentos de filas, valores nulos y ratios de eliminación. La tabla actual utiliza una actualización/inserción con clave estable; la tabla de historial cierra las versiones modificadas e inserta nuevas para que cada clave tenga una sola fila actual. MERGE, la auditoría y el estado del lote comparten una transacción, y las fallas reintentan la misma instantánea. Monitoreo deltas por lote y versiones duplicadas, y revierto o reconstruyo por lote cuando sea necesario.
Errores comunes
Fusionar archivos sin procesar directamente
Las filas de origen duplicadas pueden hacer que los resultados sean ambiguos o que se actualicen dos veces; primero realiza el staging, la deduplicación y los filtros de calidad.
Coincidir sobre columnas mutables
Un cliente renombrado puede parecer una clave nueva. Haz la coincidencia sobre un identificador de negocio estable.
Insertar únicamente para SCD Tipo 2
Las versiones antiguas permanecen actuales y las consultas devuelven múltiples filas actuales. Mantén la validez y la unicidad.
Volver a leer archivos en un reintento
Los archivos pueden haber cambiado o pueden haber aparecido archivos nuevos. Congela la instantánea de entrada y el ID de lote.
Preguntas de seguimiento
¿Qué pasa si llegan dos eventos diferentes para una misma clave al mismo tiempo?
Elige uno con una regla explícita de tiempo de evento, versión o prioridad de origen; de lo contrario, ponlo en cuarentena en lugar de sobrescribir silenciosamente.
¿Cómo manejas una eliminación tardía?
Compara el tiempo de evento de la eliminación con la versión de destino, registra un tombstone y evita que una eliminación antigua sobrescriba una actualización más reciente.
¿Cómo demuestras que un MERGE fallido no se confirmó parcialmente?
Mantén MERGE, la auditoría y el estado del lote en una sola transacción; inspecciona los recuentos y el estado del destino tras una falla y luego reintenta la misma instantánea de staging.
¿Cuándo evitarías MERGE?
Para reemplazos casi totales, coincidencias complejas o transacciones entre diferentes sistemas, construye una tabla nueva e intercámbiala atómicamente para reducir la incertidumbre en las acciones sobre las filas.