빅데이터를 지탱하는 기술 Ch2 - 빅데이터의 탐색

크로스 집계의 기본

크로스 집계의 개념: 트랜잭션 테이블, 크로스 테이블, 피벗 테이블

• 크로스 테이블: 엑셀에서 많이 보는 형태로 행 방향과 열 방향의 데이터가 교차하는 부분에 숫자 데이터가 들어간다.
• 트랜잭션 테이블: 데이터베이스를 생각하면 되는데, 행 방향으로 증가하는 테이블이다.
• 크로스 집계: 트랜잭션 테이블에서 크로스 데이블로 변환하는 과정.
• 피벗 테이블: 소량의 데이터를 크로스 집계하는데 편리한 것이 스프레드시트의 피벗 테이블 기능이다.
• 룩업 테이블: 트랜잭션 테이블에 새로운 항목을 추가하는 것이 아니라, 다른 테이블과 결합할 수도 있다. 예를 들면 상품 ID를 사용하여 상품명과 상품 카테고리를 참고하는 형태이다.

트랜잭션 테이블과 룩업 테이블은 서로 독립적으로 관리할 수 있다. 트랜잭션 테이블은 데이터베이스에서 가져오기 때문에 변경할 수 없지만 룩업 테이블은 분석 용도에 따라 변경할 수 있다.

BI, Pandas에 의한 크로스 집계

크로스 집계는 BI 도구와 Pandas로 할 수 있다. 자주 데이터를 살펴볼 때는 BI 도구를 사용하는 것이 좋다.

만약 스크립트로 크로스 집계를 실행하고 싶다면 pandas를 이용하는 것이 편리하다.

SQL에 의한 테이블 집계

BI 도구와 pandas를 이용한 피벗 테이블 크로스 집계는 간편하긴 하지만 데이터가 많아지면 너무 느려져서 쓸 수가 없다. 대량의 데이터를 크로스 집계하려면 SQL을 사용하여 집계 함수를 이용해 데이터양 감소를 고려할 필요가 있다.

데이터를 집계하는 데 뛰어난 SQL과 크로스 집계에 뛰어난 시각화 도구를 결합함으로써 많은 양의 데이터가 있어도 크로스 집계가 가능하다.

데이터 집계 -> 데이터 마트 -> 시각화

데이터 집계와 시각화 사이에 있는 것이 데이터 마트이다. 데이터 마트가 작으면 시각화하는 것은 간단하지만, 동시에 원래 데이터에 포함된 정보를 잃어버리게 되어 시각화 프로세스에서 할 수 있는 것이 적어진다.

 

반대로 너무 많은 정보가 있다면 좋은 시각화를 할 수 없게 될 우려가 있다. 이것은 크기와 정보 간의 트레이드 오프 관계에 있으며, 필요에 따라 어느 정도의 정보를 남길 것인가를 결정해야 한다. 최종적으로는 "데이터 마트의 크기"에 따라 시스템 구성이 결정된다.

열 지향 스토리에 의한 고속화

데이터베이스의 지연을 줄이기

초 단위로 응답을 얻기 위해서 대량의 데이터를 처리할 수 있는 데이터 레이크와 데이터 웨어하우스에 원 데이터를 저장하고, 거기에서 원하는 데이터를 추출하여 데이터 마트를 구축한다.

① 모든 데이터 메모리에 올리기

데이터 마트를 만들 때는 가급적 지연이 적은 데이터베이스가 있어야 하는데, 가장 간단한 방법은 모든 데이터를 메모리에 올리는 것이다. 데이터가 메모리 용량 정도라면 MySQL이나 PostgreSQL 같은 일반적인 RDB가 데이터 마트에 적합하다. 하지만 RDB는 메모리가 부족하면 급격히 성능이 나빠진다.

② MPP 기술: 압축과 분산에 의해 지연 줄이기

고속화를 위해 압축과 분산을 사용하게 된다.

분산된 데이터를 읽어들이려면 멀티 코어를 활용하면서 디스크 I/O를 병렬 처리하는 것이 효과적이다. 이러한 아키텍처를 MPP(Massive Parallel Processing: 대규모 병렬 처리)라고 부르며, 여기에는 Amazon Redshift 및 구글 BigQuery 등이 있다. MPP는 데이터의 집계에 최적화되어 있으며, 데이터 웨어하우스와 데이터 분석용 데이터베이스에 많이 사용되고 있다. 요새는 클라우드의 도입으로 문턱이 많이 낮아졌다.

 

