Week_2

데이터/스터디

Week_2

stubborngastropod 2023. 2. 8. 17:30

728x90

빅데이터의 기초 지식

분산 시스템의 발전과 클라우드 서비스의 보급에 따라 대량의 데이터를 효율적으로 처리하는 일이 점차 어려워짐.

‘빅데이터’라는 단어가 퍼질 때까지의 역사

빅데이터의 정착

빅데이터 기술

데이터 처리에 분산 시스템(여러개의 컴퓨터를 이용한 시스템)을 도입한 후로 빅데이터가 대두됨

Hadoop: 다수의 컴퓨터에 방대한 데이터를 저장할 스토리지와 데이터를 순차적으로 처리할 수 있는 구조를 관리하기 위한 다수의 컴퓨터를 관리하는 프레임워크
Hive: 자바 언어로 동작하는 Hadoop에서 SQL과 같은 쿼리 언어를 실행하기 위한 소프트웨어 → 사용자 확대에 기여
NoSQL 데이터베이스: 전통적인 RDB의 제약을 제거하는 것을 목표로 등장. 빈번한 읽기/쓰기 및 분산 처리가 강점이며 KVS(Key-Value Store), Document store, Wide-column store 등이 대표적

Data warehouse가 Hadoop에 비해 뛰어난 점도 많지만, 분산 시스템의 발전에 따라 대량으로 발생하는 데이터를 Hadoop으로 처리함으로써 data warehouse의 부하를 줄이는 데에 이용됨

파일 단위의 스몰 데이터 기술은 데이터의 양이 적을 때 빅데이터 기술보다 효율적으로 쓰일 수 있으므로 적재적소에 구사할 수 있어야 함

Data Discovery: 셀프서비스용 BI 도구(경영자용 시각화 시스템)로, 대화형으로 데이터를 시각화하여 가치 있는 정보를 찾으려고 하는 프로세스

빅데이터 시대의 데이터 분석 기반

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

데이터 전송

벌크형: 이미 어딘가에 존재하는 데이터를 정리해 추출하는 방법
- 배치 처리: 장기적인 데이터 분석을 위해 대량의 데이터를 저장하고 처리하기에는 어느 정도 정리된 데이터를 효율적으로 가공하기 위한 배치 처리 구조가 적합
- 워크플로 관리를 통해 매일 정해진 시간에 배치 처리를 스케줄대로 실행하고 오류가 발생하는 경우 관리자에게 통지
스트리밍형: 실시간으로 생성되는 데이터를 끊임없이 계속해서 보내는 방법
- 스트림 처리: 모바일 애플리케이션 증가로 덩달아 늘어나는 스트리밍 데이터를 실시간으로 처리하기 위한 구조. 시계열 데이터 베이스 등 실시간 처리를 지향한 데이터베이스가 자주 사용됨

분산 데이터 처리

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

객체 스토리지: 한 덩어리로 모인 데이터에 이름을 부여해서 파일로 저장(ex. Amazon S3)
NoSQL 데이터베이스: 애플리케이션에서 많은 데이터를 읽고 쓰기에 좋음. 데이터 사용량을 얼마든지 늘릴 수 있도록 확장성이 높은 제품을 선택

빅데이터를 SQL로 집계하는 방법

쿼리 엔진: Hive, 대화형 쿼리 엔진 등으로 분산 스토리지 상의 데이터를 SQL로 집계
ETL 프로세스: 외부 데이터 웨어하우스 제품 이용을 위해 분산 스토리지에서 추출한 데이터를 변환하는 절차

데이터 저장소

데이터 소스: 업무 시스템을 위한 RDB나 로그 등을 저장하는 파일 서버, 원시 데이터 보존. ETL 프로세스를 거쳐 데이터 웨어하우스에 저장됨
데이터 웨어하우스: 일반적인 RDB와는 달리 대량의 데이터를 장기 보존하는 것에 최적화
데이터 마트: 데이터 분석과 같은 목적에 사용하는 경우 데이터 웨어하우스에서 필요한 데이터만을 추출하여 구축
데이터 레이크: 모든 데이터를 원래의 형태로 축적해두고 나중에 필요에 따라 가공하는 구조

데이터 분석 기반

데이터 엔지니어의 역할: 시스템의 구축 및 운용, 자동화 등을 담당(데이터 수집, ETL 프로세스, 분산 시스템, 워크플로 관리, 스크립트 언어, SQL, BI 도구 사용)

