Memperkenalkan 3FS, sistem file terdistribusi dari DeepSeek

 (maknee.github.io)
20 poin oleh GN⁺ 2025-04-18 | 2 komentar | Bagikan ke WhatsApp
  • 3FS adalah sistem file terdistribusi open-source berperforma tinggi yang dikembangkan oleh DeepSeek, mendukung pemrosesan data skala besar dan throughput tinggi
  • Berfungsi seperti sistem file biasa, tetapi sebenarnya menyimpan data secara terdistribusi di banyak mesin, dengan lapisan abstraksi sehingga pengguna tidak perlu menyadarinya
  • Melalui 4 komponen utama (Meta, Mgmtd, Storage, Client), sistem ini memisahkan pengelolaan metadata, manajemen node, penyimpanan data aktual, dan pemrosesan permintaan pengguna
  • Mencapai konsistensi kuat dan toleransi kegagalan melalui algoritme CRAQ, serta meneruskan permintaan tulis dengan aman melalui struktur berantai
  • 3FS dibedakan dari sistem file terdistribusi lain dalam hal kelayakan penerapan nyata dan skalabilitas performa

Apa itu 3FS?

  • 3FS adalah singkatan dari Fire-Flyer File System, sebuah sistem file terdistribusi yang dirilis oleh DeepSeek
  • Dirilis bersamaan dalam pekan rilis open-source DeepSeek
  • Terlihat seperti path file biasa, tetapi sebenarnya menyediakan abstraksi atas data yang disimpan secara terdistribusi di banyak mesin

Apa itu sistem file terdistribusi?

  • Bagi pengguna, sistem ini terlihat seperti sistem file lokal, tetapi sebenarnya menyimpan data secara tersebar di banyak server
  • Contoh: path /3fs/stage/notes.txt tampak seperti satu file, tetapi sebenarnya disimpan terpisah di beberapa server
  • Pengguna dapat memakainya seperti file biasa dengan perintah seperti mkdir, cat

Mengapa menggunakan sistem file terdistribusi?

  • Mendukung data berukuran besar (tingkat petabyte) dan throughput tinggi
  • Menjamin keandalan melalui fault tolerance dan redundansi
  • Contoh penggunaan nyata:
    • Framework pemrosesan paralel seperti HDFS + Spark
    • Checkpointing pada pipeline pelatihan ML
    • Colossus milik Google
    • Haystack, penyimpanan foto milik Meta
    • Contoh storage untuk AI: JuiceFS vs CephFS

Komponen 3FS

  • Terdiri dari total 4 jenis node utama

Meta

  • Mengelola metadata seperti path file, atribut, dan lokasi
  • Menangani permintaan klien melalui RPC (open, stat, close, dll.)
  • Informasi metadata disimpan di FoundationDB
  • Inode menyimpan informasi seperti ukuran file dan pemilik
  • DirEntry menghubungkan path dan inode (seperti symbolic link, satu file dapat memiliki beberapa path)

Mgmtd

  • Bertanggung jawab atas registrasi node dan pemeriksaan status klaster
  • Node mendaftarkan dirinya saat boot dan secara berkala mengirim heartbeat
  • Berperan sebagai router terpusat, sehingga tidak perlu menjaga koneksi langsung antar-node
  • Juga mengelola informasi konfigurasi untuk pembentukan rantai CRAQ

Storage

  • Bertanggung jawab atas penyimpanan data aktual
  • Mengelola blok disk melalui ChunkEngine berbasis Rust
    • Melacak ukuran, offset, checksum, versi, dan sebagainya dari blok disk
    • Pengguna tidak berinteraksi langsung dengan blok, melainkan melalui antarmuka yang disediakan
    • Informasi metadata disimpan di LevelDB
  • Terdapat berbagai worker
    • AllocateWorker mengalokasikan blok baru
    • PunchHoleWorker mereklamasi blok yang tidak digunakan
    • AioReadWorker menangani pembacaan asinkron melalui antrean io_uring
  • Saat operasi tulis, data diteruskan ke node berikutnya mengikuti rantai CRAQ

Client

  • Menangani permintaan pengguna dan berkomunikasi dengan node lain
  • Alur kerja:
    • Menanyakan lokasi node ke Mgmtd
    • Meminta operasi file ke Meta
    • Mentransfer data dengan Storage

Algoritme CRAQ

  • Singkatan dari Chain Replication with Apportioned Queries, memberikan konsistensi kuat (linearizability)
  • Alur tulis:
    • Propagasi tulis berurutan dari Head → Middle → Tail
    • Pada tahap tengah, data ditandai sebagai dirty (tidak bisa dibaca)
    • Setelah commit di Tail, status clean dipropagasikan mundur
  • Alur baca:
    • Jika clean, data langsung dikembalikan
    • Jika dirty, permintaan dikirim ke tail untuk mengambil data terbaru

CRAQ dari sisi performa

  • Kecepatan tulis dibatasi oleh node yang paling lambat
  • Untuk data dirty yang sering diakses, permintaan baca dapat menumpuk di tail sehingga berpotensi menimbulkan bottleneck baca
  • Contoh: performa dapat menurun pada workload Zipfian
  • Pada klaster dengan 5 node, replikasi ke 3 node digunakan untuk meminimalkan kehilangan performa saat terjadi kegagalan

