2017.11.16

대세로 자리잡은 빅데이터 분석 플랫폼, '아파치 스파크'의 이해

Ian Pointer | InfoWorld
아파치 스파크(Apache Spark)는 2009년 버클리대학교의 AMPLab에서 소소하게 시작된 이후, 발전을 거듭해 세계에서 가장 중요한 빅데이터 분산 처리 프레임워크 가운데 하나로 부상했다.


Credit: Getty Images Bank

스파크는 다양한 방법으로 배포가 가능하고 자바, 스칼라, 파이썬, R 프로그래밍 언어를 위한 네이티브 바인딩을 제공하며 SQL, 스트리밍 데이터, 머신러닝 및 그래프 처리를 지원한다. 은행, 통신업체, 게임업체, 정부를 비롯해 애플, 페이스북, IBM, 마이크로소프트와 같은 모든 주요 IT 기업들이 아파치 스파크를 사용한다.

스파크는 기본 상태에서 클러스터의 각 머신에 아파치 스파크 프레임워크와 JVM만 있으면 되는 독립형 클러스터 모드로 실행이 가능하다. 그러나 리소스 또는 클러스터 관리 시스템을 활용해 수요에 따라 작업자를 할당하고자 하는 경우가 더 많다.

기업에서 이는 일반적으로 하둡 얀(YARN)에서 실행하는 것을 의미하지만(클라우데라 및 호튼웍스 배포판이 스파크 작업을 이렇게 실행함) 아파치 스파크는 아파치 메소스에서도 실행 가능하다. 현재 쿠버네티스(Kubernetes)에 대한 네이티브 지원을 추가하기 위한 작업이 진행 중이다.

매니지드 솔루션을 찾는다면 아마존 EMR, 구글 클라우드 데이터프록(Google Cloud Dataproc) 및 마이크로소프트 애저 HD인사이트(HDInsight)에서 아파치 스파크를 찾을 수 있다.
아파치 스파크 창립자들을 채용한 업체 데이터브릭스(Databricks)는 아파치 스파크 클러스터, 스트리밍 지원, 통합 웹 기반 노트북 개발, 표준 아파치 스파크 배포판에 비해 최적화된 클라우드 I/O 성능을 갖춘 포괄적인 매니지드 서비스인 데이터브릭스 유니파이드 애널리틱스 플랫폼(Databricks Unified Analytics Platform)을 제공한다.

스파크와 하둡과의 비교
일단 아파치 스파크와 아파치 하둡과의 비교는 다소 부적절하다. 요즘에는 대부분의 하둡 배포판에 스파크가 포함된다. 그러나 스파크는 두 가지 큰 이점 덕분에 하둡의 부상을 이끈 기존 맵리듀스 패러다임을 앞질러 빅데이터 처리의 핵심 프레임워크로 부상했다.

첫 번째 이점은 속도다. 스파크의 메모리 내 데이터 엔진은 특정 상황에서, 특히 스테이지 간에 다시 디스크에 상태를 써야하는 다중 스테이지 작업과 비교할 때 맵리듀스에 비해 최대 100배 더 빠르다. 데이터가 메모리 내에 완전히 들어갈 수 없는 아파치 스파크 작업도 맵리듀스에 비해 약 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 Dataset, RDD) 개념이다. RDD에서의 운영 역시 여러 클러스터로 분할할 수 있으며 병렬 배치 프로세스로 실행이 가능하고, 이는 더 빠르고 확장성 높은 병렬 처리로 이어진다.

RDD는 간단한 텍스트 파일, SQL 데이터베이스, NoSQL 저장소(예를 들어 카산드라, 몽고DB), 아마존 S3 버킷, 그 외에도 많은 방법으로 생성할 수 있다. 스파크 코어 API의 대부분은 이 RDD 개념을 기반으로 구축되므로 전통적인 맵과 리듀스 기능을 실현하지만 그와 함께 데이터 집합 조인, 필터링, 샘플링 및 집계도 기본적으로 지원한다.