애드 혹 분석: 일회성 데이터 분석, SQL 쿼리를 직접 작성해서 실행하거나 스프레드시트에서 그래프를 만드는 등의 수작업
정기적으로 그래프 및 보고서를 만들 때 대시보드 도구를 도입해서 스케줄에 따라 쿼리를 실행하고 그래프 생성

데이터 수집의 목적

검색: 데이터 중 조건에 맞는 것을 찾는 것
가공: 업무 시스템의 일부로서 데이터 처리 결과를 이용하기 위해 변형하는 것
시각화: 데이터를 시각적으로 확인함으로써 정보를 얻기 위한 것

기간계 시스템: 비즈니스 근간에 관련된 중요한 시스템

정보계 시스템: 사내 커뮤니케이션 및 의사 결정을 위해 이용하는 시스템

→ 데이터는 기간계 시스템과 정보계 시스템을 연결

확증적 vs. 탐색적 데이터 분석

확증적 데이터 분석: 통계 분석 및 머신러닝 등을 사용해 가설을 세우고 검증하는 데이터 분석
탐색적 데이터 분석: 데이터를 시각화하여 그 의미를 읽어내려고 하는 데이터 분석

스크립트 언어에 의한 특별 분석과 데이터 프레임

—생략—

BI 도구와 모니터링

Tableau Public 등의 BI 도구를 이용해 데이터를 시각화할 수 있으며 직접 데이터를 살펴볼 수 있도록 해줌

BI 도구 사용 자동화 방법

BI 도구에서 직접 데이터 소스에 접속

장점: 시스템 구성이 간단

단점: BI 도구 측에서 지원하지 않는 데이터 소스에 접속 불가

데이터 마트를 준비하고 그것을 BI 도구로부터 열기

장점: 어떤 테이블이라도 자유롭게 만들 수 있음

단점: 데이터 마트의 설치 및 운영에 시간이 걸림

웹 방식의 BI 도구를 도입하여 CSV 파일을 업로드하기

장점: 스크립트로 자유롭게 데이터를 가공

단점: 데이터의 생성 및 업로드에 별도의 프로그래밍이 필요

빅데이터의 탐색

데이터를 시각화하는 환경을 정비함으로써 대량의 데이터를 효율적으로 탐색할 수 있도록 준비

크로스 집계의 기본

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

크로스 테이블: 행과 열이 교차하는 지점에 데이터가 들어가는 테이블
트랜잭션 테이블: 행 방향으로만 데이터가 증가하는 테이블, 크로스 집계 과정을 거쳐 크로스 테이블로 변환 가능
피벗 테이블: 소량의 데이터를 크로스 집계 하기 위한 기능
룩업 테이블: 트랜잭션 테이블을 다른 테이블과 결합하여 속성을 늘리는 기능

크로스 집계는 BI 도구, Pandas, SQL 등으로 가능.

SQL로 데이터를 집계하고 시각화 도구로 크로스 집계하는 과정을 거쳐 데이터를 시각화

데이터 집계 → 데이터 마트 → 시각화 과정에서 데이터 마트의 크기에 따라 시스템이 구성됨

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

데이터 처리의 지연

레이턴시가 적은 데이터베이스를 위한 선택

모든 데이터를 메모리에 올리는 것 → MySQL이나 PostgreSQL 등 RDB는 원래 지연이 적고 많은 수의 클라이언트를 처리하기 때문에 데이터 마트로 우수. 메모리가 부족하면 급격히 성능이 저하되는 단점
MPP 기술을 사용한 압축과 분산 → 대규모 병렬 처리(MPP;Massive Parallel Processing)는 멀티 코어를 활용하면서 디스크 I/O를 병렬 처리(ex. Amazon Redshift, Google BigQuery)

행/열 지향 데이터베이스 접근

Oracle Database, MySQL등 일반적인 RDB는 모두 레코드 단위의 읽고 쓰기에 최적화된 행 지향 데이터베이스. Teradata, Amazon Redshift 등 열 지향 데이터베이스는 칼럼 단위의 집계에 최적화

행 지향 데이터베이스

테이블의 각 행을 하나의 덩어리로 디스크에 저장. 새 레코드 추가 시 빠르게 추가가 가능하며 대량의 트랜잭션을 지연 없이 처리하기 위해 데이터 추가를 효율적으로 할 수 있도록 하는 것이 특징

데이터 검색의 고속화를 위해 인덱스가 사용되도록 튜닝하는 것이 중요하며 대량의 I/O를 동반하는 데이터 분석에는 부적합

열 지향 데이터베이스

데이터를 미리 칼럼 단위로 정리해 둠으로써 필요한 칼럼만을 로드하여 디스크 I/O를 줄일 수 있음