※ 데이터 웨어하우스의 성능이 날이 갈수록 발전하면서 데이터 마트의 필요성이 점차 사라지고 있는 추세이다.

열 지향 데이터베이스 접근

일반적으로 업무 시스템에서 사용하는 데이터베이스는 행 지향 데이터베이스이다. 우리가 흔히 아는 RDB가 여기에 해당한다.

하지만 데이터 분석에 사용되는 데이터베이스는 열 지향 데이터베이스이다. 아까의 MPP가 여기에 해당한다.

행 지향 데이터베이스

행 지향 데이터베이스에서는 테이블의 각 행을 하나의 덩어리로 디스크에 저장한다. 끝부분에만 데이터를 붙이면 되므로 데이터를 빠르게 추가할 수 있다.

 

여기서는 검색을 고속화하기 위해 인덱스를 만든다. 하지만 데이터 분석은 어떤 칼럼이 사용되는지 미리 알 수 없기 때문에 인덱스를 작성했다 해도 도움이 되지 않는다. 따라서 인덱스에 의지하지 않는 고속화 기술이 필요하다.

열 지향 데이터베이스

열 지향 데이터베이스에서는 데이터를 미리 컬럼 단위로 정리해 둠으로써 필요한 칼럼만을 로드하여 디스크 I/O를 줄인다.

 

열 지향 데이터베이스는 압축 효율 또한 우수한데, 같은 칼럼에는 종종 유사한 데이터가 나열되기 때문에 매우 작게 압축이 가능하다.

 

※ 열 지향 데이터베이스와 MPP 데이터베이스 차이

열 지향 데이터베이스는 MPP 데이터베이스를 포함하고 있다. MPP 데이터베이스는 하나의 쿼리를 여러개의 프로세스로 병렬처리하는 데이터베이스이다. 그렇기에 MPP 데이터베이스는 기본적으로 열지향 데이터베이스로 설계되어있다. 그 이유는 대용량 데이터를 집계할 때 컬럼들이 여러 Disk에 저장되어있어야 많은 프로세스들이 개별 Disk에 접근하여 데이터를 처리할 수 있기 때문이다. 

MPP 데이터베이스의 접근 방식

행 지향 데이터베이스에서는 보통 하나의 쿼리는 하나의 스레드에서 실행된다. 각 쿼리는 짧은 시간에 끝나는 것으로 생각하기 때문에, 하나의 쿼리를 분산 처리하는 상황은 가정하지 않는다.

 

하지만 열 지향 데이터베이스에서는 대량의 데이터를 읽기 때문에 1번의 쿼리 실행 시간이 길어진다. CPU 리소스를 필요로 하므로 멀티 코어를 활용하여 고속화하는 것이 좋다.

 

MPP에서는 하나의 쿼리를 다수의 작은 태스크로 분해하고 이를 병렬로 실행한다. 예를 들어 1억 개의 레코드의 합계라면 이를 10만개로 구분하여 1000개의 태스크로 구분하고 각각 집계하여 마지막에 합치는 것이다.

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

MPP는 구조상, 고속화를 위해 CPU와 디스크 모두를 균형있게 늘려야 한다. 따라서 일부 제품은 하드웨어와 소프트웨어가 통합된 제품으로 제공된다. 이처럼 하드웨어 수준에서 데이터 집계에 최적화된 데이터베이스를 MPP 데이터베이스라고 한다.

 

MPP 아키텍처는 대화형 쿼리 엔진으로도 채택되고 있다. 이때 데이터를 저장하는 것은 분산 스토리지이다. 여기에는 Hive, Presto 같은 것들이 있다.

 

둘 중 어느 쪽을 선택할 지는 때에 따라 다르다. 안전성과 서포트 체제 측면에서는 MPP 데이터베이스, 하둡과의 궁합은 대화형 쿼리 엔진 쪽이 탁월하다.

 

결론적으로 빠른 데이터 마트를 위해 아래의 3가지 기술을 활용할 수 있다.

 

- 행 지향 데이터베이스: RDB

