2.1 크로스 집계의 기본

---

2.1.1 트랜잭션 테이블, 크로스 테이블, 피벗 테이블

크로스 집계의 개념

크로스 테이블

• 행과 열이 교차하는 부분에 숫자 데이터가 들어간 테이블
• 사람이 다루기 쉽지만, 데이터베이스는 다루기 어려움
  • 새로운 행은 늘리기 쉽지만, 열은 늘리기 어려움

트랜잭션 테이블

• 행 방향으로만 증가하고, 열 방향으로는 증가하지 않는 테이블

크로스 집계

• 트랜잭션 테이블에서 크로스 테이블로 변환하는 과정
• 스프레드시트의 피벗 테이블 기능으로 집계 편리하게 가능
  
  

2.1.2 룩업 테이블

테이블을 결합하여 속성 늘리기

2.1.3 SQL에 의한 테이블의 집계

• 대량의 데이터를 크로스 집계하려면 SQL을 사용하여 데이터 집계(aggregation), 즉 sum()과 같은 집계 함수(aggregation function)을 이용해 데이터양 감소를 고려할 필요가 있다.
• SQL의 실행 결과는 크로스 테이블이 아닌 트랜잭션 테이블의 형태로 되어 있다. 따라서, 이를 크로스 집계함으로써 임의의 크로스 테이블을 얻을 수 있다.
• 데이터를 집계하는 데 뛰어난 SQL + 크로스 집계에 뛰어난 시각화 도구 → 이론상 무한히 많은 데이터 크로스 집계 가능
  
  

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

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

• 데이터마트의 크기 DOWN → 시각화 간단 but 정보 잃어버리게 되어 시각화 프로세스에서 할 수 있는 것이 적어짐
• 데이터마트의 크기 UP → 시각화가 어려워짐 TRADEOFF
  

2.2 열 지향 스토리지

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

• 데이터양이 증가함에 따라 집계에 걸리는 시간이 길어짐
• 초 단위로 집계하려면 처음부터 그것을 예상해서 시스템을 마련해야 함
• 데이터 레이크에서 데이터 마트로의 집계가 수 시간이 걸리더라도, 데이터 마트에서는 항상 수 초 단위의 응답을 얻을 수 있도록 해야 함.

데이터 처리의 지연

지연이 적은 데이터 마트 작성을 위한 기초 지식

• 제이터 처리의 응답이 빠르다 → 대기 시간(latency)이 적다
• 모든 데이터를 메모리에 올리는 것
  • 5GB정도의 데이터양이라면 MySQL등의 일반적인 RDB가 데이터 마트에 적합함
  • RDB는 원래 지연이 적고, 많은 수의 클라이언트가 동시 접속해도 성능이 나빠지지 않으므로 많은 사용자가 사용하는 실제 운영환경의 데이터 마트로 특히 우수함
  • 메모리가 부족하면 성능히 저하됨. 수억 레코드를 초과하는 데이터 집계에서는 항상 디바이스 I/O가 발생한다고 가정하고 그것을 어떻게 효율화할 것인지가 중요한 열쇠임.

‘압축’과 ‘분산’

MPP 기술

• 고속화를 위해 사용되는 기법이 ‘압축’과 ‘분산’임
  • 데이터를 가능한 한 작게 압축하고, 그것을 여러 데이터에 분산함으로써 데이터의 로드에 따른 지연을 줄임
• 분산된 데이터를 읽어들이려면 멀티 코어를 활용하면서 디스크 I/O 를 병렬 처리하는 것이 효과적 → MPP(Massive Parallel Processing: 대규모 병렬 처리)
• Amazon Redshift, Google Bigquery
• MPP는 데이터 집계에 최적화되어 있으며, 데이터 웨어하우스와 데이터 분석용의 데이터베이스에서 많이 사용됨

열 지향 데이터베이스의 접근

컬럼을 압축하여 디스크 I/O를 줄이기

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

행 지향 데이터베이스

