중복 제거

Xet 지원 저장소는 콘텐츠 정의 청킹(CDC)을 사용하여 바이트 수준(약 64KB의 데이터, “청크”라고도 함)에서 중복을 제거합니다. 각 청크는 실제 파일 콘텐츠에 기반하여 청크 경계를 결정하는 롤링 해시로 식별되며, 이는 파일 내 어디에든 삽입 또는 삭제가 발생해도 견고합니다. Xet 인식 클라이언트를 사용하여 Xet 기반 저장소에 파일을 업로드하면, 그 콘텐츠는 이러한 가변 크기 청크로 분해됩니다. 청킹 후 Xet 저장소에 이미 존재하지 않는 새로운 청크만 유지되고, 나머지는 모두 폐기됩니다.

Chunk-level deduplication은 서버 사이드 복사 작업이 즉시 완료되는 이유이기도 합니다: 리포지토리와 버킷 간의 hf buckets cp는 데이터 재업로드 없이 콘텐츠 해시만 마이그레이션합니다. 리포지토리와 버킷 간 파일 복사를 참조하세요.

컨텐트 정의 청킹(Content-Defined Chunking)의 작동 방식

컨텐트 정의 청킹(content-defined chunking)을 이해하려면 파일을 긴 텍스트로 생각하십시오. 시스템은 롤링 해시(rolling hash)를 사용하여 데이터를 스캔합니다. 롤링 해시는 바이트 위로 이동하는 작은 수학적 함수입니다. 해시가 특정 패턴에 도달할 때마다 해당 위치에 청크 경계가 설정됩니다. 경계가 컨텐트 자체(고정된 위치가 아님)에 의해 결정되므로, 주변 컨텐트가 변경되더라도 동일한 데이터 영역은 항상 동일한 청크를 생성합니다.

고정 크기 청크를 사용하지 않는 이유는 무엇인가요?

파일 중간에 소량의 데이터를 삽입했을 때 발생하는 상황을 생각해 보세요. 고정 크기 청킹을 사용하면 삽입 지점 이후의 모든 청크 경계가 이동하여 모든 하류 청크가 무효화됩니다. 대부분의 데이터는 변경되지 않았음에도 불구하고요:

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!

5바이트만 삽입되었음에도 불구하고, 편집 이후 모든 경계가 5개 위치만큼 이동했기 때문에 8개 청크 중 3개가 변경되었습니다. 64KB 청크 크기의 실제 파일에서는 작은 편집이 수백 메가바이트에 달하는 청크를 무효화할 수 있습니다.

Content-Defined Chunking은 경계를 안정적으로 유지합니다

CDC를 사용하면 content가 패턴과 일치하는 위치에 경계가 설정되며, 고정된 간격에 설정되지 않습니다. 이는 삽입이 편집이 발생한 청크에만 영향을 미친다는 것을 의미합니다. 앞뒤의 청크는 동일하게 유지됩니다:

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)

4개 청크 중 1개만 변경되었습니다. 편집이 포함된 청크입니다. 나머지 세 개는 바이트 단위로 동일하며 중복 제거됩니다. CDC가 버전 관리 데이터에 매우 효과적인 이유는 모델 체크포인트를 업데이트하거나 데이터셋에 행을 추가할 때, 수정된 부분만 업로드 및 저장하면 되기 때문입니다.

Chunks에서 저장소까지

전체 중복 제거 파이프라인은 다음과 같이 작동합니다:

파일이 청크로 분할되면, 각 청크의 해시가 이미 저장된 내용과 대조됩니다. 이 과정은 여러 단계에서 수행됩니다. 먼저 현재 업로드 세션에서 이미 확인된 청크와 대조하고, 다음으로 이전에 업로드된 메타데이터의 로컬 캐시와 대조하며, 마지막으로 일부 청크는 전역 중복 제거 쿼리를 통해 Xet 스토리지 전체와 대조합니다. 중복된 청크는 완전히 건너뜁니다. 새로운 청크는 64 MB 블록으로 그룹화되어 업로드됩니다. 각 블록은 해시를 키로 사용하여 콘텐츠 주소 기반 스토어(CAS)에 한 번만 저장됩니다.

실무에서의 저장 공간 절약

Hub의 현재 권장 사항은 파일 크기를 200 GB로 제한하는 것입니다. 64KB의 청크 크기를 사용할 경우, 20GB 파일에는 312,500개의 청크가 포함되며, 이 중 상당수는 버전 간에 변경되지 않습니다. Git LFS는 파일이 변경되었음을 감지하고 해당 리비전의 전체 내용을 저장하도록 설계되어 있습니다. 청크 수준에서 중복을 제거하는 Xet 백엔드를 사용하면 파일 내에서 변경된 내용(몇 KB 또는 MB에 불과할 수 있음)만 저장하고, 저장소 간에 공유되는 블록을 안전하게 중복 제거할 수 있습니다. 모델 및 데이터셋 저장소에서 발견되는 대용량 바이너리 파일의 경우, 이를 통해 파일 전송 시간이 크게 개선됩니다.

For more details, refer to the From Files to Chunks and From Chunks to Blocks blog posts, or the Git is for Data paper by Low et al. that served as the launch point for XetHub prior to being acquired by Hugging Face.