데이터 웨어하우스(Data Warehouse)는 십 수년간 기업의 의사결정 및 분석을 위한 가장 강력한 엔터프라이즈 애플리케이션의 지위를 유지해 왔는데요. 데이터 웨어하우스를 지원하는 수많은 애플리케이션들도 함께 발전해 왔습니다.

여기에는 수많은 하드웨어와 소프트웨어 벤더들이 제공하는 전통적인 OLAP과 ETL 툴들, 데이터베이스와 서버를 통합한 데이터 웨어하우스 어플라이언스(DW Appliance)들과 인-메모리(In-Memory) 데이터베이스, 비주얼라이제이션(Visualization) 툴 등이 포함됩니다.

빅데이터와 함께 발전하고 있는 하둡 에코시스템에도 데이터 웨어하우스 구축을 위한 다양한 기술 세트가 포함되어 있습니다.

예를 들어, 아파치 하이브는 SQL을 이용하여 분산 스토리지 환경에 저장된 대규모 데이터세트를 처리하기 위한 하둡 에코 시스템의 데이터 웨어하우스 옵션입니다. 하둡 에코시스템 내부뿐만 아니라 데이터 웨어하우스 관련 툴과 데이터베이스를 공급하던 기존 메이저 벤더들도 하둡 커넥터들을 자신들의 데이터베이스와 툴에 포함시키는 형태로 하둡과의 연계를 강화하고 있습니다.

현재까지 Oracle, IBM, Microsoft 등에서 제공하는 데이터베이스에 다차원 모델링을 구축한 사례에 관한 수많은 자료가 존재하지만, 하둡 에코시스템을 이용한 데이터 모델링에 대해서는 아직까지 미약한 것이 사실입니다. 하지만 빅데이터 기술의 발전에 따라 향후에는 하둡이 엔터프라이즈 데이터 웨어하우스 구축에 사용될 수 있는 또 다른 플랫폼의 역할을 수행할 수도 있을 것입니다.

따라서, 데이터 웨어하우스를 하둡 에코시스템 기반으로 이관하거나 새롭게 구축하고자 할 때 다차원 모델링에서는 어떤 기술적 요소를 고려해야 하는가에 대해 간략히 살펴보고자 합니다.

다차원 모델링이란?

다차원 모델링은 데이터 웨어하우스 구축을 위한 근간이 되는 모델링 기법입니다. 다차원 모델링을 통해서 사용자들이 데이터를 ‘쉽고’, ‘빠르게’ 데이터 웨어하우스에서 정보를 추출할 수 있는 환경을 구성하게 됩니다.

스타 스키마(Star Schema)로 대표되는 다차원 모델링은 실제 사용자가 데이터를 좀 더 손쉽게 이해할 수 있도록 해주고, 사용자들이 만들어내는 쿼리 결과를 빠른 속도로 제공할 수 있기 때문에 데이터 웨어하우스 모델링 작업에서 가장 많이 사용하는 기법입니다.

다차원 모델링의 주요 구성 요소로는 팩트 테이블과 디멘션 테이블을 들 수 있습니다. 팩트 테이블은 비즈니스 프로세스 상에서 발생하는 수치 값(판매 수량, 지불 금액 등)을 말합니다.

팩트 테이블의 가장 중요한 성격 중 하나는 그래뉴래러티(Granularity)로, 하나의 팩트 테이블의 각 행은 모두 동일한 수준의 값이어야 한다는 것입니다. 이 특성이 유지되는 한, 팩트 테이블의 모든 값에 대해 다양한 연산을 적용하더라도 팩트 테이블의 계산 값에 대해 무결성을 보장할 수 있습니다.

또 다른 구성요소인 디멘션 테이블은 팩트 테이블을 설명하는 항목으로 날짜, 판매지점, 고객 등을 예로 들 수 있습니다. 디멘션과 팩트 테이블을 이용한 다차원 모델은 스타 스키마 또는 스노우플레이크 스키마(Snowflake Schema)로 표현되며, 이들 엔터티가 물리적 테이블로 전환된 후 데이터 적재, 데이터 분석 등에 활용됩니다.