Perbedaan dengan sistem file terdistribusi lain

  • Strukturnya serupa, tetapi ada pembeda dalam penerapan nyata dan cara implementasi
  • Elemen perbandingan:
    • Workload apa yang paling cocok ditangani
    • Fleksibilitas pengaturan performa
    • Kemudahan deployment
    • Skalabilitas throughput
    • Pengelolaan latensi dalam batas SLO
    • Keandalan
  • Elemen teknis detail:
    • Penyebab bottleneck dan cara menanganinya
    • Ada tidaknya lock
    • Struktur data yang digunakan
    • Hardware target
    • Algoritme toleransi kegagalan atau metode koreksi error yang digunakan

Topik berikutnya dalam seri blog

  • Akan memverifikasi klaim DeepSeek melalui analisis performa nyata
  • Poin yang akan ditinjau:
    • Klaim DeepSeek tentang bottleneck FUSE
    • Apakah grafik performa bisa direproduksi
    • Analisis situasi penurunan performa
    • Faktor bottleneck (CPU, memori, disk, jaringan)
    • Workload seperti apa yang memberikan performa unggul
    • Analisis perbandingan dengan sistem yang sudah ada
    • Perbedaan dengan cara sistem lama menyelesaikan masalah
    • Tinjauan kemungkinan perbaikan langsung

Materi tambahan

Bacaan terkait

2 komentar

 
softer 2025-04-19

Ini memang masalah yang sedang kupikirkan, lalu ini ..
 
GN⁺ 2025-04-18
Opini Hacker News

  • S3FS adalah sistem file metadata yang dapat diskalakan, dan dibandingkan dengan berbagai sistem file terdistribusi

    • Ada Collosus, Tectonic (Meta), ADLSv2 (Microsoft), HopsFS (Hopsworks), PolarFS (Alibaba), dan lain-lain
    • S3FS menggunakan FoundationDB, Collosus menggunakan BigTable, Tectonic menggunakan KV store, dan HopsFS menggunakan RonDB
    • Hal penting dari S3FS adalah (1) mendukung klien FUSE sehingga nyaman digunakan, dan (2) mendukung penyimpanan NVMe sehingga tidak terlalu terikat pada I/O disk
    • HopsFS menambahkan penyimpanan bertingkat sehingga data terbaru disimpan di NVMe, sedangkan data arsip disimpan di S3

  • Saat mengevaluasi sistem-sistem ini, perlu mempertimbangkan batas teoretis, efisiensi, dan batas praktis

    • Secara teoretis, sistem file terdistribusi paralel seperti Lustre dapat diskalakan tanpa batas
    • Untuk menilai efisiensi, dihitung berapa banyak kapasitas penyimpanan dan throughput yang bisa diperoleh dari node dengan disk X TiB
    • Dibandingkan dengan FSx for Lustre, 3FS dapat dioperasikan di AWS dengan biaya 12–30% lebih murah
    • Masih ada pertanyaan apakah sistem file benar-benar bisa dibangun pada ukuran deployment yang diinginkan orang
    • Dapat dipahami bahwa DeepSeek membangun sistem seperti ini untuk mendapatkan karakteristik yang mereka inginkan sendiri
    • Di Archil, ada harapan untuk menemukan konfigurasi default yang lebih baik agar kebanyakan orang bisa menggunakannya tanpa harus mengelola klaster raksasa

  • Ada ketertarikan untuk membandingkannya dengan SeaweedFS

    • SeaweedFS digunakan untuk menyimpan data cuaca, dan sekitar 3 PB data dipakai untuk pelatihan ML

  • Pertanyaan tentang alasan tidak menggunakan CephFS

    • CephFS telah diuji secara menyeluruh dalam skenario dunia nyata dan terbukti andal bahkan pada skala petabyte
    • Sebagai solusi open source, CephFS dapat dijalankan di penyimpanan NVMe tercepat dan mencapai IOPS yang sangat tinggi dengan interkoneksi di atas 10 gigabit

  • Pertanyaan tentang perbandingan dengan JuiceFS

    • Ada rencana menjalankan JuiceFS di atas S3 Garage dalam pengaturan homelab pribadi
    • Garage hanya mendukung replikasi, dan tidak mendukung erasure coding atau sharding
    • Dipilih karena pengaturannya terlihat sederhana

  • Sebagai operator skala kecil dan pengguna homelab, tampaknya tidak akan ada kebutuhan untuk menggunakan sistem file terdistribusi berskala besar

    • Ada rasa penasaran tentang backup dan pemulihan saat menangani data pada skala petabyte

  • Ini memang pengaturan yang kompleks, tetapi tidak jelas fitur mana yang benar-benar esensial untuk workload deep learning

    • Fitur yang dibutuhkan adalah penyimpanan skala petabyte, paralelisme baca/tulis, dan redundansi
    • Konsistensi sulit dicapai, dan dalam konteks ini tampaknya tidak diperlukan

  • Pertanyaan tentang seberapa mudah menonaktifkan sistem file terdistribusi DeepSeek

    • Misalnya, sebuah universitas di AS mungkin mendapat persetujuan untuk menggunakan DeepSeek demi riset, tetapi datanya harus dipastikan tidak keluar dari sistem file klaster riset lokal

  • Pertanyaan apakah ini bisa direplikasi dengan drive ZFS yang terdistribusi di beberapa perangkat