SPARK

Spark Core는 Apache Spark의 기본 실행 엔진이자 모든 다른 라이브러리(Spark SQL, Spark Streaming, MLlib, GraphX)의 기반이 되는 핵심 구성 요소이다. 이는 분산 작업 스케줄링, 메모리 관리, 장애 복구, 그리고 스토리지 시스템과의 상호작용과 같은 가장 기본적인 기능들을 제공한다. 다른 모든 고수준 API들은 결국 이 코어 엔진 위에서 실행된다.

Spark Core의 가장 핵심적인 추상화는 RDD이다. RDD는 변경 불가능한 분산 객체 컬렉션으로, 여러 컴퓨터의 클러스터에 걸쳐 분할되어 저장된다. RDD는 사용자가 명시적으로 지정한 파티션 단위로 데이터를 처리하며, 메모리나 디스크에 지속적으로 저장될 수 있다. 코어 엔진은 RDD의 생성, 변환, 그리고 최종 결과를 계산하는 액션 연산을 조율하는 역할을 담당한다.

이 엔진은 DAG 실행 엔진을 통해 작업을 최적화한다. 사용자가 정의한 RDD 변환 연산들은 하나의 방향성 비순환 그래프로 구성되고, 이 그래프는 스케줄러에 의해 여러 태스크로 분할되어 실행된다. 이 방식은 MapReduce와 같은 기존 모델보다 더 효율적인 실행 계획을 가능하게 하며, 특히 반복적인 알고리즘에서 성능 이점을 제공한다. 또한, 메모리 캐싱을 통해 중간 결과를 메모리에 저장함으로써 동일한 데이터셋에 대한 반복적인 접근 속도를 크게 향상시킨다.

Spark Core는 다양한 클러스터 관리자와 통합되어 실행될 수 있다. 이는 자체적인 스탠드얼론 클러스터 관리자를 포함하며, Apache Hadoop YARN, Apache Mesos, 그리고 Kubernetes와 같은 외부 관리자 위에서도 원활하게 동작한다. 또한, HDFS, Apache Cassandra, Amazon S3와 같은 다양한 데이터 소스로부터 데이터를 읽고 쓸 수 있는 기능을 내장하고 있다.

Spark SQL은 Apache Spark의 구성 요소 중 하나로, 구조화된 데이터 처리를 위한 모듈이다. 이 모듈은 사용자가 표준 SQL 쿼리와 DataFrame API를 사용하여 데이터를 쿼리할 수 있게 해준다. Spark SQL의 핵심 목표는 관계형 처리와 함수형 프로그래밍을 통합된 API로 제공하여 다양한 데이터 소스를 효율적으로 처리하는 것이다.

Spark SQL은 Hive와의 호환성을 제공하는 HiveQL을 지원하며, 기존 Hive 메타스토어, 테이블, UDF(사용자 정의 함수)를 그대로 사용할 수 있다. 또한 JSON, Parquet, ORC, JDBC 등 다양한 데이터 소스에 대한 통합 인터페이스를 제공한다. 내부적으로 Catalyst 최적화 엔진을 사용하여 쿼리 실행 계획을 생성하고 최적화하며, Tungsten 프로젝트의 바이트코드 생성 및 오프-힙 메모리 관리 기능을 활용하여 높은 성능을 달성한다.

사용자는 Spark SQL을 통해 두 가지 주요 API를 사용할 수 있다. 첫 번째는 익숙한 SQL 구문을 사용하는 것이고, 두 번째는 DataFrame 및 Dataset API를 사용하는 프로그래밍 방식이다. 두 방식 모두 동일한 실행 엔진을 공유하므로 성능 차이가 발생하지 않는다. Spark SQL은 배치 처리와 Spark Streaming을 통한 스트리밍 처리 모두에서 구조화된 데이터를 처리하는 데 사용될 수 있다.

주요 기능은 다음과 같다.

Spark Streaming은 Apache Spark의 핵심 구성 요소 중 하나로, 실시간 데이터 스트림을 처리하기 위한 라이브러리이다. 이는 마이크로 배치(micro-batch) 아키텍처를 기반으로 작동하여, 들어오는 실시간 데이터를 짧은 간격(예: 1초, 2초)의 배치로 나누어 처리한다. 이 방식은 Spark Core 엔진의 강력한 배치 처리 능력과 RDD 모델을 그대로 활용할 수 있게 해준다. 결과적으로 개발자는 배치 처리와 동일한 API와 프로그래밍 모델을 사용하여 스트림 처리 애플리케이션을 작성할 수 있다.

주요 추상화 객체는 DStream(Discretized Stream)이다. DStream은 일정 시간 간격으로 생성된 일련의 RDD로 표현되는 연속적인 데이터 스트림이다. 사용자는 마치 정적인 RDD 컬렉션을 다루듯이 map, reduce, join, window 등의 고수준 연산을 DStream에 적용할 수 있다. 내부적으로 Spark Streaming은 이러한 연산들을 각 배치 간격에 해당하는 RDD들에 변환 연산으로 적용하고, Spark Core 엔진을 통해 분산 병렬 실행한다.

이 라이브러리는 다양한 실시간 데이터 소스와 싱크를 지원한다. 주요 입력 소스로는 Kafka, Flume, Kinesis, HDFS, TCP 소켓 등이 있다. 처리된 결과는 다시 Kafka나 Flume 같은 메시지 큐로, 또는 HDFS, 데이터베이스 등 다양한 외부 저장 시스템으로 출력될 수 있다. 또한 상태 유지가 필요한 스트림 처리(예: 사용자 세션별 클릭 수 집계)를 위한 updateStateByKey나 mapWithState와 같은 연산도 제공한다.

