[책정리]빅데이터를 지탱하는 기술 5.2 배치형의 데이터 플로우

6월 선정도서 - 빅데이터를 지탱하는 기술

선정계기 - 데이터가 쌓이고 흐르는 전체적인 구조를 깊이 있게 이해할 수 있고,

미래의 데이터엔지니어로써 해야하는 업무들의 전반적인 흐름을 파악할 수 있을 것 같아 선정(기대가 된다)

하 면접이랑 코딩테스트를 준비하면서 병행하지 못해 아직도 못 끝내고 있다...얼릉 끝내야하는데..

 

목차 

챕터5. 빅데이터의 파이프라인

5-1. 워크플로관리 

5-2. 배치형의 데이터플로우

5-3. 스트리밍형의 데이터플로우

 

챕터6. 빅데이터 분석 기반의 구축

6-1. 스키마리스 데이터의 애드훅분석 

6-2. 하둡에 의한 데이터파이프라인

6-3. 워크플로 관리도구에 의한 자동화(airflow)

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

 

복잡한 텍스트처리나 다단계의 데이터파이프라인을 만들기 위해서 프로그래밍 언어로 데이터처리를 구현하고 싶을때

DAG를 사용한 배치형의 분산 데이터처리의 사고방식을 알아보자.

---

MapReduce의 시대는 끝났다

분산스토리지로 데이터전송이 완료되면, 이젠 분산시스템의 프레임워크를 사용할 수 있다.

이떄 SQL만으로 데이터를 처리하는 것이 아니라 프로그래밍 언어로 데이터 파이프라인을 작성할 수 있다. 

 

데이터플로우

MapReduce 프로그램으로 워크플로의 테스크를 등록을 하여 데이터처리를 하는 프레임워크

외부 도구에 의존하는 워크플로우와는 구별된다. 

 

MapReduce구조

• 분할된 데이터를 처리하는 첫번쨰 단계를 Map,
• 그 결과를 모아서 집계하는 두번쨰 단계를 Reduce라고 부른다. 
• 이렇게 Map과 Reduce를 반복하면서 목적하는 결과를 얻을떄까지 계속해서 데이터를 변환해나가는 구조이다. 

이제는 MapReduce를 과거의 기술로 간주한다.

Map과 Reduce의 하나의 사이클이 끝나지 않으면 다음처리로 이동하지 않는다.

복잡한 데이터처리에서는 Map과 Reduce를 여러번 반복하지 않으면 원하는 결과를 쉽게 얻을 수 없어서,

하나의 사이클에서 다음 사이클로 이동할때까지 대기시간이 많이 걸린다. 

특히 애드훅 데이터분석이 요구되는 집계는 MapReduce로 실현하기 어렵다 .

---

MapReduce를 대신할 새로운 프레임워크

DAG(Directed acyclic graph)

방향성 비순환 그래프

어떤 새로운기술이 아니라 수학과 컴퓨터 알고리즘에서 사용되는 데이터모델의 하나.

방형성 비순환그래프의 특징은 아래와 같다.

• 노드와 노드가 화살표로 연결된다.
• 화살표를 아무리 따라가도 동일노드로 되돌아오지 않는다. 

DAG로 표현하는 Task

실행해야 할 일련의 테스크를 DAG에 의한 데이터구조로 표현한다. 

그럼 그 안의 화살표는 테스크의 실행순서를 나타내고,

그 의존관계를 유지하면서 실행순서를 알맞게 정하면

모든 테스크를 빠짐없이 완료할 수 있다. 

 

맵리듀스 VS DAG

기존의 맵리듀스도 Map과 Reduce의 두 종류의 노드로 이루어진 간단한 DAG라고 볼 수 있다.

단 하나의 노드에서 처리가 끝나지 않으면 다음 처리로 진행할 수 없으므로 비효율적이다. 

반면 DAG를 구성하는 각 노드가 모두 동시 병행으로 실행된다. 

처리가 끝난 데이터는 네트워크를 거쳐 차례대로 전달되어 MapReduce에 존재했던 대기시간을 없앤다. 

 

Spark의 DAG

데이터플로우에 국한되지 않고, Hive on Tez나 Presto와 같은 쿼리엔진에서도 DAG 채택.

Spark와 같은 데이터플로우의 프레임워크에서는 프로그래밍 언어를 사용하여 더욱 직접 DAG의 데이터구조를 조립한다.

각 노드는 이름을 나타내듯이 Map과 Reduce에 상당한 처리를 하고 있어 처리내용이 늘어남에 따라 DAG도 복잡해진다.

 