스파크에서 분산 실행을 구현하는 방법은 스파크 애플리케이션을 여러 작업으로 분할해 이를 작업을 시행하는 다수의 이그제큐터(executor) 프로세스로 분산하는 드라이버 코어 프로세스를 결합하는 것이다. 이런 이그제큐터는 애플리케이션의 필요에 따라 확장과 축소가 가능하다.

스파크 SQL
원래는 샤크(Shark)라는 이름으로 알려진 스파크 SQL은 아파치 스파크 프로젝트에서 점점 더 중요해지고 있다. 아마 현재 개발자들이 애플리케이션을 만들 때 가장 흔히 사용하는 인터페이스일 것이다.

스파크 SQL은 구조적 데이터 처리에 초점을 두며, R과 파이썬(판다스)에서 차용한 데이터프레임을 사용한다. 그러나 이름이 시사하듯 스파크 SQL은 데이터 쿼리를 위한 SQL2003 호환 인터페이스도 제공해 분석가는 물론 개발자도 아파치 스파크의 강력함을 활용할 수 있게 해준다.

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

데이터프레임에서 열을 선택하는 코드는 다음과 같이 간단하다.

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

SQL 인터페이스를 사용해서 데이터프레임을 임시 테이블로 등록하고 이후 이에 대해 SQL 쿼리를 발행할 수 있다.

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


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

아파치 스파크 2.x 시대에서 데이터프레임과 데이터 집합의 스파크 SQL 인터페이스(기본적으로 컴파일 시에 정확성 확인이 가능하고 런타임에 추가적인 메모리 및 컴퓨팅 최적화를 활용할 수 있는 형식이 지정된 데이터프레임)는 개발 시 권장되는 접근 방법이다. RDD 인터페이스도 여전히 사용할 수 있지만 스파크 SQL 패러다임 내에 캡슐화할 수 없는 경우에만 권장된다.

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

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

스파크 MLlib은 분류, 회귀, 클러스터링, 필터링과 같은 기본적인 머신러닝을 다루지만 심층 신경망(deep neural networks)을 모델링하고 학습시키기 위한 기능은 포함하지 않는다. 단, 딥 러닝 파이프라인은 현재 개발 중이다.

스파크 그래프X
스파크 그래프X(Spark GraphX)는 구글 페이지랭크 구현을 포함한 그래프 구조 처리를 위한 분산 알고리즘과 함께 제공된다. 이런 알고리즘은 스파크 코어의 RDD 접근 방법을 사용해 데이터를 모델링한다. 그래프프레임(GraphFrames) 패키지는 그래프 쿼리에 카탈리스트 옵티마이저를 활용하는 기능을 비롯해 데이터프레임에서 그래프 작업을 수행할 수 있게 해준다.

스파크 스트리밍
스파크 스트리밍(Spark Streaming)은 초기에 아파치 스파크에 추가된 요소로, 실시간 또는 근 실시간 처리가 필요한 환경에서 아파치 스파크가 부상하는 데 힘을 보탰다. 이전에는 아파치 하둡의 배치와 스트림 처리는 서로 별개의 세계였다. 배치 처리가 필요하면 맵리듀스 코드를 썼고, 실시간 스트리밍이 필요한 경우에는 아파치 스톰(Storm)과 같은 것을 사용했다.

결과적으로 서로 다른 리소스가 필요하고 서로 다른 운영 요소를 감안해야 하는, 서로 완전히 다른 프레임워크를 기반으로 함에도 불구하고 애플리케이션 도메인을 위해 개별적인 두 코드베이스의 동기화를 유지해야 하는 상황이 발생한다.

스파크 스트리밍은 스트리밍을 지속적인 일련의 마이크로배치로 나누는 방법으로 아파치 스파크의 배치 처리 개념을 스트리밍으로 확장했다. 이렇게 나눈 마이크로배치는 아파치 스파크 API를 사용해 조작이 가능하다. 이 방식을 통해 배치와 스트리밍 작업의 코드는 (대부분) 동일한 코드를 공유하며 동일한 네트워크에서 실행된다. 따라서 개발자와 운영자 오버헤드가 모두 줄어든다. 모두에게 이익이다.

