분산 데이터 처리: MapReduce, Spark, SQL 엔진

빅데이터 처리란

실무에서 빅데이터는 서버 한 대로 감당할 수 없는 데이터다. 메모리가 모자라 작업이 죽고(out of memory), 디스크가 가득 찬다. 그래서 여러 서버를 묶은 클러스터로 처리하고, 그 과정에서 생기는 클러스터 관리·병렬 처리·부하 분산 문제를 푸는 것이 데이터 엔지니어링의 큰 축이다.

크기(volume)만 문제가 아니다. 흔히 4V로 정리한다.

커지는 데이터에 대응하는 길은 둘이다. 더 큰 장비로 바꾸는 스케일 업은 쉽지만 곧 한계와 비용에 부딪힌다. 여러 대에 나누는 스케일 아웃은 관리가 복잡하다. 그래서 스스로 데이터를 나누고 장애가 나면 복구하는 분산 처리 시스템이 나왔다. 반대로 한 서버로 되면 분산 도구를 쓰지 않는다. 클러스터는 최소 몇 대가 필요하고 개발·운영비가 든다.

계보

MapReduce와 그 한계

MapReduce는 입력을 나눠 각 워커가 Map(키-값 쌍 만들기)을 하고, 같은 키끼리 모으는 셔플(SQL의 GROUP BY와 비슷하다)을 거쳐 Reduce(키별 집계)로 결과를 낸다. 단순한 두 함수로 거의 모든 일괄 집계를 표현한다.

한계는 단계마다 결과를 HDFS(디스크)에 쓰고 다음 단계가 다시 읽는다는 점이다. 같은 데이터를 수십 번 도는 머신 러닝·그래프 알고리즘과, 같은 데이터에 질의를 연달아 던지는 대화형 분석에서 특히 느리다.

논문이 설계한 지역성·장애 처리·낙오자 대응 같은 세부 기법은 고전 분산 시스템 설계에 있다.

Spark와 RDD

RDD: 메모리를 읽기 전용으로 쓰기

중간 결과를 메모리에 두면 빠르지만, 노드가 죽으면 메모리 데이터도 사라진다. 기존 메모리 기반 시스템은 값을 세밀하게 고칠 수 있게 하는 대신 복제나 디스크 체크포인트로 장애에 대비했고, 그동안 작업이 멈춰 느렸다. RDD(Resilient Distributed Dataset)는 GFS가 「수정 불가」로 시스템을 단순하게 만든 것처럼 메모리 데이터를 읽기 전용으로 만들어 이 문제를 풀었다.

좁은 의존성과 넓은 의존성

그래서 셔플을 줄이는 것이 성능 최적화의 핵심이고, 셔플을 여러 번 거친 결과(반복 조인)는 체크포인트로 저장해 두는 편이 낫다. 읽기 전용이라 쓰는 동안 바뀔 걱정이 없어 체크포인트를 멈춤 없이 백그라운드로 남길 수 있다. 스케줄러는 이미 계산된 파티션은 건너뛰고, 데이터가 있는 노드에서 작업을 돌리도록(data locality) 배치한다.

지금의 Spark: DataFrame과 Spark SQL

지금은 RDD를 직접 다루기보다 DataFrame·Dataset API와 Spark SQL을 쓴다. 컬럼 구조를 아는 API라 Catalyst 최적화기가 실행 계획을 다시 짜고(필요한 컬럼만 읽기, 조건을 저장소로 내리기), 런타임 통계로 셔플 파티션 수와 조인 방식을 바꾸는 적응형 질의 실행(AQE)이 기본으로 켜져 있다. RDD는 그 아래 실행 모델로 남아 있다. 같은 DataFrame API로 스트림을 다루는 Structured Streaming도 있다.

# 하루치 로그에서 메시지를 보낸 사용자 수
logs = spark.read.json("s3://my-logs/2026-10-30/*")
logs.filter(logs.action == "ADD_MSG").select("userId").distinct().count()