Spark Streaming의 마이크로 배치 모델은 엄격한 저지연(1ms 미만)이 요구되는 경우보다는, 초 단위의 지연 시간이 허용되면서도 높은 처리량과 장애 복구 능력이 필요한 사용 사례에 적합하다. 예를 들어, 실시간 대시보드, 이상 감지, 실시간 ETL 파이프라인 등에 널리 사용된다. 이후 Apache Spark는 지연 시간을 더욱 줄인 진정한 의미의 스트리밍 처리 엔진인 Structured Streaming을 도입하였다.

MLlib는 Apache Spark의 핵심 구성 요소 중 하나로, 대규모 데이터에 대한 머신러닝 작업을 분산 환경에서 효율적으로 수행할 수 있도록 설계된 확장 가능한 라이브러리이다. 이 라이브러리는 RDD와 DataFrame 기반의 API를 제공하며, 분류, 회귀 분석, 클러스터링, 협업 필터링, 차원 축소 등 다양한 머신러닝 알고리즘을 포함하고 있다. MLlib의 주요 목표는 Spark의 인메모리 컴퓨팅 엔진을 활용하여 반복적인 알고리즘 연산 속도를 획기적으로 높이고, 사용자가 손쉽게 엔드투엔드 머신러닝 파이프라인을 구축할 수 있도록 하는 것이다.

MLlib는 크게 두 가지 주요 API를 제공한다. 첫 번째는 원시 데이터를 직접 다루는 'RDD 기반 API'이다. 두 번째는 Spark SQL과 통합되어 구조화된 데이터를 효율적으로 처리하며, 파이프라인 개념을 도입한 'DataFrame 기반 API'이다. DataFrame 기반 API는 피처 추출, 변환, 선택, 머신러닝 모델 추정 등 여러 단계를 하나의 워크플로우로 구성할 수 있는 파이프라인 객체를 중심으로 설계되었다. 이를 통해 데이터 전처리부터 모델 학습, 평가, 튜닝까지의 과정을 체계적으로 관리하고 재현할 수 있다.

MLlib가 제공하는 주요 기능은 다음과 같이 분류할 수 있다.

이 라이브러리의 장점은 Spark의 분산 처리 능력과 통합되어 있어, 디스크 기반의 전통적인 도구들보다 훨씬 빠르게 대용량 데이터에 대한 모델 학습과 예측을 수행할 수 있다는 점이다. 또한, 파이썬, 스칼라, 자바, R 언어를 모두 지원하여 넓은 범위의 사용자 층을 포용한다. 그러나 매우 깊은 신경망을 요구하는 딥러닝 작업에는 특화되지 않았으며, 이러한 영역은 TensorFlow나 PyTorch와 같은 별도의 프레임워크와의 연동을 통해 보완되는 경우가 많다[2].

GraphX는 Apache Spark의 구성 요소 중 하나로, 대규모 그래프 데이터를 처리하고 분석하기 위한 분산 그래프 처리 라이브러리입니다. 이 라이브러리는 Spark Core의 RDD 추상화를 기반으로 구축되어, Pregel과 같은 그래프 처리 모델과 MapReduce 스타일의 데이터 병렬 처리를 통합합니다. GraphX는 정점과 간선으로 구성된 그래프 데이터 구조를 효율적으로 표현하고, 이를 활용한 다양한 그래프 알고리즘을 실행할 수 있는 API를 제공합니다.

GraphX의 핵심 데이터 구조는 속성 그래프입니다. 속성 그래프는 각 정점과 간선에 사용자 정의 속성을 첨부할 수 있는 방향성 다중 그래프입니다. 이는 정점과 간선에 추가 데이터(예: 사용자 프로필, 관계 가중치)를 저장할 수 있어 실세계 데이터 모델링에 유용합니다. GraphX는 이러한 그래프를 분산 환경에서 효율적으로 저장하고 조작하기 위해 정점과 간선을 파티션으로 나누어 관리합니다.

주요 기능으로는 그래프 생성, 변환, 조인 연산과 같은 기본적인 그래프 연산과 함께, 널리 알려진 그래프 알고리즘들의 최적화된 구현체를 포함합니다. 제공되는 알고리즘에는 다음과 같은 것들이 있습니다.

GraphX는 그래프를 위한 전용 API와 함께, 그래프를 RDD나 DataFrame으로 변환하여 Spark SQL이나 MLlib과 같은 다른 Spark 구성 요소와 연동하는 기능도 지원합니다. 이를 통해 사용자는 그래프 분석 결과를 다시 테이블 형태로 변환하여 SQL 쿼리를 수행하거나, 머신러닝 모델의 입력 데이터로 활용하는 복합적인 데이터 파이프라인을 구성할 수 있습니다. 이는 단일 처리 엔진 내에서 그래프 처리와 일반 데이터 처리 작업을 통합한다는 Spark의 철학을 잘 반영합니다.

RDD는 분산 컴퓨팅 환경에서 데이터를 표현하는 기본 추상화 단위이다. RDD는 불변성을 가지는 읽기 전용 데이터 집합으로, 여러 노드에 걸쳐 분할되어 저장된다. 이 분산된 데이터 조각을 파티션이라고 부른다.

RDD의 핵심 특성은 회복 탄력성이다. RDD는 데이터 자체를 저장하지 않고, 데이터를 생성하기 위한 일련의 변환 연산 기록을 저장한다. 이 기록을 Lineage라고 한다. 클러스터의 특정 노드에 장애가 발생하여 데이터 파티션을 잃어버리더라도, Lineage 정보를 바탕으로 해당 파티션만 다시 계산하여 복구할 수 있다. 이는 데이터의 복제본을 지속적으로 유지하는 방식보다 훨씬 효율적이다.

