Entrevista de ingeniería de datos: ¿Cómo demuestras que el pushdown de campos anidados en DataFusion reduce el costo de escaneo?

Pregunta

DataFusion 53 puede enviar expresiones como get_field hacia una fuente de datos. ¿Cómo diseñarías consultas, planes y pruebas de rendimiento para demostrar un menor costo de E/S y decodificación sin alterar los resultados?

Contexto y límites

Supón que una tabla Parquet tiene una columna struct ancha s, mientras que la consulta solo necesita s['label'] y filtra por s['value']. Cubre escaneos por lotes, estadísticas, nulos, evolución del esquema y una alternativa segura (fallback) cuando el pushdown no aplique. No trates el hecho de que “la proyección aparezca en el plan” como evidencia de extremo a extremo.

Qué está evaluando el entrevistador

La habilidad consiste en separar la corrección semántica, la reescritura de planes, la capacidad de la fuente de datos y el beneficio observable. DataFusion 53 traslada el acceso a campos anidados más cerca del escaneo para que no sea necesario leer una estructura completa; su documentación de configuración describe que enable_leaf_expression_pushdown extrae get_field de expresiones de filtro, ordenamiento o unión y lo envía hacia los nodos hoja.

Aclara estos puntos primero:

• ¿La fuente admite proyección a nivel de campo y el formato de archivo es Parquet?
• ¿Cuáles son los tipos, la semántica de nulos y las reglas de campos faltantes para s['label'] y s['value']?
• ¿La línea base es la optimización deshabilitada, una versión anterior de DataFusion o una consulta que lee toda la estructura?
• ¿La comparación debe enfocarse en bytes de escaneo, CPU de decodificación, memoria máxima, latencia o solicitudes al almacenamiento de objetos?

Respuesta en 30 segundos

Comienza con SQL que contenga proyección y filtrado anidados. Luego compara los planes lógicos y físicos y la proyección del lector de Parquet antes y después de la optimización. Por último, utiliza datos idénticos, el mismo estado de caché y la misma concurrencia para medir los bytes escaneados, el tiempo de decodificación, la memoria máxima y las comprobaciones de resultados, indicando al mismo tiempo cuándo recurrir a la alternativa de respaldo.

Análisis detallado paso a paso

1. Construir los datos: crea archivos Parquet con particiones, grupos de filas y estadísticas idénticos mientras controlas el ancho de la estructura, la tasa de nulos y la selectividad de campo.
2. Definir las líneas base: mantén constantes la versión de DataFusion, el recuento de subprocesos, la latencia del almacenamiento de objetos y el estado de la caché para lecturas de estructura completa, pushdown deshabilitado y lecturas de campos hoja.
3. Inspeccionar los planes: confirma que get_field esté cerca del escaneo y que la proyección contenga solo id, s.label y el campo de filtro s.value; el texto de SQL por sí solo es insuficiente.
4. Observar la fuente: registra las columnas de Parquet leídas, el descarte de grupos de filas (row-group pruning), los bytes obtenidos y los lotes de decodificación, separando el beneficio de la proyección del beneficio de los predicados.
5. Comprobar los resultados: compara hashes ordenados o filas, cubriendo campos faltantes, nulos, cambios de tipo, estructuras vacías y filas duplicadas.
6. Definir la alternativa de respaldo: si la fuente carece de pushdown de campo, la reescritura es insegura o el beneficio está por debajo de un umbral, mantén la ruta correcta de lectura completa y registra el motivo.

Respuesta modelo

Construiría tres líneas base a partir de un conjunto de datos Parquet fijo: leer el s completo, deshabilitar enable_leaf_expression_pushdown y habilitar la optimización mientras se seleccionan los campos hoja. La consulta es:

SELECT id, s['label']
FROM events
WHERE s['value'] > 150;

Guardaría los planes lógicos y físicos y verificaría que get_field se sitúe cerca del escaneo y que la proyección de escaneo ya no incluya la totalidad de s. Ejecutaría múltiples iteraciones con caché fría y caché caliente, registrando bytes leídos, solicitudes al almacenamiento de objetos, CPU de decodificación de Parquet, memoria máxima, latencia de extremo a extremo y filas de salida. Compararía un hash ordenado y estable con la línea base de estructura completa, cubriendo explícitamente nulos, campos faltantes y esquemas nuevos y antiguos. Si la fuente no puede proyectar campos, mantendría la lectura completa y emitiría una métrica en lugar de sacrificar la corrección por un plan más atractivo. Antes del despliegue, los bytes de escaneo y los hashes de resultados se convertirían en compuertas de control de regresión.

Errores comunes

• Comparar solo la latencia de extremo a extremo sin controlar la caché, la concurrencia y la distribución de archivos.
• Combinar la proyección de campos, el pushdown de predicados y el descarte de grupos de filas en un único número sin explicar.
• Probar únicamente valores ordinarios e ignorar nulos, campos faltantes y la evolución del esquema.
• Declarar el éxito a partir de un plan reescrito sin verificar las columnas y los bytes que el lector realmente consumió.
• Forzar una reescritura cuando el pushdown falla en lugar de mantener una alternativa de respaldo que priorice la corrección.

Una respuesta sólida conecta el SQL, el plan, la fuente y las métricas; proporciona una línea base reproducible y una comprobación de resultados; y explica la atribución y la alternativa de respaldo. Una respuesta débil solo dice que “el pushdown de proyección es más rápido” sin controles experimentales ni evidencia de corrección.

Preguntas de seguimiento y respuestas

¿Por qué las lecturas de campos hoja podrían no mostrar ningún beneficio?

El archivo puede estar orientado a filas, la estructura puede no ser físicamente separable, las solicitudes al almacenamiento de objetos pueden predominar o la fuente puede no implementar la proyección de campos. Inspecciona los bytes reales y el tiempo de decodificación en lugar de solo el plan.

Si s['value'] es en su mayoría nulo, ¿cómo preservas los resultados?

Asegura primero la semántica de nulos y tipos de SQL, y luego compara las filas con una línea base de lectura completa. La optimización puede evitar campos innecesarios, pero no debe tratar un valor nulo como faltante o erróneo.

¿Qué sucede con los archivos antiguos después de agregar un campo anidado?

El lector debe resolver los campos por nombre y aplicar a los archivos antiguos la semántica definida para nulos o valores predeterminados. La prueba de rendimiento debe incluir archivos antiguos y nuevos y validar el escaneo combinado.

Lista de verificación para la entrevista

Conclusión en una oración

Demuestra el pushdown verificando la ubicación en el plan, el comportamiento real de escaneo, la equivalencia de resultados y una alternativa segura cuando la fuente no pueda optimizar.