<1. 빅데이터의 기초 지식> BI의 의미와 데이터를 시각화하기까지의 간략한 과정 설명에 이어 작성합니다.
1. BI 도구로 집계하기 (데이터 마트의 필요)
2. 집계 효율을 높일 수 있는 데이터베이스 구조
3. 데이터 마트의 과거
4. 거대한 하나의 팩트 테이블인 비정규화 테이블
5. 다차원 모델
1. BI 도구로 집계하기 (데이터 마트의 필요)
BI 도구는 크로스 집계 방식으로 많은 양의 데이터를 집계하고 보고서로 한눈에 요약해서 볼 수 있도록 도와주는 역할을 합니다. 엑셀의 피벗 테이블 기능으로 생각하면 쉬운데 트랜잭션 테이블에서 크로스 테이블로 변환하는 과정이라고도 합니다.
크로스 테이블은 행과 열이 교차하는 부분에 숫자 데이터가 들어가며 열을 늘리는 방식이고 트랜잭션 테이블은 행으로 데이터가 늘어나는 방식입니다.
데이터가 쌓이는 방식은 주로 트랜잭션 테이블 형식이며 집계해서 보고자 하는 방식은 크로스 테이블로 변환이 필요합니다.
하지만 수천만 이상의 데이터를 BI 도구만으로 크로스 집계하는 데에는 한계가 있습니다.
그래서 이런 경우 SQL로 트랜잭션 테이블 형태로 먼저 집계를 한 후에 크로스 집계하는 방식을 사용합니다.
- SQL Aggregate function : SUM, COUNT, MIN, MAX, AVG
예를 들어 하루치의 데이터가 매일 쌓여있는 트랜잭션 테이블을 월 단위로 집계(데이터 집계)하는데 그 형태는 트랜잭션 테이블 형태로 유지되어있는 상태입니다. 이 데이터를 BI 도구로 크로스 집계를 해 시각화가 가능합니다.
2. 집계 효율을 높일 수 있는 데이터베이스 구조
집계 효율이 높은 DB 시스템 구조는 데이터 레이크/DW → 데이터 마트 → 시각화 도구 까지의 3계층 구조입니다.
데이터 마트는 데이터 웨어하우스나 데이터 레이크로부터 시각화해서 보고자 하는 필요한 데이터만 가공, 집계해서 추출한 것을 말합니다. 데이터 마트를 만들 때 되도록 작게 만드는 것이 좋겠지만 어쩔 수 없는 Trade-off 관계가 존재합니다.
많은 양의 데이터가 있으면 무거우며, 집계 과정을 거친 적은 양의 데이터는 표현할 수 있는데 한계가 생깁니다.
의사소통을 통해 시각화할 때 필요한 정보가 무엇인지 파악하고 정말 필요한 컬럼과 집계값을 가져올 수 있도록 마트를 구성하는 것이 제일 좋습니다.
< 데이터 압축 >
일반적으로 DW / Data Lake는 일정 시간에 처리할 수 있는 데이터의 양, 배치 처리 등 대규모 데이터 처리에서 중요시 되는 처리량에 집중하고, 데이터 마트는 데이터 처리가 끝날 때까지의 대기 시간인 지연 시간을 줄이는데 집중해야합니다.
데이터 처리의 응답이 빠르다는 표현을 Latency(대기시간)이 적다, 지연이 적다라고 표현하는데 되도록 지연이 적은 데이터베이스로 데이터 마트를 만들어야 합니다. 데이터 마트 → 시각화 도구로 가는 크로스 집계는 초 단위의 응답이 가능하도록 구현해야하기 때문입니다.
수천만 레코드, 수십GB 정도면 일반적 RDB인 MySQL, PostgreSQL 를 사용해도 데이터 마트로 적합하지만 그 이상 레코드인 수억 레코드의 경우에는 RDB의 메모리가 부족해지고 성능이 급격하게 떨어집니다.
그런 집계를 고속화하기 위해서는 압축, 분산 기법을 사용하며 데이터를 최대한 작게 압축하고 여러 디스크에 분산해 로드에 따른 지연을 줄이는데, 멀티 코어를 활용해 디스크 I/O를 병렬처리하는 방식으로 MPP 아키텍처(massive parallel processing = 대규모 병렬 처리)라고 합니다.
데이터 집계에 최적화 되어있는 방법으로 대량의 데이터를 분석하는 Amazon Redshift, Google bigquery 등의 데이터베이스에서 사용되는 방식입니다.
행 지향 데이터베이스 | 열 지향 데이터베이스 | MPP 데이터베이스, 대화형 쿼리엔진 |
일반적인 업무 시스템에서 사용되는 DB, 레코드 단위의 읽고 쓰기에 최적화 |
데이터 분석에 사용되는 DB, 컬럼 단위의 집계에 최적화 |
분산된 데이터를 멀티 코어를 활용해 디스크 I/O를 병렬 처리하는 DB, 대량 데이터 분석 |
매일 발생하는 대량 트랜잭션 처리가 중심이기에 지연되지 않는 데이터 쓰기가 중요 |
어떤 컬럼이 사용될 지 모르기에 모든 데이터 필요 ( 많은 디스크 I/O 발생) | CPU와 디스크 모두 균형적으로 증가 필요 |
각 행을 하나의 덩어리로 디스크에 저장함 |
필요한 컬럼만 로드해 디스크 I/O를 줄일 수 있음 | 여러 디스크에 분산된 데이터가 다른 CPU 코어들로 읽혀 부분적인 쿼리 실행. 하나의 쿼리를 작게 태스크로 분해해 독립적으로 병렬 실행하고 결과값 합침. |
새 레코드를 추가할 때 파일 끝에 데이터를 쓰기 때문에 빠르고 효율적으로 추가함 | 집계하는데 매우 빠르며, 압축 효율이 좋음 (같은 문자열의 반복은 더 작게 압축 가능) |
동시에 병렬로 실행되기에 CPU 코어 개수에 비례해 빠른 속도 |
검색을 위해 적절한 인덱스가 필요함 | 저장하는데 시간이 걸림 |
데이터를 열 지향 스토리지로 변환 필요 - MPP 데이터베이스 : 하드웨어 일체형 - Hadoop 대화형 쿼리 엔진 : 분산 스토리지에 보관 (열 지향 스토리지 필요) |
쿼리가 짧은 시간안에 끝나는 가정. 하나의 쿼리를 하나의 스레드로 실행함. |
압축된 대량의 데이터를 읽기 때문에 쿼리 실행 시간이 김. 멀티 코어 활용해 쿼리 고속화 필요. |
쿼리에 따라 리소스 사용량도 많이 증가하기에 과도한 부하가 걸릴 수 있음. |
RDB (oracle, MySQL) | Teradata, Redshift | Amazon Redshift, Google bigquery Hadoop과의 궁합 - 대화형 쿼리 엔진 |
3. 데이터 마트의 과거
BI 도구를 사용하기 위해서는 시각화에 필요한 정보를 모은 데이터 마트가 필요합니다. BI도구는 OLAP 라는 구조를 사용해 데이터를 집계하기 위한 소프트웨어로 데이터 마트도 과거에는 다차원 데이터 OLAP 큐브로 작성되어있었다고 합니다.
OLAP가 무엇일까요?
OLAP는 Online Analytical Processing로 데이터 집계를 효율화하는 접근 방식 중 하나입니다.
RDB 에서는 표 형식으로 데이터를 SQL로 집계하지만 OLAP는 다차원 데이터 모델(OLAP 큐브)를 MDX (Multidimensional Expressions) 라는 쿼리 언어로 크로스 집계하는 구조입니다.
과거에는 다차원 데이터를 크로스 집계하기 위해서 모든 조합을 미리 계산해두고 이를 데이터베이스 안에 캐시해두어 쿼리를 실행하면 미리 집계된 결과를 내보내는 등의 구조였다고 합니다.
하지만 MPP 데이터베이스와 인메모리 데이터베이스 보급 등 DB의 발전으로 사전 계산이 필요없어졌기 때문에 BI 도구와 MPP 데이터베이스를 조합해 크로스 집계하는 방식을 많이 채택하고 있습니다.
그러나 만들고자 하는 차트들을 위해 다차원 모델을 설계해야하는데, MPP 데이터베이스에는 다차원 모델의 개념이 없습니다. 그래서 대신하여 비정규화 테이블을 사용합니다.
<빅데이터를 지탱하는 기술> 책에서는 '시각화에 적합한 데이터 마트를 만드는 것' = 'BI 도구를 위한 비정규화 테이블을 만드는 것' 으로 표현하고 있습니다.
4. 거대한 하나의 팩트 테이블인 비정규화 테이블
RDB의 테이블은 마스터와 트랜잭션으로 구분하는데 시간과 함께 생성되는 데이터를 기록한 것을 트랜잭션, 트랜잭션에서 참고되는 각종 정보를 마스터라고 합니다.
트랜잭션은 한번 기록하면 변화되지 않지만 마스터는 상황에 따라 변경될 수 있다는 특징이 있습니다.
더 큰 범주인 DW 데이터 웨어하우스에는 팩트 테이블과 디멘젼 테이블이 있습니다. 팩트 테이블은 트랜잭션과 유사하게 사실이 기록된 것이며 집계가 되도록 숫자 데이터로 이루어져있습니다. 디맨젼 테이블은 참고되는 마스터 데이터로 데이터를 분류하기 위한 속성값으로 사용됩니다.
데이터 마트는 팩트 테이블을 중심으로 여러 디멘젼 테이블을 결합하는 형식입니다. 정규화를 분해라고 표현한다면 결합은 비정규화로 표현할 수 있습니다.
디멘젼 테이블을 작성하기 위해서는 정규화로 분해되어 있던 테이블을 최대한 결합해 하나의 테이블로 만드는데, 결합하다보면 데이터가 중복될 수도 있습니다.
<스타 스키마>
현재는 데이터 마트를 구축할 때 열 지향 스토리지를 많이 사용하지만 과거 데이터마트를 구축할 때는 팩트 테이블을 중심으로 여러 디맨젼 테이블을 결합하는 스타 스키마를 주로 사용했습니다.
스타 스키마를 사용하는 이유는 단순하고 쿼리의 작성법이 정해져있어 SQL을 자동 생성하기에 쉽기 때문입니다.
또한 데이터 양이 증가하면 팩트 테이블은 디맨젼보다 훨씬 커지고, 팩트 테이블이 메모리 용량을 초과하면 디스크 I/O가 발생하면서 쿼리 지연으로 이어집니다.
팩트 테이블에서 키값만 남겨두고 나머지 컬럼들을 모두 디멘젼으로 옮기면 팩트 테이블이 작아지기에 성능을 높일 수 있어 테이블을 분해하는 스타 스키마가 많이 사용되었습니다.
<스타 스키마가 필요없는 데이터 마트>
현재는 열 지향 스토리지의 발전으로 컬럼이 늘어나도 성능에 전혀 영향을 주지 않아 팩트 테이블에 모든 컬럼을 포함하고 쿼리 실행 시에는 필요 없는 컬럼들을 결합하지 않는 방식으로 사용할 수 있습니다.
또한 컬럼 단위로 데이터 압축이 되기에 데이터를 굳이 디멘젼 테이블로 옮기며 나눌 필요가 없어졌습니다.
그리하여 거대한 팩트 테이블, 스타 스키마에서 비정규화를 진행해 모든 테이블을 결합한 팩트 테이블을 비정규화 테이블이라고 부르고 데이터 마트는 비정규화 테이블로 하는 것이 단순하고 효율적인 방법으로 꼽힙니다.
5. 다차원 모델
이러한 비정규화 테이블이 준비되면 다차원 모델로 추상화를 하는데, BI 도구의 기본적인 데이터 모델이며 디멘젼과 측정값으로 분류합니다.
쉽게 말하면 숫자값 데이터를 측정값으로, 날짜, 문자열 등 행과 열에 들어가는 부분을 디멘젼 으로 지칭합니다.
다차원 모델은 BI 도구로 손쉽게 확장 가능한데, 예시로 나이를 그룹화해 연령대를 만드는 등 분석하고자 하는 요구에 따라 다수의 컬럼을 추가할 수 있으며 필요한 데이터 분석이 가능하도록 만들어 줍니다.
BI를 목표로 빅데이터를 다루는 방법에 대해 살펴보고자 했습니다.
- 데이터 마트의 필요성
- 데이터 마트의 과거
- 데이터 마트에 사용하는 데이터베이스
- 데이터 마트 구축 방식
- 데이터 마트를 사용한 BI 데이터 분석 과정
해당 내용은 < 빅데이터를 지탱하는 기술 - 니시다 케이스케 >
2. 빅데이터의 탐색 을 참고하여 작성했습니다.
3. 빅데이터의 분산 처리
4. 빅데이터의 축적
5. 빅데이터의 파이프라인
6. 빅데이터 분석 기반의 구축
순서로 정리하고자 합니다.
감사합니다😄
'Visualization > BI - DW' 카테고리의 다른 글
<3. 빅데이터의 분산처리> Hadoop, Spark 이용한 데이터 처리 (0) | 2023.05.21 |
---|---|
<1. 빅데이터의 기초 지식> BI란 무엇일까요? (3) | 2023.03.26 |
[seaborn] Color palette (0) | 2021.07.22 |
[nbviewer] jupyter notebook 사이트 내 표시 (0) | 2021.07.21 |
댓글