[빅데이터를 지탱하는 기술] 5. 빅데이터의 파이프라인 (2)

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

MapReduce의 시대는 끝났다 

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

▪ 이전부터 MapReduce를 사용한 데이터처리에서는 MapReduce 프로그램을 워크플로의 태스크로 등록함으로써 다단계의 복잡한 데이터를 처리할 수 있었음 

▪ 현재는 다단계의 데이터 처리를 그대로 분산 시스템의 내부에서 실행할 수 있음, 이를 '데이터 플로우(data flow)'라고 지칭 

 

데이터 플로우를 위한 프레임워크

MapReduce의 구조

▪ 한때 빅데이터의 대표적인 기술이었던 MapReduce, 현재는 'MillWhell', 'Tez', 'Spark'등의 다양한 프레임워크의 등장으로 대체됨 

 

MapReduce의 실행 예

 

▪ 하나하나의 처리는 독립적으로 다수의 컴퓨터로 분산, 분산 처리의 결과는 마지막에 집계 

▪ 분할된 데이터를 처리하는 첫 번째 단계를 'Map', 그 결과를 모아서 집계하는 두 번째 단계를 'Reduce'라고 부름 

▪ 다음과 같이 Map과 Reduce를 반복하며 데이터를 변환해 나가는 구조인 MapReduce 

▪ MapReduce는 그 구조상 Map과 Reduce의 하나의 사이클이 끝나지 않으면 다음 처리로 이동하지 않음 

▪ 따라서 하나의 사이클에서 다음 사이클로 이동할 때까지 대기 시간이 발생 

MapReduce를 대신할 프레임워크 

▪ 새로운 프레임워크에 공통으로 들어가는 'DAG(directed acyclic graph)', 한국어로는 '방향성 비순환 그래프'

▪ DAG의 성질 

   - 노드와 노드가 화살표로 연결됨 (방향성)

   - 화살표를 아무리 따라가도 동일 노드로는 되돌아오지 않음 (비순환)

▪  데이터 플로우에서는 실행해야 할 일련의 태스크를 DAG에 의한 데이터 구조로 표현 

▪ 화살표는 태스크의 실행 순서를 나타내고, 그 의존 관계를 유지하면서 실행 순서를 정하면 모든 태스크를 완료할 수 있음 

 

DAG의 예

 

▪ 데이터 플로우에서는 DAG을 구성하는 각 노드가 모두 동시 병행으로 실행 

▪ 처리가 끝난 데이터는 네트워크를 거쳐 전달되어 MapReduce와 달리 대기시간이 존재하지 않음 

Spark에 있어서의 DAG 

▪ DAG은 시스템의 내부적인 표현 

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

▪ 따라서 SQL로부터 DAG의 데이터 구조가 내부적으로 자동 생성 

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

 

Spark와 관련된 DAG의 예

 

▪ DAG에 의한 프로그래밍의 특징인 '지연 평가(lazy evaluation)'

▪ 데이터 파이프라인 전체를 DAG으로 조립하고 실행하면 내부 스케줄러가 분산 시스템에 효과적인 실행 계획을 세워주는 것이 데이터 플로우의 장점 

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

▪ 데이터 플로우에서 데이터의 입출력을 모두 하나의 DAG으로 기술

▪ 워크플로 관리 도구와 데이터 플로우는 서로 보완적으로 사용

▪ 태스크를 정기적으로 실행하거나, 실패한 태스크를 기록하여 복구하기 위해 워크플로 관리 도구가 필요 

▪ 데이터 플로우의 프로그램도 다시 워크플로의 일부로 실행되는 하나의 태스크로 고려 가능

▪ 분산 시스템의 외부와 데이터를 주고 받는 경우, 오류 발생시 복구를 고려해 워크플로 안에서 실행하는 것이 바람직 

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

▪ 데이터 플로우로부터 읽어 들일 데이터는 성능적으로 안정된 분산 스토리지에 배치 

▪ 동일 데이터를 여러 번 읽어들이는 플로우 개발 테스트 중에는 분산 스토리지에 복사된 데이터만을 이용, 그렇지 않을 경우 성능 문제를 일으킴 

 

데이터는 복사한 다음 이용

 

▪ 외부의 데이터 소스에서 데이터를 읽어 들일 때는 벌크 형의 전송 도구로 태스크를 구현 

▪ 데이터 소스에서의 읽기 속도는 한계가 있음, 오류 발생시 적절한 대처를 통해 복사를 끝내는 것이 중요 

▪ 이를 위해 태스크 실행에는 워크플로 관리 도구를 사용하는 것이 적합 

▪ 데이터 복사만 완료될 경우 부하가 큰 처리는 데이터 플로우로서 실행할 수 있음 

 

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

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

▪ 데이터 플로우 안에서 대량의 데이터를 외부에 전송하는 것은 피하는게 좋음 

▪ 쓰기 작업이 오래 걸리면, 실행이 완료되지 않고 자원만 소비 

▪ 데이터 플로우의 출력은 CSV 파일과 같이 취급하기 쉬운 형식으로 변환하여 분산 스토리지에 써넣음 

▪ 외부 시스템에 데이터를 전송하는 것은 워크플로의 역할 

▪ 벌크 형의 전송 도구를 사용하여 태스크를 구현 또는 외부 시스템 쪽에서 파일을 읽어들이도록 지시

 

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

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

▪ 위와 같은 데이터 입출력에 SQL에 의한 쿼리의 실행을 조합시킴으로써 배치형의 데이터 파이프라인이 완성 

▪ SQL을 MPP 데이터베이스에서 실행하는 경우는 '데이터 웨어하우스의 파이프라인' 

▪ 분산 시스템상의 쿼리 엔진에서 실행하는 경우는 '데이터마트의 파이프라인'

 

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

 

▪ 데이터 웨어하우스를 구축할 경우, 로드되는 데이터를 만드는 부분까지가 데이터 플로우의 역할 

▪ 비구조화 데이터를 가공하여 CSV파일 등으로 만들어 분산 스토리지에 써놓음 

▪ 그 이후 태스크 실행, SQL에 의한 쿼리 실행은 워크플로가 처리 

 

데이터 마트의 파이프라인

 

▪ 쿼리 엔진을 사용하여 데이터 마트를 구축할 경우, 구조화 데이터를 만드는 부분까지가 데이터 플로우의 역할 

▪ 분산 스토리지 상의 데이터를 매일 반복되는 배치로 가공하여 열 지향의 스토리지 형식으로 보관 

▪ 쿼리 엔진을 사용한 SQL 실행, 결과를 데이터 마트에 써서 보내는 것은 워크플로에서 실행  

대화식 플로우 

▪ 애드 혹 분석에서는 많은 데이터 처리를 수작업으로 시행하므로 워크플로는 필요하지 않음 

 

쿼리 엔진에서 대화식으로 집계

 

▪ 아직 구조화되어 있지 않은 데이터를 애드 혹으로 분석할 때는 데이터 플로우가 유용, 데이터를 구조화하면 고속 집계 처리 가능 

▪ 데이터가 이미 구조화되어 있는 경우, 쿼리 엔진을 사용해 참조 

▪ 시각화 도구나 쿼리 엔진을 직접 접속하는 경우 ODBC와 JDBC 드라이버 사용 

▪ 쿼리 엔진과 시각화 도구의 조합은 무수히 많이 존재, 아직은 안정적인 접속을 할 수 없는 경우도 많음 

▪ 안정적인 운영을 추구하기 위해 RDB나 MPP 데이터베이스를 데이터 마트로 사용 

 

 

빅데이터를 지탱하는 기술(니시다 케이스케)