Spotify описала Random Access Parquet (RAP) как способ делать low-latency point queries прямо по data lake. Это важно там, где аналитика уже живёт в Parquet, но онлайн-сервисам и AI-приложениям нужны отдельные записи без копирования в операционные базы.
Проблема в этой архитектуре знакома многим командам, которые вырастили data lake до уровня общей платформы. Озёра данных хорошо работают для сканов, аналитики и ML-пайплайнов, но начинают деградировать на точечных запросах. Причина не в одном слое, а в цепочке целиком: планирование запроса, обход метаданных и поиск нужных файлов добавляют задержку, даже если объектное хранилище само по себе уже отвечает за миллисекунды.
Spotify отдельно указывает на масштаб этого компромисса. Онлайн-данные компания хранит в Bigtable, а эксабайты лежат в Google Cloud Storage-based data lake. Дублировать всё это в отдельные serving databases становится дорого. Поэтому RAP выбирает другой путь: не копировать данные, а добавить внешний индекс поверх Apache Parquet. Это прагматичный выбор с понятным trade-off. Платформа получает быстрый доступ к ключам, но сохраняет сложность управления индексами и layout-оптимизациями.
Суть решения в том, что внешний индекс связывает lookup keys, например user IDs, с конкретными Parquet-файлами и позициями строк. Вместо сканирования тысяч файлов запрос сначала проходит через индекс, а затем делает targeted ranged read в object storage. Для immutable Parquet-файлов это особенно важно: данные не переписываются, а индекс строится отдельным слоем. Spotify пишет, что по мере записи новых данных в Apache Iceberg tables builder формирует append-only index fragments, не затрагивая исходные файлы.
На уровне реализации RAP дополняют оптимизации хранения. Данные сортируют по lookup key, чтобы уменьшить число файлов, которые нужно трогать. Related records группируют вместе. Value columns interleave, чтобы несколько атрибутов можно было считать одним contiguous read. Используются и covering indexes, которые в части запросов позволяют вообще не читать Parquet-файлы. Здесь виден типичный инженерный компромисс: немного растут размер файлов и индексной структуры, но система платит за это меньшим числом storage operations. Для некоторых запросов это сводится к одному ranged read в несколько килобайт.
Отдельно Spotify описывает secondary indexes. Они нужны, когда доступ идёт не только по одному первичному ключу. Такие индексы обслуживаются на serving layer и позволяют добавить новые access paths без изменения data pipelines. Hash-based indexes подходят для exact lookups. Sorted indexes пригодны для range queries. Дополнительно упоминаются Z ordering и Hilbert curves как способы улучшить data locality для вторичных измерений. Это не отменяет общей сложности, но расширяет набор сценариев, где один и тот же Parquet dataset может обслуживать и аналитические сканы, и интерактивные точечные запросы.
В инженерном смысле RAP решает не только задачу latency. Он сокращает разрыв между analytical storage и operational access. Это особенно актуально для online services, notebooks, AI agents и ML workloads, которые всё чаще хотят читать одни и те же данные, но с разной моделью доступа. Spotify фактически показывает, как open data lake technologies можно довести до более операционного режима, не ломая базовый формат хранения и не строя вторую копию платформы рядом.
При этом важно не переоценить универсальность подхода. RAP не делает data lake полноценной заменой всем serving databases. Он улучшает точечный доступ за счёт индексации и layout-оптимизаций, но требует дисциплины в организации данных и в обслуживании индексов. Это не магия, а аккуратная инженерная надстройка над уже существующим storage stack. Именно поэтому подход выглядит убедительно для архитекторов: он не отменяет ограничения, а сдвигает их в более управляемую часть системы.