BI|분석 / 개발자 / 데이터ㆍ분석 / 애플리케이션

글로벌 칼럼 | 스파크 1.6이 빅데이터에 중요한 이유

Ian Pointer | InfoWorld 2016.01.19
1월 초, 스파크 1.6이 출시되면서 빅데이터도 2016년 힘찬 도약을 시작했다. 스파크 팀은 원래 포인트 릴리스에서 유용한 기능을 제공해왔지만 1.6은 한 걸음 더 나아가 스파크 2.0을 향한 미니 이정표라 할 만한 버전이다.

스파크 1.6에는 개발자와 운영자 모두에게 유용한 새로운 기능과 개선 사항이 포함되어 있다. 그 가운데 중요한 부분들을 살펴보자.

자동 메모리 관리(Automatic memory management)
생산 환경에서 스파크를 사용하는 사람들은 스파크의 메모리 관리를 최적화하기 위해 필요한 수작업 튜닝에 대해 불만을 토로하는 경우가 많다. 특히 핫 데이터 메모리 로컬리티를 위한 캐싱과 실행 메모리(셔플, 정렬, 셔플링) 간의 정적 구분을 튜닝하기 위해 며칠씩을 가비지 컬렉션을 뒤져야 하는 경우도 있다.

물론 스파크 팀도 스파크에서 메모리 관리의 어려움을 인지해 프로젝트 텅스텐(Tungsten)을 통해 지난 몇 차례 릴리스에서 상당히 많은 부분을 개선했다.

스파크 1.6에는 현재 실행 계획에 따라 메모리 사용을 자동으로 조정하는 새로운 메모리 관리자가 포함되어 있다. 이 메모리 관리자가 모든 메모리 튜닝 문제를 해결해주진 않겠지만 고된 데이터 시스템 관리자의 업무를 한결 수월하게 해줄 것임은 분명하다.

스트리밍 개선(Streaming improvements)
스파크 스트리밍은 유망한 기능이지만 스톰(Storm)을 비롯한 경쟁 프레임워크에 비하면 그동안 신통치 못했다. 대규모의 집계 스트리밍 파이프라인이 큰 상태 변경에 대처하지 못하는 경우가 발생했고, 스파크의 updateStateByKey API는 전체 작업 세트를 메모리에 유지해야 한다.

스파크 1.6에 새롭게 추가된 API인 mapWithState는 전체 작업 세트가 아닌 델타를 다루므로 이전 방식에 비해 속도와 메모리 측면에서 즉각적인 이점을 제공한다.

과거 updateStateByKey 관련 문제로 인해 스파크 스트리밍 실험이 실패했다면 지금 다시 해보길 권한다. 데이터브릭스(Databricks)의 보고에 따르면 스파크 1.5 대비 속도 개선이 최대 10배에 이른다.

ML 지속성(ML persistence)
ML립(MLLib)은 머신러닝 도구/알고리즘 모음으로서의 가치를 높이고 있다. 스파크 1.6은 k-평균 클러스터링, 모델 요약 통계, 더 풍부한 R 지원 등으로 이 컬렉션을 더욱 보완했다(전체 목록은 릴리스 노트 참조).

이번 릴리스의 ML립에 추가된 최고의 새로운 기능은 파이프라인 지속성이다. 이전 버전에서도 모델을 지속시킬 수 있었지만 스파크 1.6에서는 외부 스토리지를 통해 에스티메이터(Estimator), 트랜스포머(Transformer), 모델, 파이프라인의 워크플로우를 가져오고 내보낼 수 있게 됐다.

덕분에 생산 환경에서 ML 파이프라인을 설정하는 데 필요한 코드의 양이 줄어들고 이것저것 실험하기가 훨씬 더 쉬워질 것이다(다른 워크플로우를 로드하는 간단한 방법으로 전체 파이프라인을 스왑할 수 있기 때문이다). 필자는 곧 이 기능을 사용할 기회를 고대하고 있다.