RDD의 주요 장점은 다음과 같다.

이러한 특성 덕분에 RDD는 반복 알고리즘과 대화형 데이터 분석 작업에 특히 적합하다. 예를 들어, 머신러닝 알고리즘은 동일한 데이터셋에 대해 반복적인 계산을 수행하는데, RDD의 메모리 캐싱 기능은 이러한 작업의 성능을 크게 개선시켰다.

RDD는 크게 두 가지 방식으로 생성됩니다. 첫째, 외부 데이터 소스(예: HDFS, 로컬 파일 시스템, Cassandra, HBase)에서 데이터를 읽어 생성하는 방법입니다. SparkContext의 textFile(), wholeTextFiles(), sequenceFile() 등의 메서드를 사용합니다. 둘째, 드라이버 프로그램에서 이미 존재하는 스칼라, 파이썬 또는 자바 컬렉션(예: 리스트, 세트)을 parallelize() 또는 makeRDD() 메서드로 변환하여 생성하는 방법입니다.

변환 연산은 기존 RDD로부터 새로운 RDD를 생성하는 지연 실행(lazy) 연산입니다. 주요 변환 연산은 다음과 같습니다.

이러한 변환 연산은 비순환 방향 그래프 형태의 실행 계획을 구성하기만 하고, 실제 계산은 액션 연산이 호출될 때까지 시작되지 않습니다. 이 지연 실행 모델은 불필요한 중간 결과물 저장을 피하고, 전체 작업 흐름을 최적화할 수 있는 기회를 제공합니다[3].

액션 연산은 RDD나 DataFrame 등의 데이터셋에 대해 실제 계산을 수행하고 결과를 드라이버 프로그램으로 반환하거나 외부 저장소에 저장하는 작업을 의미한다. 변환 연산이 지연 실행되는 반면, 액션 연산은 호출되는 즉시 연산 그래프를 실행시키는 트리거 역할을 한다.

주요 액션 연산으로는 데이터 수집, 집계, 저장 등이 있다. 대표적인 예는 다음과 같다.

액션 연산이 호출되면 Spark는 지연 실행되었던 모든 변환 연산들의 계보를 확인하고, 최적화된 실행 계획을 수립한 후 클러스터에서 작업을 분산 실행한다. 결과는 단일 값, 배열, 혹은 외부 저장 시스템에 쓰여진 파일 형태로 나타난다. reduce나 aggregate 같은 액션은 셔플 과정을 유발할 수 있으며, 이는 성능에 중요한 영향을 미친다. 따라서 액션 연산의 사용은 필요한 최종 결과를 얻는 데 꼭 필요한 시점에 신중하게 이루어져야 한다.

초기 RDD API는 유연성을 제공했지만, 개발자가 데이터의 구조를 명시적으로 정의하고 최적화를 수동으로 수행해야 하는 부담이 컸다. 특히 SQL과 같은 선언형 언어에 익숙한 데이터 분석가나 엔지니어에게는 함수형 프로그래밍 스타일의 RDD API가 진입 장벽으로 작용했다.

이러한 배경에서 2013년에 도입된 Spark SQL과 DataFrame API는 RDD 위에 구조화된 데이터 추상화 계층을 제공했다. 이는 RDD의 장점인 분산 처리와 내결함성을 유지하면서, 데이터 스키마를 명시적으로 정의함으로써 카탈리스트 옵티마이저와 같은 고급 쿼리 최적화 엔진의 적용을 가능하게 했다. 사용자는 컬럼 이름과 데이터 타입을 가진 테이블 형태로 데이터를 다룰 수 있게 되었다.

구조적 API의 등장은 스파크의 사용성을 크게 확장시켰다. 사용자는 더 이상 저수준의 RDD 변환 연산을 작성할 필요 없이, 친숙한 SQL 구문이나 도메인 특화 언어(DSL)를 사용하여 복잡한 데이터 처리 작업을 표현할 수 있게 되었다. 또한, 최적화 엔진이 자동으로 필터 푸시다운, 조인 재정렬, 불필요한 계산 생략 등의 최적화를 수행하여 성능을 크게 향상시켰다.

결과적으로, 구조적 API는 스파크를 단순한 분산 처리 엔진에서 대규모 구조화 데이터를 위한 통합 분석 플랫폼으로 진화시키는 핵심 계기가 되었다. 이는 이후 Dataset API의 등장으로 이어져 정적 타입 안정성과 RDD의 함수형 API 장점을 결합하는 토대를 마련했다.

RDD는 스파크의 기본적인 분산 데이터 추상화로, 개발자가 저수준의 변환과 액션을 직접 제어할 수 있는 유연성을 제공한다. 그러나 RDD는 스키마 정보가 없어 구조적 API의 최적화 기회를 활용하지 못하며, 직렬화와 역직렬화 과정에서 성능 오버헤드가 발생할 수 있다. 특히 자바 가상 머신 기반의 객체로 처리되기 때문에 가비지 컬렉션의 부담이 크고, 메모리 사용 효율이 낮은 편이다.

반면 데이터프레임은 명명된 열을 가진 테이블 형태의 구조적 데이터 추상화다. 각 열의 데이터 타입과 전체 스키마를 명시적으로 정의함으로써 스파크 SQL의 카탈리스트 옵티마이저가 효율적인 실행 계획을 수립할 수 있게 한다. 이 최적화 과정에는 조건절 푸시다운, 필터링, 공통 표현식 제거 등이 포함되어, 개발자가 작성한 코드와 실제 실행 계획 사이에 큰 차이가 발생할 수 있다.

