F3 - Format File Data Open Source untuk Masa Depan

• F3 adalah format file data yang dirancang dengan mempertimbangkan efisiensi, interoperabilitas, dan skalabilitas
• F3 menyediakan cara pengorganisasian data yang memperbaiki keterbatasan tata letak format generasi sebelumnya seperti Parquet, sambil mempertahankan interoperabilitas dan skalabilitas melalui dekoder Wasm bawaan
• File F3 yang bersifat self-describing memiliki struktur yang memuat bukan hanya data dan metadata, tetapi juga biner WebAssembly untuk mendekode data tersebut
• Pendekatan menyematkan dekoder di dalam file hanya membutuhkan ruang penyimpanan minimum pada tingkat kilobyte, dan dirancang untuk menjamin kompatibilitas di platform mana pun bahkan saat dekoder native tidak tersedia
• Ini adalah proyek Future-proof File Format yang menyediakan struktur pengorganisasian data dan API umum agar pengembang dapat dengan mudah menambahkan metode encoding baru
• Status saat ini adalah prototipe riset untuk memverifikasi gagasan dalam makalah, dan tidak boleh digunakan di produksi
• Build hanya diuji di Debian 12 pada mesin Intel, dan build paket PoC serta pengujian unit dijalankan dengan cargo build -p fff-poc, cargo test -p fff-poc
• Definisi format file berbasis FlatBuffer, dan juga menyediakan kode utama, implementasi decoding Wasm, serta benchmark dan skrip untuk eksperimen dalam makalah
• Lisensinya adalah MIT License

[GN⁺]

Komentar Hacker News

• Saya kurang paham kenapa ini mendapat begitu banyak rekomendasi, dan landing page-nya juga kurang meyakinkan, jadi rasanya lebih baik langsung membaca makalahnya: https://dl.acm.org/doi/epdf/10.1145/3749163
  Ini tampak seperti format penyimpanan berorientasi kolom yang mencoba menutupi sebagian kekurangan Parquet, tetapi penentu sebenarnya untuk format seperti ini adalah kompatibilitas, dan format baru selalu berada pada posisi lemah dalam hal itu sejak pertama muncul
  Parquet sudah terlalu kuat hanya karena menjadi yang pertama tersebar luas, dan menurut makalahnya bahkan versi Parquet yang paling banyak dipakai pun adalah versi tertua dari tahun 2013, jadi bahkan Parquet sendiri tidak berhasil menggantikan Parquet
  Jika F3 ingin melampaui itu, tampaknya dibutuhkan hasil yang sangat kuat, tetapi sejauh ini tidak terlihat demikian
  Secara pribadi, keluhan terbesar saya terhadap Parquet, yaitu masalah satu tabel per file, juga tidak dibahas, jadi namanya terasa agak berlebihan, dan fakta bahwa ia memasukkan biner Wasm untuk decoding tetapi tetap memerlukan FlatBuffers untuk mem-parsing bagian itu juga mengaburkan tujuannya
  Pencapaian utamanya tampak seperti peningkatan akses acak, tetapi penyimpanan berorientasi kolom pada dasarnya lahir dengan mengorbankan akses acak demi analitik cepat, dan F3 justru tampak mengorbankan analitik cepat karena decoder Wasm, jadi saya kurang mengerti

  • Satu tabel per file pada Parquet lebih merupakan ekspektasi yang diberikan query engine terhadap format file daripada sifat format file itu sendiri
    Spark, DataFusion, dan DuckDB kemungkinan tidak akan tahu harus melakukan apa bahkan jika menerima file dengan banyak tabel
    Memang benar Parquet melakukan banyak hal dengan baik, tetapi bukan berarti hanya karena datang lebih dulu, ia harus selamanya menjadi satu-satunya format file untuk analitik
    Analitik cepat dan beban kerja machine learning modern pada dasarnya merupakan campuran antara batch scan dan akses acak
    Beberapa penulis F3 juga pernah menulis makalah yang membahas secara rinci kekurangan Parquet: https://www.vldb.org/pvldb/vol17/p148-zeng.pdf
    Format-format yang lebih baru seperti Vortex, Lance, dan F3 mencoba menyelesaikan masalah yang dirangkum dalam makalah tersebut
    Lance punya beberapa ide menarik, sementara Vortex mengganti encoder black-box Parquet dengan encoding yang transparan dan berfokus pada ekstensibilitas dan performa
    Dengan begitu, kompromi antara decoding massal dan decoding per elemen bisa dikurangi sehingga pemindaian penuh yang efisien dan akses acak yang sangat cepat dapat diperoleh bersamaan
    Misalnya, LangChain menjelaskan bahwa mereka membangun ulang sistem berbasis file Parquet mereka dengan Vortex dan melihat peningkatan kecepatan yang besar: https://www.langchain.com/blog/introducing-smithdb
    Sebagai catatan, saya sedang mengembangkan Vortex, jadi saya sendiri sudah banyak memikirkan pertanyaan “mengapa membuat format baru”
  • Menurut saya, kesederhanaan Parquet bukan kelemahan, melainkan kelebihan
    Jika butuh beberapa tabel, cukup bungkus beberapa file Parquet dalam sebuah tar, dan itu menjadi indah karena sederhana serta mudah dibaca di bahasa apa pun yang punya library tar dan Parquet
  • Saat menangani Parquet, saya pernah membayangkan format bernama .parquetz
    Jika itu berupa file zip yang berisi beberapa file Parquet tanpa kompresi, maka beberapa tabel bisa dipindahkan dalam satu file sekaligus tetap bisa diakses lewat range request
  • Dibandingkan kebanyakan landing page akhir-akhir ini yang penuh kebisingan seperti buatan ChatGPT, ini justru terasa sebagai perubahan