- 열 지향 데이터베이스이며, 하드웨어 일체형: MPP 데이터베이스

- 열 지향 데이터베이스이며, 분산 스토리지에 보관: 대화형 쿼리 엔진

애드 훅 분석과 시각화 도구

주피터 노트북으로 애드 혹 분석

어떤 데이터 분석이라도 처음에는 애드 혹 분석부터 시작한다. 여기에는 대화형 도구로 인기가 있는 주피터 노트북이 가장 유명하다. 주티퍼 노트북의 matplotlib을 활용하여 시각화를 할 수도 있고, Run All을 통해 간이적인 워크플로 실행도 할 수 있다.

애드 혹 분석과 정기적인 데이터 처리 자동화에는 필요한 지식도 도구도 전혀 다르다. 자동화가 필수적이지 않은 이상 노트북을 중심으로 하는 애드 혹 분석 환경을 갖추는 것이 우선이다.

대시보드 도구

정기적으로 쿼리를 실행해 보고서를 작성하거나 주요 그래프를 모아 대시보드를 작성한다면 BI 도구를 사용할 수 있다. 하지만 대시보드만 만드는 것이 목적이라면 그에 특화된 도구를 사용한다.

 

대시보드 도구와 BI 도구는 그렇게 다르지 않다. 전자는 새로운 그래프 추가처럼 최신의 집계 결과가 중점이 된다면, 후자는 대화형 데이터 탐색과 같이 차분히 데이터를 보고 싶을 때 적합하다.

 

Redash

Redash는 SQL에 의한 쿼리의 실행 결과를 그대로 시각화하는 데에 적합하다. 

데이터 소스 등록 -> 쿼리 실행 후 표와 그래프 생성 -> 그래프 대시보드에 추가와 같은 단계로 구성되고, 등록한 쿼리는 정기적으로 실행되어 Redash 자신의 데이터베이스에 저장된다.

 

Superset

Superset은 대화형 대시보드를 작성하기 위한 도구로 BI 도구와 비슷하다. Redash처럼 쿼리를 수동으로 입력하는 것이 아니라 마우스로 조작한다. Redash와 달리 대화형 시각화를 가정하기 때문에 데이터 소스에 의한 집계를 몇 초 내에 완료할 것으로 판단된다. 그리고 내장 스토리지를 가지고 있지 않으므로 Druid와 같은 열 지향 스토리지에 의존하고 있다. BI 도구와 마찬가지로 데이터 마트를 통해 필요한 데이터를 미리 결합해두어야 한다.

 

Kibana

Kibana는 실시간 대시보드를 만들 목적으로 자주 이용된다. Elasticsearch의 프론트 엔드로 개발되었기 때문에 Elasticsearch가 필수이다. 시각화하려는 데이터는 모두 Elasticsearch에 저장해야 한다.

BI 도구: 대화적인 대시보드

몇 개월 단위의 장기적인 데이터의 추이를 시각화하거나, 집계 조건을 세부적으로 바꿀 수 있는 대시보드를 만들려면, BI 도구를 사용하는 것이 적합하다. 여기서는 시각화에 적합한 데이터 마트를 만들어 읽고 쓰는 것을 전제로 한다.

 

바탕이 되는 데이터를 모두 포함하는 하나의 테이블을 작성하고 거기에서 다수의 대시보드를 만든다. 그리고 알고 싶은 것이 늘어날 때마다 데이터 마트에 테이블을 만들고 거기에서 파생된 다수의 대시보드가 생겨나는 것이 BI 도구의 시각화 과정이다.

데이터 마트의 기본구조

OLAP: 시각화에 적합한 데이터 마트 만들기

다차원 모델과 OLAP 큐브

데이터 마트를 구축하는데 OLAP(Online Analytical Processing) 개념은 매우 중요하다. 이는 데이터 집계를 효율화하는 접근 방법 중 하나이다. 일반적으로 RDB는 SQL로 집계한다.

 

한편, OLAP에서는 다차원 모델의 데이터 구조를 MDX 등의 쿼리 언어로 집계한다. 데이터 분석을 위해 만들어진 다차원 데이터를 OLAP 큐브라고 부르며 그것을 크로스 집계하는 구조가 OLAP이다.

