프로젝션과 Hive 방식 파티셔닝 비교
필터 프로젝션과 Hive 방식 파티셔닝은 특정 열로 조회할 때 읽을 데이터를 줄인다는 목적이 겹칩니다. 원본을 직접 어떤 파일로 쓸지, 별도 조회 표현을 유지할지와 소비 엔진에 따라 선택합니다.
| 기준 | 데이터셋 프로젝션 | Hive 방식 파티셔닝 |
|---|---|---|
| 파일 정리 | 프로젝션 빌드가 자동 컴팩션을 수행합니다. | 이 배치 자체가 자동 컴팩션을 제공하지 않습니다. |
| 사용 시작 | 원본 커밋 후 비동기 프로젝션 빌드가 필요합니다. | 해당 파일을 쓴 뒤 바로 배치 정보를 이용할 수 있습니다. |
| 원본 스냅샷 | 새 스냅샷 뒤에는 프로젝션 재빌드 전까지 최적화 이점이 없습니다. | 새 스냅샷도 같은 방식으로 썼다면 즉시 사용할 수 있습니다. |
| 데이터 형식 | 필터 최적화는 전용 형식을 사용하고 매우 긴 문자열 등에 제약이 있습니다. | 일반적으로 공개 Apache Parquet 형식으로 기록합니다. |
| 고유값이 많은 열 | 필터 프로젝션은 높은 카디널리티와 시계열 타임스탬프 같은 열에 적합하도록 설계되었습니다. | 고유값 조합마다 최소 하나의 파일이 필요하여 파일 수가 지나치게 늘 수 있습니다. |
| 소비 엔진 | 필터 최적화 프로젝션을 활용하는 엔진은 Foundry에서 사용하는 Foundry Spark입니다. | Spark, Polars와 다른 지원 조회 엔진이 배치 정보를 활용할 수 있습니다. |
| 파일 API의 직접 활용 | 같은 방식으로 사용자 코드에 노출되지 않습니다. | Python 또는 Java 파일시스템 코드에서 경로의 파티션 값을 이용한 최적화를 구현할 수 있습니다. |
하나의 데이터셋을 여러 다른 필터 또는 조인 패턴에 맞추거나 작은 증분 파일을 계속 정리해야 하면 프로젝션을 검토합니다. 여러 엔진에서 바로 읽거나 파일 경로를 직접 활용해야 하고 파티션 열의 고유값 수가 적절하다면 Hive 방식이 맞을 수 있습니다.
프로젝션의 열 범위와 트랜잭션 및 스키마 제약, 비동기 갱신 비용은 별도로 고려합니다. 원본과 프로젝션을 함께 유지하는 저장 비용 및 컴팩션 이력 정리는 내부 동작에서 설명합니다.