Offcanvas

How To / 개발자 / 빅데이터 | 애널리틱스 / 애플리케이션

'하둡을 제압한 빅데이터 플랫폼'··· 아파치 스파크란?

2020.03.23 Ian Pointer   |  InfoWorld
아파치 스파크(Apache Spark)는 매우 큰 데이터 집합을 대상으로 빠르게 처리 작업을 수행하는 한편, 단독으로 또는 다른 분산 컴퓨팅 툴과 조율해 여러 컴퓨터로 데이터 처리 작업을 분산할 수 있는 데이터 처리 프레임워크다.

거대한 데이터 스토어를 탐색하면서 작업하기 위해 막대한 컴퓨팅 성능을 모아야 하는 빅데이터와 머신러닝 분야에서 이 2가지 특성은 문을 여는 열쇠라고 할 수 있다. 스파크는 또한 분산 컴퓨팅과 빅데이터 처리의 힘든 작업 대부분을 추상화하는, 사용하기 쉬운 API를 통해 개발자들이 짊어지는 부담을 일부 덜어주는 역할도 한다.

아파치 스파크는 2009년 U.C. 버클리의 AMP랩(AMPLab)에서 소소하게 시작됐으나 지금은 세계에서 가장 중요한 빅데이터 분산 처리 프레임워크 가운데 하나다. 스파크는 다양한 방식으로 배포가 가능하며 자바(Java), 스칼라(Scala), 파이썬(Python), R 프로그래밍 언어를 위한 네이티브 바인딩을 제공하고 SQL, 스트리밍 데이터, 머신러닝, 그래프 프로세싱을 지원한다. 은행, 통신업체, 게임 회사, 정부를 비롯해 애플, 페이스북, IBM, 마이크로소프트와 같은 주요 기술 대기업도 모두 아파치 스파크를 사용한다.


아파치 스파크 아키텍처

아파치 스파크의 구성 요소는 크게 드라이버(driver)와 이그제큐터(executor) 2가지다. 드라이버는 사용자의 코드를 여러 작업자 노드로 배분할 수 있는 여러 작업으로 변환하고 이그제큐터는 이런 노드에서 실행되면서 할당된 작업을 실행한다. 그리고 이 둘을 중재하기 위한 클러스터 관리자가 필요하다.

스파크는 기본적으로 클러스터의 각 머신에 JVM과 아파치 스파크 프레임워크만 있으면 되는 독립형 클러스터 코드로 실행이 가능하다. 그러나 작업자를 자동으로 할당하기 위해 더 강력한 리소스 또는 클러스터 관리 시스템을 활용하고자 하는 경우가 많다. 엔터프라이즈에서는 이를 위해 보통 하둡 얀(Hadoop YARN)에서 실행하지만 아파치 메소스(Mesos), 쿠버네티스(Kubernetes), 도커 스웜(Docker Swarm)에서도 아파치 스파크를 실행할 수 있다.

매니지드 솔루션을 찾는다면 아마존 EMR, 구글 클라우드 데이터프록(Dataproc), 마이크로소프트 애저 HD인사이트(HDInsight)의 일부로 제공되는 아파치 스파크도 있다. 아파치 스파크 개발진을 직원으로 채용한 데이터브릭스(Databricks)도 표준 아파치 스파크 배포판에서 아파치 스파크 클러스터와 스트리밍 지원, 통합 웹 기반 노트북 개발, 최적화된 클라우드 I/O 성능을 제공하는 포괄적인 매니지드 서비스인 데이터브릭스 유니파이드 애널리틱스 플랫폼(Unified Analytics Platform)을 제공한다.

아파치 스파크는 사용자의 데이터 처리 명령을 방향성 비순환 그래프(Directed Acyclic Graph, DAG)로 만든다. DAG는 아파치 스파크의 스케줄링 계층으로, 어느 작업이 어느 노드에서 어느 순서로 실행되는지를 결정한다.


스파크 대 하둡, 아파치 스파크를 사용하는 이유

우선 밝혀 둘 점은 아파치 스파크 대 아파치 하둡의 비교는 다소 부적절하다는 것이다. 요즘은 대부분의 하둡 배포판에 스파크가 포함된다. 어쨌든 스파크는 두 가지 큰 이점 덕분에 빅데이터 처리 분야에서 하둡의 인기를 이끈 기존의 맵리듀스(MapReduce) 패러다임을 추월, 가장 유력한 프레임워크로 부상했다.

