앞 글에서 살펴본 것처럼, 스키마리스 형태의 비구조화 데이터를 분석하기 위해서는 데이터를 구조화해 열 기반 스토리지에 저장하는 과정이 필요하다. 하지만 이 과정은 데이터의 양이 방대할수록 변환, 압축, 저장에 많은 컴퓨팅 자원과 처리 시간이 요구된다.
따라서 이러한 대규모 처리 파이프라인을 안정적이고 효율적으로 실행하기 위해 등장한 것이 Hadoop과 같은 분산 처리 프레임워크이다. 지금부터 Hadoop의 구조와 역할에 대해 자세히 살펴보자.
| Hadoop 분산 데이터 처리의 공통 플랫폼
Hadoop
분산 데이터 처리를 위한 오픈소스 프레임워크
- 대용량 데이터를 여러 서버에 나눠 저장하고 병렬로 처리할 수 있게 해줌
- 단일 소프트웨어가 아닌, 여러 소프트웨어로 구성된 집합체
Hadoop의 역사
| 2003년 | Nutch 프로젝트에서 시작 (분산 파일 시스템 실험) |
| 2004년 | Google이 MapReduce 논문 발표 → 개념적 기반 제공 |
| 2006년 | Apache Hadoop 프로젝트 독립 출범 |
| 2013년 | Hadoop 2.2.0 발표, YARN 도입 (리소스 관리자) |
| 2014~2016년 | Spark, Flink, Mesos 등 다양한 분산 컴퓨팅 프로젝트 등장 |
Hadoop 시스템의 구성 요소
Hadoop은 HDFS, YARN, MapReduce를 기본 구성으로 하며, 각 요소는 독립적이어서 다양한 도구들과 조합해 유연하게 분산 시스템을 구성할 수 있다.

분산 파일 시스템 HDFS
HDFS는 Hadoop의 분산 파일 시스템이다.
- 데이터를 여러 컴퓨터(노드)에 복사하여 저장해 중복성과 신뢰성을 향상한다.
- 마치 네트워크 상의 파일 서버처럼 작동한다.
리소스 관리자 YARN
YARN은 Hadoop의 리소스 관리자이다.
- 클러스터 전체의 CPU, 메모리 등의 자원 사용을 통제한다.
- 각 애플리케이션이 사용하는 리소스를 컨테이너(Container) 단위로 관리한다.
- 실행 가능한 호스트를 골라 컨테이너를 할당하고 실행한다.
* YARN 컨테이너
YARN의 컨테이너는 운영 체제 수준의 가상화 기술이 아니라, 어떤 호스트에서 어떤 프로세스를 실행시킬 것인지를 결정하는 애플리케이션 수준의 기술이다. 쉽게 말해, 하드웨어 자원(CPU, 메모리 등)을 묶어서 하나의 작업 단위로 할당해주는 장치라고 보면 된다.
즉, YARN은 클러스터 전체를 바라보며, 각 애플리케이션에 얼마만큼의 자원을 할당할지 그리고 어느 노드에서 실행할지를 결정하고, 그 실행 단위를 컨테이너로 만들어 배포하는 것이다.

그림으로 이해해보자. 그림 3.4에는 두 개의 호스트(컴퓨터)가 있다. 각 호스트는 CPU, 메모리, 디스크를 가지고 있고 이 자원들이 YARN과 HDFS에 의해 관리된다.
| HDFS | 데이터 저장 담당, 데이터를 여러 호스트의 디스크에 중복 저장 |
| YARN | 리로스 관리 및 스케줄링 담당, 각 애플리케이션이 사용할 CPU와 메모리 관리 |
| 컨테이너 | CPU + 메모리 자원의 묶음 (논리적 실행 단위) |
본산 시스템은 많은 계산 리소스를 소비하지만, 호스트의 수에 따라 사용할 수 있는 리소스가 제한적이다. 한정된 리소스를 여러 애플리케이션이 동시에 사용하기 때문에, 리소스의 경합이 발생한다.
이때 YARN은 각 애플리케이션에 얼마만큼의 리소스를 할당할지 조정하며, 우선순위를 설정해 주요한 작업부터 자원을 배분한다. 이를 통해 불필요한 자원 낭비 없이 효율적이고 공정한 데이터 처리를 가능하게 한다.
분산 데이터 처리 엔진 MapReduce
MapReduce는 YARN 상에서 동작하는 분산 애플리케이션으로, 분산 시스템에서 데이터 처리를 실행하는 데 사용된다.
- 자바 기반으로 비구조화 데이터 처리에 적합하다.
- 대량의 데이터를 배치 처리하기 위한 시스템이다. 따라서 실행의 오버헤드가 커 짧은 쿼리의 반복에 부적합하다.
SQL 기반 분산 쿼리 엔진 Hive
Apache Hive는 쿼리 엔진 중 하나로, 쿼리를 자동으로 MapReduce 프로그램을 변환하는 소프트웨어로 개발되었다.
- SQL 질의를 MapReduce로 변환
- 사용자 친화적
- MapReduce와 마찬가지로 시간이 걸리는 배치 처리에는 적합하지만, 애드 혹 쿼리를 여러 번 실행하는 데는 부적합하다.