데이터의 압축 효율이 우수하여 압축되지 않은 행 지향 데이터베이스와 비교하면 10% 수준으로 압축 가능

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

행 지향 데이터베이스도 여러 개의 스레드를 활용해 많은 쿼리를 동시에 실행할 수 있지만 개별 쿼리가 분산 처리되지는 않음. 열 지향 데이터베이스는 대량의 데이터를 읽기 때문에 쿼리 실행 시간이 길어지고 압축된 데이터 전개를 위한 CPU 리소스가 필요하므로 멀티코어를 활용한 고속화 필요

MPP → 하나의 쿼리를 다수의 태스크로 분해하고 가능한 한 병렬로 실행

경우에 따라 편리성을 위해(ex. Hadoop과의 궁합) MPP 대신 대화형 쿼리 엔진을 사용하기도 함

애드 혹 분석과 시각화 도구

애드 혹 분석 도구

Jupyter Notebook: 오픈소스 대화형 도구
matplotlib: 시각화 라이브러리

대시보드 도구

Redash: SQL에 의한 쿼리의 실행 결과를 그대로 시각화(파이썬)

하나의 쿼리가 하나 또는 여러 그래프에 대응하며 마지막으로 실행된 집계 결과만을 표시하기 때문에 SQL로 쿼리를 작성해 시각화하기 위한 콘솔로 우수. BI 도구만큼 대량의 데이터를 처리할 수는 없음

Superset: 화면 상에서 마우스 조작만으로 그래프를 만드는 도구(파이썬)

내장 스토리지가 없어 데이터 집계는 외부 데이터 저장소에 의존. 열 지향 스토리지인 Druid 제공. 집계 시 데이터를 결합할 수 없기 때문에 시각화에 필요한 데이터는 미리 결합해 데이터 마트를 형성해야 함

Kibana: Elasticsearch의 프론트엔드에서 실시간 대시보드를 작성(자바스크립트)

Elasticsearch 외의 데이터 소스에 대응하지 않기 때문에 시각화하려는 데이터는 모두 Elasticsearch에 저장해야 하며 전체 텍스트 검색에 대응한 데이터 스토어이므로 키워드로 텍스트 데이터를 검색하는 것에 특화

BI 도구

장기적인 데이터 추이 시각화, 집계 조건을 세부적으로 바꿀 수 있는 대시보드 작성

하나의 테이블에서 다수의 대시보드를 작성함으로써 대량 쿼리 실행이 반복되지 않고 배치 처리의 부하가 안정됨

데이터 마트의 기본 구조

OLAP

On-Line Analytical Processing. 데이터 집계를 효율화하는 접근 방법 중 하나로 다차원 모델의 데이터 구조를 MDX(Multi-Dimensional Expressions) 등의 쿼리 언어로 집계

OLAP 큐브: 데이터 분석을 위해 만들어진 다차원 데이터 → OLAP로 크로스 집계

테이블 비정규화

시각화에 적합한 데이터 마트 작성 == BI 도구를 위한 비정규화 테이블 작성

트랜잭션: 시간과 함께 생성되는 데이터를 기록한 것
마스터: 트랜잭션에서 참고되는 각종 정보

팩트 테이블 & 디멘션 테이블

팩트 테이블: 트랜잭션처럼 사실이 기록된 것(실제 수치)
디멘션 테이블: 팩트 테이블에서 참고되는 마스터 데이터 등(데이터 분류를 위한 속성값)

비정규화

스타 스키마: 팩트 테이블을 중심으로 여러 디멘션 테이블을 결합한 것

→ 분해된 테이블을 최대한 결합하여 하나의 테이블로 결합하는 비정규화 과정을 거침 → RDB에서의 정규화와 반대 개념

단순하기 때문에 이해하기 쉽고 데이터 분석을 용이하게 함

펙트 테이블을 최대한 작게 하고 나머지 데이터는 디멘션 테이블로 옮김으로써 고속화에 기여

열 지향 데이터베이스의 도입으로 디스크 I/O 증가가 억제된 상황에서 스타 스키마에서 추가로 비정규화가 이루어진 비정규화 테이블로 데이터 마트를 작성

다차원 모델

테이블 및 칼럼의 집합을 알기 쉽도록 비정규화 테이블을 추상화하여 다차원 모델 작성

칼럼을 디멘션과 측정값으로 분류

브레이크 다운 분석: 데이터를 몇 개의 그룹으로 분산하여 각 그룹에 내용을 정리. 각 레코드의 출처를 알기 쉽고 누락되는 레코드가 없도록 함

빅데이터의 분산 처리

대규모 분산 처리의 프레임워크