다차원 모델링의 역할

사용자들이 데이터를 조회하고 분석하는 일을 수행하기 위해서는 데이터 자체에 대한 이해가 선행되어야 하기 때문에, 다차원 모델링이라는 도구를 이용하여 사용자들이 데이터 구성에 관한 이해를 할 수 있는 자료를 제공해야 합니다.

그러므로 하둡 기반 데이터 웨어하우스 구축 시에도 다차원 모델링을 첫 번째 단계로 수행하여, 이 결과물을 사용자들에게 제공해야 합니다. 다시 말해 하둡 기반 데이터 웨어하우스에도 동일한 다차원 모델링 작업을 수행해야 하며, 이 다차원 모델로 사용자들이 데이터를 손쉽게 이해할 수 있도록 해야 합니다.

RDBMS1 기반 데이터 웨어하우스 설계 단계와 유사한 점은 하둡 기반 데이터 웨어하우스 구축 시에도 다차원 모델을 물리 모델로 전환할 때, 사용자들이 만들게 될 예측 불가능한 수많은 쿼리의 성능을 보장할 수 있도록, 하둡의 특성을 반영하여 추가적인 물리 설계 작업을 수행해야 한다는 점입니다.

RDBMS를 이용하여 데이터 웨어하우스를 구축하는 경우 다차원 모델링 후 데이터 웨어하우스의 기반 데이터베이스의 다양한 기능을 사용하듯, 하둡을 이용하는 경우에도 다차원 모델링을 논리 모델링 단계로 보아야 합니다. 이를 기반으로 물리 모델 단계에서 엔터티의 통합, 분리 등을 이용하여 최적의 쿼리 성능을 제공할 수 있도록 재설계 해야 합니다.

또한, 사용자의 쿼리 패턴은 예측할 수 없기 때문에 단일 또는 몇 개 쿼리의 성능 향상이 아닌 다양한 쿼리의 전반적인 성능 향상이 가능하도록 구성해야 합니다. 다음으로 다차원 모델이라는 논리 모델을 설계한 후 물리 모델링 단계의 고려 사항에 대해 살펴보겠습니다.

하둡 모델링 고려사항

하둡 기반 데이터 웨어하우스의 물리 모델을 구현하는 절차는 다음과 같습니다. 우선, 논리 설계 단계의 다차원 모델링을 기반으로 다음과 같은 단계를 거쳐 물리 모델을 완성하게 됩니다.

※ 아래의 물리 모델링 절차는 HDFS•하이브 활용을 가정했습니다.

① 반정규화(De-normalization)

HDFS(Hadoop Distributed File System) 기반으로 스타 스키마 모델을 구현할 때 성능 향상을 위해 반정규화를 적용합니다. RDBMS와 달리 하둡에서는 상대적으로 저렴한 장비와 소프트웨어 덕분에 반정규화로 인한 데이터의 중복은 허용할 수 있습니다.

그러나 반정규화를 적용한 데이터세트에 수정 사항을 반영하는 작업은 중복된 데이터 모두에 수정 사항을 동일하게 반영해야 하므로 쉽지 않은 작업이 될 것입니다.

그러므로 자주 변화하는 데이터를 대상으로 반정규화를 적용하는 경우 조회 성능과 배치 작업 간의 트레이드오프를 고려하여 신중하게 사용 여부를 판단해야 합니다. 다음은 하둡 기반 데이터 웨어하우스 구축에서 사용할 수 있는 반정규화 기법의 예시입니다.

