Entrevista de ingeniería de datos: ¿Cómo usarías el Page Index de Parquet para escaneos selectivos?

Planteamiento y alcance

La tabla se escribe diariamente como Parquet, con muchas páginas de datos dentro de cada row group. Las consultas suelen filtrar por customer_id y un rango de tiempo, coincidiendo con menos del 1 % de las filas mientras escanean casi toda la tabla. Explica cómo el Page Index opcional puede reducir las lecturas de páginas irrelevantes manteniendo la corrección en lectores antiguos, controlando el costo de los metadatos y demostrando que las mejoras provienen de la poda de páginas (page pruning) y no de cambios en la caché o en los recursos.

La capacidad, la selectividad y la tasa de escaneo son suposiciones para la entrevista, no benchmarks universales. Esta pregunta encaja en roles de ingeniería de datos, motores lakehouse, optimización de consultas e infraestructura de almacenamiento. Su habilidad central es la disposición de archivos columnares y el predicate pushdown, por lo que pertenece a data.

Qué evalúan los entrevistadores

Primero, ¿puedes distinguir ColumnIndex de OffsetIndex? El primero utiliza estadísticas de límites por página para decidir qué páginas pueden coincidir; el segundo mapea los rangos de filas coincidentes a offsets en las columnas proyectadas.

Segundo, ¿puedes explicar columnas ordenadas frente a no ordenadas? Las columnas ordenadas pueden utilizar búsqueda binaria en los límites; las columnas no ordenadas suelen requerir la verificación secuencial de los límites de las páginas. Un Page Index no es un índice secundario general.

Tercero, ¿puedes proteger la corrección? Los valores min/max truncados pueden agrandar el conjunto de candidatos, pero no deben excluir una página que podría coincidir. Los nulos, NaNs, el orden de las columnas y column_orders siguen la definición del formato.

Cuarto, ¿puedes cuantificar los trade-offs? Los metadatos del índice añaden E/S en el área del footer y trabajo de escritura, mientras que los escaneos selectivos pueden reducir la E/S de páginas de datos. Mide con la carga de trabajo real en lugar de prometer una aceleración fija.

Quinto, ¿puedes ofrecer un mecanismo de respaldo (fallback)? Un lector antiguo puede ignorar el Page Index y aun así leer correctamente con estadísticas ordinarias de row groups o páginas. Habilitar el índice no debe cambiar la semántica de los resultados.

Preguntas para aclarar primero

• ¿El motor y el lector implementan ColumnIndex y OffsetIndex, y los leen por defecto?
• ¿customer_id está agrupado por rangos (range-clustered) o clasificado al momento de escribir, o no está ordenado?
• ¿Los predicados son de igualdad, rango, prefijo o expresiones complejas?
• ¿Los archivos existentes contienen estadísticas a nivel de página, y cuáles son la codificación y los tamaños de página?
• ¿Cuál es la versión mínima de lector antiguo y la matriz de compatibilidad entre lenguajes?
• ¿Estamos optimizando búsquedas puntuales (point lookups), escaneos de rangos o agregaciones de tabla completa?

Estructura de respuesta de 30 segundos

“Primero verificaría el soporte del lector y muestrearía los footers de los archivos para obtener conteos de páginas, tamaño de ColumnIndex, ordenamiento y selectividad de los predicados. Para customer_id ordenado, usaría los límites min/max de página para localizar candidatos; para otras columnas, evaluaría los límites y usaría OffsetIndex para mapear las filas coincidentes a las columnas proyectadas. Cambiaría el ordenamiento o el tamaño de página solo cuando un benchmark muestre valor, porque Page Index no es un índice secundario. Los lectores antiguos deben devolver el mismo resultado ignorándolo. Finalmente, con caché fría y recursos fijos, compararía los bytes escaneados, las páginas leídas, el tiempo de planificación, el p95 de extremo a extremo y la sobrecarga de footer/índice contra un control con el índice deshabilitado.”

Respuesta paso a paso

Paso 1: Verificar el formato y el soporte del lector

Page Index es metadato opcional de ColumnChunk que contiene ColumnIndex y OffsetIndex. Inspecciona los metadatos del archivo para ver la ubicación y longitud del índice, el orden de las columnas y column_orders; luego habilita métricas explícitas de poda de páginas en el motor de destino. Si un lector solo escribe el índice pero no lo consume, escribirlo no reducirá los escaneos.

for each row_group:
  read ColumnIndex for predicate columns
  select pages whose min/max may match predicate
  use OffsetIndex to map selected row ranges to projected columns
  read only those page ranges

Paso 2: Separar columnas ordenadas y no ordenadas

Parquet documenta que los límites para columnas ordenadas admiten búsqueda binaria, mientras que las columnas no ordenadas generalmente requieren comprobaciones min/max secuenciales. El ordenamiento no es un requisito de todo el formato. Registra el solapamiento de rangos de valores por row group en lugar de utilizar únicamente la cardinalidad de la tabla.

Paso 3: Interpretar min/max de forma conservadora

Los escritores pueden truncar cadenas largas o usar límites que cubran el rango de valores real. Dichos límites pueden provocar páginas candidatas adicionales, pero no deben excluir una posible coincidencia. Interpreta nulos, NaNs y comparaciones de acuerdo con column_orders; cuando las estadísticas estén incompletas, lee la página de forma segura.

Paso 4: Conectar lecturas entre columnas

ColumnIndex identifica páginas candidatas solo para las columnas de predicados. La proyección todavía necesita otras columnas, por lo que OffsetIndex mapea los rangos de filas coincidentes a sus offsets de página. Los límites de página pueden diferir entre columnas; nunca reutilices el número de página de una columna para otra. Sin OffsetIndex, un lector puede decodificar más columnas de forma secuencial.

