Guía de entrevista para Data Engineers

Enfoque — Función de ventana con orden determinista

Asignaría un número de fila con row_number() over (partition by event_id order by updated_at desc, ingestion_at desc, source_sequence desc) y conservaría el rango uno. El orden debe ser determinista; updated_at por sí solo suele ser insuficiente cuando hay empates. Antes confirmaría que event_id es la clave de negocio y que las actualizaciones posteriores pueden sustituir a eventos anteriores. Para el procesamiento incremental, gestionaría datos tardíos mediante una ventana retrospectiva o MERGE y escribiría de forma idempotente. Mediría duplicados, claves nulas y conflictos en lugar de descartarlos silenciosamente.

Enfoque — Actividad válida → fecha → usuarios únicos → partición incremental

Primero definiría qué eventos representan actividad y qué usuarios de prueba, bots o internos deben excluirse. Después normalizaría event_at a la zona horaria y fecha acordadas y contaría user_id distintos por día. La transformación se prepara para producción mediante escritura particionada por event_date, repetición idempotente, tratamiento de eventos tardíos y controles de calidad. Compararía volúmenes de origen y destino, vigilaría saltos anómalos y documentaría la definición y la actualidad de los datos.

Enfoque — Acotar el cambio → plan de ejecución → volumen → joins y filtros → recursos

Primero determinaría cuándo comenzó la degradación y si cambiaron código, esquema, volumen, distribución, estadísticas, particiones o recursos del warehouse. Después compararía planes de ejecución en busca de escaneos completos, estrategias de join deficientes, spill, skew o ausencia de partition pruning. Revisaría crecimiento de filas, cardinalidad y granularidad de joins; un nuevo one-to-many puede multiplicar los datos. Las mejoras pueden incluir filtros y agregaciones tempranos, otro orden de joins, particiones o clustering adecuados, estadísticas actualizadas y más recursos. Mediría tiempo, bytes leídos, shuffle y coste antes y después.

Enfoque — Procesos empresariales → hechos → dimensiones → granularidad → métricas

Empezaría por navegación, carrito, pedidos, pagos, envíos, devoluciones, reembolsos, existencias y atribución. Los posibles hechos incluyen fact_orders por pedido, fact_order_items por línea, fact_payments, fact_refunds, fact_shipments e instantáneas diarias de inventario. Las dimensiones abarcan cliente, producto, fecha, almacén, canal y campaña. Definiría expresamente cada granularidad. Los ingresos por categoría proceden de líneas; el ciclo de vida, de clientes o suscripciones; el inventario, de instantáneas. También consideraría cambios históricos de atributos, cancelaciones, descuentos por pedido o línea, divisas, impuestos, compras como invitado y datos tardíos. Validaría contra Finanzas y los sistemas de transacciones, pagos y almacén.

Enfoque — Tipo 1 o tipo 2 según la necesidad de histórico

El tipo 1 sobrescribe los valores anteriores y sirve cuando solo importa el estado actual. El tipo 2 crea una nueva fila de dimensión para cada cambio, con inicio de vigencia, fin de vigencia, current_flag y clave sustituta. Si un cliente pasa de la región Oeste a la Este, el tipo 1 reasigna también los ingresos históricos. El tipo 2 conserva la región que correspondía en cada momento y enlaza los hechos con la versión válida en la fecha del evento. Esto añade complejidad en claves, joins temporales, hechos tardíos y vistas actuales frente a históricas. La necesidad empresarial debe decidir el enfoque.

Enfoque — Gobernanza y flexibilidad frente a sencillez y rendimiento de consulta

Un esquema en estrella separa hechos y dimensiones. Favorece dimensiones reutilizables, métricas coherentes, granularidad clara y análisis flexibles con menos duplicación. Las tablas amplias funcionan bien para cuadros muy usados, casos analíticos concretos o features de ML cuando prima consultar con sencillez y rapidez, pero pueden duplicar datos y fomentar definiciones contradictorias. A menudo, la mejor solución combina hechos y dimensiones canónicos con data marts o tablas amplias para consumidores concretos. Deciden el volumen, los usuarios, la herramienta de BI, el coste, la latencia y la frecuencia de cambio.

Enfoque — Extraer → guardar datos brutos → transformar → validar → publicar → monitorizar

Aclararía actualidad, volumen, carga admisible en el origen, consumidores y correcciones posteriores. Extraería pedidos incrementalmente mediante updated_at o CDC, conservaría una copia inmutable en object storage o una tabla raw, limpiaría en staging y publicaría fact_orders y fact_order_items. Un orquestador gestionaría las dependencias. Los reintentos deben ser deterministas mediante MERGE, sustitución de particiones o intercambio atómico. Una ventana retrospectiva capturaría cambios tardíos. Los controles abarcarían filas, claves nulas, ID duplicados, ingresos, estados, actualidad y conciliación con origen. Las alertas cubrirían fallos, volúmenes anómalos, duplicados y retrasos; responsables y dependencias estarían documentados.