MPP 데이터베이스와 비정규화 테이블

예전에는 OLAP를 고속화하기 위해서 크로스 집계에 대한 모든 경우의 수를 미리 계산해 두는 등 여러 아이디어가 있었다. 하지만 최근에는 MPP 데이터베이스와 인 메모리 데이터베이스 등의 보급으로 사전에 계산할 필요가 없어졌다. 따라서 OLAP 큐브를 위해 특별할 구조를 준비하는 것이 아니라, BI 도구와 MPP 데이터베이스를 조합하여 크로스 집계하는 경우가 증가하고 있다.

 

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

테이블을 비정규화하기

데이터베이스의 설계에서는 테이블을 마스터와 트랜잭션으로 구분한다.

 

트랜잭션: 시간과 함께 생성되는 데이터를 기록하는 것

마스터: 트랜잭션에서 참고되는 각종 정보.

 

트랜잭션은 한 번 기록되면 변화하지 않지만, 마스터는 상황에 따라 다시 쓰인다.

팩트 테이블과 디멘전 테이블

데이터 웨어하우스에서는 트랜잭션처럼 사실이 기록된 것을 팩트 테이블, 거기에서 참고되는 마스터 데이터 등을 디멘전 테이블이라고 한다.

스타 스키마와 비정규화

데이터 마트를 만들 때는 팩트 테이블을 중심으로 여러 디멘션 테이블을 결합하는 것이 좋다. 이를 스타 스키마라고 부른다. 디멘전 테이블을 작성하려면 정규화에 의해 분해된 테이블을 최대한 결합하여 하나의 테이블로 정리한다. 이를 비정규화라고 한다.

 

데이터 마트에서 스타 스키마가 사용되는 이유는 두 가지가 있다. 하나는 단순하기 때문에 이해하기 쉽고, 데이터 분석을 쉽게 할 수 있다는 점이다. 또 하나는 성능상의 이유이다. 데이터양이 증가하면 팩트 테이블은 디멘전 테이블보다도 훨씬 커져 그 데이터양이 집계시간을 좌우한다. 따라서 팩트 테이블을 될 수 있는 한 작게 하는 것이 고속화에 있어서 중요하며, 팩트 테이블에는 ID와 같은 키만을 남겨두고, 나머지는 디멘전 테이블로 옮긴다.

 

다음의 링크가 데이터 웨어하우스에서 팩트 테이블과 디멘젼 테이블에 대해 잘 설명해주고 있다.

비정규화 테이블

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

※ 데이터 마트가 아니라 데이터 웨어하우스의 테이블 구조로는 스타 스키마가 우수하다. 데이터를 축적하는 단계에서는 팩트 테이블과 디멘젼 테이블로 분리해두고 데이터 마트를 만들 때 비정규화 테이블을 만든다.

다차원 모델 시각화에 대비하여 테이블을 추상화하기

비정규화 테이블을 준비했다면 그것을 다차원 모델에 의해 추상화한다. 다차원 모델이란 BI 도구의 기본이 되는 데이터 모델로 테이블 및 칼럼의 집합을 알기 쉽게 정리해 이름을 붙인 것이다.

다차원 모델에서 디멘젼은 크로스 집계에 있어서의 행과 열, 측정값은 숫자 데이터와 그 집계 방법을 정의하는 것이다.

모델의 정의 확장

BI 도구를 이용한 데이터의 시각화는 일반적으로 다음과 같은 절차를 밟는다.

 

• 시각화하고 싶은 측정값 및 디멘젼 결정
• 데이터 마트에 비정규화 테이블을 만들고 그것을 BI 도구로 시각화한다.
• 다차원 모델의 정의는 나중에 확장될 수 있다. 데이터 분석의 요구에 따라 비정규화 테이블에는 다수의 칼럼이 추가되고 거기에서 다스의 그래프가 생성된다.

이렇게 만들어진 비정규화 테이블을 모은 것이 데이터 마트다. 일단 그래프를 만들면 나머지는 비정규화 테이블을 업데이트하는 것만으로 그것을 참고하는 모든 그래프가 업데이트된다. 워크플로 등을 이용해서 데이터 마트를 정기적으로 자동 업데이트함으로써 일상적인 데이터의 움직임을 확인할 수 있다.