데이터 웨어하우스?? 데이터 마트??
데이터 웨어 하우스(Data Warehouse)
데이터 웨어하우스는 다양한 출처의 데이터를 통합하여 중앙 집중식으로 저장하고, 분석 및 보고를 위한 데이터 관리 시스템이다. 이는 BI활동을 지원하며, 현재 및 과거 데이터를 포함하여 조직의 의사결정에 도움을 줄 수 있다.
데이터 마트 (Data Mart)
데이터 마트는 특정 부서나 주제 영역의 요구를 충족시키기 위해 설계된 데이터 웨어하우스의 하위 집합이다. 특정 사용자 그룹이 필요한 데이터에 빠르게 접근 하고 분석할 수 있도록 지원한다.
그렇다면 왜 사용하는 걸까?
운영 시스템의 데이터베이스를 직접 조회해 분석하는 것은 언뜻 간단해 보이지만, 실제로는 다양한 한계와 위험을 동반합니다. 예를 들어, 쇼핑몰 서비스가 다음 네 가지 분리된 시스템으로 운영된다고 가정해 봅시다.
이들 시스템의 데이터베이스는 모두 OLTP용으로 설계되어 있습니다. 즉, 짧고 빈번한 조회·삽입·수정·삭제 작업에 최적화되어 있죠. 반면, “회원들이 지난 6개월 동안 어떤 상품을 얼마나 주문했는지” 같은 대규모 집계 쿼리는 OLAP 성격이 강해서 만약 수백만~수천만 건 단위의 데이터를 Join, Group By로 집계하면 디스크 I/O와 CPU 사용량이 급증하게되고 그 결과 웹 서버에서의 응답 지연으로 실제 서비스에 차질이 생길수가 있습니다.
이런 이유로, 데이터 웨어하우스를 별도로 구축해 운영 DB에서 주기적으로 데이터를 복제·적재하는 방식을 사용합니다. 데이터 웨어하우스는 OLAP 특화 스토리지(MPP, 칼럼형 DB 등)에 데이터를 쌓아두고, 복잡한 집계·분석 쿼리를 수행하도록 설계되어 있기 때문에 다음과 같은 장점이 있습니다.
분리된 분석 환경: 운영 DB에는 별다른 부하를 주지 않고, 분석 전용 인프라에서 자유롭게 쿼리 실행
일관된 시계열 데이터: 스냅샷 방식으로 특정 시점의 데이터를 저장해 분석 중에도 변하지 않는 결과 보장
확장성: 대규모 데이터 처리에 최적화된 분산 아키텍처(MPP, 클라우드 DW 등)를 저비용으로 확장 가능
관리 편의성: ETL/ELT 파이프라인을 통해 데이터 품질·거버넌스를 적용하고, 분석에 필요한 스키마로 사전 가공
결론적으로, 운영 시스템의 DB는 “빠른 트랜잭션 처리”에, 데이터 웨어하우스는 “복잡한 분석·집계”에 각각 최적화된 역할을 분리함으로써 시스템 안정성과 분석 효율성을 동시에 확보할 수 있습니다.
데이터 웨어하우스와 데이터 마트 구축방법
데이터 웨어하우스와 데이터 마트는 온프레미스, 클라우드, 또는 하이브리드 환경에 구축할 수 있으며, 각 환경별로 사용되는 기술 스택과 관리 방식이 다릅니다. 온프레미스에서는 Teradata, Oracle Exadata 같은 하드웨어 어플라이언스와 전통적 RDBMS·ETL 도구를 사용하며 , 클라우드에서는 AWS Redshift, Google BigQuery, Azure Synapse, Snowflake 같은 완전관리형 서비스를 통해 무제한 확장성과 운영 편의성을 얻을 수 있습니다 . 하이브리드 또는 레이크하우스 형태로는 S3·HDFS 등 객체 스토리지 위에 Delta Lake, Iceberg, Presto/Trino, Athena 등을 결합해 유연성과 비용 효율을 모두 추구할 수있습니다.
빅데이터 및 분석을 위한 데이터 웨어하우스 설계 방법론 비교
참고했던 논문을 보면 (Inmon, Kimball, Data Vault, Lambda Architecture) 이렇게 4가지 방법이 있다. 한번 살펴보자
Inmon 방법론
처음부터 전사적 데이터 웨어하우스를 최우선으로 구축하는 톱다운(Top-down) 방식의 설계 방법이다. 다양한 운영 시스템에서 ETL과정을 통해 중앙의 통합 EDW에 적재한 후, 필요에 따라 DM를 생성하는 접근법으로 기업 전체 데이터를 일관되고 통합된 하나의 진실된 데이터 소스로 관리한다. 이런 설계 방법이다 보니 전사 데이터에 대한 단일 통합 뷰를 제공하여 모든 사용자가 하나의 일관된 데이터를 활용 할수있고, 중앙 집중식 ETL과 메타데이터 관리로 데이터 품질 및 거버넌스를 효과 적으로 유지 할 수 있다. 다만, 초기 구축에 막대한 노력과 비용이 들며 전체 EDW를 구축해야 비로소 활용이 가능하기 때문에 초기 가치 실현이 느리다. 새로운 요구 상항이나 소스 변경에 구조를 유연하게 바꾸기 어려워 변화에 대한 대응이 느리고 개발 주기가 길다라는 단점이 있다.
Kimball 방법론
Kimball 방법론은 Inmon 방법론에 반대인 바텀 업(Bottom-up)방식의 비즈니스 중심 DW 접근법으로, 기업의 각 부서나 프로세스별로 DM를 개별 구축한 후 이를 통합하는 형태를 취한다. 그래서 비즈니스 요구에 직접 대응하는 주제별 DM를 신속히 구축함으로써 현업에 유용한 인사이트를 빠르게 제공할 수 있고, DW를 한번에 구축하지 않고 부분별로 점진적으로 개발하기 때문에 변화하는 요구에도 기민하게 대응할 수 있다. 하지만 여러 DM을 운영하게 되면 데이터 사일로가 생기기 쉽고 중앙에서 엄격히 관리되지 않을 경우 부서간 데이터 정의에 불일치가 발생할 수 있다. 또한 분산된 DM 개발로 인해 데이터 중복 및 비관리 문제가 생길 수 있고, 일관성이 저해될 우려도 있다. 이로 인해 일관성 유지와 통합 관리가 어려워질 수 있어 지속적인 데이터 거버넌스 노력이 필요하다.
Data Vault 2.0 모델
빅데이터 환경에서 잦은 스키마 변화와 대규모 확장을 효율적으로 처리하기 위해 고안된 허브 앤 스포크 아키텍처 기반의 설계 기법이다. 주요 개념은 원시 데이터를 변형 없이 허브(Hub) 테이블에 적재하고, 엔티티 간 관계 는 링크(Link) 테이블로, 속성의 이력과 상태는 새틀라이트(Satellite) 테이블로 관리하는 것이다 . 즉 모든 원본 데이터를 손실 없이 기록해 두고, 그 위에 가상 뷰나 데이터 마트 계층을 통해 활용하는 방식으로 동작하며, 이력 추적과 이기종 소스 데이터 통합에 강점이 있다. 또한 스키마 변경이 유연해 새로운 소스를 쉽게 통합할 수 있고, 모든 원본 변경 이력을 그대로 보존해 감사, 추적이 용이하며, RDBMS나 NoSQL등 하이브리드 저장소를 활용해 대용량 데이터 분산처리로 확장성과 성능을 확보한다는 장점이 있다. 다만 허브, 링크, 새틀라이트 구조가 복잡해 비즈니스 사용자가 직접 이해하기 어려우며 분석용 가상 뷰나 DM 계층 설계와 복잡한 ETL 파이프라인 전문확보가 필수라는 단점이 있다.
Lambda 아키텍처
Lambda 아키텍처는 배치 레이어, 스피드 레이어, 서빙 레이어를 결합해 과거 데이터 분석과 실시간 분석을 동시에 수행하는 빅데이터 처리 패턴이다. 배치 레이어는 전체 데이터를 주기적으로 처리해 정확한 집계 결과를 생성하고, 스피드 레이어는 최신 이벤트를 즉시 처리해 실시간 인사이트를 제공한다. 서빙 레이어는 두 레이어의 결과를 통합해 사용자에게 일관된 쿼리 서비스를 제공하며, 데이터의 완전성과 실시간성을 한 시스템에서 보장할 수 있다. 데이터는 불변(immutable) 형태로 저장되고 필요시 전체 재처리를 통해 정확도를 높일 수 있으며, 분산 및 가로 확장 구조로 높은 처리 성능과 내결함성을 확보한다. 다층 구조와 다양한 기술 스택(Hadoop, Spark, Kafka 등)을 활용하기 때문에 설계·구현·운영이 복잡하고 비용 및 전문 지식 요구가 크다는 단점이 있다. 또한 배치와 실시간 결과를 병합·중복 저장해야 하므로 시스템 통합과 유지보수 부담이 크고, 데이터 정합성 관리가 추가적으로 필요하다.
정리
결론적으로, 방법론 선택은 조직의 데이터 특성, 분석 목표, 규모, 실시간 요구, 보유역량 등 종합적으로 고려해서 이뤄져야 한다. 예를 들어, 안정적인 통합 데이터 기반의 정형 리포팅이 주 목적이라면 Inmon식 접근이 유리할 수 있고, 민첩한 개발로 빠른 가치를 원한다면 Kimball식 데이터 마트 전략이 적합하다. 소스 변경이 빈번하고 데이터 감사가 중요시된다면 Data Vault 2.0이 유용하며, 실시간 대용량 데이터 처리가 핵심이라면 Lambda 아키텍처가 강점을 발휘할 것이다. 이처럼 각 방법론의 강점과 한계를 파악하고 조직이나 자신의 용도에 맞는 설계전략을 선택하면 된다. DW 설계 방법론이 위에 4가지만 있는게 아니다 추가적으로 Kappa Architecture, Data Mesh, Hybrid Architecture, Anchor Modeling까지 있다 기회가 되면 4가지만 또 한번 다뤄 보겠다.
