1. 워크 플로우 관리

기초 지식

1. 워크 플로우 관리 도구

   워크 플로우 관리 도구의 주요 역할은, 정기적으로 태스크를 실행하고 비정상적인 상태를 감지하여 해결을 돕는 것이다.

   ex) Airflow, Azkaban, Digdag, Luigi, Oozie

2. 태스크

   데이터 파이프라인의 실행 과정에서 데이터를 잇달아 이동하면서 정해진 처리를 반복하는데, 이때 실행되는 개별 처리이다.

3. 기본 기능

   • 테스크를 정기적인 스케쥴로 실행하고 결과 통지

   • 테스크 간의 의존 관계를 정하고 순서대로 빠지없이 실행

   • 테스크의 실행 결과를 보관하고, 오류 발생하면 재실행 할 수 있도록 하기

4. 선언 형과 스크립트 형

   • 선언형 : XML 이나 YAML 등의 서식으로 워크플로우 기술
   • 스크립트형 : 스크립트 언어로 워크플로우 정의

오류로부터 복구 방법

모든 오류를 사전에 예상하는 것은 불가능하기 때문에, 오류 발생 가능성을 고려하여 대처 방법을 결정해야한다.

1. Retry

   재시도를 반복해도 문제가 없는 태스크라면, 1회나 2회의 재시도를 실행해도 좋다.

   그러나, 그 이상은 재시도가 아니라 올바른 문제 해결 방법을 찾아야한다.

2. Backfill

   플로우 전체를 처음부터 다시 실행한다. 다음 상황에 사용한다.

   • 태스크의 실패가 며칠 동안이나 계속된 후에 이를 모아서 재시도 하고 싶을 때
   • 새롭게 만든 워크 플로우를 과거로 거슬라 올라가 실행하고 싶을 때

재실행의 안정성을 위한 두가지 방법

1. 원자성 조작 (Atomic Operation)

   예를 들어, INSERT 문 2회를 호출하는 태스크가 있다고 하자.

   첫 번째의 INSERT 가 종료되고 오류가 발생하면 태스크를 재실행하면 동일한 데이터가 다시 쓰이게 될 수 있다.

   이 문제를 회피하기 위해, 각 태스크가 시스템에 변경을 가하는 것을 한 번만 할 수 있도록 하는 것이다.

   쓰기가 필요한 수 만큼 테스크를 나누는 것이다.

   하지만, 태스크 구현상의 버그 등으로 원자성 조작 직후에 문제가 발생하면 원자성 조작 자체는 성공했어도 워크 플로우 관리 도구에서는 오류로 여길 수 있다.

2. 멱등한 조작

   더 확실한 방법은, 동일한 태스크를 여러 번 실행해도 동일한 결과가 되도록 하는 것이다.

   예를 들어 분산 스토리지에 파일을 업로드할 때,

   • 매번 새로운 파일명을 만들 경우 데이터를 추가 (append) 하는 것이고,
   • 동일 파일명으로 덮어쓰면 치환 (replace)하는 것이다. 치환은 반복해도 결과가 변하지 않으므로 멱등하다.

데이터 추가

1. 멱등한 추가

   과거의 모든 데이터를 치환하면 멱등하지만 부하가 커진다. 그래서, Table Partitioning 이 필요하다.

   예를 들면 테이블을 1일마다 또는 1시간 마다 파티션으로 분할하고 파티션 단위로 치환하는 것이다.

   파티션의 모든 데이터를 삭제할 때, TRUNCATE 문이나 INSESRT OVERWRITER 문 등을 사용할 수 있다.

   ex) Hive 는 파티셔닝 지원, Amazon Redshift 는 파티셔닝을 지원하지 않아 UNION ALL 사용

2. 원자성을 지닌 추가

   하나의 테이블에 여러번 데이터를 써넣는 경우, 중간 테이블을 이용해 마지막에 목적 테이블에 한 번 추가한다.

   즉, 전반 부분에서는 중간 테이블을 만들기 위해 테이블을 치환하므로 멱등하다.

   그러나 마지막에 INSESRT 는 단순히 추가이므로 전체로서는 멱등하지 않다.

   단, 마지막에 쓰기를 1회만 실시하므로 이것은 원자성을 지닌 조작이다.

   그래서 플로우가 실패해도 아무것도 쓰이지 않아 실패한 태스크를 재실행해도 복구가 완료된다.

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

데이터 수집 방법으로 두 가지 방법이 있다.
이 챕터에서는 각각의 방법으로, 분산 스토리지에 데이터가 저장되기까지의 흐름을 정리한다.

1. 벌크 형
2. 스트리밍 형

객체 스토리지와 데이터 수집

