F3 - Gelecek için açık kaynak veri dosya biçimi

• F3, verimlilik, birlikte çalışabilirlik ve ölçeklenebilirlik göz önünde bulundurularak tasarlanmış bir veri dosya biçimidir
• Parquet gibi önceki nesil biçimlerin yerleşim sınırlamalarını düzelten bir veri organizasyon yöntemi sunarken, gömülü Wasm kod çözücü aracılığıyla birlikte çalışabilirlik ve genişletilebilirliği korur
• Kendi kendini tanımlayan F3 dosyaları; veri ve meta verinin yanı sıra, veriyi çözümleyen WebAssembly ikili dosyasını da birlikte barındıran bir yapıya sahiptir
• Dosyaya kod çözücü gömme yaklaşımı kilobayt düzeyinde ek depolama alanı gerektirir ve yerel bir kod çözücü olmadığında bile her platformda uyumluluğu garanti etmek için tasarlanmıştır
• Geliştiricilerin yeni kodlama yöntemlerini kolayca ekleyebilmesi için veri organizasyon yapısı ve genel amaçlı API sunan bir Future-proof File Format projesidir
• Mevcut durum, makaledeki fikirleri doğrulayan bir araştırma prototipidir ve üretimde kullanım için uygun değildir
• Derleme yalnızca Intel makinelerde Debian 12 üzerinde test edilmiştir; PoC paketini derlemek ve birim testlerini çalıştırmak için cargo build -p fff-poc, cargo test -p fff-poc komutları kullanılır
• Dosya biçimi tanımı FlatBuffer tabanlıdır; ana kod, Wasm kod çözme uygulaması ve makaledeki deneyler için kıyaslamalar ile betikler birlikte sunulur
• Lisans MIT License'dır

[GN⁺]

Hacker News yorumları

• Neden bu kadar çok tavsiye aldığını pek anlamadım; landing page de pek iyi değil, bu yüzden makaleye bakmak daha mantıklı görünüyor: https://dl.acm.org/doi/epdf/10.1145/3749163
  Parquet’in bazı eksiklerini gidermeye çalışan bir sütun odaklı depolama biçimi gibi görünüyor, ancak bu tür biçimlerde asıl belirleyici unsur uyumluluk ve yeni bir biçim daha ortaya çıktığı anda bu konuda dezavantajlı oluyor
  Parquet sadece ilk yaygınlaşan format olduğu için bile fazlasıyla güçlü ve makaleye göre en çok kullanılan Parquet sürümü de 2013’teki en eski sürüm; yani Parquet bile Parquet’in yerini alamamış
  F3’ün bunu aşabilmesi için çok güçlü sonuçlar göstermesi gerekir gibi duruyor ama öyle görünmüyor
  Bana göre Parquet’le ilgili en büyük şikayet olan dosya başına tek tablo meselesini de ele almıyor; bu yüzden adı da biraz abartılı geliyor, ayrıca decoding için Wasm ikilisi koyarken o bloğu parse etmek için yine de FlatBuffers gerektirmesi amacı bulanıklaştırıyor
  Asıl kazanım rastgele erişimi iyileştirmek gibi görünüyor ama sütun odaklı depolama zaten hızlı analitik uğruna rastgele erişimden vazgeçmek için ortaya çıkmıştı; F3 ise Wasm decoder yüzünden hızlı analitiği feda ediyor gibi, o yüzden çok anlamlı gelmiyor

  • Parquet’in dosya başına tek tablo meselesi, dosya biçiminin kendisinden çok sorgu motorlarının dosya biçimine yüklediği bir beklentiye daha yakın
    Spark, DataFusion ve DuckDB çoklu tablo içeren bir dosyayı alsa ne yapacağını pek bilmez
    Parquet’in pek çok işi iyi yaptığı doğru, ama önce çıkmış olması onun sonsuza kadar tek analiz amaçlı dosya biçimi olması gerektiği anlamına gelmiyor
    Hızlı analitik ile modern makine öğrenimi tarzı iş yükleri özünde toplu tarama ile rastgele erişimin karışımından oluşuyor
    F3’ün yazarlarından bazıları Parquet’in eksiklerini ayrıntılı ele alan bir makale de yazmıştı: https://www.vldb.org/pvldb/vol17/p148-zeng.pdf
    Son dönemde çıkan Vortex, Lance ve F3 gibi biçimler o makalede özetlenen sorunları çözmeye çalışıyor
    Lance’ta ilginç fikirler var; Vortex ise Parquet’in kara kutu encoder’larını şeffaf encoding’lerle değiştirerek genişletilebilirlik ve performansa odaklanıyor
    Bu sayede toplu decoding ile öğe düzeyinde decoding arasındaki ödünleşimi azaltıp verimli tam tarama ile çok hızlı rastgele erişimi birlikte sağlayabiliyor
    Örneğin LangChain, Parquet dosyalarına dayalı bir sistemi Vortex ile yeniden kurduğunu ve büyük hız artışı gördüğünü anlatıyor: https://www.langchain.com/blog/introducing-smithdb
    Bu arada Vortex geliştirdiğim için “neden yeni bir biçim yapalım” sorusunu bizzat çok düşündüm
  • Parquet’in basitliği bence bir eksiklik değil, bir avantaj
    Birden fazla tablo gerekiyorsa birkaç Parquet dosyasını tar ile paketlersin; böylece tar ve Parquet kütüphaneleri olan her dilde okunması kolay olur, hoş bir sadelik sağlar
  • Parquet’le uğraşırken .parquetz diye bir format hayal etmiştim
    Sıkıştırılmamış birden çok Parquet dosyası içeren bir zip dosyası olsa, tek dosyayla birden çok tablo taşınabilir ve range request ile erişim de mümkün olabilir
  • Bugünlerde çoğu landing page’in ChatGPT ile üretilmiş gibi görünen gürültüyle dolu olmasına kıyasla, bu en azından farklı bir şey

