🖼️ 인포그래픽

🖼️ 4컷 인포그래픽

💡 한 줄 요약

파케이 콘텐츠 정의 청킹은 유사한 파케이 파일에서 변경된 데이터 조각만 전송하도록 해, 허깅 페이스 허브의 업로드·다운로드 시간과 저장 비용을 크게 줄이는 기능이다.

📌 핵심 요약

• 허깅 페이스는 약 21페타바이트의 데이터셋 중 파케이 파일이 4페타바이트 이상을 차지하는 상황에서, 제트 저장 계층과 파케이 콘텐츠 정의 청킹을 결합해 중복 데이터 전송을 줄이고자 했다.
• 파케이는 작은 논리적 변경도 압축된 바이트 배열 전체를 다르게 만들 수 있으므로, 일반적인 형식 비의존 청킹만으로는 중복 제거 효율이 낮아질 수 있다.
• 파이애로와 판다스에서 콘텐츠 정의 청킹 옵션을 활성화하면 새 열, 형식이 바뀐 열, 갱신된 메타데이터처럼 실제로 달라진 조각만 업로드할 수 있다.
• 실험에서는 96.1메가바이트짜리 동일 테이블을 다시 올릴 때 전송량이 0바이트였고, 다른 저장소로 복사해도 저장소 간 중복 제거가 적용됐다.
• 열 추가·삭제와 열 자료형 변경에서도 전체 파일 대신 수십∼수백 킬로바이트만 전송됐으며, 원문은 이후 행 추가·삭제, 행 그룹 크기, 파일 분할 변화까지 시험 대상으로 제시한다.

🧩 주요 포인트

1. 허깅 페이스는 약 21페타바이트의 데이터셋 중 파케이 파일이 4페타바이트 이상을 차지하는 상황에서, 제트 저장 계층과 파케이 콘텐츠 정의 청킹을 결합해 중복 데이터 전송을 줄이고자 했다.
2. 파케이는 작은 논리적 변경도 압축된 바이트 배열 전체를 다르게 만들 수 있으므로, 일반적인 형식 비의존 청킹만으로는 중복 제거 효율이 낮아질 수 있다.
3. 파이애로와 판다스에서 콘텐츠 정의 청킹 옵션을 활성화하면 새 열, 형식이 바뀐 열, 갱신된 메타데이터처럼 실제로 달라진 조각만 업로드할 수 있다.
4. 실험에서는 96.1메가바이트짜리 동일 테이블을 다시 올릴 때 전송량이 0바이트였고, 다른 저장소로 복사해도 저장소 간 중복 제거가 적용됐다.
5. 열 추가·삭제와 열 자료형 변경에서도 전체 파일 대신 수십∼수백 킬로바이트만 전송됐으며, 원문은 이후 행 추가·삭제, 행 그룹 크기, 파일 분할 변화까지 시험 대상으로 제시한다.

🧠 상세 정리

1. 대규모 파케이 저장소가 직면한 중복 전송 문제

아파치 파케이는 데이터 엔지니어링에서 널리 쓰이는 열 지향 저장 형식이지만, 대규모 저장소에서는 파일을 조금만 수정해도 상당한 데이터가 다시 전송될 수 있다. 허깅 페이스가 보유한 데이터셋은 약 21페타바이트이며, 이 가운데 파케이 파일만 4페타바이트 이상이어서 저장 및 전송 효율 개선이 중요한 과제로 제시된다. 새 제트 저장 계층은 데이터 내용을 기준으로 조각을 나누고 이미 존재하는 조각을 재사용해 저장 비용과 업로드·다운로드 시간을 줄인다. 다만 파케이는 열 조각과 데이터 페이지 단위로 압축되므로, 작은 논리적 변경도 파일의 바이트 표현을 크게 바꾸어 일반적인 중복 제거 효율을 떨어뜨릴 수 있다. 파케이 콘텐츠 정의 청킹은 유사한 데이터가 가능한 한 비슷한 바이트 구조를 유지하도록 파일을 작성해 이 문제를 완화하는 기능이다.

2. 콘텐츠 정의 청킹의 사용 방법과 핵심 효과

