데이터셋 프로젝션의 조회 최적화
데이터셋 프로젝션은 특정 조회 패턴에 맞춰 별도로 저장한 데이터 표현입니다. 한 프로젝션은 보통 특정 열의 필터 또는 조인을 최적화합니다. 서로 다른 패턴이 중요하면 같은 데이터셋에 여러 프로젝션을 추가할 수 있습니다. Noho 서비스가 이를 관리합니다.
프로젝션은 스냅샷 또는 증분 방식으로 빌드하는 데이터셋에 구성할 수 있지만 입력 변경의 종류와 스키마에 제한이 있습니다.
지원 조건
지원하는 원본 트랜잭션은 APPEND, SNAPSHOT과 기존 파일을 수정하지 않고 데이터만 추가하는 UPDATE입니다. 수동 파일 및 트랜잭션 삭제나 기존 파일을 바꾸는 갱신은 추가 전용 조건을 깨뜨립니다. 시스템은 이 조건을 위반한 데이터셋을 감지하면 프로젝션을 비활성화합니다.
SNAPSHOT은 허용되지만 프로젝션이 완전히 오래된 상태가 되므로 다시 빌드하기 전에는 최적화 이점을 얻지 못합니다. 스키마 진화는 지원하지 않으며, 증분 처리에 일관된 열 추가도 예외가 아닙니다.
열 자료형은 전반적으로 지원하지만 필터 최적화의 범위 조회와 긴 문자열 등에는 별도 제약이 있습니다. 저장 방식 비교와 아래 조건을 함께 확인합니다.
순서 있는 열 목록의 필터
필터 프로젝션은 설정한 열 목록의 선두 연속 부분(prefix)에 맞는 조건을 최적화합니다. 열을 상수와 비교하는 필터여야 하며 문자열 비교는 대소문자를 구분해야 합니다.
예를 들어 순서가 x, y, z인 프로젝션에서 다음 조건은 최적화할 수 있습니다. x, y, q는 숫자 열이고 z는 문자열 열인 가상 예시입니다.
| 필터 조건 | 적용되는 부분 |
|---|---|
x = 5 AND y = 10 AND z = '15' | 세 열 전체 |
x = 5 AND y = 10 | 선두 두 열 |
x = 5 AND q = 3 | x 조건을 원천에 밀어 넣고 q 조건은 이후 평가 |
다음 조건에는 같은 최적화를 적용하지 못합니다.
| 필터 조건 | 이유 |
|---|---|
abs(x) = 10 | 열 자체가 아닌 함수 결과를 비교합니다. |
x % 100 = 10 | 열을 변환한 식의 결과를 비교합니다. |
y = 10 | y만으로는 설정 목록의 선두 연속 부분이 아닙니다. |
z = '15' | z만으로는 설정 목록의 선두 연속 부분이 아닙니다. |
x = 5 OR q = 3 | x만 먼저 필터링하면 x가 5가 아니어도 q가 3인 행을 잃습니다. |
범위 조회
범위 조회를 지원하도록 구성하면 x > 5 AND x < 10 같은 조건도 최적화할 수 있습니다. 문자열 열 s를 적절한 필터 열로 구성한 경우 s LIKE 'SOME_PREFIX%' 같은 접두사 조회에도 사용할 수 있습니다.
배열처럼 기본형이 아닌 열을 포함하는 프로젝션과 필터 열의 범위 조회 지원을 함께 구성할 수는 없습니다. 열 포함 범위와 범위 조회 옵션을 함께 결정합니다.
정확히 일치하는 조인 키
조인 프로젝션은 순서 없는 조인 열 집합과 버킷 수로 구성합니다. 키 집합이 x, y라면 두 열이 모두 같은 조건의 조인을 최적화합니다. x만으로 조인하는 것은 같은 키 집합이 아닙니다.
| 조인 구성 | 줄일 수 있는 작업 |
|---|---|
| 양쪽 모두 일반 데이터셋 | 일반적인 sort-merge join은 양쪽을 shuffle하고 정렬합니다. |
| 한쪽에 키가 맞는 프로젝션 | 프로젝션 쪽의 재분배를 줄이고 다른 쪽을 맞춰 처리할 수 있습니다. |
| 양쪽 프로젝션의 조인 키와 버킷 수가 정확히 같음 | 양쪽 shuffle을 피할 수 있습니다. |
| 프로젝션과 명시적으로 버킷을 나눈 데이터셋 | 조인 열과 버킷 수가 정확히 같으면 같은 이점을 활용할 수 있습니다. |
프로젝션이 이미 정렬되어 있어도 많은 Foundry 소비자는 기본적으로 그 정렬을 sort-merge join에 활용하지 않아 실행 계획에 정렬이 남을 수 있습니다. 변환에서 BUCKET_SORTED_SCAN_ENABLED 프로필로 기존 정렬 정보를 활용하는 방식을 바꿀 수 있지만 항상 빨라지는 것은 아니며 오히려 느려질 수도 있습니다.
집계와 기본 키 검사
해시 버킷으로 나눈 프로젝션을 집계 키에 맞춰 읽으면 집계를 위한 shuffle을 줄일 수 있습니다. 모든 조인 최적화 프로젝션은 해시 버킷을 사용하지만 필터 최적화 프로젝션은 그렇지 않을 수 있습니다.
추가 전용으로 갱신하는 데이터셋의 기본 키 검사는 특히 이점을 얻을 수 있습니다. 키 열의 프로젝션이 파일을 컴팩션하고 키별 집계에 버킷 구성을 활용할 수 있기 때문입니다.
작은 파일이 계속 쌓이는 입력
5분마다 파일 10개를 추가하는 파이프라인은 1년에 100만 개 이상의 파일을 만들 수 있습니다. 파일을 찾고 파티션 목록을 만드는 작업 자체가 부담이 됩니다. 필터 또는 조인 프로젝션은 내부 파일을 컴팩션하여 이런 입력의 읽기를 개선할 수 있습니다.
프로젝션이 최신 트랜잭션까지 완성되지 않아도 마지막 빌드 이후 원본에 SNAPSHOT, DELETE 또는 기존 파일을 수정한 UPDATE가 없다면, 지원되는 읽기는 프로젝션과 새 원본 구간을 결합하여 최적화를 활용할 수 있습니다.
업로드한 CSV 조회
CSV는 최초 수집에 편리하지만 반복 질의에는 비효율적일 수 있습니다. 변환으로 Parquet를 만드는 방법 외에도 원본 CSV에 프로젝션을 추가하여 최적화된 표현으로 읽는 방법을 사용할 수 있습니다. 원본 데이터셋에는 기존 CSV 파일이 그대로 남습니다.
구성과 선택
| 작업 | 관련 설명 |
|---|---|
| 프로젝션 생성과 빌드 | Noho 활성화, 열 및 최적화 유형, 브랜치별 스케줄을 구성합니다. |
| 내부 동작과 보존 정책 | 오래된 프로젝션의 읽기, 선택 우선순위, 비용과 대체된 파일 정리를 설명합니다. |
| Hive 방식과 비교 | 소비 엔진, 즉시 사용, 고유값 수와 데이터 형식 제약을 비교합니다. |
| Hive 방식 파일 쓰기 | Python과 Java에서 파일 경로 기반 배치를 구성합니다. |
필터 최적화 프로젝션을 활용하는 엔진은 Foundry Spark입니다. 일반 Spark나 Polars가 같은 최적화를 자동으로 사용할 것으로 가정하지 않습니다.