열지향 저장 방식

열 지향 저장 방식은 데이터를 테이블의 행 단위가 아닌, 컬럼(열) 단위로 연속적으로 배치하고 저장하는 방식을 의미한다. 이는 전통적인 행 지향 저장 방식과 근본적으로 다른 데이터 배치 전략이다.

구체적으로, 하나의 테이블에서 모든 레코드의 첫 번째 컬럼 값들을 연속된 블록으로 저장한 후, 그 다음으로 모든 레코드의 두 번째 컬럼 값들을 또 다른 블록으로 저장하는 식으로 진행된다. 예를 들어, 고객 테이블에 ID, 이름, 나이, 도시 컬럼이 있다면, 열 지향 저장은 모든 고객의 ID 값을 모아 저장하고, 그 뒤에 모든 고객의 이름 값을 모아 저장하는 방식으로 데이터를 구성한다.

이러한 물리적 배치는 데이터가 디스크나 메모리에 실제로 기록되는 구조를 결정하며, 쿼리 처리 성능에 직접적인 영향을 미친다. 특정 컬럼만을 읽어야 하는 분석 질의의 경우, 필요한 컬럼의 데이터 블록만 효율적으로 접근할 수 있어 불필요한 I/O를 크게 줄일 수 있다.

행 지향 저장 방식은 레코드나 튜플 단위로 데이터를 연속적으로 저장하는 전통적인 방식이다. 예를 들어, 고객 정보 테이블의 경우 각 고객의 ID, 이름, 주소, 구매이력 등 모든 컬럼 값이 하나의 행으로 묶여 디스크에 기록된다. 이 방식은 단일 레코드의 삽입, 갱신, 삭제와 같은 OLTP 작업에 효율적이다. 전체 레코드를 한 번의 I/O 연산으로 읽거나 쓸 수 있기 때문이다.

반면, 열 지향 저장 방식은 각 컬럼별로 값을 모아서 별도의 데이터 블록에 저장한다. 동일한 테이블에서 모든 행의 '구매금액' 컬럼 값들은 함께 저장되고, '주소' 컬럼 값들은 또 다른 곳에 모여 저장된다. 이는 특정 컬럼만을 대상으로 하는 집계 쿼리나 분석 작업에서 결정적인 차이를 만든다. 쿼리가 '구매금액'의 평균을 요구할 경우, 행 지향 방식은 모든 컬럼을 포함한 전체 행을 디스크에서 읽어야 하지만, 열 지향 방식은 해당 컬럼의 데이터 블록만 읽으면 된다.

두 방식의 성능 특성은 워크로드에 따라 극명하게 갈린다. 비교는 다음과 같이 요약할 수 있다.

결론적으로, 행 지향 방식은 데이터의 '수정'에, 열 지향 방식은 데이터의 '조회'와 '분석'에 각각 특화되어 있다. 현대의 하이브리드 트랜잭션/분석 처리 시스템은 이 두 방식을 상황에 따라 결합하거나, 메모리와 스토리지 계층을 다르게 활용하는 방식으로 발전하고 있다.

열지향 저장 방식에서 데이터는 테이블의 각 컬럼별로 물리적으로 함께 저장된다. 이는 행 지향 저장 방식이 하나의 레코드에 속한 모든 컬럼 값을 연속적으로 배치하는 것과 근본적으로 다르다. 예를 들어, 고객 테이블에 고객ID, 이름, 나이, 도시 컬럼이 있다면, 열지향 방식에서는 모든 고객ID 값이 하나의 블록에, 모든 이름 값이 다른 블록에 저장되는 식이다.

이러한 배치 방식은 데이터가 디스크에 저장되는 물리적 순서를 결정한다. 아래 표는 두 방식의 데이터 배치 차이를 보여준다.

컬럼 단위 배치의 핵심 장점은 특정 분석 쿼리를 처리할 때 디스크로부터 읽어야 하는 데이터 양을 극적으로 줄일 수 있다는 점이다. "평균 나이를 구하라"는 쿼리는 열지향 저장에서 나이 컬럼이 모여 있는 블록 C만 읽으면 된다. 반면 행 지향 저장에서는 네 명의 고객에 대한 모든 컬럼 데이터(블록 A, B, C, D에 해당하는 전체 행)를 읽은 후 필요한 나이 값만 추출해야 한다.