스파크 스트리밍 접근 방법에 대한 비판점은 유입 데이터에 대한 저지연 응답이 필요한 시나리오에서 아파치 스톰, 아파치 플링크(Flink), 아파치 아펙스(Apex)와 같은 다른 스트리밍 지원 프레임워크의 성능에 비해 마이크로배치의 성능이 떨어진다는 점이다. 이러한 프레임워크는 모두 마이크로배치가 아닌 순수 스트리밍 방법을 사용한다.

구조적 스트리밍
스파크 스트리밍에서 구조적 스트리밍(Structured Streaming, 스파크 2.x에 추가)의 역할은 스파크 코어 API에서 스파크 SQL의 역할과 같다. 즉, 애플리케이션 작성을 위한 더 높은 수준의 API와 더 쉬운 추상화다. 구조적 스트리밍의 경우 더 높은 수준의 API는 개발자가 무한한 스트리밍 데이터프레임과 데이터 집합을 생성할 수 있게 해준다.

또한 이전 프레임워크, 특히 이벤트 시간 집계 및 늦은 메시지 배달 처리와 관련한 부분에서 사용자들이 씨름했던 골치아픈 몇 가지 문제도 해결해준다. 구조적 스트림의 모든 쿼리는 카탈리스트 쿼리 옵티마이저를 거치며 인터랙티브한 방식으로도 실행이 가능하므로 사용자는 라이브 스트리밍 데이터를 대상으로 SQL 쿼리를 수행할 수 있다.

구조적 스트리밍은 스파크 2.2 릴리스부터 프로덕션 환경에 사용 가능한 것으로 표시된 만큼 아파치 스파크에서 비교적 새로운 부분이다. 그러나 구조적 스트리밍은 이 플랫폼에서 스트리밍 애플리케이션의 미래이므로 새로운 스트리밍 애플리케이션을 제작 중이라면 구조적 스트리밍을 사용해야 한다.

기존의 스파크 스트리밍 API는 계속 지원되지만 이 프로젝트에서도 구조적 스트리밍으로의 이식을 권장한다. 새로운 방법이 훨씬 더 편하게 스트리밍 코드를 쓰고 유지할 수 있게 해주기 때문이다.

아파치 스파크의 다음 단계
구조적 스트리밍이 스파크 스트리밍을 개선하지만 지금은 스트리밍 데이터 처리에서 마이크로배치 체계에 계속 의존한다. 아파치 스파크는 마이크로배치 없이 지속적 스트리밍을 구현하기 위해 연구 중이며 이것이 실현될 경우 저지연 응답 처리와 관련된 많은 문제가 해결된다(현재 논의되는 수치는 1ms 미만으로, 상당히 인상적임). 더 좋은 점은 구조적 스트리밍은 스파크 SQL 엔진을 기반으로 하므로 코드를 변경하지 않고도 새 스트리밍 방법을 사용할 수 있다는 것이다.

아파치 스파크는 스트리밍 성능 개선 외에 딥 러닝 파이프라인을 통해 딥 러닝에 대한 지원도 추가할 예정이다. 향후 MLlib의 기존 파이프라인 구조를 사용해서 단 몇 줄의 코드로 분류기를 제작하고, 유입되는 데이터에 맞춤형 텐서플로우(Tensorflow) 그래프 또는 케라스(Keras) 모델을 적용할 수 있게 된다. 나아가 이런 그래프와 모델을 맞춤형 스파크 SQL UDF(사용자 정의 함수)로 등록할 수도 있으므로 딥 러닝 모델을 SQL 문의 일부로 데이터에 적용할 수 있다.

두 가지 기능 모두 프로덕션에 사용 가능하게 되려면 아직 멀지만 과거 아파치 스파크의 빠른 개발 속도로 비추어 볼 때 2018년이면 성숙기에 접어들 것으로 예상된다. editor@itworld.co.kr
 



