Entrevista de Ingeniería de Datos: ¿Cómo depuras números incorrectos en un dashboard?

Consigna y contexto aplicable

Tras el despliegue de un pipeline de datos, el dashboard de ingresos diarios muestra un 8% más que la conciliación del procesador de pagos para el mismo día hábil. La ingesta de eventos es at-least-once, los reembolsos pueden llegar con retraso y finanzas cierra los libros en dos horas. Explica cómo confirmarías el impacto, localizarías la causa raíz, evitarías que los datos erróneos se propaguen, repararías los datos afectados y demostrarías que el dashboard vuelve a ser confiable.

El 8%, el plazo de dos horas, la entrega at-least-once y la hora de despliegue son supuestos para la entrevista, no estándares de la industria. La ruta principal asume este linaje: origen de eventos de pago, capa raw, capa staging, tabla de hechos de ingresos, capa semántica y caché de BI. El procesador de pagos es un comparador candidato, no automáticamente la fuente de verdad absoluta. Si este agrupa por fecha de liquidación mientras que el dashboard agrupa por fecha del evento de pago, ambas salidas pueden ser correctas y aun así diferir.

Los materiales públicos de entrevistas de ingeniería de datos para 2026 incluyen directamente la consigna “el dashboard muestra números incorrectos” y listan calidad de datos, linaje, backfills, SLAs, respuesta a incidentes y ownership como temas de preparación. La categoría es data porque las habilidades fundamentales son la semántica de métricas, linaje de datos, aserciones de calidad, conciliación y backfills seguros. La pregunta no solicita el diseño completo de una plataforma entre múltiples componentes.

Qué evalúa el entrevistador

La primera señal es si el candidato distingue entre “números diferentes” y “datos erróneos”. Volver a ejecutar un job de inmediato puede escribir el mismo defecto otra vez. Una respuesta sólida primero fija el día hábil, la zona horaria, la moneda, los estados de las órdenes y si los ingresos significan autorización, captura, liquidación o el monto neto después de reembolsos. Solo entonces el candidato puede decidir si la brecha del 8% es un incidente de calidad o una discrepancia semántica.

La segunda señal es si se utiliza el linaje para encontrar el primer límite erróneo. Editar el SQL final del dashboard no explica cómo ingresó el defecto al sistema. Un diagnóstico útil compara conteos, montos y estados para las mismas claves de negocio en el origen, la capa raw, la capa staging, la tabla de hechos, la capa semántica y la caché. El objetivo es la transición donde la parte upstream sigue siendo correcta y la parte downstream pasa a ser incorrecta por primera vez.

La tercera señal es el control de incidentes. Con finanzas a punto de cerrar, el candidato debe reducir el tiempo de recuperación sin generar una segunda corrupción mediante una corrección no verificada. Eso implica marcar el dashboard como no seguro para el cierre, pausar exportaciones o sincronizaciones inversas que utilicen los datos erróneos, preservar las entradas raw inmutables y realizar el backfill en una tabla shadow o partición versionada.

Por último, el entrevistador busca un ciclo de evidencia cerrado. Un job exitoso, conteos de filas idénticos o un dashboard que “parece normal” no demuestran la recuperación. Una respuesta sólida combina conciliación de semántica de negocio, validaciones de claves y cardinalidad de joins, diffs para los cortes afectados, auditorías de registros críticos y la aprobación de finanzas antes de restaurar el consumo.

Preguntas para clarificar antes de responder

