피드로 돌아가기
Improving Parquet Dedupe on Hugging Face Hub
Hugging Face BlogHugging Face Blog
Backend

Hugging Face의 Xet 팀이 Parquet 파일의 Content-Defined Chunking 방식을 분석해 행 기반 Content-Defined Row Groups로 개선하여 압축된 Parquet 파일의 삭제 작업 후 데이터 중복 제거율을 89%에서 90% 이상으로 향상

Improving Parquet Dedupe on Hugging Face Hub

2024년 10월 5일8intermediate

Context

Hugging Face Hub는 약 11PB의 데이터셋을 호스팅하며 그 중 Parquet 파일이 2.2PB 이상을 차지한다. 사용자가 데이터셋을 정기적으로 업데이트할 때마다 전체를 재업로드하지 않으려면 데이터 중복 제거가 필수인데, 현재의 바이트 레벨 CDC 방식은 Parquet 구조로 인해 수정 및 삭제 작업 시 중복 제거 효율이 급격히 떨어진다.

Technical Solution

  • 바이트 레벨 Content-Defined Chunking(CDC) 분석: 행 추가 시 99.1% 중복 제거 달성(20MB 추가 스토리지)하지만, 행 수정 시는 89%로 하락하고 행 삭제 시는 절반 이상의 파일이 새로 작성됨을 확인
  • 절대 파일 오프셋 문제 해결: Parquet 열 헤더에 포함된 절대 파일 오프셋이 행 수정 시 모든 열 헤더를 재작성하도록 강제하는 원인 규명
  • 콘텐츠 정의 행 그룹(Content Defined Row Groups) 도입: 고정 행 수 대신 핵심 열의 해시 값 기반으로 행 그룹 경계를 결정(hash(key) % target_row_count = 0일 때 행 그룹 분리)
  • 실험 검증: Content-Defined Row Groups 적용 시 압축된 Parquet 파일에서도 행 삭제 후 효율적인 중복 제거 가능 확인

Impact

  • 추가(append) 작업: 새 파일이 99.1% 중복 제거되어 20MB의 추가 스토리지만 필요
  • 수정(modification) 작업: 현재 89% 중복 제거로 230MB의 추가 스토리지 필요
  • 압축 미적용 시 삭제(deletion): 중복 제거율 향상 가능하나 파일 크기가 약 2배 증가

Key Takeaway

Parquet 같은 구조화된 파일 형식에서는 바이트 레벨 청킹만으로는 부족하며, 파일 형식의 메타데이터 구조(절대 오프셋, 행 그룹 레이아웃)를 고려한 의미론적 수준의 청킹 전략이 필요하다. 형식 변경 없이도 기존 Parquet 스펙의 유연성(균등하지 않은 행 그룹 지원)을 활용해 중복 제거 효율과 압축률을 동시에 확보할 수 있다.


대규모 Parquet 데이터셋을 관리하는 데이터 허브나 데이터 레이크 환경에서 행 키의 해시 값 기반으로 행 그룹 경계를 재정의하면, 압축을 유지하면서도 삭제/수정 후 중복 제거 효율을 10~15% 향상시킬 수 있다.

원문 읽기