A. 디멘션 통합
행의 수가 적은 여러 개의 디멘션들을 묶어서 하나의 디멘션 데이터세트로 구성하여, 팩트 데이터세트와 조인의 개수를 줄입니다. 하둡에서는 디멘션 데이터세트들과 팩트 데이터세트 간의 조인 개수가 많아진다면 최적화하기 어렵습니다.

그러므로 데이터의 건수가 적고 개수가 많으며 빈번하게 쿼리에서 함께 사용되는 디멘션 데이터세트들은 Cartesian product(데카르트 곱: 집합 A와 B를 곱한 집합)를 구성하여 단일 데이터세트로 만들고, 이 데이터세트와 팩트 데이터세트를 조인하도록 만듭니다.

하둡의 경우 많은 수의 작은 파일보다는 적은 수의 큰 파일을 처리하는 것이 최적의 성능을 보여주기 때문에, 여러 개 작은 디멘션보다 크기가 큰 디멘션 하나가 처리 성능이 더 높습니다. 이 방식은 RDBMS에서 지원하는 스타 조인을 물리적인 데이터세트로 구성하는 방식과 유사합니다.

B. 팩트-디멘션 통합
쿼리에 함께 쓰이는 디멘션과 팩트 데이터세트를 대상으로 사용자 쿼리에서 조인하지 않고 배치 프로세스에서 조인을 적용하며 하나의 데이터세트로 구성합니다.

디멘션 통합과 마찬가지로, 조인 회수를 줄이기 위하여 데이터 적재 시점에 이미 조인된 데이터세트를 만들어 두어 쿼리에서 최소한의 데이터세트가 사용되도록 구성합니다. 통합의 대상이 팩트-디멘션이라는 것 외에는 디멘션 통합과 동일합니다.

C. 배치 처리용 데이터세트 생성
HDFS의 특성을 생각해보면 단일 건의 업데이트보다 전체 데이터세트의 재생성이 빠른 경우가 대부분이므로, 데이터 성격에 따라 적재 프로세스에 필요한 데이터세트를 추가합니다.

예를 들어 현재 시점을 설명하는 데이터세트가 필요하다면, 주기적인 배치 작업으로 데이터마트에서 해당 건을 업데이트하기보다는 적재 단계에서 전체 이력을 가지고 있는 데이터세트를 추가 생성하고, 이 데이터세트를 이용하여 최종 데이터마트를 재생성하는 프로세스도 고려해 볼 수 있습니다.

② 파일 저장 방식 결정

HDFS 등에서 사용할 저장 옵션을 정의합니다. 저장 옵션은 데이터세트의 각각의 특징에 따라 서로 다른 방식을 사용할 수 있습니다. 만약 행 기반 데이터 접근이 필요하다면 시퀀스 파일을, 컬럼 단위 접근이 필요하다면 컬럼너(Columnar) 포맷인 파케이나 RCFile 등을 사용함으로써 성능을 향상시킬 수 있습니다.

특히 사용자들이 하나의 데이터세트의 일부 컬럼만을 이용하여 데이터를 추출하고 활용하는 데이터 웨어하우스를 구성하는 경우, 해당 데이터세트의 일부 컬럼만을 추출할 수 있도록 만들어주는 컬럼너 포맷을 사용하면 조회 성능이 크게 향상됩니다.

③ 압축 코덱(Compression Codec) 결정

압축(Compression)은 데이터 저장 공간을 줄여줄 뿐만 아니라, 디스크 I/O의 양을 줄여주므로 처리 성능을 향상시키는 데에도 도움이 됩니다. 압축 코덱을 선택할 때는 분산 처리 환경에서 각 노드들이 병렬 처리할 수 있도록 분할 가능한 압축 코덱을 사용해야 합니다.

압축 코덱 차체에서 ‘분할 가능’을 지원하지 않는다면, 분할 가능한 컨테이너 포맷인 애브로, 시퀀스 파일 등과 같은 파일 저장 방식을 사용해야 합니다. 또한, 압축 코덱도 파일 저장 방식과 동일하게 테이터세트의 특성 또는 데이터세트로 구성한 파티션의 특성에 따라 하나의 데이터세트 내에서 파티션 별로 다르게 적용할 수 있습니다.