• ¿Ambas partes definen los ingresos de manera idéntica? Alinea el tratamiento de autorización, captura, liquidación, reembolso, contracargo, impuestos, tarifas y órdenes canceladas. Si las definiciones difieren, primero construye una vista comparable en lugar de calificar la brecha esperada como un incidente.
• ¿Qué reloj y zona horaria definen el día hábil? UTC, la hora local del comercio y la fecha de liquidación del procesador pueden delimitar fronteras distintas. La respuesta cambia las particiones afectadas y el plan de reparación.
• ¿El 8% es una brecha de montos, una brecha de conteos o una brecha específica de un corte? Conteos normales con exceso de valor sugieren eventos duplicados de alto valor, cambio de divisas o multiplicación por joins (fanout). Conteos en exceso hacen que la reejecución y la deduplicación sean verificaciones de mayor prioridad.
• ¿Qué cambió y cuándo entró en vigor? Vincula la versión del código, el ID de ejecución del job, los datasets de entrada y salida, y la primera hora anómala. El momento del despliegue constituye una hipótesis útil, no una prueba que justifique un rollback inmediato.
• ¿Los eventos raw son inmutables y cuentan con un event_id estable? De ser así, el equipo puede reconstruir un día hábil de forma idempotente. Si no, la recuperación requiere un libro mayor (ledger) o snapshot upstream y un límite explícito sobre lo que no se puede reconstruir con exactitud.
• ¿Cuándo maduran los reembolsos y los tipos de cambio? Si el dashboard promete una estimación casi en tiempo real mientras que la conciliación incluye reembolsos completos solo en T+1, muestra los valores preliminares y finales por separado y define una ventana de corrección.
• ¿Qué consumidores dependen de la tabla? Las exportaciones de finanzas, dashboards ejecutivos, alertas, features de machine learning y reverse ETL conllevan riesgos diferentes, por lo que la contención debe seguir el impacto de negocio.
• ¿Cuál es la versión confiable actual? Un snapshot o partición validada previa al despliegue puede servir temporalmente como una vista conocida en buen estado con marca de tiempo. Si no existe, muestra un estado degradado en lugar de entregar números obsoletos silenciosamente.

Estructura de respuesta de 30 segundos

“Primero congelaría este dashboard para el cierre financiero y pausaría las exportaciones downstream afectadas mientras preservo los eventos raw. Luego alinearía la definición de ingresos, día hábil, moneda y ventana de reembolsos para confirmar que la brecha del 8% sea un defecto de calidad real. Usando los metadatos del despliegue y el linaje, avanzaría desde la consulta del dashboard a través de la capa semántica, tabla de hechos y capa de staging hasta los eventos raw, comparando conteos de eventos únicos, montos netos y estados de claves en cada límite. La primera divergencia identifica el dominio del fallo. Reconstruiría las particiones afectadas de forma idempotente en una tabla shadow utilizando IDs de eventos estables. Tras verificar que la conciliación source-to-target, las comprobaciones de cardinalidad de joins, los cortes críticos y las muestras de finanzas pasen con éxito, cambiaría atómicamente la versión y refrescaría las cachés. Finalmente, incluiría la definición de la métrica, el owner, las aserciones, la identidad del despliegue y las alertas en el contrato de datos y el runbook.”

Respuesta detallada paso a paso

Paso 1: Establecer hechos que puedan determinar el incidente.

Registra la hora de detección, el primer día hábil afectado, la versión del despliegue, los dashboards afectados y el plazo de cierre. Divide el “8% de más” en al menos cuatro cantidades reproducibles: conteo de eventos, conteo de órdenes, monto capturado y monto neto después de reembolsos. Segmenta por moneda, región, estado del pago y hora. Ejecuta la consulta del dashboard directamente para eludir la caché del navegador, luego ejecuta el SQL generado por la capa semántica. Si el SQL es correcto pero la página es errónea, el defecto reside en los filtros, la caché o la presentación; no hagas un backfill de la tabla de hechos.

Escribe la métrica como una ecuación explícita. Para este escenario, el ingreso neto puede definirse como el monto capturado exitoso menos los reembolsos y contracargos confirmados para el mismo día hábil y moneda. Si las tarifas, impuestos o ganancias por tipo de cambio pertenecen a los ingresos, agrégalos explícitamente. No cambies la definición a mitad de la investigación para hacer desaparecer la brecha. Mapea el reporte de liquidación del procesador a la misma semántica de estados y tiempos antes de tratarlo como un comparador.

Paso 2: Contener el impacto y preservar la evidencia.

Marca el dashboard como “bajo validación de datos”, con la última marca de tiempo confiable y la hora de la próxima actualización. Informa a finanzas que no cierre utilizando la partición afectada. Pausa exportaciones, reportes y sincronizaciones inversas que propagarían el monto erróneo. Si las particiones previas al despliegue ya están validadas, aísla solo el día hábil afectado en lugar de dejar fuera de línea todo el historial.

No elimines eventos raw, no sobrescribas la tabla actual ni trunques inmediatamente una partición. Preserva los logs de jobs, IDs de ejecución, versiones de código, versiones de datasets, particiones de entrada y aserciones fallidas. El modelo de Job, Run y Dataset de OpenLineage demuestra por qué esos identificadores deben estar unidos: saber qué ejecución leyó qué entradas y produjo qué salidas es lo que permite que el radio de impacto y la reparación delimitada sean reproducibles.

