[빅데이터의 파이프라인] 2. 배치 형의 데이터 플로우

---

이 글은 빅데이터를 지탱하는 기술을 읽고 정리한 글입니다.

---

 

 

 

1. MapReduce의 시대는 끝났다.

---

분산스토리지로의 데이터 전송이 완료되면, 분산 시스템의 프레임워크를 사용할 수 있다. 여기서 SQL로 데이터를 처리하는 것이 아니라 프로그래밍 언어로 데이터 파이프라인을 작성하고 싶은 경우도 있는데, 이전부터 MapReduce를 사용한 데이터 처리에서는 MapReduce 프로그램을 워크플로의 태스크로 등록함으로써 다단계의 복잡한 데이터 처리를 할 수 있었다. 그래서 데이터 플로우란 다단계의 데이터 처리를 그대로 분산 시스템의 내부에서 실행하는 것이라고 정의한다. 예를 들어서 Google Cloud Dataflow, Apache Spark, Apach Flink가 있다.

 

MapReduce의 구조

MapReduce는 이제 과거의 기술로 간주되고 있지만, MapReduce의 개념 자체는 계속 만나게 된다.

 

ex) 텍스트 파일에 포함된 단어를 세는 처리

1. MapReduce는 파일을 일정 크기로 나누어 작은 데이터인 스플릿을 만든다.

2. 이후 나눈 데이터를 읽어들여 그중에 포함된 단어를 카운트한다. 이 과정은 분산시킬 수 있다. (= Map)

3. 처리한 데이터의 결과를 집계한다. (= Reduce)

4. 원하는 결과를 얻을 때까지 2와 3을 반복한다.

 

MapReduce는 구조상 Map과 Reduce의 하나의 사이클이 끝나지 않으면 다음 처리로 이동하지 않는다. 복잡한 데이터 처리에서는 Map과 Reduce를 여러 번 반복하지 않으면 원하는 결과를 얻을 수 없다. 특히 애드 혹 데이터 분석에서는 요구되는 지역이 적은 집계는 MapReduce로 실현하는 것이 어렵다. 그래서 최근에는 Hive나 Tez, Spark 등을 사용한다. (관련 내용 참고)

---

 

 

 

2. MapReduce를 대신할 프레임워크

---

새로운 프레임 워크에서 들어가는 것이 DAG(directed acyclic graph)라는 데이터 구조를 사용한다. 방향성 비순환 그래프로 컴퓨터공학과를 나온 학생이라면 DAG하면 위상정렬이 생각날 것이다.

데이터 플로우에서는 실행해야 할 일련의 태스크를 DAG에 의한 데이터 구조로 표현할 수 있다. 그러면 노드는 태스크를 나타내고, 화살표는 태스크의 실행 순서를 나타내고 있다. DAG로 정의를 한다면 태스크 간의 의존 관계를 유지하면서 실행 순서를 결정하는 것이 가능하다.

 

기존의 MapReduce도 Map과 Reduce 두 노드로 이루어진 DAG라고 생각할 수 있다. 이때 MapReduce는 Map 처리가 끝나지 않으면 Reduce를 실행할 수 없지만, 데이터 플로우에서는 각 노두가 모두 동시 병행으로 실행하여 MapReduce에 존재했던 대기 시간을 없앴다.

 

Spark에 있어서의 DAG

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

DAG에 의한 프로그래밍의 특징이 지연 평가인데, 프로그램의 각 행은 실제로는 DAG의 데이터 처리를 조립하고 있지만 다른 일을 하지는 않는다. 그래서 먼저 DAG를 구축하고, 이후에 실행 결과를 요구해야 데이터 처리가 시작하게 된다. 그래서 MapReduce와 다르게 Map과 Reduce를 하나씩 실행하지 않고, 먼저 데이터 파이프라인을 DAG로 조립하고 나서 실행하는 것이 데이터 플로우의 장점이다.

---

 

 

 

3. 데이터 플로우와 워크플로를 조립하기

---

데이터 플로우에서 프로그래밍을 할 수 있게 되면, 데이터의 입출력은 모두 하나의 DAG로 기술할 수 있다. 이렇게 하면 굳이 워크플로 관리 도구를 사용하지 않아도 될까 싶지만, 태스크를 정기적으로 실행하거나, 실패 태스크를 기록하여 복구하는 것은 데이터 플로우에서 할 수 없으므로 워크플로 관리 도구가 필요하다.