콘텐츠 정의 청킹 기능은 파이애로와 판다스에서 사용할 수 있으며, 파케이 파일을 기록할 때 콘텐츠 정의 청킹 사용 옵션을 참으로 지정하는 방식으로 활성화한다. 저장 대상에는 허깅 페이스의 전용 주소 형식을 직접 사용할 수 있어, 별도의 중간 업로드 절차 없이 데이터프레임이나 파이애로 테이블을 허브에 기록할 수 있다. 핵심 효과는 파일 전체가 아니라 이전 버전과 달라진 데이터 조각만 새로 업로드하거나 다운로드한다는 점이다. 이미 저장 계층에 존재하는 조각은 다시 전송하지 않으므로 동일 파일 복사, 열 추가·삭제, 일부 열의 자료형 변경과 같은 반복 작업에서 전송량과 저장량을 줄일 수 있다. 원문은 이 기능이 파이애로 21.0.0 이상에서 제공되는 허깅 페이스 주소 지원과 결합돼 보다 직접적인 데이터 작업 흐름을 만든다고 설명한다.

3. 오픈오르카 기반 실험 데이터 준비

실험에는 오픈오르카 데이터셋의 관리 가능한 크기인 일부 구간이 사용됐다. 원본 파케이 파일을 허깅 페이스 허브의 로컬 캐시로 내려받은 뒤, 식별자·시스템 지시문·질문·응답 필드를 지정한 스키마로 읽어 파이애로 테이블을 구성했다. 이어 질문과 응답의 문자열 길이를 계산한 열을 각각 추가하고, 저장 계층에 이미 알려진 배열과 겹치는 상황을 피하기 위해 고정된 난수 시드로 행 순서를 섞었다. 최종 실험 테이블은 처음 10만 행으로 제한됐으며 식별자, 시스템 지시문, 질문 길이, 질문, 응답 길이, 응답으로 이루어진 여섯 개 열을 포함했다. 이 준비 과정은 이후 파일 복사, 열 변경, 자료형 변경 등 여러 상황에서 같은 기준 데이터를 비교하기 위한 것이다.

4. 최초 업로드와 허깅 페이스 주소를 통한 직접 입출력

준비한 테이블을 처음 허깅 페이스 허브에 기록했을 때 전체 크기와 실제 전송량은 모두 96.1메가바이트로 나타났다. 해당 데이터가 제트 저장 계층에 아직 알려지지 않았기 때문에 최초 업로드에서는 파일 전체가 새로운 데이터로 처리됐고, 제시된 전송 속도는 초당 48.0킬로바이트였다. 업로드한 파일은 같은 허깅 페이스 주소를 이용해 다시 파이애로 테이블로 읽었으며, 원본 테이블과 정확히 동일하다는 검증도 수행됐다. 원문은 파일 경로를 받는 파이애로 기능이라면 데이터셋 처리, 쉼표 구분값 처리, 증분 파케이 기록, 메타데이터 읽기 등에서도 같은 주소 방식을 사용할 수 있다고 설명한다. 실제 메타데이터 확인 결과 파일에는 열 여섯 개가 아니라 여섯 개, 행 10만 개, 행 그룹 한 개가 기록돼 있었고 형식 버전은 2.6이었다.

5. 동일 파일 재업로드와 저장소 간 중복 제거

첫 번째 검증은 동일한 테이블을 다른 파일 이름으로 다시 업로드하는 상황이었다. 전통적인 파일 시스템에서는 같은 내용이어도 별도 파일로 저장하거나 전송할 수 있지만, 콘텐츠 기준 저장 방식은 파일 내용이 이미 존재한다는 사실을 식별할 수 있다. 실험에서 전체 파일 크기는 96.1메가바이트로 표시됐지만 실제 신규 전송량은 0바이트였고, 작업도 즉시 완료됐다. 같은 파일을 기존 저장소가 아닌 다른 저장소에 다시 기록했을 때도 전송량은 0바이트로 유지됐다. 이는 중복 제거 범위가 한 저장소 내부에만 제한되지 않고 저장소 사이에도 적용된다는 결과이며, 원문은 이를 데이터 공유와 협업을 효율화하는 제트 저장 계층의 핵심 특징으로 평가한다.

6. 열 추가와 삭제에서 확인된 부분 전송

원본 테이블에 응답 문자열의 앞부분을 담는 새 열을 추가한 파일은 로컬 기준으로 원본과 비슷한 약 92메가바이트였지만, 허브에 올릴 때 실제로 전송된 신규 데이터는 575킬로바이트에 그쳤다. 기존 열의 데이터 페이지는 저장 계층에 이미 존재했기 때문에 새 열에 해당하는 데이터와 변경된 파케이 꼬리말 메타데이터만 전송된 것이다. 반대로 큰 응답 열을 제거한 파일은 로컬 크기가 약 67메가바이트로 줄었으며, 업로드 전송량은 37.7킬로바이트에 불과했다. 열 삭제는 남아 있는 열의 내용을 바꾸지 않으므로 대부분의 데이터 조각을 그대로 재사용하고, 주로 파일 구조를 설명하는 메타데이터만 갱신하면 된다. 이 결과는 열 중심 구조를 가진 파케이에서 스키마 일부를 수정할 때 콘텐츠 기준 중복 제거가 특히 효과적일 수 있음을 보여준다.

