한 칸씩 쌓기

3-1. 대규모 분산 처리의 프레임워크

구조화 데이터와 비구조화 데이터

- 스키마: 칼럼명, 데이터형, 테이블 간의 관계 등이 정의된 정보

- 구조화된 데이터 (Structured Data): 스키마가 명확하게 정의된 데이터 (SQL로 집계)

- 비구조화 데이터 (Unstructured Data): 텍스트, 이미지, 동영상 등의 미디어 데이터로 스키마가 없는 데이터 (SQL로 집계 불가)

- 데이터 레이크: 비구조화 데이터를 분산 스토리지 등에 저장하고, 분산 시스템에서 처리하는 것

    - 데이터 가공 과정에서 스키마 정의 => 구조화된 데이터로 변환 => 분석에 사용

스키마리스 데이터

- 스키마리스 데이터(shemaless data): CSV, JSON, XML 등 데이터 서식은 정해져 있지만, 칼럼 수나 데이터형은 명확하지 않은 데이터

- 스키마를 정하는 것은 시간과 비용이 소요되기 때문에 JSON은 그대로 저장하고 데이터 분석에 필요한 필드만 추출하는 편이 가장 간단

데이터 구조화의 파이프라인

- 먼저 필요한 것은 스키마를 명확하게 한 테이블 형식의 '구조화 데이터'로 변환하는 것

- 구조화 데이터는 일반적으로 데이터 압축률을 높이기 위해 열 지향 스토리지로 저장

- 데이터 마트는 고려하지 않고, 데이터를 구조화하여 SQL로 집계 가능하게 만드는 것만 생각

열 지향 스토리지의 작성

- 분산 스토리지 상에 작성해 효율적으로 데이터 집계

- MPP 데이터베이스: 제품에 따라 스토리지 형식이 고정되어 있어 사용자가 그 상세를 몰라도 됨

- Hadoop: 사용자가 직접 열 지향 스토리지 형식을 선택, 쿼리 엔진도 선택

- Hadoop에서 선택할 수 있는 열 지향 스토리지 종류:

    - Apache ORC: 구조화 데이터를 위한 열 지향 스토리지

    - Apache Parquet: 스키마리스에 가까운 구조로 되어있어 JSON 같은 데이터도 그대로 저장 가능

- 비구조화 데이터를 열 지향 스토리지로 변환하는 과정에는 데이터 가공 및 압축을 위해 많은 컴퓨터 리소스가 소비됨

Hadoop - 분산 데이터 처리의 공통 플랫폼

- Hadoop: 분산 시스템을 구성하는 다수의 소프트웨어로 이루어진 집합체 (대규모 분산시스템을 구축하기 위한 공통 플랫폼 역할 담당)

분산 시스템의 구성 요소

Hadoop의 기본 구성 요소

1. HDFS (Hadoop Distributed File System): 분산 파일 시스템

2 YARN (Yet Another Resource Negotiator): 리소스 관리자

3. MapReduce: 분산 데이터 처리

- 그 외의 프로젝트는 Hadoop 본체와 독립적으로 개발되어 Hadoop을 이용한 분산 애플리케이션으로 동작

- Hadoop을 일부만 사용하거나 전혀 사용하지 않게 분산 시스템을 구성할 수도 있다

분산 파일 시스템과 리소스 관리자: HDFS, YARN

- HDFS: Hadoop에서 처리되는 데이터 대부분이 저장됨

    - 다수의 컴퓨터에 파일을 복사하여 중복성을 높임

- YARN: CPU나 메모리 등 계산 리소스 관리

    - 컨테이너 (container): 애플리케이션이 사용하는 CPU 코어와 메모리를 관리하는 단위

    - Hadoop이 분산 애플리케이션을 실행하면 YARN이 클러스터 전체의 부하를 보고 비어있는 호스트부터 컨테이너를 할당

    - (Docker 컨테이너와 무관)

    - 한정된 리소스를 여러 애플리케이션에 어떻게 할당할 지 관리하므로써 모든 애플리케이션이 차질없이 실행되도록 제어

분산 데이터 처리 및 쿼리 엔진: MapReduce, Hive

