아파치 스파크란? 빅데이터 입문자를 위한 가장 쉬운 입문서

목차

 

들어가며

앞 글에서 다룬 하둡(Hadoop)은 거대한 데이터를 여러 대의 컴퓨터에 나누어 저장하고 처리하는 길을 열었다.

 

그러나 하둡의 처리 방식인 맵리듀스(MapReduce)는 단계마다 디스크에 결과를 기록해 속도가 느렸다.

 

이 한계를 넘어서기 위해 등장한 것이 아파치 스파크(Apache Spark)이다.

 

스파크는 데이터를 디스크가 아니라 메모리에서 처리해 훨씬 빠른 속도를 낸다.

 

이 글은 스파크라는 이름을 처음 들어 보는 독자도 따라올 수 있도록 기초부터 설명한다.

 

스파크가 왜 등장했는지, 무엇이며 어떻게 빠른지, 그리고 지금 어디에 서 있는지를 차례로 다룬다.

맵리듀스는 너무 느렸다

단계마다 디스크에 쓰는 맵리듀스의 한계

하둡의 맵리듀스는 데이터를 맵 단계와 리듀스 단계로 나누어 처리한다.

 

문제는 각 단계가 끝날 때마다 중간 결과를 디스크에 기록한다는 점이다.

 

디스크는 메모리보다 읽고 쓰는 속도가 수십 배에서 수백 배 느리다.

 

따라서 여러 단계를 거치는 작업일수록 디스크 입출력에 많은 시간이 쌓인다.

 

맵리듀스는 한 번 훑고 끝나는 대규모 일괄 처리에는 적합했다.

 

그러나 같은 데이터를 여러 번 다루어야 하는 작업에서는 이 구조가 큰 약점이 되었다.

반복 연산이 많은 머신러닝에서 드러난 병목

맵리듀스의 약점이 가장 크게 드러난 분야는 머신러닝(machine learning, 기계 학습)이었다.

 

머신러닝의 많은 알고리즘은 같은 데이터를 수십 번에서 수백 번 반복해 계산한다.

 

반복할 때마다 디스크에서 데이터를 다시 읽어야 하므로 시간이 크게 늘어났다.

 

데이터를 탐색적으로 여러 번 조회하는 분석 작업에서도 같은 문제가 나타났다.

 

분 단위면 끝날 작업이 디스크 입출력 때문에 시간 단위로 늘어지는 일이 흔했다.

 

바로 이 반복 작업의 병목이 새로운 처리 방식을 요구하는 직접적인 계기가 되었다.

버클리 연구실에서 출발한 인메모리 엔진

스파크는 2009년 캘리포니아 대학교 버클리의 AMPLab이라는 연구실에서 시작되었다.

 

당시 박사과정 학생이던 마테이 자하리아가 맵리듀스의 속도 문제를 풀기 위해 개발하였다.

 

핵심 발상은 데이터를 디스크에 반복해 기록하지 않고 메모리에 올려 두고 재사용하는 것이었다.

 

메모리에서 데이터를 다루는 이 방식을 인메모리(in-memory, 메모리 내) 처리라 부른다.

 

스파크는 2010년에 오픈소스로 공개되었고, 2013년 아파치 소프트웨어 재단에 기증되었다.

 

이후 2014년 초 아파치의 최상위 프로젝트가 되면서 널리 쓰이기 시작하였다.

스파크는 저장하지 않고 계산만 한다

저장은 하둡에 맡기고 처리만 담당하는 엔진

흔히 스파크가 하둡을 대체했다고 오해하지만, 이는 정확하지 않다.

 

스파크가 대체한 것은 하둡 전체가 아니라 처리 엔진인 맵리듀스이다.

 

스파크 자체에는 데이터를 보관하는 저장 기능이 없다.

 

그래서 스파크는 HDFS(Hadoop Distributed File System, 하둡 분산 파일 시스템)나

 

아마존 S3 같은 외부 저장소에서 데이터를 읽어 온다.

 

즉 스파크는 저장을 남에게 맡기고 오직 계산에만 집중하는 처리 엔진이다.

 

