[빅데이터를 지탱하는 기술] 5장 빅데이터의 파이프라인

Chapter 5

빅데이터의 파이프라인

📑 목차

1. 워크플로 관리란?

2. 오류 복구와 멱등성

3. 태스크 큐와 병렬화

4. DAG와 데이터 플로우

5. 스트림 처리와 람다/카파 아키텍처

6. 핵심 요약 정리

01

워크플로 관리란?

워크플로 관리란 정해진 업무 프로세스를 원활하게 진행하기 위한 구조입니다. 데이터 파이프라인에서는 태스크를 정기적으로 실행하고, 실패 시 복구를 돕는 역할을 합니다.

💡 비유로 이해하기

워크플로 관리 도구는 데이터 파이프라인의 사령탑(관제탑)입니다. 공항 관제탑이 비행기의 이착륙 순서를 관리하고, 문제 발생 시 대체 경로를 안내하듯이, 워크플로 관리 도구는 태스크의 순서·실행·복구를 관장합니다.

📌 워크플로 관리 도구의 3대 핵심 기능

✔ 태스크를 정기 스케줄로 실행하고 결과를 통지
✔ 태스크 간 의존 관계를 정하고 순서대로 실행
✔ 실행 결과를 보관하고, 오류 시 재실행 지원

선언형 vs 스크립트형

📋 선언형 (Oozie, Azkaban, Digdag)

XML/YAML로 워크플로 기술

누가 작성해도 동일 → 유지보수성 높음

SQL 실행, 반복적 자동 생성에 적합

🔧 스크립트형 (Airflow, Luigi)

스크립트 언어로 워크플로 정의

변수·제어 구문 → 유연성 최고

ETL 프로세스, 파일 가공에 적합

---

02

오류 복구와 멱등성

빅데이터 파이프라인에서 오류는 반드시 발생합니다. 네트워크 장애, 스토리지 부족, 쿼리 성능 문제 등 원인도 다양합니다. 핵심은 오류를 막는 것이 아니라, 신속하게 복구할 수 있는 구조를 미리 만드는 것입니다.

💡 비유로 이해하기

멱등성은 식기세척기의 "세척 완료" 버튼과 같습니다. 실수로 두 번 눌러도 접시가 두 배로 깨끗해지거나 망가지지 않습니다. 동일한 작업을 여러 번 실행해도 항상 같은 결과가 나오는 것, 이것이 멱등성입니다.

복구 전략 3단계

🔄

플로우 재실행

실패한 플로우를 동일 파라미터로 다시 실행. 클릭 한 번으로 복구 완료

⏱️

자동 재시도

5~10분 간격으로 1~2회 재시도. 그 이상은 근본 원인 해결 필요

⏪

백필(Backfill)

날짜를 바꿔가며 일정 기간의 플로우를 연속 재실행. 과거 데이터 일괄 처리

멱등한 태스크 만들기: 추가 vs 치환

❌ 추가(Append) = 멱등하지 않음

재실행하면 데이터가 중복됨. 자동 재시도 시 위험. 반드시 수동 복구 필요

✅ 치환(Replace) = 멱등함

매번 덮어쓰기. 여러 번 실행해도 결과 동일. 안전한 자동 복구 가능

📌 추가가 필요한 경우 → 테이블 파티셔닝

테이블을 날짜/시간별 파티션으로 나누고, 파티션 단위로 치환(INSERT OVERWRITE)합니다. 겉보기엔 추가처럼 보이지만, 내부적으로는 멱등한 치환이 이뤄지는 구조입니다.

⚠️ 원자성(Atomic) 조작

각 태스크는 "끝까지 성공" 또는 "실패하면 아무것도 남지 않음"이어야 합니다. "도중까지 성공"이라는 어정쩡한 상태는 허용하지 않습니다. 여러 번 쓰기가 필요하면 중간 테이블을 활용하세요.

---

03

태스크 큐와 병렬화

워크플로 관리 도구의 또 다른 역할은 외부 시스템의 부하 컨트롤입니다. 태스크의 크기와 동시 실행 수를 조절하여 자원을 효율적으로 사용합니다.

💡 비유로 이해하기

태스크 큐는 은행 번호표 시스템입니다. 고객(태스크)이 대기열(큐)에 쌓이면, 창구 직원(워커)이 순서대로 처리합니다. 창구를 늘리면 처리 속도가 올라가지만, 너무 많으면 혼잡(병목)이 발생합니다.

❌ 태스크가 너무 작으면

오버헤드만 커짐. 파일 1만 개를 각각 태스크로 만들면 → 오류 확률 증가, 14시간 소요

✅ 적정 크기로 묶기

수백 개 파일을 하나의 태스크로. 날짜 파라미터로 분할 → 365개 태스크로 축소. 20개 워커로 병렬 실행

---

04

DAG와 데이터 플로우