Paso 3: Rastrear el linaje hasta el primer límite erróneo.

Para el mismo día hábil y las mismas claves de negocio, construye esta lista de verificación de downstream hacia upstream:

Utiliza el mismo día hábil, moneda y conjunto de estados en cada capa. Compara primero los agregados, luego haz un anti-join de las diferencias y toma muestras de claves de negocio. El primer límite con una discrepancia reduce “cualquier parte del pipeline” a una sola transformación o paso de transporte.

Las hipótesis candidatas tras un despliegue incluyen: una reejecución at-least-once que no se deduplica por event_id; un join de órdenes que genera fanout contra una dimensión de múltiples filas; reembolsos particionados por tiempo de procesamiento mientras las capturas usan el tiempo del evento; un lote completo reintentado después de que solo algunas particiones se completaron; un join de tipo de cambio que coincide con múltiples versiones válidas; o un nuevo estado asignado por defecto a los ingresos. Estas son hipótesis a refutar. Asigna a cada una una predicción, como “si un join de dimensión genera fanout, la amplificación ocurre solo para monedas con claves de dimensión duplicadas”, y pruébala antes de modificar el código.

Paso 4: Elegir el mecanismo de recuperación.

Si el defecto reside solo en la caché, invalida las claves relevantes y verifica la nueva consulta. Si la fórmula semántica es incorrecta, versiona la corrección y verifica cada dashboard que consuma la métrica. Si la tabla de hechos está corrupta, identifica las particiones afectadas más pequeñas y las entradas confiables, luego reconstruye en una tabla shadow o nueva versión de datos:

1. Deduplica mediante el event_id inmutable; cuando un evento tenga versiones, aplica una regla explícita de versionado o transición de estados.
2. Asocia reembolsos, contracargos y monedas por clave de negocio para que las ejecuciones repetidas devuelvan el mismo resultado.
3. Delimita el backfill y regula la carga del data warehouse para que los jobs incrementales normales continúen de forma segura.
4. Ejecuta comprobaciones estructurales, de negocio y de conciliación en la salida shadow en lugar de sobrescribir producción directamente.
5. Tras la validación, cambia atómicamente la versión de la vista o tabla, refresca las cachés de BI y reanuda los jobs downstream.

Si los datos raw contienen duplicados pero existen claves estables, reconstruye desde raw. Si faltan eventos críticos y el upstream dispone de un ledger o snapshot, extrae nuevamente desde ese origen. Si no existe una fuente recuperable, no afirmes una reparación exacta. Proporciona a finanzas el alcance confirmado, la diferencia no explicada y el plan de ajuste.

Paso 5: Demostrar la recuperación con tres clases de comprobaciones.

Las comprobaciones estructurales cubren esquema, valores no nulos, unicidad, valores aceptados e integridad referencial. dbt documenta unique, not_null, accepted_values y relationships como pruebas de datos genéricas integradas. Estas detectan claves duplicadas, claves nulas, estados desconocidos y registros huérfanos, pero no reemplazan la conciliación de negocio.

Las comprobaciones de negocio aplican invariantes de métricas: un reembolso no puede deducirse dos veces, el monto neto de una orden no puede exceder su monto capturado exitoso y unir la tabla de hechos no debe incrementar inesperadamente el número de claves de órdenes. La conciliación compara conteos y montos de origen y shadow por día hábil, moneda y estado, examinando luego la diferencia a nivel de registro. Totales iguales son insuficientes porque un sobreconteo y una omisión pueden anularse mutuamente.

Define las compuertas de recuperación por adelantado: cada aserción estricta (hard assertion) para los cortes afectados pasa con éxito; cada diferencia source-to-target se explica por la semántica, la ventana de llegada tardía o una excepción registrada; las muestras de capturas, reembolsos y órdenes multimoneda se rastrean de extremo a extremo; y finanzas confirma la definición de cierre. Observa al menos un ciclo incremental normal para asegurar que la siguiente ejecución no recree el defecto.

Paso 6: Convertir el modo de falla en una barrera de protección (guardrail).

Un contrato de datos debe contener esquema, semántica de campos, día hábil, moneda, mapeo de estados, umbrales de calidad, objetivos de servicio, owners y rutas de escalamiento. Data Contract CLI documenta contratos legibles por máquina que combinan estructura, semántica, calidad y niveles de servicio, y que pueden verificarse en CI o contra datos reales.