첫 번째 이점은 속도다. 스파크는 인메모리 데이터 엔진을 통해 특정 상황에서 맵리듀스보다 100배 더 빠르게 작업을 수행할 수 있다. 특히 단계 간에 디스크에 상태를 써야 하는 다단계 작업에서 성능 차이가 두드러진다. 기본적으로 맵리듀스는 데이터 맵핑과 리듀싱으로 구성되는 2단계 실행 그래프를 생성하는 반면 아파치 스파크의 DAG에는 더 효율적으로 분산이 가능한 여러 단계가 있다. 메모리에 데이터를 완전히 집어넣을 수 없는 아파치 스파크 작업도 맵리듀스보다 대체로 10배 정도는 더 빠르다.

두 번째 이점은 개발자 친화적인 스파크 API다. 스파크의 빠른 속도 못지않게 중요한 요소이며 개발자에 따라서는 스파크 API의 친근함이 속도보다 더 중요하다고 말하기도 한다.


스파크 코어

맵리듀스 및 다른 아파치 하둡 구성요소와 비교할 때 아파치 스파크 API는 개발자에게 매우 친화적이며 분산 처리 엔진이 갖는 복잡함의 대부분을 간단한 메서드 호출 뒤로 숨긴다. 전형적인 예로, 문서의 단어 수를 세는 약 50줄짜리 맵리듀스 코드를 아파치 스파크에서 단 몇 줄로 줄일 수 있다. 다음은 스칼라 예시다.