2017.11.16

대세로 자리잡은 빅데이터 분석 플랫폼, '아파치 스파크'의 이해

Ian Pointer | InfoWorld
아파치 스파크(Apache Spark)는 2009년 버클리대학교의 AMPLab에서 소소하게 시작된 이후, 발전을 거듭해 세계에서 가장 중요한 빅데이터 분산 처리 프레임워크 가운데 하나로 부상했다.


Credit: Getty Images Bank

스파크는 다양한 방법으로 배포가 가능하고 자바, 스칼라, 파이썬, R 프로그래밍 언어를 위한 네이티브 바인딩을 제공하며 SQL, 스트리밍 데이터, 머신러닝 및 그래프 처리를 지원한다. 은행, 통신업체, 게임업체, 정부를 비롯해 애플, 페이스북, IBM, 마이크로소프트와 같은 모든 주요 IT 기업들이 아파치 스파크를 사용한다.

스파크는 기본 상태에서 클러스터의 각 머신에 아파치 스파크 프레임워크와 JVM만 있으면 되는 독립형 클러스터 모드로 실행이 가능하다. 그러나 리소스 또는 클러스터 관리 시스템을 활용해 수요에 따라 작업자를 할당하고자 하는 경우가 더 많다.

기업에서 이는 일반적으로 하둡 얀(YARN)에서 실행하는 것을 의미하지만(클라우데라 및 호튼웍스 배포판이 스파크 작업을 이렇게 실행함) 아파치 스파크는 아파치 메소스에서도 실행 가능하다. 현재 쿠버네티스(Kubernetes)에 대한 네이티브 지원을 추가하기 위한 작업이 진행 중이다.

매니지드 솔루션을 찾는다면 아마존 EMR, 구글 클라우드 데이터프록(Google Cloud Dataproc) 및 마이크로소프트 애저 HD인사이트(HDInsight)에서 아파치 스파크를 찾을 수 있다.
아파치 스파크 창립자들을 채용한 업체 데이터브릭스(Databricks)는 아파치 스파크 클러스터, 스트리밍 지원, 통합 웹 기반 노트북 개발, 표준 아파치 스파크 배포판에 비해 최적화된 클라우드 I/O 성능을 갖춘 포괄적인 매니지드 서비스인 데이터브릭스 유니파이드 애널리틱스 플랫폼(Databricks Unified Analytics Platform)을 제공한다.

스파크와 하둡과의 비교
일단 아파치 스파크와 아파치 하둡과의 비교는 다소 부적절하다. 요즘에는 대부분의 하둡 배포판에 스파크가 포함된다. 그러나 스파크는 두 가지 큰 이점 덕분에 하둡의 부상을 이끈 기존 맵리듀스 패러다임을 앞질러 빅데이터 처리의 핵심 프레임워크로 부상했다.

첫 번째 이점은 속도다. 스파크의 메모리 내 데이터 엔진은 특정 상황에서, 특히 스테이지 간에 다시 디스크에 상태를 써야하는 다중 스테이지 작업과 비교할 때 맵리듀스에 비해 최대 100배 더 빠르다. 데이터가 메모리 내에 완전히 들어갈 수 없는 아파치 스파크 작업도 맵리듀스에 비해 약 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 Dataset, RDD) 개념이다. RDD에서의 운영 역시 여러 클러스터로 분할할 수 있으며 병렬 배치 프로세스로 실행이 가능하고, 이는 더 빠르고 확장성 높은 병렬 처리로 이어진다.

RDD는 간단한 텍스트 파일, SQL 데이터베이스, NoSQL 저장소(예를 들어 카산드라, 몽고DB), 아마존 S3 버킷, 그 외에도 많은 방법으로 생성할 수 있다. 스파크 코어 API의 대부분은 이 RDD 개념을 기반으로 구축되므로 전통적인 맵과 리듀스 기능을 실현하지만 그와 함께 데이터 집합 조인, 필터링, 샘플링 및 집계도 기본적으로 지원한다.