• 각 생이 디스크 상에 일련의 데이터로 기록됨
• Oracle, MySQL등 일반적인 RDB
• 새 레코드를 추가할 때 파일의 끝에 데이터를 쓸 뿐임으로 빠르게 추가 가능
• 매일 발생하는 대량의 트랜잭션을 지연 없이 차리하기 위해 데이터 추가를 효율적으로 할 수 있도록 해줌
• 데이터 검색을 고속화하기 위해 인덱스(index)를 만듦
  • 적절한 인덱스가 사용되도록 튜닝하는 것이 중요함
• 데이터 분석에서는 어떤 칼럼이 사용되는지 미리 알 수 없기 떄문에 도움이 되지 않음
• 대량의 데이터 분석은 항상 디스크 I/O를 동반하고, 따라서 인덱스에 의지하지 않는 고속화 기술이 필요함

열 지향 데이터베이스

• 데이터를 미리 칼럼 단위로 정리해 둠으로써 필요한 칼럼만을 로드하여 디스크 I/O를 줄임
• 데이터의 압축 효율도 우수함.(같은 칼럼에는 유사한 데이터가 나열되므로)
• 행 지향 데이터베이스와 비교하면 1/10 이하로 압축 가능
  
  

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

• MPP 아키텍처에 의한 데이터 처리의 병렬화로 쿼리 지연을 줄일 수 있음

행 지향 데이터베이스

• 하나의 쿼리는 하나의 스레드에서 실행됨.
• 각 쿼리는 충분히 짧은 시간에 끝나는 것으로 생각되므로, 하나의 쿼리를 분산 처리하는 상황은 가정하지 않음

열 지향 데이터베이스

• 디스크에서 대량의 데이터를 읽기 떄문에 1번의 쿼리 실행 시간이 길어짐
• 압축된 데이터의 전개 등으로 CPU 리소스를 필요로 하므로 멀티 코어를 활용하여 고속화하는 것이 좋음
• MPP에서는 하나의 쿼리를 다주의 작은 태스크로 분해하고 이를 가능한 한 병렬로 실행

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

• 쿼리가 잘 병렬화 할 수 있다면, MPP를 사용한 데이터의 집계는 CPU 코어 수에 비례하여 고속화됨

• MPP는 구조상, 고속화를 위해 CPU와 디스크 모두를 균형 있게 늘려야 함.

• 하드웨어 수준에서 데이터 집계에 최적화된 데이터베이스 → MPP 데이터베이스

• MPP 아키텍처는 Hadoop과 함께 사용도는 대화형 쿼리 엔진으로도 채택되고 있음

• 데이터를 저장하는 것은 분산 스토리지의 역할이지만, 열 지향으로 압축하지 않으면 MPP 데이터베이스와 동일한 성능이 되지 못함. 따라서, Hadoop 상에서 열 지향 스토리지를 만들기 위해 여러 라이브러리가 개발되고 있음

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

집계 시스템 종류	스토리지의 종류	최적의 레코드 수
RDB	행 지향	~수천만 정도
MPP 데이터베이스	열 지향(하드웨어 일체형)	수억 ~
대화형 쿼리 엔진	열 지향(분산 스토리지에 보관)	수억 ~

2.3 애드 혹 분석과 시각화 도구

2.3.1 Jupyter Notebook

2.3.2 대쉬보드

• 정기적으로 쿼리를 실행해 보고서를 작성하거나 주요 그래프를 모아서 대시보드를 작성하는 것

Redash

SQL에 의한 쿼리의 실행 결과를 그대로 시각화

• 대시보드의 작성 단계
  1. 데이터 소스를 등록
  2. 쿼리를 실행해서 표와 그래프를 만듦
  3. 그래프를 대시보드에 추가
     
     
     
     

2.4 데이터 마트의 기본 구조

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

• OLAP(Online Analytic processing): BI 도구에 있어서 핵심적인 개념.

다차원 모델과 OLAP 큐브

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

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

• 최근에는 OLAP 큐브를 위해 특별한 구조를 준비하는 것이 아니라, BI 도구와 MPP 데이터베이스를 조합하여 크로스 집계하는 경우가 증가하고 있음