다음 표는 두 데이터 추상화의 주요 차이점을 요약한다.

결과적으로, 대부분의 데이터 처리 작업에서는 데이터프레임 API를 사용하는 것이 성능과 사용 편의성 측면에서 유리하다. RDD는 여전히 사용자 정의 파티셔닝이나 매우 특수한 저수준 제어가 필요한 경우에 한해 활용된다. 스파크의 발전 방향은 구조적 API를 중심으로 이루어지고 있으며, 데이터세트 API는 데이터프레임의 성능과 RDD의 타입 안정성을 결합한 진화된 형태로 제공된다.

Dataset API는 DataFrame의 구조적 최적화 이점과 RDD의 타입 안정성 및 객체 지향 프로그래밍 스타일을 결합한 강력한 인터페이스를 제공한다. Dataset은 정적 타입 언어인 Scala와 Java에서 사용 가능하며, 동적 타입 언어인 Python과 R에서는 완전한 타입 안정성을 지원하지 않는다[4].

Dataset의 핵심 장점은 컴파일 타임에 스키마와 데이터 타입 오류를 검출할 수 있다는 점이다. DataFrame은 Row 객체로 표현되는 비정형 데이터를 다루지만, Dataset은 사용자가 정의한 도메인 특화 객체(Domain-specific Object)로 작업한다. 예를 들어, Dataset<Person>을 정의하면 각 레코드는 Person 클래스의 인스턴스가 되며, name이나 age 같은 필드에 접근할 때 컴파일러가 타입을 검증한다. 이는 잘못된 필드명 사용이나 타입 불일치로 인한 런타임 오류를 사전에 방지하여 애플리케이션의 안정성을 크게 높인다.

내부적으로 Dataset은 인코더(Encoder)라는 구성 요소를 사용하여 JVM 객체와 Spark SQL의 내부 바이너리 형식 간의 효율적인 변환을 수행한다. 인코더는 직렬화/역직렬화를 처리하며, Java 직렬화나 Kryo보다 훨씬 빠르고 메모리 효율적이다. 이는 타입 안정성을 유지하면서도 DataFrame과 동등한 수준의 성능 최적화를 가능하게 하는 기반 기술이다.

따라서 복잡한 비즈니스 로직이나 타입에 민감한 데이터 처리 파이프라인을 구축할 때 Dataset API는 개발 생산성과 런타임 안정성 측면에서 유리하다.

스탠드얼론 모드는 Apache Spark를 실행하기 위한 가장 기본적인 클러스터 관리 모드이다. 이 모드에서는 Spark 자체에 내장된 독립적인 클러스터 관리자가 자원 할당과 작업 스케줄링을 담당한다. 사용자는 별도의 클러스터 관리자(Apache Mesos나 Hadoop YARN 등)를 설치하거나 설정할 필요 없이, Spark 패키지만으로도 마스터 노드와 워커 노드를 구성하여 클러스터를 구동할 수 있다.

이 모드의 구성은 간단하다. 하나의 머신을 마스터 노드로 지정하고, 다른 머신들을 워커 노드로 등록하면 된다. 마스터 노드는 start-master.sh 스크립트로, 워커 노드는 start-worker.sh 스크립트를 사용하여 시작한다. 워커 노드는 마스터 노드의 URL을 인자로 받아 연결을 설정한다. 클러스터의 상태는 마스터 노드의 웹 UI(기본 포트 8080)를 통해 모니터링할 수 있다.

스탠드얼론 모드는 학습, 테스트, 또는 소규모 프로덕션 환경에 적합하다. 외부 의존성이 적어 초기 설정이 쉽고, Spark의 모든 기능을 빠르게 시험해 볼 수 있다는 장점이 있다. 그러나 고가용성(HA)을 위한 추가 설정이 필요하며, Hadoop YARN이나 Kubernetes와 같은 전문 클러스터 관리자에 비해 다중 테넌시 지원이나 다른 프레임워크와의 자원 공유 측면에서 기능이 제한적이다.

Apache Mesos는 클러스터 자원을 추상화하고 효율적으로 관리하는 오픈 소스 클러스터 관리자이다. Apache Spark는 Mesos를 클러스터 관리자로 사용하여 CPU, 메모리, 기타 자원을 동적으로 할당받고 실행할 수 있다. 이 방식은 스탠드얼론 모드보다 더 유연한 자원 공유가 가능하며, Hadoop YARN과 유사한 중앙 집중식 관리의 이점을 제공한다.

Spark 애플리케이션을 Mesos에서 실행할 때는 두 가지 모드[5]를 선택할 수 있다. 세분화 모드(fine-grained)에서는 각 Spark 작업이 개별 Mesos 작업으로 실행되어 매우 세밀한 자원 공유가 가능하지만, 스케줄링 오버헤드가 증가할 수 있다. 반면, 거친 모드(coarse-grained)에서는 전체 Spark 실행기가 하나의 Mesos 작업으로 장기 실행되어 시작 지연 시간을 줄이고 처리량을 높인다.

Mesos는 마스터-에이전트 아키텍처를 기반으로 한다. Spark는 Mesos 마스터에 연결하여 자원 제안을 받고, 해당 자원을 사용하여 드라이버와 실행기 프로세스를 시작한다. 이를 통해 Mesos 클러스터에서 실행 중인 다른 프레임워크(예: Apache Marathon, Chronos)와 자원을 효율적으로 공유하며 동작할 수 있다. 그러나 이후 Kubernetes의 부상과 함께 Mesos의 인기는 상대적으로 감소하는 추세를 보인다.

