F3 - Gelecek için açık kaynaklı veri dosyası formatı

 (db.cs.cmu.edu)
9 puan yazan GN⁺ 2025-10-03 | 1 yorum | WhatsApp'ta paylaş
  • F3(Future-proof File Format), birlikte çalışabilirlik, genişletilebilirlik ve verimliliği temel tasarım ilkeleri olarak benimseyen yeni nesil açık kaynaklı sütunlu depolama formatıdır ve veri işleme ile hesaplama ortamları her değiştiğinde yeni bir format oluşturma ihtiyacını ortadan kaldırmayı amaçlar
  • Her F3 dosyası kendini tanımlayan (self-describing) bir yapıya sahiptir; veri ve meta verinin yanı sıra WebAssembly(Wasm) ikili decoder bile içerir, böylece yerel bir decoder olmasa bile tüm platformlarda uyumluluk sağlanır
  • Basamaklı sıkıştırma ve vektörleştirilmiş decoding gibi modern encoding tekniklerini içeren verimli bir depolama yerleşimi sunar ve Parquet ile ORC'nin yerleşim sorunlarını iyileştirerek I/O, encoding ve dictionary birimlerini birbirinden ayırır
  • Eklenti tabanlı decoding API ve Wasm gömme mekanizması sayesinde geliştiriciler yeni encoding şemalarını kolayca ekleyebilir; ayrıca kütüphane sürümünden bağımsız olarak tüm dosyalar okunabildiği için Parquet'nin birlikte çalışabilirlik sorunları çözülür
  • Değerlendirme sonuçları, F3'ün depolama yerleşimi verimliliğini ve Wasm tabanlı decoding'in avantajlarını doğrulamıştır; depolama ek yükü kilobayt düzeyinde ihmal edilebilir seviyededir ve Wasm decoding performans kaybı yerel sürüme kıyasla %10~30 ile kabul edilebilir düzeydedir

Arka plan ve motivasyon

Mevcut sütunlu formatların sınırlamaları

  • Parquet ve ORC, 2010'ların başında Hive, Impala ve Spark gibi veri analitiği sistemleri için geliştirildi ve veri ambarları ile veri gölleri arasında veri paylaşımını mümkün kıldı
  • Aradan geçen 10 yılın ardından araştırmalar, bu formatların modern veri analitiği için yetersiz kaldığını gösteriyor; bunun nedeni tasarım sırasında yapılan eski donanım performansı varsayımları ve iş yükü erişim deseni varsayımlarıdır
    • Son 10 yılda depolama ve ağ performansı onlarca kat arttı, ancak CPU performansı aynı ölçüde artmadı; bu nedenle sistemlerde darboğaz artık I/O değil, hesaplama tarafında oluşuyor
    • Veri göllerinin yükselişiyle birlikte daha fazla veri, yüksek bant genişliğine ancak yüksek gecikmeye sahip bulut depolama alanlarında (ör. Amazon S3) saklanıyor
    • Uygulamalar artık yalnızca az sayıda sütuna sahip tablo verilerini depolamıyor. ML iş yüklerinde binlerce sütuna sahip geniş tabloları, yüksek boyutlu vektör embedding'leri ve büyük blob'ları (görüntü, video) depolamak yaygın hale geldi
    • Rastgele erişim veya güncelleme yapma ihtiyacı da arttı, ancak mevcut formatlar bu tür kullanım kalıplarına uygun değil
  • Sıkıştırma, indeksleme ve filtreleme yöntemlerindeki son gelişmeler bu eksikleri gidermeye çalışsa da, mevcut dosya formatları kolay genişletilebilir olacak şekilde tasarlanmadı
    • Yeni özellikler eklense bile Parquet ve ORC kütüphanelerinin farklı dillerde çok sayıda implementasyonu bulunduğundan en güncel sürümün her yerde kullanılacağını varsaymak zor
    • Eski kütüphaneleri kullanan sistemler yeni dosyaların içeriğini çözemeyebilir; bu yüzden çoğu sistem birlikte çalışabilirlik sorunlarından kaçınmak için yalnızca en düşük ortak payda özelliklerini destekler

