[빅데이터를 지탱하는 기술] 2.빅데이터의 탐색

빅데이터를 탐색하기 위한 기초 지식인 시각화에 대한 내용이다.

데이터 집계 → 데이터 마트 → 시각화

데이터 집계와 시각화 사이에 있는 것이 데이터 마트이다.

시스템 구성은 데이터 마트의 크기에 따라 결정된다.

데이터 마트가 작을수록 시각화하는 것이 간단하지만 원래 데이터에 포함된 정보를 잃어버리게 되어 시각화 프로세스에서 할 수 있는 것이 적어지고, 데이터 마트가 거대화된다면 좋은 시각화를 할 수 없는 트레이드 오프 관계에 있다.

 

 

3계층의 데이터 집계 시스템

원 데이터는 용량적인 제약이 적어서 대량의 데이터를 처리할 수 있는 데이터 레이크와 데이터 웨어하우스에 저장한다.

그리고서 원하는 데이터를 추출해 데이터 마트를 구축하고 초 단위의 응답을 얻을 수 있도록 한다.

 

데이터 마트에 사용되는 기술

데이터 마트를 만들 때는 가급적 지연이 적은 데이터 베이스가 있어야 한다.

수 천만 개까지의 레코드의 양이라면 일반적인 RDB가 데이터 마트에 적합하다. RDB는 지연이 적고 많은 수의 클라이언트가 동시 접속해도 성능이 나빠지지 않는다. 한편 메모리가 부족하다면 급격히 성능이 저하된다는 단점이 있다.

 

지연을 줄이기 위한 방법으로 데이터를 압축하고 여러 디스크에 분산한다.

분산된 데이터를 읽기 위해 멀티 코어를 활용하면서 디스크 I/O를 병렬 처리하는 아키텍쳐를 MPP(massive parallel processing: 대규모 병럴처리)라고 한다. ex) Amazon Redshift, Google BigQuery

 

빅데이터 대부분은 디스크 상에 있기 때문에 쿼리에 필요한 최소한의 데이터만을 가져옴으로써 지연을 줄어들게 한다.

이를 위해 사용되는 것이 Column 단위로 데이터를 압축하는 '열 지향 데이터베이스'이다.

데이터를 미리 Column 단위로 정리해둠으로써 필요한 칼럼만 로드하여 디스크 I/O를 줄인다.

또한 같은 Column에는 유사한 데이터가 나열되기 때문에 매우 작게 압축할 수 있다.

ex) Teradata, Amazon Redshift

(일반적인 업무 시스템에 사용되는 데이터베이스는 행 단위로 읽고 쓰는 '행 지향 데이터 베이스'이다. ex) 일반적인 RDB)

 

지연을 줄이는 또 다른 방법은 MPP 아키텍쳐에 의한 데이터 처리의 병렬화이다.

행 지향 데이터베이스에서는 각 쿼리는 충분히 짧은 시간에 끝나는 것으로 생각하므로 하나의 쿼리를 분산 처리하는 상황은 가정하지 않는다.

열 지향 데이터베이스는 디스크에서 대량의 데이터를 읽기 때문에 쿼리 실행 시간이 길어지고 압축된 데이터의 전개로 인해 CPU 리소스가 필여하므로 멀티 코어를 활용하는 것이 좋다.

MPP는 하나의 쿼리를 다수의 작은 태스크로 분할하고 이를 병렬로 실행한다.

 

 

MPP 데이터 베이스와 대화형 쿼리 엔진

MPP 데이터베이스는 하드웨어 수준에서 데이터 집계에 최적화된 데이터베이스를 의미한다.

대화형 쿼리 엔진은 Hadoop과 함께 사용되는 MPP 아키텍쳐이다.

시스템의 안정성과 서포트 체제 등의 측면에서는 MPP 데이터베이스가 뛰어나고

Hadoop과의 궁합을 고려하면 편리성은 대화형 쿼리 엔진 쪽이 뛰어나다.

MPP 데이터 베이스와 대화형 쿼리 엔진 어느쪽을 사용하더라도 어쨌든, 수 억 레코드를 초과하는 데이터 마트의 지연을 작게 유지하기 위해서는 데이터의 열 지향 스토리지 형식으로 저장해야한다.

 

데이터 마트의 기본 구조

시각화에 적합한 데이터 마트 생성