• Dil bazlı SDK’lara veya kütüphanelere bağımlı olmadan, bunlar yoksa yerleşik Wasm yöntemine geri düşebilmesi oldukça zekice
  “Her kendini tanımlayan F3 dosyası, veri ve metadata’nın yanı sıra veriyi decode eden bir WebAssembly (Wasm) ikilisi de içerir. Her dosyaya bir decoder gömmek için gereken ek depolama alanı küçüktür (kilobayt düzeyinde) ve yerel decoder olmadığında bile tüm platformlarda uyumluluğu garanti eder”

  • Saldırganın özellikle bozuk dosya üretmesine bile gerek yok yani; saldırı kodunu doğrudan veri dosyasının içine koyması yeterli mi?
  • Havalı görünüyor ama yüksek karmaşıklıktaki biçimlerde çökecekmiş gibi duruyor
    PDF için gömülü bir decoder nasıl görünürdü acaba?
    Dosya baytlarına sıkı sıkıya bağlı olduğundan, dosyayı yazan kişi hangi biçimin makul olduğuna karar verebilir belki ama her biçim için tek bir “doğru decoding adımı” diye bir şey yok
  • Bunun nasıl çalışması gerektiğini anlayamıyorum
    Decoder neyi, neye decode ediyor?
    Bu tamamen veri türüne bağlı olur; bazı biçimler bir bayt akışıdır, bazıları 2 boyutlu bir piksel düzlemidir, bazıları tepe noktaları, 2 boyutlu piksel düzlemi ve UV haritası gerektirir, bazı durumlarda ise nesne grafiği daha doğaldır
  • Applet’in geri dönüşü gibi görünüyor
  • Wasm’ın C binding’e göre üstünlüğü ne?

• İnsanların neye bakıp konuştuğunu anlamıyorum
  README’de bunun ne olduğu ya da hangi sorunu çözdüğü hakkında neredeyse hiç bilgi yok; sadece FlatBuffers açıklaması ve kaynak kod dizinlerine bağlantılar görünüyor
  Acaba bir bağlamı mı kaçırdım?

  • Bağlantısı verilmiş bir makale var: https://dl.acm.org/doi/epdf/10.1145/3749163

