Chapter 2. 빅데이터의 탐색

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

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

• 데이터 마트의 크기가 작을수록
  • 시각화는 간단
  • 원래 데이터에 포함된 정보를 읽어버리게 됨.
  • 시각화의 프로세스에서 할 수 있는것이 적어짐
• 데이터 마트 클수록
  • 데이터 마트가 거대해져 좋은 시각화를 하기 힘듦.
    데이터의 양을 수백만 건 정도까지 줄일 수 있다면 모든 데이터를 시각화 도구에 넣을 수 있기 때문에 특별한 시스템이 필요 없다. 이게 되지 않는다면 지연이 적은 데이터베이스를 사용하여 데이터 마트를 만들 수 있어야 한다.

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

메모리에 다 올라가지 않을 정도의 대용량 데이터를 신속하게 집계하려면 미리 데이터를 집계에 적합한 형태로 변환하는 것이 필요하다.

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

초 단위로 데이터를 집계하려면 처음부터 그것을 예상해서 시스템을 마련해야 한다. 데이터 수집 단계에서는 거기까지 생각하지 않기 때문에 주로 데이터 레이크 -> 데이터 마트 -> 시각화 도구 와 같이 3계층의 시스템을 만든다.
원 데이터는 용량적인 제약이 적어서 대량의 데이터를 처리할 수 있는 데이터 레이크와 데이터 웨어하우스에 저장한다. 거기에서 원하는 데이터를 추출하여 데이터 마트를 구축하고 여기에서는 항상 초 단위의 응답을 얻을 수 있도록 한다.

데이터 처리의 지연

일반적으로 데이터 처리의 응답이 빠르다는 표현을 대기 시간(latency)이 적다 또는 지연이 적다고 한다. 데이터 마트를 만들 때는 가급적 지연이 적은 데이터베이스가 있어야 한다. 두 가지 방법이 있다.

• 압축과 분산에 의해 지연 줄이기 - MPP 기술
  • 데이터를 가능한 한 작게 압축하고 그것을 여러 디스크에 분산함으로써 데이터의 로드에 따른 지연을 줄인다.
  • MPP(Massive Parallel processing) - 분산된 데이터를 멀티 코어를 활용하면서 디스크 I/O 병렬 처리 하는 것
    • 데이터의 집계에 최적화
    • 하나의 쿼리를 다수의 작은 태스크로 분해하고 이를 병렬로 실행
      • e.g) 1억 레코드로 이루어진 테이블의 합계를 계산하기 위해 10만 레코드로 구분하여 1000개의 태스크로 나누는 것
    • 각 태스크는 각각 독립적으로 10만 레코드의 합계를 집계해 마지막 모든 결과를 모아 총합계를 계산한다.
• 열 지향 데이터베이스 접근 - 컬럼을 압축하여 디스크 I/O 줄이기
  • 데이터 압축을 고려한 후에 알아두어야 할 것이 컬럼 지향 개념이다. 빅데이터로 취급되는 대부분의 데이터는 디스크상에 있기 때문에 쿼리에 필요한 최소한의 데이터만을 가져옴으로써 지연이 줄어들게 된다.

시각화 도구

• 대시보드 도구 or BI도구
  • 대시보드
    • 새로운 그래프를 쉽게 추가할 수 있는 것이 중요시 될 때
    • 최신의 집계 결과를 즉시 확인하길 바랄 때.
    • 정해진 지표의 일상적인 변화를 모니터링 하고 싶은 경우.
  • BI
    • 대화형 데이터 탐색이 중요시될 때
    • 그래프를 클릭하여 상세한 표시로 전환하거나 집계에 기반이 되는 로우 데이터를 표시하는 등 차분히 데이터를 보고 싶은 경우

대시보드 도구

• Redash - SQL에 의한 쿼리의 실행 결과를 그대로 시각화
  • 파이썬으로 만든 대시보드
  • SQL에 의한 쿼리의 실행 결과를 그대로 시각화하는데에 적합
  • 하나의 쿼리가 하나 또는 여러 그래프에 대응
  • 등록한 쿼리는 정기적으로 실행되어 결과가 Redash 자신의 데이터베이스에 저장됨.