• Fakta bahwa ini tidak bergantung pada SDK atau library per bahasa, dan jika tidak ada bisa fallback ke metode Wasm bawaan, cukup cerdik
  “Setiap file F3 yang bersifat self-describing tidak hanya memuat data dan metadata, tetapi juga biner WebAssembly (Wasm) untuk mendekode data tersebut. Ruang penyimpanan yang dibutuhkan untuk menanamkan decoder di setiap file kecil (dalam hitungan kilobyte), dan menjamin kompatibilitas di semua platform bahkan ketika decoder native tidak tersedia”

  • Jadi penyerang bahkan tidak perlu sengaja membuat file rusak, cukup menaruh kode serangan langsung di dalam file data itu sendiri?
  • Terlihat keren, tetapi rasanya bisa runtuh pada format yang kompleks
    Seperti apa decoder tertanam untuk PDF?
    Karena sangat terikat dengan byte file, penulis file memang bisa memilih bentuk format yang masuk akal, tetapi tidak semua format memiliki satu “langkah decoding yang benar” yang unik
  • Saya tidak paham bagaimana ini seharusnya bekerja
    Decoder melakukan decoding menjadi apa?
    Itu akan sepenuhnya bergantung pada jenis datanya; beberapa format berupa aliran byte, beberapa berupa bidang piksel 2D, beberapa lagi memerlukan vertex, bidang piksel 2D, dan peta UV, dan dalam kasus lain graph objek terasa lebih alami
  • Ini terlihat seperti kembalinya Applet
  • Apa keunggulan Wasm dibanding binding C?

• Saya tidak tahu orang-orang melihat apa sampai bisa membicarakan ini
  README hampir tidak memberi informasi tentang apa ini atau masalah apa yang ingin diselesaikannya, saya hanya melihat penjelasan FlatBuffers dan tautan ke direktori source code
  Apakah saya melewatkan konteks tertentu?

  • Ada makalah yang ditautkan: https://dl.acm.org/doi/epdf/10.1145/3749163