Enfoque — La misma entrada y repetición producen la misma salida

Un pipeline idempotente puede ejecutarse varias veces con la misma entrada y producir siempre el mismo estado correcto, sin duplicados ni efectos secundarios inesperados. Es esencial para reintentos y backfills. Un proceso no idempotente añadiría de nuevo los pedidos de ayer en cada ejecución. Una variante robusta sustituye la partición de destino, ejecuta MERGE por clave primaria o escribe primero en una ubicación temporal y realiza un intercambio atómico. Para ello necesita claves únicas, particiones adecuadas, transformaciones deterministas y efectos secundarios controlados.

Enfoque — Detectar → clasificar → proteger → comunicar → migrar

Detectaría los cambios mediante un registro, comprobaciones de metadatos, pruebas de contrato o validación de ingesta, y los clasificaría como columna añadida, eliminada o renombrada, cambio de tipo, nulabilidad o significado. Una columna nullable suele ser compatible; renombrar, eliminar o cambiar tipos puede romper consumidores. Los cambios semánticos son especialmente peligrosos porque el esquema puede seguir siendo válido. Conservaría los datos brutos y aplicaría contratos y compatibilidad en fuentes críticas. Ante un cambio incompatible, coordinaría al responsable de origen, versionaría el esquema, adaptaría transformaciones, reconstruiría histórico si fuera necesario y avisaría a los consumidores afectados a partir del linaje.

Enfoque — Latencia de decisión frente a complejidad

Streaming tiene sentido cuando una baja latencia aporta valor real, por ejemplo en detección de fraude, alertas operativas, personalización, actualización de existencias o funciones basadas en eventos recientes. Para informes diarios, análisis históricos, conciliaciones financieras y transformaciones horarias, batch suele ser más sencillo, barato y fácil de reproducir. La decisión depende de actualidad, volumen, orden, procesamiento con estado, tolerancia a fallos, experiencia del equipo, coste y consumidores. Streaming añade trabajo para duplicados, eventos tardíos, checkpoints, esquemas y monitorización. Elegiría la arquitectura más sencilla que cumpla la necesidad empresarial.

Enfoque — Eventos → flujo → enriquecimiento → reglas o modelo → acción → almacenamiento → monitorización

Aclararía volumen, objetivo de latencia, tipo de decisión, falsos positivos tolerables y si una transacción se bloquea o revisa. Los eventos de pago entrarían en Kafka o Kinesis. Un procesador validaría el esquema, deduplicaría por event_id, añadiría atributos de usuario, dispositivo, comercio y velocidad, y aplicaría reglas o un modelo. Un riesgo alto provocaría bloqueo, autenticación adicional o revisión manual. Los eventos y decisiones se guardarían para auditoría y entrenamiento. Son críticos el orden, los duplicados, la actualidad de features, el tamaño del estado, backpressure, dead-letter queue, replay, latencia y versionado. Códigos de motivo, seguimiento de falsos positivos y rollback protegen a clientes y operaciones.

Enfoque — Redistribución de datos entre particiones

Un shuffle aparece cuando Spark redistribuye datos entre particiones para groupBy, join, distinct, orderBy o repartition. Exige transferencia de red, serialización, E/S de disco y coordinación. Un resultado intermedio grande o una clave muy frecuente puede ralentizar algunas tareas o agotar memoria. Reduciría shuffles con filtros tempranos, solo las columnas necesarias, preagregación, broadcast joins para tablas pequeñas, particiones adecuadas, salting ante skew y evitando distinct u orderBy innecesarios. En Spark UI revisaría etapas, shuffle read y write, spill, duración de tareas y memoria de ejecutores.

Enfoque — Localizar etapa → reducir datos → corregir skew → ajustar particiones → eliminar operaciones problemáticas

Utilizaría Spark UI y los logs para localizar etapa, operación, partición y ejecutor. Las causas pueden ser skew, joins grandes, collect(), particiones excesivas, UDF ineficientes o demasiados datos en caché. Filtraría y proyectaría pronto, usaría partition pruning, revisaría broadcast joins, aplicaría salting a claves frecuentes y ajustaría el número de particiones. Sustituiría collect() grandes y UDF de Python cuando bastaran funciones nativas, y solo almacenaría en caché datos reutilizados. Aumentar memoria puede ayudar, pero mejorar el reparto y el plan es más sostenible que ampliar el clúster sin más.

Enfoque — Formato columnar, esquema, compresión y predicate pushdown

Parquet almacena por columnas, conserva tipos y esquema, comprime con eficiencia y permite column pruning y predicate pushdown. Como las consultas analíticas suelen leer pocas columnas, escanean menos datos. CSV es texto portable, pero carece de tipos, ocupa más, es más lento y sufre problemas de separadores y escape. Puede ser adecuado para exportaciones pequeñas e intercambio, pero Parquet suele ser más rápido y barato como formato principal en data lakes o warehouses.

Enfoque — Actualidad → integridad → unicidad → validez → conciliación