- MapReduce: YARN 상에서 동작하는 분산 애플리케이션 중 하나

    - Java 프로그램을 실행할 수 있음 - 비구조화 데이터를 가공하는 데 적합

- Apache Hive: SQL 등 쿼리 언어에 의한 데이터 집계시 사용하는 쿼리 엔진

    - 초기 Hive: SQL 쿼리를 자동으로 MapReduce 프로그램으로 변환하는 소프트웨어로 개발

Hive on Tez

- Hive를 가속화하기 위해 개발

    - 기존 MapReduce는 오버헤드가 매우 컸음 => 애드 혹 쿼리 실행에 부적합

- Tez에서는 스테이지 종료를 기다리지 않고 처리가 끝난 데이터를 차례대로 후속 처리에 전달하므로써 쿼리 전체 실행 시간 단축

대화형 쿼리 엔진

- (Hive 고속화 말고) 처음부터 대화형 쿼리 실행만 전문으로 하는 쿼리 엔진 개발

- Presto, Apache Impala

- 대화형 쿼리 엔진: 순간 최대 속도를 높이기 위해 모든 오버헤드 제거

    - 사용할 수 있는 리소스를 최대한 활용하여 쿼리 실행

    - MPP 데이터베이스와 비교해도 손색없는 응답 시간 실현

목적에 따른 쿼리 엔진 구분

- Hive: 대량의 비구조화 데이터를 가공하는 무거운 배치 처리에 활용 (높은 처리량 (Throughput)이 특징)

- Presto, Impala: 구조화 데이터를 대화식으로 집계 (적은 지연이 특징)

SQL-on-Haddop: Hadoop 에서 개발된 쿼리 엔진들

- 아직 MPP 데이터베이스 만큼 기능적으로 따라잡지 못한 부분들이 있지만, 분산 스토리지에 저장된 데이터를 신속하게 집계할 수 있는 점에서 우수

Spark - 인 메모리 형의 고속 데이터 처리

Hadoop과는 다른 독립된 프로젝트

- Spark의 대표적 특징: 대량의 메모리를 활용하여 고속화

    - MapReduce는 처리 대부분을 디스크 읽고 쓰기에 사용

    - 컴퓨터 메모리 성능이 높아짐에 따라, 가능한 한 많은 데이터를 메모리 상에 올려놓고 디스크에는 아무것도 기록하지 않는 것이 현실화됨

MapReduce 대체하기

Spark은 Hadoop을 대체하는 것이 아니라 MapReduce를 대체

- HDFS, YARN 등은 Spark에서도 그대로 사용

- 분산 스토리지로 Amazon S3를 이용하거나 Cassandra 등의 분산 데이터베이스를 사용하는 것도 가능

- Spark 상에서 실행되는 데이터 처리는 스크립트 언어를 사용할 수 있음: Java, Scala, Python, R

- Spark SQL: Spark 상에서 SQL 쿼리 실행

- Spark Streaming: 스트림 처리

3-2. 쿼리 엔진

SQL-on-Hadoop에 의한 데이터 처리의 구체적인 예: 

- Hive에 의한 구조화 데이터 생성

- Presto에 의한 대화식 쿼리

데이터 마트 구축의 파이프라인

1. 분산 스토리지에 저장된 데이터를 구조화하고 열 지향 스토리지 형식으로 저장

    - 다수의 텍스트 파일을 읽어들여 가공하는 부하가 큰 처리: Hive 사용

2. 완성한 구조화 데이터를 결합, 집계하고 비정규화 테이블로 데이터 마트에 작성

    - 열 지향 스토리지를 이용한 쿼리 실행: Presto 사용

- Hive Metastore: Hive에서 만든 각 테이블의 정보

    - Hive 뿐만 아니라 다른 SQL-on-Hadoop의 쿼리 엔진에서도 공통의 테이블 정보로 참고됨

Hive에 의한 구조화 데이터 작성

Hive 시작 후 CREATE EXTERNAL TABLE로 외부 테이블 정의

- 외부 테이블 (external table): Hive의 외부에 있는 특정 파일을 참고해 마치 거기에 있는 테이블이 존재하는 것처럼 읽어들일 수 있음

- 텍스트 파일 로드되고 구조화 데이터로 변환됨