• Biraz daha fazla “neden” gerekli gibi görünüyor
  Parquet’in dezavantajlarını aştığını söylüyorlar ama bunların tam olarak ne olduğunu merak ediyorum
  Bunun kesinlikle geniş araç desteği olmadığını düşünüyorum
  Neden Parquet ya da ORC’den çıkıp bu yapıyı kullanalım?

  • “Neden” kısmı README’nin sonundaki referanslara bağlanıyor ve sanki bu depoyu tek başına tüketin diye yapılmış gibi görünmüyor
    Önce makaleye bakmak daha iyi olur: https://doi.org/10.1145/3749163
  • İlk başta ne anlatıldığını hiç anlamamıştım ama Parquet’in donanımı iyi hesaba katmaması ve metadatanın biraz fazla küresel olmasıyla ilgili iyi noktalar var
    Şu yazı ilginçti: https://medium.com/@reliabledataengineering/f3-the-future-pr...
  • Bunların önemli bir kısmı, Parquet’e daha fazla geliştirme zamanı ayrılarak çözülebilir gibi görünüyor
  • Makalede Parquet, ORC, Nimble, Lance, TSFile, Bullion, BtrBlocks anılıyor

• Bazıları buna dahiyane dedi ama can sıkıcı HN şüphecisi rolünü oynayacak olursam bana biraz aptalca görünüyor
  Veri sıkıştırma biçimi, veri decode edildikten sonra onunla ne yapacağınıza kıyasla ikincil önemdedir
  Ses dosyaları ile SVG görseller tamamen farklı şeylerdir ve videoyu ham piksellere açan yerleşik bir VM olması, o videoyu bir metin düzenleyicide oynatabileceğiniz anlamına gelmez; dolayısıyla temelde yeni bir birlikte çalışabilirlik de doğmaz
  Her yeni biçim için yine biçime özgü işlem gerekir
  Örneğin H.265’ten daha iyi bir video sıkıştırma yöntemi geliştirdiniz ama tüm platformlar desteklemiyorsa, decoder’ı gömüp eski donanımda oynatmak gibi bir kullanım olabilir
  Ama bu da kendi zayıflığını ortaya koyuyor. Eski donanımın gelecekteki video biçimlerini yazılımsal decode ile iyi çalıştırması pek olası değil ve bu fikir 1990’larda ortaya atılmış olsaydı bile i386 üzerinde Netflix izlemeyi mümkün kılmazdı
  Aynı şekilde Word 2021 dosyalarını Word 97’de açtırabileceğinden de şüpheliyim; veri yapıları arasında bire bir eşleme yok
  Bu uyumluluk net bir zafer değilse hedefin ne olduğunu bilmiyorum
  Dezavantajlar ise açık. Decoder’da düzeltilmesi gereken bir hata çıkarsa, o decoder’ı zaten gömülü taşıyan tüm dosyaları nasıl yamayacaksınız?
  Buna bir de boyut ek yükü ve güvenlik riskleri ekleniyor; tüm biçim ayrıştırıcılarına kayda değer bir saldırı yüzeyi katmış oluyorsunuz, yani uzaktan kod çalıştırma, kaynak tüketme saldırıları vb. için daha fazla fırsat doğuyor
  Bu her zaman yanlış bir yaklaşım değil ama kazancın ne olduğu önemli

  • Bu tür biçimlerin çözdüğü problemle sanırım henüz karşılaşmadınız
    Sütun odaklı depolama biçimlerine bakarsanız artıları ve eksileri bugünlerde epey iyi özetlenmiş durumda
    Tabii video decode etmek için değil

• Bazı modern biçimlerin avantajı, araçların onları algılanan çok yüksek hızlarda okuyabilmesidir
  Örneğin DuckDB, kendi yerel biçimini ya da Parquet’i okurken her türlü optimizasyonu uygulayabiliyor
  Ama biçimi anlamak için bir Wasm parçası çalıştırmak gerekiyorsa, bu tür optimizasyonların ne kadar etkili uygulanabileceğinden emin değilim
  İster SIMD olsun ister SIMD ile optimize edilmiş olsun, veriyi bir kez tararken o geçiş sorguyu anlamıyorsa zaten baştan kaybetmiş olabilirsiniz
  Makalenin yalnızca başını göz gezdirdim; gerçek biçim kulağa geldiğinden daha az genel olabilir

  • Anladığım kadarıyla bu bir fallback mekanizması