또한, 같은 데이터 유형의 값들이 연속적으로 배치되기 때문에 압축 효율이 매우 높아진다. 유사한 값들은 런 렝스 인코딩이나 딕셔너리 인코딩과 같은 효율적인 인코딩 기법을 적용하기에 이상적이다[1]. 이는 저장 공간을 절약할 뿐만 아니라, 디스크 I/O 대역폭을 더 효율적으로 사용하게 만든다.

Parquet는 Apache Software Foundation이 개발한 오픈 소스 열지향 저장 방식 데이터 파일 포맷이다. 하둡 에코시스템을 비롯한 다양한 빅데이터 처리 프레임워크에서 널리 사용되는 표준 형식 중 하나로 자리 잡았다. 이 포맷은 복잡한 중첩 데이터 구조를 효율적으로 저장할 수 있도록 설계되었으며, Apache Thrift를 기반으로 한 메타데이터 정의를 사용한다.

Parquet 파일의 핵심 구조는 행 그룹, 컬럼 청크, 페이지로 구성된다. 데이터는 먼저 행 그룹으로 나뉘며, 각 행 그룹 내에서 컬럼별 데이터는 물리적으로 연속된 청크로 저장된다. 이 컬럼 청크는 다시 하나 이상의 페이지로 구성되는데, 페이지는 압축 및 인코딩의 기본 단위가 된다. Parquet는 런 렝스 인코딩, 딕셔너리 인코딩, 델타 인코딩 등 다양한 인코딩 방식을 지원하여 데이터 유형과 패턴에 맞춰 높은 압축률을 달성한다.

주요 특징으로는 스키마 진화를 지원한다는 점을 들 수 있다. 파일에 저장된 스키마 정보와 실제 읽기를 요청하는 애플리케이션의 스키마가 다를 경우, 호환 가능한 범위 내에서 자동으로 병합되거나 프로젝션된다. 또한, 각 파일, 행 그룹, 컬럼 청크 수준에 상세한 통계 정보(최소값, 최대값, Null 값 개수 등)를 포함하여, 프레디케이트 푸시다운과 같은 쿼리 최적화를 가능하게 한다.

ORC는 Apache Hive 프로젝트에서 개발된 열지향 저장 방식의 파일 포맷이다. Optimized Row Columnar의 약자로, 이름 그대로 행과 열을 최적화한 저장 방식을 의미한다. 초기 Hive의 RCFile 포맷의 한계를 극복하고 성능을 개선하기 위해 설계되었다. Hadoop 에코시스템, 특히 Hive와 Spark에서 널리 사용되는 주요 포맷 중 하나이다.

ORC 파일은 데이터를 스트라이프, 로우 그룹, 풋터라는 세 가지 수준으로 구성한다. 각 스트라이프는 일반적으로 256MB 크기로, 독립적으로 처리될 수 있는 데이터의 기본 단위이다. 스트라이프 내에는 보통 10,000개 행으로 구성된 여러 로우 그룹이 존재하며, 각 컬럼의 데이터는 이 로우 그룹 단위로 함께 저장된다. 파일의 끝에는 풋터가 위치하여 파일의 메타데이터(행 수, 각 컬럼의 데이터 타입 정보, 통계 정보 등)를 포함한다.

ORC는 다양한 고급 인코딩과 압축 기법을 적용하여 높은 효율성을 제공한다. 정수형 데이터에는 정수 런-렝스 인코딩이나 델타 인코딩을, 문자열 데이터에는 사전 인코딩을 사용한다. 이후 ZLIB, SNAPPY, ZSTD와 같은 범용 압축 알고리즘을 추가로 적용하여 저장 공간을 절약한다. 또한, 각 컬럼과 로우 그룹 수준에 최소값, 최대값, 합계, NULL 개수와 같은 통계 정보를 저장하여, 쿼리 실행 시 조건자 푸시다운 최적화를 가능하게 하여 불필요한 I/O를 크게 줄인다.

RCFile(Record Columnar File)은 하둡 생태계에서 초기에 등장한 열지향 저장 방식 포맷이다. 아파치 하이브 프로젝트의 일부로 개발되어, 기존의 행 지향 파일 포맷과 컬럼형 저장의 장점을 절충하고자 했다.

RCFile은 파일을 먼저 행 기반으로 '로우 그룹'으로 나눈 후, 각 그룹 내에서 데이터를 컬럼 단위로 저장하는 하이브리드 방식을 사용한다. 이 구조는 데이터를 로드할 때 행 지향 저장 방식처럼 한 번에 하나의 로우 그룹을 메모리에 올린 후, 필요한 컬럼만 선택적으로 읽을 수 있게 한다. 주요 구성 요소는 다음과 같다.