스파크에서 분산 실행을 구현하는 방법은 스파크 애플리케이션을 여러 작업으로 분할해 이를 작업을 시행하는 다수의 이그제큐터(executor) 프로세스로 분산하는 드라이버 코어 프로세스를 결합하는 것이다. 이런 이그제큐터는 애플리케이션의 필요에 따라 확장과 축소가 가능하다.

스파크 SQL
원래는 샤크(Shark)라는 이름으로 알려진 스파크 SQL은 아파치 스파크 프로젝트에서 점점 더 중요해지고 있다. 아마 현재 개발자들이 애플리케이션을 만들 때 가장 흔히 사용하는 인터페이스일 것이다.

스파크 SQL은 구조적 데이터 처리에 초점을 두며, R과 파이썬(판다스)에서 차용한 데이터프레임을 사용한다. 그러나 이름이 시사하듯 스파크 SQL은 데이터 쿼리를 위한 SQL2003 호환 인터페이스도 제공해 분석가는 물론 개발자도 아파치 스파크의 강력함을 활용할 수 있게 해준다.

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

데이터프레임에서 열을 선택하는 코드는 다음과 같이 간단하다.

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

SQL 인터페이스를 사용해서 데이터프레임을 임시 테이블로 등록하고 이후 이에 대해 SQL 쿼리를 발행할 수 있다.

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


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

아파치 스파크 2.x 시대에서 데이터프레임과 데이터 집합의 스파크 SQL 인터페이스(기본적으로 컴파일 시에 정확성 확인이 가능하고 런타임에 추가적인 메모리 및 컴퓨팅 최적화를 활용할 수 있는 형식이 지정된 데이터프레임)는 개발 시 권장되는 접근 방법이다. RDD 인터페이스도 여전히 사용할 수 있지만 스파크 SQL 패러다임 내에 캡슐화할 수 없는 경우에만 권장된다.

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

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

스파크 MLlib은 분류, 회귀, 클러스터링, 필터링과 같은 기본적인 머신러닝을 다루지만 심층 신경망(deep neural networks)을 모델링하고 학습시키기 위한 기능은 포함하지 않는다. 단, 딥 러닝 파이프라인은 현재 개발 중이다.

스파크 그래프X
스파크 그래프X(Spark GraphX)는 구글 페이지랭크 구현을 포함한 그래프 구조 처리를 위한 분산 알고리즘과 함께 제공된다. 이런 알고리즘은 스파크 코어의 RDD 접근 방법을 사용해 데이터를 모델링한다. 그래프프레임(GraphFrames) 패키지는 그래프 쿼리에 카탈리스트 옵티마이저를 활용하는 기능을 비롯해 데이터프레임에서 그래프 작업을 수행할 수 있게 해준다.

스파크 스트리밍
스파크 스트리밍(Spark Streaming)은 초기에 아파치 스파크에 추가된 요소로, 실시간 또는 근 실시간 처리가 필요한 환경에서 아파치 스파크가 부상하는 데 힘을 보탰다. 이전에는 아파치 하둡의 배치와 스트림 처리는 서로 별개의 세계였다. 배치 처리가 필요하면 맵리듀스 코드를 썼고, 실시간 스트리밍이 필요한 경우에는 아파치 스톰(Storm)과 같은 것을 사용했다.

결과적으로 서로 다른 리소스가 필요하고 서로 다른 운영 요소를 감안해야 하는, 서로 완전히 다른 프레임워크를 기반으로 함에도 불구하고 애플리케이션 도메인을 위해 개별적인 두 코드베이스의 동기화를 유지해야 하는 상황이 발생한다.

스파크 스트리밍은 스트리밍을 지속적인 일련의 마이크로배치로 나누는 방법으로 아파치 스파크의 배치 처리 개념을 스트리밍으로 확장했다. 이렇게 나눈 마이크로배치는 아파치 스파크 API를 사용해 조작이 가능하다. 이 방식을 통해 배치와 스트리밍 작업의 코드는 (대부분) 동일한 코드를 공유하며 동일한 네트워크에서 실행된다. 따라서 개발자와 운영자 오버헤드가 모두 줄어든다. 모두에게 이익이다.