Comprobaría actualidad, volumen de filas, nulos en claves primarias, transacciones duplicadas, estados y divisas válidos, importes y fechas admisibles, e integridad referencial entre pedidos, pagos, reembolsos y clientes. También conciliaría ingresos con el sistema de pagos o Finanzas y vigilaría desviaciones frente al día y semana anteriores, teniendo en cuenta la estacionalidad. Las reglas deben excluir pruebas y cancelaciones, restar reembolsos de los ingresos netos y convertir divisas correctamente. Cada alerta necesita responsable, acción, tabla afectada, gravedad, impacto downstream y runbook.

Enfoque — Evaluar impacto → comparar versiones → seguir linaje → mitigar → corregir causa

Primero aclararía cuadro, métrica, usuarios, periodo y decisiones afectadas, y si la cifra nueva es incorrecta o corrige un error anterior. Compararía salida antigua y nueva por tabla, partición, filas, valores únicos, totales y segmentos, y seguiría los cambios por el linaje. Revisaría código, esquema, filtros, joins, deduplicación y fechas. Si la cifra es incorrecta, revertiría la transformación o versión de tabla, desactivaría o etiquetaría la vista y reconstruiría después los datos correctos. Comunicaría impacto, nivel de confianza, plazo estimado y si deben revisarse decisiones anteriores.

Enfoque — Instrumentación → ingesta → almacenamiento → procesamiento → modelado → serving → gobernanza

Aclararía volumen, latencia, consumidores, retención, evolución del esquema, privacidad y fiabilidad. Los clientes enviarían eventos tipados mediante un SDK con event_name, ID de usuario y sesión, marca de tiempo, propiedades, versión de aplicación y plataforma. Un collector escribiría en un flujo duradero y guardaría eventos brutos en object storage para replay y en un warehouse o lakehouse para analítica. El procesamiento validaría esquemas, deduplicaría, filtraría bots y usuarios internos, crearía sesiones y resolvería identidades. De ahí surgirían fact_events, fact_sessions, dim_users y data marts. Contratos, schema registry, normas de PII y consentimiento, linaje, responsables y alertas de actualidad y volumen protegerían la plataforma. El serving abarcaría BI, experimentos, reverse ETL y feature stores.

Enfoque — Coherencia offline/online → definiciones → actualidad → serving → monitorización

Un feature store ofrece features reutilizables y fiables para entrenamiento y serving. Las features offline se guardan por fecha y entidad en el warehouse o lakehouse; las online, en un almacén clave-valor de baja latencia. Un registro documenta nombre, responsable, clave de entidad, transformación, SLA de actualidad, fuentes y descripción. La point-in-time correctness impide que el entrenamiento use información futura. Las transformaciones online y offline deben compartir lógica o compararse con pruebas estrictas. La monitorización cubre actualidad, nulos, drift de distribución, latencia de serving, training-serving skew e impacto del modelo; la gobernanza controla PII, linaje, permisos y retirada.

Enfoque — Impacto → triaje → mitigación → causa → prevención

Elegiría un incidente con impacto real: datos ausentes, métricas incorrectas, duplicados, un cuadro roto o una función afectada. Primero explicaría quién sufrió el impacto y por qué importaba. Después describiría el triaje mediante logs, orquestador, actualidad de fuentes, despliegues, esquemas, filas, particiones y linaje, y la mitigación mediante reintento, rollback, parche, backfill o advertencia. La respuesta más sólida termina con prevención: controles de calidad, alertas, contratos, escrituras idempotentes, runbooks, linaje o despliegues más seguros. Debe demostrar responsabilidad y comunicación, no buscar culpables.

Enfoque — Aclarar → reproducir → seguir linaje → resolver → documentar

Concretaría métrica, tabla, periodo, filtros, valor esperado y razonamiento empresarial. Después reproduciría la consulta y revisaría granularidad, filtros, joins, zona horaria, actualidad, definición y cambios recientes a lo largo del linaje. Si los datos son incorrectos, los corregiría y comunicaría el impacto. Si la técnica es correcta pero la definición difiere, acordaríamos la definición empresarial y la documentaríamos. Si persiste la incertidumbre, explicaría qué sabemos, qué se está comprobando y cuándo responderemos. Las respuestas rápidas y basadas en pruebas generan confianza.

Enfoque — Impacto → fiabilidad → urgencia → dependencias → efecto multiplicador

Priorizaría por impacto empresarial, riesgo de fiabilidad, urgencia, dependencias downstream y efecto multiplicador. Un pipeline de ingresos roto o un riesgo de cumplimiento supera a un modelo opcional; una mejora de plataforma puede aportar más que muchas solicitudes aisladas. Separaría incidentes, trabajo estratégico de plataforma, peticiones, deuda técnica y carga operativa. Un proceso equilibrado utiliza responsables, SLA, gravedad, hoja de ruta y compensaciones transparentes, y deja claro qué se aplaza y qué riesgo supone.