RCFile은 데이터 압축 효율과 쿼리 성능 향상이라는 열지향 저장 방식의 기본 이점을 제공했지만, 후속 포맷들에 비해 제한적이었다. 특히, Parquet나 ORC 포맷과 달리 각 컬럼 내에서도 다양한 인코딩 방식을 지원하지 않았고, 인덱싱이나 복잡한 데이터 타입에 대한 지원이 미흡했다. 그럼에도 불구하고, 하둡 기반 초기 데이터 웨어하우스 환경에서 행 지향 파일에서 컬럼형 저장으로의 전환을 촉진하는 역할을 했다.

열지향 저장 방식의 가장 큰 강점 중 하나는 동일한 데이터 유형을 가진 값들을 연속적으로 배치함으로써 얻어지는 높은 데이터 압축 효율이다. 행 지향 저장에서는 각 행에 다양한 데이터 타입(예: 정수, 문자열, 날짜)이 섞여 있어 압축 알고리즘이 적용하기 어렵지만, 열지향 방식에서는 한 컬럼 내의 모든 값이 동일한 유형을 가지므로 훨씬 효율적인 압축이 가능해진다.

주로 사용되는 압축 기법으로는 런 렝스 인코딩, 딕셔너리 인코딩, 델타 인코딩 등이 있다. 예를 들어, 많은 행에서 반복되는 값(예: 국가 코드 'KR')은 딕셔너리 인코딩을 통해 정수 ID로 매핑되고, 연속된 동일한 값(예: 성별 'M'이 100번 연속)은 런 렝스 인코딩으로 압축된다. 또한 정렬된 숫자 데이터는 델타 인코딩을 통해 인접 값 간의 차이만 저장하여 데이터 크기를 크게 줄인다.

이러한 고효율 압축은 직접적으로 저장 공간 절약과 I/O 비용 감소로 이어진다. 디스크에서 읽어야 할 데이터의 물리적 크기가 줄어들기 때문에, 특히 대규모 데이터 세트를 스캔하는 분석 쿼리의 성능이 향상된다. 압축된 데이터는 메모리로 로드될 때에도 더 적은 공간을 차지하므로, 캐시 효율성이 높아지고 더 많은 데이터를 메모리에 유지할 수 있게 된다.

결과적으로, 열지향 저장은 데이터 웨어하우스나 빅데이터 분석 환경에서 테라바이트 또는 페타바이트 규모의 데이터를 저장할 때 전체 저장 비용을 낮추고, 동시에 압축 해제 오버헤드보다 절감된 I/O량이 훨씬 커 전반적인 처리 처리량을 높이는 핵심 메커니즘으로 작동한다.

열지향 저장 방식은 특정 컬럼만 읽어야 하는 분석 쿼리에서 행 지향 방식보다 월등한 성능을 보인다. 쿼리가 필요한 컬럼만 디스크에서 읽어오기 때문에 불필요한 데이터 I/O를 크게 줄일 수 있다. 예를 들어, 수억 개의 판매 기록에서 특정 기간의 총매출만 집계하는 쿼리는 날짜와 금액 컬럼만 접근하면 된다. 이 경우, 행 단위로 모든 컬럼을 읽는 방식에 비해 디스크 읽기 양이 극적으로 감소한다.

또한, 동일한 데이터 타입의 값들이 연속적으로 저장되기 때문에 벡터화 처리와 같은 현대 CPU의 고급 최적화 기법을 효과적으로 활용할 수 있다. SIMD 명령어를 사용해 한 번의 연산으로 여러 데이터 값을 동시에 처리할 수 있어 집계 및 필터링 연산 속도가 크게 향상된다. 컬럼 내 데이터의 지역성도 높아 CPU 캐시 히트율을 개선하는 데 도움을 준다.

특정 컬럼에 대한 필터링이 효율적으로 이루어질 수 있어, 쿼리 실행 계획 최적화에도 유리하다. 조기 종료가 가능한 경우, 조건을 만족하지 않는 데이터를 빠르게 스킵할 수 있다. 특히 런 렝스 인코딩과 같은 인코딩을 적용하면, 압축된 청크 단위로 데이터를 평가하여 처리량을 더욱 높일 수 있다.

이러한 특성들로 인해, OLAP 워크로드를 처리하는 데이터 웨어하우스나 빅데이터 분석 시스템에서 열지향 저장 포맷은 표준으로 자리 잡았다.