BI 도구에서 대화형으로 데이터를 참고하려면 시각화에 필요한 정보만을 모은 데이터 마트가 필수적이다. 

데이터 마트를 구축하는데 OLAP(Online Analytical Processing) 개념이 중요하다.

OLAP는 데이터 집계를 효율화하는 접근 방법 중 하나이다. RDB는 SQL로 집계하지만, OLAP에서는 다차원 모델의 데이터 구조를 MDX 등의 쿼리 언어로 집계한다.

데이터 분석을 위해 만들어진 다차원 데이터를 OLAP 큐브라고 부르며 그것을 크로스 집계하는 구조가 OLAP이다.

 

이전에는 OLAP를 고속화하기 위해서 크로스 집계에 대한 모든 경우의 수를 미리 계산해 두는 등의 방법이 있었지만 최근에는 MPP 데이터베이스와 인 메모리 데이터베이스 등의 보급으로 사전에 계산할 필요가 없어졌다.

따라서 OLAP 큐브를 위해 특별할 구조를 준비하는 것이 아니라, BI 도구와 MPP 데이터베이스를 조합하여 크로스 집계하는 경우가 증가하고 있다.

MPP 데이터베이스에 다차원 모델의 개념은 없기 때문에 이를 대신해 비정규화 테이블을 준비해야 한다. 그렇게 만든 비정규화 테이블을 BI 도구에서 열어서 기존의 OLAP와 동등한 시각화를 실현할 수 있다.

 

비정규화 테이블

데이터 마트를 작성할 때는 트랜잭션처럼 사실이 기록된 팩트 테이블에 마스터 데이터 등의 디멘션 테이블을 모두 결합한 비정규화 테이블을 만든다.

데이터베이스 설계에서는 종종 테이블을 '마스터'와 '트랜잭션'으로 구분한다.
transaction: 시간과 함께 생성되는 데이터를 기록한 것, 한 번 기록하면 변화하지 않음
master: 트랜잭션에서 참고되는 각 종 정보, 상황에 따라 다시 쓰일 수 있음

fact table: 데이터 웨어하우스에서는 트랜잭션처럼 사실이 기록된 것을 의미
dimension table: 데이터 웨어하우스에서는 팩트 테이블에서 참고되는 마스터 데이터를 의미

테이블이 메모리에 실을 정도로 작으면 RDB를 데이터마트로 사용하지만

그렇지 않다면 MPP 데이터베이스 등과 같이 열 지향로 데이터가 보관되도록 하는 것이 좋다.

 

스타 스키마와 비정규화

데이터 마트를 만들 때는 팩트 테이블을 중심으로 여러 디멘션 테이블을 결합하는 스타 스키마 형태가 좋다.

디멘전 테이블을 작성하려면 정규화에 의해 분해된 테이블을 최대한 결합하여 하나의 테이블로 정리한다. 이 작업을 비정규화라고 한다.

데이터 마트에서 스타 스키마가 사용되는 이유는 두 가지가 있다.

하나는 단순하기 때문에 이해하기 쉽고, 데이터 분석을 쉽게 할 수 있다는 점이다.

다른 이유는 성능상의 이유이다. 데이터양이 증가하면 팩트 테이블은 디멘전 테이블보다도 훨씬 커져 그 데이터양이 집계시간을 좌우한다. 따라서 팩트 테이블을 될 수 있는 한 작게 하는 것이 고속화에 있어서 중요하며, 팩트 테이블에는 ID와 같은 키만을 남겨두고, 나머지는 디멘전 테이블로 옮긴다.

 

위의 내용은 MPP 데이터베이스가 보급됨에 따라 사정이 바뀌었다.
열 지향 스토리지는 칼럼 단위로 데이터가 저장되므로 칼럼의 수가 아무리 늘어도 성능에 지장을 주지 않는다.
따라서 처음부터 팩트 테이블에 모든 칼럼을 포함해두고, 쿼리 실행 시에는 테이블 결합을 하지 않는 편이 간단하다. 하나의 거대한 팩트 테이블만 있으면 충분하다.

데이터 마트에 스타 스키마가 사용된 것은 과거의 이야기이며, 성능상의 문제는 열 지향 스토리지에 의해 해결된다.
데이터 마트는 비정규화 테이블로 하는 것이 가장 단순하며 효율적인 방법이다.

비정규화 테이블: 스타 스키마에서 좀 더 비정규화를 진행해 모든 테이블을 결합한 팩트 테이블