Spotify ha lanzado Random Access Parquet (RAP), una capa de indexación externa que permite consultas de punto en sub-segundo directamente contra archivos Parquet en su data lake basado en GCS, sin copiar datos a Bigtable, DynamoDB u otras tiendas de atendimiento. El sistema cierra una brecha que ha obligado a los equipos de datos a escala a elegir entre costo de almacenamiento y latencia de consulta.
El problema es concreto a escala. Spotify aloja petabytes en Bigtable para atendimiento de baja latencia, pero exabytes viven en GCS. Replicar incluso una fracción en una tienda clave-valor para hacerla consultable es económicamente insostenible. El almacenamiento en la nube ahora entrega 30–100ms por solicitud; GCS Rapid Storage y S3 Express One Zone bajan a milisegundos de un solo dígito. El cuello de botella real es la sobrecarga de planificación de consultas. Trino y BigQuery añaden segundos de trabajo de programación incluso para consultas de una sola fila.
La lectura en cadena de dependencias es el problema central de RAP. Una consulta de punto para el historial de escucha de un usuario durante 90 días con 1.000 archivos Parquet por día comienza con 90.000 archivos candidatos. La partición basada en clave más los filtros Bloom se reducen a aproximadamente 12 archivos. Cada uno aún requiere viajes de ida y vuelta secuenciales: obtener pie de página, analizar metadatos de grupo de filas, escanear la columna de clave, resolver desplazamientos de página para cada columna de valor. En el almacenamiento en la nube cada uno cuesta decenas de milisegundos. Encadenados, eso es cientos de milisegundos antes de que llegue un solo byte de datos del usuario.
RAP colapsa la cadena a una única búsqueda O(1). Un índice externo mapea cada clave directamente a números de archivo y fila. El lector accede al índice, resuelve números de fila a rangos de bytes usando metadatos de archivo en caché, e emite lecturas de rango paralelas. Sin viajes de ida y vuelta dependientes. Las entradas de índice son compactas: clave, archivo (ordinal codificado por diccionario), números de fila y recuento de valor opcional para paginación. Regla general: indexar un petabyte produce un terabyte de índice; terabytes producen gigabytes.
Los cambios de diseño del lado de escritura eliminan la amplificación restante. Incluso con un índice perfecto, los lectores obtienen una página completa de 4MB para extraer tal vez 100 bytes de datos útiles. Spotify ordena la salida de Parquet por clave de búsqueda, alinea límites de página con transiciones de clave, y utiliza diseño de columnas intercaladas colocando columnas de valor relacionadas. Los índices de cobertura almacenan en caché suficientes datos de valor dentro del índice mismo para satisfacer algunas consultas sin abrir ningún archivo Parquet. La compensación es crecimiento modesto del índice y tamaño de archivo para consultas que se resuelven en kilobytes.
Los índices secundarios extienden el modelo sin cambios de pipeline. Los índices basados en hash sirven búsquedas exactas entre dimensiones; los índices ordenados manejan consultas de rango. Ambos se administran en la capa de atendimiento, permitiendo que los equipos añadan rutas de acceso—ID de comprador, ID de vendedor, ID de sesión—sin tocar trabajos anteriores o reescribir datos.
La función de fuerza práctica es agentes de IA. Los agentes que responden preguntas temporales como "¿qué estaba escuchando el verano pasado?" necesitan paginar meses de historial por usuario a velocidades interactivas. Ese volumen de datos siempre ha excedido lo que las tiendas clave-valor pueden económicamente mantener. RAP permite que los mismos datasets Parquet alimenten análisis por lotes, entrenamiento de ML, notebooks y contexto de agente desde una única copia.
Punto de evaluación: si tu equipo mantiene una réplica de datos de lake en una tienda KV puramente por latencia de consulta de punto, RAP merece una evaluación directa. La sobrecarga de indexación está limitada, los archivos Parquet permanecen inmutables, y los cambios de diseño del lado de escritura son incrementales suficientes para aplicar por tabla sin reescrituras de pipeline.