열지향 저장 방식에서 I/O 효율성은 행 지향 저장 방식에 비해 가장 두드러지는 장점 중 하나이다. 이는 데이터가 컬럼 단위로 물리적으로 배치되기 때문에 발생하는 근본적인 특성이다.

쿼리가 특정 컬럼만 요구할 경우, 저장 시스템은 필요한 컬럼의 데이터 블록만 디스크에서 읽어 들인다. 예를 들어, 100개의 컬럼을 가진 테이블에서 SUM(매출액)과 AVG(할인율) 두 개의 컬럼만 조회하는 분석 쿼리가 있다고 가정하자. 행 지향 방식은 각 행의 모든 100개 컬럼 데이터를 읽어야 하지만, 열 지향 방식은 오직 '매출액'과 '할인율' 컬럼에 해당하는 데이터 페이지만 읽으면 된다. 이로 인해 불필요한 I/O를 현저히 줄일 수 있으며, 이는 특히 대규모 데이터셋에서 디스크 대역폭과 읽기 시간을 절약하는 데 결정적인 역할을 한다.

또한, 컬럼 내 데이터는 유형과 의미가 동일하기 때문에 고도로 최적화된 인코딩 방식과 데이터 압축을 적용하기 용이하다. 동일한 값이 연속적으로 나타나는 경우가 많아 압축률이 높아지고, 결과적으로 디스크에서 읽어야 할 물리적 데이터의 양 자체가 줄어든다. 이는 네트워크를 통한 데이터 전송 시에도 이점으로 작용한다. 따라서 쿼리 성능 향상은 단순히 읽는 데이터 양의 감소뿐만 아니라, 압축된 데이터를 메모리로 로드하는 속도와 CPU 캐시 활용 효율이 높아지는 복합적인 효과에서 비롯된다.

쓰기 작업은 데이터를 행 단위가 아닌 컬럼 단위로 분리하여 저장해야 하므로, 추가적인 처리 오버헤드가 발생합니다. 새로운 레코드 하나를 삽입하려면 각 컬럼의 데이터를 해당 컬럼 저장소의 적절한 위치에 배치해야 합니다. 이 과정은 행 지향 저장 방식에서 단일 블록에 모든 데이터를 순차적으로 기록하는 것보다 복잡하고 비용이 많이 듭니다.

이 오버헤드는 특히 작은 규모의 쓰기나 온라인 트랜잭션 처리 환경에서 두드러집니다. 트랜잭션이 여러 컬럼을 업데이트할 경우, 각 컬럼 파일을 별도로 수정해야 하므로 디스크 I/O 횟수가 증가하고 잠금 관리가 복잡해질 수 있습니다. 결과적으로, 높은 동시성과 낮은 지연 시간을 요구하는 실시간 업데이트에는 적합하지 않은 특성을 보입니다.

다음 표는 쓰기 작업 시 주요 오버헤드 요소를 정리한 것입니다.

이러한 특성으로 인해, 열지향 저장 방식은 대규모 배치 삽입이나 주기적인 데이터 적재에는 효율적이지만, 실시간으로 레코드가 추가되거나 수정되는 OLTP 시나리오에서는 성능 저하를 초래할 수 있습니다.

열지향 저장 방식은 데이터 웨어하우스와 같은 분석 중심의 읽기 작업에 최적화되어 있다. 그러나 온라인 트랜잭션 처리 시스템에서 요구하는 빈번한 데이터 갱신, 삽입, 삭제 작업에는 상대적으로 부담이 큰 구조를 가진다. 이는 데이터를 컬럼 단위로 배치하고 압축하는 기본 원리에서 기인한다.

트랜잭션 처리를 위해 단일 레코드의 여러 컬럼을 수정하려면, 해당 레코드의 데이터가 흩어져 저장된 여러 컬럼 파일을 모두 찾아 업데이트해야 한다. 이는 행 지향 저장 방식이 단일 행을 한 블록에 모아두는 방식에 비해 훨씬 많은 I/O 작업을 유발한다. 또한, 높은 압축률을 위해 적용된 인코딩 방식은 데이터를 직접 수정하기 어렵게 만든다. 작은 수정 사항이라도 압축된 블록 전체를 읽고, 압축을 해제한 후 수정하고, 다시 압축하여 쓰는 과정이 필요할 수 있다.

