데이터 웨어하우스 (r1)

데이터 웨어하우스는 OLTP 시스템과 구분되는 몇 가지 핵심적인 특징을 가진다. 이러한 특징들은 데이터 웨어하우스가 분석과 의사결정 지원에 최적화된 저장소로서의 역할을 정의한다.

첫 번째 특징은 주제 중심성이다. 데이터 웨어하우스는 특정 비즈니스 주제나 도메인을 중심으로 데이터를 구성한다. 예를 들어, 판매, 재고, 고객, 마케팅과 같은 주제별로 데이터가 통합되고 구조화된다. 이는 운영 시스템이 개별 트랜잭션 처리에 초점을 맞추는 것과 대조적이다. 두 번째 특징은 통합성이다. 데이터 웨어하우스는 기업 내 다양한 소스 시스템(예: ERP, CRM, 스프레드시트)에서 발생하는 이기종 데이터를 수집하여 일관된 형식과 명명 규칙, 측정 단위로 통합한다. 이를 통해 기업 전체의 통일된 분석 관점을 제공한다.

세 번째 특징은 시계열성이다. 데이터 웨어하우스의 데이터는 시간의 흐름에 따른 변화를 추적하고 분석할 수 있도록 기록된다. 대부분의 기록은 시간 타임스탬프와 함께 저장되며, 과거의 상태를 조회하고 시간에 따른 추세를 분석하는 것이 핵심 목적 중 하나이다. 네 번째 특징은 비휘발성이다. 일단 데이터 웨어하우스에 적재된 데이터는 일반적으로 삭제나 갱신이 빈번하게 발생하지 않는다. 주기적으로 새로운 데이터가 추가(삽입)되며, 기존 데이터는 읽기 전용으로 유지되어 안정적인 역사적 기록을 제공한다[2].

OLTP 시스템은 은행 거래, 주문 처리, 재고 관리와 같은 일상적인 비즈니스 거래를 실시간으로 처리하고 기록하는 데 최적화되어 있다. 이 시스템의 주요 목적은 데이터의 신속한 입력, 갱신, 삭제를 지원하여 운영 효율성을 극대화하는 것이다. 따라서 OLTP의 데이터 구조는 정규화가 높고, 트랜잭션의 무결성과 일관성을 보장하기 위해 설계된다. 쿼리는 주로 소량의 특정 레코드를 빠르게 조회하거나 수정하는 형태를 띤다.

반면, 데이터 웨어하우스는 OLTP 시스템을 포함한 여러 소스에서 수집된 방대한 역사적 데이터를 저장하고, 복잡한 분석 쿼리와 비즈니스 인텔리전스 보고를 지원하는 데 특화되어 있다. 그 목적은 경영진의 의사 결정을 돕기 위해 트렌드 분석, 패턴 발견, 집계 보고 등을 가능하게 하는 것이다. 따라서 데이터 구조는 분석 효율성을 위해 비정규화된 스타 스키마나 스노우플레이크 스키마를 사용하며, 읽기 중심의 작업에 최적화되어 있다.

두 시스템의 핵심 차이점은 아래 표와 같이 요약할 수 있다.

요약하면, OLTP 시스템은 조직의 '운영'을 지원하는 반면, 데이터 웨어하우스는 '분석'과 '전략적 의사결정'을 지원한다. 이들은 상호 보완적인 관계에 있으며, 일반적으로 OLTP 시스템에서 생성된 데이터가 ETL 과정을 거쳐 정제되어 데이터 웨어하우스로 이관된다.

데이터 웨어하우스의 아키텍처는 일반적으로 여러 계층으로 구성되어 데이터의 흐름과 처리를 체계적으로 관리한다. 이 계층 구조는 데이터가 다양한 소스에서 최종 사용자에게 도달하기까지 거치는 단계를 정의하며, 각 계층은 특정한 목적과 기능을 가진다.

주요 계층은 다음과 같다.