Apache Hadoop YARN은 Hadoop 2.0부터 도입된 클러스터 자원 관리 및 작업 스케줄링 프레임워크이다. Apache Spark는 YARN을 클러스터 관리자로 사용하여 Hadoop 클러스터 상에서 실행될 수 있다. 이 모드에서는 YARN이 클러스터의 CPU, 메모리 등 자원을 중앙에서 관리하고, Spark 애플리케이션은 YARN에게 자원을 요청하여 실행한다. 이를 통해 기존 HDFS와 YARN 인프라를 그대로 활용하면서 Spark의 고성능 처리 엔진을 도입할 수 있다.

YARN 상에서 Spark 애플리케이션은 두 가지 모드로 실행된다. 클라이언트 모드에서는 Spark 드라이버가 클라이언트 머신(예: 사용자의 로컬 컴퓨터)에서 실행된다. 클러스터 모드에서는 드라이버가 YARN ApplicationMaster 내부에서 실행되어, 클러스터 노드 중 하나에서 작동한다. 클러스터 모드는 장시간 실행되는 작업이나 사용자 클라이언트의 연결이 끊겨도 지속되어야 하는 작업에 더 적합하다.

YARN을 사용할 때의 주요 장점은 다음과 같다.

반면, YARN은 Apache Mesos나 Kubernetes에 비해 동적 자원 할당 기능이 제한적일 수 있으며, 주로 Hadoop 에코시스템에 최적화되어 있다는 특징이 있다. 따라서 이미 안정적인 Hadoop 클러스터를 보유하고 있는 조직에서는 YARN이 Spark 실행을 위한 실용적이고 강력한 선택지가 된다.

Apache Spark는 Kubernetes를 공식 지원하는 클러스터 관리자 중 하나로 활용할 수 있다. 이 모드에서는 Spark 애플리케이션의 드라이버와 익스큐터가 Kubernetes 파드(Pod)로 실행된다. 사용자는 spark-submit 명령을 통해 애플리케이션을 직접 Kubernetes 클러스터에 제출할 수 있으며, Spark는 내부적으로 Kubernetes API와 상호작용하여 필요한 파드들을 생성하고 관리한다.

이 실행 모드의 주요 장점은 통합된 컨테이너 오케스트레이션 환경을 활용할 수 있다는 점이다. 기존 Hadoop YARN이나 Apache Mesos에 비해 Docker 컨테이너 기반의 배포와 관리를 표준화할 수 있으며, 특히 클라우드 네이티브 환경에서 다른 마이크로서비스와 동일한 플랫폼 상에서 Spark 작업을 운영할 수 있어 관리 효율성이 높다. 또한, Kubernetes의 자동 스케일링 기능을 활용하여 리소스를 탄력적으로 조절할 수 있다.

초기 버전에서는 몇 가지 제약 사항이 있었으나, 지속적인 개발을 통해 안정성과 기능이 개선되고 있다. Kubernetes 모드는 Spark 애플리케이션을 컨테이너화된 워크로드로 통합하려는 현대적인 데이터 처리 아키텍처에서 점차 중요한 옵션이 되고 있다.

SPARK는 인메모리 컴퓨팅을 핵심으로 하여 Hadoop MapReduce에 비해 월등한 성능을 제공한다. 이 성능 향상의 근간에는 효율적인 메모리 관리와 데이터 캐싱 전략이 자리 잡고 있다. SPARK는 실행 중인 애플리케이션(Spark 애플리케이션)에게 할당된 JVM 힙 메모리를 여러 목적을 위해 논리적으로 구분하여 관리한다.

메모리는 크게 저장(Storage) 영역과 실행(Execution) 영역으로 나뉜다. 저장 영역은 주로 RDD의 캐시된 파티션을 저장하는 데 사용되며, 실행 영역은 셔플, 조인, 정렬 등의 연산을 수행할 때 발생하는 중간 데이터를 위한 공간이다. 두 영역 사이의 경계는 고정되지 않고 애플리케이션의 필요에 따라 동적으로 변경된다. 한 영역의 메모리가 부족하면 다른 영역의 여유 공간을 사용할 수 있으며, 두 영역 모두 가득 차면 디스크로 데이터를 내보내(스풀링) 작업을 계속한다. 이 유연한 메모리 관리 모델은 Unified Memory Manager에 의해 구현된다.

데이터 캐싱은 SPARK의 가장 강력한 기능 중 하나이다. 사용자는 자주 재사용되는 RDD, DataFrame, 또는 Dataset에 persist() 또는 cache() 메서드를 호출하여 메모리나 디스크에 지속시킬 수 있다. 캐싱 수준(Storage Level)을 지정함으로써 성능과 안정성, 메모리 사용량 사이의 트레이드오프를 제어할 수 있다. 주요 저장 수준은 다음과 같다.

적절한 캐싱 전략은 작업의 반복성과 데이터 크기, 클러스터 자원에 따라 결정된다. 예를 들어, 작은 데이터셋을 여러 번 재사용한다면 MEMORY_ONLY가 이상적이지만, 메모리보다 큰 데이터셋을 다룰 때는 MEMORY_AND_DISK_SER가 더 실용적인 선택이 될 수 있다. SPARK는 LRU 알고리즘을 기반으로 캐시된 데이터를 관리하여 메모리 공간이 부족할 때 가장 오래전에 사용된 파티션을 제거한다.