MapReduce는 Map→Reduce 한 사이클이 끝나야 다음으로 넘어가서 비효율적이었습니다. 이를 대체한 것이 DAG(Directed Acyclic Graph, 방향성 비순환 그래프)를 사용한 데이터 플로우입니다.

💡 비유로 이해하기

MapReduce는 릴레이 경기입니다. 앞 주자가 끝나야 다음 주자가 출발하죠. DAG는 공장 조립 라인입니다. 각 공정이 동시에 병행으로 돌아가고, 완성된 부품은 즉시 다음 공정으로 전달됩니다. 대기 시간이 없으니 훨씬 빠릅니다!

🔄 MapReduce (과거)

Map→Reduce 순차 실행. 한 사이클 끝나야 다음 진행. 쓸데없는 대기 시간 발생

⚡ DAG 데이터 플로우 (현재)

모든 노드가 동시 병행 실행. 처리된 데이터는 즉시 전달. 지연 평가로 최적 실행 계획 자동 생성

데이터 플로우 vs 워크플로 — 역할 분담

📡 외부 데이터
워크플로 (벌크 전송) → ⚙️ 분산 처리
데이터 플로우 (DAG) → 💾 분산 스토리지
CSV·열 지향 저장 → 📊 외부 출력
워크플로 (로드·전송)

📌 핵심 원칙

✔ 분산 시스템 내부 처리 → 데이터 플로우 (텍스트 가공, 열 지향 변환 등)
✔ 분산 시스템 외부와 데이터 교환 → 워크플로 (오류 복구가 필요하므로)
✔ SQL 실행, 스케줄 관리 → 워크플로

---

05

스트림 처리와 람다/카파 아키텍처

배치 처리의 한계는 데이터를 볼 수 있기까지 시간이 걸린다는 점입니다. 이벤트 발생 후 몇 초 안에 결과가 필요하다면 스트림 처리가 필수입니다.

⏰ 배치 처리

유한 데이터 대상. 장기 분석에 강함. 과거 데이터 재집계 가능. 실시간성 없음

⚡ 스트림 처리

무한 데이터 대상. 실시간성 최고. 과거 데이터 변경 어려움. 부정확할 수 있음

람다 아키텍처 — 배치 + 스트림 결합

💡 비유로 이해하기

람다 아키텍처는 뉴스 속보 + 정식 기사 시스템입니다. 스피드 레이어(속보)로 즉시 빠른 결과를 보여주고, 배치 레이어(정식 기사)가 나중에 정확한 결과로 교체합니다. 속보가 틀려도 정식 기사가 나오면 문제없죠!

🏭

배치 레이어

모든 데이터를 처리
장기 스토리지 축적
느리지만 정확

🍽️

서빙 레이어

배치 결과를 제공
빠른 응답 DB
배치 뷰 생성

⚡

스피드 레이어

스트림 처리 전담
배치 뷰 나올 때까지만
실시간 뷰 (잠정값)

카파 아키텍처 — 스트림만으로 단순화

람다의 단점인 이중 구현 번거로움을 해결하기 위해, 배치 레이어를 제거하고 스피드 레이어만 남긴 것이 카파 아키텍처입니다. 문제 발생 시 메시지 브로커의 시간을 과거로 되돌려 스트림 처리를 재실행합니다.

✅ 람다 아키텍처

배치 + 스트림 2계통. 정확하지만 개발 비용 높음. 배치가 안정적이면 스트림 재실행 불필요

✅ 카파 아키텍처

스트림만으로 단순화. 과거 데이터도 스트림으로 재처리. 부하가 높지만 클라우드 확장으로 해결

⚠️ 아웃 오브 오더(Out of Order) 문제

스트림 처리에서 프로세스 시간으로 집계하면 지연·장애 시 결과가 요동칩니다. 이벤트 시간 윈도윙으로 올바른 시간 기준 집계가 필요하지만, 일정 이상 늦게 온 데이터는 무시할 수밖에 없습니다.

---

SUMMARY

핵심 요약 정리 ✨

✓

워크플로 관리 도구는 데이터 파이프라인의 사령탑. 태스크 스케줄·의존관계·오류 복구를 담당합니다.

✓

멱등한 태스크(치환)를 만들면 안전한 재실행이 가능합니다. 테이블 파티셔닝이 핵심 기법입니다.

✓

태스크는 너무 크지도, 작지도 않게 분할하고, 태스크 큐로 병렬화하여 자원을 최적 활용합니다.

✓

DAG 데이터 플로우는 MapReduce를 대체하며, 분산 시스템 내부 처리를 병행 실행합니다.

✓

람다 아키텍처: 스트림(속보) + 배치(확정값). 카파 아키텍처: 스트림만으로 단순화.

✓

스트림 처리 도입은 꼭 필요한 경우에만 신중하게. 우선 워크플로 관리로 안정성을 확보하는 것이 최우선입니다.