- SQL-on-Hadoop의 쿼리 엔진들은 MPP 데이터베이스와 달리, 데이터를 내부로 가져오지 않아도 텍스트 파일을 그대로 집계할 수 있음

- CSV 파일 등을 그대로 집계하는 것은 비효율 (매번 텍스트를 읽어야 하기 때문에 느림)

    => 열 지향 스토리지로 변환

열 지향 스토리지로의 변환: 데이터 집계의 고속화(배치형 쿼리 엔진용)

- 테이블을 열지향 스토리지 형식 (ex. ORC 형식)으로 변환

- 변환에는 다소 시간이 걸리지만, 변환 후 집계 시간 크게 단축

Hive로 비정규화 테이블을 작성하기

- 데이터 구조화가 완료되면 데이터 마트 구축

- Presto 같은 대화형 쿼리 엔진을 사용할 것인지, Hive 같은 배치형 쿼리 엔진을 사용할 것인지 결정

- 시간이 걸리는 배치 처리는 원칙적으로 Hive 사용

    - 수억 레코드는 데이터 마트로 내보내는 것만으로도 상당한 시간 소요

    - 쿼리 엔진 자체의 성능으 최종적인 실행 시간에 영향 거의 없음

    - 리소스 효율 측면에서, 배치형 시스템 사용하는게 더 좋음

- 비정규화 테이블 생성시 효율적일 쿼리를 작성하는 것이 중요

서브 쿼리 안에서 레코드 수 줄이기

- 초기 단계에서 팩트 테이블 작게 하기

데이터 편향 피하기

- 중복 없는 값 세기 (count distinct ...)는 데이터를 한 곳에 모아야 해서 분산 처리하기 어려움

대화형 쿼리 엔진 Presto의 구조

작은 쿼리를 여러 번 실행하는 대화형 데이터 처리에는, 실행의 지연을 감소시키는 것이 필요

- 참고 기술: Dremel

플러그인 가능한 스토리지

Presto의 주요 특징: 하나의 쿼리 안에서 여러 데이터 소스에 연결 가능

- Presto는 전용 스토리지를 갖고 있지 않아, Hive와 마찬가지로 다양한 데이터 소스에서 직접 데이터를 읽어 드림

    - MPP 데이터베이스에서는 소티리지와 컴퓨팅 노드가 밀접하게 결합되어 있어 처음에 데이터를 로드하지 않으면 집계를 시작할 수 없음

- Presto가 성능을 최대한 발휘하려면 원래 스토리지가 열 지향 데이터 구조로 되어 있어야 함

    - ORC 형식의 로드에 최적화됨

CPU 처리의 최적화

Presto의 SQL 실행

1. 쿼리를 분석하여 최적의 실행 계획 생성

2. Java의 바이트 코드로 변환

3. 바이트 코드는 Presto의 worker 노드로 배포 -> 런타임 시스템에 의해 기계 코드로 컴파일

4. 멀티 스레드화되어 단일 머신에서 수백 태스크로 병렬 실행

    - CPU 이용률이 높을 수밖에 없음

    - (메모리와 CPU 리소스만 충분하다면) 데이터의 읽기 속도가 쿼리의 실행 시간을 결정

- Presto 쿼리는 일단 실행 시작되면 중간에 끼어들 수 없음

    => 너무 큰 쿼리 실행시, 그 쿼리에 대부분의 리소스가 사용되어 다른 쿼리를 실행할 수 없음

인 메모리 처리에 의한 고속화

- (Hive와 달리) Presto는 디스크에 쓰기를 하지 않음

- 모든 데이터 처리를 메모리상에서 실시하고 메모리가 부족하면 여유가 생길 때까지 기다리거나 오류로 실패

- 효과적인 데이터 처리 방식: 메모리상에서 할 수 있는 것은 메모리상에서 실행하고, 디스크가 있어야 하는 일부 데이터 처리는 Hive 등에 맡기기

    - GROUP BY는 단순 반복 처리기 때문에 메모리 소비량이 거의 고정

    - 대규모 배치 처리, 거대한 테이블끼리 결합 등에는 디스크 활용 필요

분산 결합과 브로드캐스트 결합

- 테이블의 결합은 종종 대량의 메모리 소비