Hive on Tez
Hive의 성능을 개선하기 위해 개발된 Apache Tex 위에서 실행되는 Hive이다.
- MapReduce의 비효율을 극복하고 실행 속도를 높이기 위해 고안된 구조

기존의 MapReduce가 각 스테이지가 끝날 때까지 다음 처리를 못해 대기 시간이 발생했다면, Tez는 그렇지 않다. 스테이지 간의 대기 없이 앞에서 처리된 데이터를 바로 다음 스테이지로 전달한다. 이를 통해 전체 쿼리 실행 시간을 단축할 수 있었다.
| Hive on MapReduce | Hive on Tez | |
| 실행 방식 | 스테이지 순차 실행 | 스테이지 간 병렬 실행 |
| 대기 시간 | 스테이지마다 존재 | 최소화 |
| 처리 속도 | 느림 (오버헤드 큼) | 빠름 (동시성↑) |
Hive On Spark도 있다. Hive on Tez와 마찬가지로 속도 향상이 목적이고, 더 빠른 SQL 처리를 위한 진화형 구조로 소개되었다.
지금까지 비구조화된 데이터를 구조화하고 분석 가능한 형태로 만들기 위한 Hadoop 시스템과 엔진에 대해 알아보았다.Hive는 SQL을 기반으로 대용량 데이터를 처리할 수 있게 해주었지만 실행 속도가 느리고 짧은 쿼리나 반복적인 질의에 비효율적이라는 단점이 있었다.
이를 개선하기 위해 Hive on Tez, Hive on Spark와 같은 고속화 시도가 있었지만, 즉각적인 응답이 필요한 상황에는 여전히 한계가 존재했다.
이러한 상황 속에 등장한 것이 대화형 쿼리 엔진이다. 사용자가 보내는 질의에 대해 빠르고 실시간에 가까운 응답을 제공할 수 있도록 설계되었다.
| 대화형 쿼리 엔진
MapReduce와 Tez는 장시간의 배치 처리를 가정해 한정된 리소스를 유효하게 활용하도록 설계되어 있다. 하지만 대화형 쿼리 엔진은 순간 최대 속도를 높이기 위해 모든 오버헤드가 제거되어 사용할 수 있는 리소스를 최대한 활용해 쿼리를 실행한다. 그 결과, MPP와 비교해도 손색없는 응답 시간을 실현하고 있다.

대표적인 대화형 쿼리 엔진에는 Apache Impala와 Presto가 있다. 이러한 대화형 쿼리 엔진은 Hive를 거쳐 완성된 구조화 데이터를 대화식으로 집계하고자 할 때 사용된다.
Apache Impala
Hadoop 기반의 빠른 대화형 SQL 질의를 지원하는 쿼리 엔진
- 실시간 분석에 최적화 (Hive와 비교해 속도가 훨씬 빠름)
- MapReduce를 사용하지 않고 별도 실행 엔진으로 처리
- HDFS, Hive 메타스토어와 연동되어 있어 기존 Hadoop 인프라 그대로 사용 가능
- MPP 아키텍처 기반으로 여러 노드 간 병렬 실행
Presto
Facebook(Meta)에서 개발, 다양한 저장소에 분산된 데이터를 빠르게 질의할 수 있는 대화형 엔진
- 자체 실행 엔진으로 빠른 응답 제공
- HDFS, Hive, S3, MySQL, Kafka 등 다양한 데이터 소스에 질의 가능
- 단일 SQL 인터페이스를 사용해 다양한 데이터 소스에 질의 가능
- MPP 아키텍처 기반으로 여러 노드 간 병렬 실행
Hadoop에서는 이와 같이 성질이 다른 쿼리 엔진을 목적에 따라 구분한다. 대량의 비구조화 데이터를 가공하는 무거운 배치 처리에는 높은 처리량으로 리소스를 활용할 수 있는 Hive를 활용한다. 한편, 그렇게 해서 완성한 구조화 데이터를 대화식으로 집계하고자 할 때는 지연이 적은 Impala와 Presto 등이 적합하다.
[여기서 잠깐!] 대화형 쿼리 엔진을 설명할 때 왜 MPP가 계속 등장할까?
MPP는 Massively Parallel Processing의 준말로, 대규모 병렬 처리를 의미한다. 여러 개의 노드(서버)가 각자 데이터를 나눠서 동시에 처리하는 구조를 말하며 각 노드는 자기만의 CPU, 메모리, 스토리지를 가지고 있다. 즉, '하나의 큰 작업을 여러 컴퓨터가 나눠서 동시에 처리하는 방식'이다.

