Data Engineer 가 알아야 할 Data Modeling (Korean)
Data Modeling A to Z for Data Engineer
Table of contents
- Dimensional Data Modeling
- Fact Data Modeling
- Aggregation Data Modeling
- 용어 설명
Dimensional Data Modeling
정의
Data Warehouse 설계에서 데이터를 구조화하는 중요한 기법
- 특히 OLAP (Online Analytical Processing) 시스템에서 주로 사용되며, 데이터를 분석하기 용이하게 구성하는 것이 목표
이 Modeling 은 크게 3 가지 구성 요소로 나눌 수 있습니다.
Fact Table
Dimension Table
Summary Table
Fact Table
정의
Fact Table 은 측정값 또는 비즈니스 이벤트(Transaction) 를 저장하는 테이블입니다.
- 예를 들어, 판매 데이터를 저장할 때 판매량, 수익, 거래 날짜와 같은 데이터를 포함합니다.
특징
주로 숫자 데이터(측정값) 가 포함됩니다.
Foreign Key 로 여러 Dimension Table 과 연결됩니다. (RDMS 와 유사)
큰 Table 이 될 수 있으며, 많은 양의 데이터가 저장됩니다. (보통 HDFS, S3 등 에 저장)
예시
판매 Fact Table 에는 판매 ID, 제품 ID, 고객 ID, 판매량, 가격 등이 포함될 수 있습니다.
여기서 제품 ID, 고객 ID 는 Dimension Table 과의 연결을 위한 Foreign Key 입니다.
Dimension Table
정의
Dimension Table 은 데이터를 분석할 수 있는 관점 (Dimension) 을 정의하는 Table 입니다.
주로 비즈니스 Context (배경) 를 제공하는 설명 데이터로 이루어져 있습니다.
특징
Foreign Key 로 Fact Table 과 연결됩니다.
날짜, 지역, 제품, 고객과 같은 Text 기반 정보를 담고 있습니다.
데이터 중복을 허용하는 경우가 많으며, 테이블의 크기는 상대적으로 작습니다.
예시
- 고객 Dimension Table 에는 고객 ID, 이름, 주소, 성별, 나이 등이 포함될 수 있습니다. 이는 고객 관련 데이터를 분석할 수 있게 해줍니다.
주요한 Dimension 들
Cumulative Dimension
시간이 흐름에 따라 누적된 데이터를 관리하는 Dimension 입니다.
즉, 이 Dimension 은 특정 Entity 의 속성들이 시간에 따라 변화하거나 확장되는 데이터를 추적하는 데 사용됩니다.
이러한 Dimension 은 주로 데이터를 분석할 때, 변화의 누적된 경향을 확인하거나 비교 분석을 할 수 있게 도와줍니다.
특징
시간 경과에 따른 상태 변화 추적: Cumulative Dimension 은 Entity (예: 고객, 제품, 재고 등)가 시간에 따라 어떻게 변화 했는지 추적합니다.
누적된 데이터를 유지: 데이터가 누적 되므로 과거의 변화와 현재의 상태를 모두 기록하여 분석할 수 있습니다.
Slowly Changing Dimension (SCD) 와 연관: Cumulative Dimension 은 주로 Slowly Changing Dimension (SCD) 유형 중 일부와 밀접한 관련이 있습니다. 특히, SCD Type 2 에서 누적된 이력을 관리하는 방식과 유사합니다.
사용 사례
고객 이력 관리
- 고객의 정보가 시간에 따라 변화하는 것을 추적하는 경우, 고객의 주소, 직업, 상태 등의 변화를 누적 차원으로 저장하여 과거와 현재 상태를 모두 분석할 수 있습니다.
예시
고객 A 는 2021 년에 서울에 살고 있었지만, 2023 년에는 부산으로 이사했습니다. Cumulative Dimension 에서는 과거의 주소(서울)와 현재의 주소(부산)를 모두 기록하여 분석할 수 있습니다.
재고 관리: 제품의 재고가 시간에 따라 누적되는 경우, 재고 변화의 누적 데이터를 관리하는 데 사용됩니다. 누적된 재고 데이터를 바탕으로 제품이 특정 기간 동안 얼마나 많이 입고 되었고, 출고 되었는지를 분석할 수 있습니다.
장점
이력 추적 가능: 데이터를 분석할 때 과거와 현재의 상태를 모두 고려하여, 시간 경과에 따른 변화를 정확하게 파악할 수 있습니다.
장기적인 경향 분석 가능: 시간이 지남에 따라 데이터가 어떻게 변화하는지를 기반으로, 장기적인 추세를 분석하는 데 유리합니다.
단점
데이터 크기 증가: 누적 데이터를 저장해야 하기 때문에 데이터의 크기가 증가할 수 있습니다. 특히, 데이터의 변화가 자주 발생하는 경우 저장소 사용량이 크게 늘어날 수 있습니다.
복잡한 관리: 과거 데이터와 현재 데이터를 모두 관리해야 하므로 Database 관리가 복잡해질 수 있습니다.
Daily Dimension
Daily Dimension 은 일별로 데이터를 추적하고 관리하는 차원입니다.
Daily Dimension 은 특정 Entity 가 매일 발생하는 변화를 추적하거나, 일별 데이터 분석을 목적으로 할 때 유용합니다.
일 단위로 데이터를 수집하고, 그날의 데이터를 다른 날의 데이터와 비교하거나 분석할 수 있게 해줍니다.
특징
일일 데이터 기록: 매일의 데이터를 기록하고, 시간 흐름에 따른 변화를 세부적으로 추적할 수 있습니다.
정밀한 분석: 일별로 데이터를 세분화하여 분석할 수 있어, 주간, 월간, 연간 분석보다 더 정밀한 일일 분석을 수행할 수 있습니다.
주로 날짜 차원과 결합: Daily Dimension 은 주로 날짜 차원과 밀접하게 연관되어 있으며, 날짜별 데이터를 저장하여 다양한 시간 기준의 분석을 용이하게 만듭니다.
사용 사례
일일 판매 분석: 소매업체가 매일의 판매 데이터를 기록하여 일별 매출, 판매량, 트랜잭션 수 등을 추적하는 경우에 사용됩니다. 일별 판매 데이터를 통해 특정 날짜나 기간 동안 판매 트렌드를 분석할 수 있습니다.
예제
- 특정 제품의 2024년 1월 1일 판매량은 500개, 2024년 1월 2일 판매량은 300개였다. Daily Dimension 을 사용하면 날짜별로 데이터를 구분하여 저장하고 분석할 수 있습니다.
일일 사용자 활동 분석: 소셜 미디어 플랫폼에서 매일의 사용자 활동(예: 로그인 수, 게시물 작성 수)을 기록하고, 일별로 변화를 분석할 때 사용됩니다.
예제
- 2024년 10월 1일에는 1,000명이 로그인 했고, 10월 2일에는 1,200 명이 로그인했다. 이러한 데이터를 Daily Dimension 으로 관리하여 일별 활동 변화를 분석할 수 있습니다.
장점
세부적인 시간 분석 가능: 일별로 데이터를 기록하고 관리 하므로, 시간의 세부적인 변화를 분석할 수 있습니다. 예를 들어, 특정 날에 발생한 이벤트가 매출에 미치는 영향을 분석할 수 있습니다.
시간 기반 분석 유리: 날짜별 데이터를 저장하여 특정 날짜의 성과를 비교하거나 분석할 때 매우 유용합니다.
단점
데이터 양 증가: 매일 데이터를 기록하기 때문에 데이터 양이 매우 많아질 수 있습니다. 특히, 대규모 시스템에서 일일 데이터를 관리하는 경우 저장소 부담이 클 수 있습니다.
복잡한 Query: 일별 데이터를 분석하는 경우, 일일 데이터의 변화와 누적 데이터를 동시에 관리해야 할 경우 복잡한 Query 작성이 필요할 수 있습니다.
Summary Table
정의
데이터의 집계 또는 요약된 정보를 미리 계산해서 저장해 두는 Table 입니다.
사용자는 대량의 데이터를 즉시 집계하는 대신, 미리 계산된 요약 데이터를 사용함으로써 Query 성능을 크게 개선할 수 있습니다.
일반적으로 대규모 Fact Table 에서 자주 필요한 집계 정보를 미리 계산하여 Summary Table 에 저장하고, 분석 시 빠르게 조회합니다.
Summary Table 이 필요한 이유
Dimension Data Modeling 에서는 대량의 데이터를 실시간으로 분석하는 것이 중요한데, 사실 테이블은 일반적으로 세분화된 (Low Granularity) 데이터를 포함하고 있어 집계 연산이 자주 필요합니다.
예를 들어, 하루 수백만 건의 Transaction 데이터를 사실 Table 에 저장하는 경우, 일일 매출, 주간 매출과 같은 집계를 자주 수행해야 할 수 있습니다. 이러한 작업이 매번 Query 될 때마다 실시간으로 이루어지면 성능이 크게 저하됩니다.
따라서 Summary Table 을 사용하면 미리 계산된 요약 데이터를 빠르게 조회할 수 있어 성능이 개선됩니다.
Summary Table 의 구성
Summary Table 은 일반적으로 다음과 같은 구조를 가집니다.
Grouping 된 Dimension Column
- Summary Table 에서 데이터를 집계할 때 사용하는 Dimension 데이터 (예: 날짜, 제품, 지역 등)
미리 계산된 집계 값
각 Dimension 조합에 대한 미리 계산된 집계 값 (예: 매출 총액, 판매량 등)
예를 들어, 일일 매출 Summary Table 을 생성할 경우
Dimension: 날짜 (Date), 제품 (Product), 지역 (Region)
Aggregation 값: 총 매출 (Total Sales), 총 판매량 (Total Quantity)
이런 식으로 Summary Table 에 저장해두면, 매일 매출 데이터를 다시 계산할 필요 없이 요약된 데이터를 빠르게 조회할 수 있습니다.
특징
사용자 정의 Table
Summary Table 은 개발자나 DBA 가 직접 생성하고 관리하는 Table 입니다.
요약하고자 하는 데이터를 미리 결정하고, 그 데이터를 별도의 Table 로 생성합니다.
자동 관리되지 않음
Summary Table 은 Database 가 자동으로 갱신하거나 관리하지 않습니다.
새로운 데이터가 INSERT 되거나 UPDATE 되면, Summary Table 을 수동으로 갱신해야 합니다.
이를 위해 Batch 작업이나 ETL (Extract, Transform, Load) Process 를 별도로 설계해야 합니다.
Customized
- Summary Table 은 특정 비즈니스 요구에 맞게 다양한 집계 방식으로 데이터를 요약할 수 있습니다. 예를 들어, 주간 매출, 제품별 판매량, 지역별 매출 등을 미리 계산하여 저장할 수 있습니다.
임의적인 구조 설계 가능
- Table 의 구조를 원하는 대로 설계할 수 있고, Query 성능에 최적화된 형태로 만들 수 있습니다.
Summary Table 의 장점
Query 성능 향상
- Summary Table 을 사용하면 실시간으로 데이터를 집계할 필요가 없으므로 Query 속도가 크게 개선됩니다. 특히, 대용량 Fact Table 에서 자주 사용 되는 Aggregation Query 의 경우 큰 성능 차이를 만들 수 있습니다.
Resource 절약
Fact Table 에 직접 Aggregation Query 를 실행하는 대신, 미리 계산된 Summary 데이터를 사용하기 때문에 CPU 와 Memory 사용량을 줄일 수 있습니다.
이는 동시에 여러 사용자가 대규모 데이터를 Query 할 때 시스템의 부하를 줄이는 데 유용합니다.
복잡한 계산 간소화
- 복잡한 계산이나 Aggregation 연산이 자주 수행되는 경우, 이러한 연산을 미리 계산하여 저장해 두면, 실시간으로 처리해야 하는 복잡성을 크게 줄일 수 있습니다.
사용자 정의 최적화
- 매우 세부적이고 구체적인 요구 사항에 맞춰 설계할 수 있습니다. 여러 종류의 집계나 분석 쿼리를 미리 계산하여 최적화할 수 있습니다.
설계의 유연성
- 여러 Fact Table 에서 데이터를 조합하거나, 집계할 항목 들을 자유롭게 정의할 수 있습니다.
Summary Table 의 단점 및 고려 사항
데이터 중복
- Summary Table 은 데이터를 미리 계산해 저장 하므로, 동일한 데이터를 다른 형태로 여러 번 저장하게 됩니다. 이는 저장소 사용량을 증가시킬 수 있으며, 데이터 중복 문제가 발생할 수 있습니다.
데이터 갱신 필요성
Summary Table 의 데이터는 Fact Table 의 데이터가 변경되면 동기화 되어야 합니다.
예를 들어, 새로운 Transaction 이 발생하면 Summary Table 을 다시 계산하고 갱신해야 합니다. 데이터 일관성 (Consistency) 을 유지하기 위한 추가 작업이 필요하며, 실시간 데이터 변경이 잦은 경우 유지 관리가 복잡해질 수 있습니다.
비용 vs 성능 고려
- Summary Table 을 사용하면 Query 성능은 향상되지만, 데이터를 미리 집계하고 저장하는 데에 따른 추가적인 저장소 비용이 발생할 수 있습니다. 또한, Summary Table 을 갱신하는데 추가적인 Batch Process 나 Resource 가 필요할 수 있습니다.
Summary Table 설계 시 고려사항
집계 (Aggregation) 수준 결정
- Summary Table 을 설계할 때, 어느 수준까지 데이터를 집계할 것인지를 결정해야 합니다. 일별, 주별, 월별 집계로 요약할지, 아니면 다른 비즈니스 요구사항에 맞춰 그룹화 할지를 미리 계획해야 합니다.
데이터 동기화
- Summary Table 을 갱신하는 프로세스를 계획해야 합니다. 이는 배치 처리, ETL 프로세스, 또는 Trigger 기반으로 Summary Table 을 주기적으로 업데이트하는 방식으로 이루어질 수 있습니다.
Query 패턴 분석
Summary Table 은 자주 사용 되는 분석 Query 에 적합하도록 설계되어야 합니다.
Summary Table 을 사용함으로써 자주 필요한 Aggregation 연산이 성능 상 이점을 가지도록 하며, 전체 데이터 스캔을 피할 수 있어야 합니다.
Schema Types
- Data Modeling 에서 가장 흔한 Schema 는 Star Schema 와 Snowflake Schema 입니다.
Star Schema
구조
- Fact Table 이 중앙에 있고, 여러 Dimension Table 이 주변에 위치한 단순한 구조입니다.
장점
이해하기 쉽고, 빠르게 Query 할 수 있습니다.
데이터 중복을 허용하는 대신, JOIN Operation 의 Overhead 를 줄여서 Query 성능을 올릴 수 있습니다.
단점
- Dimension Table 에서 데이터 중복이 발생할 수 있습니다.
예시
- 판매 Fact Table 과 제품, 고객, 날짜 Dimension Table 이 중앙의 Fact Table 과 각각 1:1 로 연결됩니다.
Snowflake Schema
구조
- Star Schema 를 확장하여, Dimension Table 을 더 세분화 (Table Normalize 를 위해서) 하여 여러 Table 로 나누는 방식입니다.
장점
데이터 중복을 최소화하고 정규화된 구조를 제공합니다.
데이터 중복을 최소화 한만큼 보다 작은 데이터 규모를 유지할 수 있습니다.
단점
- Query 가 복잡해지고, JOIN Operation 이 많아 성능이 떨어질 수 있습니다.
예시
- 고객 Fact Table 을 세분화하여 주소, 도시, 국가 테이블로 분리할 수 있습니다.
주요 설계 원칙
Dimension Data Modeling 의 주요 원칙은 데이터를 직관적으로 설계하여, 분석과 보고를 용이하게 만드는 것입니다. 이를 위해 다음의 설계 원칙을 따릅니다.
비즈니스 요구에 맞게 설계
- 분석하고자 하는 비즈니스 프로세스를 중심으로 Fact Table 을 설계하고, 이를 지원하는 Dimension Table 을 구축합니다.
정규화 (Normalization) vs 비 정규화 (Denormalization)
- Dimension Table 은 일반적으로 비 정규화하여 직관적인 데이터 분석을 지원하고, Fact Table 은 정규화를 통해 데이터를 효율적으로 관리합니다.
Timestamp 와 Version 관리
- 시간에 따른 변화를 추적하기 위해 날짜 Dimension Table 을 사용하며, Version 관리를 통해 이력을 기록합니다.
장점
분석 속도 향상
- Dimension Data Modeling 은 복잡한 분석 Query 를 빠르게 수행할 수 있도록 설계됩니다.
데이터 통합 용이성
- Dimension 테이블을 통해 서로 다른 Data Source 를 통합하여 분석할 수 있습니다.
확장성
- 새로운 데이터나 Dimension 이 추가될 때 모델을 쉽게 확장할 수 있습니다.
단점
JOIN 비용
대량의 데이터를 처리할 때 JOIN 비용이 증가할 수 있으며, 성능에 영향을 미칠 수 있습니다.
- JOIN 비용이 과도하게 들지 않도록 Dimension Table 의 Denormalization 을 잘 해두어야 함.
중복 데이터
Dimension Table 의 비 정규화로 인해 중복 데이터가 발생할 수 있습니다.
중복으로 인한 데이터 유지보수 비용이 추가로 발생.
중복으로 인한 저장소도 추가로 더 필요함.
Star Schema vs Snowflake Schema
Star Schema 가 적합한 경우
단순하고 직관적인 구조
- Star Schema 는 Dimension Table 이 단순하고 덜 세분화되어 있어 비즈니스 사용자나 데이터 분석가 들이 더 쉽게 이해할 수 있습니다. 따라서 사용자가 데이터 모델을 빠르게 이해해야 하는 상황에서는 Star Schema 가 적합합니다.
빠른 Query 성능
Star Schema 는 Dimension Table 이 Fact Table 과 직접 연결되어 있어 JOIN 연산이 비교적 적습니다.
Query 성능이 중요한 경우, 특히 대량의 데이터에 대한 분석에서 Star Schema 가 유리할 수 있습니다. (TB, PB 급의 DB, Table 의 경우, OLAP 분석이 필요할 경우)
데이터 중복 허용
- Dimension Table 에서 중복 데이터가 발생할 수 있지만, 이를 통해 JOIN 의 복잡성을 줄이고 Query 속도를 높일 수 있습니다. 즉, 성능이 최우선인 경우 적합합니다.
Snowflake Schema가 적합한 경우
데이터 정규화
Snowflake Schema 는 데이터가 정규화되어 Dimension Table 이 더 세분화됩니다.
만약 데이터 중복을 최소화하거나 공간 효율성을 중요하게 생각한다면 Snowflake Schema 가 더 나은 선택일 수 있습니다.
복잡한 데이터 구조
데이터의 Dimension 이 복잡하고, 여러 단계로 구분되는 정보 (예: 지역 → 국가 → 도시) 등을 세분화해야 하는 경우 Snowflake Schema 가 유리합니다.
데이터의 무결성을 유지하고자 할 때 이 스키마를 선호할 수 있습니다.
- 데이터 중복이 적기 때문에 유지보수 비용이 적게 들고, 그에 따른 Data Integrity 도 좋아지게 된다.
데이터 통합
여러 시스템에서 데이터를 가져와 통합할 때, 정규화를 통해 더 체계적으로 데이터를 관리할 수 있습니다.
Snowflake Schema 는 데이터 통합 및 데이터 일관성을 보장하는 데 적합합니다.
결정 요인
Query 성능 요구사항: 빠른 Query 성능이 중요한 경우 Star Schema
유지보수 용이성: 단순한 구조로 유지보수가 적게 들길 원한다면 Star Schema
데이터 중복 및 저장소 관리: 저장소 효율성을 중시한다면 Snowflake Schema
데이터 모델의 복잡성: 데이터 모델이 복잡하거나 Dimension Table 이 Multi-Level 로 나누어져야 한다면 Snowflake Schema
Dimension Data Modeling 으로 비즈니스 요구 사항에 맞는 Fact Table 을 설계하는 방법 예제
비즈니스 프로세스 이해
Fact Table 설계의 첫 단계는 비즈니스 요구 사항과 관련된 핵심 비즈니스 프로세스를 명확히 이해하는 것입니다.
어떤 비즈니스 이벤트를 추적할 것인가?
분석하고자 하는 핵심 성과 지표 (KPI) 는 무엇인가?
예제
소매업체에서는 판매가 주요 비즈니스 프로세스
분석 대상 (KPI) 은 판매량, 수익, 고객 행동 등
Fact Table 의 주제 정의
비즈니스 이벤트를 중심으로 Fact Table 의 주제를 정의합니다.
이 단계에서는 어떤 비즈니스 활동을 추적할 것인지 명확히 해야 합니다.
예제
판매 Table 의 경우, 판매된 제품, 고객, 판매 날짜 등이 추적됩니다.
재고 Table 의 경우, 입고된 제품, 창고 위치, 입고 일자 등이 추적될 수 있습니다.
측정값 (Metric) 결정
Fact Table 은 측정값 (Metric) 을 저장하는 역할을 하므로, 어떤 Metric 이 필요한지 정의해야 합니다.
Metric 은 비즈니스의 성과를 수치적으로 표현한 값입니다.
여기서 중요한 Metric 은 무엇인지 고려합니다.
예제
판매 Table 에서는
판매량,수익,할인율등이 Metric 이 될 수 있습니다.재고 Table 에서는
재고량,입고 횟수,재고 회전율등이 Metric 이 됩니다.
Dimension 결정 및 Foreign Key 설정
Fact Table 에 저장되는 Metric 들은 여러 Dimension 으로 설명 가능합니다.
이때 각 Dimension Table 과 Fact Table 을 연결할 Foreign Key 를 정의해야 합니다.
각각의 Dimension 은 데이터를 분석하는 관점이 됩니다.
예제
판매 Table 에서는
제품 ID,고객 ID,날짜 ID등의 Foreign Key 가 포함됩니다.Dimension Table 은
제품,고객,날짜와 같은 Dimension 을 정의하고, 각 Dimension 의 속성들을 담습니다.
시간 Dimension 설정
비즈니스 요구 사항에서 시간이 중요한 요소라면, 시간 Dimension 은 거의 필수적으로 포함됩니다.
분석 시 시간 경과에 따른 변화를 추적해야 하기 때문입니다. 일반적으로
연도,월,일과 같은 Field 를 포함하는 시간 Dimension 이 사용됩니다.예제
- 판매 데이터에서 월별 매출 분석을 위해 날짜 Dimension 이 필요합니다.
수정 이력 관리 (SCD, Slowly Changing Dimension)
비즈니스 요구 사항에 따라 차원의 이력 관리가 필요한 경우, 이를 반영할 필요가 있습니다.
이는 Slowly Changing Dimension (SCD) 기법을 통해 구현할 수 있습니다.
이는 시간에 따라 변하는 Dimension 데이터를 추적하고, 해당 정보를 분석에 반영하는 방법입니다.
예제
- 고객의 주소가 변경될 경우, 이전 주소와 새로운 주소 모두를 관리해야 할 수 있습니다.
Granularity (세분성) 결정
Fact Table 의 Granularity 를 결정하는 것은 매우 중요한 작업입니다.
Granularity 은 Fact Table 이 얼마나 구체적인 데이터를 저장할 것인지를 의미합니다.
Granularity 이 높을수록 더 상세한 데이터를 기록하지만, 데이터 양이 많아집니다.
데이터 크기 관리
압축
- 데이터 크기가 클 경우, 저장 공간을 최적화하기 위해 Table 압축을 적용할 수 있습니다.
Partitioning
데이터 크기를 관리하고 Query 성능을 높이기 위해 Partitioning 을 적용할 수 있습니다.
특히, 날짜 Dimension 을 기준으로 Partitioning 하면 특정 기간의 데이터만 효율적으로 조회할 수 있습니다.
Query 성능 최적화
Index 설정
자주 조회되는 Column 에 Index 를 설정하면 성능을 향상시킬 수 있습니다.
특히, Foreign Key 나 날짜와 같은 Column 에 Index 를 설정하면 Query 성능이 좋아집니다.
Summary Table 활용
- High Granularity 의 Fact Table 에서 전체 데이터를 모두 Query 하지 않고, 자주 사용 되는 집계된 데이터를 별도로 저장하는 Summary Table 을 생성할 수 있습니다. 이를 통해 복잡한 분석 시 성능을 개선할 수 있습니다.
Granularity 은 비즈니스 질문에 따라 달라집니다. 고객의 일별 구매 패턴을 분석하려면 일별 Granularity 을 선택해야 합니다.
예제
일별 Granularity: 각 고객이 하루에 구매한 제품의 데이터를 기록
주별 Granularity: 각 고객이 한 주 동안 구매한 제품의 데이터를 기록
Query 성능 최적화
Fact Table 은 대규모 데이터를 저장하게 되므로, 설계 시 Query 성능도 고려해야 합니다.
적절한 Index 설정과 데이터 Partitioning 을 통해 Query 성능을 향상시킬 수 있습니다.
Index 최적화
- 자주 사용하는 Foreign Key 나 날짜 Field 에 Index 를 설정합니다.
Partitioning
- 날짜별로 데이터를 Partitioning 하면 특정 기간의 데이터를 빠르게 Query 할 수 있습니다.
Partition Pruning
정의
Partitioning 을 사용한 경우, Query 시 필요하지 않은 Partition 을 스캔하지 않도록 하는 기술입니다.
Database 가 특정 Partition 만을 조회하도록 설계하면 불필요한 데이터 읽기를 피할 수 있습니다.
장점
- Query 가 필요한 데이터만 조회하여 성능을 극대화합니다.
사용 시점
특히 날짜 기반의 Partition 을 사용할 때, 과거 데이터를 Query 하지 않아도 되는 경우 유용합니다.
적절한 Filter 조건을 Query 에 포함하여 쓸모없는 Partition 을 제외시킵니다.
Materialized View
정의
Materialized View 는 복잡한 Query 결과를 미리 계산하여 저장해 두는 Table입니다.
이를 통해 자주 사용되는 복잡한 Query 를 빠르게 처리할 수 있습니다.
장점
- 데이터 Aggregation, Join, Filtering 을 미리 수행하고 그 결과를 저장해두기 때문에 Query 시간이 대폭 줄어듭니다.
사용 시점
- 동일한 분석 Query 를 반복적으로 수행할 때, 특히 JOIN 이 복잡하거나 대량의 데이터를 처리해야 할 경우 매우 유용합니다.
Data Clustering
정의
Data Clustering 은 비슷한 데이터를 물리적으로 가깝게 저장하여 디스크 읽기 성능을 최적화하는 방법입니다.
같은 범위의 데이터를 한 곳에 모아두면 조회 시 디스크 I/O가 줄어들고, Cache 효율성이 높아집니다.
장점
- 데이터 접근 패턴이 일정하다면 Query 성능을 크게 개선할 수 있습니다.
사용 시점
- 시간, 지리적 위치, 고객 ID 등과 같은 필드를 기준으로 Range Query 가 자주 발생하는 경우
Compression
정의
Table 의 데이터를 압축하여 저장하면 데이터 크기를 줄이고, 읽기 속도를 높일 수 있습니다.
압축된 데이터는 디스크에서 더 적은 양을 읽기 때문에 I/O 성능이 개선되며, 많은 경우 CPU 비용이 증가 하더라도 전반적인 Query 성능은 좋아집니다.
장점
- 디스크 I/O 를 줄이고 더 많은 데이터를 메모리에 저장할 수 있어 성능 향상이 가능합니다.
사용 시점
- 대량의 Fact 데이터를 저장할 때 특히 유용하며, 읽기 성능을 중시할 때 적합합니다. 다만, 압축과 압축 해제에 따른 CPU 비용을 고려해야 합니다.
Bucketing
정의
Bucketing 은 데이터를 특정 Column 을 기준으로 작은 그룹(Bucket)으로 나누어 저장하는 방식입니다.
이는 데이터를 균등하게 분배하고, 특정 범위의 데이터를 효율적으로 검색할 수 있게 합니다.
장점
- 데이터 분포가 불균형 (Skewed) 할 때 Query 성능을 최적화할 수 있으며, Join 성능 향상에 유리합니다.
사용 시점
- 대규모 데이터를 Join 할 때 또는 특정 Field 에 집중된 Query 가 발생할 때 사용합니다.
Query Caching
정의
자주 실행되는 Query 의 결과를 Cache 하여, 동일한 Query 가 다시 실행될 때 빠르게 결과를 반환하는 기법입니다.
Caching 된 결과는 메모리나 디스크에 저장되어 있으며, 데이터가 변경되지 않는 한 동일한 결과를 반복적으로 반환할 수 있습니다.
장점
- 복잡한 연산을 반복해서 수행하지 않으므로 Query 시간을 대폭 줄일 수 있습니다.
사용 시점
- 자주 사용되는 동일한 Query 가 많을 때 유용하며, 데이터가 자주 변경되지 않는 환경에서 적합합니다.
Denormalization
정의
Denormalization 는 Table 간의 JOIN 을 줄이기 위해 데이터를 중복하여 저장하는 방법입니다.
이를 통해 JOIN 연산을 줄이고, Query 속도를 높일 수 있습니다.
장점
- JOIN 이 복잡할 경우 성능을 크게 개선할 수 있으며, Query 단순화에도 기여합니다.
사용 시점
- 데이터 일관성보다 읽기 성능이 중요한 경우, 예를 들어 읽기 성능이 중시되는 OLAP 시스템에서 적합합니다.
Shard Partitioning
정의
Sharding 은 대규모 데이터를 여러 Node 에 분산하여 저장하는 기법입니다.
이를 통해 데이터 처리 부하를 분산시키고, 병렬 처리를 통해 성능을 높일 수 있습니다.
장점
- 데이터 처리 성능을 Horizontally scaling 할 수 있으며, 대규모 데이터를 빠르게 처리할 수 있습니다.
사용 시점
- 매우 큰 데이터 세트에 대해 다수의 노드에서 병렬로 Query 해야 하는 경우.
Indexes for Analytical Workloads (Bitmap Index)
정의
일반적인 Index 외에도, Bitmap Index 는 Fact Table 에서 대량의 데이터를 분석할 때 유용한 Indexing 방식입니다.
Bitmap Index 는 각 Column 값을 Bit 로 변환하여 효율적으로 저장하고 조회합니다.
장점
- 대용량 데이터를 다루는 경우, 특히 Cardinality 가 낮은 값들 (예: 성별, 상태 코드 등) 에 대해 빠른 검색을 지원합니다.
사용 시점
- 분석 Query 에서 특정 값들에 대한 Aggregation 이 많이 일어날 때 유용합니다.
Columnar Storage
정의
Columnar Storage 는 데이터를 Row 가 아니라 Column 단위로 저장하는 방식입니다.
이는 분석 Query 가 전체 Row 를 읽는 것이 아니라 필요한 Column 만 읽기 때문에 읽기 성능이 매우 뛰어납니다.
장점
- 분석 Query 성능에 매우 유리하며, 디스크 I/O 를 줄여 성능을 크게 향상시킬 수 있습니다.
사용 시점
- OLAP 시스템에서 대규모 데이터를 조회할 때 유리하며, 많은 양의 데이터를 효율적으로 읽어야 할 때 사용됩니다.
종류
RDBMS 기반
Amazon Redshift
AWS 에서 제공하는 고성능 Data Warehouse 서비스로, Columnar Storage 를 사용하여 대량의 데이터를 효율적으로 처리합니다.
주로 분석 Query 에 최적화되어 있어 대규모 데이터를 빠르게 읽을 수 있습니다.
Google BigQuery
Google Cloud Platform 에서 제공하는 완전 관리형 Data Warehouse 로, Columnar Storage 방식을 사용합니다.
SQL-like Query 를 통해 대규모 데이터를 분석하는 데 매우 효과적 입니다.
Snowflake
Cloud 기반 Data Warehouse 시스템으로, Columnar 데이터 저장 방식을 채택하고 있습니다.
분석 작업에 최적화된 성능을 제공하며, 병렬 처리를 통해 매우 빠른 Query 성능을 보여줍니다.
NoSQL 기반
Apache HBase
Hadoop 기반의 NoSQL Database 로, Columnar Storage 를 사용합니다.
주로 대규모 분산 데이터를 관리하는 데 적합하며, Google Bigtable 과 유사한 구조를 가지고 있습니다.
대량의 데이터를 빠르게 읽고 쓰는 데 강점이 있습니다.
Cassandra (with CQL)
Apache 에서 개발한 고성능 NoSQL Database 로, 주로 Row 기반으로 동작하지만 CQL(Cassandra Query Language)을 통해 Columnar 데이터 Storage 를 흉내 낼 수 있습니다.
대규모 데이터를 수평 확장하는 데 뛰어난 성능을 보입니다.
Druid
실시간 분석 처리를 위해 설계된 오픈소스 분산 Database 로, Columnar Storage 방식을 사용합니다.
빠른 데이터 조회 및 집계 연산을 제공하며, 주로 대규모 이벤트 데이터를 분석하는 데 사용됩니다.
기타 분석 System
Apache Parquet
Columnar File Format 으로, 대규모 데이터를 효율적으로 저장하고 분석할 수 있도록 설계되었습니다.
주로 Hadoop, Spark 와 같은 분산 처리 시스템에서 사용되며, 데이터 압축과 빠른 Query 성능을 제공합니다.
Apache ORC
Parquet 와 유사하게 Columnar File Format 으로, 대용량 데이터 처리를 최적화하기 위한 설계입니다.
주로 Hadoop 에코시스템에서 사용되며, Parquet 에 비해 더 작은 파일 크기와 빠른 성능을 제공합니다.
사례 적용
예를 들어, 전자 상거래 플랫폼에서 판매 분석을 위한 사실 테이블을 설계한다고 가정합니다.
비즈니스 이벤트는 판매이며, 매일 발생하는 각 거래를 기록합니다.
Fact Table 은
판매량,판매 금액,할인 금액등의 Metric 을 포함합니다.Dimension 은
고객,제품,날짜,지역으로 정의되고, 각 Dimension 의 Foreign Key 가 Fact Table 에 포함됩니다.시간 Dimension 을 통해 월별, 분기별 또는 연도별 분석이 가능하게 합니다.
Fact Table 의 Granularity 은 각 거래 단위로 설정됩니다.
Fact Data Modeling
- Fact Data Modeling 은 Data Warehouse 나 Data Mart 에서 자주 사용하는 Modeling 기법 중 하나로, 주로 비즈니스의 이벤트나 Transaction 을 기록하는 Table 을 설계하는 과정입니다.
정규화 된 Fact Table
정의
정규화된 Fact Table 은 데이터를 중복 없이 저장하고, 데이터를 가능한 한 여러 테이블로 나누어 Foreign Key 관계를 통해 JOIN 하는 구조입니다.
보통 3차 정규화 (Third Normal Form, 3NF) 까지 이루어진 상태로 설계 되며, 중복을 최소화하고 데이터 무결성을 유지하는 것을 목표로 합니다.
필요성
데이터 중복 방지
정규화된 Table 은 데이터를 여러 Table 로 분리해, 중복된 데이터를 제거할 수 있습니다.
예를 들어, 동일한 제품 정보를 여러 곳에 저장하는 대신, 제품 정보를 별도의 Dimension Table 에 저장하고 참조할 수 있습니다.
데이터 무결성 유지
정규화는 데이터 무결성을 유지하기에 용이합니다.
한 곳에서만 데이터를 관리하면, 데이터 수정 시 일관성을 보장할 수 있습니다.
- 예를 들어, 고객 정보가 하나의 Table 에서 관리되면, 고객 정보 변경 시 모든 관련된 데이터에 자동으로 반영됩니다.
유지보수 용이성
- 구조가 체계적으로 나누어져 있으므로, Schema 변경이나 Table 관리가 상대적으로 쉽습니다.
System 성능에 끼치는 영향
JOIN 성능 저하
정규화된 구조는 분석할 때 여러 Dimension Table 을 조인해야 하므로 Query 성능이 떨어질 수 있습니다.
특히, Fact Table 이 매우 크고 Dimension Table 도 여러 개일 경우, JOIN 연산의 비용이 상당히 커질 수 있습니다.
읽기 성능
데이터 조회 시 Dimension Table 과 Fact Table 간의 많은 JOIN 이 필요하므로, 데이터 접근 성능이 저하될 수 있습니다.
복잡한 Query 일수록 이러한 성능 저하는 더 두드러집니다.
사용 사례
데이터 업데이트가 빈번하고, 무결성이 매우 중요한 환경에서는 정규화 된 Fact Table 이 필요합니다.
예를 들어, 금융 Transaction 시스템에서는 계좌 정보, 고객 정보 등 자주 변경 되며 중요한 데이터를 정규화하여 관리하는 것이 적합합니다.
여러 테이블에 나누어 저장하면, 특정 정보가 Update 되었을 때 하나의 Table 에서만 수정을 진행하면 되므로, 데이터 일관성을 유지할 수 있습니다.
비 정규화 된 Fact Table
정의
비 정규화된 Fact Table 은 중복된 데이터를 허용하면서, 하나의 Table 에 가능한 한 많은 관련 정보를 포함하는 방식입니다.
Dimension Table 의 일부 속성들을 Fact Table 에 함께 저장해 JOIN 연산을 최소화하는 구조입니다.
필요성
성능 최적화
비 정규화는 특히 데이터 읽기 성능을 높이는 데 유리합니다.
JOIN 이 필요하지 않거나 적기 때문에, Query 성능이 크게 향상될 수 있습니다.
특히 대규모 데이터 분석이나 실시간 보고서 생성 시, 비 정규화 된 Table 은 빠른 응답을 제공할 수 있습니다.
Simple Query
JOIN 없이도 필요한 데이터를 조회할 수 있어, Query 가 간단해지고 Query 최적화의 필요성이 줄어듭니다.
이는 개발자의 작업을 단순화시키고 유지보수를 쉽게 할 수 있는 장점도 있습니다.
읽기 중심 Workload 에 적합
읽기 작업이 자주 발생하고, 데이터 수정이 드물 경우 비 정규화 된 구조가 매우 적합합니다.
OLAP 시스템에서는 주로 데이터가 한번 적재된 후 주기적으로 읽히기 때문에, 비 정규화가 자주 사용됩니다.
System 성능에 끼치는 영향
데이터 중복 증가
비 정규화는 Dimension Table 의 데이터를 Fact Table 에 포함하기 때문에 데이터 중복이 발생할 수 있습니다.
예를 들어, 제품 이름과 같은 속성이 여러 행에 반복적으로 저장될 수 있습니다.
데이터 업데이트 비용 증가
중복된 데이터를 비 정규화 한 경우, 데이터 업데이트 시 각 Row 마다 데이터를 수정해야 하므로 성능 저하가 발생할 수 있습니다.
수정 작업이 자주 발생하는 환경에서는 비효율적입니다.
저장 공간 증가
중복된 데이터는 저장 공간을 더 많이 차지하므로, 데이터 스토리지 비용이 증가할 수 있습니다.
특히 대규모 데이터에서 이 문제는 매우 심각해질 수 있습니다.
사용 사례
데이터의 변경이 드물고 빠른 분석이 요구되는 Data Warehouse 나 BI 시스템에서 비 정규화 된 Fact Table 이 많이 사용됩니다.
예를 들어, E-Commerce Platfrom 에서의 사용자 행동 분석, 대규모 Log 데이터 처리 등에서는 데이터가 주기적으로 적재되고 주로 읽기 작업이 이루어지기 때문에 비 정규화 된 Table 이 성능을 높일 수 있습니다.
Fact Table 의 주요 특성
Measures (수치 데이터)
Fact Table 의 핵심은 수치 데이터를 저장하는 것에 있습니다.
예를 들어, 판매 데이터를 저장하는 Fact Table 이라면, 판매 금액, 판매 수량 같은 데이터가 포함됩니다.
이러한 데이터는 Aggregation (SUM, AVG 등) 연산의 대상이 됩니다.
Composite Key (복합 키)
Fact Table 은 일반적으로 여러 차원 테이블의 Key 로 구성된 Composite Key 를 가지고 있습니다.
예를 들어, 날짜, 제품, 고객 등의 Dimension Table 을 참조하는 Foreign Key 를 가질 수 있습니다.
상대적으로 적은 속성
Fact Table 은 수치 정보와 Foreign Key 외에는 다른 속성을 많이 갖지 않습니다.
필요한 모든 Context 는 Dimension Table 에서 제공되기 때문입니다.
정규화 또는 비정규화
Fact Table 은 3차 정규화 된 구조일 수도 있고, 특정 성능 요구에 따라 일부 비 정규화 될 수도 있습니다.
다만 일반적으로 Fact Table 은 매우 큰 데이터 양을 처리 하므로 효율적인 데이터 접근이 중요합니다.
Fact Data Modeling 과정
비즈니스 프로세스 정의
Modeling 의 첫 번째 단계는 어떤 비즈니스 프로세스를 Modeling 할지 결정하는 것입니다.
예를 들어, 판매 Transaction 을 Modeling 할지, 재고 변동을 Modeling 할지에 따라 Fact Table 의 구조가 달라집니다.
Fact Table 에 저장할 측정값 결정
각 Transaction 이나 이벤트에서 어떤 측정 값을 기록할지 결정합니다.
이를 통해 비즈니스 의사결정에 필요한 중요한 정보를 제공할 수 있습니다.
예를 들어, 매출 금액, 주문량, 클릭 수 등이 있습니다.
Dimension Table 정의
Fact Table 에 기록된 측정 값은 Dimension Table 의 맥락 내에서 이해됩니다.
따라서 어떤 Dimension (예: 시간, 제품, 고객, 지역 등)을 사용할지 결정하고, 그에 맞는 Dimension Table 을 설계합니다.
Foreign Key 설계
Fact Table 의 각 Row 은 여러 Dimension Table 의 Foreign Key 를 참조하여, 해당 Fact 가 언제, 어디서, 누구에 의해, 어떤 조건에서 발생했는지 설명합니다.
이 Foreign Key 들이 Composite Key 역할을 합니다.
집계 수준 결정
데이터를 어떤 수준으로 집계할 것인지 결정해야 합니다.
예를 들어, 일 단위로 집계할 것인지, 시간 단위로 집계할 것인지, 혹은 제품별, 지역별로 집계할 것인지 결정합니다.
집계 수준에 따라 Fact Table 의 크기와 성능이 크게 영향을 받습니다.
Fact Table 의 유형 선택
Transaction Fact Table
- 각 이벤트나 Transaction 을 기록합니다. 예를 들어, 주문이나 결제 기록
Snapshot Fact Table
- 특정 시점에서의 상태를 기록합니다. 예를 들어, 월말 재고 수준을 기록하는 Table
Accumulating Snapshot Fact Table
이벤트가 시간이 지남에 따라 진행되는 과정의 여러 단계를 기록합니다.
예를 들어, 주문 처리의 각 단계(주문 접수, 배송, 결제 완료 등)를 기록하는 Table
One Big Table 방법론
설명
Data Warehouse 나 Data Mart 에서 사용하는 Data Modeling 기법 중 하나로, 말 그대로 모든 데이터를 하나의 Table 에 통합하여 저장하는 방법입니다.
이 방법론은 주로 빠른 분석 Query 를 필요로 하는 환경에서 사용됩니다.
정규화 된 구조와는 반대로, 모든 관련 데이터를 하나의 비 정규화 된 Table 에 담아 여러 Table 간의 JOIN 을 최소화하여 Query 성능을 극대화 하는 것이 목표입니다.
One Big Table Model (OBT) 의 핵심 개념
데이터 통합
하나의 Table 에 모든 필요한 데이터를 포함 시킵니다. 즉, Fact Table 과 모든 관련 Dimension Table 의 속성을 JOIN 한 결과를 하나의 Table 로 통합합니다.
예를 들어, 시간, 고객, 제품, 매장 등의 정보를 각각의 Dimension Table 로 나누지 않고, 모든 정보를 포함한 하나의 Table 에 기록합니다.
비 정규화된 Table
모든 관련 데이터를 한 곳에 저장하기 때문에 많은 중복이 발생합니다.
예를 들어, 같은 제품이나 고객 정보가 여러 번 반복해서 저장될 수 있습니다.
그러나 이러한 비 정규화는 Query 성능을 극대화하기 위한 의도적인 선택입니다.
조인 없이 Query
하나의 큰 Table 은 JOIN 없이 분석 Query 를 수행할 수 있도록 설계되었습니다.
이를 통해 Query 성능을 크게 향상시킬 수 있으며, 복잡한 Query 의 경우에도 상대적으로 빠른 응답 시간을 제공할 수 있습니다.
OLAP 환경에 적합
OBT 는 일반적으로 읽기 전용 작업이 많고 데이터가 자주 수정되지 않는 OLAP (Online Analytical Processing) 환경에 매우 적합합니다.
BI System 이나 Data Warehouse 에서 정기적으로 대규모 데이터를 분석하는 데 적합한 모델입니다.
One Big Table (OBT) 방법론의 장점
Query 성능 최적화
OBT 는 데이터를 조회할 때 Table 간의 JOIN 이 필요 없으므로, Query 성능이 크게 향상됩니다.
하나의 Table 에서 필요한 모든 데이터를 가져올 수 있기 때문에 복잡한 Query 를 간단하게 작성할 수 있으며, 대규모 데이터에서 빠른 분석이 가능합니다.
단순한 데이터 구조
비즈니스 요구 사항을 반영한 모든 데이터를 한 Table 에 담기 때문에 데이터 모델이 단순 해집니다.
데이터를 이해하고 분석하는 과정도 더 쉬워집니다.
데이터 분석가는 여러 Table 을 이해하고 JOIN 하는 복잡한 쿼리를 작성할 필요 없이, 하나의 Table 에서 필요한 데이터를 쉽게 가져올 수 있습니다.
유연성
Table 하나만 관리하면 되기 때문에, Data Modeling 과 관리 측면에서 상대적으로 유연할 수 있습니다.
새로운 데이터를 추가하거나 기존 데이터를 수정할 때에도 여러 Table 을 수정할 필요가 없으므로 유지보수가 용이합니다.
One Big Table 방법론의 단점
데이터 중복 문제
동일한 Dimension 정보가 반복적으로 저장되기 때문에 데이터 중복이 심하게 발생합니다.
예를 들어, 동일한 고객 정보가 여러 번 저장되면 저장 공간이 불필요하게 낭비됩니다.
또한, 중복된 데이터는 저장 비용을 증가시키고, 데이터 관리의 복잡성을 높일 수 있습니다.
데이터 수정 및 업데이트의 복잡성
OBT 에서 데이터를 수정하거나 업데이트할 경우, 동일한 정보가 여러 곳에 중복되어 있기 때문에 모든 행을 수정해야 합니다.
예를 들어, 고객의 주소가 변경되면 그 고객과 관련된 모든 행에서 해당 데이터를 수정해야 하므로, 수정 작업이 매우 비 효율적 입니다.
이런 경우, 데이터 무결성을 유지하는 것이 매우 어렵습니다.
확장성의 한계
데이터 양이 매우 많아질 경우, 하나의 큰 Table 에 모든 데이터를 저장하는 방식은 확장성에 문제를 야기할 수 있습니다.
Table 크기가 지나치게 커지면 Database 의 성능에 영향을 미칠 수 있으며, Partitioning 이나 Sharding 같은 전략이 필요할 수 있습니다.
데이터 무결성 유지 어려움
비 정규화된 구조에서는 중복된 데이터가 많아지기 때문에 데이터의 일관성을 유지하는 것이 어려워집니다.
예를 들어, 제품의 정보가 여러 행에 중복되어 있을 때, 한 곳에서 제품 정보가 잘못 수정되면 다른 행의 데이터와 불일치가 발생할 수 있습니다.
One Big Table vs Denormalized Table
용도 및 적용 범위
Denormalized Fact Table
주로 Data Warehouse 의 중심에서 특정 비즈니스 프로세스를 기록하기 위한 Table 로 설계됩니다.
예를 들어, 판매 Transaction, 주문 내역 등의 특정 이벤트에 대한 데이터를 저장하는 Table 입니다.
이 Table 은 특정 주제나 프로세스에 맞춘 비 정규화를 목표로 하며, 여전히 일부 Dimension Table 이 남아 있을 수 있습니다. 즉, 특정 주제 영역의 Transaction 을 최적화하기 위한 목적이 큽니다.
One Big Table
Denormalized Fact Table 보다 더 광범위하게 모든 데이터를 하나의 Table 에 통합하는 것을 목표로 합니다.
이는 단순히 Transaction 기록 뿐만 아니라 여러 Dimension Table 까지 포함한 매우 포괄적인 Table 입니다.
OBT 는 여러 주제 영역의 데이터를 모두 통합하여 하나의 큰 Table 로 만들기 때문에, Multi-Dimensional 분석을 할 때 JOIN 없이 바로 데이터를 조회할 수 있습니다.
BI 시스템이나 Reporting System 에서 주로 사용되며, 다양한 분석 시나리오에 대응할 수 있도록 설계됩니다.
성능 측면에서의 차이
Denormalized Fact Table
특정 Query 성능을 최적화하기 위해 설계됩니다.
비즈니스 Transaction 이나 이벤트에 맞춘 데이터로서, 필요한 일부 Dimension 데이터만 가져와 성능을 개선합니다.
JOIN 없이도 빠르게 특정 데이터를 조회할 수 있지만, 여전히 Dimension Table 과의 일부 JOIN 이 필요한 경우가 있을 수 있습니다.
One Big Table
모든 분석 시나리오에서 JOIN 을 완전히 제거하여 성능을 극대화하려는 목적입니다.
따라서 매우 빠르게 Query 할 수 있지만, Table 이 매우 커지고 중복이 심해질 수 있습니다.
특히 다양한 분석 요구에 맞춰 Multi-Dimensional 데이터를 빠르게 조회해야 할 때 사용됩니다.
차이 요약
One Big Table 방법론과 Denormalized Table 방법론 모두 데이터 분석 및 시스템 성능 최적화를 위한 비 정규화 기법을 사용한다는 점에서 유사하지만, 적용 범위와 목적에서 차이가 있습니다.
Denormalized Fact Table 은 특정 Transaction 최적화를, One Big Table 은 더 포괄적인 분석을 위한 최적화를 목적으로 사용됩니다.
Aggregation Data Modeling
데이터 분석의 성능을 향상시키기 위해 대규모 데이터를 사전에 요약하고 집계하는 방식의 데이터 모델링 기법입니다.
대규모 데이터 셋을 처리하는 환경에서 자주 사용되며, 데이터의 크기를 줄이고 복잡한 Query 의 성능을 최적화하는 것이 목표입니다.
이 Modeling 방식은 주로 OLAP (Online Analytical Processing) 환경, Data Warehouse, 또는 BI (Business Intelligence) 시스템에서 사용됩니다.
Aggregation Data Modeling 의 핵심 개념
사전 집계된 데이터 사용
대규모 Raw (원시) 데이터를 처리하기 전에, 미리 집계된 데이터를 생성하여 저장합니다.
이를 통해 실시간으로 데이터를 집계할 필요가 없으므로 Query 성능이 향상됩니다.
예를 들어, 일별, 주별, 월별 판매 데이터를 미리 계산하여 저장함으로써 조회 시 신속한 응답을 제공합니다.
원시 데이터와 집계 데이터 분리
원시 데이터를 그대로 보관하는 것이 아니라, 중요한 비즈니스 분석에 필요한 데이터 만을 요약하여 저장 (Summary Table) 합니다.
이러한 집계 데이터를 이용하면 전체 Raw 데이터를 처리하지 않고도 효율적인 분석이 가능합니다.
Multi-Dimensional Analysis
주로 다 차원적 분석에 사용됩니다.
예를 들어, 판매 데이터가 시간(일, 주, 월), 지역, 제품과 같은 다양한 Dimension 에서 분석될 수 있습니다.
이때 각각의 Dimension 에 맞는 집계 데이터를 생성하여 사용합니다.
데이터 저장 및 조회의 균형
저장 공간을 절약하기 위해 무조건 모든 데이터를 집계하는 것이 아니라, 비즈니스 요구에 따라 어떤 수준에서 데이터를 집계할지 결정합니다.
예를 들어, 일별 판매 데이터를 저장할 것인지, 월별 데이터를 저장할 것인지에 따라 집계 수준이 달라질 수 있습니다.
Aggregation Data Modeling 의 장점
Query 성능 향상
미리 집계된 데이터를 활용함으로써 복잡한 계산을 실시간으로 수행할 필요가 없어, 대규모 데이터에서도 매우 빠른 조회 성능을 제공할 수 있습니다.
특히 OLAP Query 에서 다양한 Dimension 과 Metrics 을 결합한 복잡한 분석을 수행할 때 매우 유리합니다.
효율적인 Resource 사용
Raw 데이터를 일일이 계산하고 처리하는 대신, 사전 집계된 데이터를 활용함으로써 CPU 와 Memory 사용량이 줄어들고 Query 응답 시간이 단축됩니다.
이를 통해 Database 서버의 부담을 줄이고 더 많은 사용자에게 빠른 응답을 제공할 수 있습니다.
사용자 경험 향상
BI 도구나 데이터 시각화 도구를 사용하는 사용자들은 빠른 응답을 원합니다.
Aggregation Data Modeling 은 사용자가 요구하는 데이터에 대해 즉각적인 응답을 제공할 수 있기 때문에, 사용자 경험을 크게 개선할 수 있습니다.
복잡한 분석 Query 지원
Multi-Dimensional 분석과 다양한 시나리오에 대한 집계 데이터를 제공함으로써, 복잡한 비즈니스 질문에 대한 신속한 답변을 가능하게 합니다.
예를 들어, 특정 지역에서의 월별 판매 트렌드를 분석하거나, 특정 제품군에 대한 주간 매출을 조회할 때 매우 효율적 입니다.
Aggregation Data Modeling 의 단점
저장 공간 증가
데이터를 집계할 때, Raw 데이터 외에도 추가로 집계된 데이터를 저장해야 하므로 저장 공간이 더 많이 필요합니다.
특히 집계 수준이 많아질수록 저장 공간이 급격히 증가할 수 있습니다.
예를 들어, 일별, 주별, 월별, 지역별, 제품별로 데이터를 모두 집계하여 저장한다면, 저장 공간이 크게 증가합니다.
유연성 부족
집계된 데이터는 고정된 형태로 저장 되므로, 사전에 정의되지 않은 Dimension 이나 새로운 분석 요구가 생겼을 때 즉각적으로 대응하기 어렵습니다.
예를 들어, 기존에는 지역별 판매 데이터만 집계 했는데, 새로운 비즈니스 요구로 고객 연령대별 판매 데이터를 분석해야 할 경우, 사전에 집계된 데이터로는 이를 처리하기 어려울 수 있습니다.
데이터 일관성 관리
Raw 데이터가 변경되거나 업데이트될 경우, 기존에 집계된 데이터 역시 재 계산되어야 하므로 관리가 복잡해질 수 있습니다.
특히 실시간 데이터 업데이트가 빈번한 환경에서는 집계 데이터의 일관성을 유지하는 데 어려움이 있을 수 있습니다.
집계 수준 결정의 어려움
데이터를 어느 수준에서 집계할지 결정하는 것이 매우 중요합니다.
만약 너무 세부적으로 집계하면 성능이 떨어질 수 있고, 너무 큰 단위로 집계하면 분석의 유연성이 떨어질 수 있습니다.
이를 적절히 조정하지 않으면 데이터 모델링의 효과를 극대화할 수 없습니다.
Aggregation Data Modeling 의 구현 방식
구체적 Aggregation Table
Raw 데이터를 바탕으로 특정 Dimension 과 집계 수준에 따라 Table 을 미리 생성하여 저장합니다.
예를 들어, 일별 판매량, 월별 매출 등을 저장한 Table 을 각각 따로 생성할 수 있습니다.
이 방식은 Query 할 때 JOIN 없이 즉시 데이터를 조회할 수 있으므로 성능이 좋습니다.
Roll-up 과 Drill-down
Roll-up 은 데이터를 상위 집계 수준으로 요약하는 과정이고, Drill-down 은 더 세부적인 집계 수준으로 세분화하는 방식입니다.
예를 들어, 일별 판매 데이터를 집계하여 월별, 연도별로 Roll-up 할 수 있습니다.
사용자 요구에 따라 Drill-down 하여 일자별 데이터를 조회할 수 있는 방식도 지원됩니다.
Cube 방식
OLAP Cube 는 Multi-Dimensional 데이터를 분석하기 위해 사용되며, 여러 Dimension 에서 데이터를 사전에 집계한 구조를 갖습니다.
예를 들어, 시간, 제품, 지역과 같은 여러 Dimension 을 기준으로 데이터를 요약하여 Cube 형태로 저장하면, 다양한 조합으로 데이터를 신속하게 조회할 수 있습니다.
물리적 집계와 가상 집계
물리적 집계는 데이터를 사전에 집계하여 저장하는 방식이고, 가상 집계는 실시간으로 데이터를 집계하는 방식입니다.
물리적 집계는 빠른 성능을 제공하지만 유연성이 떨어지고, 가상 집계는 성능이 약간 느릴 수 있지만 더 유연하게 데이터를 처리할 수 있습니다.
Aggregation Data Modeling 의 예시
e-Commerce 판매 데이터 집계
Raw 데이터
- 각 Transaction 별로 제품, 고객, 구매 날짜, 구매 수량, 구매 금액을 저장
집계 데이터
일별: 날짜별로 모든 제품의 총 판매 금액과 수량 집계
제품별: 각 제품의 주간/월간 판매량 집계
지역별: 지역별로 일자별 판매 데이터를 요약
웹사이트 트래픽 분석
Raw 데이터
- 웹사이트 Log 데이터를 수집하여 사용자, 페이지 뷰, 방문 시간, 방문 지역 등 기록
집계 데이터
일별/월별: 일자별, 월별 트래픽 집계
지역별: 국가, 지역별 트래픽 집계
장치별: PC, 모바일 등 장치 유형별 트래픽 집계
Aggregation Data Modeling 의 사용 사례
BI System
Business Intelligence System 에서는 빠른 분석이 요구됩니다.
Aggregation Data Modeling 을 통해 데이터를 사전에 집계해 두면, 다양한 Dimension 에서의 분석을 빠르게 수행할 수 있습니다.
OLAP System
OLAP 시스템에서는 Multi-Dimensional 데이터를 기반으로 복잡한 분석이 이루어집니다.
Aggregation Data Modeling 은 OLAP System 에서 데이터 처리와 Query 성능을 최적화하는 데 매우 유리합니다.
Log 분석
- 대규모 Log 데이터를 실시간으로 분석하기에는 성능 문제가 발생할 수 있으므로, Aggregation Data Modeling 을 통해 Log 데이터를 집계하여 실시간 분석을 지원할 수 있습니다.
용어 설명
Third Normal Form, 3NF
간단한 설명
Database 에서 데이터를 효율적으로 저장하고 데이터의 중복을 줄이며 무결성을 유지하기 위해 사용하는 정규화(Normalization) 단계 중 하나 입니다.
3NF (3차 정규화) 는 데이터를 논리적으로 구조화하는 기법으로, 데이터를 관리하기 쉽게 하고, Database 에서 일어날 수 있는 여러 가지 문제(예: 데이터 중복, 갱신 이상 등)를 해결하는 데 도움을 줍니다.
정규화
정규화는 Database 에서 데이터를 중복 없이 저장하고 무결성을 유지하는 방식입니다.
이를 통해 Database 는 더 작은 Table 로 나누어지며, 각 Table 은 데이터의 중복을 피하고 관련 데이터를 효율적으로 관리할 수 있습니다.
정규화 과정은 여러 단계로 나뉘는데, 그 중 3차 정규화는 1차와 2차 정규화를 만족한 상태에서 더욱 엄격하게 데이터 관계를 정의하는 방식입니다.
3NF 의 정의
3NF 은 다음 두 가지 조건을 만족하는 정규형입니다.
Table 이 2차 정규형 (2NF) 을 만족해야 한다.
Table 의 모든 비주요 속성(non-prime attribute)이 Primary Key 에만 종속적이어야 하며, 다른 비주요 속성에 종속되면 안 된다. 즉, 이행적 종속성(Transitive Dependency) 이 없어야 합니다.
Transitive Dependency 이란, 한 속성이 Primary Key 가 아닌 다른 속성에 의해 결정되는 것을 의미합니다.
예를 들어, 만약 속성 A 가 Primary Key B 에 의존하고, 속성 C 가 A 에 의존한다면, 속성 C 는 기본 키 B 에 간접적으로 종속 되므로 Transitive Dependency 이 발생한 것입니다. 이를 제거하는 것이 3NF 의 목표입니다.
A → B, C → A 는 결국 C → A → B, C 가 B 에 간접적으로 종속
3NF 가 되는 조건의 예제
1차 정규형 (1NF)
- 모든 값이 원자적인 값 이어야 하며, Table 의 각 열에 여러 값이 들어갈 수 없습니다.
2차 정규형 (2NF)
- Table 에 부분 함수 종속이 없어야 합니다. 즉, Composite Primary Key 가 있는 경우, Primary Key 의 일부만을 참조하는 속성이 없어야 합니다.
3차 정규형 (3NF)
- 모든 비 주요 속성이 Primary Key 에 직접 종속해야 하며, 다른 비 주요 속성에 Transitive Dependency 가 있으면 안됩니다.
3NF 의 예제
- 다음은 2NF 까지 만족하지만, 3NF 를 만족하지 않는 테이블입니다.
| 학번 (Student_ID) | 학과 (Department) | 학과장 (Department_Head) |
| 1001 | 컴퓨터공학 | 김철수 |
| 1002 | 기계공학 | 박영희 |
| 1003 | 컴퓨터공학 | 김철수 |
여기서 Student_ID 는 Primary Key 이고, Department 는 학번에 종속적 입니다.
그런데 Department_Head는 학과에 종속적 이며, 결국 학번에 Transitive Dependency 를 갖게 됩니다.
이 경우 Department_Head 는 Department 에 의해 결정되므로, Transitive Dependency 가 발생합니다.
3NF 로 변환
위의 테이블을 3차 정규화하려면, Transitive Dependency 를 제거해야 합니다.
이 경우,
Department_Head는Department에 의해 결정되므로 별도의 Table 로 분리해야 합니다.학생 정보 테이블 (Students Table)
| 학번(Student_ID) | 학과(Department) |
| 1001 | 컴퓨터공학 |
| 1002 | 기계공학 |
| 1003 | 컴퓨터공학 |
- 학과 정보 테이블 (Departments Table)
| 학과(Department) | 학과장(Department_Head) |
| 컴퓨터공학 | 김철수 |
| 기계공학 | 박영희 |
- 이렇게 2 개의 Table 로 분리하면,
Department_Head는 이제 학번이 아니라 학과를 통해 결정되므로, Transitive Dependency 가 사라지고 3NF 를 만족하게 됩니다.
3NF 의 장점
데이터 중복 최소화
3NF 는 Transitive Dependency 를 제거하여 데이터를 더 작은 Table 로 나누므로, 동일한 데이터가 여러 곳에 중복 저장되는 것을 방지합니다.
이를 통해 Database 의 크기를 줄이고, 데이터 중복으로 인한 갱신 이상을 방지할 수 있습니다.
데이터 무결성 유지
데이터가 여러 곳에 중복 저장되지 않으므로, 데이터를 갱신할 때도 일관성 있게 변경됩니다.
이는 데이터 무결성을 유지하는 데 매우 중요한 요소입니다. 한 곳에서 데이터를 수정하면, 동일한 정보가 있는 모든 곳에 변경 사항이 반영됩니다.
유지보수 용이성
Table 이 더 작은 단위로 분리되면, 데이터 모델이 간결해지고 유지보수가 용이 해집니다
필요한 Table 만 수정하면 되므로, Database 의 확장성과 유연성이 커집니다.
이상 현상 방지
3NF 는 Database 에서 흔히 발생할 수 있는 INSERT 이상, UPDATE 이상, DELETE 이상을 방지합니다.
예를 들어, 데이터를 INSERT 할 때 중복된 데이터를 여러 Table 에 추가할 필요가 없으며, UPDATE 할 때도 한 번의 작업으로 모든 관련 데이터가 수정됩니다.
3NF 의 단점
복잡한 JOIN
데이터를 더 작은 Table 로 나누기 때문에, 데이터를 조회할 때 여러 Table 간의 JOIN 이 필요할 수 있습니다.
이는 데이터 조회 Query 가 복잡해지고, 성능이 저하될 가능성이 있습니다.
성능 문제
정규화가 과도하게 이루어진 경우, 복잡한 Query 에서 성능이 떨어질 수 있습니다.
많은 Table 간의 JOIN 연산이 자주 발생하면, Database 성능에 부정적인 영향을 미칠 수 있습니다.
데이터를 이해하기 어려움
Table 이 너무 많이 나뉘면, 데이터를 전체적으로 파악하기 어려워질 수 있습니다.
특히 비 전문가나 Database 구조를 잘 모르는 사용자에게는 각 Table 간의 관계를 이해하는 것이 까다로울 수 있습니다.
3NF 를 사용하는 이유
3NF 는 Database 에서 데이터 중복을 줄이고, 데이터를 일관성 있게 유지하며, Database 설계의 무결성을 높이기 위해 사용됩니다.
특히, 대규모 Database System 이나 빈번한 데이터 갱신이 필요한 시스템에서 매우 유용합니다.
데이터 정규화를 통해 Database 의 확장성과 유연성을 높일 수 있으며, 데이터 갱신 시 일관성을 유지하는 데 중요한 역할을 합니다.
Materialized View
Database 에서 Query 결과를 물리적으로 저장하는 기능을 제공하는 Database Object 입니다.
일반 View 와 달리 Query 를 실행할 때마다 계산하지 않고, Query 결과를 저장해 두고 필요할 때 빠르게 조회합니다.
주요 특징
자동 갱신 가능
Materialized View 는 Database 시스템에서 자동으로 관리되거나 갱신될 수 있습니다.
이는 Trigger, 주기적인 Batch 작업, 혹은 데이터 변경 시 자동 갱신 메커니즘을 설정할 수 있는 경우에 유용합니다.
자동 업데이트
Materialized View 는 데이터가 변경되면 이를 자동으로 반영하거나, 주기적으로 갱신할 수 있습니다.
REFRESH옵션을 통해 설정할 수 있으며, 변경이 적고 정적 데이터에 매우 적합합니다.
Query 기반 저장
Materialized View 는 미리 정의된 SQL Query 를 기반으로 데이터를 저장합니다.
일반적으로 복잡한 JOIN, FILTERING, AGGREGATION 등을 수행하는 Query 결과를 저장하며, 그 결과를 빠르게 조회할 수 있습니다.
장점
자동 갱신 지원
- Database 에서 Trigger 나 주기적인 갱신을 설정하면, 데이터 변경에 따라 Materialized View 를 자동으로 갱신할 수 있어 관리가 비교적 간단합니다.
Query 최적화
복잡한 Query 결과를 저장해 둠으로써 반복적인 Query 실행을 피할 수 있습니다.
데이터 JOIN, FILTERING, AGGREGATION 이 반복되는 작업에서 매우 유용합니다.
간단한 유지보수
- Database 가 갱신 주기를 자동으로 관리할 수 있으므로 유지보수가 Summary Table 보다 덜 복잡할 수 있습니다.
단점
제한된 유연성
- Materialized View 는 일반적인 Table 이 아니므로, 특정 Summary 요구사항을 자유롭게 조정하거나 복잡한 계산을 포함하기 어려울 수 있습니다.
갱신 비용
- 데이터가 자주 변경되거나 Materialized View 가 자주 갱신될 경우, 갱신 비용이 발생할 수 있으며 이는 시스템 부하로 작용할 수 있습니다.
데이터 실시간성 부족
- 실시간 데이터를 필요로 하는 상황에서 Materialized View 는 갱신 주기와 관련된 지연이 있을 수 있습니다. 즉, 최신 데이터가 즉시 반영되지 않을 수 있습니다.
- Summary Table 과 Materialized View 의 비교
| 특성 | Summary Table | Materialized View |
| 생성 방식 | 개발자가 직접 정의하여 집계 데이터를 저장 | Query 결과를 자동으로 물리적 데이터로 저장 |
| 갱신 관리 | 수동으로 갱신하거나 Batch 작업으로 처리 | Database 시스템이 자동으로 갱신 가능 |
| 관리 복잡성 | Batch 작업, Scheduling 등을 관리해야 함 | 갱신 주기를 자동화할 수 있어 관리가 비교적 용이 |
| 저장소 사용량 | 집계 데이터가 중복 저장 되므로 저장 공간 증가 | 저장 공간이 필요하지만 시스템에서 관리 가능 |
| 성능 최적화 | 자유롭게 Table 을 설계하고 최적화 가능 | 복잡한 Query 의 실행 시간을 크게 단축 가능 |
| 갱신 주기 | Fact Table 에 맞춰 수동으로 갱신해야 함 | 실시간 또는 주기적인 자동 갱신 가능 |
| 유연성 | Customize 가 가능하여 다양한 요구 사항을 반영 가능 | Query 기반이므로 자유도가 낮고 복잡한 요구 사항에는 한계 있음 |
| 사용 시나리오 | 비즈니스에 맞춘 고도로 Customized Summary 가 필요할 때 | 복잡한 Query 를 미리 실행하고 그 결과를 빠르게 조회해야 할 때 |
사용 시나리오
Summary Table
정밀한 집계 또는 Customize 가 필요할 때
- 특정 비즈니스 요구에 따라 데이터를 다각도로 분석하거나 집계하는 경우에 유리합니다. 예를 들어, 여러 Data Source 를 결합하거나 특정 Summary 형태를 원할 때.
관리 주도적인 환경
수동으로 Table 을 갱신하고, 관리할 수 있는 환경에서 적합합니다.
Batch 처리나 ETL 작업을 통해 수시로 갱신되는 데이터를 요약할 때 주로 사용됩니다.
Materialized View
복잡한 쿼리의 반복 실행을 최적화할 때
자주 실행되는 복잡한 Query (i.e. 다중 Table JOIN, AGGREGATION 등)를 빠르게 조회해야 하는 경우에 적합합니다.
데이터가 실시간으로 크게 변경되지 않고, 미리 계산된 데이터를 반복 조회할 때 매우 유용합니다.
자동 갱신이 필요한 경우
- 데이터가 주기적으로 변경되고, 실시간 갱신을 요구하지 않는 상황에서 Database 가 자동으로 갱신을 관리할 수 있습니다.
Cardinality
Database 관점에서 2 가지 주요 의미로 사용
Table 의 Row Count (Cardinality of a Table)
Table 에서 Cardinality 는 Table 에 있는 Record (Row) 의 수를 의미합니다.
예를 들어, 1000 개의 Record 가 있는 Table 의 Cardinality 는 1000 입니다. 이 개념은 주로 Table 의 크기를 표현할 때 사용됩니다.
Column 의 Cardinality
테이블의 특정 열에서 고유한 값의 수를 나타냅니다.
High Cardinality
해당 Column 에 고유한 값이 많은 것을 의미.
예를 들어, 사용자 ID 열은 각 사용자가 고유한 ID 를 가질 것 이므로 Cardinality 가 높습니다.
Low Cardinality
해당 열에 고유한 값이 적은 것을 의미.
예를 들어, 성별이나 참/거짓 값 같은 Column 은 낮은 Cardinality 를 가집니다.
Cardinality 는 Index 최적화 또는 Query 성능 조정에서 중요한 요소로 작용합니다.
High Cardinality 의 Column 은 Index 효율이 높을 수 있음.
Low Cardinality 의 Column 은 Index 효율이 낮을 수 있음.
Bitmap Index
Bitmap Index 의 기본 개념
Bitmap Index 는 저장된 값들에 대해 Bitmap 을 생성하여, 각 값이 Data Set 에서 어디에 위치 하는지를 Bit 로 표현한 Index 입니다. 이는 Cardinality 가 낮은 값들 (즉, 값의 종류가 적은 Column) 에 특히 효과적 입니다.
예를 들어, 성별 데이터가 있는 Column 에서 값이 "남성(M)" 또는 "여성(F)" 두 가지로만 구성된다고 가정합시다.
일반적인 Index 에서는 각 Record 마다 값과 해당 위치 정보를 저장하는 방식으로 작동하지만, Bitmap Index 에서는 다음과 같이 Bitmap 을 생성합니다.
데이터 예제
| ID | 성별 |
| 1 | M |
| 2 | F |
| 3 | M |
| 4 | F |
| 5 | M |
Bitmap Index Representation:
"M" 값에 대한 비트맵: 1, 0, 1, 0, 1
"F" 값에 대한 비트맵: 0, 1, 0, 1, 0
여기서 각 행의 위치를 Bit 로 표현한 것입니다. "M" 이면 1, "F" 면 0 으로 표현
Bitmap Index 가 효율적인 이유
공간 절약
Bitmap Index 는 일반적인 B-Tree 와 같은 Index 방식과 비교했을 때 공간 효율성이 매우 뛰어납니다. 특히, Cardinality 가 낮은 값 들에서 유리합니다.
만약 성별처럼 두 가지 값만 존재하는 경우, 각 값을 Bit 로 표현하면 데이터의 크기를 크게 줄일 수 있습니다.
비트는 0 또는 1 로만 표현되기 때문에, 값이 반복되는 Column 에서 압축이 가능해지며, 이로 인해 저장 공간을 절약할 수 있습니다.
예를 들어, 10000 개의 행에서 "남성"과 "여성"이라는 값 만이 존재할 때, 이 두 값을 각각 하나의 Bit 로 표현하고 압축하면, 훨씬 적은 공간을 차지하게 됩니다.
빠른 검색
Bit 연산은 매우 빠르기 때문에 Bitmap Index 에서의 검색은 효율적 입니다. 만약 "성별이 남성인 데이터"를 검색하고 싶다면, "M" 에 해당하는 Bitmap 에서 1 인 위치를 찾아 해당 데이터를 추출하면 됩니다.
Bit 연산의 효율성
컴퓨터는 Bit 단위의 연산을 매우 빠르게 처리합니다. 예를 들어, 1 과 0 으로 이루어진 Bitmap 에서 "남성" 과 "여성" 을 구별하는 작업은 단순히 비트 AND, OR 연산을 통해 즉시 처리될 수 있습니다.
예시로, 성별이 "M" 인 데이터를 찾는 쿼리는
1, 0, 1, 0, 1Bitmap 을 그대로 활용하여 빠르게 조회할 수 있습니다. 이때 수천, 수백만 건의 데이터를 처리 하더라도 비트 연산을 통해 빠르게 처리 가능합니다.
빠른 다중 조건 Query 처리
Bitmap Index 의 강력한 기능 중 하나는 다중 조건 Query 를 빠르게 처리하는 능력입니다. 예를 들어, 여러 Column 의 조건을 함께 Filtering 하는 경우에도 효율적입니다.
예시: 성별이 "M" 이고 나이가 30세 이상인 데이터를 찾는다고 할 때, 각 Column 에 대한 Bitmap 을 결합하여 매우 빠르게 결과를 도출할 수 있습니다.
성별이 "M" 인 Bitmap:
1, 0, 1, 0, 1나이가 30세 이상인 Bitmap:
1, 1, 0, 1, 0
두 Bitmap 을 AND 연산을 하면 1, 0, 0, 0, 0 이라는 결과가 나오며, 이 결과로 빠르게 일치하는 데이터를 조회할 수 있습니다. 이러한 다중 조건 처리를 통해 성능을 크게 향상시킬 수 있습니다.
압축 기술과 결합
Bitmap Index 는 데이터가 반복될 때 압축 알고리즘과 결합하여 효율성을 극대화할 수 있습니다. Bitmap 데이터는 특성상 0 과 1 의 반복 패턴이 나타날 가능성이 높으며, 이때 Run Length Encoding (RLE) 등의 압축 방식을 활용하면 큰 데이터를 압축하여 처리 속도를 더 높일 수 있습니다.
- 예시로
1, 1, 1, 1, 0, 0, 0, 0과 같은 Bit Array 를4개 1, 4개 0으로 표현하면, 훨씬 적은 공간을 사용하게 됩니다.
Cardinality 가 낮은 경우 효율성 극대화
Bitmap Index 는 Cardinality 가 낮은 Column 에서 특히 효율적 입니다. 성별, 상태 코드, 또는 Boolean 값과 같이 값의 범위가 제한적인 Column 일수록, Bitmap 을 활용한 Indexing 이 효율적으로 작동합니다.
예를 들어, 성별처럼 2개의 값만 존재하는 경우, Bitmap 으로 각각을 1 과 0 으로 표현하면 매우 작은 크기의 Index 로 빠른 검색이 가능합니다.
반면, Cardinality 가 높은 경우에는 Bitmap 의 크기가 커질 수 있어 효율성이 떨어질 수 있으므로 주의해야 합니다.
Bitmap Index 의 장단점
장점
빠른 읽기 성능
- Bit 연산은 매우 빠르며, 대량의 데이터를 빠르게 조회할 수 있습니다.
공간 효율성
- Cardinality 가 낮은 경우, 저장 공간이 매우 적게 필요하고 압축이 용이합니다.
다중 조건 Query
- 여러 Column 에 대한 Filtering 작업을 빠르게 처리할 수 있습니다.
복잡한 Aggregation Query 에서 유리
- Bitmap 을 활용하여 빠르게 Aggregation 연산을 수행할 수 있습니다.
단점
Cardinality 가 높은 Column 에 비 효율적
- Bitmap 의 크기가 커질 수 있어 성능이 떨어질 수 있습니다.
데이터 변경에 약함
- 빈번한 데이터 삽입, 삭제, 업데이트가 발생하는 경우 Bitmap 을 자주 재 생성해야 하므로, 데이터 변경 작업에 적합하지 않습니다.
OLAP Cube
간단한 설명
OLAP Cube 는 Multi-Dimensional 데이터를 효율적으로 분석하고 빠르게 조회하기 위해 사용하는 데이터 구조입니다.
OLAP (Online Analytical Processing) 는 데이터 분석과 Query 에 특화된 방식으로, Cube 는 여러 Dimension 에서 데이터를 집계하여 다양한 시각으로 분석할 수 있게 해줍니다.
OLAP Cube 는 특히 Multi-Dimensional 분석을 필요로 하는 BI, Data Warehouse 에서 널리 사용됩니다.
OLAP Cube 의 핵심 개념
Multi-Dimensional Data Modeling
OLAP Cube 는 데이터를 여러 Dimension 에서 분석할 수 있도록 구조화된 데이터 모델입니다.
각 Dimension 은 데이터의 특정 속성을 나타내며, 이러한 Dimension 들을 기준으로 데이터를 분석할 수 있습니다.
- 예를 들어, 시간(Time), 제품(Product), **지역(Region)**과 같은 Dimension 이 있을 수 있습니다.
Measures (측정값)
OLAP Cube 는 데이터를 분석할 때 Measure 를 중심으로 집계합니다.
Measure 은 주로 수치 데이터로, 예를 들어 매출액, 주문 수량, 이익 등이 Measure 이 될 수 있습니다.
Dimension 을 기준으로 Measure 을 다각도로 분석할 수 있습니다.
Dimensions (차원)
Dimension 은 데이터를 분석하는 기준입니다.
Dimension 은 데이터의 특정 속성을 나타내며, OLAP Cube 는 여러 Dimension 을 동시에 분석할 수 있게 합니다.
예를 들어, 시간 차원은 연도, 월, 일 등으로 세분화될 수 있고, 제품 차원은 카테고리, 브랜드, 제품명 등으로 세분화될 수 있습니다.
Cell (셀)
OLAP Cube 는 각각의 Cell 에 데이터를 저장합니다.
각 Cell 은 여러 Dimension 의 교차점에서 발생한 Measure 을 의미합니다.
예를 들어, "2023년 1월에 서울에서 A제품의 매출액"이라는 분석 결과는 시간, 지역, 제품 Dimension 의 교차점에 해당하는 Cell 에 저장됩니다.
Cube 의 Dimension 수
OLAP Cube 는 Multi-Dimensional 구조를 가지며, Dimension 수는 분석하고자 하는 데이터의 특성에 따라 달라질 수 있습니다.
두 개 이상의 Dimension (예: 시간, 지역, 제품 등)을 결합하여 데이터를 다각도로 분석할 수 있습니다.
Dimension 이 많아질수록 분석할 수 있는 데이터의 복잡성은 증가하지만, 분석 유연성도 높아집니다.
OLAP Cube 의 동작 방식
Aggregation
OLAP Cube 는 데이터를 사전에 집계하여 저장합니다.
예를 들어, 일자별 판매량을 주간별, 월별로 집계해두고, 필요할 때 바로 조회할 수 있게 하는 방식입니다.
이를 통해 실시간으로 데이터를 계산할 필요 없이 빠르게 응답할 수 있습니다.
Roll-up
Roll-up 은 데이터를 더 높은 수준으로 집계하는 과정입니다.
예를 들어, 일별 데이터를 주별 또는 월별 데이터로 집계하는 것을 의미합니다.
더 높은 Dimension 으로 데이터를 요약하여 분석할 수 있습니다.
Drill-down
Drill-down 은 Roll-up 과 반대로, 데이터를 더 세부적으로 분석하는 것입니다.
예를 들어, 월별 데이터를 조회한 후, 특정 월의 일별 데이터를 Drill-down 하여 더 자세한 분석을 수행할 수 있습니다.
Slice 와 Dice
Slice
Cube 에서 특정 Dimension 의 특정 값을 선택하여 데이터를 Filtering 하는 작업입니다.
예를 들어, 특정 연도와 특정 제품군의 판매 데이터를 조회하는 경우를 의미합니다.
Dice
여러 Dimension 의 값에 따라 데이터를 Filtering 하는 작업입니다.
예를 들어, 특정 연도, 특정 지역, 특정 제품군의 매출 데이터를 추출하는 작업입니다.
Pivot
Pivot 은 데이터 분석의 시각을 전환하는 작업입니다.
예를 들어, 지역별 매출을 기준으로 데이터를 분석하다가, 제품별 매출로 분석 시각을 전환하는 방식입니다.
OLAP Cube 는 이런 Multi-Dimensional 분석을 빠르게 수행할 수 있도록 지원합니다.
OLAP Cube 의 유형
MOLAP (Multidimensional OLAP)
MOLAP 은 데이터를 Multi-Dimensional Cube 로 사전에 저장하는 방식으로, 성능이 매우 뛰어납니다.
모든 데이터를 Multi-Dimensional 배열 형태로 저장하여 사전 계산된 집계 데이터를 바로 조회할 수 있습니다.
그러나 대규모 데이터를 처리하기 위해서는 많은 저장 공간이 필요할 수 있습니다.
ROLAP (Relational OLAP)
ROLAP 은 관계형 데이터베이스(RDBMS) 에서 데이터를 조회하는 방식입니다.
데이터를 별도로 사전 계산하지 않고, 필요할 때 실시간으로 집계를 수행합니다.
저장 공간을 절약할 수 있지만, Query 성능이 MOLAP 보다 느릴 수 있습니다.
ROLAP 은 기존의 관계형 데이터베이스 구조를 활용할 수 있어 확장성이 좋습니다.
HOLAP (Hybrid OLAP)
HOLAP 은 MOLAP 과 ROLAP 의 장점을 결합한 방식입니다.
자주 사용되는 데이터는 MOLAP 처럼 미리 집계하여 저장하고, 덜 자주 사용 되는 데이터는 ROLAP 처럼 실시간으로 집계하여 처리합니다.
이를 통해 성능과 저장 공간을 적절히 균형 있게 사용할 수 있습니다.
OLAP Cube 의 장점
빠른 Query 성능
OLAP Cube 는 사전에 데이터를 집계해두기 때문에, 대규모 데이터에 대해 즉시 응답할 수 있습니다.
복잡한 Multi-Dimensional 분석도 빠르게 수행할 수 있어, BI 시스템이나 데이터 분석 환경에서 매우 유리합니다.
Multi-Dimensional 분석
OLAP Cube 는 다양한 Dimension 에서 데이터를 분석할 수 있기 때문에, 다각적인 분석이 가능합니다.
시간, 제품, 지역 등 여러 시점에서 데이터를 분석할 수 있으며, Roll-up, Drill-down, Slice 등의 기법을 통해 세부적으로 데이터를 탐색할 수 있습니다.
사용자 친화적인 분석
OLAP Cube 는 사용자에게 직관적인 분석 환경을 제공합니다.
사용자는 SQL 같은 복잡한 Query 언어를 몰라도, 차원과 Measures 을 선택해 데이터를 분석할 수 있습니다.
많은 BI 도구에서 OLAP Cube 를 사용하여 데이터를 시각적으로 분석할 수 있습니다.
효율적인 데이터 탐색
OLAP Cube 는 사용자가 대규모 Data Set 에서 효율적으로 탐색할 수 있도록 설계되었습니다.
Multi-Dimensional 으로 데이터를 분석하고, 다양한 관점에서 Insight 를 도출할 수 있습니다.
OLAP Cube 의 단점
저장 공간 문제
MOLAP 방식은 사전에 데이터를 집계하고 저장하기 때문에 대규모 데이터의 경우 저장 공간이 많이 필요합니다.
많은 Dimension 을 고려해야 하는 경우에는 Cube 의 크기가 급격히 커질 수 있습니다.
유연성 부족
사전에 정의된 Dimension 과 Measures 에 맞추어 데이터를 집계 하므로, 분석 요구가 변경되면 Cube 를 다시 설계하거나 재구성해야 합니다.
사전에 정의되지 않은 새로운 분석 요구가 생길 경우, 즉각적으로 대응하기 어려울 수 있습니다.
실시간 데이터 분석의 어려움
OLAP Cube 는 미리 집계된 데이터를 사용하는 방식이기 때문에, 실시간 데이터 분석에는 적합하지 않을 수 있습니다.
데이터가 계속해서 실시간으로 변동하는 경우, 집계 데이터와 Raw 데이터 사이에 불일치가 발생할 수 있습니다.
Cube 설계의 복잡성
Cube 를 설계할 때 각 Dimension 의 수준과 Measures 을 신중하게 결정해야 하므로, 설계 단계에서 복잡성이 존재합니다.
잘못된 설계는 데이터 분석의 유연성을 떨어뜨리거나 성능 문제를 초래할 수 있습니다.