• Sepertinya perlu sedikit lebih banyak penjelasan tentang “mengapa”
  Katanya ini mengatasi kekurangan Parquet, tetapi saya penasaran kekurangan yang mana
  Dukungan alat yang luas jelas bukan salah satunya
  Mengapa harus meninggalkan Parquet atau ORC dan memakai struktur ini?

  • “Mengapa”-nya tertaut ke referensi di akhir README, dan sepertinya repositori ini memang tidak dibuat untuk dikonsumsi sendirian
    Sebaiknya mulai dari makalahnya: https://doi.org/10.1145/3749163
  • Awalnya saya sama sekali tidak paham mereka sedang membicarakan apa, tetapi ada poin bagus tentang Parquet yang tidak terlalu mempertimbangkan perangkat keras dan metadatanya agak terlalu global
    Tulisan ini menarik: https://medium.com/@reliabledataengineering/f3-the-future-pr...
  • Sebagian besar dari ini rasanya bisa diatasi kalau lebih banyak waktu pengembangan dicurahkan ke Parquet
  • Makalahnya menyebut Parquet, ORC, Nimble, Lance, TSFile, Bullion, BtrBlocks

• Ada yang menyebut ini jenius, tetapi kalau saya memainkan peran skeptis HN yang menjengkelkan, ini terlihat agak bodoh
  Format kompresi data itu sekunder dibanding apa yang akan dilakukan terhadap data tersebut setelah didekode
  File audio dan gambar SVG itu sama sekali berbeda, dan meskipun ada VM tertanam yang bisa mengurai video menjadi piksel mentah, itu tidak berarti editor teks bisa memutar video tersebut, jadi tidak ada interoperabilitas baru yang benar-benar mendasar
  Setiap format baru tetap memerlukan penanganan khusus format
  Misalnya, kalau Anda membuat cara kompresi video yang lebih baik daripada H.265 tetapi belum didukung semua platform, mungkin ada kegunaan untuk menyematkan dekoder agar bisa diputar di perangkat keras lama
  Tetapi di situ juga kelemahannya terlihat. Kecil kemungkinan perangkat keras lama akan mampu menangani format video masa depan dengan decoding perangkat lunak, dan walaupun ide ini sudah muncul sejak 1990-an, itu tetap tidak akan membuat Netflix bisa ditonton di i386
  Begitu juga, saya ragu ini akan membuat file Word 2021 bisa dibuka di Word 97, karena tidak ada pemetaan 1:1 antar struktur data
  Kalau kompatibilitas seperti ini bukan kemenangan yang jelas, saya tidak tahu apa tujuannya
  Kekurangannya jelas. Jika ada bug pada dekoder yang harus diperbaiki, bagaimana cara menambal semua file yang sudah menyematkan dekoder itu?
  Ada juga overhead ukuran dan risiko keamanan, dan ini pada dasarnya menambah permukaan serangan yang signifikan ke semua parser format, sehingga peluang untuk eksekusi kode jarak jauh, serangan pengurasan sumber daya, dan semacamnya meningkat
  Bukan berarti ini selalu pendekatan yang salah, tetapi yang penting adalah apa keuntungan nyatanya

  • Sepertinya Anda belum menemui masalah yang coba diselesaikan oleh keluarga format ini
    Jika mencari format penyimpanan kolumnar, kelebihan dan kekurangannya belakangan ini sudah cukup dirangkum dengan baik
    Tentu saja ini bukan untuk decoding video

• Salah satu kelebihan beberapa format modern adalah alat bisa membacanya dengan kecepatan yang terasa sangat tinggi
  Misalnya, DuckDB bisa menerapkan berbagai macam optimisasi saat membaca format native-nya sendiri atau Parquet
  Namun saya kurang yakin optimisasi seperti itu bisa diterapkan secara efektif pada format yang mengharuskan menjalankan segumpal Wasm untuk memahami formatnya
  Entah itu bukan SIMD atau sudah dioptimalkan dengan SIMD, kalau saat memindai data satu kali lintasan itu tidak memahami kuerinya, Anda mungkin sudah dirugikan
  Saya baru membaca bagian awal makalahnya, jadi mungkin format nyatanya kurang umum dibanding kesan awalnya

  • Menurut pemahaman saya, ini adalah mekanisme fallback

