Deduplikasi

Repositori yang mendukung Xet memanfaatkan content-defined chunking (CDC) untuk deduplikasi pada level byte (~64KB data, juga disebut sebagai “chunk”). Setiap chunk diidentifikasi oleh rolling hash yang menentukan batas chunk berdasarkan konten file yang sebenarnya, sehingga tahan terhadap penyisipan atau penghapusan di mana pun dalam file. Ketika file diunggah ke reposisi yang didukung Xet menggunakan klien yang mendukung Xet, kontennya dipecah menjadi chunk berukuran variabel ini. Hanya chunk baru yang belum ada di penyimpanan Xet yang disimpan setelah chunking, sisanya dibuang.

Deduplikasi pada tingkat chunk juga yang membuat salinan sisi server menjadi instan: hf buckets cp antara repositori dan bucket hanya memigrasi hash konten, tanpa mengunggah ulang data. Lihat Menyalin file antar repositori dan bucket.

Cara Kerja Chunking yang Didefinisikan Konten

Untuk memahami chunking yang didefinisikan berdasarkan konten, bayangkan sebuah file sebagai paragraf teks yang panjang. Sistem memindai data menggunakan rolling hash — sebuah fungsi matematika kecil yang bergeser di atas byte. Setiap kali hash mencapai pola khusus, batas chunk ditempatkan pada posisi tersebut. Karena batas-batas ini ditentukan oleh konten itu sendiri (bukan oleh posisi tetap), wilayah data yang identik selalu menghasilkan chunk yang sama, bahkan jika konten di sekitarnya berubah.

Mengapa Tidak Menggunakan Chunk Berukuran Tetap?

Pertimbangkan apa yang terjadi ketika Anda menyisipkan sejumlah kecil data di tengah file. Dengan pengchunkan ukuran tetap, setiap batas chunk setelah penyisipan akan bergeser, sehingga membatalkan semua chunk di hilir — meskipun sebagian besar data tidak berubah:

Original file, fixed 6-byte chunks:

  |The qu|ick br|own fo|x jump|s over| the l|azy do|g     |
  chunk1  chunk2 chunk3 chunk4 chunk5 chunk6 chunk7 chunk8

Insert "very " before "lazy":

  |The qu|ick br|own fo|x jump|s over| the v|ery la|zy dog|
  chunk1  chunk2 chunk3 chunk4 chunk5 chunk6 chunk7 chunk8
                                       ~~~~~~ ~~~~~~ ~~~~~~
                                        3 chunks changed!

Meskipun hanya 5 byte yang disisipkan, 3 dari 8 chunk berubah karena semua batas setelah pengeditan bergeser 5 posisi. Pada file nyata dengan ukuran chunk 64KB, pengeditan kecil dapat membatalkan ratusan megabyte chunk.

Chunking Berdefinisi Konten Menjaga Batas Tetap Stabil

Dengan CDC, batas ditempatkan di mana konten cocok dengan pola — bukan pada interval tetap. Ini berarti penyisipan hanya memengaruhi chunk tempat pengeditan terjadi. Chunk sebelum dan sesudahnya tetap identik:

Original file, content-defined chunks (boundaries marked by "|"):

  |The quick |brown fox |jumps over |the lazy dog|
    chunk 1     chunk 2    chunk 3     chunk 4

Insert "very " before "lazy":

  |The quick |brown fox |jumps over |the very lazy dog|
    chunk 1     chunk 2    chunk 3     chunk 4'
    (same)      (same)     (same)      (changed)

Hanya 1 dari 4 chunk yang berubah — yaitu chunk yang memuat editan. Tiga chunk lainnya identik per byte dan dideduplikasi. Inilah mengapa CDC sangat efektif untuk data berversi: saat Anda memperbarui checkpoint model atau menambahkan baris ke dataset, hanya bagian yang dimodifikasi yang perlu diunggah dan disimpan.

Dari Chunks ke Penyimpanan

Pipeline deduplikasi lengkap bekerja sebagai berikut:

Ketika sebuah file dipecah menjadi beberapa chunk, hash dari setiap chunk diperiksa terhadap data yang sudah tersimpan. Proses ini terjadi pada beberapa tingkatan: pertama, terhadap chunk yang sudah terlihat dalam sesi unggah saat ini; kemudian, terhadap cache lokal dari metadata yang diunggah sebelumnya; dan akhirnya, sebagian subset chunk diperiksa terhadap seluruh penyimpanan Xet melalui query deduplikasi global. Chunk duplikat dilewati sepenuhnya. Chunk baru dikelompokkan menjadi blok berukuran 64 MB dan diunggah. Setiap blok disimpan sekali di dalam content-addressed store (CAS), dengan hash-nya sebagai kunci.

Hemat Penyimpanan dalam Praktik

Rekomendasi saat ini dari Hub adalah membatasi ukuran file hingga 200 GB. Dengan ukuran chunk 64KB, file berukuran 20GB memiliki 312.500 chunk, di mana banyak di antaranya tidak berubah dari satu versi ke versi lainnya. Git LFS dirancang untuk hanya mendeteksi bahwa sebuah file telah berubah dan menyimpan keseluruhan revisi tersebut. Dengan melakukan deduplikasi pada level chunk, backend Xet memungkinkan penyimpanan hanya konten yang dimodifikasi dalam sebuah file (yang mungkin hanya beberapa KB atau MB) serta melakukan deduplikasi blok yang dibagikan antar repositori secara aman. Untuk file biner besar yang ditemukan di repositori Model dan Dataset, hal ini memberikan peningkatan signifikan pada waktu transfer file.

Untuk detail lebih lanjut, lihat posting blog Dari File ke Chunk dan Dari Chunk ke Blok, atau makalah Git adalah untuk Data oleh Low et al. yang menjadi titik awal peluncuran XetHub sebelum diakuisisi oleh Hugging Face.