분산 시스템 안에서만 실행되는 데이터 처리라면 하나의 데이터 플로우로 기술할 수 있다. 하지만 분산 시스템의 외부와 데이터를 주고 받는 경우에는 어떤 오류가 발생할지 모르므로 복구를 고려해 워크플로 안에서 실행해야 한다.

 

 

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

데이터 플로우로부터 읽어 들일 데이터는 성능적으로 안정된 분산 스토리지에 배치해야 한다. 특히 플로우가 완성될 때까지의 개발중에는 외부의 데이터 소스에 자주 접속할 수 있으므로 분산 스토리지에 복사된 데이터만을 이용한다.

외부의 데이터 소스에서 데이터를 읽어 들일 때는 벌크 형의 전송 도구로 태스크를 구현하여 오류의 발생에 대해 확실하게 대처할 수 있도록 복사를 한다. 그러기 위해 태스크 실행에는 워크플로 관리 도구를 사용하는 것이 적합하다.

이제 데이터의 복사만 완료하면 이제 부하가 큰 처리는 데이터 플로우로 실행한다.

 

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

외부 시스템에 데이터 집계 결과를 써서 내보내는 경우에는 데이터를 읽어들일 때와의 반대로 작동한다. 데이터 플로우 안에서 대량의 데이터를 외부로 전송하는 것은 시간이 너무 오래 걸리므로 CSV 파일과 같이 취급하기 쉬운 형식으로 변환하여 일단 분산 스토리지에 저장하고, 다음 태스크를 실행하여 할 일을 하면 된다.

외부 시스템에 데이터를 전송하는 것은 이제 워크플로의 역할이다. 이것은 벌크 형의 전송 도구를 사용하여 태스크를 구현하거나, 외부 시스템 쪽에서 파일을 읽어 들이도록 한다.

---

 

 

 

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

---

바로 위의 과정에서 데이터의 입력과 출력을 구현하였으면 이제 SQL에 의한 쿼리의 실행까지 조합시킨다. 이것이 배치형의 데이터 파이프라인이다. 데이터 분석을 목적으로 할 경우에는 SQL로 쿼리를 실행시키는 일이 많으므로 그것을 호출하는 것도 워크플로의 업무이다.

 

 

1. 데이터 웨어하우스의 파이프라인

SQL을 MPP 데이터베이스에서 실행한다면 이것은 전형적인 데이터 웨어하우스의 파이프라인이다. 여기서 데이터 플로우의 역할은 데이터 웨어하우스를 구축하기 전에 CSV파일을 만드는 것까지 데이터 플로우의 역할이다. 이후 태스크 실행이나 SQL에 의한 쿼리 실행은 워크플로에 맡긴다.

 

 

2. 데이터마트의 파이프라인

SQL을 분산 시스템상의 쿼리 엔진에서 실행하는 경우는 전형적인 데이터마트의 파이프라인이다. 여기서 데이터 플로우의 역할은 위 사진에서 구조화 데이터를 만드는 부분까지이다. 그리고 분산 스토리지 상의 데이터를 배치로 가공하여 열 지향의 스토리지 형식으로 변환한다. 이후 쿼리 엔진을 사용한 SQL 실행이나 그 결과를 데이터 마트에 보내는 것은 워크플로에서 실행하면 된다.

 

 

3. 대화식 플로우

원래 애드 혹 데이터 분석에서는 많은 데이터 처리를 수작업으로 하니 워크플로가 필요없게 된다. 하지만 아직 구조화되어 있지 않은 데이터를 애드 혹으로 분석할 때에는 데이터 플로우가 매우 유용하다. 여기서 로우 데이터에 직접 접속하여 스크립트 언어를 사용하여 바로 데이터를 가공하고 구조화가 끝나면, 데이터 집계는 고속 처리가 가능하다. 이것은 쿼리 엔진을 통해서 얻는 결과물과 비슷한 속도로 얻을 수 있다. 이때 쿼리 엔진에 직접 접속하여 시각화를 하는 경우에는 ODBC나 JDBC를 사용한다.

분석하고 싶은 데이터가 이미 존재하는 경우 쿼리 엔진을 사용하여 데이터를 참조한다. 이때 쿼리 엔진과 시각화 도구와의 조합은 무수히 많기 때문에 안정적인 접속을 할 수 없을지도 몰라서 이미 많이 사용되어 온 RDB나 MPP 데이터베이스를 데이터 마트로 하는 것이 좋다.

---