Ubica cada verificación en el límite útil más temprano: comprobaciones de esquema y clave primaria en la ingesta, cardinalidad de joins e invariantes de negocio tras la transformación, y frescura, completitud y conciliación de origen antes de la entrega. Trata la frescura y la corrección por separado; una tabla entregada a tiempo pero un 8% por encima sigue siendo un fallo. Adjunta la versión del código, el ID de ejecución y la versión de los datos de salida a los metadatos del despliegue. Ejecuta particiones críticas en modo shadow y compara los datos antes de redirigir a los lectores.

Las alertas deben ser accionables: nombrar el dataset, día hábil, regla fallida, valor real, umbral, impacto downstream y owner. Una tabla exploratoria de bajo riesgo puede continuar tras una advertencia; una tabla de ingresos financieros debe bloquear la publicación ante fallas de claves o conciliación. Añade un runbook de backfill tras el incidente y ensaya duplicados, reembolsos tardíos, cambios de esquema, escrituras parciales y fanout de joins para demostrar que la recuperación en sí misma es idempotente.

Respuesta de ejemplo de alta calidad

“No volvería a ejecutar el pipeline como primera medida. La brecha del 8% puede ser semántica, y una reejecución puede amplificar el mismo defecto de escritura. Notificaría a finanzas que detenga el uso del día hábil afectado para el cierre, marcaría la última hora confiable, pausaría las exportaciones de la partición defectuosa y preservaría tanto los eventos raw como las salidas actuales para la investigación.

A continuación, alinearía el día hábil, la zona horaria, la moneda y el estado en ambos lados y determinaría si los ingresos significan el monto capturado o el monto neto después de reembolsos. Si el procesador reporta por día de liquidación mientras que el dashboard reporta por día de pago, primero construiría una vista comparable. Una vez confirmado el defecto, dividiría el 8% en órdenes, eventos, capturas y reembolsos, y luego segmentaría por hora, moneda, región y estado para encontrar cuándo y dónde comienza.

Rastrearía de forma ascendente desde la consulta del dashboard a través de la capa semántica, tabla de hechos, staging, capa raw y origen de pagos. En cada capa compararía conteos de eventos únicos, montos netos y diferencias de registros para las mismas claves de negocio, buscando el primer límite donde lo correcto pasa a ser erróneo y vinculándolo con el despliegue y el ID de ejecución del job. Conteos normales de órdenes en la tabla de hechos que aumentan tras un join semántico sugieren fanout. Eventos raw y de hechos duplicados sugieren falta de deduplicación tras una reejecución at-least-once. Si solo los reembolsos están bajos, sugiere problemas en el manejo del tiempo del evento, tiempo de procesamiento o ventana de retraso.

Reconstruiría solo las particiones afectadas en una tabla shadow. La deduplicación utiliza IDs de eventos inmutables, y las reglas de reembolsos y transiciones de estado deben garantizar que backfills repetidos devuelvan el mismo resultado. La tabla shadow debe superar las comprobaciones de claves, no nulos, estado, integridad referencial, cardinalidad de joins e invariantes de negocio. Luego conciliaría el origen y la salida por día hábil, moneda y estado e inspeccionaría las diferencias de registros. Solo después de que finanzas dé su visto bueno cambiaría atómicamente las versiones, refrescaría las cachés, reanudaría los jobs downstream y monitorearía el siguiente ciclo incremental.

Finalmente, registraría la definición de ingresos, día hábil, moneda, ventana de corrección tardía, owner y ruta de escalamiento en el contrato de datos. Los límites de ingesta, transformación y entrega incorporan verificaciones de esquema, deduplicación, cardinalidad, frescura y conciliación de origen. Los futuros despliegues ejecutarán en shadow las particiones afectadas y bloquearán el cambio si fallan las aserciones estrictas.”

Errores comunes