반대의 구조로는 SMP 구조도 있다.
| SMP (Symmetric Multi-Processing) | MPP (Massively Parallel Processing) | |
| 의미 | 하나의 서버(머신) 안에서 여러 CPU가 함께 처리 | 여러 개의 독립된 서버(노드)가 병렬로 처리 |
| 구조 | 공유 메모리, 공유 스토리지 | 각 노드가 CPU, 메모리, 스토리지를 모두 독립적으로 가짐 |
| 처리 방식 | 단일 시스템 내부의 병렬 처리 | 클러스터 기반 병렬 처리 |
| 확장성 | 하드웨어 확장에 한계 있음 (스케일 업) | 노드를 추가하면 확장 가능 (스케일 아웃) |
| 예시 | 전통적인 RDBMS (Oracle, MySQL 등) | Presto, Impala, BigQuery, Redshift 등 |
즉, MPP는 어떻게 처리하느냐 하는 구조를 말한다. MPP 구조는 대용량 데이터를 분산 저장하고 동시에 병렬로 처리해 속도가 빠르고, 사용자가 질의를 날리면 수 초 내 응답이 가능하다. 각 엔진을 비교해보면 아래와 같다.
| Hive (MapReduce 기반) | Presto, Impala (MPP 기반) | |
| 처리 방식 | 순차적, 단계별 실행 | 병렬 처리 |
| 속도 | 느림 (분 단위) | 빠름 (초 단위) |
| 용도 | 배치 분석 | 대화형 분석 |
대화형 쿼리 엔진들은 빠른 응답을 위해 MPP 구조를 채택하고, 리소스를 최대한 활용해 즉각적인 질의를 가능케 했다. 이런 흐름 속에서, 기존 디스크 중심의 MapReduce를 넘어 메모리를 활용해 성능을 극대화한 다른 접근 방식도 등장했다. 그것이 Apache Spark이다.
| Apache Spark
Spark는 대용량 데이터를 메모리 기반으로 빠르게 처리할 수 있도록 설계된 고속 분산 데이터 처리 엔진이다.

실행 구조를 살펴보자. 먼저 구성은 아래와 같다.
| 입력 데이터 HDFS | HDFS 또는 다른 저장소에 저장된 원본 데이터를 읽어온다. |
| YARN 또는 Mesos | Spark 애플리케이션을 실행하기 위한 클러스터 자원 관리 시스템이다. |
실행 흐름은 아래와 같다.
1. 입력 데이터 로딩
HDFS에서 입력 데이터를 불러온다.
2. Map (M)
데이터를 분산 처리하기 위한 첫 번째 연산 단계이다. 메모리에서 처리되며, 중간 결과를 디스크에 저장하지 않고 메모리 상에 유지한다.
3. Reduce 단계 (R)
- Map 단계의 결과를 받아 후속 연산을 수행한다.
- 디스크를 거치지 않고 네트워크 통신을 통해 직접 전달되거나 메모리에서 연속적으로 처리된다.
4. 중간 데이터
- Spark는 중간 결과 데이터를 디스크에 저장하지 않고 메모리에 보존한다.
- 필요에 따라디스크에 의도적으로 게시할 수 있지만, 기본적으로 메모리를 기반으로 처리한다.
5. 출력 데이터
- 최종 결과는 디스크(HDFS 등)에 저장된다.
Spark는 중간 데이터를 디스크에 쓰지 않기 때문에 I/O 병목이 줄어들고 속도가 향상된다. 또한 데이터를 메모리 상에서 직접 전달하거나 최소한의 통신만 사용해 네트워크 통신에 최적화 되어 있다.
구체적인 특징을 정리하면 아래와 같다.
| 처리 위치 | 메모리 중심 |
| 중간 데이터 저장 | 기본적으로 저장 안 함 (필요시 캐시) |
| 속도 | 빠름 |
| 장애 발생 시 | 처음부터 재실행 또는 캐시 활용 |
| 데이터 흐름 | 입력(HDFS) → 메모리(Map) → 메모리(Reduce) → 출력(HDFS) |
Spark는 대규모 배치 처리, 대화형 쿼리 실행, 실시간 스트리밍 처리까지 모두 지원하는 범용 데이터 처리 플랫폼이다. 기능을 어떻게 확장할 수 이쓴지 알아보자.
Spark SQL
- SQL 쿼리를 통해 데이터를 처리할 수 있도록 지원
- 대화형 쿼리 엔진처럼 사요 가능, 익숙한 SQL 문법으로 빠른 분석 가능
Spark Streaming
- 실시간 데이터 스트림을 처리하기 위한 기능
- 정적 데이터 분석 뿐 아니라 실시간 로그, 이벤트 처리 등에도 활용 가능
'Database' 카테고리의 다른 글
| [Database] 분산 처리 프레임워크 (4) 대화형 쿼리 엔진 Presto의 구조 (3) | 2025.07.30 |
|---|---|
| [Database] 분산 처리 프레임워크 (3) 구조화부터 비정규화까지: Hive로 완성하는 데이터 마트 구축 A to Z (1) | 2025.07.29 |
| [Database] 분산 처리 프레임워크 (1) 구조화 데이터 vs 비구조화 데이터 (1) | 2025.07.28 |
| [Database] 빅데이터 시대에 '열 기반 데이터베이스'가 중요한 이유는 무엇일까? (2) | 2025.07.25 |
| [Database] 데이터 마트의 기본 구조 (1) | 2025.07.22 |