이러한 특성은 ACID 트랜잭션을 보장하기 위한 락 관리와 동시성 제어를 복잡하게 만든다. 여러 사용자가 동시에 서로 다른 컬럼을 수정할 경우, 잠금의 단위를 설정하고 충돌을 관리하는 것이 행 단위 저장보다 까다롭다. 결과적으로, 실시간으로 데이터를 갱신하는 OLTP 워크로드에서는 쓰기 성능이 저하되고 처리 지연이 발생할 수 있다. 따라서 열지향 저장은 주로 대규모 배치 처리나 추가 전용의 로그 수집에 적합하며, 트랜잭션 부하는 이를 구현하는 시스템 설계 시 고려해야 할 주요 한계점이다.

열지향 저장 방식은 특정 유형의 데이터 처리 작업에는 적합하지 않다. 가장 큰 제약은 온라인 트랜잭션 처리 워크로드이다. 이 방식은 데이터를 컬럼 단위로 배치하기 때문에, 단일 레코드의 모든 컬럼 값을 삽입하거나 갱신하려면 여러 개의 서로 다른 파일 블록에 쓰기 작업을 분산해야 한다. 이로 인해 쓰기 지연 시간이 증가하고 처리 처리량이 현저히 떨어진다. 또한, ACID 트랜잭션을 보장하기 위한 잠금 및 복구 메커니즘 구현이 복잡해지는 부담이 따른다.

레코드 중심의 작업 역시 비효율을 초래한다. 사용자 프로필 조회나 주문 상세 정보 조회와 같이 개별 행의 모든 컬럼을 자주 읽어야 하는 워크로드에서는, 필요한 데이터가 여러 컬럼 파일에 흩어져 있어 I/O 횟수가 증가한다. 이는 행 지향 저장 방식이 한 번의 디스크 읽기로 전체 레코드를 가져올 수 있는 상황과 대비된다. 데이터가 실시간으로 지속적으로 수집되고 즉시 조회되어야 하는 운영 데이터베이스 환경에는 일반적으로 부적합하다.

다음과 같은 특성의 워크로드는 열지향 저장의 이점을 살리기 어렵다.

따라서 열지향 저장 방식은 주로 대규모 분석 쿼리에 최적화되어 있으며, 쓰기 중심이거나 레코드 단위 작업이 빈번한 시스템에서는 행 지향 저장 방식이나 하이브리드 방식을 고려하는 것이 일반적이다.

대규모 분석 시스템은 열지향 저장 방식의 가장 대표적인 적용 분야이다. 이러한 시스템은 테라바이트 또는 페타바이트 규모의 데이터를 처리하며, 주로 집계 쿼리나 분석 쿼리를 실행한다. 열지향 저장 방식은 전체 테이블을 스캔하지만 특정 컬럼만 선택하여 읽는 워크로드에 매우 적합하여, 대규모 분석 시스템의 핵심 저장 포맷으로 자리 잡았다.

이 방식은 데이터 웨어하우스와 빅데이터 처리 프레임워크에서 널리 채택된다. 예를 들어, 아파치 하둡 에코시스템의 아파치 하이브나 아파치 스파크는 내부 저장 포맷으로 Parquet나 ORC 같은 열지향 포맷을 기본 권장한다. 이는 분산 파일 시스템 상에서 대용량 데이터를 효율적으로 저장하고 처리하는 데 필수적이다[4].

다음은 대규모 분석 시스템에서 열지향 저장을 사용하는 주요 시스템의 예시이다.

이러한 시스템에서 열지향 포맷을 사용하면, 분석가가 특정 기간의 매출(sales 컬럼)과 비용(cost 컬럼)만을 조회하는 쿼리를 실행할 때, 디스크 I/O 양이 행 지향 방식에 비해 극적으로 줄어든다. 결과적으로 쿼리 실행 시간이 단축되고, 클러스터의 자원 사용 효율이 향상되어 대규모 데이터 분석 비용을 절감하는 효과를 가져온다.

데이터 웨어하우스는 의사 결정 지원 시스템의 핵심 구성 요소로, 다양한 소스에서 수집된 대규모의 역사적 데이터를 통합하여 분석과 보고에 사용됩니다. 이러한 시스템의 주요 작업은 특정 기간의 매출 합계, 특정 지역의 고객 수 세기, 제품 카테고리별 트렌드 분석 등과 같이, 전체 데이터 집합의 일부 컬럼만을 스캔하는 집계 쿼리가 대부분입니다. 열지향 저장 방식은 이러한 워크로드에 매우 적합한 특성을 가지고 있습니다.