스파크 스트리밍 접근 방법에 대한 비판점은 유입 데이터에 대한 저지연 응답이 필요한 시나리오에서 아파치 스톰, 아파치 플링크(Flink), 아파치 아펙스(Apex)와 같은 다른 스트리밍 지원 프레임워크의 성능에 비해 마이크로배치의 성능이 떨어진다는 점이다. 이러한 프레임워크는 모두 마이크로배치가 아닌 순수 스트리밍 방법을 사용한다.

구조적 스트리밍
스파크 스트리밍에서 구조적 스트리밍(Structured Streaming, 스파크 2.x에 추가)의 역할은 스파크 코어 API에서 스파크 SQL의 역할과 같다. 즉, 애플리케이션 작성을 위한 더 높은 수준의 API와 더 쉬운 추상화다. 구조적 스트리밍의 경우 더 높은 수준의 API는 개발자가 무한한 스트리밍 데이터프레임과 데이터 집합을 생성할 수 있게 해준다.

또한 이전 프레임워크, 특히 이벤트 시간 집계 및 늦은 메시지 배달 처리와 관련한 부분에서 사용자들이 씨름했던 골치아픈 몇 가지 문제도 해결해준다. 구조적 스트림의 모든 쿼리는 카탈리스트 쿼리 옵티마이저를 거치며 인터랙티브한 방식으로도 실행이 가능하므로 사용자는 라이브 스트리밍 데이터를 대상으로 SQL 쿼리를 수행할 수 있다.

구조적 스트리밍은 스파크 2.2 릴리스부터 프로덕션 환경에 사용 가능한 것으로 표시된 만큼 아파치 스파크에서 비교적 새로운 부분이다. 그러나 구조적 스트리밍은 이 플랫폼에서 스트리밍 애플리케이션의 미래이므로 새로운 스트리밍 애플리케이션을 제작 중이라면 구조적 스트리밍을 사용해야 한다.

기존의 스파크 스트리밍 API는 계속 지원되지만 이 프로젝트에서도 구조적 스트리밍으로의 이식을 권장한다. 새로운 방법이 훨씬 더 편하게 스트리밍 코드를 쓰고 유지할 수 있게 해주기 때문이다.

아파치 스파크의 다음 단계
구조적 스트리밍이 스파크 스트리밍을 개선하지만 지금은 스트리밍 데이터 처리에서 마이크로배치 체계에 계속 의존한다. 아파치 스파크는 마이크로배치 없이 지속적 스트리밍을 구현하기 위해 연구 중이며 이것이 실현될 경우 저지연 응답 처리와 관련된 많은 문제가 해결된다(현재 논의되는 수치는 1ms 미만으로, 상당히 인상적임). 더 좋은 점은 구조적 스트리밍은 스파크 SQL 엔진을 기반으로 하므로 코드를 변경하지 않고도 새 스트리밍 방법을 사용할 수 있다는 것이다.

아파치 스파크는 스트리밍 성능 개선 외에 딥 러닝 파이프라인을 통해 딥 러닝에 대한 지원도 추가할 예정이다. 향후 MLlib의 기존 파이프라인 구조를 사용해서 단 몇 줄의 코드로 분류기를 제작하고, 유입되는 데이터에 맞춤형 텐서플로우(Tensorflow) 그래프 또는 케라스(Keras) 모델을 적용할 수 있게 된다. 나아가 이런 그래프와 모델을 맞춤형 스파크 SQL UDF(사용자 정의 함수)로 등록할 수도 있으므로 딥 러닝 모델을 SQL 문의 일부로 데이터에 적용할 수 있다.

두 가지 기능 모두 프로덕션에 사용 가능하게 되려면 아직 멀지만 과거 아파치 스파크의 빠른 개발 속도로 비추어 볼 때 2018년이면 성숙기에 접어들 것으로 예상된다. editor@itworld.co.kr
 

X