• Hacer rollback solo porque la hora coincide con un despliegue → La correlación no prueba causalidad; la semántica o los datos upstream también pudieron haber cambiado → Confirma con el primer límite erróneo y la evidencia de versiones.
• Reejecutar todo el DAG de inmediato → Un job no idempotente puede duplicar escrituras y ampliar la corrupción → Contén primero, luego ejecuta un backfill acotado en una salida shadow.
• Tratar al procesador como verdad absoluta → El día de liquidación, las ventanas de reembolso y las definiciones de estado pueden diferir → Mapea ambos lados a la misma semántica de negocio.
• Comparar solo el monto total → Sobreconteos y omisiones pueden anularse mutuamente → Compara también claves, conteos, cortes y diferencias de registros.
• Comprobar únicamente si el job tuvo éxito → El éxito indica que el job finalizó, no que los datos sean correctos → Agrega aserciones estructurales, de negocio y de conciliación con el origen.
• Eliminar duplicados directamente en producción → Esto destruye evidencia e invalida un rollback seguro → Preserva los datos raw y reconstruye una salida versionada.
• Reparar la tabla de hechos sin refrescar la caché → Los usuarios seguirán viendo números viejos y asumirán que la reparación falló → Invalida las cachés relevantes tras el cambio validado.
• Equiparar frescura con calidad total → Los datos puntuales aún pueden estar duplicados o erróneos → Define frescura, completitud y corrección por separado.
• Enviar una alerta genérica para cada defecto → Un mensaje sin dataset, corte ni owner no permite tomar acciones → Incluye el valor real, el radio de impacto y la ruta de escalamiento.
• Declarar la recuperación inmediatamente después de la reparación → La siguiente ejecución incremental puede recrear el mismo defecto → Observa una ejecución normal y pon a prueba el nuevo guardrail.

Preguntas de seguimiento y respuestas

Pregunta de seguimiento 1: Los totales coinciden, pero la conciliación a nivel de orden aún difiere. ¿Puedes restaurar el dashboard?

No basándote únicamente en los totales. Un sobreconteo en una orden y una omisión en otra pueden anularse mutuamente mientras que los cortes por cliente, región o impuestos siguen siendo erróneos. Continúa comparando órdenes únicas y diferencias de eventos, y explica cada clase por estado, moneda y relación de reembolsos. Los totales idénticos se convierten en una señal de recuperación solo después de que las llegadas tardías permitidas y las excepciones semánticas estén listadas y los consumidores críticos las aprueben.

Pregunta de seguimiento 2: Los eventos raw no tienen un event_id estable. ¿Cómo los deduplicarías?

Primero solicita un libro mayor (ledger) upstream, ID de transacción o snapshot reproducible. Una huella digital (fingerprint) construida a partir de hora, monto y usuario puede fusionar erróneamente dos pagos válidos. Si una clave compuesta es la única opción, especifica campos, tolerancia de tiempo y reglas de conflicto, mide fusiones falsas y fusiones omitidas en la tabla shadow, y mantén una cola de excepciones para revisión. Si no se puede probar la unicidad, comunica la incertidumbre restante en lugar de presentar la salida heurística como un registro exacto.

Pregunta de seguimiento 3: El backfill requiere seis horas, pero finanzas cierra en dos. ¿Qué haces?

Reduce el alcance según el impacto de negocio. Si la brecha del 8% se concentra en una sola moneda o en las dos horas posteriores al despliegue, prioriza esa partición y entrega a finanzas los datos validados previos al despliegue, el alcance afectado y el ajuste pendiente. Si el backfill aun así no llega al cierre, finanzas debe usar el procesador u otra conciliación temporal aprobada y registrar un ajuste posterior. No omitas la validación ni reemplaces toda la tabla con una salida no verificada para ganarle al reloj.

Pregunta de seguimiento 4: Un join de dimensión uno a muchos causó el error. ¿Cómo previenes la recurrencia?

Valida la unicidad de la clave de negocio de la dimensión y la existencia de intervalos de validez no superpuestos. Compara conteos de claves de hechos y conteos de filas antes y después del join, e impone una compuerta estricta de despliegue ante cualquier multiplicación inesperada por join. Si la dimensión debe conservar versiones históricas, el predicado del join necesita que el tiempo del evento esté dentro del intervalo válido; unir cada versión por clave de negocio es inválido. Realiza pruebas con marcas de tiempo límite y escenarios (fixtures) de versiones superpuestas.

Pregunta de seguimiento 5: Los reembolsos tardíos reescriben el historial a diario. ¿Cuándo es correcto el dashboard?

Define dos compromisos: visibilidad rápida y corrección final. Muestra un monto neto preliminar con marca de tiempo para el día actual y define una ventana de corrección de reembolsos. Los reembolsos tardíos dentro de esa ventana activan correcciones idempotentes; tras la ventana, publica una versión casi definitiva. Los reembolsos fuera de ella entran en un proceso independiente de ajuste y auditoría. El dashboard, el contrato de datos y las políticas de finanzas deben utilizar el mismo estado de madurez para que un número sujeto a revisión no se confunda con uno cerrado.