쿼리가 필요한 컬럼만 디스크에서 읽어오기 때문에, 불필요한 컬럼에 대한 I/O를 크게 줄일 수 있습니다. 예를 들어, 100개의 컬럼을 가진 테이블에서 3개의 컬럼만 조회하는 쿼리는, 행 지향 저장 방식에서는 전체 행을 읽어야 하지만, 열지향 방식에서는 필요한 3개의 컬럼 데이터만 읽으면 됩니다. 이는 디스크 대역폭을 절약하고 쿼리 응답 시간을 단축시키는 핵심 메커니즘입니다.

또한, 동일한 데이터 유형의 값들이 연속적으로 저장되기 때문에 압축 효율이 매우 높습니다. 런 렝스 인코딩이나 딕셔너리 인코딩과 같은 기법을 적용하기 쉬워, 저장 공간을 절감하고 메모리로 로드되는 데이터 양을 최소화합니다. 이는 대규모 데이터를 처리하는 데이터 웨어하우스의 비용과 성능에 직접적인 영향을 미칩니다.

주요 상용 및 오픈소스 데이터 웨어하우스 및 분석 시스템들은 열지향 저장을 채택하고 있습니다. 예를 들어, Amazon Redshift, Google BigQuery, Snowflake와 같은 클라우드 데이터 웨어하우스는 내부 저장 엔진으로 열지향 포맷을 사용합니다. 또한, Apache Hive나 Presto와 같은 오픈소스 쿼리 엔진도 Parquet나 ORC 같은 열지향 파일 포맷을 기본 또는 권장 형식으로 지원하여 데이터 웨어하우스 구축에 활용됩니다.

로그 분석은 열지향 저장 방식이 특히 빛을 발하는 대표적인 적용 분야 중 하나이다. 서버, 애플리케이션, 네트워크 장비 등에서 생성되는 로그 데이터는 일반적으로 방대한 양의 레코드를 포함하며, 분석 시 특정 필드(예: 응답 코드, IP 주소, 에러 메시지)에 대한 집계와 필터링이 빈번하게 수행된다. 이러한 워크로드 특성상, 전체 행을 읽는 대신 필요한 컬럼만 선택적으로 스캔할 수 있는 열지향 포맷은 I/O 효율성을 극대화하고 분석 성능을 획기적으로 개선한다.

로그 데이터는 종종 반정형 또는 스키마가 진화하는 형태를 띠며, Apache Parquet와 같은 포맷은 중첩된 데이터 구조를 효율적으로 지원한다. 또한, 로그의 각 컬럼(예: 타임스탬프, 사용자 에이전트, 요청 URL)은 데이터 유형과 값의 분포가 명확하여 런 렝스 인코딩이나 사전 인코딩과 같은 고효율 압축 기법을 적용하기에 이상적이다. 이로 인해 저장 공간을 크게 절약할 수 있으며, 이는 곧 클라우드 저장 비용 감소로 직결된다.

아래 표는 로그 분석에서 열지향 저장 방식을 사용할 때의 주요 이점을 요약한 것이다.

이러한 이유로 아파치 하둡, 아파치 스파크 기반의 대규모 로그 처리 파이프라인과 아마존 S3, 구글 클라우드 스토리지 같은 객체 저장소에 로그를 장기 보관할 때, Parquet나 ORC 형식은 사실상의 표준으로 자리 잡았다. 실시간 스트리밍 로그를 미리 정의된 스키마에 따라 열지향 포맷으로 변환하여 저장하는 아키텍처는 점점 더 일반화되고 있다[5].

Apache Parquet 구현체는 Apache Parquet 포맷의 명세를 구현한 소프트웨어 라이브러리 및 도구 모음을 의미한다. 주로 Java와 C++로 작성된 참조 구현체가 존재하며, 다양한 프로그래밍 언어와 데이터 처리 프레임워크에서 널리 사용될 수 있도록 바인딩이 제공된다.

핵심 구현체는 파일 포맷의 읽기와 쓰기를 담당하는 라이브러리로 구성된다. 이 라이브러리는 Apache Arrow와 같은 인메모리 포맷과의 효율적인 상호 변환을 지원하며, Apache Hadoop, Apache Spark, Apache Hive, Apache Impala와 같은 빅데이터 처리 시스템과의 긴밀한 통합을 제공한다. 구현체는 리프 노드의 데이터 페이지 인코딩, 사전 인코딩, 런 렝스 인코딩과 같은 다양한 인코딩 방식을 지원하여 저장 효율성을 극대화한다.