만약 파티션의 데이터가 자주 사용하지 않은 오래된 데이터라면 압축률이 높은 압축 코덱을, 자주 사용하는 데이터라면 압축 및 압축 해제 처리 속도가 빠른 압축 코덱을 적용합니다.

④ 데이터세트 파티셔닝(Partitioning) 전략 수립

데이터 조회 패턴을 분석하여, 전체 데이터세트를 검색하지 않고도 원하는 결과를 얻을 수 있도록 데이터세트에 파티션을 구성합니다. 파티셔닝은 쿼리의 스캔 대상 범위를 줄여 I/O를 감소시키기 때문에 성능을 높일 수 있습니다.

예를 들어 사용자들의 조회 패턴에 따라 일별 또는 조직 등과 같은 기준을 이용하여 파티션 단위로 데이터세트를 분리해 두면, 하루치 데이터를 추출하는 쿼리는 전체 데이터세트가 아니라 해당일의 일별 파티션 하나만을 검색하게 되므로 풀 스캔에 비해 높은 성능을 보여 주게 됩니다.

파티셔닝 적용 방식은 RDBMS를 이용한 데이터 웨어하우스 구축 시 적용하는 파티셔닝 전략과 동일합니다. 한 가지 차이점이 있다면 RDBMS에서는 하나의 데이터세트를 어떻게 파티셔닝 할 것인가를 결정하는 작업이라면, 하둡에서는 조회 패턴에 따라 하나의 데이터세트에 여러 개의 파티셔닝 전략을 세운다는 점입니다.

하둡에서는 원본 데이터세트를 복제하여 각 전략에 대응하는 파티션 된 데이터세트를 여러 개 만들 수 있다는 점을 기억해 두어야 합니다. 즉, 하둡에서는 데이터세트를 여러 개로 복제하여 디스크 공간을 희생함으로써 성능을 향상시키는 방법을 사용할 수 있습니다.

⑤ 데이터세트 버키팅(Bucketing) 전략 수립

버키팅은 데이터세트를 해시 알고리즘을 이용하여 특정 컬럼의 값을 이용하여 클러스터 된 데이터의 집합인 버킷으로 분할하는 작업을 의미합니다. 하나의 버킷에는 기준 컬럼 값이 여러 개(1개 이상) 포함될 수 있지만, 기준 컬럼 값 중 임의 값 1개는 하나의 버킷에만 포함됩니다.

파티션과 함께 사용할 수 있으며, 파티셔닝 된 데이터세트를 더 작은 크기로 나눌 수 있습니다(RDBMS의 해시 파티셔닝 전략과 유사합니다). 버키팅의 장점은 파티셔닝의 장점과 유사하며, 하둡의 맵리듀스 작업 실행 시 전체 데이터세트를 조인하는 것이 아니라 개별 버킷끼리만 조인하고 이 조인을 병렬로 수행할 수 있기 때문에 비약적으로 성능을 향상시킬 수 있습니다.

버키팅의 또 다른 장점은 데이터세트의 크기가 작아지므로 이 버킷을 메모리에 올려 빠르게 처리하는 맵 사이드 조인을 사용할 수 있다는 점입니다.

⑥ 인덱싱(Indexing) 전략 수립

아파치 하이브 등에서는 RDBMS들의 인덱스와 유사한 역할을 하는 인덱스를 구성할 수 있습니다. 예를 들어 하이브는 컴팩트 인덱스와 비트맵 인덱스 등을 지원합니다. 인덱스 생성 시에는 실제 데이터세트를 사용할 사용자 쿼리 패턴을 분석하는 작업이 선행되어야 하며, 이에 따라 인덱스를 생성해야 합니다(RDBMS의 인덱싱 전략과 유사합니다).