• BI 도구로 생각한 대로의 그래프를 만들기 위해서는 이미 존재하는 테이블을 그대로 시각화하려고 하는 것이 아니라, 만들고 싶은 ㄷ그래프에 맞추어 ‘다차원 모델’을 설계함

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

• 시각화에 적합한 데이터 마트를 만드는 것 → BI 도구를 위한 비정규화 테이블을 만드는 프로세스
  
  

2.4.2 테이블 비정규화하기

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

• 트랜잭션(transaction): 시간과 함께 생성되는 데이터를 기록한 것

  • 한 번 기록하면 변화하지 않음

• 마스터(master): 트랜잭션에 참고되는 각종 정보

  • 상황에 따라 다시 쓰이기도 함

• 데이터 분석의 경우, 정규화된 관계형 모델에서 출발해서 그와는 반대의 작업을 실행함

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

• 팩트 테이블(fact table): 트랜잭션, 숫자 데이터(팬매액)처럼 사실이 기록된 것
• 디멘션 테이블(dimension table): 팩트 테이블에 참고되는 데이터를 분류하기 위한 속성값, 마스터 데이터 등.

스타 스키마와 비정규화

팩트 데이터를 중심으로 여러 디멘션 테이블을 결합

• 데이터 마트를 만들 떄는 팩트 테이블을 중심으로 여러 디멘션 테이블을 결합하는 것이 좋음. 이를 스타 스키마(star schema)라고 부름

  • 이용하는 이유
    1. 단순하기 때문에 이해하기쉽고, 데이터 분석을 쉽게 할 수 있음
    2. 성능상의 이유
       • 데이터양이 증가함에 따라 팩트 테이블을 디멘션 테이블보다도 훨씬 커져 그 데이터양이 집계 시간을 좌우함
       • 팩트 테이블이 메모리 용량을 초과한 시점에서 디스크 I/O가 발생하고 그 대기 시간이 쿼리의 지연으로 이어짐
       • 팩트 테이블을 될 수 있는 한 작게 하는 것이 고속화에 있어서 중요하며, 팩트 테이블에는 ID와 같은 키만을 남겨두고 그 외에 나머지는 디멘션 테이블로 옮김

• 정규화에 의해 분해된 테이블을 최대한 결합하여 하나의 테이블로 정리(중복 허용)

  • 정규화와 반대의 작업 → 비정규화

비정규화 테이블

데이터 마트에 정규화는 필요 없다

• MPP 데이터베이스는 열 지향 스토리지를 가짐
• 열 지향 스토리지는 칼럼 단위로 데이터가 저장되므로 칼럼의 수가 아무리 늘어나도 성능에 영향을 주지 않음
• 따라서 처음부터 팩트 테이블에 모든 칼럼을 포함해두고, 쿼리의 실행 시에는 테이블 결합을 하지 않는 편이 간단함
• 게다가 열 지향 스토리지는 칼럼 단위로의 데이터 압축이 있음
  • 문자열을 그대로 저장해도 아주 작게 압축되므로 디스크 I/O의 증가는 억제됨
  • 디멘션 테이블이 존재할 이유가 거의 없어짐

• 데이터 마트의 성능상의 문제는 열 지향 스토리지에 의해 해결됨
• 비정규화 테이블(denormalized table): 스타 스키마에서 좀 더 비정규화를 진행해 모든 테이블을 결합한 팩트 테이블
• 대부분의 경우, 데이터 마트는 이렇게 비정규화 테이블로 하는 것이 가장 단순하며, 충분히 효율적인 방법임
  
  

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

• 비정규화 테이블을 다차원 모델(multidimensional model)에 의해 추상화해야 함
  • BI 도구의 기본이 되는 데이터 모델로, 테이블 및 칼럼의 집합을 알기 쉽게 정리해 이름을 붙인 것
• 다차원 모델은 칼럼을 디멘션(dimension: 크로스 집계에 있어서 행과 열을 이용함)과 측정값(measure: 숫자 데이터와 그 집계 방법을 정의함)으로 분류함