데이터는 ETL 또는 ELT 프로세스를 통해 이 계층들을 순차적으로 이동한다. 데이터 소스에서 추출된 데이터는 먼저 스테이징 영역에 로드되어 품질 검사와 기본 정제를 거친다. 이후 비즈니스 규칙이 적용된 본격적인 변환과 통합을 통해 데이터 저장소에 적재된다. 최종 사용자나 특정 애플리케이션은 대개 이 통합 저장소보다는 특화된 데이터 마트를 통해 데이터에 접근하여 비즈니스 인텔리전스 리포트나 분석을 수행한다.

이러한 계층적 구조는 원본 운영 시스템에 부하를 주지 않으면서 데이터 품질을 보장하고, 효율적인 데이터 관리와 유연한 접근을 가능하게 한다. 스테이징 영역은 변환 과정의 실패 시 복구 지점 역할을 하며, 데이터 마트는 최종 사용자에게 빠른 응답 성능과 용이한 데이터 탐색을 제공하는 핵심 요소이다.

ETL은 데이터 웨어하우스 구축의 핵심 프로세스로, 추출(Extract), 변환(Transform), 적재(Load)의 세 단계로 구성된다. 이 과정은 다양한 운영 시스템의 데이터를 일관된 형식으로 변환하여 데이터 웨어하우스 또는 데이터 마트에 통합하는 역할을 한다.

첫 번째 단계인 추출에서는 하나 이상의 원천 시스템(OLTP 데이터베이스, CRM, ERP, 로그 파일, 외부 데이터 피드 등)으로부터 데이터를 읽어온다. 추출 방식은 원본 시스템에 대한 부하와 데이터 신선도 요구사항에 따라 결정되며, 주로 전체 덤프(Full Dump)나 증분 추출(Incremental Extract) 방식을 사용한다. 이 단계에서 데이터는 원본의 형태 그대로 중간 영역인 스테이징 영역으로 이동한다.

두 번째 단계인 변환은 추출된 원시 데이터를 분석에 적합한 형태로 정제하고 통합하는 작업이다. 이 과정에서 데이터 품질을 보장하기 위한 다양한 작업이 수행된다. 주요 변환 작업은 다음과 같다.

마지막 단계인 적재는 변환이 완료된 데이터를 최종 목표인 데이터 웨어하우스의 팩트 테이블과 차원 테이블에 체계적으로 로드하는 단계이다. 적재 전략은 비즈니스 요구사항에 따라 전체 새로 고침(Full Refresh)이나 증분 적재(Incremental Load)를 선택한다. 적재 과정은 데이터 무결성을 유지하면서도 성능을 최적화하기 위해 인덱스 관리와 파티셔닝 전략을 함께 고려해야 한다. 전통적인 ETL은 배치(Batch) 방식으로 주기적으로 실행되지만, 실시간 분석 요구가 증가함에 따라 데이터 흐름을 지속적으로 처리하는 ELT 또는 스트리밍 ETL 방식으로도 진화하고 있다.

스타 스키마는 데이터 웨어하우스에서 가장 널리 사용되는 차원 모델링 기법이다. 이 모델은 중앙에 하나의 팩트 테이블이 위치하고, 그 주변을 여러 개의 차원 테이블이 직접 연결되는 구조를 가진다. 시각적으로 별(star) 모양을 띠기 때문에 스타 스키마라는 이름이 붙었다. 팩트 테이블은 분석의 중심이 되는 수치적 측정값(예: 판매액, 수량)을 저장하고, 각 차원 테이블은 분석의 관점(예: 시간, 제품, 고객, 지점)을 제공하는 설명적 속성으로 구성된다. 이 구조는 쿼리가 직관적이고 조인 경로가 단순하여 사용자 친화적이며, 분석 성능이 우수한 특징을 가진다.

반면, 스노우플레이크 스키마는 스타 스키마의 변형으로, 차원 테이블이 추가로 정규화된 구조를 말한다. 스타 스키마에서 하나의 평평한(flat) 차원 테이블이었던 것을, 중복을 제거하고 데이터 무결성을 높이기 위해 여러 개의 관련 테이블로 분해한다. 예를 들어, '제품' 차원 테이블을 '제품 카테고리', '제품 서브카테고리', '제품' 테이블로 나누어 계층적 관계를 형성할 수 있다. 이로 인해 데이터 다이어그램이 눈송이(snowflake) 모양처럼 보이게 된다.