과거에는 Scala RDD API(sc.textFile(...).filter(...).map(...).distinct.count)로 같은 일을 했다. 하둡 MapReduce로 10시간 걸리던 하루치 분석이 Spark로 옮기며 1시간 안팎으로 줄어든 사례처럼, 반복·다단계 분석일수록 차이가 크다.

클라우드에서 Spark 클러스터 운영

대화형 SQL 엔진: Trino(Presto)

Hive는 SQL을 MapReduce로 바꿔 디스크를 오가므로 느리다. Presto(지금 커뮤니티 버전 이름은 Trino)는 페이스북이 만든 분산 SQL 엔진으로, 페타바이트급 데이터에 대화형 속도로 질의한다.

커넥터가 또 하나의 장점이다. Hive 카탈로그(S3의 Parquet), MySQL, Elasticsearch, Pinot, Cassandra 등을 데이터 복사 없이 한 SQL로 조인한다(federated query). 커넥터는 메타데이터(스키마·테이블·컬럼), 데이터를 작업 단위로 나누는 split, 조건·LIMIT를 원천으로 내려보내는 푸시다운을 구현한다. Elasticsearch를 붙일 때는 인덱스 하나를 테이블 파티션으로, 같은 접두사를 가진 인덱스들을 논리 테이블 하나로 본다.

열 지향 포맷: Parquet

분석 질의는 SELECT *보다 몇 개 컬럼만 고르는 경우가 많다. Parquet은 같은 컬럼 값을 디스크에 모아 두는 열 지향(columnar) 파일 포맷이다.

Parquet 파일
├─ 로우 그룹 1
│   ├─ 컬럼 청크: user_id
│   ├─ 컬럼 청크: status     ← LOGIN/LOGOUT처럼 종류가 적으면 사전 인코딩
│   └─ 컬럼 청크: city_id
├─ 로우 그룹 2 ...
└─ 푸터: 스키마, 로우 그룹별 컬럼 통계(최솟값·최댓값·사전)

• 필요한 컬럼만 읽는다(column pruning). 중첩 구조(base.city_id)도 필요한 하위 필드만 읽는다.
• 조건을 저장소로 내린다(predicate pushdown). city_id = 12인데 푸터 통계나 사전에 12가 없는 로우 그룹은 통째로 건너뛴다. 기본 리더가 모든 중첩 필드를 읽던 것을 필요한 필드만 읽고 조건을 바로 평가하게 바꿔 수 배~10배 빨라진 사례가 있다.
• 같은 종류 값이 모여 압축이 잘 된다. 종류가 적은 값은 값 대신 사전 인덱스만 저장한다. 코덱은 Snappy·ZSTD·GZIP 등을 고른다.

같은 열 지향 원리를 쓰는 분석 DB(ClickHouse, BigQuery, Redshift)는 데이터베이스 고르기의 OLAP 항목에 있다.

정리

• 서버 한 대로 안 될 때 분산 처리를 쓴다. 그 전에는 운영비가 이득보다 크다.
• MapReduce는 단계마다 디스크를 거쳐 반복·대화형 작업에 느렸고, Spark는 읽기 전용 메모리 데이터(RDD)와 계보로 장애 복구를 해결해 이를 넘었다.
• 성능은 셔플(넓은 의존성)을 줄이는 데서 나온다. 지금은 DataFrame·SQL API를 써서 최적화기에 맡긴다.
• 저장은 객체 저장소 + Parquet, 계산은 필요할 때 띄우는 클러스터, 대화형 질의는 Trino 같은 SQL 엔진이 지금의 기본 조합이다.

관련 노트: 데이터 파이프라인과 저장소 용어, 데이터베이스 고르기, 와이드 컬럼 데이터베이스, 블록·파일·객체 스토리지, 메시지 큐와 Kafka