- 분산 결합 (Distribute Join): 같은 키를 갖는 데이터는 동일한 노드에 모임

    - Presto 의 기본 JOIN 방식

    - 노드 간 데이터 전송을 위한 네트워크 통신 발생 => 쿼리 지연 초래

- 브로드캐스트 결합 (Broadcast Join): 결합하는 테이블의 모든 데이터가 각 노드에 복사

    - 디멘전 테이블은 메모리에 충분히 들어갈 정도로 작은 것이 대부분이므로, 테이블 결합이 훨씬 빨라짐

열 지향 스토리지 집계

- Presto에서는 열 지향 스토리 집계가 매우 빠름

데이터 분석의 프레임워크 선택

MPP 데이터베이스, Hive, Presto, Spark의 장단점 비교

MPP 데이터 베이스

장점

- 완성한 비정규화 테이블의 고속 집계에 적합

- 구조화 데이터를 SQL로 집계하는 것뿐이라면 기존의 데이터 웨어하우스 제품과 클라우드 서비스 이용하는 것이 가장 좋음

    - Hadoop이 데이터 웨어하우스를 능가할 수 없다

- 이 장에서 다룬 복잡한 기술 전혀 필요하지 않음

    - MPP 데이터베이스는 스토리지 및 계산 노드가 일체화되어 있기 때문에, ETL 프로세스 등으로 데이터 가져오는 절차는 필요

- BI 도구와의 조합도 용이

단점

- 확장성 및 유연성 떨어짐 (아래 경우들 대응 못함)

    - 대량의 텍스트 처리가 필요한 경우

    - 데이터 처리를 프로그래밍하고 싶은 경우

    - NoSQL 데이터베이스에 저장된 데이터를 집계하고 싶은 경우

Hive

장점

- 데이터양에 좌우되지 않음 (높은 안정성)

    - Hadoop 상의 분산 애플리케이션이 원래부터 높은 확장성과 내결함성을 목표로 설계됨

- 열 지향 스토리지를 만드는 등의 무거운 처리에 적합

- Tez의 등장으로 대화형 쿼리에도 사용됨

Presto

장점

- 속도 중시 & 대화식으로 특화된 쿼리 엔진 (Hive와 정반대)

    - 쿼리가 실패해도 빠르게 재실행 가능

- 많은 데이터 스토어와 조합 가능 - 모든 데이터를 SQL로 집계하게 해줌

단점

- 메모리가 부족하면 쿼리 실행할 수 없음

- 텍스트 처리가 중심이 되는 ETL 프로세스 및 데이터 구조화에는 적합하지 않음

    - 열 지향 스토리지를 만드는 데 사용할 수는 있지만 적합하지는 않음

- 단시간에 대량의 리소스 소비

    - 너무 무리하게 사용하면 다른 쿼리 실행 불가

Spark

장점

- 분산 시스템을 사용한 프로그래밍 환경 제공

    - SQL 뿐만 아니라 스크립트 실행

- 일련의 데이터 파이프라인을 하나의 프레임워크로 작성 가능

    - ETL부터 데이터 분석, 머신 러닝 등 모든 데이터 처리 가능

- 인 메모리 데이터 처리로 대화형 쿼리도 가능

단점

- 메모리 관리 등의 러닝 커브 소요

3-3. 데이터 마트의 구축

각종 테이블의 경할과 비정규화 테이블을 만들기까지의 흐름 설명

팩트 테이블 - 시계열 데이터 축적하기

팩트 테이블 작성의 두 가지 방법

1. 추가 (append): 새로 도착한 데이터만 증분으로 추가

2. 치환 (replace): 과거 데이터를 포함하여 테이블 전체 치환

테이블 파티셔닝

추가 (append)의 잠재적 문제

- 결손: 추가 실패를 알아채지 못한 경우

- 중복: 오류로 인해 추가가 여러 번 실행된 경우

- 관리의 복잡성: 팩트 테이블을 다시 만들어야 하는 경우

테이블 파티셔닝: 테이블을 물리적인 여러 파티션으로 나눔으로써 파티션 단위로 정리하여 데이터를 쓰거나 삭제할 수 있도록 함

- 각 파티션은 매번 교체 (이미 존재한다면 덮어쓰도록)하도록 설계