두 기법의 주요 차이점은 다음과 같이 정리할 수 있다.

실제 구축에서는 데이터의 특성과 요구사항에 따라 선택한다. 대부분의 비즈니스 인텔리전스 도구와 OLAP 쿼리는 스타 스키마에 최적화되어 있어, 성능과 사용 편의성을 중시하는 경우 스타 스키마가 선호된다. 스노우플레이크 스키마는 저장 공간 효율성과 데이터 구조의 정교함이 중요한 매우 복잡한 차원을 모델링할 때 고려된다. 현대의 고성능 컬럼 기반 저장소와 대용량 저장 장비의 발전으로, 성능 우위와 관리 편의성 때문에 스타 스키마가 더 보편적으로 채택되는 경향이 있다.

팩트 테이블은 데이터 웨어하우스의 스타 스키마 또는 스노우플레이크 스키마에서 비즈니스 프로세스의 측정 가능한 수치 데이터를 저장하는 핵심 테이블이다. 이 테이블은 주로 판매 금액, 수량, 비용, 이익 등 양적 사실을 기록하며, 이러한 수치들은 분석의 주요 대상이 된다. 팩트 테이블의 각 행은 특정 사건이나 트랜잭션에 해당하는 경우가 많다. 테이블 구조는 대부분의 열이 외래 키로 구성되어 있으며, 이러한 외래 키들은 다양한 차원 테이블을 가리킨다. 외래 키들로 구성된 이 집합을 팩트 테이블의 그레인(Granularity) 또는 세분성이라고 하며, 이는 데이터의 가장 낮은 수준의 세부 정보를 정의한다[5]. 측정 수치 자체는 일반적으로 숫자형이며, 이러한 수치 필드를 팩트(Fact) 또는 측정값(Measure)이라고 부른다.

차원 테이블은 팩트 테이블의 문맥과 속성을 제공하는 설명자 테이블이다. 시간, 지리, 제품, 고객, 직원 등 비즈니스를 이해하는 데 필요한 관점을 나타낸다. 차원 테이블의 각 행은 하나의 차원 멤버(예: 특정 제품, 특정 날짜, 특정 매장)를 설명하며, 각 열은 해당 차원의 속성(예: 제품명, 제품 카테고리, 색상, 날짜, 연도 분기, 도시, 국가)을 포함한다. 이러한 속성들은 보고서의 행, 열, 필터의 기준이 되어 비즈니스 질문에 답하는 데 사용된다. 차원 테이블의 기본 키는 팩트 테이블의 외래 키와 연결되어, 하나의 팩트 레코드가 '언제', '어디서', '무엇을', '누가'와 관련된지 설명한다.

두 테이블의 관계와 역할은 다음과 같이 대비된다.

이러한 분리는 데이터 모델링의 핵심 원리이다. 팩트 테이블은 빠른 수치 집계에 최적화된 구조를 유지하고, 차원 테이블은 사용자가 이해하기 쉬운 풍부한 비즈니스 문맥을 제공한다. 분석가는 팩트 테이블과 차원 테이블을 조인(JOIN)하여 "2023년 4분기 북미 지역의 특정 제품 카테고리별 총 매출"과 같은 복잡한 질의에 답할 수 있다.

데이터 웨어하우스는 전통적으로 관계형 데이터베이스 관리 시스템(RDBMS)을 기반으로 구축되는 경우가 많다. 이는 관계형 모델의 강력한 데이터 무결성 보장, 표준화된 SQL 질의 언어, 그리고 수십 년간 검증된 안정성과 성능 덕분이다. 데이터 웨어하우스에 사용되는 RDBMS는 온라인 트랜잭션 처리(OLTP) 시스템용 데이터베이스와는 다른 최적화 방식을 채택한다. 분석 질의에 특화되어 대량의 데이터를 읽고 집계하는 작업에 효율성을 높이는 것이 주목적이다.