val textFile = sparkSession.sparkContext.textFile(“hdfs:///tmp/words”)
val counts = textFile.flatMap(line => line.split(“ “))
                      .map(word => (word, 1))
                      .reduceByKey(_ + _)
counts.saveAsTextFile(“hdfs:///tmp/words_agg”)


아파치 스파크는 파이썬, R과 같이 데이터 분석용으로 인기 있는 언어와 자바, 스칼라와 같은 엔터프라이즈에 적합한 언어에 대한 바인딩을 제공함으로써 애플리케이션 개발자부터 데이터 과학자에 이르기까지 모두가 아파치 스파크의 확장성과 속도를 손쉽게 활용할 수 있도록 한다.


스파크 RDD

아파치 스파크의 중심은 탄력적 분산 데이터 집합(Resilient Distributed Datase, RDD) 개념이다. RDD는 컴퓨팅 클러스터 전역으로 분할할 수 있는 불변성 객체 모음을 나타내는 프로그래밍 추상화다. 또한 RDD에서의 작업은 클러스터 전반에서 분할되어 병렬 배치 프로세스로 처리가 가능하므로 병렬 처리의 속도와 확장성이 더 높다.

RDD는 간단한 텍스트 파일, SQL 데이터베이스, NoSQL 스토어(카산드라, 몽고DB 등), 아마존 S3 버킷을 비롯해 다른 많은 방법으로 만들 수 있다. 스파크 코어 API의 대부분은 이 RDD 개념을 기반으로 만들어졌으므로 전통적인 맵과 리듀스 기능을 실현하면서 데이터 집합 조인, 필터링, 샘플링, 집계도 기본적으로 지원한다.

스파크는 분산형으로 실행된다. 드라이버 코어 프로세스가 스파크 애플리케이션을 여러 작업으로 분할해 다수의 이그제큐터 프로세스로 분배하면 이그제큐터 프로세스가 작업을 수행하는 방식이다. 이그제큐터는 애플리케이션의 필요에 따라 확장하거나 축소할 수 있다.


스파크 SQL

스파크 SQL은 최초 샤크(Shark)라는 이름으로 시작되어 이후 아파치 스파크 프로젝트 내에서 차지하는 비중을 점차 늘려왔다. 현재 개발자가 애플리케이션을 만들 때 가장 일반적으로 사용하는 인터페이스라고 할 수 있다. 스파크 SQL은 R과 파이썬(판다스(Pandas))에서 차용한 데이터프레임 접근 방식을 사용한 구조적 데이터 처리에 중점을 둔다. 그러나 이름이 시사하듯이 스파크 SQL은 데이터 쿼리를 위해 SQL2003 규격을 준수하는 인터페이스도 제공하므로 개발자는 물론 분석가도 아파치 스파크의 강력함을 활용할 수 있다.

스파크 SQL은 표준 SQL 지원과 함께 기본적으로 지원되는 JSON, HDFS, 아파치 하이브(Hive), JDBC, 아파치 ORC, 아파치 파켓(Parquet)을 포함한 다른 데이터 스토어를 읽고 쓰기 위한 표준 인터페이스도 제공한다. 아파치 카산드라, 몽고DB, 아파치 H베이스(HBase)를 비롯한 그 외의 인기 있는 스토어는 스파크 패키지 생태계에서 별도의 커넥터를 가져와 사용할 수 있다.

데이터프레임에서 열을 선택하는 방법은 다음과 같이 매우 간단하다.

citiesDF.select(“name”, “pop”)

SQL 인터페이스를 사용해 데이터프레임을 임시 테이블로 등록한 다음 이를 대상으로 SQL 쿼리를 실행할 수 있다.

citiesDF.createOrReplaceTempView(“cities”)
spark.sql(“SELECT name, pop FROM cities”)


내부적으로 아파치 스파크는 카탈리스트(Catalyst)라는 쿼리 옵티마이저를 사용한다. 카탈리스트는 데이터와 쿼리를 살펴보고 데이터 지역성(locality)과 계산을 위한 효율적인 쿼리 계획을 생성해서 클러스터를 통해 필요한 계산을 수행한다.

아파치 스파크 2.x에 들어서면서 개발 용도로 스파크 SQL의 데이터프레임과 데이터 집합(컴파일 시 정확성에 대한 확인이 가능하고 런타임에 부가적인 메모리 및 컴퓨팅 최적화를 활용할 수 있는 형식 지정 데이터프레임) 인터페이스가 권장된다. RDD 인터페이스도 여전히 사용할 수 있지만 필요한 일을 스파크 SQL 패러다임 내에서 수행할 수 없는 경우에 한해 권장된다.

스파크 2.4에는 배열과 기타 고차 데이터 형식을 직접 다루기 위한 내장 고차 함수 집합이 도입됐다.
 

스파크 MLlib

아파치 스파크에는 머신러닝과 그래프 분석 기법을 대규모로 데이터에 적용하기 위한 라이브러리가 함께 제공된다. 스파크 MLlib에는 머신러닝 파이프라인을 만들기 위한 프레임워크가 포함되어 있어 구조적 데이터 집합을 대상으로 한 형상 추출, 선택, 변형을 손쉽게 구현할 수 있다.

MLlib에는 k-평균 클러스터링, 랜덤 포리스트와 같이 맞춤형 파이프라인에 손쉽게 넣고 뺄 수 있는 클러스터링 및 분류 알고리즘의 분산 구현이 포함돼 있다. 데이터 과학자가 R 또는 파이썬을 사용해서 아파치 스파크에서 모델을 학습시키고 MLlib를 사용해 저장한 다음 프로덕션 용도의 자바 또는 스칼라 기반 파이프라인으로 이 모델을 가져올 수 있다.

스파크 MLlib는 분류(classification), 회귀(regression), 클러스터링(clustering), 필터링(filtering)을 비롯한 기본적인 머신러닝을 다루지만 심층 신경망(Deep Neural Networks)의 모델링과 학습을 위한 기능은 없다.
 

스파크 그래프X

스파크 그래프X(GraphX)에는 구글 페이지랭크(PageRank) 구현을 포함한 그래프 구조 처리를 위한 몇 가지 분산 알고리즘이 제공된다. 이러한 알고리즘은 모델링 데이터에 대해 스파크 코어의 RDD 접근 방식을 사용한다. 그래프프레임(GraphFrame) 패키지를 사용하면 그래프 쿼리를 위한 카탈리스트 옵티마이저 활용을 포함해 데이터프레임에서 그래프 연산이 가능하다.


스파크 스트리밍

스파크 스트리밍(Spark Streaming)은 초기에 실시간 또는 근 실시간 처리가 필요한 환경에서 아파치 스파크가 인기를 끄는 데 일조한 요소다. 이전 아파치 하둡 환경에서는 배치(batch)와 스트림 처리가 서로 별개였다. 배치 처리가 필요할 때는 맵리듀스 코드를 쓰고, 실시간 스트리밍이 필요한 경우에는 아파치 스톰(Storm) 등을 사용했다. 이로 인해 상호 이질적인 코드베이스가 형성되고 서로 전혀 다른 프레임워크를 기반으로 함에도 불구하고 애플리케이션 도메인을 위해 각기 필요한 리소스도 다르고 운영 고려 사항도 다른 두 코드베이스를 동기화해야 했다.

스파크 스트리밍은 스트림을 연속적인 마이크로배치(microbatch)로 쪼개는 방법으로 아파치 스파크의 배치 처리 개념을 스트리밍으로 확장했다. 이렇게 쪼개진 마이크로배치는 아파치 스파크 API를 사용해 조작할 수 있다. 이 방법을 사용하면 배치 작업과 스트리밍 작업의 코드가 (대부분) 동일한 코드를 공유하고 같은 프레임워크에서 실행될 수 있어 결과적으로 개발자와 운영자의 오버헤드가 낮아진다. 모두에게 이익이다.

스파크 스트리밍 방식에 대한 비판은 수신 데이터에 대한 저지연 응답이 필요한 일부 시나리오에서 마이크로배치의 성능이 아파치 스톰, 아파치 플링크(Flink), 아파치 에이펙스(Apex)와 같이 마이크로배치가 아닌 순수 스트리밍 방식을 사용하는 다른 스트리밍 지원 프레임워크의 성능에 미치지 못할 수 있다는 것이다.
 

구조적 스트리밍

스파크 스트리밍에서 구조적 스트리밍(Structured Streaming: 스파크 2.x에 추가됨)이 갖는 의미는 스파크 코어 API에서 스파크 SQL이 가진 의미와 비슷하다. 즉, 애플리케이션 쓰기에 있어 더 높은 수준의 API와 더 쉬운 추상화라고 할 수 있다. 구조적 스트리밍의 경우 더 높은 수준의 API는 기본적으로 개발자가 무한한 스트리밍 데이터프레임과 데이터 집합을 만들 수 있게 해준다. 또한 초창기 프레임워크에서, 특히 이벤트 시간 집계 및 늦은 메시지 전송 처리와 관련해 사용자들이 어려움을 겪었던 몇 가지 고질적인 문제도 해결해준다. 구조적 스트리밍의 모든 쿼리는 카탈리스트 쿼리 옵티마이저를 거치며 인터랙티브한 방식으로도 실행이 가능하므로 사용자는 라이브 스트리밍 데이터를 대상으로 SQL 쿼리를 수행할 수 있다.

구조적 스트리밍은 처음에는 스트리밍 데이터 처리를 위해 스파크 스트리밍의 마이크로배치 방식에 의존했다. 그러나 스파크 2.3에 이르러 아파치 스파크 팀은 구조적 스트리밍에 저지연 지속적 처리 모드(Continuous Processing Mode)를 추가해 1ms의 낮은 지연으로 응답을 처리할 수 있도록 했다. 스파크 2.4에서도 지속적 처리는 아직 실험 단계의 기능으로 분류된다. 구조적 스트리밍은 스파크 SQL 엔진을 기반으로 구축됐지만 지속적 스트리밍은 한정된 쿼리 집합만 지원한다.

구조적 스트리밍은 스파크 플랫폼에서 스트리밍 애플리케이션의 미래다. 따라서 새 스트리밍 애플리케이션을 만들고 있다면 구조적 스트리밍을 사용해야 한다. 레거시 스파크 스트리밍 API도 계속 지원은 되지만 스파크 프로젝트 차원에서 구조적 스트리밍으로의 이식을 권하고 있다. 구조적 스트리밍 방법이 스트리밍 코드를 쓰고 유지하기가 훨씬 더 용이하기 때문이다.


딥 러닝 파이프라인

아파치 스파크는 딥 러닝 파이프라인을 통해 딥 러닝을 지원한다. MLlib의 기존 파이프라인 구조를 사용해 코드 단 몇 줄로 저수준 딥 러닝 라이브러리와 구조 분류기를 호출할 수 있으며 맞춤형 텐서플로우 그래프나 케라스 모델을 수신 데이터에 적용할 수도 있다. 이런 그래프와 모델을 맞춤형 SQL UDF(User-Defined Functions)로 등록해 딥 러닝 모델을 SQL 문의 일부로 데이터에 적용하는 것도 가능하다.


아파치 스파크 자습서

아파치 스파크를 본격적으로 배울 준비가 되었는가? 에반 하이트만의 ‘원시인을 위한 파이썬 아파치 스파크 가이드(A Neanderthal’s Guide to Apache Spark in Python)’를 적극 추천한다. 이 글은 아파치 스파크의 기본적인 원리를 비교적 쉽게 설명할 뿐만 아니라 프레임워크를 사용하는 간단한 파이썬 애플리케이션을 만드는 과정도 안내한다. 데이터 과학 분야에서 빅데이터와 머신러닝의 중요성이 갈수록 커지고 있는 만큼 이 글도 데이터 과학자의 관점에서 작성되었다.

아파치 스파크 플랫폼으로 할 수 있는 일과 그 방법을 알아보기 위한 예제를 찾는다면 스파크 바이(Spark By)의 예제를 추천한다. 스파크 프로그래밍의 기초가 되는 기본적인 작업에 대한 샘플 코드가 풍부하게 제공되므로 아파치 스파크 본래의 용도인 더 큰 작업을 구성하는 구성요소를 볼 수 있다.

더 깊게 가려면 D존(Dzone)에서 많은 이가 말하는 ‘완전한 아파치 스파크 모음’을 찾아볼 수 있다. 여러 아파치 스파크 주제에 관한 유용한 자습서가 많다. editor@itworld.co.kr
CIO Korea 뉴스레터 및 IT 트랜드 보고서 무료 구독하기
추천 테크라이브러리

회사명:한국IDG 제호: CIO Korea 주소 : 서울시 중구 세종대로 23, 4층 우)04512
등록번호 : 서울 아01641 등록발행일자 : 2011년 05월 27일

발행인 : 박형미 편집인 : 천신응 청소년보호책임자 : 한정규
사업자 등록번호 : 214-87-22467 Tel : 02-558-6950

Copyright © 2024 International Data Group. All rights reserved.