파티셔닝은 RDD나 DataFrame의 데이터를 클러스터 내 여러 노드에 분산시키는 논리적 단위를 정의하는 작업이다. 적절한 파티셔닝은 데이터의 지역성을 높이고 불필요한 네트워크 통신을 줄여 성능을 크게 향상시킨다. Spark는 기본적으로 해시 파티셔닝과 범위 파티셔닝을 제공하며, 사용자는 repartition()이나 coalesce() 변환 연산을 통해 파티션 수를 조정하거나, partitionBy()를 사용해 사용자 정의 파티셔너를 적용할 수 있다. 특히 조인이나 그룹화 연산 전에 자주 사용되는 키로 데이터를 미리 파티셔닝해 두면 셔플 비용을 줄일 수 있다.

셔플은 파티션 간 데이터 재분배가 필요한 연산(예: join, groupByKey, reduceByKey)에서 발생하는 과정이다. 이 과정은 네트워크를 통해 대량의 데이터를 이동시켜야 하므로 비용이 매우 크다. 셔플 최적화의 핵심은 이동해야 할 데이터의 양을 최소화하고, 셔플 쓰기 및 읽기 단계의 효율성을 높이는 것이다. reduceByKey나 aggregateByKey는 groupByKey보다 선호되는데, 이는 맵 사이드에서 콤바이너를 실행하여 셔플 전에 데이터를 부분적으로 집계하기 때문이다.

또한, spark.sql.shuffle.partitions 구성은 Spark SQL 작업의 기본 셔플 파티션 수를 제어하며, 데이터 크기와 클러스터 리소스에 맞게 조정해야 한다. 적절한 파티션 크기는 보통 100MB에서 200MB 사이를 목표로 한다. 실행 계획을 분석하여 셔플이 예상보다 많이 발생하는 지점을 찾고, 데이터 스큐가 심한 키에 대한 처리는 솔트 기법을 적용하는 것도 고려할 수 있다.

실행 계획 분석은 Spark SQL 또는 DataFrame API를 사용할 때 쿼리 최적화 과정을 이해하고 성능 병목 현상을 진단하는 핵심 도구이다. 개발자는 explain() 메서드를 호출하여 Spark가 쿼리를 실행하기 위해 생성한 논리적 및 물리적 실행 계획을 확인할 수 있다. 이 계획은 쿼리가 어떤 단계로 변환되고, 어떤 연산자가 사용되며, 데이터가 어떻게 이동하는지를 상세히 보여준다.

실행 계획은 일반적으로 여러 단계로 출력된다. 먼저 논리적 계획은 사용자가 작성한 코드를 카탈리스트 옵티마이저가 분석하여 최적화하기 전의 초기 관계형 연산 트리를 보여준다. 다음으로 최적화된 논리적 계획은 카탈리스트 옵티마이저가 조건식 푸시다운, 불필요한 열 제거, 조인 재정렬 등의 규칙 기반 최적화를 적용한 결과를 표시한다. 마지막으로 물리적 계획은 최적화된 논리적 계획을 클러스터에서 실제로 실행 가능한 단위인 RDD 변환 연산으로 매핑한 것이다. 물리적 계획 단계에서는 브로드캐스트 조인 사용 여부나 특정 집계 연산 방식과 같은 비용 기반 최적화의 선택 사항도 확인할 수 있다.

explain() 메서드에는 여러 모드가 존재하여 상세도를 조절할 수 있다. 기본 모드는 물리적 계획만 간략히 보여주지만, explain("extended")를 사용하면 논리적 계획부터 최적화된 논리적 계획, 물리적 계획까지 모두 확인할 수 있다. 실행 계획을 분석할 때는 주로 비용이 높은 셔플 연산이나 전체 데이터 스캔이 발생하는 지점, 예상치 못한 조인 방식, 필터 조건이 적절히 적용되지 않는 부분 등을 집중적으로 검토한다. 이를 통해 데이터 파티셔닝 전략을 조정하거나 임시 캐싱을 적용하는 등 최적화 방향을 결정할 수 있다.

SPARK는 분산 컴퓨팅 프레임워크로서, 대규모 데이터를 효율적으로 처리하는 데 특화되어 있다. 초기 버전부터 핵심 강점으로 여겨진 배치 처리 능력은 RDD 모델과 메모리 내 연산을 통해 기존 MapReduce 기반 시스템보다 수십 배 빠른 성능을 제공한다. 이는 반복적인 알고리즘(예: 머신러닝 학습)이나 복잡한 다단계 ETL 작업에 특히 효과적이다.

배치 처리 작업은 일반적으로 HDFS, Amazon S3, Apache HBase와 같은 분산 저장 시스템에 저장된 정적 데이터를 대상으로 한다. SPARK는 이러한 데이터를 읽어 여러 노드에 분산시킨 후, 맵(map), 필터(filter), 리듀스(reduce)와 같은 고수준 변환 연산을 적용하여 결과를 생성한다. 메모리에 데이터를 유지하면서 연산을 수행할 수 있어, 중간 결과를 디스크에 반복적으로 쓰는 방식보다 훨씬 빠르다.

주요 사용 사례로는 웹 로그 분석, 금융 거래 내역 집계, 과학 시뮬레이션 데이터 처리, 대용량 텍스트 마이닝 등이 있다. SPARK SQL과 DataFrame API의 등장으로 SQL 쿼리 실행과 구조화된 데이터 처리가 더욱 용이해졌으며, 이는 복잡한 배치 작업을 선언적이고 간결하게 작성할 수 있게 한다.

이러한 배치 처리 능력은 SPARK를 데이터 웨어하우스 구축, 데이터 레이크 분석, 배치 파이프라인 구동을 위한 핵심 인프라로 자리매김하게 했다.