- 중복 해결

데이터 마트의 치환

- 데이터 마트의 양은 한정되어 있기 대문에, 상당히 거대한 테이블을 만들지 않는 한 매번 치환하는 것이 좋음

- 팩트 테이블 전체 치환하는 것의 장점

    1. 중복과 결손 해결

    2. 스키마 변경 등도 쉬움

- 단점: 처리 시간

    - 데이터 양이 너무 많다면 오래 걸림

- 데이터 양이 너무 많다면 마찬가지로 테이블 파티셔닝을 실시하거나 모니터링을 세팅할 필요 있음

- (Small Start) 1시간 이내에 팩트 테이블을 만들 수 있다면, 매번 치환하는 것으로 충분

    - 그것이 어려운 경우에만 추가를 이용한 워크플로 고려

집계 테이블 - 레코드 수 줄이기

집계 테이블 (Summary Table): 팩트 테이블을 어느 정도 모아서 집계하여 데이터 양을 줄임

- 일일 보고서를 만드는 데에 daily summary 테이블 자주 사용

- 카디널리티 (Cardinality): 각 칼럼이 취하는 값의 범위

    - ex. '성별'의 카디널리티 = 2 (Male, Female), 'IP 주소'의 카디널리티 = 무한(매우 높음)

    - 집계 테이블을 작게 하려면 모든 칼럼의 카디널리티를 줄여야 함

    - 카디널리티를 무리하게 낮추면 원래 있던 정보가 손실 됨

        - 레코드 수가 수억 건 정도면 집계 테이블을 만들지 않고 MPP 데이터베이스로 바로 써내는 것도 좋음

- 숫자 계산에 주의해야 함

    - 평균값은 집계 테이블을 사용하면 제대로 계산할 수 없음 (평균의 평균 vs 전체 평균)

    - count(distinct ...)도 집계 테이블로 취급하기 어려움 (daily summary table에서 MAU 계산은 불가능)

스냅샷 테이블 - 마스터 상태 기록하기

마스터 데이터처럼 업데이트될 가능성이 있는 테이블을 처리하는 두 가지 방법

1. 스냅샷 테이블 (Snapshot Table): 정기적으로 마스터 데이터를 통째로 저장

2. 이력 테이블 (History Table): 변경 내용만 저장

데이터 분석 입장에서는 스냅샷 테이블이 취급하기 쉬움

- 마스터 테이블의 레코드 수가 많다면 스냅샷 테이블은 거대해지지만 빅데이터 기술은 이걸 별로 개의치 않아도 됨

- 일종의 팩트 테이블로 간주

- 디멘전 테이블로 도 사용

- 이 때 스냅샷 날짜에 주의

    - 스냅샷은 하루의 끝에 취득하는 것이 좋음

        - ex. 1월 1일 스냅샷을 1월 1일 00:00:00로 하냐 vs 1월 1일 23:59:59로 하냐에 따라 트랜잭션 데이터와 결합 방식이 달라짐

            - 후자 방식이 훨씬 좋다: 1월 1일 15:00:00 에 발생한 이벤트를 전자랑 JOIN하려면 데이터가 없음

- 스냅샷 테이블은 나중에 다시 만들 수 없으므로, 영구적인 저장소에 보관하여 삭제되지 않도록 주의

- 스냅샷시 처음부터 비정규화된 것이 편함

이력 테이블 - 마스터 변화 기록하기

- 변경이 있을 대마다 그 내용 기록

- 데이터 양을 줄이는 데 도움이 되지만, 어느 순간의 완전한 마스터 테이블을 나중에 복원하는 것이 어려움

    - 디멘전 테이블로 사용하기 위해 별도의 처리를 통해 마스터 테이블로 복원해야 함

[마지막 단계] 디멘전을 추가하여 비정규화 테이블 완성시키기

- 팩트 테이블과 디멘전 테이블을 결합하여 비정규화 테이블 생성

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.

비정규화 테이블

다차원 모델

- 디멘전

- 측정값

모델의 정의 확장

다차원 모델의 정의는 나중에 확장할 수 있음 - 데이터 분석의 요구에 따라 비정규화 테이블에는 다수의 칼럼이 추가