관계형 데이터 웨어하우스의 내부 저장 구조는 분석 워크로드에 맞게 설계된다. 대표적인 기법으로는 파티셔닝과 인덱싱이 있다. 파티셔닝은 큰 테이블을 관리 가능한 단위로 분할하여, 특정 기간이나 범위의 데이터만 스캔하는 질의 성능을 크게 향상시킨다. 인덱싱은 비트맵 인덱스나 조인 인덱스 등 분석 질의에 특화된 형태로 구성되어 복잡한 조인과 집계 연산을 가속화한다. 또한, 데이터는 주로 스타 스키마나 스노우플레이크 스키마 같은 차원 모델링 기법에 따라 배치된다.

주요 상용 관계형 데이터 웨어하우스 플랫폼으로는 테라데이터, 오라클 Exadata, IBM Db2 Warehouse, 마이크로소프트 SQL Server의 분석 기능 등이 있다. 이러한 플랫폼들은 대규모 병렬 처리(MPP) 아키텍처를 채택하여 여러 노드에 데이터와 처리를 분산시킴으로써 매우 빠른 분석 성능을 제공한다.

이러한 관계형 기반 저장 방식은 구조화된 데이터에 대한 복잡한 비즈니스 인텔리전스 리포트와 OLAP 분석에 여전히 핵심적인 역할을 한다. 그러나 빅데이터 시대에 접어들며 반구조화 또는 비구조화 데이터 처리의 필요성이 증가함에 따라, Hadoop이나 컬럼 기반 저장소 같은 대안 기술과의 조화를 모색하는 추세이다.

컬럼 기반 저장소는 데이터 웨어하우스 환경에서 고성능 분석 쿼리를 처리하기 위해 설계된 데이터 저장 방식이다. 기존 관계형 데이터베이스가 행 단위로 데이터를 저장하는 로우 기반 저장소 방식을 사용하는 것과 대비되며, 각 열(컬럼)별로 데이터를 연속적으로 저장하는 구조를 가진다.

이 방식의 핵심 장점은 분석 쿼리의 특성에 있다. 분석 작업은 특정 열의 전체 범위를 스캔하거나 집계(SUM, AVG 등)하는 경우가 많다. 컬럼 기반 저장은 필요한 열만 디스크에서 읽어오기 때문에 I/O 양이 크게 줄어든다. 또한 같은 데이터 타입의 값들이 연속적으로 저장되므로 데이터 압축 효율이 매우 높아져 저장 공간을 절약하고 메모리 캐시 효율성을 높인다. 대표적인 컬럼 기반 데이터 웨어하우스 제품으로는 Amazon Redshift, Google BigQuery, Snowflake 등이 있다.

반면, 컬럼 기반 저장소는 단일 행을 삽입, 갱신, 삭제하는 OLTP 작업에는 비효율적일 수 있다. 한 행의 데이터가 여러 열에 흩어져 저장되므로, 행 전체를 수정하려면 여러 위치를 찾아야 하기 때문이다. 따라서 이 방식은 주로 대량의 데이터를 일괄 적재하고 읽기 중심의 복잡한 쿼리를 실행하는 데이터 웨어하우스 환경에 최적화되어 있다.

빌 인몬(Bill Inmon)이 제시한 방식은 데이터 웨어하우스 구축의 초기이자 근본적인 방법론 중 하나로, '정규화된 엔터프라이즈 데이터 웨어하우스'를 중심으로 한 상향식 접근법을 취한다. 이 방식은 기업 전체를 아우르는 단일하고 통합된 진실의 원천을 구축하는 것을 최우선 목표로 삼는다. 인몬은 데이터 웨어하우스를 '주제 중심적이고, 통합적이며, 시계열적이고, 비휘발성인 데이터의 집합'으로 정의하며, 이러한 특성을 충족시키기 위해 엔터프라이즈 전체를 위한 중앙 집중식 저장소를 먼저 설계하고 구축한다.

