Random Access Parquet: Veri Gölünde Nokta Sorguları Hızlandırıyor

Spotify gibi şirketler, kullanıcı bazlı geçmiş verilerini hem çevrimiçi servisler hem de LLM tabanlı ajanlar için düşük gecikmeyle sorgulamak zorunda. Sorun şu: exabaytlarca veri GCS gibi veri göllerinde dururken, bu ölçekte her şeyi Bigtable veya DynamoDB gibi bir KV deposunda tutmak ekonomik değil. Depolama katmanı hızlanmış olsa da (GCS 30-100ms, S3 Express One Zone ve GCS Rapid Storage tek haneli milisaniyeye iniyor), Trino veya BigQuery gibi dağıtık SQL motorları tek satırlık bir sorgu için bile saniyeler süren planlama ve zamanlama yükü ekliyor; bunlar analitik verim için tasarlanmış, etkileşimli nokta sorgular için değil.

Random Access Parquet (RAP), bu boşluğu harici bir indeksle kapatıyor: anahtarları doğrudan dosya konumlarına eşleyen bir yapı, dosya içi bağımlı okuma zincirlerini (footer okuma, satır grubu meta verisi, sütun taraması, sayfa indeksi) tek adımlı, kesin aralıklı okumalarla değiştiriyor. İndeks aramaları O(1), sonrasında gereken tek şey birkaç paralel ve hedefe yönelik okuma. RAP, ML pipeline'ları ve batch analitiğin zaten kullandığı aynı Parquet dosyaları üzerinde, hiçbir özel hazırlık gerektirmeden çalışabiliyor.

İndeks boyutu kabaca terabaytlık veri için gigabayt, petabaytlık veri için terabayt mertebesinde kalıyor ve hash bucketing ile doğal olarak dağıtılabiliyor. Yazma zamanında anahtara göre sıralama, hash bucketing, co-grouping ve daha kaba partition'lama gibi teknikler okunacak byte ve round-trip sayısını daha da azaltabiliyor — ama bu, batch sorgular için partition pruning granülerliğinden ödün vermek anlamına geliyor. Mühendisler için önemi açık: aynı veri kümesini ayrı bir serving sistemine kopyalamadan, tek bir depolama katmanından hem analitik hem düşük gecikmeli erişim sağlamak mümkün hale geliyor.