브레이크 다운 분석(Breakdown Analysis): 전용의 디멘전을 팩트테이블에 추가하고 그룹명을 써 넣음 ->그룹별로 대시보드 작성 (필터링 활용)

머리말

- 이 책의 주제: '자동화된 데이터 처리'

    - 데이터 처리를 어떻게 시스템화 하는가

    - 소프트웨어, 데이터베이스, 프로그래밍 언어, 워크플로 관리, 스트림 처리 등 데이터 처리 자동화 기술

- 주요 독자: 데이터 취급 업무 종사자, 데이터 처리 시스템 개발자

- 다루지 않는 내용: 비즈니스 인텔리전스, 데이터 마이닝

- 구성

    1. 빅데이터 기초 지식: 역사적 배경 및 기본 용어 + 스몰 데이터 기술

    2. 빅데이터의 검색: 대화적인 집계와 시각화 + 데이터 마트

    3. 빅데이터의 분산 처리: Hadoop, Spark 등의 '분산 처리 프레임워크'

    4. 빅데이터의 축적: '데이터를 수집해서 보존하는' 절차 + 분산 스토리지, 데이터 수집(data ingestion)

    5. 빅데이터의 파이프라인: '데이터 처리 자동화하기' ('배치 처리', '스트림 처리') + 워크플로 관리

    6. 빅데이터 분석 기반의 구축: 응용 + Spark, Airflow, 클라우드 서비스

1-1. [배경] 빅데이터의 정착

분산 시스템에 의한 데이터 처리의 고속화

빅데이터 기술의 요구

- Hadoop: 다수의 컴퓨터에서 대량의 데이터 처리하기 위한 시스템

- NoSQL 데이터베이스: 빈번한 읽기/쓰기 및 분산 처리가 강점

- Hadoop과 NoSQL 데이터베이스의 조합: NoSQL 데이터베이스에 기록하고 Hadoop으로 분산 처리

분산 시스템의 비즈니스 이용 개척

- 가속도적으로 늘어나는 데이터의 처리는 Hadoop에 맡기고, 비교적 작은 데이터, 또는 중요한 데이터만을 데이터 웨어하우스에 넣는 식으로 사용

직접 할 수 있는 데이터 분석 폭 확대

- 클라우드를 통해 분산 처리에 필요한 자원을 확보할 수 있게 됨

- *스몰 데이터: 한 대의 노트북에서 큰 부담 없이 처리할 수 있는 만큼의 데이터 (수백만 ~ 수천만 건, GB 단위 데이터)

데이터 디스커버리의 기초지식

데이터 디스커버리: '셀프서비스용 BI 도구'

- BI 도구: 예전부터 데이터 웨어하우스와 조합되어 사용됨 (대기업의 IT 부서에 의해 도입)

-> 셀프서비스용 BI 도구는 이것을 개인도 도입할 수 있을 정도로 단순화 한 것

1-2. 빅데이터 시대의 데이터 분석 기반

빅데이터 기술이 기존 데이터 웨어하우스와 다른 점: 다수의 분산 시스템을 조합하여 확장성이 뛰어난 데이터 처리 구조를 만든다는 점

[재입문] 빅데이터 기술

데이터 파이프라인(data pipeline): 차례대로 전달해나가는 데이터로 구성된 시스템

- 어디에서 데이터를 수집하여 무엇을 실현하고 싶은지에 따라 변화

데이터 수집

- 데이터 전송(data transfer)의 두 가지 방법

    - 벌크형 (bulk)

    - 스트리밍형 (streaming)

스트림 처리와 배치 처리

- 실시간 데이터 처리와 장기적인 데이터 분석 결과를 하나의 시스템으로 실현하는 것은 쉽지 않음

분산 스토리지: 여러 컴퓨터와 디스크로 구성된 스토리지 시스템

- 객체 스토리지 (ex. Amazon S3)

- NoSQL 데이터베이스

분산 데이터 처리: 분산 스토리지 에 저장된 데이터를 처리하는 데에 필요한 프레임워크

- 빅데이터를 SQL로 집계하는 두 가지 방법

1. 쿼리 엔진 도입: ex. Hive, 대화형 쿼리 엔진

2. 데이터 웨어하우스 제품 이용: 분산 스토리지에서 추출한 데이터를 데이터 웨어하우스에 적합한 형식으로 변환해야 함

