R2 üzerindeki tek bir Parquet dosyasından sunulan interaktif detaya inme panoları

Hamilton Ulmer tarafından yayınlanan bir geliştirici demosu, interaktif ve filtrelenebilir bir analiz panosunun object storage içindeki tek bir Parquet dosyasından fazlasıyla sunulabildiğini gösteriyor. Kurulum, Cloudflare R2 üzerinde barındırılan 40MB'lık önceden toplanmış bir veri küpü ile tarayıcıda çalışan yaklaşık 18KB'lık bir JavaScript Parquet okuyucusu olan Hyparquet'i birleştiriyor ve her grafik ve filtre etkileşimini birkaç HTTP range isteğiyle yanıtlıyor. Ortada ne bir veritabanı, ne bir sorgu motoru ne de bir API sunucusu var.

Bir panonun sorduğu soruları önceden hesaplamak

Ulmer'ın yazısına göre bu yaklaşım çalışıyor çünkü bir detaya inme panosu sınırlı bir soru kümesini yanıtlıyor: gün başına istekler, tek bir kurum için gün başına istekler, ilçelere göre tüm zamanların toplamları. Bunların her biri bir GROUP BY sorgusu; dolayısıyla bunları talep üzerine çalıştırmak yerine her sonuç önceden hesaplanıp kendi küçük tablosu olarak saklanıyor ve Ulmer bunlara grouping set diyor. Setler tek bir Parquet dosyasında, set başına bir bölüm olacak şekilde üst üste diziliyor.

Bazı setler soruları doğrudan yanıtlıyor — tüm zamanların toplamları liderlik tablolarını besliyor, her filtre kombinasyonu için günlük setler çizgi grafiği çalıştırıyor. Diğerleri ise tamamen gecikmeyi azaltmak için var; örneğin kullanıcı bir tarih aralığını sürüklediğinde, günlük satırları toplamakla karşılaştırıldığında getirilen satır sayısını küçülten haftalık ve yıllık setler gibi.

Demo, yaklaşık 15 yıllık bir döneme yayılmış 34 milyon satırlık NYC 311 servis talebi veri setinden, kurum, şikayet türü, gönderim kanalı ve ilçe filtreleriyle, seri grafikler için de bir zaman sütunuyla birlikte toplanarak oluşturuldu.

Dosya düzeni onu hızlı yapan şey

Parquet formatının iki özelliği okuma tarafındaki ağır işi yapıyor. Bir Parquet dosyası row group'lara bölünür ve footer, her grubun byte aralığını içindeki her sütunun minimum ve maksimum değerleriyle birlikte tanımlayan metadata'yı barındırır. Tarayıcı footer'ı bir kez okur — bu dosyada yaklaşık 195KB — ardından min/max istatistiklerini kullanarak hangi row group'ların bir sorguyla eşleşebileceğini belirler, yalnızca o byte aralıklarını getirir ve satırları yerel olarak toplar.

İşin diğer yarısı sıralama. Ulmer her grouping set'i, sorgularının filtrelediği sütunlara göre sıraladı; böylece eşleşen satırlar dosyanın bitişik bir bölümünü oluşturuyor ve istatistikler okuyucunun geri kalan her şeyi atlamasını sağlıyor. Satırlar rastgele sıralanmış olsaydı, her grubun değer aralığı neredeyse tüm veri setini kapsayacak ve bir sorgu zaten dosyanın büyük kısmına dokunacaktı. Sıralı düzenle, kurum liderlik tablosunda NYPD'ye tıklamak 40MB'lık küpten yaklaşık 260KB çekiyor.

Bucket'ın önünde küçük bir Cloudflare Worker duruyor; byte aralıklarını proxy'liyor ve edge'de önbelleğe alıyor. Ulmer bunu, ücretsiz r2.dev URL'sinin rate-limit'li olması nedeniyle ekledi ve dosya bir kez yazıldıktan sonra hiç değişmediği için önbellekleme güvenli olduğunu belirtiyor.

Kalıbın çalışmayı durduğu yer

Ulmer sınırlar hakkında açık konuşuyor. Grafik ve filtrelerin kombinasyonları küçük kalmalı ve pipeline her müşterinin dosyasını, güncelleme sıklığını karşılayacak kadar hızlı yeniden oluşturmalı. Gecikme büyük ölçüde küpün boyutuna duyarsız ama boyut yine önemli, çünkü müşteri başına bir dosya programlı olarak yeniden üretiliyor. Ayak izini iki etken belirliyor: zaman tanesi — günlük düzen dosyayı 5.6MB'lık haftalık muadilinden kabaca yedi kat büyük yaptı — ve kardinalite; zira yalnızca şikayet türünün 485 farklı değeri var ve her büyük bölümde yer alıyor.

Ayrıca deneyi, object storage'ı genel amaçlı bir temel olarak gören daha geniş bir proje akışına karşı çerçeveliyor; S3 ve bir write-ahead log ile ölçekli Git repository'leri yönetimi üzerine yakın zamanda yayınlanan bir yazıya atıf yapıyor. Ve test ettiği önyargıyı da kabul ediyor: Bir MotherDuck çalışanı olarak, hafif veri sorunlarının cevabının normalde DuckDB olduğunu varsayıyor. Fikir, R2 üzerindeki Iceberg'de kullanım verisi olan ve kullanıcılara başka bir satıcı eklemeden bazı temel grafikler göstermek isteyen bir arkadaşından gelmiş.

Neden önemli

Müşteriye dönük kullanım veya faturalandırma sayfalarının yaygın senaryosu için — sabit bir grafik seti, bir avuç filtre ve gerçek zamanlı yerine kaba bir programda güncellemeler — bu, neredeyse sıfır marjinal altyapı maliyetiyle analiz için işleyen bir plan. Hesaplama istemciye taşınıyor, değişmez bir dosya edge'de temizce önbelleğe alınıyor ve tek operasyonel yük küpleri üreten batch işi. Ulmer, geleneksel bir analitik veritabanı kurulumunda gerçek maliyetin büyük kısmının zaten o pipeline'da olduğunu belirtiyor. Bu kalıp bir sorgu motorunun genel bir yerine geçmiyor ama önceden hesaplamanın, bilinçli dosya düzeninin ve byte-aralığı okumalarının sıradan bir object store'u ne kadar uzağa taşıyabildiğini gösteriyor.