구조화 데이터: 스키마가 명확하게 정의된 데이터, 기존의 데이터 웨어하우스에서 일반적으로 축적하는 방식
비구조화 데이터: 자연어로 작성된 텍스트, 이미지, 영상 등의 미디어 데이터 포함. 이를 분산 스토리지 등에 저장하고 분산 시스템에서 처리하는 것이 데이터 레이크 개념
스키마리스 데이터: 서식은 정해져 있지만 칼럼 수나 데이터형은 명확하지 않은 데이터(CSV, JSON, XML 등)

데이터 구조화 파이프라인

데이터 소스에서 수집된 비구조화, 스키마리스 데이터는 분산 스토리지에 보존되고 집계를 위해 이를 구조화 데이터로 변환할 필요가 있음 → 테이블 형식으로 열 지향 스토리지에 장기 보존

비구조화 데이터를 열 지향 스토리지로 변환하는 과정에서 사용되는 것이 Hadoop과 Spark

Hadoop

대규모 분산 시스템을 구축하기 위해 다수의 소프트웨어로 이루어진 공통 플랫폼

HDFS(분산 파일 시스템): Hadoop에서 처리되는 데이터의 대부분이 저장됨. 네트워크에 연결된 파일 서버와 같지만 다수 컴퓨터에 파일을 복사하여 중복성을 높이는 특징
YARN(리소스 관리자): CPU나 메모리 등 계산 리소스 관리. CPU 코어와 메모리를 컨테이너 단위로 관리하며 Hadoop에서 분산 애플리케이션 실행 시 클러스터 전체의 부하에 따라 호스트에 컨테이너 할당
MapReduce(분산 데이터 처리 기반): YARN 상에서 동작하는 분산 애플리케이션 중 하나로 분산 시스템에서 데이터 처리를 실행하는 데 사용, 임의의 자바 프로그램을 실행시킬 수 있으므로 비구조화 데이터 가공에 적합
Hive(쿼리 엔진): 쿼리를 자동으로 MapReduce 프로그램으로 변환, MapReduce와 같이 배치 처리에는 적합하나 애드 혹 쿼리 실행에는 부적합
Tez: MapReduce를 대체하기 위한 데이터 처리 기반. 스테이지의 종료를 기다리지 않고 처리가 끝난 데이터를 차례대로 후속 처리에 전달함으로써 쿼리 실행 시간 단축
Impala / Presto: 대화형의 쿼리 실행만 전문으로 하는 쿼리 엔진. 순간 최대 속도를 높이기 위해 사용할 수 있는 리소스를 최대한 활용하여 쿼리 실행
Spark: 메모리의 발전으로 디스크에 기록하는 것 대신 인 메모리 형의 고속 데이터 처리 방식을 채택, 고속화를 실현하여 MapReduce를 대체하고자 함

쿼리 엔진

구조화 데이터 작성(Hive)

분산 스토리지에 저장된 데이터 구조화 및 열 지향 스토리지 형식으로 저장 → 텍스트 파일 가공으로 부하가 크기 때문에 Hive 이용

Hive에서 만든 테이블 정보는 Hive Metastore에 저장

서브 쿼리 안에서 레코드의 수를 줄여 초기 단계의 팩트 테이블을 최대한 축소

중복 제거 및 테이블 결합, 정렬 등으로 데이터의 편향을 고려

구조화 데이터 집계(Presto)

구조화 데이터를 결합, 집계하여 비정규화 테이블로 데이터 마트에 내보냄 → 실행 시간 단축을 위해 Presto 사용

Presto는 전용 스토리지가 없기 때문에 데이터 소스에서 데이터를 직접 읽어들임 → Hive metastore, 분산 스토리지 상의 팩트 테이블과 MySQL 마스터 테이블 JOIN, Cassandra에 저장된 데이터 집계 등 다양하게 이용

쿼리 실행에 있어 인메모리 처리를 채택하여 고속화 하고 같은 키를 갖는 데이터를 동일한 노드에 모으는 분산 결합과 결합하는 테이블의 모든 데이터를 각 노드에 복사하는 브로드캐스트 결합 사용

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

MPP 데이터베이스: 시각화를 위한 데이터 마트로서 완성된 비정규화 테이블의 고속 집계에 적합
Hive: 높은 확장성과 내결함성을 목표로 설계, 데이터 양에 좌우되지 않는 쿼리 엔진
Presto: 단시간에 리소스를 많이 사용해 속도가 빠르고 SQL로 모든 데이터를 집계할 수 있음
Spark: 데이터 구조화와 SQL을 이용한 집계가 가능한 분산 시스템 기반 프로그래밍 환경

