Las entrevistas de data engineering se apoyan fuerte en SQL y en si tus pipelines sobreviven ser corridos dos veces, tarde, o fuera de orden. Espera preguntas de modelado sin una única respuesta correcta. Aquí están las preguntas hechas más a menudo, cada una con una respuesta modelo. Middle: comprensión más profunda, optimización y situaciones reales de trabajo.
1
¿Cuál es la diferencia entre formatos orientados a filas y columnares?
Respuesta
Los formatos de fila como CSV o Avro almacenan un registro junto, lo que conviene para escribir y leer registros completos. Los formatos columnares como Parquet y ORC almacenan cada columna junta, así que una consulta que toca tres de cincuenta columnas lee solo esas tres. Columnar también comprime mucho mejor, porque una columna tiene valores similares. El trade-off es que escribir una sola fila es costoso, por eso columnar es para analytics y no para transacciones.
2
¿Qué significa que un batch job sea idempotente, y cómo haces uno de insert?
Respuesta
Idempotente significa que correrlo dos veces deja el mismo resultado que correrlo una vez — lo cual importa porque los reintentos pasan, ya sea de un scheduler, un fallo o un humano. Para un insert, las respuestas usuales son un merge o upsert en una clave de negocio, borrar la partición destino antes de escribirla, o una constraint única que hace que el duplicado falle inofensivamente. Un INSERT plano en un job reintentado duplica los datos silenciosamente.
3
¿Cuál es la diferencia entre un star schema y un snowflake schema?
Respuesta
En un star, las dimensiones están desnormalizadas en tablas únicas unidas directamente al hecho. En un snowflake, las dimensiones están normalizadas en tablas adicionales. El star necesita menos joins y es más rápido de consultar; el snowflake ahorra storage y evita anomalías de actualización. Analytics usualmente elige el star, porque el storage es barato y el tiempo del analista no.
4
¿Qué es lazy evaluation en Spark, y cuál es la diferencia entre una transformación y una acción?
Respuesta
Las transformaciones — map, filter, join — construyen un plan y no ejecutan nada. Una acción — count, collect, write — dispara todo el plan. La laziness deja al optimizador ver toda la cadena y reordenarla, empujando filtros hacia abajo y colapsando pasos. La consecuencia práctica es que cronometrar una transformación no mide nada, y el error que esperabas en la línea tres aparece en la acción.
5
¿Cuál es la diferencia entre una dependencia amplia y una angosta, y por qué importa?
Respuesta
En una dependencia angosta cada partición de entrada alimenta una partición de salida — un map o filter, computable en el nodo que tiene los datos. Una dependencia amplia requiere datos de muchas particiones, lo que significa un shuffle a través de la red. Los shuffles dominan el runtime de la mayoría de los jobs, así que un groupBy o un join es donde miras primero cuando algo está lento.
6
¿Cuándo usarías un broadcast join?
Respuesta
Cuando un lado es lo bastante pequeño como para caber en la memoria de cada executor — una tabla de dimensión contra una tabla de hechos grande. Hacerle broadcast elimina el shuffle por completo, que usualmente es la diferencia entre minutos y horas. El límite es la memoria: haz broadcast de algo demasiado grande y cada executor lo paga, así que el umbral es una configuración que vale la pena conocer en vez de adivinar.
7
¿Qué es Change Data Capture y cuándo lo usas en vez de una recarga completa?
Respuesta
CDC lee el propio log de cambios de la base de datos fuente y transmite inserts, updates y deletes en vez de releer toda la tabla. Lo usas cuando la tabla es lo bastante grande como para que una recarga completa no quepa en la ventana, o cuando necesitas los cambios en sí — deletes en particular, que una comparación de snapshot completo detecta solo por ausencia.