7. 시각화로 본 데이터 페이지와 메타데이터의 변화

원문은 전용 중복 제거 추정 도구를 이용해 두 파케이 파일 사이에서 재사용되는 영역과 새로 전송해야 하는 영역을 시각화했다. 열을 추가한 경우 새 데이터 페이지와 파일 끝의 갱신된 메타데이터가 변경 영역으로 나타났고, 나머지 기존 열은 재사용 가능한 영역으로 남았다. 압축하지 않은 경우와 스내피 압축을 사용한 경우 모두 표시된 중복 비율은 약 50퍼센트였으며, 여기서 더 작은 비율은 더 높은 중복 제거 성능을 뜻한다. 열을 제거한 비교에서는 데이터 열 대부분이 그대로 유지되고 꼬리말 메타데이터가 주된 변경 영역으로 나타났으며, 표시된 비율은 약 57∼58퍼센트였다. 이러한 시각화는 논리적으로는 단순한 열 변경이 실제 파케이 파일에서 어느 데이터 페이지와 메타데이터를 바꾸는지 구분해 보여준다.

8. 열 자료형 변경 결과와 이어지는 검증 범위

세 번째 상세 실험은 저장 크기 축소나 질의 최적화를 위해 열의 자료형을 바꾸는 상황을 다룬다. 차이를 명확히 보기 위해 질문과 응답 같은 큰 문자열 열을 먼저 제거한 뒤, 질문 길이 열을 64비트 정수에서 32비트 정수로 변환했다. 변경된 파일의 전체 크기는 1.80메가바이트였지만 실제 신규 업로드량은 181킬로바이트였으며, 새로 표현된 열 데이터와 갱신된 꼬리말 메타데이터만 전송됐다. 시각화에서도 해당 열과 메타데이터가 변경 영역으로 표시되고 나머지 열은 재사용됐으며, 제시된 중복 비율은 압축 여부에 따라 약 52∼53퍼센트였다. 원문은 이 밖에도 새 행 추가와 테이블 연결, 행 삽입·삭제, 행 그룹 크기 변경, 파일 수준 분할 변화까지 검증 대상으로 열거하지만, 제공된 본문은 새 행을 덧붙이는 실험을 시작하는 부분에서 끝난다.

🧾 핵심 주장 / 시사점

• 파케이 중복 제거의 성패는 데이터의 논리적 유사성만이 아니라 압축 이후 바이트 구조가 얼마나 안정적으로 유지되는지에 달려 있다.
• 열 단위 변경에서는 기존 데이터 페이지를 그대로 재사용하고 새 열이나 꼬리말 메타데이터만 전송할 수 있어, 전체 파일 크기와 실제 전송량 사이에 큰 차이가 생긴다.
• 저장소 간에도 동일 조각을 재사용하는 구조는 같은 데이터셋의 복사본과 여러 변형본을 다루는 협업 환경에서 불필요한 업로드를 줄이는 근거가 된다.

✅ 액션 아이템

• 파케이 업로드 파이프라인에서 콘텐츠 정의 청킹 적용 여부를 새 열·형식 변경·메타데이터 갱신 변경분 위주로 구체화한다.
• 동일 테이블 재전송에서 0바이트 전송 사례를 기준으로, 변경 탐지·중복 제거 동작의 일관성과 전송량 지표를 점검한다.
• 열 추가·삭제·자료형 변경뿐 아니라 행 추가·삭제, 행 그룹 크기, 파일 분할 변화까지 포함해 수신 전송량이 수십~수백KB 수준인지 비교 검증한다.

❓ 열린 질문

• 저장소 간 복제 시에도 중복 제거가 유지되려면 어떤 버전 조건과 동기화 기준이 필요한가?
• 형식 비의존 청킹 대비 콘텐츠 정의 청킹의 효율이 높아지는 데이터 변경 유형은 어디인가?
• 행 추가·삭제, 행 그룹 크기, 파일 분할 변화가 생길 때 허용 가능한 전송량 상한은 어떻게 설정할 것인가?