인덱스를 사용하는 경우 통계 정보를 주기적으로 수집해서 옵티마이저가 최적의 경로를 찾을 수 있도록 구성해야 합니다.

⑦ 다른 물리 모델링 옵션들

데이터 웨어하우스 구축 시 룩업(lookup) 데이터세트는 HBase를 사용하는 것을 고려해 볼 수 있습니다. HBase의 테이블을 하이브의 익스터널(external) 테이블로 선언하여 하이브에서 조인해서 사용할 수 있습니다.

또한, 모델러는 하둡 에코시스템에서 사용할 수 있는 자원 관리자(얀 또는 메소스)의 역할에 대해 이해하고 있어야 하며, 사용자의 쿼리 패턴에 적합한 자원 관리자 옵션을 설정해야 합니다. 클러스터 내에서 자원의 할당과 회수 방식은 쿼리 성능에 영향을 미칠 수 있습니다.

자주 사용하는 데이터세트는 메모리에 저장하는 옵션(예를 들면 아파치 이그나이트)을 이용하여 메모리에 올려둘 수도 있습니다. 이 경우, 디스크의 자료에 접근하지 않아도 되므로 성능 향상을 기대할 수 있습니다.

결론

최근까지도 데이터 웨어하우스는 기업의 대용량 데이터 처리를 담당해 온 전통적이며 유일한 시스템이었습니다. 그러나, 하둡 에코시스템의 발전과 빅데이터의 필요성이 증가함에 따라 많은 기업들은 하둡을 활용하여 전통적인 데이터 웨어하우스의 한계를 보완하거나, 데이터 웨어하우스를 하둡 기반으로 전환하고 있습니다.

하둡 에코시스템 입장에서 보면 데이터 웨어하우스는 하나의 애플리케이션입니다. 이는 하둡 에코시스템으로 데이터 웨어하우스라는 애플리케이션을 구축하더라도, 데이터 웨어하우스가 가지고 있는 본질적 가치는 여전하다는 것입니다.

즉, 기업의 의사 결정을 지원하기 위해 분석 데이터를 빠른 속도로 유연하게 제공해야 한다는 데이터 웨어하우스의 가치 명제를 달성해야 한다는 뜻입니다. 다행히 하둡 기반으로 데이터 웨어하우스를 구축할 때에도 기존에 사용하던 데이터 웨어하우스 구축 방법론을 큰 변화 없이 사용할 수 있습니다.

다만 물리 설계 단계에서 하둡 에코시스템의 특성을 고려하여 설계함으로써, 구조화 데이터와 비구조화된 데이터를 결합하여 또 다른 중요한 목적이 될 빅데이터 시대를 대비할 수 있을 것입니다.

글 | LG CNS 빅데이터사업담당

[혁신의 시작, 빅데이터 활용 연재 현황]

• [1편] SRA와 함께라면 당신도 데이터 분석 전문가!
• [2편] 빅데이터로 실시간 장애감지 및 분석까지!
• [3편] 금융 정보계에 HIA 도입의 필요성
• [4-1편] 빅데이터를 친구로 만드는 첫 걸음, 바라보는 관점 바꾸기 ①
• [4-2편] 빅데이터를 친구로 만드는 첫 걸음, 바라보는 관점 바꾸기 ②
• [5편] 빅데이터 시대, 자연어 기반의 빠른 검색이 온다
• [6편] 하둡 기반 데이터 웨어하우스 모델링
• [7-1편] 빅데이터 시각화 분석 ①
• [7-2편] 빅데이터 시각화 분석 ②
• [8편] 소셜 빅데이터 분석을 통해 신(新)소비 트렌드를 읽다
• [9-1편] 고객 시선 강탈의 중요 요소 ‘빅데이터 추천 시스템’ ①
• [9-2편] 고객 시선 강탈의 중요 요소 ‘빅데이터 추천 시스템’ ②