이 때문에 스파크는 하둡 위에서 돌 수도 있고, 하둡 없이 다른 저장소와 함께 쓸 수도 있다.

데이터를 메모리에 올려 다루는 핵심 단위, RDD

스파크가 데이터를 다루는 가장 기본 단위는 RDD(Resilient Distributed Dataset, 회복 가능한 분산 데이터셋)이다.

 

RDD는 여러 대의 컴퓨터에 나뉘어 저장되는, 한 번 만들면 바뀌지 않는 데이터 묶음이다.

 

사용자는 RDD를 메모리에 올려 두고 여러 작업에서 반복해 재사용할 수 있다.

 

이 덕분에 매번 디스크에서 데이터를 다시 읽지 않아도 되어 속도가 크게 빨라진다.

 

다만 RDD는 다루기가 다소 복잡해, 오늘날에는 더 쉬운 데이터프레임(DataFrame)을 주로 쓴다.

 

데이터프레임은 표 형태로 데이터를 다루는 상위 도구이지만, 그 밑바탕은 여전히 RDD이다.

SQL, 스트리밍, 머신러닝을 한 엔진으로

스파크의 또 다른 강점은 여러 종류의 작업을 하나의 엔진에서 처리한다는 점이다.

 

스파크 SQL은 SQL(Structured Query Language, 데이터베이스 질의 표준 언어) 문법으로 데이터를 다루게 해 준다.

 

정형 스트리밍(Structured Streaming)은 실시간으로 흘러드는 데이터를 처리한다.

 

MLlib(Machine Learning Library, 머신러닝 라이브러리)은 분산 환경에서 머신러닝을 수행한다.

 

GraphX는 사람 관계망 같은 그래프 형태의 데이터를 계산한다.

 

과거에는 이런 작업마다 다른 도구가 필요했지만, 스파크는 이를 하나로 묶어 통합 엔진이 되었다.

빠름의 비결은 디스크가 아니라 메모리다

디스크를 거치지 않고 메모리에서 처리한다

스파크가 빠른 가장 근본적인 이유는 데이터를 메모리에서 처리하기 때문이다.

 

맵리듀스가 단계마다 디스크에 기록하는 것과 달리, 스파크는 중간 결과를 메모리에 유지한다.

 

메모리는 디스크보다 접근 속도가 훨씬 빠르므로 처리 시간이 크게 줄어든다.

 

특히 같은 데이터를 반복해 쓰는 작업에서 그 차이가 두드러진다.

 

여러 연구와 자료는 반복 작업에서 스파크가 맵리듀스보다 10배에서 100배 빠르다고 보고한다.

 

다만 데이터가 메모리에 다 들어가지 않으면 일부를 디스크로 내보내므로, 메모리 용량도 중요한 변수이다.

실행 전에 전체 작업을 설계도로 짠다

스파크는 작업을 요청받자마자 곧바로 실행하지 않는다.

 

대신 어떤 연산들이 어떤 순서로 이어지는지를 먼저 하나의 설계도로 그린다.

 

이 설계도를 방향성 비순환 그래프(DAG, Directed Acyclic Graph)라 부른다.

 

실제 계산은 결과가 필요한 순간에야 비로소 시작되는데, 이를 지연 실행(lazy evaluation)이라 한다.

 

전체 흐름을 미리 파악한 덕분에 스파크는 불필요한 단계를 줄인 효율적인 실행 계획을 세운다.

 

데이터프레임을 쓰면 카탈리스트(Catalyst)라는 최적화 도구가 이 계획을 자동으로 더 다듬어 준다.

복제 대신 계보를 따라 다시 계산한다

분산 시스템에서는 한 대의 컴퓨터가 고장 나는 일을 늘 대비해야 한다.

 

하둡의 HDFS는 데이터를 여러 벌 복제해 두는 방식으로 이 문제를 푼다.

 

스파크는 다른 방식을 쓰는데, 데이터를 복제하는 대신 그 데이터가 만들어진 과정을 기록해 둔다.

 