SPARK의 실시간 스트림 처리는 Spark Streaming 컴포넌트를 통해 이루어진다. 이는 마이크로 배치(micro-batch) 아키텍처를 기반으로, 들어오는 실시간 데이터 스트림을 짧은 시간 간격(예: 1초, 2초)의 연속적인 RDD로 나누어 처리한다. 이 방식은 일괄 처리용으로 작성된 동일한 Spark Core 엔진과 API를 재사용할 수 있어 개발과 유지보수가 간편하다는 장점이 있다. 결과적으로, 사용자는 배치 처리 애플리케이션과 거의 동일한 코드로 스트림 처리 로직을 작성할 수 있다.

처리 과정은 크게 수신, 변환, 출력 단계로 나눌 수 있다. 먼저 Kafka, Flume, Kinesis 또는 TCP 소켓과 같은 소스로부터 데이터를 수신한다. 수신된 데이터 스트림은 DStream(Discretized Stream)이라는 고수준 추상화 객체로 표현되며, 이는 일련의 RDD로 구성된다. 이후 map, reduce, join, window 등의 연산을 적용하여 데이터를 변환하고, 최종 결과는 파일 시스템, 데이터베이스 또는 실시간 대시보드로 출력된다.

보다 낮은 지연 시간이 요구되는 사용 사례를 위해, Apache Spark 2.3 버전부터는 Structured Streaming API가 정식으로 도입되었다. 이는 Spark SQL 엔진 위에 구축되어 무한한 테이블에 대한 증분 쿼리로 스트림 처리를 모델링한다. Structured Streaming은 이벤트 시간 기반 처리, 윈도우 집계, 스트림-스트림 조인을 더욱 정교하게 지원하며, 마이크로 배치와 연속 처리(continuous processing) 모드를 모두 제공하여 밀리초 단위의 지연 시간도 달성할 수 있다[6].

SPARK의 MLlib는 종단간 머신러닝 파이프라인을 구축하기 위한 고수준 API를 제공한다. 이 파이프라인 API는 데이터 전처리, 특징 추출, 모델 학습, 평가, 튜닝, 배포까지의 전체 워크플로우를 일관된 추상화로 표현할 수 있게 한다. 파이프라인은 여러 단계(Stage)로 구성되며, 각 단계는 Transformer 또는 Estimator 중 하나의 역할을 수행한다. Transformer는 데이터를 변환하는 로직을 포함하는 반면(예: 특징 벡터화), Estimator는 데이터를 기반으로 모델을 학습시키는 알고리즘이다.

파이프라인 구축은 일반적으로 데이터 준비, 특징 공학, 모델 학습, 하이퍼파라미터 튜닝의 단계를 따른다. 사용자는 StringIndexer, VectorAssembler, StandardScaler 같은 내장 Transformer를 사용해 데이터를 변환하고, 로지스틱 회귀나 랜덤 포레스트 같은 Estimator를 파이프라인에 추가하여 모델을 학습시킨다. 학습이 완료된 Estimator는 학습된 모델을 포함하는 Transformer로 변환되어 새로운 데이터에 대한 예측을 수행한다.

파이프라인 API의 주요 장점은 모듈성과 재현성이다. 각 단계는 독립적으로 구성되고 검증될 수 있으며, 전체 파이프라인 객체는 학습과 예측을 위한 일관된 인터페이스를 제공한다. 또한 교차 검증과 격자 탐색을 위한 CrossValidator와 TrainValidationSplit 같은 도구를 통해 하이퍼파라미터 튜닝을 파이프라인에 통합할 수 있다. 이를 통해 최적의 모델 구성을 자동화된 방식으로 찾을 수 있다.

머신러닝 파이프라인은 대규모 분산 데이터셋에 대한 반복적인 연산을 효율적으로 처리하도록 설계되었다. SPARK의 인메모리 연산과 RDD 기반의 분산 처리 덕분에, 전통적인 단일 머신 도구로는 처리하기 어려운 빅데이터 환경에서도 머신러닝 모델 개발과 실험을 가능하게 한다. 이는 추천 시스템, 사기 탐지, 텍스트 분류 등 다양한 실무 응용 분야에 활용된다.

그래프 분석은 정점과 간선으로 구성된 그래프 구조 데이터를 처리하고 분석하는 작업을 말한다. 소셜 네트워크 분석, 추천 시스템, 웹 그래프 분석, 사기 탐지, 생물정보학 등 다양한 분야에서 활용된다. SPARK는 GraphX라는 전용 라이브러리를 제공하여 대규모 분산 그래프 처리를 지원한다.

GraphX는 RDD 기반의 속성 그래프 모델을 사용한다. 각 정점과 간선은 사용자 정의 속성을 가질 수 있으며, Pregel API를 구현하여 정점 중심의 반복적 메시지 전달 프로그래밍 모델을 제공한다. 이를 통해 페이지랭크, 커뮤니티 탐지, 최단 경로 탐색, 연결 요소 분석과 같은 고전적인 그래프 알고리즘을 대규모로 실행할 수 있다. GraphX의 연산은 크게 변환 연산, 구조 연산, 집계 연산, 조인 연산으로 분류된다.

GraphX를 활용한 일반적인 분석 파이프라인은 다음과 같은 단계로 구성된다.

1. 원본 데이터(정점 및 간선 목록)를 로드하여 속성 그래프를 생성한다.

2. subgraph, mapVertices, mapEdges 등의 변환 연산으로 그래프를 필터링하거나 속성을 변환한다.