데이터 마트의 구축

팩트 테이블

추가: 새로 도착한 데이터만을 증분으로 추가

→ 테이블 파티셔닝: 추가의 잠재적 문제를 해결하기 위해 하나의 테이블을 여러 물리적인 파티션으로 나눔으로써 파티션 단위로 데이터를 쓰거나 삭제할 수 있도록 한 것

치환: 과거의 데이터를 포함해 테이블 전체를 치환

→ 중복 및 누락의 위험이 줄어들지만 처리 시간이 오래 걸리는 단점

집계 테이블

팩트 테이블을 모아서 집계한 것

카디널리티: 각 칼럼이 취하는 값의 범위. 카디널리티를 줄임(ex. 위치 정보를 국가나 지역으로 변환)으로써 레코드 수를 줄일 수 있지만 정보의 손실을 고려해 적절한 균형을 찾아야 함

스냅샷 테이블

마스터 데이터와 같이 업데이트 가능성이 있는 테이블에 대해 정기적으로 테이블을 통째로 저장하는 방법

다른 팩트 테이블과 결합함으로써 디멘션 테이블로도 사용 가능

이력 테이블

변경된 데이터만을 증분으로 스냅샷하거나 변경이 있을 때마다 내용을 기록

데이터의 양을 줄일 수 있지만 특정 시점의 마스터 테이블의 완전 복원이 어려움

빅데이터의 축적

벌크 형과 스트리밍 형의 데이터 수집

빅데이터는 대부분 분산 스토리지에 저장되며 Hadoop은 HDFS, 클라우드 서비스는 Amazon S3 등의 객체 스토리지를 이용해 다수의 컴퓨터를 사용하여 파일을 여러 디스크에 복사함으로써 데이터의 중복화 및 부하 분산을 실현

데이터 수집

처리를 용이하게 하기 위해 수집한 데이터를 적절한 크기로 가공하여 분산 스토리지를 만드는 과정

벌크 형의 데이터 전송

과거에 축적된 대량의 데이터가 이미 있는 경우나 기존의 데이터베이스에서 데이터를 추출하고 싶을 경우에 벌크 형의 데이터 전송을 사용

데이터베이스나 웹 서비스 등으로부터 수집한 데이터를 추출하여 표준 포맷으로 변환 후 분산 스토리지에 저장하는 ETL 서버 이용

많은 데이터양으로 태스크 실행이 커지지 않도록 작은 태스크로 분해하는 과정에서 워크플로 관리도구가 이용됨

스트리밍 형의 데이터 전송

다수의 클라이언트에서 계속해서 작은 데이터가 전송되는 메시지 배송

메시지 저장 방식
- 작은 데이터 쓰기에 적합한 NoSQL 데이터베이스를 Hive와 같은 쿼리 엔진으로 연결해 이용
- 메시지 큐와 메시지 브로커 등의 중계 시스템에 전송
웹 브라우저에서의 메시지 배송
- 웹 서버 내에서 메시지를 만들어 배송 → Fluentd나 Logstash와 같은 서버 상주형 로그 수집 소프트웨어 사용
- 자바스크립트를 사용하여 웹 브라우저에서 직접 메시지를 전송 → 웹 이벤트 추적
모바일 앱으로부터의 메시지 배송
- 서버를 직접 마련하지 않고 MBaaS라는 백엔드 서비스 이용, 백엔드 데이터 저장소에 저장한 데이터를 벌크형 도구를 사용해 꺼내는 방법
- 모바일 앱에 특화된 액세스 해석 서비스를 통해 이벤트 데이터를 수집하는 방법
디바이스로부터의 메시지 배송
- TCP/IP를 사용하여 데이터를 전송하는 MQTT → 일반적으로 전달과 구독 형 메시지 배송 구조를 지님
- 메시지를 송수신하기 위한 토픽을 생성하고 MQTT 브로커를 통해 메시지의 교환을 중계하여 MQTT 구독자가 메시지를 수신

메시지 배송의 트레이드 오프

메시지 브로커: 분산 스토리지에 직접 메시지를 기록하면 부하 제어가 어려워 성능 한계에 도달하기 쉽기 때문에 일시적으로 데이터를 축적함으로써 분산 스토리지에 쓰는 속도를 안정화(ex. Apache Kafka, Amazon Kinesis)
푸쉬형/풀형 방식
- 푸쉬형: 송신 측의 제어로 데이터를 보내는 방식
- 풀형: 수신 측의 주도로 데이터를 가져오는 것
→ 메시지 브로커는 데이터의 조정하기 위해 푸쉬형에서 풀형으로 메시지 배송의 타이밍을 변환하여 적당히 모아진 데이터를 분산 스토리지에 기록
스트림 처리: 프런트엔드에서 메시지 브로커에 데이터를 푸쉬하도록 하고 짧은 간격으로 차례대로 데이터를 꺼내서 처리하는 것
메시지 라우팅: 메시지 브로커의 데이터를 복수의 다른 소비자에서 읽어들여 메시지를 복사 후 데이터를 여러 경로로 분기시키는 것

