콘텐츠로 이동

Spark

데이터가 몇 기가바이트를 넘어가면 한 서버의 메모리로는 감당이 안 돼요. 이벤트 데이터는 그 성격상 하루에도 엄청나게 쌓이는데, 그걸 한 번에 처리하려면 컴퓨터가 버티질 못하죠. 이런 규모는 '한 대가 전부 한다'의 문제가 아니라 '여러 대가 나눠서 한다'의 문제예요. Spark는 메모리 기반으로 대용량 데이터를 분산 처리하는 엔진이에요. 단일 서버로 못 버티는 규모를 여러 노드로 나눠 돌릴 때 씁니다.

한눈에 보면 이렇게 구분하면 돼요. Airflow가 '언제 돌릴지(오케스트레이션)'를 지휘한다면, Spark는 '실제로 어떻게 나눠 계산할지(분산 처리)'를 맡아요. 대용량 데이터를 다루는 파이프라인에서 이 둘은 짝을 이뤄요.

핵심 개념

  • 언제 쓰는가 — 데이터가 단일 서버 연산으로 감당이 안 될 만큼 커지거나, 변환이 무거워질 때 씁니다. 작은 데이터에선 설정·분산 오버헤드가 오히려 손해라서, 규모가 기준이 돼요.
  • 분산 처리 — 데이터를 여러 노드로 쪼개서 동시에 계산하고, 그 결과를 다시 모읍니다. '한 대로는 안 되는 양'을 '여러 대가 나눠 빠르게' 처리하는 구조예요.
  • 메모리 기반(RDD/DataFrame) — 중간 결과를 디스크가 아니라 메모리에 두고 단계를 이어가서, 반복 연산이 많을수록 디스크 I/O를 줄여 빨라져요. RDD와 DataFrame이 대표적인 데이터 추상화예요.
  • 배치 vs 스트리밍 — 주로 큰 배치(한 번에 많은 데이터)를 처리하는 데 쓰지만, Spark Streaming으로 실시간에 가깝게 연속 처리도 할 수 있어요. '대용량 변환'이 주요 역할이라면 배치가 기본이에요.
  • ETL과의 결합 — 원천 데이터를 가져와 변형하고 저장하는 ETL의 '변형(Transform)'을 클러스터 규모로 수행합니다. Airflow가 '언제 돌릴지'를 지휘하면, Spark는 '실제로 어떻게 나눠 계산할지'를 맡는 짝이에요.
  • 언어 지원 — Scala·Java·Python(PySpark)·R 등 여러 언어로 작성할 수 있어서, 팀 스택에 맞춰 쓰기 좋아요.

사용 사례 / 실제 적용

Events 3계층에서 Spark는 대용량 변환 층 자리를 맡는 걸로 시나리오를 잡아요. 이벤트 데이터를 표준 스키마로 정제하는 무거운 변환을 클러스터에 분산시키고, 결과를 창고(DW)에 적재하는 식이죠. Airflow가 파이프라인을 지휘하고 Spark가 계산을 나눠 맡는 조합은 대용량 데이터 처리의 대표적인 구성이에요.

다만 지금은 ⚪ 역량 단계예요. 팀이 다룰 줄 알되 제품엔 아직 전면 도입 전이라는 뜻이죠. 역량 단계 디테일은 데이터 엔지니어링 허브에서, 지휘자 역할은 Airflow에서 이어져요.

Spark를 처음 배울 때 오해하기 쉬운 점은 '빠른 도구'로만 보는 것이에요. Spark의 장점은 단순 속도가 아니라 '메모리 캐싱 + 분산 병렬 처리'라는 구조에서 나와요. 데이터가 작으면 Spark의 설정·분산 오버헤드가 오히려 손해라서, '규모가 클 때 왜 쓰는지'를 먼저 이해하는 게 중요해요. 도입할 때는 이 점도 기억하면 좋아요.

  • 데이터 분할(파티션) — 데이터가 잘게 쪼개져야 여러 노드가 동시에 일해요. 파티셔닝이 잘못되면 일부 노드만 바빠지고 나머지는 놀 수 있어요.
  • 셔플 줄이기 — 데이터를 재배치하는 셔플이 많아질수록 느려져요. 조인·집계를 설계할 때 셔플을 최소화하는 방향을 잡아요.
  • 캐싱 활용 — 반복해서 쓰는 중간 결과를 메모리에 캐시해 두면 여러 단계에서 재계산을 피할 수 있어요.
  • 스케일 전략 — 데이터가 계속 커지면 노드를 늘리거나(스케일 아웃) 성능을 키우는(스케일 업) 선택을 해야 해요.
  • 모니터링 — 작업이 오래 걸리거나 실패하는 걸 보기 위해 실행 상태를 관찰하는 지표를 함께 둬요.
  • 결과의 일관성 — 여러 노드로 나눠 계산해도 결과가 한 번에 계산했을 때와 같아야 해요. 분산 환경에서 결과 일관성을 늘 염두에 둬요.

심화 챕터

Spark의 데이터 추상화는 아래 챕터에서 공식 문서를 기준으로 더 깊게 다뤄요.

더 알아보기