이 방법론의 핵심은 데이터의 중복을 최소화하고 일관성을 극대화하기 위해 정규화된 데이터 모델을 채택하는 것이다. 즉, 엔터티-관계 모델을 기반으로 데이터를 여러 테이블에 분산시켜 저장하는 방식이다. 이렇게 구축된 엔터프라이즈 데이터 웨어하우스는 원천 시스템으로부터 ETL 프로세스를 통해 정제되고 통합된 데이터를 저장하는 중앙 허브 역할을 한다. 이후 특정 부서나 비즈니스 영역(예: 영업, 마케팅)의 분석 요구를 충족시키기 위해 이 중앙 저장소로부터 데이터를 추출하여 데이터 마트를 구축하는 하향식 접근을 따른다.

인몬 방식의 주요 장점은 데이터의 일관성과 무결성이 매우 높다는 점이다. 모든 데이터 마트가 동일한 중앙 저장소를 기반으로 하므로, 기업 전체에서 보고되는 지표의 일관성을 보장할 수 있다. 또한 새로운 비즈니스 질문이나 분석 요구사항이 발생했을 때, 기존의 통합된 데이터 웨어하우스를 기반으로 유연하게 대응할 수 있는 구조를 제공한다. 그러나 단일한 엔터프라이즈 데이터 웨어하우스를 구축하는 데에는 상당한 시간과 비용이 소요되며, 초기 투자 대비 가시적인 결과를 얻기까지의 기간이 길 수 있다는 단점도 지닌다.

이 방식은 랄프 킴볼이 주창한 차원 모델링 기반의 하향식 접근법과 자주 비교된다. 두 방식의 주요 차이점을 요약하면 다음과 같다.

랠프 킴볼이 제안한 Kimball 방식은 데이터 웨어하우스 구축을 위한 차원 모델링 방법론으로, 최종 사용자의 비즈니스 질문에 초점을 맞추는 것이 핵심이다. 이 방식은 엔터프라이즈 전체를 아우르는 단일한 정규화된 저장소를 먼저 구축하는 Inmon 방식과 대비된다. 킴볼 방식은 특정 비즈니스 프로세스(예: 영업, 마케팅)를 중심으로 한 데이터 마트를 독립적으로 구축하는 것으로 시작한다. 이후 이러한 데이터 마트들이 통합되어 하나의 가상적이지만 일관된 엔터프라이즈 데이터 웨어하우스를 형성한다.

이 방법론의 중심에는 스타 스키마 또는 스노우플레이크 스키마로 대표되는 차원 모델이 있다. 모델은 팩트 테이블과 차원 테이블로 구성된다. 팩트 테이블은 판매량, 주문 건수 같은 수치적 측정값(팩트)을 저장하고, 차원 테이블은 시간, 제품, 고객, 지역 등 팩트를 설명하는 문맥적 속성을 저장한다. 이 구조는 직관적이어서 비즈니스 사용자가 쉽게 이해하고, OLAP 쿼리 성능을 최적화하는 데 유리하다.

구축 프로세스는 일반적으로 다음과 같은 단계를 따른다.

1. 비즈니스 프로세스 선택: 분석할 핵심 프로세스를 식별한다.

2. 그레인 정의: 팩트 테이블에 저장될 데이터의 가장 낮은 수준의 세부사항을 결정한다.

3. 차원 식별: 선택한 프로세스를 설명하는 데 필요한 차원(누가, 무엇을, 언제, 어디서)을 선정한다.

4. 팩트 식별: 분석할 수치적 측정값을 선정한다.

5. 데이터 마트 구축: 설계된 차원 모델을 기반으로 첫 번째 데이터 마트를 구축한다.

이 방식의 주요 장점은 빠른 구현과 높은 사용자 수용도이다. 비즈니스 부서별로 필요한 데이터 마트를 상대적으로 신속하게 제공할 수 있어 투자 대비 효과를 빠르게 확인할 수 있다. 또한, 직관적인 데이터 모델은 최종 사용자가 비즈니스 인텔리전스 도구를 통해 직접 데이터를 탐색하고 분석하는 셀프 서비스 BI 환경을 촉진한다. 그러나 여러 데이터 마트를 통합할 때 데이터 중복이나 불일치가 발생할 위험이 있으며, 엔터프라이즈 전체의 매우 통합된 단일 버전의 진실을 구축하는 데는 한계가 있을 수 있다.