Yeni dosya formatlarının ortaya çıkışı ve sınırlamaları

  • Bu sorunları aşmak için Meta Nimble, Lance, TSFile, Bullion, BtrBlocks gibi tamamen yeni dosya formatı önerileri ortaya çıktı
  • Ancak bunlar da öncülleriyle aynı hataları yapıyor
    • Modern donanım ve iş yükü varsayımlarına göre tasarlanıyorlar
    • Yeni özellikleri desteklerken mevcut dağıtımlarla birlikte çalışabilirliği bozmadan kolay genişletilebilirliği teşvik edemiyorlar
    • Bunlardan biri Parquet veya ORC'nin yerini alacak ana format haline gelse bile, 10 yıl sonra kendi kusurlarını gidermek için yine başka bir format geliştirme ihtiyacı doğacak

F3'ün yaklaşımı

  • F3, birlikte çalışabilirlik, genişletilebilirlik ve verimliliği aynı anda sağlamayı hedefler
  • F3'ün merkezinde şu üç spesifikasyon tanımı yer alır:
    1. Dosya içeriğinin meta verisi
    2. Dosya içindeki encoded verinin fiziksel gruplanma yerleşimi
    3. Verinin encoding şemasından bağımsız veri erişim API
  • F3'ün meta veri şeması, bir tablodaki sütun alt kümelerini almak için gereken veriyi en aza indirir
  • F3, Parquet'nin kapsamlı "row group" kavramını kaldırır ve I/O, encoding ve dictionary birimlerini ayırarak yerleşim sorununu çözer
  • Basamaklı sıkıştırma ve vektörleştirilmiş decoding gibi modern yöntemleri entegre eder

F3 genel bakış