신뢰성

신뢰성 문제를 보장하기 위한 세 가지 설계 방식

at most once

중복을 방지하기 위해 메시지는 한 번만 전송, 데이터 결손 발생의 위험

exactly once

송수신 측이 코디네이터를 통해 정보를 전달, 코디네이터가 없는 경우나 시간 지연

at least once

메시지가 확실히 전달되나 중복의 가능성, 사용자가 직접 중복을 제거

중복 제거

오프셋 이용 중복 제거

각 메시지에 파일 내 시작 위치인 오프셋을 덧붙여 중복 제거, 벌크형에 적합

고유 ID에 의한 중복 제거

각 메시지에 고유 ID인 UUID 등을 지정

종단간 신뢰성

중복 제거는 클라이언트가 생성할 때와 분산 스토리지에 기록할 때, 종단 간에 실행해야 함

고유 ID 사용 중복 제거
- NoSQL 데이터베이스 사용
- SQL로 중복 제거

데이터 수집 파이프라인

클라이언트로부터 도착한 메시지를 프런트엔드가 수신해 메시지 브로커에게 전달하고 소비자가 정기적으로 파일을 생성하면 중복을 제거하고 열 지향 스토리지로 전환하여 분산 스토리지에 저장.

빅데이터 시스템에 있어 스트리밍 데이터 등의 중복은 큰 문제가 되지 않으므로 멱등한 조작에 유의해 시스템을 설계, 오차가 허용되지 않는 데이터에 대해서는 트랜잭션 처리를 지원하는 데이터베이스에 애플리케이션이 직접 기

시계열 데이터의 최적화

다수의 파일을 모두 검색하는 풀 스캔을 피하기 위해 서버가 처리하는 시간인 프로세스 시간과 다르게 데이터가 생성된 이벤트 시간에 의한 집계의 효율화를 추구

시계열 인덱스

이벤트 시간에 대해 인덱스를 만드는 것, 장기간에 걸친 대량의 데이터 집계에는 효율적이지 않음

조건절 푸쉬다운

칼럼 단위의 통계 정보를 이용해 열 지향 스토리지에서 최소한의 데이터만을 읽도록 하는 최적화

이벤트 시간에 의한 분할

열 지향 스토리지로부터 시계열 테이블을 이용해 데이터를 집계 시 대량의 작은 파일이 생성되어 쿼리 성능이 악화 → 수집 단계에서는 프로세스 시간만을 사용해 저장, 데이터 마트가 이벤트 시간에 의한 정렬을 담당하도록 함

비구조화 데이터의 분산 스토리지

객체 스토리지는 임의의 파일을 저장할 수 있지만 파일 교체가 어렵고 저장된 데이터를 집계할 수 있게 되기까지 시간이 오래 걸림 → 특정 용도에 최적화된 NoSQL 데이터베이스 사용

분산 KVS

모든 데이터를 키값 쌍으로 저장하도록 설계된 데이터 저장소. 모든 데이터에 고유의 키를 지정하여 부하 분산을 위해 이용

Amazon DynamoDB

안정된 읽기 쓰기 성능을 제공하도록 디자인된 분산형 NoSQL 데이터베이스, 하나 또의 두 개의 키에 연결하는 형태로 임의의 스키마리스 데이터를 저장.

P2P 형의 분산 아키텍처를 가지며 미리 설정한 초 단위의 요청 수에 따라 노드가 증감

와이드 칼럼 스토어

분산 KVS를 발전시켜 2개 이상의 임의의 키에 데이터를 저장할 수 있도록 한 것. 행 키와 칼럼 명의 조합에 대해 값을 저장하고 새로운 행과 열을 추가할 수 있음

Apache Cassandra

내부적인 데이터 저장소로 와이드 칼럼 스토어를 이용하면서도 CQL이라는 높은 수준의 쿼리 언어를 구현. 스키마를 결정할 필요가 있기 때문에 구조화 데이터만을 취급할 수 있고 P2P형의 분산 아키텍처를 가짐.

도큐먼트 스토어