이 과정의 기록을 계보(lineage, 리니지)라 부른다.

 

어느 컴퓨터가 고장 나 데이터 일부가 사라지면, 스파크는 계보를 따라 그 부분만 다시 계산한다.

 

이 방식은 복제에 드는 저장 공간을 아끼면서도 고장에 대응할 수 있게 해 준다.

하둡 위에서도, 쿠버네티스 위에서도 돌아간다

스파크는 스스로 자원을 관리하지 않으므로, 자원을 배분해 줄 관리자가 따로 필요하다.

 

스파크는 자체 기본 관리자 외에 하둡의 YARN이나 쿠버네티스(Kubernetes) 위에서 돌 수 있다.

 

쿠버네티스는 프로그램을 컨테이너 단위로 묶어 배포하고 관리하는 기술의 표준이다.

 

과거에는 하둡의 YARN과 함께 쓰는 경우가 많았으나, 최근 신규 프로젝트는 쿠버네티스를 선호한다.

 

저장소 역시 HDFS, 아마존 S3, 카산드라(Cassandra), 카프카(Kafka) 등 다양한 곳에서 데이터를 읽어 올 수 있다.

 

이처럼 스파크는 특정 환경에 묶이지 않고 여러 인프라 위에서 유연하게 동작한다.

스파크는 빅데이터 처리의 표준이 되었다

파이썬으로 쓰는 스파크, 파이스파크의 시대

스파크는 스칼라(Scala), 자바(Java), 파이썬(Python), R 등 여러 언어를 지원한다.

 

이 가운데 파이썬으로 스파크를 다루는 파이스파크(PySpark)가 오늘날 가장 널리 쓰인다.

 

파이썬은 데이터 분석과 머신러닝 분야에서 사실상 표준 언어이기 때문이다.

 

파이스파크는 스파크 SQL, 데이터프레임, 스트리밍, MLlib 등 거의 모든 기능을 파이썬으로 제공한다.

 

또한 판다스(Pandas)에 익숙한 사용자를 위한 도구도 갖춰, 진입장벽을 낮추었다.

 

이런 접근성 덕분에 스파크는 전문 개발자뿐 아니라 데이터 과학자에게도 친숙한 도구가 되었다.

데이터브릭스와 레이크하우스의 핵심 엔진

스파크를 만든 사람들은 2013년 데이터브릭스(Databricks)라는 회사를 설립하였다.

 

데이터브릭스는 복잡한 클러스터 관리 없이 스파크를 쓸 수 있게 해 주는 상용 플랫폼이다.

 

이 회사는 데이터 레이크하우스(data lakehouse)라는 구조를 제안해 널리 퍼뜨렸다.

 

레이크하우스는 값싼 클라우드 저장소 위에서 스파크 같은 엔진으로 데이터를 분석하는 방식이다.

 

여기서 스파크는 데이터를 실제로 처리하는 핵심 연산 엔진 역할을 맡는다.

 

넷플릭스, 우버, 에어비앤비 같은 기업은 물론 나사와 유럽입자물리연구소에서도 스파크를 사용한다.

배치를 넘어 실시간 스트리밍까지

스파크는 본래 대량의 데이터를 모아 한 번에 처리하는 배치(batch, 일괄) 작업에 강했다.

 

정형 스트리밍 기능이 더해지면서, 스파크는 실시간으로 들어오는 데이터도 다룰 수 있게 되었다.

 

정형 스트리밍은 흘러드는 데이터를 끝없이 늘어나는 표처럼 취급한다.

 

그래서 배치 작업에 쓰던 코드를 거의 그대로 실시간 처리에 쓸 수 있다.

 

2026년 기준 최신 버전인 4.1에서는 응답 지연을 한 자릿수 밀리 초까지 줄이는 기능도 도입되었다.

 

이로써 스파크는 일괄 처리와 실시간 처리를 한 도구로 아우르게 되었다.

2026년, 스파크를 지금 배워야 할까

스파크는 현재 대규모 데이터 처리 분야에서 사실상의 표준으로 자리 잡았다.

 