Genel yapı

  • Bir F3 dosyası meta veri bölümü ve veri bölümü olmak üzere iki kısımdan oluşur
    • Meta veri bölümü: OptionalData(OptData), Column Metadata(ColMetadata), Footer, Postscript
    • Veri bölümü: Gerçek veriyi içeren Row Groups(RG) yapısından oluşur
  • F3, Parquet ve ORC ile aynı PAX yerleşimini benimser
  • Ancak F3'ün mevcut formatlardan ayrıldığı birkaç temel fark vardır:
    1. Meta veri, deserialization ek yükünü ortadan kaldırır (Parquet/ORC'nin sorununu çözer)
    2. Fiziksel I/O Unit(IOUnit), mantıksal row group'tan ayrılmıştır; böylece IOUnit boyutu depolama ortamına göre bağımsız biçimde ayarlanabilir
    3. Dictionary encoding kapsamı, mantıksal row group'tan ayrılmıştır; böylece her sütun için en etkili kapsam belirlenebilir
    4. Her IOUnit birden fazla Encoding Unit(EncUnit) içerir ve EncUnit, encoding ile decoding'in en küçük birimidir

Birlikte çalışabilirlik ve genişletilebilirlik mekanizması

  • F3, implementasyonun dosya içindeki sıkıştırılmış veriyi nasıl decode edeceğini tanımlayan açık bir API sunar
  • Encoding yöntemleri eklenti olarak ele alınır; bu nedenle çekirdek kütüphaneden ayrı kurulup yükseltilebilirler
  • Tüm kütüphane sürümlerinin tüm dosyaları okuyabilmesini sağlamak için decoder implementasyonları dosyanın içine WebAssembly(Wasm) ikili biçiminde gömülür
    • Yani her F3 dosyası hem veriyi hem de o veriyi okuyan kodu birlikte içerir
  • F3'ün API'si için yerel kod ve Wasm sürümleri adına ayrı implementasyonlar gerekmez; aynı kod değişiklik yapılmadan her iki hedef için de derlenebilir
  • Bu tasarım F3'ü geleceğe dayanıklı hale getirir, yukarıda açıklanan sorunları önler ve mevcut çözümlerden daha hızlı evrim geçirmesini sağlar
    • Geliştiriciler, tüm filodaki kütüphane sürümlerini yükseltme derdi olmadan, gelecekteki encoding yöntemlerini üretim sistemlerine dağıtmak için Wasm kodunu dosyanın içine ekleyebilir
    • Wasm ikili dosyalarının depolama ek yükü ihmal edilebilir düzeydedir (kilobayt seviyesinde) ve Wasm decoding'in yerel implementasyona göre performans kaybı düşüktür (%10~30)

Sonuç

  • F3, birlikte çalışabilirlik, genişletilebilirlik ve verimliliği aynı anda sağlayan yeni nesil bir sütunlu dosya formatıdır
  • Verimli dosya yerleşimi tasarımıyla mevcut formatların verimsizliklerini giderir
  • Eklenti tabanlı decoding API ve Wasm gömme sayesinde, kütüphane sürümünden bağımsız olarak tüm dosyaların okunabilmesini sağlayan geleceğe dayanıklı bir mekanizma sunar
  • Prototip değerlendirmesi, yerleşim tasarımının verimliliğini ve Wasm mekanizmasının pratikliğini doğrulamıştır
  • Wasm ek yükü, kilobayt düzeyinde depolama ve %10~30 performans kaybıyla kabul edilebilir sınırlar içindedir

İlgili okumalar

1 yorum

 
GN⁺ 2025-10-03
Hacker News görüşleri

  • Hızlıca göz attığımda, Parquet’nin eksiklerinin çoğunu kapatmış gibi göründüğü için beklentim yüksek

    • Parquet metadata’sı Thrift tabanlı olmasına rağmen, yalnızca "bu alan varsa şu alan da mutlaka olmalı" türünde açıklamalar var; gerçek bir doğrulama mantığı yok, bu yüzden hatalı Thrift verilirse okuyucunun bozulacağını düşünüyorum

    • Parquet metadata’sı parse edilmek zorunda olduğundan, buffer ayırma ve metadata parsing için dinamik allocation tekrar tekrar yapılıyor ve aşırı heap allocation oluşuyor. Bu yeni format Flatbuffers yaklaşımını benimsediği için Flatbuffer byte’ları doğrudan yorumlanabiliyor ve bu sorun çözülüyor

    • Encoding çok daha güçlü hissettiriyor. Veritabanı dünyasında uzun süredir savunulan hafif ve birleştirilebilir encoding’lerin mümkün hale geldiği anlaşılıyor. BtrBlocks ve FastLanes gibi mevcut formatlar Parquet’den daha üstündü; onların iyi fikirlerinin devralınmış olması sevindirici

    • Parquet’nin Dremel record-shredding yaklaşımını fazla karmaşık buluyordum; bunda onun kalkmış olması iyi olmuş

    • Parquet’de DataPage içindeki row sayısı değişken olduğu için istenen row’u bulmak adına tüm ColumnChunk’ı taramak gerekiyor, ama bu formatta istenen DataPage’e (IOUnit) doğrudan atlanabiliyor

    • Ağır compression kaldırılmış, yalnızca Delta/Dictionary/RLE bırakılmış. Ağır compression pratikte çok kazanç sağlamıyor, uygulaması zahmetli ve dış bağımlılıkları da fazla

    • Genel olarak müthiş bir ilerleme. Bu formatın veri analizi dünyasını ele geçirmesini umuyorum

    • Eğer ağır compression zstd ya da brotli ise, tekrarın az olduğu string kolonlarda çok faydalı oluyor

      • Gerçekte çoğu ASCII olup ortak substring’ler bol olduğunda compression oranının %1’e kadar indiğini gördüm

    • İşin içine wasm compiler girince, ironik biçimde ‘heavy’ compression’dan daha fazla bağımlılık ortaya çıkabilir

      • Eskiden CPU kaynakları ağ ya da disk bant genişliğine göre görece daha boldu, bu yüzden ağır compression daha anlamlıydı; şimdi bu fark daha az

    • Parquet dosyasına kolon eklemekle ilgili StackOverflow tartışması

    • Bugünlerde compression tarafı zstd üzerinde sabitlenmiş gibi mi?

    • Parquet beklenmedik ölçüde karmaşık. Onu gerçekten verimli kullanmak için rahatsız edici ve iyi belgelenmemiş birçok ayrıntıyı öğrenmek gerekiyor; dolayısıyla kolay değil

  • Wes McKinney

    • Wes McKinney’yi tanımayanlar için: Python’daki en yaygın tablo biçimli analiz kütüphanesi olan Pandas’ın yaratıcısıdır

    • Onun yaptığı bir format, daha ilk çıkışından itibaren piyasanın güvenini kazanabilir; ayrıca bu sorunlara uzun süredir tutkuyla yaklaştığı için içgörüleri özellikle önemli görülüyor

    • Andy Pavlo’dan da bahsetmek gerekir

      • Kendisi veritabanı alanında uzmandır ve veri merkezli bir hayat yaşamasıyla bilinir
      • "What goes around comes around" başlıklı iki makalesine bakarsanız, veritabanı alanının geçmişini ve geleceğini kolayca görebilirsiniz
      • CMU Seminar Series de harika; onun da dahil olması beklentiyi artırıyor
      • Çinli ortak yazarlara dair pek bilgim yok, bunun için üzgünüm; ama bu makaleyi yer imlerine ekleyip dikkatle okumayı planlıyorum

    • Bir hayran olarak Pandas’ın etkisine katılıyorum, ama teknik açıdan Arrow veri formatının tüm veri ekosistemi üzerinde daha büyük etki yarattığını düşünüyorum (örneğin DataFusion)

      • Artık F3’ün gerçekte ne olduğuna bakmak istiyorum (sayende linke tıkladım)

    • Wes McKinney, Apache Arrow’un da yaratıcısıdır

      • Modern veri analizinin temel bileşenlerinden biri

    • Onun Parquet üzerindeki çalışmasının bana daha da fazla güven verdiğini düşünüyorum

    • Veriyle kodu karıştırmak klasik bir güvenlik hatasıdır

      • Ünlü birinin dahil olması hataları ortadan kaldırmaz

  • Fizikçilerin geleceği için geçerli olmayacak gibi görünüyor

  • Kolon odaklı saklama ile arasındaki farkı tam anlamamış olmamı mazur görün

    • Bunun neden çığır açıcı olduğunu merak ediyorum; aklımdaki soru şu: "Asıl mesele küçük bir vektör embedding veritabanını sandbox ile birlikte taşımak mı?"

    • Makaleden yeni bir temel olabilecekmiş hissi aldım; proje adında da Fransız usulü bir aura(?) sezdim

    • İçeriğin büyük kısmını anlamadım; ama çizimler ve renkler güzel ve cesur görünüyor. Kolay ikna olan biri olarak iki başparmak yukarı

    • Asıl mesele uyumluluk katmanı

      • Örneğin ORCv2, yeni bir format sürümü üretip özellikleri aşamalı sunmaya çalıştı ama sonunda yayımlanamadı
      • Yeni bir float encoding’i WASM shim ile birlikte dosyayla dağıtabilseydiniz, okuma yazılımını güncellemeden ya da uyumluluk sorunu yaşamadan yeni formatı kolayca ulaştırabilirdiniz
      • Spark’ın variant tipi gibi karmaşık recombination gerektiren durumlarda da yorumlayıcı yerine bytecode ile dağıtmak çok daha kolay olur
      • Ben de kişisel olarak ORC tuning yaparken geceleri uyanık kaldım; benchmark’ta iyi dayanmasına bakıp gururlanıyordum

    • Kolonlu saklamanın gerçek avantajı, karmaşık nested schema’ları primitive değerlere bölerek saklayabilmesidir

      • Böylece leaf değerler doğrudan okunabilir ve IO ile parsing verimliliği ciddi biçimde artar
      • Formatlar en üst düzeyde row group bazında partition edilir
      • Bu format, Apache Arrow buffer’larını veri sayfalarından doğrudan almayı sağlıyor (WASM kullanarak ya da native decoder ile)
      • Parquet şu anda çok karmaşık. Dremel encoding kullanarak primitive değerleri iki integer stream’iyle (repetition/definition level) birlikte saklıyor; sıradan biri için parse etmek zor
      • Özellikle bit-packing ile RLE karışık halde ve referans implementasyonda yalnızca bit-packing kodu 74 bin satır
      • Arrow buffer’a dönüştürmek için ciddi emek gerekiyor. F3 ile bu çok daha kolay ve geleceğe dönük uyumluluk da daha yüksek olur
      • Ayrıca metadata için random access mümkün hale gelmesi de büyük artı
      • Örneğin GeoParquet kullanırken SQLite index koymazsanız tek bir spatial query ortalama 10 dakika sürüyor ve 500 dosyanın footer’ını parse etmek için 150MB Thrift parsing gerekiyor
      • Flatbuffers seçimi şaşırtıcı. Flatbuffers’ın bellek güvenliği sorunları biliniyor (ilgili uyarı)
      • Hatta onun yerine içine SQLite veritabanı koymak daha iyi olmaz mı diye düşünüyorum

    • Kolon odaklı saklamanın asıl kazancı, tüm column’u tek seferde çok hızlı tarayabilmektir

      • Bu, OS buffer’larını çok verimli kullanmayı sağlar. Örneğin select a where b = 'x' sorgusu çok hızlı olur

  • wasm decoder’ın native’e göre %10-30 daha yavaş olması ciddi bir hayal kırıklığı

    • Yani en baştan %10-30 performans kaybını kabul etmek ve gelecekte decoder’ı geliştirme fırsatından da kalıcı olarak vazgeçmek demek

    • "Tüm bloğu decode et ve belleğe yaz" dışında gelişmiş decoding yetenekleri de kullanılamıyor

    • Gerçekten neden bunu bu şekilde yaptıklarını anlayamıyorum

    • Hız önemliyse wasm çözüm değil; hız önemli değilse de bilinen encoding’ler kullanılabilir

    • WASM yedek seçenek olarak sunuluyor

      • Native decoder (örneğin bir crate) kuruluysa önce o kullanılıyor, yoksa WASM fallback oluyor
      • %10-30 kaybı göze almak, dosyayı hiç okuyamamaktan iyidir görüşündeler

    • Katıldığım noktalar var ama mesele biraz daha karmaşık

      • Zaten benzer durumlar farklı compression yöntemlerinde de tekrar tekrar yaşanıyor
      • Örneğin bitpack yöntemi ya da compression değiştiğinde her seferinde "transcoding", yani dosyayı yeniden yazmak gerekiyor
      • WASM geldikten sonra da aynı şekilde dosyayı yeniden yazmak gerekecek
      • Geleceğe dönük esneklik bunun değerini karşılar mı emin değilim. Exabyte ölçekli sistemlerde veriyi yeniden encode etmek gerçekten çok zor

  • Vortex ile F3 arasındaki ilişkinin tam olarak ne olduğu anlaşılmıyor

    • İkisi de "yeni bir format üretmeden encoding yöntemlerini kolayca ekleyebilmek" vizyonundan söz ediyor

    • Tanıtım yazısında Vortex’in encoding implementasyonlarını kullandığı yazıyor ama type system’lerinin farklı olduğu da belirtilmiş

    • Projenin ortaya çıkış hikâyesi karmaşık

      • Başta CMU, Tsinghua, Meta, CWI, VoltronData, Nvidia ve SpiralDB bir konsorsiyum kurup tek bir dosya formatını birleştirmeye çalıştı
      • Ancak Meta NDA ile ilgili CMU avukatlarının yaşadığı sorun yüzünden bu gerçekleşmedi
      • Bunun üzerine herkes kendi dosya formatını çıkardı
      • Araştırma açısından CMU+Tsinghua, encoder geliştirmekten çok WASM gömme konusuna odaklandı
      • DuckDB’den Hannes ilk fikri Wes McKinney’ye önerdi
      • Vortex’in encoding implementasyonları Rust tabanlı olduğu için düzenlenince çoğu WASM’a compile edilebiliyor
      • Vortex, F3’ten ayrı bağımsız bir proje; F3 ise şu anda akademik bir prototip
      • Almanya’da da bu yıl WASM kullanan ayrı bir format çıktı: AnyBlox formatı (tüm dosyayı WASM’a dönüştürüyor; F3 ise kolon grubu düzeyinde)

  • Seneye F4 duyurusunu da beklemeye başlıyorum

  • Kaynak kodun nerede olduğunu epey aradım; burada açık durumda

  • Veriyi okuyabilmek için zorunlu olarak webassembly çalıştırma şartı getirmesi, bağımlılık ve bloat azaltmak isteyen ortamlar için pek uygun görünmüyor

    • wasm basit bir şey

      • "web" ile doğrudan ilgili değil
      • Başkalarının da dediği gibi, wasm bir yedek mekanizma
      • Native binding sağlanırsa performans daha iyi olur

    • Native decoder varsa WASM kullanmaya gerek yok

      • Bu nokta özet metinde de açıkça yazıyor

  • Dosya formatı içine WebAssembly modülü gömen ilk örneklerden biri gibi görünüyor

    • Özellikle compression açısından ilgimi çekiyor. WASM preprocessor iyi tasarlanırsa compression oranını ciddi biçimde artırabilir diye düşünüyorum

    • Ben de aynı konseptle bir dosya formatı geliştiriyorum

    • Alan Kay, 60’larda bir programcı tarafından yapılmış olduğu düşünülen teyp tabanlı bir depolama sistemini bir keresinde ‘ilk nesne yönelimli sistem’ diye anlatmıştı

      • Teybin formatı, belirli konumları okumak ve yazmak için bir dizi rutin içeriyordu
      • Yani öncül bir örnek var
      • ilgili makale bağlantısı (sayfa 4)