-> ETL

워크플로 관리

- 오류 발생 처리와 재실행 기능이 반드시 필요

데이터 웨어하우스와 데이터 마트

데이터 웨어하우스: RDB와 달리 대량의 데이터를 장기 보존하는 것에 최적화

- data source: RDB, 로그 파일 등

- ETL Process: data source에 보존된 raw data를 추출하고 필요에 따라 가공후 데이터 웨어하우스에 저장

데이터 마트: 데이터 웨어하우스에 시스템 부하를 줄이기 위해, 데이터 분석 등의 목적으로 필요한 데이터만 추출 후 구축

- BI 도구와 조합해 데이터를 시각화하는 데에도 사용

데이터 레이크

- 빅데이터 시대가 되면 ETL 프로세스 자체가 복잡해짐 (모든 데이터가 데이터 웨어하우스를 가정해 만들어지지는 않음)

- 우선 데이터가 있고, 나중에 테이블을 설계하는 것이 빅데이터

- 데이터 레이크: 미가공의 원시 데이터를 그대로 저장

데이터 레이크와 데이터 마트: 필요한 데이터는 데이터 마트에 정리

데이터 분석 기반을 단계적으로 발전시키기

가능한 작은 시스템에서 시작하여 나중에 단계적으로 확장해 나가는 것이 좋다

애드 혹 분석 및 대시보드 도구

애드 혹 분석: 수작업으로 데이터 추출 후 분석 - 데이터 마트를 만들지 않은 채 데이터 레이크와 데이터 웨어하우스에 직접 연결

- 사용자는 작업하기 쉬운 환경을 선호하기 때문에 대화형 분석 도구를 사용

- 대시보드 도구: 일부 대시보드 도구는 데이터 마트가 없어도 동작, 설정한 스케줄에 따라 데이터 레이크와 데이터 웨어하우스에 접속해 쿼리 실행하고 그래프 생성

데이터 마트와 워크플로 관리

데이터 분석이 복잡해지고 시각화에 BI 도구가 활용됨에 따라, 데이터 마트가 필수가 된다

- 데이터 마트 구축은 배치 처리로 자동화되는 경우가 많기 때문에 실행 관리를 위해 워크플로 관리 도구를 사용한다

- 데이터 처리를 자동화해서 장기적으로 운영해 나가기 위해서는 안정된 워크플로 관리가 필수적이다

- 데이터 파이프라인의 큰 흐름은 변하지 않는다

    1. 저장할 수 있는 데이터 용량에 제한이 없어야 함

    2. 데이터를 효율적으로 추출할 수단이 있어야 함

데이터를 수집하는 목적

데이터 검색

- 시스템 장애 원인 파악, 고객 문의 대응을 위한 로그 확인 등

- 시스템 로그, 고객 행동 로그 등 발생하는 모든 데이터를 ㅜ취득해 놓는다

- 신속한 대응을 위해  실시간 데이터 처리 및 검색 엔진 등이 필요할 수도

데이터의 가공

- 업무 시스템의 일부로 데이터 처리 결과를 이용하고 싶은 경우

- 목적이 명확하기 때문에, 필요한 데이터를 계획적으로 모아 데이터 파이프라인을 설계한다

- 꼼꼼한 테스트 반복적으로 실행한다

- 데이터 분석이라기보다는 시스템 개발 영역에 해당

데이터 시각화

- 앞으로의 상황을 예측해 의사 결정에 도움

- 데이터 분석 시스템은 원칙적으로 정보계 시스템

확증적 데이터 분석과 탐색적 데이터 분석

1-3. [속성 학습] 스크립트 언어에 의한 특별 분석과 데이터 프레임

- 스몰 데이터의 기술 잘 사용하기: 스몰 데이터에는 스몰 데이터 기술을 사용하는 것이 효율적이므로 무리하게 빅데이터 기술을 사용할 필요가 없다

1-4. BI 도구와 모니터링

스프레드시트에 의한 모니터링

데이터에 근거한 의사 결정

월간 보고서

스프레드 시트 장점: 수작업으로 숫자 입력하는 정도는 유연성 있음 -> 섣불리 시스템화 하면 나중에 손보는게 어려워짐