성능 향상보다 데이터 처리의 유연성을 목적으로 함. 복잡하게 뒤얽힌 스키마리스 데이트를 그대로의 형태로 저장하고 쿼리를 실행할 수 있도록 함. 스키마를 정하지 않고 데이터 처리를 할 수 있으며 외부 데이터를 저장하는 데 특히 적합

MongoDB

오픈 소스 분산형 도큐먼트 스토어로 자바스크립트나 각종 언어를 사용해 데이터를 읽고 쓸 수 있음. 성능이 뛰어나고 간편한 반면 신뢰성이 낮은 특징

검색 엔진

텍스트 데이터 및 스키마리스 데이터를 집계하는 데 자주 사용. 역 색인을 통해 적극적으로 색인을 만들어 데이터를 찾고 집계하는 데 특화되어 있으며 민첩성이 요구되는 분야에서 최근의 데이터를 보기 위해 사용

Elasticsearch

아무것도 지정하지 않으면 모든 필드에 색인이 만들어지기 때문에 간단한 도큐먼트 스토어에 비해 쓰기 부하가 큼

자체 쿼리 언어에 의한 고급 집계 기능 제공

Splunk

비정형 데이터에 특화. 검색을 실행할 때 텍스트에서 필드가 추출되며 다양한 테이블을 만들어낼 수 있고 파이프라인을 사용해 데이터를 순차적으로 가공. 대화형 쿼리를 이용해 데이터 추출에서 분석 및 시각화까지의 단계를 하나의 화면에서 실행할 수 있으므로 텍스트 데이터를 신속하게 애드 혹 분석할 때 유용

빅데이터의 파이프라인

워크플로 관리

워크플로 관리 도구의 주 역할

정기적으로 태스크를 실행하고 비정상적인 상태를 감지하여 그것에 대한 해결을 돕는 것

태스크: 데이터 파이프라인이 실행되며 정해진 처리가 반복해서 수행되는 개별 처리 단위
워크플로 관리 도구의 종류
- 선언형: XML이나 YAML 등의 서식으로 워크플로를 기술, 최소한의 기술로 태스크를 정의할 수 있어 유지 보수성이 높아짐
- 스크립트형: 스크립트 언어로 워크플로를 정의, 태스크의 정의를 프로그래밍할 수 있으며 데이터 처리를 태스크 안에서 실행하는 것도 가능
오류 복구 방법

기본적으로 워크플로 관리에서는 수작업에 의한 복구를 전제한 태스크 설계

여러 번 발생하는 오류에 대해 자동화하여 수작업 없이 복구하는 태스크 단위의 자동적인 재시도, 플로우 전체를 처음부터 다시 실행하는 백필 등의 방법

멱등한 조작

원자성 조작: 각 태스크가 시스템에 변경을 가하는 것을 한 번만 할 수 있도록 하는 것

→ 원자성을 지닌 추가: 같은 테이블에 데이터를 여러 번 입력할 때 추가를 반복하는 것이 아니라 중간 테이블을 만들어 처리한 후 마지막에 목적 테이블에 한 번에 추

멱등한 조작: 동일한 태스크를 여러 번 실행해도 동일한 결과가 되도록 하는 것

→ 멱등한 추가: 테이블을 일정 주기마다 파티션으로 분할하고 파티션 단위로 치환되도록 하는 것

태스크 큐

워크플로 관리 도구의 역할 → 외부 시스템 부하 컨트롤

병렬화: 각 태스크는 파일 서버로부터 파일을 추출해 압축하고 분산 스토리지로 전송
태스크 큐: 모든 태스크가 큐에 저장되고 일정 수의 워커 프로세스가 그것을 순서대로 꺼내면서 병렬화 실현

CPU, 메모리, 네트워크 등 자원의 한계로 인해 병목 현상이 발생할 수 있음, 태스크 수를 목적에 맞게 적절히 잘 분할해야

배치 형의 데이터 플로우

MapReduce: 분할된 데이터를 Map하고 그 결과를 모아서 집계하는 Reduce 과정을 여러 번 반복

→ 지연이 적은 집계 방식 설계의 필요로 대부분 DAG를 도입한 프레임워크 등장

DAG: 방향성 비순환 그래프, 노드간 화살표로 연결되는 방향성, 동일 노드로 되돌아오지 않는 비순환 특징을 지님

데이터 플로우 + 워크플로

데이터 플로우로부터 읽어 들일 데이터는 성능적으로 안정된 분산 스토리지에 배치, 이 과정에서 오류의 발생에 대해 확실하게 대처하여 복사를 끝낼 수 있도록 태스크 실행에는 워크플로 관리 도구 사용. 이후 데이터 가공 등 부하가 큰 처리를 데이터 플로우로 실행. 이후 취급하기 쉬운 파일 형식으로 변환하여 분산 스토리지에 보관하고 워크플로가 외부 시스템에 데이터 전송