DAG에 의한 프로그래밍의 특징 : 지연평가

프로그램 각 행은 실제로 DAG의 데이터구조를 조립하고 있을 뿐, 특별히 처리하는건 없다.

먼저 DAG구축하고 그 후에 명시적 혹은 암묵적으로 실행결과를 요구해야 데이터처리가 시작된다. 

맵리듀스처럼 map과 reduce를 하나씩 실행하는 것이 아니라 먼저 데이터파이프라인 DAG로 조립하고 실행에 옮긴다. 

---

데이터플로우와 워크플로 조합하기

테스크를 정기적으로 실행하거나, 실패한 테스크를 기록하여 복구 -> 데이터플로우만으로 불가, 워크플로관리필요

데이터 플로우의 프로그램도 다시 워크플로의 일부로서 실행되는 하나의 태스크로 고려할 수 있다.

 

분산시스템안에서만 실행되는 데이터 처리라면 -> 하나의 데이터플로우로 기술가능 굳이 테스크분리가 필요없다. 

분산시스템의 외부와 데이터를 주고받을 경우라면 복구가 필요-> 워크플로우 안에서 실행하는 것 권장 

 

1. 데이터를 읽어들이는 플로우 

성능적으로 안정된 분산스토리지에 읽어들인 데이터를 복사함으로써 안정적으로 사용한다

 

1) 워크플로우  : 분산스토리지에 데이터 복사

특히 플로우가 완성될때 까지 개발중인 경우

동일 데이터를 여러번 읽어들여 테스트하므로 분산스토리지에 있는 데이터만 이용한다

(외부의 데이터소스에 여러번 접속하게 되면 성능상 문제)

만약 외부의 데이터소스에서 데이터를 읽어 들일 경우 벌크형 전송도구로 테스트 구현

오류의 발생에 대해 확실하게 대처하여 복사를 하기 위한 목적으로 워크플로 관리도구를 사용한다.

2) 데이터플로우 : 데이터처리 

데이터복사가 완료되면 텍스트 데이터의 가공이나 열지향 스토리지로의 변환 등 부하가 큰 처리를 데이터플로우가 처리

거기까지 하나의 테스크로 구현하여 정기적으로 데이터를 읽어들이기 위한 워크플로우가 완성된다.

 

2. 데이터를 써서 내보내는 플로우

데이터를 읽을떄랑 반대작업

1) 데이터플로우 : 데이터보관

CSV파일과 같이 취급하기 쉬운 형식으로 변환하여 일단 분산스토리지에 써넣는다. 

2) 워크플로우 : 외부시스템에 데이터전송

벌크형 전송도구를 사용하여 테스크를 구현하거나, 외부 시스템 쪽에서 파일을 읽어들이도록 지시한다. 

예를 들어 데이터마트로 MPP데이터베이스를 이용한다면 분산스토리지로부터 파일을 로드하는 명령어를 수행한다. 

---

데이터플로우와 SQL을 나누어사용하기

위와 같은 데이터입출력에 SQL에 의한 쿼리실행까지 더하면 배치형 데이터파이프라인이 완성된다.

워크플로우는 sql로 쿼리를 실행하는 것까지 호출한다. 

 

1.MPP데이터베이스에서 SQL을 실행하는 경우 (데이터웨어하우스 파이프라인)

데이터플로우 : 로드데이터를 만드는 부분까지 

워크플로우 : 이후 비구조화 데이터를 가공해 csv파일 등으로 만듦, 분산스토리지에 넣음, 태스크실행 및 SQL쿼리실행까지 

 

2.쿼리엔진에서 SQL을 실행하는 경우 (데이터마트의 파이프라인)

데이터플로우 : 비구조화 데이터를 가공해 구조화 데이터를 만드는 부분까지

워크플로우 : 이후 분산스토리지 상의 데이터를 배치형태로 가공,

열지향 스토리지 형식으로 보관하고, 쿼리엔진으로 SQL실행하거나 그 결과를 데이터마트에 써서 내보내는것 까지

 

3.대화식플로우 (애드훅 분석시 파이프라인) 

많은 데이터처리를 수작업으로 시행하므로 워크플로우가 필요하지 않다. 

아직 구조화되어 있찌 않은 데이터를 애드훅 분석할떄는 데이터플로우가 매우 유용.

raw data에 직접 접속하여 그 자리에서 데이터가공, 집계, 데이터구조화하면

그후에 쿼리엔진에서 SQL처리와 비슷한 속도로 빠르게 처리가 가능.