빅데이터는 확장성이 높은 분산 스토리지에 저장된다. 분산 스토리지로,

1. 분산형 데이터베이스

2. 객체 스토리지
   객체 스토리지는 다수의 컴퓨터를 사용해 파일을 여러 디스크에 복사해서 데이터 중복화 및 부하 분산을 실현한다.
   객체 스토리지의 구조는 데이터 양이 많을 때는 우수하지만, 소량의 데이터에 대해서는 비효율적이다.
   하둡의 HDFS, 클라우드 서비스의 Amazon S3 가 대표적이다.

데이터 수집

데이터 수집이란, 수집한 데이터를 가공해 집계 효율이 좋은 분산 스토리지를 만드는 일련의 프로세스이다.
작은 데이터는 적당히 모아서 하나의 큰 파일로 만들어 효율을 높이는데 도움이 된다.
파일이 지나치게 크면, 네트워크 전송 시간이 오래 걸려 오류 발생률이 높다.

벌크 형 데이터 전송

1.빅데이터의 정착

빅데이터 기술의 요구 : Hadoop 과 NoSQL 의 대두

세계 곳곳에서 엑세스 되는 시스템 증가로, 전통적인 관계형 데이터베이스로는 취급 할 수 없는 데이터가 쌓이게 되었다.
그래서 다른 구조가 필요했다.

1. Hadoop
   다수의 컴퓨터에서 대량의 데이터 처리

2. NoSQL Database
   빈번한 읽기/ 쓰기 및 분산처리가 강점

분산 시스템의 비즈니스 이용 개척 : 데이터 웨어하우스와의 공존

위 그림처럼, 확장성이 뛰어난 Hadoop 에 데이터 처리를 맡겨 데이터 웨어하우스의 부하를 줄이고 있다.

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

‘여러 컴퓨터에서 분산 처리한다’ 는 빅데이터의 특징으로 하드웨어를 준비하고 관리하는게 어려웠다.
하지만, 클라우드 시대에서는 필요한 자원 확보가 쉬워서 얼마든지 빅데이터를 이용할 수 있다.

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

1. 크로스 집계

크로스 집계

1. 크로스 테이블
   행과 열이 교차하는 부분에 숫자 데이터가 들어감

2. 트랜젝션 테이블
   행방향으로만 증가하고, 열방향으로는 데이터가 증가하지 않음

3. 크로스 집계
   트레젝션 테이블에서 크로스 테이블로 변환하는 과정.
   피봇 테이블을 이용해서 할 수 있다.

룩업 테이블

트랜젝션 테이블의 ‘상품 ID’ 를 사용해서 ‘상품명’ 과 ‘상품 카테고리’ 참고할 때 사용되는 것이, 룩업 테이블이다.
상품 정보를 하나의 테이블로 정리해두면 나중에 속성을 추가하거나 변경하는 것도 간단하다.

2. 열 지향 스토리지

처리량과 지연 시간

1. 처리량 ( throughput )
   일정 시간에 처리할 수 있는 데이터의 양.
   배치 처리 등 대규모 데이터 처리에서 중요시.

2. 지연 ( latency )
   데이터 처리가 끝날 때 까지의 대기 시간.
   애드 혹 데이터 분석에서 중요시.

데이터 처리의 지연

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

비구조화 데이터를 읽어 들여 열 지향 스토리지로 변환하는 과정에서, 데이터의 가공 및 압축을 위해 많은 컴퓨터 리소스가 소비된다.
그래서 사용하는 것이 Hadoop, Spark 같은 분산 처리 프레임워크다.

구조화 데이터, 비구조화 데이터, 스키마리스 데이터

1. 구조화 데이터
   스키마가 명확하게 정의된 데이터.
   기존의 데이터 웨어하우스에서는 항상 구조화 데이터로 축적하는 것이 일반적이었다.

2. 비구조화 데이터
   스키마가 없는 데이터.
   이 상태로는 SQL 로 제대로 집계할 수 없다.

3. 스키마리스 데이터
   CSV, JSON, XML 등의 데이터는 서식은 정해져 있지만, 칼럼 수나 데이터 형은 명확하지 않다.

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

분산 스토리지에 수집된 데이터는 명확한 스키마를 갖지 않아 그대로는 SQL 로 집계할 수 없다.
그래서, 먼저 스키마를 명확하게 한 테이블 형식으로 변환해야한다.
구조화된 데이터는 데이터 압축률을 높이기 위해 열 지향 스토리지에 저장한다.

열 지향 스토리지의 작성

Hadoop 의 열 지향 스토리지는,

1. Apache ORC
   처음에 스키마를 정한 후 데이터를 저장

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