주요 구현체의 구성 요소는 다음과 같다.

이러한 구현체들은 지속적인 개발을 통해 새로운 데이터 타입 지원, 향상된 압축 알고리즘, 그리고 더 나은 쿼리 푸시다운 기능과 같은 최적화를 지속적으로 추가하고 있다.

컬럼형 데이터베이스는 열지향 저장 방식을 핵심 저장 구조로 채택한 데이터베이스 관리 시스템(DBMS)이다. 이는 기존의 행 지향 저장 방식을 사용하는 OLTP 시스템과는 설계 철학과 최적화 목표에서 근본적인 차이를 보인다. 컬럼형 데이터베이스는 각 컬럼(열)의 데이터를 물리적으로 연속된 블록에 함께 저장하여, 분석 쿼리에서 특정 컬럼만을 스캔할 때의 디스크 I/O를 최소화하는 데 중점을 둔다.

주요 컬럼형 데이터베이스 제품 및 오픈소스 프로젝트는 다음과 같다.

이러한 시스템들은 공통적으로 데이터 압축 효율이 뛰어나며, 컬럼 단위로 적용 가능한 런 렝스 인코딩, 딕셔너리 인코딩 등의 기법을 적극 활용한다. 또한, 대량의 데이터를 배치로 처리하는 벡터화 처리를 지원하여 CPU 캐시 활용률을 높이고 현대적 하드웨어의 성능을 극대화한다.

컬럼형 데이터베이스는 주로 OLAP 워크로드, 즉 대용량 데이터에 대한 복잡한 집계, 조인, 분석 쿼리를 빠르게 처리하는 데 사용된다. 그러나 개별 레코드의 빈번한 갱신이나 삽입이 필요한 트랜잭션 처리에는 덜 효율적일 수 있어, 이러한 시스템들은 종종 ELT 파이프라인의 최종 분석 저장소로 배치된다.

하둡 에코시스템 내에서 열지향 저장 방식은 HDFS를 기반 스토리지로 활용하며, 맵리듀스, Apache Spark, Apache Hive, Apache Impala와 같은 주요 처리 엔진들과 긴밀하게 통합되어 작동한다. 이 통합은 대규모 데이터 분석 파이프라인의 핵심 구성 요소를 형성한다. Parquet와 ORC와 같은 열지향 파일 포맷은 이러한 엔진들에 의해 네이티브하게 지원되며, 데이터를 HDFS에 효율적으로 저장하고 읽어들일 수 있는 표준화된 방식을 제공한다.

주요 통합 포인트는 다음과 같다.

* Apache Hive: Hive는 메타스토어를 통해 테이블 스키마를 관리하고, ORC를 기본 권장 포맷으로 채택하며, Parquet도 완벽하게 지원한다. Hive 쿼리 컴파일러는 열지향 파일에서 필요한 컬럼만 선택적으로 스캔하도록 실행 계획을 최적화한다.

* Apache Spark: Spark의 DataFrame과 Dataset API는 Parquet 및 ORC 파일을 읽고 쓰는 것을 기본 기능으로 포함한다. 특히 Parquet는 Spark의 기본 저장 포맷으로 널리 사용되며, 프레디케이트 푸시다운과 같은 최적화를 통해 필터링 연산을 데이터 소스 수준으로 밀어내 성능을 극대화한다.

* Apache Impala 및 기타 MPP 엔진: Impala, Presto와 같은 대화형 쿼리 엔진들은 열지향 포맷과의 긴밀한 통합을 통해 HDFS 상의 데이터에 대한 저지연 분석 쿼리를 가능하게 한다.

이러한 통합은 하둡 분산 파일 시스템의 확장성과 내구성 위에 열지향 저장 방식의 쿼리 성능과 압축 효율을 결합한다. 결과적으로, 데이터 엔지니어들은 ETL/ELT 파이프라인에서 Apache Spark를 사용하여 Parquet 형식으로 데이터를 변환 및 저장하고, Apache Hive나 Apache Impala를 통해 대화형 분석을 수행하는 하이브리드 아키텍처를 구축하는 것이 일반적이다. 또한 Apache Arrow와 같은 인메모리 포맷과의 연계를 통해 네트워크를 통한 데이터 전송 효율을 더욱 높이는 최적화도 진행되고 있다[6].