• Superset - 화면상에서 마우스 조작만으로 그래프를 만들기
  • 대화형 대시보드
  • 쿼리를 입력하는게 아닌 마우스 조작으로 그래프를 만드는 것이 기본
  • 내장 스토리지 시스템을 갖고 있지 않아 집계는 Druid와 같은 외부 저장소에 의존하고 있다.
  • Druid는 집계 시에 테이블을 결합할 수 없기 때문에 시각화에 필요한 데이터는 미리 모두 결합해두어야 한다.
• Kibana - Elasticsearch의 프론트 엔드에서 실시간으로 작성
  • 자바스크립트로 만들어진 대화식 시각화 도구
  • 실시간 대시 보드를 만들 목적으로 자주 사용 됨
  • Elasticsearch 외의 데이터 소스에는 대응하고 있지 않아 시각화하려는 데이터는 모두 Elasticsearch에 저장해야 한다.
  • 검색 조건에 맞는 데이터를 빠르게 시각화하는 데에 적합한 도구이다.

BI도구

몇 개월 단위의 장기적인 데이터의 추이를 시각화하거나, 집계의 조건을 세부적으로 바꿀 수 있는 대시보드를 만들려면 BI도구를 사용하는 것이 적합하다. Tableau가 많이 사용된다.

데이터 마트의 기본 구조

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

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

• OLAP(Online Analytical Processing)

• 다차원 모델과 OLAP큐브

  • OLAP은 데이터 집계를 효율화하는 접근 방법 중의 하나이다.
  • 다차원 모델의 구조를 MDX(Multidimensinal Expressions) 등의 쿼리 언어로 집계한다.
  • 데이터 분석을 위해 만들어진 다차원 데이터를 OLAP 큐브라고 부르며, 그것을 크로스 집계하는 구조가 OLAP이다.

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

  • 최근 MPP데이터베이스와 인메모리 데이터베이스 등의 보급으로 사전에 계산해 둘 필요가 없어졌다. 따라서, BI도구와 MPP데이터베이스를 조합하여 크로스 집계하는 경우가 증가하고 있다.
  • BI도구로 생각한 대로의 그래프를 만들기 위해서는 비정규화 테이블을 준비한다.
  • 시각화에 적합한 데이터 마트를 만드는 것은 BI도구를 위한 비정규화 테이블을 만드는 프로세스이다.

테이블 비정규화하기

• 팩트 테이블과 디멘전 테이블
  • 팩트 테이블 - 트랜잭션처럼 사실이 기록된 것
  • 디멘전 테이블 - 팩트 테이블에 참고되는 마스터 데이터
  • e.g) 집계의 기반이 되는 숫자 데이터는 팩트 테이블, 데이터를 분류하기 위한 속성값은 디멘전 테이블
• 스타 스키마와 비정규화
  • 데이터 마트를 마들 때에는 팩트 테이블을 중심으로 여러 디멘전 테이블을 결합하는 것이 좋다. 그림으로 그리면 별 모양이 되므로, 이를 스타 스키마라고 한다.
    • 스타 스키마 사용 이유
      • 단순하기 때문에 이해하기 쉬우며 데이터 분석을 쉽게 할 수 있다.
      • 성능
        • 팩트 테이블의 부하를 방지하기 위해 팩트 테이블을 될 수 있는 한 작게 하는 것이 고속화에 있어서 중요하다.
        • 팩트 테이블에는 ID와 같은 키만 남겨놓고 그 외의 나머지는 디멘전 테이블로 옮긴다.
  • 디멘전 테이블을 작성하려면 분해된 테이블을 최대한 결합하여 하나의 테이블로 정리한다. 데이터가 중복되어도 괜찮다. 정규화의 반대 작업이기 때문에 비 정규화라고 한다.
• 비정규화 테이블 - 데이터 마트에 정규화는 필요 없다.
  • 컬럼 지향 스토리지는 컬럼 단위로 데이터가 저장되므로 컬럼의 수가 아무리 늘어나도 성능에 영향을 주지 않는다.
  • 따라서, 처음부터 팩트 테이블에 모든 컬럼을 포함해두고, 쿼리의 실행 시에는 테이블 결합을 하지 않는 편이 간단하다.
  • 컬럼 단위로의 데이터 압축이 있기 때문에 하나의 거대한 팩트 테이블만 있으면 디멘전 테이블을 만들 필요가 없다.
• 참고) 데이터 웨어하우스의 테이블 구조로는 스타 스키마가 우수하다.
  • 데이터 축적 단계에서는 팩트 테이블과 디멘전 테이블로 분리해두고 분석 단계 후에 결합해 비정규화 테이블을 만든다.