클라우드 데이터 웨어하우스는 클라우드 컴퓨팅 인프라를 기반으로 구축, 운영, 관리되는 데이터 웨어하우스 서비스이다. 기존의 온프레미스 하드웨어에 의존하던 방식과 달리, 클라우드 서비스 제공업체가 관리하는 가상화된 스토리지와 컴퓨팅 리소스를 사용한다. 사용자는 필요한 만큼의 용량과 성능을 유연하게 확장하거나 축소할 수 있으며, 초기 대규모 자본 투자 없이 운영 비용 중심으로 서비스를 이용한다. 주요 제공업체로는 Amazon Redshift, Google BigQuery, Microsoft Azure Synapse Analytics, Snowflake 등이 있다.

이 서비스의 핵심 장점은 탄력적인 확장성과 관리 부담의 감소이다. 사용자는 데이터 양이나 분석 작업의 복잡도가 증가하면 실시간에 가깝게 컴퓨팅 노드를 추가할 수 있으며, 유휴 시간에는 리소스를 줄여 비용을 최적화한다. 또한, 하드웨어 프로비저닝, 소프트웨어 패치, 백업, 보안 업데이트와 같은 인프라 관리 작업 대부분이 클라우드 공급자에게 이관되어, 조직은 데이터 분석과 비즈니스 인사이트 도출에 집중할 수 있다.

아키텍처 측면에서 클라우드 데이터 웨어하우스는 종종 스토리지와 컴퓨팅이 분리된 설계를 채택한다. 이는 데이터를 객체 스토리지에 저장하고, 분석 쿼리가 실행될 때만 필요한 만큼의 컴퓨팅 클러스터를 동적으로 할당하는 방식으로, 비용 효율성과 성능을 동시에 달성하는 데 기여한다. 또한, 다양한 데이터 소스와의 네이티브 통합, 머신러닝 기능 내장, 그리고 데이터 레이크와의 긴밀한 연동을 통해 현대적인 데이터 플랫폼의 핵심 구성 요소로 자리 잡았다.

데이터 레이크는 정형, 반정형, 비정형 데이터를 원본 형태로 대규모 저장하는 데 적합하지만, ACID 트랜잭션과 데이터 품질 관리, 고성능 분석 쿼리를 위한 최적화가 부족한 경우가 많았다. 반면 데이터 웨어하우스는 정제된 정형 데이터에 대한 강력한 분석 성능과 일관성을 제공하지만, 유연성이 낮고 다양한 원시 데이터를 저장하는 데 한계가 있었다. 레이크하우스(Lakehouse)는 이 두 패러다임의 장점을 통합한 새로운 아키텍처로 등장했다. 레이크하우스는 데이터 레이크의 경제적이고 유연한 저장소(주로 클라우드 객체 저장소) 위에 데이터 웨어하우스 수준의 데이터 관리 및 트랜잭션 기능을 계층으로 추가한다.

레이크하우스의 핵심은 오픈 포맷과 메타데이터 계층이다. Apache Iceberg, Delta Lake, Apache Hudi와 같은 오픈 테이블 포맷은 객체 저장소에 저장된 데이터 파일들에 대해 ACID 트랜잭션, 스키마 진화, 시간 여행(Time Travel) 같은 고급 데이터 관리 기능을 제공한다. 이를 통해 데이터 레이크에 저장된 원시 데이터를 직접적으로 BI 도구와 머신러닝 프레임워크가 고성능으로 접근하고 처리할 수 있다. 이 아키텍처는 복잡한 ETL 과정 없이도 원시 데이터에 대한 직접적인 분석과 머신러닝을 가능하게 하며, 데이터 사일로를 제거한다.

결과적으로 레이크하우스는 단일 플랫폼에서 데이터 수집, 저장, 분석, AI/ML 워크로드를 지원하는 통합 데이터 관리 패러다임으로 진화하고 있다. 이는 기존의 별도로 운영되던 데이터 웨어하우스와 데이터 레이크 인프라를 간소화하고, 데이터 중복을 줄이며, 엔드-투-엔드 데이터 파이프라인의 효율성을 높이는 방향으로 발전하고 있다.