데이터 플로우 + SQL

데이터 웨어하우스 구축

데이터 플로우가 비구조화 데이터를 가공해 CSV 파일 등을 만들어 분산 스토리지에 써넣으면 워크플로가 태스크 실행이나 SQL에 의한 쿼리 실행

데이터 마트 구축

데이터 플로우가 분산 스토리지 상의 데이터를 매일 반복되는 배치로 가공하여 열 지향의 스토리지 형식으로 보관, 워크플로가 쿼리 엔진을 사용한 SQL 실행이나 그 결과를 데이터 마트에 내보냄

대화식 플로우

비구조화 데이터를 애드 혹으로 분석하기 위해 데이터 플로우 사용

스트리밍 형의 데이터 플로우

배치 처리는 실행 시 데이터 양이 정해지는 유한 데이터, 스트림 처리는 제한 없이 데이터가 보내지는 무한 데이터를 다룸. 그러나 데이터를 분할에서 DAG에서 실행한다는 점에서 같으므로 DAG를 사용한 데이터 플로우에서는 배치/스트림 처리를 동일하게 프로그래밍 할 수 있음

람다 아키텍처

배치 레이어: 과거의 데이터를 장기적인 스토리지에 축적하고 다시 집계할 수 있게 함
서빙 레이어: 배치 처리 결과에 접근해 응답에 빠른 데이터베이스로 집계 결과인 배치 뷰를 추출
스피드 레이어: 배치 뷰 업데이트 이전까지 실시간 뷰를 추출

→ 배치 뷰와 실시간 뷰 모두를 조합시키는 형태로 쿼리를 실행

카파 아키텍처

같은 처리를 구현하는 스피드 레이어와 배치 레이어의 개발 효율을 커버하기 위해 스피드 레이어만을 남기고 메시지 브로커의 데이터 보관 기간을 충분히 길게 함

아웃 오브 오더의 데이터 문제

프로세스 시간과 이벤트 시간의 차이로 스트림 처리의 문제점 발생

원래 데이터를 이용한 올바른 집계를 위해 이벤트 시간이 보존되어야 함

이벤트 시간 윈도윙: 이벤트 시간을 기준으로 일정 시간 간격으로 윈도우를 나누는 것

빅데이터 분석 기반의 구축

스키마리스 데이터의 애드 혹 분석

-생략-

Hadoop에 의한 데이터 파이프라인

-생략-

워크플로 관리 도구에 의한 자동화

-생략-

클라우드 서비스에 의한 데이터 파이프라인

AWS

Amazon EMR을 기점으로 빅데이터 분야에 예전부터 이용된 클라우드 서비스

Redshift: 데이터 웨어하우스를 위한 MPP 데이터베이스. 스토리지와 계산 노드가 일체화되어 보존할 데이터 양에 따라 노드를 확장할 필요가 있음
Amazon S3: Redshift Spectrum 기능을 이용해 Redshift에서 S3 상의 파일을 직접 편집 가능

서비스가 기능별로 세세하게 나누어져 있어 조합의 자유도가 높지만 복잡하다는 단점이 있음

구글 클라우드 플랫폼

GCP는 구글의 소프트웨어와 기본시설을 활용해 대규모 데이터 처리를 실행할 수 있음

Big Query: 풀 매니지드 형의 데이터 웨어하우스 서버, 분산 스토리지와 쿼리 엔진이 분리된 아키텍처
Google Cloud Dataflow & Google Cloud Datalab: 데이터 플로우 방식과 노트북을 서비스화. Spark나 주피터에 해당하는 서비스를 같은 데이터 센터에서 실행함으로써 고속 네트워크로 연결된 데이터 분석 환경의 구축 가능

트레주어 데이터

처음부터 모든 서비스가 포함된 상태로 제공. 다수의 외부 시스템과의 연계가 통합되어 있어 외부 데이터를 가져와 외부에 출력함으로써 보다 큰 데이터 파이프라인 구축 가능. 풀 매니지드 형의 서비스로 사용자가 시스템 구성을 의식할 필요 없이 데이터 파이프라인을 관리 화면 및 API로 조작

Digdag: 선언형 워크플로 관리 도구. YAML의 표기법을 사용해 태스크 정의. 사용자가 직접 워크플로 서버를 유지 관리할 필요 없이 데이터 파이프라인의 전체를 클라우드화 가능

728x90