2-1. 크로스 집계의 기본
트랜잭션 테이블, 크로스 테이블, 피벗 테이블
- 크로스 테이블: 행과 열이 교차하는 부분에 숫자 데이터가 들어가 있는 테이블. 보고서의 기본
- 트랜잭션 테이블: 행 방향으로만 증가하고 열 방향으로는 증가하지 않는 테이블 (데이터 베이스에 새로운 행을 추가하는 것은 간단하지만, 열을 늘리는 것은 간단하지 않음)
- 크로스 집계: 트랜잭션 테이블에서 크로스 테이블로 변환하는 과정 (ex. 스프레드시트의 pivot table 기능)
룩업 테이블
- 추가 정보를 참고하고 싶을 때 사용 (트랜잭션 테이블에 추가하는 것은 간단하지 않으므로)
SQL에 의한 테이블의 집계
- 스프레드시트, BI 도구, pandas는 대량의 데이터를 크로스 집계하기에 부적합 (느려져서 불편)
- 대량의 데이터를 집계하는 데에 뛰어난 SQL로 먼저 양을 줄이고(데이터 집계 프로세스), 시각화 도구로 크로스 집계하는 것(시각화 프로세스)이 가능
데이터 집계 -> 데이터 마트 -> 시각화
데이터 마트: 데이터 집계와 시각화 사이에 있음
- 데이터 마트의 크기에 따라 시스템 구성이 결정
- trade-off: 데이터 마트가 작을수록 시각화하는 것이 간단하지만, 많은 정보를 잃어 시각화 프로세스에서 할 수 있는 것이 적어짐 <-> 데이터 마트를 크게 유지하면 시각화하는 것이 복잡해짐
2-2. 열 지향 스토리지에 의한 고속화
데이터베이스의 지연 줄이기
3계층의 데이터 집계 시스템: "데이터 레이크" -> (데이터 집계) -> "데이터 마트" -> (크로스 집계) -> "시각화 도구"
데이터 처리의 지연
latency를 줄이는 두 가지 방법
1. 모든 데이터를 메모리에 올리는 것
2. RDB를 사용하는 것: RDB는 원래 지연이 적고 많은 수의 클라이언트가 동시 접속해도 성능이 나빠지지 않음
- 하지만 RDB는 메모리가 부족하면 급격히 성능이 저하됨 (디바이스 I/O 발생)
'압축'과 '분산'에 의해 지연 줄이기: MPP 기술
MPP (Massive Parallel Processing): 분산된 데이터를 읽기 위해 멀티 코어를 활용하면서 디스크 I/O를 병렬 처리 하는 아키텍처
ex. Amazon Redshift, Google BigQuery
- 데이터 집계에 최적화 됨
- 데이터 웨어하우스, 데이터 분석용 데이터베이스에 활용
열 지향 데이터베이스 접근
- 행 지향 데이터베이스: 레코드 단위의 읽고 쓰기에 최적화 (일반적인 운영용 데이터베이스) (ex. Oracle, MySQL)
- 열 지향 데이터베이스: 칼럼 단위 집계에 최적화 (데이터 분석에 사용되는 데이터베이스)
행 지향 데이터베이스
- 매일 발생하는 대량의 트랜잭션을 지연 없이 처리하기 위해 데이터 추가를 효율적으로 할 수 있도록 함
- 데이터 검색을 고속화하기 위해 index를 만듬 -> 디스크 I/O를 최적화하기 위해 적절한 index 튜닝이 중요
- 필연적으로 대량의 데이터 분석은 항상 디스크 I/O를 동반하기 때문에 index에 의지하지 않는 고속화 기술 필요
열 지향 데이터베이스
- 미리 칼럼 단위로 정리해 둠으로써 필요한 칼럼만 로드하여 디스크 I/O를 줄임
- 데이터 압축 효율도 우수
MPP 데이터베이스의 접근 방식
쿼리 지연을 줄이는 또 다른 방법은 MPP 아키텍처에 의한 데이터 처리의 병렬화
- 열 지향 데이터베이스는, 디스크에서 대량의 데이터를 읽기 때문에 1번의 쿼리 실행시간이 길어짐 + 압축된 데이터의 전개 등 CPU 리소스 필요 => 멀티 코어를 활용하여 고속화하는 것이 좋음
- MPP: 하나의 쿼리를 다수의 작은 태스크로 분해하고 이를 가능한 한 병렬로 실행
MPP 데이터베이스와 대화형 쿼리 엔진
- MPP를 사용한 데이터 집계는 CPU 코어수에 비례하여 고속화
- 이를 위해 데이터가 고르게 분산되어 있어야 함 (쿼리가 잘 병렬화되도록)
- 일부 MPP 제품은 하드웨어(MPP 데이터베이스), 소프트웨어를 통합된 제품으로 제공 (CPU, 디스크가 모두 균형있게 늘어야 성능이 확보됨)
- 다른 MPP 아키텍처는 Hadoop과 함께 사용되는 대화형 쿼리 엔진으로도 채택
- 그러나 데이터를 열 지향으로 압축하지 않는 한 MPP 데이터베이스만큼의 성능 확보가 안됨 - Hadoop 상의 열 지향 스토리지를 만들기 위해 여러 라이브러리 개발 (Ch.3에서 언급 예정)
2-3. 애드 혹 분석과 시각화 도구
Jupyter Notebook에 의한 애드 혹 분석
- 어떻게 해서든 자동화를 해야겠다는 강한 이유가 없는 한, 노트북을 중심으로 하는 애드 혹 분석 환경을 갖추는 것이 우선 과제
대시보드 도구
- 최신의 집계 결과를 즉시 확인할 수 있길 기대
- 스몰 데이터만을 처리하는 데는 로컬 호스트 메모리에서의 처리가 가장 좋다: 네트워크 I/O, 디바이스 I/O를 모두 없앤 상테에서 데이터 집계까 가장 빠르기 때문
Redash
Superset
Kibana: Elasticsearch의 프론트엔드에서 실시간으로 작성
BI 도구
- 시각화에 적합 데이터 마트를 만들어 읽고 쓰는 것을 전제로 함
Tableau
2-4. 데이터 마트의 기본 구조
시각화에 적합한 데이터 만들기 - OLAP
OLAP (Online Analytical Processing)
- 데이터 집계를 효율화하는 접근 방법 중 하나
- 운영에서의 RDB는 표 형식으로 모델링된 데이터를 SQL로 집계 <-> OLAP에서는 '다차원 모델'의 데이터 구조를 MDX(multidimensional expressions)등의 쿼리 언어로 집계
- OLAP 큐브: 데이터 분석을 위해 만들어진 다차원 데이터
- OLAP: OLAP 큐브를 크로스 집계하는 구조
- BI 도구는 본래 OLAP 구조를 사용해 데이터를 집계하기 위한 소프트웨어 -> 데이터 마트도 이전에는 OLAP 큐브로 작성되어 있었음
MPP 데이터베이스와 비정규화 테이블
- 최근, MPP 데이터베이스와 인 메모리 데이터베이스 등의 보급으로 사전에 OLAP 큐브를 만드는 등의 필요가 사라짐
- BI 도구와 MPP 데이터베이스를 조합하여 크로스 집계하는게 보편화
- MPP 데이터베이스는 다차원 모델의 개념이 없기 때문에, 이를 대신에 '비정규화 테이블' 준비
- 시각화에 적합한 데이터를 만드는 것 = BI 도구를 위한 비정규화 테이블을 만든느 것
테이블을 비정규화하기
- 트랜잭션: 시간과 함께 생성되는 데이터를 기록한 것 (한 번 기록하면 변화하지 않음)
- 마스터: 트랜잭션에서 참고되는 각종 정보 (상황에 따라 덮어씌워짐)
- 데이터 분석의 경우, 정규화된 관계형 모델에서 출발해 반대의 비정규화를 진행
팩트 테이블과 디멘션 테이블
데이터 웨어하우스에서의 개념
- 팩트 테이블 (fact table): 트랜잭션처럼 사실이 기록된 것 - 집계의 기반이 되는 숫자 데이터(ex. 판매액)를 기록
- 디멘전 테이블 (dimension table): 마스터 테이블 - 데이터를 분류하기 위한 속성값
스타 스키마와 비정규화: 팩트 테이블을 중심으로 여러 디멘션 테이블을 결합
- 스타 스키마 (star schema): 팩트 테이블을 중심으로 여러 디멘전 테이블을 결합
- 장점 1. 구축이 단순: 데이터 분석을 쉽게할 수 있음
- 장점 2. 성능상 좋음: 팩트 테이블을 될 수 있는 한 작게 유지하는 것이 고속화에 유리
비정규화 테이블: 데이터 마트에 정규화는 필요 없다
- MPP 데이터베이스와 같은 열 지향 스토리지를 갖는 시스템이 보편화되며 사정이 바뀜
- 열 지향 스토리지는 칼럼 단위로 데이터가 저장되므로 칼럼의 수가 아무리 늘어나도 성능에 영향 주지 않음
=> 처음부터 팩트 테이블에 모든 칼럼을 포함해두고, 쿼리 실행시 테이블 결합을 하지 않는 편이 바람직
- 비정규화 테이블(denormalized table): 스타 스키마에서 좀 더 비정규화를 진행해 모든 테이블을 결합한 팩트 테이블
다차원 모델 시각화에 대비하여 테이블 추상화하기
다차원 모델: BI 도구의 기본이 되는 데이터 모델 - 테이블 및 칼럼 집합을 알기 쉽게 정리해 이름을 붙인 것
- 시각화를 위해 비정규화 테이블에서 다차원 모델로 추상화한다
- 측정값(measure): 숫자 데이터와 그 집계 방법을 정의하는 것
- 디멘전(dimension): 크로스 집계에 있어서 행과 열을 이용하는 것
- ex.
비정규화 테이블
매출일 | 점포명 | 지역 | 상품명 | 상품 카테고리 | 금액 |
2025-01-01 | 점포 A | 서울 | 상품 A | 식료품 | 1000 |
2025-01-01 | 점포 A | 서울 | 상품 B | 전자제품 | 20000 |
... |
다차원 모델
- 디멘전
이름 | 쿼리 |
매출일 | "매출일" |
점포명 | "점포명" |
지역 | "지역" |
상품명 | "상품명" |
상품 카테고리 | "상품 카테고리" |
- 측정값
이름 | 쿼리 |
금액 | sum("금액") |
모델의 정의 확장
다차원 모델의 정의는 나중에 확장할 수 있음 - 데이터 분석의 요구에 따라 비정규화 테이블에는 다수의 칼럼이 추가
브레이크 다운 분석(Breakdown Analysis): 전용의 디멘전을 팩트테이블에 추가하고 그룹명을 써 넣음 ->그룹별로 대시보드 작성 (필터링 활용)
'Data Engineering' 카테고리의 다른 글
[빅데이터를 지탱하는 기술] Ch3. 빅데이터의 분산 처리 (0) | 2025.03.14 |
---|---|
[빅데이터를 지탱하는 기술] Ch1. 빅데이터의 기초 지식 (2) | 2025.02.25 |
Hadoop Ecosystem Explained (0) | 2024.08.04 |
[12주차] Airflow, EMR 스터디 (0) | 2022.05.08 |
[AWS] Ubuntu EC2에서 python3 version 변경하기 (0) | 2022.04.30 |