• Saya masih bisa membayangkan ini menggantikan EXE self-extracting, tetapi banyak alasan memilih format file tertentu justru karena fitur spesifik yang ditawarkan format itu
  Sistem yang mendeskripsikan dirinya sendiri pun bisa jatuh ke keadaan yang sama seperti format lain: “fiturnya saling bersaing terlalu banyak dan tidak ada yang bisa menangani semuanya”
  Misalnya, apakah file ini bisa di-mmap secara efisien?
  Kalau secara internal meniru tar, mungkin bisa, tetapi sebelum dijalankan kita tidak tahu
  Bisakah melompat ke posisi byte tertentu dan hanya mengekstrak sebagian?
  Mungkin hanya mendukung versi prarilis dari penelusuran ISO-36898533, sementara pustaka file yang Anda pakai sudah menghapus dukungan itu 6 tahun lalu
  Kalau menulis ulang 1MB di tengah, apakah cukup mengganti halaman disk yang bersangkutan, atau harus menulis ulang semuanya?
  Bisa saja segumpal Wasm mendukung 97 API untuk ini, dan 35 di antaranya hanya salinan dengan nama berbeda, sampai ukurannya lebih besar daripada datanya sendiri, tetapi tidak ada yang peduli
  Pada akhirnya pilihan yang benar-benar dikenali ada 19, tetapi akselerasi Wasm native CPU hanya bisa menangani dua atau tiga, sehingga Anda mungkin tetap harus sangat menspesialisasi kode
  Setidaknya dengan *.tar.gz, kita masih bisa sedikit menebak apa yang mungkin dilakukan

• Bagus. Dunia memang selalu butuh format data yang lebih baik
  Hanya saja, sepertinya README akan lebih menarik perhatian jika langsung menuliskan keunggulannya dibanding Parquet dan format file lain
  Saat seseorang masuk ke https://github.com/future-file-format/f3, mereka harus bisa melihat mengapa ini layak dicoba
  Tampilkan kelebihan dan metriknya, dan metriknya pun boleh yang menguntungkan
  Mungkin ada use case yang bagus, tetapi dari README saat ini belum jelas siapa yang harus memakainya dan mengapa

• Jika Anda menyimpan data skala PB selama lebih dari 10 tahun, saya tidak ingin bergantung pada asumsi bahwa interpreter Wasm masih akan ada di masa depan dan cukup cepat untuk membaca file-file itu
  Saya menginginkan spesifikasi byte yang sederhana dan terdokumentasi dengan baik seperti Parquet
  Selain itu, memasukkan logika decoding ke dalam biner Wasm berarti menambahkan lapisan eksekusi aktif ke sesuatu yang seharusnya menjadi cold storage

  • Format WinRAR juga menyertakan bytecode RAR VM sebagai bagian dari arsip untuk mencapai kompresi mutakhir pada file media
    Itu disandbox dan diterima luas, dan Wasm punya kemampuan sandbox yang sama
    Untuk penyimpanan jangka panjang, ini justru bisa dianggap lebih baik
    Anda tidak perlu membawa program ekstraksinya secara terpisah, karena sudah ada di dalam file arsip itu sendiri
  • Maksud Anda, Anda tidak ingin menjalankan fungsi parsing data kustom berusia 10 tahun setiap kali membaca satu rekaman data?

• Jika decoding gagal, hal yang mengkhawatirkan adalah harus men-debug Wasm yang dimasukkan orang lain, dan bisa saja ada bug arbitrer di dalamnya
  Mungkin akan membantu jika ada pustaka decoder standar yang dikelola dan diuji oleh proyek, tetapi saya tidak yakin apakah itu justru akan menghilangkan keunggulan fleksibilitas yang ditawarkan pendekatan ini

  • Wasm bersifat eksekusi deterministik, jadi jika decoding gagal di pihak saya, seharusnya itu juga gagal di pihak pembuatnya
    Dengan kata lain, itu bukan masalah baru yang dibuat oleh sistem saya, dan mereka seharusnya bisa mereproduksinya secara independen dari klien mana pun