3. aggregateMessages 연산을 사용하여 이웃 정점들로부터 정보를 집계하거나, Pregel 연산자를 사용하여 반복적인 알고리즘을 실행한다.

4. 분석 결과를 정점 RDD나 간선 RDD 형태로 추출하거나, 다른 Spark SQL 데이터프레임과 조인하여 추가 분석에 사용한다.

GraphX는 SPARK의 통합 스택의 일부로 동작하기 때문에, 그래프 분석의 결과를 MLlib을 이용한 머신러닝이나 Spark SQL을 이용한 구조화된 쿼리 처리와 쉽게 결합할 수 있는 장점이 있다. 그러나 매우 대규모이거나 특수한 그래프 처리에는 Apache Giraph나 Neo4j와 같은 전용 시스템이 더 적합할 수 있다[7].

SPARK는 Hadoop MapReduce의 후속 및 대체 기술로 자리 잡으며, 특히 대규모 데이터 처리 성능에서 몇 가지 결정적인 장점을 보여준다. 가장 큰 차이는 처리 방식에 있다. MapReduce는 디스크 기반의 처리 모델을 사용하여 각 맵(Map)과 리듀스(Reduce) 단계 후 중간 결과를 HDFS에 저장한다. 이로 인해 반복적인 계산이 많은 작업(예: 머신러닝 알고리즘, 그래프 처리)에서 디스크 I/O 오버헤드가 크게 발생하여 성능이 저하된다. 반면, SPARK는 RDD를 기반으로 한 인메모리(in-memory) 연산을 지원한다. 데이터를 가능한 한 메모리에 유지함으로써 반복 작업과 여러 단계로 이루어진 처리 파이프라인의 속도를 MapReduce에 비해 수십 배에서 수백 배까지 향상시킬 수 있다.

두 번째 장점은 프로그래밍 모델의 표현력과 사용 편의성에 있다. MapReduce는 맵과 리듀스라는 두 가지 고정된 연산으로 모든 로직을 표현해야 하므로 복잡한 작업을 작성하기가 번거롭고 코드가 길어지는 경향이 있다. SPARK는 변환(Transformation)과 액션(Action)으로 구성된 풍부한 고수준 연산 API(예: map, filter, join, groupBy)를 제공한다. 이를 통해 개발자는 간결하고 선언적인 코드로 복잡한 데이터 처리 흐름을 쉽게 표현할 수 있으며, 특히 SPARK SQL과 데이터프레임(DataFrame) API를 통해 SQL과 유사한 쿼리 작성도 가능하다.

또한, SPARK는 통합 스택(unified stack)이라는 철학을 지닌다. MapReduce는 주로 배치 처리에 특화되어 있어 실시간 스트림 처리, 머신러닝, 그래프 분석 등 다른 유형의 작업을 위해서는 Apache Storm, Apache Mahout 등 별도의 시스템을 도입해야 했다. SPARK는 하나의 프레임워크 내에서 SPARK Core, SPARK Streaming, MLlib, GraphX 같은 라이브러리를 통해 배치 처리, 스트림 처리, 머신러닝, 그래프 처리까지 포괄적으로 지원한다. 이로 인해 다양한 워크로드를 위한 별도의 클러스터나 시스템을 유지 관리할 필요가 줄어들고, 서로 다른 처리 패러다임 간에 코드와 데이터를 공유하기가 훨씬 용이해진다.

마지막으로, SPARK의 DAG 스케줄러는 작업 실행을 최적화하는 데 기여한다. MapReduce는 작업의 각 단계를 독립적으로 실행하고 관리자에게 의존하는 반면, SPARK는 작업 전체의 연산 그래프(DAG)를 파악하여 불필요한 셔플(Shuffle)이나 중간 저장을 최소화하고, 가능한 연산들을 파이프라이닝하여 효율적으로 실행한다. 이러한 지연 실행(lazy evaluation)과 최적화는 개발자가 작성한 코드의 실제 실행 효율을 높여준다.

SPARK는 Hadoop 에코시스템의 핵심 저장소인 HDFS와 밀접하게 연동되어 작동한다. SPARK 애플리케이션은 HDFS에 저장된 데이터를 직접 읽고 쓸 수 있으며, 이를 통해 MapReduce와 같은 기존 Hadoop 도구들과 동일한 데이터 소스를 공유한다. 데이터 로컬리티를 최대화하기 위해 SPARK는 클러스터 관리자와 협력하여 데이터가 저장된 노드에서 연산을 실행하려고 시도한다[8]. 또한 SPARK는 HBase나 Amazon S3와 같은 다른 Hadoop 호환 저장 시스템과도 연동이 가능하다.

Apache Hive와의 연동은 Spark SQL 모듈을 통해 이루어진다. SPARK는 Hive의 메타스토어에 직접 연결하여 기존에 정의된 Hive 테이블의 스키마와 데이터 위치 정보를 읽어올 수 있다. 이를 통해 사용자는 기존 Hive 웨어하우스의 데이터에 대해 SPARK의 고성능 엔진을 사용한 쿼리 및 분석을 즉시 수행할 수 있다. 반대로, SPARK를 사용하여 처리한 결과 데이터를 다시 새로운 Hive 테이블로 저장하는 것도 일반적인 작업 흐름이다.

두 시스템의 통합은 다음과 같은 주요 포인트를 제공한다.

이러한 긴밀한 연동 덕분에 조직은 기축 투자를 보호하면서도 SPARK의 빠른 인메모리 처리 성능을 활용할 수 있다. 결과적으로 SPARK는 Hadoop의 강력한 저장 기반과 Hive의 편리한 데이터 관리 체계 위에 고속 처리 계층으로 자리 잡았다.