• Kendiliğinden açılan EXE’lerin yerini almasını bir ölçüde hayal edebiliyorum ama belirli bir dosya biçimini seçme nedenlerinin büyük kısmı, o biçimin sunduğu somut özelliklerdir
  Kendini tanımlayan bir sistem de diğer biçimlerde olduğu gibi “rekabet eden özellikler çok fazla ve kimse hepsini tam destekleyemiyor” durumuna düşebilir
  Örneğin bu dosya verimli şekilde mmap edilebilir mi?
  İçeride tar’ı taklit ediyorsa belki mümkündür ama çalıştırmadan bilemezsiniz
  Belirli bir bayt konumuna gidip yalnızca bir kısmını açmak mümkün mü?
  Belki yalnızca ISO-36898533 aramasının ön sürümünü destekliyordur ve kullandığınız dosya kütüphanesi o desteği 6 yıl önce kaldırmıştır
  Ortadaki 1MB’yi yeniden yazarsanız diskte yalnızca ilgili sayfayı mı değiştirirsiniz, yoksa her şeyi baştan mı yazmanız gerekir?
  Wasm parçası bunun için 97 API destekliyor olabilir; bunların 35’i yalnızca farklı isimli kopyalardır, veriden daha büyük hale gelmiştir ama kimse umursamamıştır
  Sonunda tanınabilir seçenek sayısı 19’dur ama CPU’nun yerel Wasm hızlandırması bunların yalnızca iki ya da üçünü ele alıyordur; dolayısıyla yine kodu ciddi biçimde özelleştirmeniz gerekebilir
  En azından *.tar.gz ise neyin mümkün olacağına dair kabaca bir fikriniz olur

• Güzel. Dünyanın her zaman daha iyi veri biçimlerine ihtiyacı var
  Yine de README’ye Parquet ve diğer dosya biçimlerine göre avantajları doğrudan yazarlarsa daha çok ilgi göreceğini düşünüyorum
  Birisi https://github.com/future-file-format/f3 sayfasına girdiğinde neden denemesi gerektiğini görebilmeli
  Avantajları ve metrikleri koyun; metrikleri lehinize olanlardan seçseniz bile olur
  İyi kullanım alanları olabilir ama mevcut README’ye bakınca kimin neden kullanması gerektiği net değil

• PB ölçeğinde veriyi 10 yıldan uzun süre saklayacaksam, dosyayı okuyabilmek için gelecekte de bir Wasm yorumlayıcısının var olacağına ve yeterince hızlı çalışacağına bel bağlamak istemem
  Parquet gibi basit ve iyi belgelenmiş bir bayt düzeyi spesifikasyon isterim
  Ayrıca decode mantığını Wasm ikilisinin içine koymak, soğuk depolama olması gereken bir yere etkin bir yürütme katmanı eklemek anlamına geliyor

  • WinRAR biçimi de medya dosyalarında en yeni sıkıştırmayı elde etmek için arşivin bir parçası olarak RAR VM bytecode içeriyor
    Sandbox içinde çalıştırılıyor ve geniş kabul gördü; Wasm da aynı sandbox yeteneklerine sahip
    Uzun vadeli saklama için hatta daha iyi olduğu bile söylenebilir
    Çünkü sıkıştırma açma programını ayrıca taşımanız gerekmiyor; arşiv dosyasının içinde geliyor
  • Yani her tekil veri kaydını okurken 10 yıllık özelleştirilmiş bir veri ayrıştırma fonksiyonunu çalıştırmak istemediğinizi mi söylüyorsunuz?

• Kod çözme başarısız olursa, başkasının eklediği Wasm'ı debug etmek zorunda kalmak ve onun içinde rastgele hatalar bulunabilmesi endişe verici.
  Projenin bakımını yaptığı ve test ettiği standart bir decoder kütüphanesi olması yardımcı olabilir, ama o zaman bunun sunduğu esneklik avantajını ortadan kaldırıp kaldırmayacağından emin değilim.

  • Wasm deterministik çalıştığı için, bende kod çözme başarısız olduysa onu üreten tarafta da başarısız olmuş olması gerekirdi.
    Yani bu benim sistemimin yeni oluşturduğu bir sorun değil; herhangi bir istemciden bağımsız olarak onların da bunu yeniden üretebilmesi gerekir.