컬럼 청킹은 열지향 저장 방식에서 개별 컬럼의 데이터를 관리 가능한 크기의 블록으로 나누는 기법이다. 하나의 컬럼 전체를 한 번에 처리하는 대신, 이를 더 작은 단위로 분할하여 저장하고 읽는다. 이는 특히 매우 넓은 테이블(컬럼 수가 많은 테이블)이나 대용량 데이터를 다룰 때 메모리 사용 효율성과 처리 성능을 최적화하는 데 핵심적인 역할을 한다.

청크의 크기는 시스템의 성능에 직접적인 영향을 미친다. 일반적인 구성은 다음과 같다.

따라서 청크 크기는 보통 수만에서 수백만 개의 행을 하나의 단위로 설정하며, 저장 포맷과 시스템의 특성에 따라 조정된다. 예를 들어, Apache Parquet에서는 행 그룹(Row Group)이 이에 해당하는 개념으로 사용된다[7].

이 방식의 주요 이점은 선택적 읽기를 더 세밀하게 제어할 수 있다는 점이다. 쿼리가 특정 컬럼의 일부 구간만 필요로 할 경우, 시스템은 해당 컬럼의 전체 데이터 대신 필요한 청크만 정확히 디스크에서 읽어 들일 수 있다. 이는 불필요한 I/O를 줄이고 데이터 압축 및 인코딩 효율을 청크 단위로 최적화하는 기반이 된다. 결과적으로 스캔 성능이 향상되고 쿼리 처리 시 메모리 압력이 완화된다.

열지향 저장 방식에서 인코딩은 데이터를 디스크에 저장하기 전에 변환하는 과정을 의미한다. 컬럼 단위로 유사한 데이터를 모아 저장하기 때문에, 각 컬럼의 데이터 특성에 최적화된 압축 및 인코딩 기법을 적용할 수 있다. 이는 저장 공간을 절약하고, 디스크 I/O 양을 줄이며, 결과적으로 쿼리 처리 성능을 크게 향상시키는 핵심 메커니즘이다.

주요 인코딩 방식으로는 런 렝스 인코딩, 딕셔너리 인코딩, 델타 인코딩, 비트 패킹 등이 있다. 런 렝스 인코딩은 연속적으로 반복되는 값을 (값, 반복 횟수) 쌍으로 압축하여 저장 공간을 절약한다. 딕셔너리 인코딩은 고유한 값들에 대한 사전을 만들고, 실제 데이터는 짧은 정수 ID로 변환하여 저장한다. 델타 인코딩은 연속된 값들 간의 차이만을 저장하며, 정렬된 숫자형 데이터에 매우 효율적이다. 비트 패킹은 값을 저장하는 데 필요한 최소 비트 수를 계산하여, 불필요한 비트를 제거하고 데이터를 압축한다.

이러한 인코딩 기법들은 단독으로 또는 조합되어 사용된다. 예를 들어, 딕셔너리 인코딩을 적용한 후, 생성된 정수 ID 시퀀스에 런 렝스 인코딩이나 비트 패킹을 추가로 적용할 수 있다. Apache Parquet나 ORC와 같은 대표적인 열지향 파일 포맷들은 데이터 유형과 통계 정보를 기반으로 자동으로 최적의 인코딩 방식을 선택한다. 이는 개발자의 부담을 줄이면서도 데이터 특성에 맞는 고효율 저장을 가능하게 한다.

열지향 저장 방식에서 인덱싱은 행 지향 저장 방식과 근본적으로 다른 접근법을 요구합니다. 컬럼 단위로 데이터가 배치되기 때문에, 특정 값을 효율적으로 찾기 위한 전통적인 B-트리 인덱스보다는 컬럼 내 데이터의 통계와 메타데이터를 활용한 필터링이 핵심 전략이 됩니다.

주요 인덱싱 및 최적화 전략은 다음과 같습니다.

이러한 전략들은 쿼리 실행 계획 수립 시에 집중적으로 활용됩니다. 예를 들어, WHERE salary > 100000 같은 범위 쿼리가 발생하면, 쿼리 엔진은 각 salary 컬럼 청크의 최소값/최대값 메타데이터를 먼저 확인합니다. 최대값이 100000 미만인 청크는 아예 읽지 않고 스킵합니다. 또한 Parquet나 ORC 포맷은 페이지 수준에서도 이러한 통계를 유지하여 더 세밀한 스킵이 가능합니다. 결과적으로, 인덱스를 위한 별도의 저장 공간과 유지 보수 비용을 최소화하면서, 대규모 스캔 쿼리의 성능을 극대화하는 것이 열지향 저장 방식의 인덱싱 철학입니다.