데이터셋과 스파크 2.0을 향한 길
스파크 1.6에 새로 추가된 요소 가운데 가장 중요한 것은 데이터셋일 것이다. 데이터셋은 데이터프레임에 RDD(Resilient Distributed Datasets)와 같은 작업을 제공하는, 형식 지정 확장이다. 많은 측면에서 RDD에 중심을 둔 과거 스타일의 코드와 새로운 데이터프레임 방식 사이에 남아 있는 간극을 잇는 다리라고 생각하면 된다.

전형적인 단어 수 계산 방법을 살펴보자. RDD 환경에서는 다음과 같이 한다.

val lines = sc.textFile("shakespeare.txt")
val words = lines.flatMap(_.split(" "))
val counts = words.groupBy(_.toLowerCase).map(w => (w._1, w._2.size))


그러나 데이터프레임/데이터셋 방식에서는 먼저 as() 메서드를 사용해 String 형식의 데이터프레임을 선언한다(케이스 클래스(case classes)나 자바 빈스(Java Beans)를 사용해 더 복잡한 데이터의 형식 지정 가능).

val lines = sqlContext.read.text("shakespeare.txt").as[String]
val words = lines.flatMap(_.split(" "))
val counts = words.groupBy(_.toLowerCase).count()


보다시피 flatMap()과 같은 전통적인 RDD 형태의 함수뿐만 아니라 표준 데이터프레임 count() 집계에도 접근할 수 있다.

대수롭지 않게 생각될 수도 있지만 내부적으로 많은 작업이 이뤄진다. 이것이 데이터프레임 위에서 실행되고 실행 계획은 카탈리스트(Catalyst) 쿼리 플래너를 통해 생성된다. 즉, 기존 RDD 코드로 만들었던 것보다 더 최적화된 계획을 생산하게 된다. 작업은 동적 최적화 프로세스에서 계속 수행되므로 카탈리스트는 더 효율적인 방법으로 수신 데이터를 처리할 수 있다고 판단되는 경우 실행 계획을 변경할 수 있다.

또한 데이터셋 구성에 제공되는 형식 정보는 직렬화(serialization)를 위한 인코더 생성에 사용된다. 생산 환경에서 스파크를 사용하는 경우 클러스터를 거쳐 데이터를 전송하기 위한 자바 직렬화 오버헤드로 인해 메모리 문제에 직면하게 될 가능성이 높다(그래서 크라이오(Kryo) 직렬화로 바꾸곤 한다).

인코더는 직렬화와 역직렬화(deserialization)를 위한 맞춤형 바이트코드를 생성하는 최적화된 코드 생성기이며(스파크 1.6은 프리미티브(primitives), 케이스 클래스, 자바빈스를 위한 인코더를 포함하며 이후 릴리스에서 API를 공개할 예정), 데이터브릭스에 따르면 크라이오보다 메모리를 덜 사용하면서 10배 이상의 성능을 제공한다.

데이터셋은 스파크 2.0에서 중요한 요소가 될 것이다. 스파크 1.6에서 데이터셋 API는 '실험적 기능'으로 분류되어 있지만 지금부터 바로 연구를 시작하기를 권한다. 그래야 이 새로운 데이터 조작 방법에서 앞서 나갈 수 있을 것이다.

스파크 1.6에는 이번에 언급한 것보다 더 많은 기능이 있다. 앞서 언급했지만 추가된 모든 기능은 릴리스 노트를 통해 확인할 수 있다(예를 들어 JSON 지원 향상, 멀티테넌트 SQLContext 등). 스파크 2.0을 향해 가는 길목에서 아마 올해는 스파크가 빅데이터 처리를 위한 기본 플랫폼으로 자리잡는 해가 될 것이다. editor@itworld.co.kr

회사명 : 한국IDG | 제호: ITWorld | 주소 : 서울시 중구 세종대로 23, 4층 우)04512
| 등록번호 : 서울 아00743 등록발행일자 : 2009년 01월 19일

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

Copyright © 2024 International Data Group. All rights reserved.