Paso 5: Medir el costo de escritura y metadatos

Más páginas añaden encabezados de página y entradas de índice; páginas más grandes reducen la granularidad de la poda. Evalúa con un benchmark una matriz de selectividad de consultas, ancho de fila, compresión y tamaño de página. Las búsquedas puntuales pueden justificar más metadatos, mientras que los escaneos amplios y las agregaciones completas solo pagarán E/S adicional en el footer.

Paso 6: Diseñar compatibilidad y despliegue

Antes de habilitar las escrituras, haz un inventario de todos los consumidores. Un lector antiguo que ignore Page Index debería utilizar estadísticas de row group o lecturas normales de páginas y devolver el mismo resultado. Despliega primero en archivos nuevos y en una partición fija, manteniendo un control con el índice deshabilitado. Registra hashes de resultados, bytes escaneados y errores para lectores compatibles y no compatibles.

Paso 7: Definir una aceptación repetible

Ejecuta consultas equivalentes sobre la misma instantánea con caché fría, concurrencia fija y ensayos repetidos. Registra bytes escaneados, páginas leídas, tasa de omisión (skip ratio), bytes de footer/índice, CPU de decodificación, latencia de extremo a extremo y validación de resultados. Mantén una partición no ordenada con alto solapamiento como control negativo; detén el proceso si el índice solo añade costos para cargas de trabajo de baja selectividad.

Respuesta modelo

“Primero verificaría que el lector consuma ColumnIndex y OffsetIndex, luego muestrearía los footers para ver el conteo de páginas, la longitud del índice, column_orders y el ordenamiento de escritura. Page Index es metadato opcional, no un índice secundario; indica qué páginas pueden coincidir.

Para customer_id ordenado, realizaría una búsqueda binaria en los límites min/max de página; para columnas no ordenadas, verificaría los límites secuencialmente. Usaría OffsetIndex para mapear las filas que coinciden con el predicado a las columnas proyectadas, sin reutilizar nunca el número de página de una columna para otra. Las estadísticas truncadas pueden ampliar los candidatos; las estadísticas faltantes, los nulos o el orden incierto requieren una lectura segura.

En las escrituras, evaluaría la selectividad, el tamaño de página, la compresión y el crecimiento del footer. Durante el despliegue conservaría un control para lectores antiguos y con índice deshabilitado, y exigiría resultados idénticos. Con caché fría y recursos fijos, compararía los bytes escaneados, la tasa de omisión, la E/S del índice, la CPU, el p95 y los hashes de resultados antes de expandir.”

Errores comunes

• Tratar Page Index como un índice secundario → las columnas no ordenadas pueden tener aún muchos candidatos → mide el solapamiento de rangos de valores y la selectividad.
• Escribir solo ColumnIndex → las columnas proyectadas no pueden saltar por filas coincidentes → valida el mapeo de OffsetIndex.
• Tratar min/max truncados como exactos → se pueden excluir coincidencias reales → permite solo una expansión conservadora de candidatos.
• Probar solo con caché caliente → la caché oculta la E/S → repite las ejecuciones de control con caché fría.
• Reutilizar números de página entre columnas → los límites de página difieren → usa rangos de filas y offsets.
• Ignorar a los lectores antiguos → el despliegue introduce regresiones de compatibilidad → mantén una matriz de lectores y mecanismos de respaldo.
• Verificar latencia sin comprobar resultados → los errores de poda pueden perder filas → compara hashes y agregaciones de negocio.
• Habilitarlo en todas partes por defecto → los escaneos de baja selectividad pagan el costo de metadatos → despliega por tabla o partición.

Preguntas de seguimiento

Pregunta de seguimiento 1: ¿Por qué las columnas ordenadas se benefician más?

El ordenamiento concentra los valores en páginas vecinas, por lo que un rango a menudo se asigna a un intervalo de páginas contiguo que admite búsqueda binaria. Los valores no ordenados se solapan más y producen más candidatos. El tamaño de página y la selectividad del predicado siguen determinando el resultado.

Pregunta de seguimiento 2: ¿Se pueden omitir páginas sin OffsetIndex?

La columna de predicado puede identificar candidatos, pero las columnas proyectadas no pueden ubicar directamente los mismos rangos de filas, por lo que el lector puede necesitar más lecturas secuenciales. Valida el lector de destino en lugar de inferir el soporte únicamente a partir de los metadatos del archivo.

Pregunta de seguimiento 3: ¿Son seguras las estadísticas truncadas?

Un escritor correcto presenta límites conservadores que cubren el rango real. Esto puede generar falsos positivos y lecturas adicionales, pero no falsos negativos. Si esa garantía no está disponible, recurre a lecturas normales.

Pregunta de seguimiento 4: ¿Cómo demuestras que no se pierden filas?

Ejecuta la misma instantánea con Page Index habilitado y deshabilitado, compara resultados completos, conteos, agregaciones y muestras clave, luego prueba valores límite, nulos, duplicados y cadenas largas con datos sintéticos.

Pregunta de seguimiento 5: ¿Cuándo no vale la pena escribir Page Index?

Los escaneos completos, los predicados de baja selectividad, las pocas páginas o la latencia dominada por el footer pueden no beneficiarse. Compara los bytes de índice, la CPU de escritura y el costo de mantenimiento, y mantén un interruptor por tabla o por partición.

Pregunta de seguimiento 6: ¿Qué pasa con los cambios de esquema o de ordenamiento?

Los archivos nuevos deben interpretarse con su propio esquema y column_orders; la tabla no puede asumir un ordenamiento global único. Los archivos históricos mixtos necesitan un manejo consciente de capacidades y monitoreo de índices faltantes.