단점 1. 보고서에 입력하는 숫자를 어디선가 계산해야 함 - 이를 위해 준비된 것이 데이터 웨어하우스, 배치 처리, 워크플로 관리

단점 2. 상세한 내역을 조사하기 어려움 - 별도 BI 도구가 필요

변화를 파악하고 세부 사항 이해하기 - BI 도구의 활용

- BI 도구는 고속의 집계 엔진을 내장하고 있어 수백만 레코드 정도의 스몰 데이터라면 순식간에 그래프를 그려줌

모니터링의 기본 전략 및 BI 도구

- BI 도구는 자신이 직접 데이터를 살펴보기 위해서 필요

수작업과 자동화해야할 것의 경계 판별하기

- BI 도구를 활용하려면 베이스가 되는 데이터가 준비되어야 한다 (데이터 설계의 필요성)

수작업으로 할 수 있는 것은 수작업으로 해두기

- BI 도구를 위한 새로운 테이블을 설계부터 시작하기보다는 한 달에 한 번씩 수동으로 하는 것이 더 쉬울 것

자동화하려는 경우에는 데이터 마트를 만든다

가장 범용성이 높은 방법: 데이터 마트를 준비하고, 그것을 BI 도구로부터 열기

https://youtu.be/p0TdBqIt3fg?si=n9hl3KGaYCpm0Cm_

Summary

HDFS (Hadoop Distributed File System): Data storage

- Stores differenct formats of data on various machines

- 2 major components: Namenode(Master), Datanode(Slave)

- Splits the data into multiple blocks (128MB by default)

YARN (Yet Another Resource Negotiator): Cluster reource management

- Handles the cluster of nodes

- Allocates RAM, memory and other resources to differenct applications

- 2 major components: ResourceManager(Master), NodeManager(Slave)

MapReduce: Data Processing

- MapReduce processes large volumes of data in a parallelly distributed manner

Sqoop, Flume: Data collection and ingestion

- Sqoop is used to transfer data between Hadoop and external datastores such as relational databases and enterprise data warehouses

- Flume is distributed service for collecting, aggregating and moving large amounts of log data

Pig, Hive: Scripting and SQL

- Pig is used to analyze data in Hadoop. It provides a high level data processing language to perform numerous operations on the data

- Hive facilitates reading, writing and managing large datasets residing in the distributed storage using SQL (Hive Query Language)

    - 2 Major components: Hive Command Line, JDBC/ODBC driver

    - Provides User Defined Functions (UDF) for data mining, document indexing, log processing, etc.

Spark: Real time data analysis

- Spark is an open-source distributed computing engine for processing and analyzing huge volume of real time data (written in Scala)

- Runs 100x times faster than MapReduce

- Provides in-memory computation of data

- Used to process and analyze real time streaming data such as stock market and banking data

mahout: Machine Learning

- alternative: PySpark

Ambari: An Apache open-source tool responsible for keeping track of running applications and their statuses

Kafka, Storm: Streaming

- Kafka is a distributed streaming platform to store and process streams of records (written in Scala, Java)

    - Builds real-time streaming data pipelines that reliably get data between applications

    - Builds real-time streaming applications that transforms data into streams

    - Kafka uses a messaging system for transferring data from one application to another

- Storm is a processing engine that processes real-time streaming data at a very high speed (written in clojure)

    - Ability to process over a milion jobs in a fraction of seconds on a node

    - It is integrated with Hadoop to harness higher throughputs

Ranger, Knox: Security

Oozie: Workflow system

- Workflow scheduler system to manager Hadoop jobs

HDFS

reference

• https://nathanh.tistory.com/91

• How to submit Spark jobs to EMR cluster from Airflow

• Amazon EMR Deep Dive - 홍준혁 (AWS 월간 웨비나)

Reference

https://mungto.tistory.com/289

https://codechacha.com/ko/change-python-version/

서버를 생성하고, 로컬 노트북으로 접근하는 법

1. EC2 인스턴스 생성

2. 탄력적 IP 할당

1. 탄력적 IP 생성
2. 인스턴스에 탄력적 IP 할당

3. pair key 생성

4. ssh configuration 설정

5. VS Code 연결