2026년에도 활발히 개발되고 있으며, 최신 버전은 4.1이다.

 

새로 데이터 시스템을 구축할 때 처리 엔진으로 스파크를 택하는 경우가 가장 많다.

 

아마존 EMR, 구글 데이터프록 같은 클라우드 관리형 서비스로 손쉽게 쓸 수도 있다.

 

파이썬만 알아도 시작할 수 있어, 데이터를 다루려는 입문자에게 진입장벽이 낮은 편이다.

 

따라서 빅데이터를 다루려는 사람에게 스파크는 지금 배워 둘 가치가 분명한 기술이다.

나가며

스파크는 맵리듀스가 단계마다 디스크에 기록하느라 느렸던 문제에서 출발하였다.

 

그 해법은 데이터를 메모리에 올려 두고 재사용하는 인메모리 처리였다.

 

스파크는 저장 기능 없이 계산만 담당하는 엔진으로, HDFS나 클라우드 저장소에서 데이터를 읽어 온다.

 

메모리 처리와 설계도 기반 실행, 계보를 통한 복구가 스파크를 빠르고 안정적으로 만든다.

 

오늘날 스파크는 파이스파크와 데이터브릭스를 통해 빅데이터 처리의 표준으로 쓰인다.

 

하둡이 분산 데이터의 토대를 놓았다면, 스파크는 그 위에서 데이터를 빠르게 다루는 표준 도구가 되었다.

소제목

기원과 역사
Matei Zaharia (Wikipedia): https://en.wikipedia.org/wiki/Matei_Zaharia
Apache Spark (Wikipedia): https://en.wikipedia.org/wiki/Apache_Spark
A brief history of Databricks (Bigeye): https://www.bigeye.com/blog/a-brief-history-of-databricks
The Story Behind Apache Spark (Medium): https://medium.com/@itai.yaffe/i-havent-heard-it-through-the-grapevine-the-story-behind-apache-spark-2bb234089dd

 

핵심 개념 (RDD, 데이터프레임, 통합 엔진)
RDD Programming Guide (Apache Spark): https://spark.apache.org/docs/latest/rdd-programming-guide.html
Benefits and Features of RDDs (Carmatec): https://www.carmatec.com/blog/benefits-and-features-of-rdds-in-apache-spark/
RDD vs DataFrame vs Dataset (Baeldung): https://www.baeldung.com/java-spark-dataframe-dataset-rdd
PySpark Documentation (Apache Spark): https://spark.apache.org/docs/latest/api/python/index.html

 

빠른 처리의 원리 (인메모리, DAG, 계보)
Apache Spark Technical Deep Dive (Medium): https://medium.com/@jashvanth/apache-spark-a-technical-deep-dive-into-distributed-big-data-processing-f3d752b05266
Apache Spark Performance Tuning (Flexera): https://www.flexera.com/blog/finops/spark-performance-tuning/
Apache Spark Architecture (Instaclustr): https://www.instaclustr.com/education/apache-spark/apache-spark-architecture-concepts-components-and-best-practices/

 

배포 환경과 데이터 소스
Cluster Mode Overview (Apache Spark): https://spark.apache.org/docs/latest/cluster-overview.html
Cluster Managers for Apache Spark (Luminousmen): https://luminousmen.com/post/hadoop-yarn-spark/
Choosing the Right Spark Cluster Manager (Medium): https://medium.com/@kakarot1725/choosing-the-right-spark-cluster-manager-yarn-kubernetes-or-standalone-163441447ced

 

현재 동향 (Spark 4.x, 파이스파크, 데이터브릭스, 레이크하우스)
Introducing Apache Spark 4.1 (Databricks): https://www.databricks.com/blog/introducing-apache-sparkr-41
Introducing Apache Spark 4.0 (Databricks): https://www.databricks.com/blog/introducing-apache-spark-40
Databricks (Wikipedia): https://en.wikipedia.org/wiki/Databricks
Spark vs Hadoop 2026 (Tech Insider): https://tech-insider.org/spark-vs-hadoop-2026/