Page 1


책1.indb 1

2017-01-25 오전 11:45:27


IV

서문

처음 하둡을 접한 것은 2011년 여름이었습니다. 당시 스프링 프레임워크를 주로 사 용하던 웹 개발자였던 저는 새로운 업무를 맡을 기회가 생겨 야심 찬 포부를 가지고 처음으로 하둡과 마주했습니다. 하지만 하둡에 관해 아무런 사전 지식이 없었기에 저에게 하둡은 너무나 생소하고 어려운 기술로 다가왔습니다. 당시만 해도 초보자를 위한 친절한 하둡 책을 구하기가 쉽지 않았고, 어딘지 모르게 생소한 코드와 결과를 얻기까지의 오랜 기다림, 문제가 발생해도 원인을 찾을 방법 이 없는 엄청난 크기의 데이터 파일과 익숙지 않은 디버깅 환경, 이 모든 것들이 스 프링과 같은 고급 프레임워크에 길들여져 있던 저에게는 큰 어려움으로 다가오기에 충분했습니다. 그래서인지 처음 빅데이터와 하둡을 접하던 시기에 코끼리 그림이 그려진 책을 손에 들고 망연자실하던 기억이 지금도 생생하기만 합니다. 그렇게 하루하루 맵리듀스를 배우는 재미에 빠져들어가고 있을 무렵 우연히 접하게 된 스파크에 관한 기사는 저에게 매우 깊은 인상을 안겨줬습니다. 맵리듀스로 구현 하려면 몇 번의 작업을 연달아 수행해야 겨우 구할 수 있을까 말까 한 데이터를 절 반 수준도 안 되는 짧은 코드로 처리할 수 있는 데다 기존 라이브러리보다 빠른 성 능까지 겸비했다니 한편으론 그동안 고생한 게 억울하기도 하고 어서 사용해 보고 싶다는 욕구도 강하게 들었습니다.

책1.indb 4

2017-01-25 오전 11:45:29


서문

V

하지만 막상 스파크를 써보기로 마음먹었을 때 엉뚱한 곳에서 문제가 터졌습니다. 그것은 바로 스파크가 아닌 스칼라(Scala) 언어였습니다. 물론 그때도 스파크 공식 문서에서는 스칼라뿐 아니라 자바와 파이썬 언어에 대한 프로그래밍 가이드도 함께 제공하고 있었지만 초보자인 제가 읽을 수 없는 코드로 작성된 프레임워크를 사용 한다는 것은 결코 쉬운 일이 아니었습니다. API를 읽다가 막히면 소스코드를 들여 다봐서 이해하곤 했는데 소스코드가 암호문 같아서 도무지 이해할 수가 없었기 때문 이었습니다. 특히 자바 언어를 사용할 경우 스칼라로 작성된 예제에서 본 것 같은 간 결한 방식으로 작성하기가 쉽지 않다는 사실을 깨닫고 나서는 누군가의 축적된 노하 우나 베스트 프랙티스 같은 걸 배워서 적용할 수 있다면 좋겠다고 생각했습니다. 그러던 어느 날 우연히 미국 아마존 홈페이지를 방문했는데, 그곳에서 스파크와 하 둡의 맵리듀스 코드를 비교해서 설명해 주는 서적을 발견했습니다. 동일한 문제에 대한 RDD와 맵리듀스의 해결 방법을 비교해 둔 것도 흥미로웠지만 무엇보다도 예 제 코드가 스칼라가 아닌 자바 언어로 작성돼 있다는 점이 마음에 들었습니다. 예제 코드에 목말라 있던 저는 곧바로 그 책을 구매했고 한두 장 읽어나가는 과정에서 문 득 이 책을 저와 같은 상황에 놓인 개발자들에게도 소개하면 좋겠다는 생각이 들었 습니다. 며칠을 고민하다가 부족하나마 원서 번역을 해 봤던 예전의 경험을 떠올려 위키북스에 번역 제안을 하게 됐고, 그때의 인연이 지금까지 이어져 직접 이 책을 쓰는 계기가 됐습니다.

책1.indb 5

2017-01-25 오전 11:45:29


VI

서문

당시 저에게 스파크는 RDD만으로도 충분히 매력적이었습니다. 하지만 지금의 스 파크는 RDD보다도 더 뛰어난 API로 무장한 데이터셋을 도입해서 머신러닝, 그래 프 알고리즘, 실시간 스트리밍 처리는 물론이고 R, 하이브(Hive), 카프카(Kafka), 아파치 제플린(Zeppelin), NumPy 등 빅데이터 분야의 기존 스타들과의 연동을 통해 데이터 처리와 관련된 거의 대부분의 영역에서 영향력을 높여가고 있습니다. 심지어 이러한 스파크의 인기가 한동안 주목받지 못했던 스칼라 언어에 대한 인기 로까지 이어지면서 최근에는 R, 파이썬과 더불어 스칼라가 머신러닝과 데이터 처리 분야에서 자주 활용되는 주력 언어로 자리매김했습니다. 이 책은 저처럼 스파크에 대해서는 들어본 적이 있지만 이런저런 이유로 주저하고 있던 동료 개발자들에게 스파크란 이런 것이다, 라고 소개할 목적으로 집필한 책입 니다. 당연한 이야기겠지만 스파크가 빅데이터 분야의 전 범위를 아우르는 라이브 러리라고 해서 이 책을 쓰는 제가 그런 능력이나 지식을 갖추고 있는 것은 결단코 아닙니다. 저 역시 하둡을 비롯한 빅데이터 분야의 기술을 배운 지 이제 겨우 6년을 조금 넘었을 뿐이며, 매일 쏟아지는 기사를 읽고 기존에 모르던 새로운 기술을 배우 느라 하루가 어떻게 지나가는지 모르게 일하고 공부하고 있습니다. 처음 이 책을 집필할 때는 그동안 제가 도움을 받았던 여러 훌륭한 책처럼 최대한 상세하면서도 쉽고 명확한 설명을 싣고 이해를 돕기 위한 그림도 충분히 넣어야겠

책1.indb 6

2017-01-25 오전 11:45:30


서문

VII

다고 생각했지만 막상 집필을 해보니 저에게 부족한 점이 너무나 많다는 점과 자신 의 생각을 다른 사람에게 글로 전달한다는 것이 얼마나 어려운 일인지 새삼 깨달았 습니다. 비록 이 책이 스파크를 마스터할 수 있는 교재는 아니더라도 최소한 스파크 의 개념을 잡고 현업에서 활용하고자 하는 동료 개발자들의 시간을 조금이라도 줄 여주는 데 보탬이 됐으면 하는 바람입니다. 마지막으로 짧다면 짧고 길다면 긴 집필 기간 동안 배려와 조언, 응원으로 도와주신 분들께 감사하다는 말씀을 전해드리며 이 글을 마치고자 합니다. 먼저 이런 기회를 주신 하나님께 감사드립니다. 또한 마음으로 기도로 집필 과정을 지켜봐 주시고 응원해 주신 부모님과 장인, 장모님, 때로는 기술로, 때로는 조언과 응원으로 도움을 주신 동료들에게 감사하다는 말을 전하고 싶습니다. 무엇보다 긴 시간 동안 인내하면서 응원과 조언을 아끼지 않으신 위키북스 박찬규 대표님과 정 리도 안 된 원고를 교정하느라 지금도 고생하고 계실 이대엽 님, 그리고 반복된 수 정 요청에도 꼼꼼히 대응해 주신 김남곤 님께 감사의 말씀을 드립니다. 끝으로 주말마다 가족을 버려두고 방에만 처박혀 있는 남편을 이해해 주고 응원해 준 사랑하는 아내 영미와 아빠랑 운동하고 예당마을에 산책 갈 날만 기다리는 우리 쌍둥이 진우, 선우에게 진심으로 고맙고 미안하다는 말을 전합니다.

책1.indb 7

2017-01-25 오전 11:45:30


VIII

목차

01

1.1 스파크 장

스파크 소개

1.1.1 빅데이터의 등장

2

1.1.2 빅데이터의 정의

4

1.1.3 빅데이터 솔루션

5

1.1.4 스파크

9

1.1.5 RDD(Resilient Distributed Dataset) 소개와 연산

12

1.1.6 DAG

19

1.1.7 람다 아키텍처

23

1.2 스파크 설치

25

1.2.2 사전 준비

26

1.2.3 스파크 설치

29

1.2.4 예제 실행

31

1.2.5 스파크 셸

32

1.2.6 실행 옵션

41

1.2.7 더 살펴보기

46

1.3.1 로컬 개발 환경 구축

1.4 예제 프로젝트 설정 1.4.1 WordCount 예제 실행

RDD

책1.indb 8

25

1.2.1 스파크 실행 모드의 이해

1.3 개발 환경 구축

02

2

49 49 58 60

1.5 정리

82

2.1 RDD

83

2.1.1 들어가기에 앞서

84

2.1.2 스파크컨텍스트 생성

91

2.1.3 RDD 생성

92

2017-01-25 오전 11:45:30


목차

2.1.4 RDD 기본 액션

94

2.1.5 RDD 트랜스포메이션

97

2.1.6 RDD 액션

140

2.1.7 RDD 데이터 불러오기와 저장하기

156

2.1.8 클러스터 환경에서의 공유 변수

163

2.2 정리

174

3.1 클러스터 환경

175

3.1.1 클러스터 모드와 컴포넌트

176

3.1.2 클러스터 모드를 위한 시스템 구성

180

3.1.3 드라이버 프로그램과 디플로이 모드

185

3.2 클러스터 매니저

책1.indb 9

클러스터 환경

187

3.2.1 스탠드얼론 클러스터 매니저

188

3.2.2 아파치 메소스

206

3.2.3 얀

219

3.2.4 히스토리 서버와 매트릭스

232

4.1 스파크 프로퍼티

234

4.2 환경변수

240

4.3 로깅 설정

240

4.4 스케줄링

241

4.4.1 애플리케이션 간의 자원 스케줄링

241

4.4.2 단일 애플리케이션 내부에서의 자원 스케줄링

243

4.5 정리

03

IX

04

스파크 설정

245

2017-01-25 오전 11:45:31


X

목차

05

스파크 SQL

5.1 데이터셋

249

5.2 연산의 종류와 주요 API

249

5.3 코드 작성 절차 및 단어 수 세기 예제

252

5.4 스파크세션

259

5.5 데이터프레임, 로우, 칼럼

260

5.5.1 데이터프레임 생성

261

5.5.2 주요 연산 및 사용법

271

5.6 데이터셋

06 스파크 스트리밍

5.6.1 데이터셋 생성

318

5.6.2 타입 트랜스포메이션 연산

323

5.7 하이브 연동

333

5.8 분산 SQL 엔진

335

5.9 Spark SQL CLI

336

5.10 정리

337

6.1 개요 및 주요 용어

341

6.1.1 스트리밍컨텍스트

341

6.1.2 DStream(Discretized Streams)

345

6.2 데이터 읽기

책1.indb 10

316

346

6.2.1 소켓

347

6.2.2 파일

349

6.2.3 RDD 큐(Queue of RDD)

350

6.2.4 카프카(Kafka)

351

6.3 데이터 다루기(기본 연산)

357

6.3.1 print()

358

6.3.2 map(func)

358

2017-01-25 오전 11:45:32


목차

6.3.3 flatMap(func)

359

6.3.4 count(), countByValue()

359

6.3.5 reduce(func), reduceByKey(func)

360

6.3.6 filter(func)

360

6.3.7 union()

361

6.3.8 join()

361

6.4 데이터 다루기(고급 연산)

XI

362

6.4.1 transform(func)

362

6.4.2 updateStateByKey()

363

6.4.3 윈도우 연산

366

6.4.4 window(windowLength, slideInterval)

368

6.4.5 countByWindow(windowLength, slideInterval)

368

6.4.6 reduceByWindow(func, windowLength, slideInterval)

369

6.4.7 reduceByKeyAndWindow(func, invFunc, windowLength, slideInterval, [numTasks])

370

6.4.8 countByValueAndWindow(windowLength, slideInterval, [numTasks])

6.5 데이터의 저장

374 374

6.5.1 saveAsTextFiles(), saveAsObjectFiles(), saveAsHadoopFiles() 6.5.2 foreachRDD()

책1.indb 11

374 375

6.6 CheckPoint

376

6.7 캐시

382

6.8 모니터링

382

6.9 주요 설정

383

2017-01-25 오전 11:45:32


XII

목차

07

스트럭처 스트리밍

08 MLlib

책1.indb 12

7.1 개요

387

7.2 프로그래밍 절차

389

7.3 데이터프레임과 데이터셋 생성

395

7.4 스트리밍 연산

397

7.4.1 기본 연산 및 조인 연산

397

7.4.2 윈도우 연산

399

7.4.3 워터마킹

403

7.4.4 스트리밍 쿼리

407

7.5 정리

410

8.1 개요

412

8.2 관측과 특성

412

8.3 레이블

413

8.4 연속형 데이터와 이산형 데이터

413

8.5 알고리즘과 모델

413

8.6 파라메트릭 알고리즘

414

8.7 지도학습과 비지도학습

415

8.8 훈련 데이터와 테스트 데이터

415

8.9 MLlib API

416

8.10 의존성 설정

416

8.11 벡터와 LabeledPoint

417

8.11.1 벡터

418

8.11.2 LabeledPoint

420

8.12 파이프라인

423

8.13 알고리즘

433

8.13.1 Tokenizer

433

8.13.2 TF-IDF

435

8.13.3 StringIndexer, IndexToString

438

2017-01-25 오전 11:45:33


목차

8.14 회귀와 분류

442

8.14.1 회귀

442

8.14.2 분류

458

8.15 클러스터링

469

8.16 협업 필터링

474

8.17 정리

476

9.1 개요

477

9.2 R 설치 및 실행

478

09

9.3 데이터프레임

480

SparkR

9.4 데이터프레임 생성

480

9.4.1 R데이터프레임으로부터 생성

481

9.4.2 파일로부터 생성

483

9.5 데이터프레임 연산

책1.indb 13

XIII

484

9.5.1 조회 및 기본 연산

485

9.5.2 그룹 및 집계 연산

490

9.5.3 칼럼 연산

495

9.5.4 집합 연산

498

9.5.5 dapply(), dapplyCollect()

500

9.5.6 gapply(), gapplyCollect()

501

9.5.7 spark.lapply()

503

9.5.8 createOrReplaceTempView()

503

9.5.9 write()

504

9.6 하이브 연동

504

9.7 머신러닝

504

9.8 정리

507

2017-01-25 오전 11:45:34


XIV

목차

10 GraphX

10.1 주요 용어 장

10.1.1 유방향 그래프

509

10.1.2 유방향 멀티 그래프

510

10.1.3 속성 그래프

510

10.2 데이터 타입

책1.indb 14

509

511

10.2.1 RDD

511

10.2.2 VertextID

511

10.2.3 꼭짓점

511

10.2.4 선(Edge)

511

10.2.5 EdgeTriplet

512

10.2.6 VertexRDD

512

10.2.7 EdgeRDD

513

10.2.8 Graph

513

10.3 그래프 생성

514

10.4 그래프 연산

516

10.4.1 numEdges, numVertices

517

10.4.2 inDegrees, outDegrees, degrees

517

10.4.3 vertices, edges, triplets

518

10.4.4 mapVertices(), mapEdges(), mapTriplets()

518

10.4.5 reverse()

519

10.4.6 subgraph()

520

10.4.7 mask()

521

10.4.8 groupEdges()

521

10.4.9 joinVertices(), outerJoinVertices()

523

10.4.10 collectNeighborIds(), collectNeighbors()

523

10.4.11 aggregateMessages()

524

10.4.12 pregel()

526

10.5 VertextRDD, EdgeRDD 연산

529

10.6 그래프 알고리즘

533

10.7 정리

534

2017-01-25 오전 11:45:34


목차

책1.indb 15

스칼라 설치

535

스칼라 셸

536

변수 타입과 변수 선언

537

Range와 형변환

538

클래스, 객체, 컴패니언 오브젝트

539

트레이트와 상속

541

apply

542

튜플과 옵션, 케이스클래스

543

패턴 매치

544

패키지 객체

546

type

547

임포트

547

함수와 메서드

547

제네릭

549

암묵적 변환과 타입 클래스 패턴

549

정리

551

XV

부록 스칼라란?

2017-01-25 오전 11:45:35


01 스파크 소개

이번 장에서는 빅데이터의 의미와 특징을 살펴보고 빅데이터 처리를 위해 등장한 주요 기술로 어떤 것들이 있는지 알아보겠습니다.

1.1 스파크 1.1.1 빅데이터의 등장 ‘유행은 돌고 돈다’라는 말이 있습니다. 패션도 그렇고 음악도 그렇고 사람에 대한 이상형 또한 그렇 습니다. 물론 정말 똑같은 옷, 똑같은 노래가 다시 나와서 과거와 같은 인기를 누리는 것은 아닙니 다. 예를 들어, 옷의 경우 옷감은 더 튼튼하면서도 가벼워지고 색상은 훨씬 선명해졌으며, 예전에 비 해 잘 바래지지도 않습니다. 게다가 더울 때는 땀을 배출해 주고 추울 때는 체온을 유지해 주는 기능 까지 갖추고 있는, 말 그대로 스마트한 옷이 됐습니다. 옷 자체만 보면 분명 매일매일 달라지고 있지

책1.indb 2

2017-01-25 오전 11:45:35


01. 스파크 소개

3

만 옷에 대한 취향은 몸에 꼭 맞는 옷에서 조금 넉넉하게 편안한 옷으로 또 다시 몸에 꼭 맞는 옷으 로, 시간과 상황에 따라 비슷하게 반복되는 것 또한 사실입니다. 요즘 매일 같이 새로운 기술들이 쏟아져 나오는 IT 분야도 결코 이 법칙에서 예외라고 할 수는 없을 것입니다. 흔히 패러다임의 변화라고 불리는 기술들의 등장 배경을 살펴보면 과거에도 경험했던 문 제 상황과 해법들이 시간의 흐름에 따라 변화된 컴퓨팅 환경과 비즈니스 요구사항을 만나서 예전과 는 사뭇 달라진 모양새를 갖춰서 나타난 것임을 느낄 때가 종종 있습니다. “해 아래 새것이 없다”는 성경 구절처럼 새롭게 등장해서 주목받는 기술들이라고 해서 모두 다 과거 에 생각해 본 적도 없던 새로운 아이디어와 이론을 기반으로 하는 것만은 아닙니다. 아주 오래전부 터 있어왔지만 단지 상상을 뒷받침해 줄 만한 기반 이론과 기술이 성숙하지 못했고 사람들의 무관심 에 제대로 주목받지 못하고 구현되지 못했던 아이디어들이 새로운 환경을 만나 결실을 이룬 것들도 많습니다. 그렇다고 새로운 기술들을 접할 때 무조건 과거에 이미 알고 있던 지식에 빗대어 배워야 한다는 의 미는 아닙니다. 오히려 그렇게 하는 것은 가급적 피해야 할 잘못된 학습 방법 중 하나라고 할 수 있 습니다. 새로운 개념의 언어를 배울 때 기존에 익숙한 문법이나 프로그래밍 방식을 하나하나 대조해 가면서 이해하려 한다거나 HBase 같은 NoSQL 데이터베이스를 기존의 관계형 데이터베이스 지식 과 어떻게든 연관 지어 이해해 보려고 하는 시도 등이 그런 예라고 할 수 있습니다. 누구나 잘 알고 있는 당연한 이야기를 굳이 말머리에 끄집어낸 이유는 새로운 기술을 접할 때 열린 마음을 갖는 것도 중요하지만 지나치게 두려워하고 낯설어하거나, 반대로 무슨 마법이라도 보여줄 수 있을 것처럼 맹목적인 신뢰를 보여서도 안 된다는 얘기를 하고 싶었기 때문입니다. 바야흐로 빅데이터의 세상이 됐습니다. 개발자들을 대상으로 하는 기술 세미나에는 빅데이터와 관련된 주제가 꼭 한두 가지 포함되는 것이 기본이고 IT 회사의 채용 공고에도 빅데이터 관련 분야가 따로 분류돼 있습니다. 아내와 제가 즐겨 보던 모 방송국 프로그램에 소위 빅데이터 전문가라는 분이 출연하면서 이제 아내도 주변 사람들에 게 저를 소개할 때 광고 분야에서 일하는 남편 대신 정확한 제 업무를 말해 줄 수 있게 됐습니다.

IT 관련 기사나 서적을 보면 정치, 금융, 제조, 국방, 정보통신 등등 거의 모든 사회 분야에서 빅데 이터가 활용되고 있으며, 이러한 추세에 따라 빅데이터가 세상을 바꿀 것이라는 얘기도 심심치 않게 나오고 있습니다. 이제 더 이상 권위 있는 조사기관의 통계 자료나 기사를 인용하지 않더라도 빅데 이터가 우리 사회에 큰 영향을 미치고 있음을 누구나 공감할 수 있는 세상이 됐습니다.

책1.indb 3

2017-01-25 오전 11:45:36


4

빅데이터 분석을 위한 스파크 2 프로그래밍: 대용량 데이터 처리부터 머신러닝까지

1.1.2 빅데이터의 정의 IT라고 하면 컴퓨터와 핸드폰 등 각종 전자 기기들을 떠올리게 됩니다. 그래서 IT 분야는 그 어떤 다 른 산업 분야보다 명확하고 과학적이며 객관적인 사실들로 가득 차 있으리라는 기대감을 줍니다. 하 지만 실제로 IT 업계에서 사용하는 용어 중에는 정확한 의미를 설명하기 모호한 것들이 의외로 많습 니다. 한때 인터넷 업계를 술렁이게 했던 ‘웹2.0’과 ‘웹 서비스’가 그랬고 지금 다루고 있는 빅데이터 역시 한마디로 정의하기에는 모호한 부분들이 없지 않습니다. 이런 용어들은 대개 기술 세미나 또는 특정 회사의 홍보 과정에서 사용했던 신종 용어들이 다양한 경로를 통해 전달되는 과정에서 다양한 의미가 덧붙여져 생겨나는 경우가 많습니다. 또 어떤 기술들 은 관련 표준이 여러 버전으로 나뉘면서 복합적인 의미를 내포하게 된 경우도 있습니다. 따라서 이 런 용어를 한두 마디의 짧은 문장으로는 명확히 정의내리는 것은 쉬운 일이 아닙니다. 빅데이터라는 용어도 특별한 협의 과정을 거쳐서 정의된 용어가 아니다 보니 이 용어의 정의가 필 요할 때는 외국의 대형 IT 기업 또는 연구기관에서 발표한 연구 결과 등을 인용하는 경우가 많습니 다. 2001년 가트너의 더그 레이니( Doug Laney)가 작성한 연구 보고서는 그중 많은 기사에서 자 주 인용되고 있는 자료 중 하나인데, 여기서는 빅데이터를 크기( Volume)와 다양성( Variety), 속도 ( Velocity)라는 세 가지 속성을 통해 정의하고 있습니다. 즉, 다양한 형태를 지닌 대량의 데이터가 빠른 속도도 쌓이고 있다면 이를 빅데이터라고 부를 수 있다는 뜻입니다. 그 후 시간이 흐르면서 빅 데이터에 대한 정의도 몇 차례 수정됐고 현재는 가변성( Variability)과 정확성( Veracity), 복잡성 ( Complexity), 시인성( Visibility) 등도 새로운 빅데이터의 속성으로 추가됐습니다. 이렇게 크고 빠르고 복잡한 것이 빅데이터라고 정의한다 해도 아직 모호하기는 마찬가지입니다. 왜 냐하면 크고 빠르고 복잡한 것에 대한 기준은 아직도 정해진 것이 없기 때문입니다. 어쩌면 모 연예 인의 유명 대사처럼 “(크기가) 얼마면 돼?”라고 물어야 할지도 모르겠습니다. 이 또한 정답은 아니 겠지만 아래에 빅데이터의 주요한 속성이라고 언급되는 것들을 몇 가지 골라서 정리해봤습니다. ■■ 크기:

첫 번째 속성인 데이터의 크기 측면에서 볼 때 빅데이터는 대량의 데이터를 처리한다는 특성을 지니고 있습니다. 하지

만 구체적으로 얼마 정도의 크기라야 ‘대량’이라고 말할 수 있을까요? 페이스북의 경우 2012년에 이미 하루 평균 500테라 바이트(TB) 이상의 데이터를 처리하고 있다고 발표했습니다. 그렇다면 만약 내가 운영하는 시스템에 하루 평균 쌓이는 로 그가 페이스북의 1/5000 수준인 100기가바이트(GB) 정도라면 페이스북에 비해 너무 작은 용량이라서 빅데이터라고 부를 수 없는 걸까요? 앞서 말한 빅데이터의 정의에 따르면 데이터의 크기는 그 데이터가 빅데이터인지를 구분하는 데 중요한 기준이 되는 것은 맞습니다. 하지만 이때 말하는 크기 기준은 꼭 정해진 어떤 값이라기보다 기존에 보유하고 있던 일반적인 규모의 서버와 기술을 가지고 처리할 수 있는 용량의 한계를 의미한다고도 볼 수 있습니다. 즉, 어떤 시스템에서 처리해야 할 데이터가 기존에 보유한 서버와 기술로는 더 이상 다룰 수 없는 수준의 용량에 도달했다면 이를 해결하기 위한 빅데이터

책1.indb 4

2017-01-25 오전 11:45:36


01. 스파크 소개

5

기술들의 도입이 필요해진 것이고, 이 경우 데이터의 크기 측면에서 빅데이터의 요건을 충족했다고 말할 수도 있을 것입니 다. 물론 그렇다면 기존 서버의 용량은 어떤 수준이어야 하는가?라는 물음이 또 나올 수 있겠지만 어떤 특정 데이터를 처리 할 때 빅데이터 기술의 도입이 내가 고려할 수 있는 여러 해법 가운데 가장 좋은 해법이 된다면 이제 빅데이터의 세계에 들 어왔다고 봐도 좋을 것입니다. ■■ 속도:

데이터의 종류는 무궁무진하게 많습니다. 하지만 빅데이터라고 하면 보통 구글이나 아마존과 같은 인터넷 기업의 로

그 파일이나 통신사의 통화 기록, 페이스북의 좋아요, 사용자들이 업로드한 사진 등을 대표적인 예로 뽑곤 합니다. 이런 데 이터의 특징은 단순히 용량이 많기도 하지만 데이터의 증가가 꾸준히, 그러면서도 빠른 속도로 진행된다는 것입니다. 특별 히 어느 정도 빨라야 하는가에 대한 기준이 있는 것은 아니지만 데이터의 증가가 지속적이고 빠르기 때문에 이에 부합하는 빠른 데이터 처리 기술 또한 필요하다는 특성을 갖고 있습니다. ■■ 다양성:

이 속성은 빅데이터의 다양성을 의미합니다. 앞에서도 언급했듯이 데이터베이스에 저장된 전통적인 데이터는 물론

이고 웹 서버나 각종 전자 기기의 작업 수행 로그, SNS 등에서 생성되는 이미지와 동영상 등 세상의 모든 데이터가 빅데이 터 후보가 될 수 있다는 것을 의미합니다. 결국 빅데이터를 제대로 다루기 위해서는 이런 다양성에 대비한 대비책 또한 필 요하다는 것을 알 수 있습니다.

지금까지 빅데이터의 정의와 빅데이터의 몇 가지 속성을 살펴봤습니다. 다음 절에서는 다양한 빅데 이터 솔루션의 종류와 특징을 간략하게 알아보겠습니다.

1.1.3 빅데이터 솔루션 빅데이터를 처리하기 위한 기술은 지금도 꾸준히 발전하고 있습니다. 독자분들 중에는 현업에서 빅 데이터 관련 업무를 하고 계시는 분들도 있고 그렇지 않은 분들도 있겠지만 어느 쪽이든 하둡에 대 해서는 한 번쯤 들어보셨을 것입니다. 물론 하둡은 이 분야에서 가장 널리 알려진 분산 처리 프레임워크입니다. 하지만 현업에서 빅데이터 처리를 할 때 하둡만으로는 부족한 부분들이 많다고 할 수 있습니다. 빅데이터 분야에 어떤 소프트웨어들이 있는지 살펴보기 전에 먼저 우리가 직접 빅데이터 처리용 플 랫폼을 구축한다면 어떤 모습이 될지 간단하게 생각해 보겠습니다. 편의상 각 처리 단계를 담당하는 소프트웨어 컴포넌트를 “모듈”이라는 이름으로 부르겠습니다. 먼저 데이터를 처리하는 플랫폼이니만큼 데이터를 가져오는 데이터 수집 모듈이 필요할 것입니다. 이 모듈의 역할은 여기저기 다양한 형태로 흩어진 데이터를 수집해서 그다음 단계에 있는 모듈에게 전달해 주는 것입니다. 빅데이터 정의에서 살펴본 바와 같이 빅데이터는 파일이나 이미지, 동영상 등 다양한 형태로 존재할 수 있고 일반적인 애플리케이션 서버 한 대 정도의 규모로는 처리하기 곤란한 수준의 대용량이면서

책1.indb 5

2017-01-25 오전 11:45:36


6

빅데이터 분석을 위한 스파크 2 프로그래밍: 대용량 데이터 처리부터 머신러닝까지

빠르게 증가하는 속성을 띠고 있기 때문에 수집 모듈 역시 이런 데이터의 특성에 맞춰 동작할 수 있 는 능력이 필요할 것입니다. 예를 들어, 데이터가 1초에 수십 메가바이트씩 생성되는데 수집 모듈이 하루에 한 번씩만 데이터를 수집할 수 있다면 그 데이터는 결국 하루에 한번 생성되는 것이나 마찬 가지이기 때문입니다. 하지만 빠른 처리가 필요하다고 해서 원본 데이터가 담긴 서버에 과도한 부하를 주면 안 될 것입니 다. 따라서 최소한의 컴퓨팅 자원을 사용해 빠르고 안정적으로 데이터를 수집하고 여러 클라이언트 에서 나눠줄 수 있는 능력을 갖춰야 합니다. 흔히 데이터 수집은 그냥 주기적으로 한 번씩 하면 되는 것으로 쉽게 생각할 수 있는데, 데이터 수집은 빅데이터 시스템을 구축할 때 가장 신경 써야 하는 핵 심 모듈 중 하나라고 할 수 있습니다. 다음으로는 이렇게 수집된 데이터를 저장하고 조회하는 저장 및 조회 모듈이 필요합니다. 저장 및 조회 모듈이라고 표현했지만 개발자들에게 좀 더 친숙한 단어로 다시 표현하자면 수집한 데이터에 대한 CRUD1를 수행하는 모듈이 필요하다는 의미입니다. 단, 이때도 기존 데이터 저장소와는 다르 게 빅데이터의 특성을 잘 살려줄 수 있는 저장 및 처리 기능이 필요합니다. 예를 들어, 수백 기가바 이트에서 수 테라바이트에 달하는 데이터를 저장하거나 조회하더라도 안전하고 투명한 방식으로 여 러 서버에 분산해서 처리할 수 있는 능력이 필요합니다. 데이터에 대한 기본적인 읽기와 쓰기 기능을 위한 모듈이 구축됐다면 이제는 본격적으로 데이터를 분석하고 그 결과를 가공할 수 있는 모듈이 필요합니다. 이렇게 가공된 결과는 사람에게 전달될 수 도 있고 외부 시스템에 전달될 수도 있는데 각 경우에 맞게 데이터를 분석하고 리포팅할 수 있는 모 듈을 구축해야 합니다. 또한 이 모든 과정을 제어할 수 있는 워크플로우 엔진 기능이 필요할 수도 있습니다. 물론 작업 흐름 을 관리하는 셸 스크립트 같은 코드를 작성하거나 기존 시스템에서 사용하던 배치 작업 관리 소프트 웨어를 그대로 사용할 수도 있습니다. 하지만 여러 종류의 빅데이터 소프트웨어들이 순차적으로 연 동되어 동작해야 하는 빅데이터 작업의 특성을 생각해 볼 때 다양한 소프트웨어들을 통일된 방식으 로 제어하고 작업 실패 시 재실행과 복구 등을 지원하는 워크플로우 도입은 유용한 도구가 될 수 있 습니다. 마지막으로 빅데이터 처리 작업에 크고 작은 도움을 주는 다양한 관리 및 유틸리티 성격의 모듈들이 필요합니다.

1

책1.indb 6

CRUD: Create, Read, Update, Delete(https://ko.wikipedia.org/wiki/CRUD)

2017-01-25 오전 11:45:36


01. 스파크 소개

7

지금까지 간단하게 빅데이터 처리 플랫폼의 모습을 그려봤습니다. 우리가 알고 있는 것처럼 세상에 수많은 빅데이터 처리 소프트웨어가 있기 때문에 그중 원하는 것만 골라서 위 구성에 맞게 사용만 하면 될 것 같지만 실제로 실무에서 사용되는 빅데이터 처리 플랫폼은 그리 간단하지만은 않습니다. 왜냐하면 대부분의 빅데이터 기술이 최근에 발표되어 현재까지 계속 안정화되어 가는 중이어서 실 제로 현업에서 활용하기 위해서는 커스터마이징해야 할 부분들이 많기 때문입니다. 또한 같은 기능 을 제공하는 솔루션도 여러 개씩 존재하는 경우가 많아 사실상의 표준이라 할 만한 것이 없어서 무 엇을 선택해야 하는지 고르기도 쉽지 않은 것이 사실입니다. 그렇다면 각 모듈별로 사용 가능한 솔 루션에는 어떤 것이 있는지 살펴보겠습니다. 데이터 수집 ■■ 플럼(Flume):

CDH라는 하둡 배포판 제작사로 유명한 클라우데라사에서 개발했으며, 현재는 아파치에서 Flume-NG라

는 이름으로 서비스되고 있습니다. 데이터를 수집하고자 하는 서버에 데이터 변경과 관련된 이벤트를 감지하는 Agent를 띄워두고 있다가 이벤트가 발생할 때마다 데이터를 수집하는 방식으로 동작합니다. Agent 내부는 소스(Source)와 채널 (Channel), 싱크(Sink)로 구성되며 소스로부터 데이터를 읽어 채널에 저장했다가 싱크에 최종적으로 반영합니다. 소스의 종류로는 파일시스템, HTTP, Avro, Kafka 등 데이터 유형별로 다양한 형태를 지정할 수 있고 메모리 또는 파일시스템 채 널을 사용하며, HBase나 HDFS, Spark 등을 싱크로 지정해서 사용할 수 있습니다. ■■ 카프카(Kafka):

아파치에서 서비스되며, 링크드인과 트위터 등에서 사용하는 것으로 알려져 있습니다. 최근에는 국내에서

도 인기가 높으며 플럼과 연동해서 사용하는 경우가 많아 “Flafka”2라고 불리기도 합니다. 기본적인 동작 개념은 퍼블리셔 (Publisher)와 컨슈머(Consumer) 형태이며, 여러 대의 서버에 브로커(Broker)라는 카프카 프로세스를 띄워두고 데이터 를 가지고 있는 프로듀서(Producer) 프로세스들이 데이터를 브로커에게 전달하면 컨슈머(Consumer) 프로세스들이 브로 커를 통해 데이터를 읽어가는 구조로 확장성이 높고 메모리 대신 파일시스템을 이용하면서도 빠르고 안정적인 서비스를 제 공합니다. ■■ 스쿱(SQOOP):

아파치에서 서비스되는 오픈소스 프로젝트로서 주로 기존 관계형 데이터베이스 시스템과 연동하는 목적으

로 많이 사용됩니다. 하둡이나 스파크 등에서 데이터를 분산 처리하기 위해 다수의 서버에 여러 개의 프로세스를 구동하게 되는데, 이러한 프로세스 하나하나를 데이터베이스의 클라이언트로 삼아서 전체 데이터를 나누어 각자 할당된 분량만큼 처 리하는 방식으로 동작합니다. 데이터 저장 및 처리 ■■ 하둡(Hadoop):

빅데이터 분야에서 가장 널리 알려진 아파치 오프소스 프로젝트이며 분산 파일 저장 시스템인 HDFS

와 HDFS 상에서 동작하는 분산 데이터 처리 프로그래밍 모델이자 프레임워크인 맵리듀스(MapReduce)를 제공합니다. HDFS는 여러 대의 서버에 데이터를 다중 복제해서 저장하는 방식으로 안정성을 보장하며, 최근에는 클러스터 자원 관리 시스템인 Yarn의 도입과 더불어 하나의 클러스터에 한 개 이상의 네임노드를 설정할 수 있는 네임노드 페더레이션 기능도 제공하는 등 더욱 안정적인 서비스가 가능해졌습니다.

2

책1.indb 7

https://goo.gl/avn3A9

2017-01-25 오전 11:45:36


8

빅데이터 분석을 위한 스파크 2 프로그래밍: 대용량 데이터 처리부터 머신러닝까지

■■ HBase:

하둡 에코시스템 중 하나이며, HDFS를 저장소로 사용하는 칼럼 기반 NoSQL DB입니다. 데이터는 논리적 관점에

서 로우키(row key)와 칼럼패밀리(column family), 칼럼 퀄리파이어(column Qualifier)의 중첩 맵 구조로 저장되며, 물리 적 관점에서는 칼럼 패밀리 단위로 생성되는 HFile이라는 파일에 저장됩니다. 테이블, 로우, 칼럼이라는 용어 때문에 일반적 인 관계형 데이터베이스와 유사한 방식으로 다룰 수 있을 것처럼 오해받기도 하지만 데이터를 저장하고 읽을 때 기존 데이 터베이스와는 전혀 다른 방식을 사용해야 합니다. 칼럼패밀리 단위로 파일을 분리해서 관리하기 때문에 빠른 조회 성능을 보여줄 수 있지만 제대로 사용하기 위해서는 HBase 내부 동작 방식에 대한 정확한 이해를 바탕으로 최적의 로우키와 칼럼 키를 설계할 수 있는 능력이 필요합니다. ■■ 카산드라(Cassandra):

페이스북에서 개발했으나 현재는 아파치 오픈소스 프로젝트로 제공되고 있습니다. HBase 같은 칼

럼 기반 NoSQL 데이터베이스로 분류되며, 데이터 리플리케이션과 커밋 로그 등을 활용해 높은 안정성과 성능을 보장합 니다. ■■ 레디스(Redis):

메모리를 이용한 키, 값 형태의 저장소입니다. 문자열 외의 다양한 바이너리 파일도 저장할 수 있고 집합 연

산 기능도 제공합니다. 또한 hash, set, list 등 다양한 자료구조를 지원하기 때문에 다양한 유형의 자료구조를 저장할 수 있 습니다. ■■ 피그(Pig):

피그라틴(Pig Latin)이라는 추상화된 스크립트 언어를 제공함으로써 맵리듀스 프로그램을 작성하지 않고도 맵리

듀스 잡을 이용한 데이터 분석을 수행할 수 있습니다. 작성된 스크립트를 내부적으로 맵리듀스 잡으로 변환하는 형태로 실행 되며 데이터 처리와 관련된 다양한 함수를 제공하고 있어 프로그램을 작성할 줄 모르는 사용자도 맵리듀스 잡을 실행할 수 있다는 장점이 있습니다. 피그 스크립트는 데이터 처리와 관련된 다양한 함수를 제공하고 처리 단계를 선언적으로 기술하는 방식이므로 맵리듀스를 작성할 때에 비해 더욱 자연스럽게 처리 흐름을 기술할 수 있다는 장점이 있습니다. 하지만 실무에서 커스터마이징이 많이 필요한 복잡한 연산을 수행할 때는 맵리듀스를 직접 작성하는 것이 더 편한 경우도 있습니다. ■■ 하이브(Hive):

피그와 같이 별도의 스크립트 언어를 제공함으로써 프로그램을 작성하지 않고도 맵리듀스 잡을 실행할

수 있습니다. 단 이 스크립트의 문법이 기존 관계형 데이터베이스에서 사용하던 SQL과 비슷해서 SQL에 익숙한 사용 자가 좀 더 손쉽게 데이터 분석을 수행할 수 있다는 장점이 있습니다. 테이블 형태의 논리적인 뷰도 제공하며, DW(data warehouse)를 구축하기 위한 용도로도 활용됩니다. 간편하게 사용할 수 있다는 장점이 있는 반면 테이블을 미리 준비해야 하고 피그와 마찬가지로 복잡도가 높은 작업을 처리할 때는 직접 맵리듀스 프로그램을 작성하는 편이 더 편리한 경우도 있 습니다.

피그 A = LOAD 'data1' AS (a1:int, a2:int, a3:int); B = LOAD 'data2' AS (b1:int, b2:int); X = JOIN A BY a1, B BY b1;

하이브 SELECT pv.*, u.gender, u.age FROM user u JOIN page_view pv ON (pv.userid = u.id) WHERE pv.date = '2008-03-03'

그림 1-1 피그와 하이브의 스크립트 언어 비교

■■ 스파크(Spark):

하둡과 유사한 클러스터 기반의 분산 처리 기능을 제공하는 오픈소스 프레임워크입니다. 처리 결과를 항상

파일시스템에 유지하는 하둡과 달리 메모리에 저장하고 관리할 수 있는 기능을 제공함으로써 머신러닝 등 반복적인 데이터 를 처리하는 데 뛰어난 성능을 보입니다. 하둡과 하이브를 비롯한 기존의 여러 솔루션과의 연동을 지원하고 마이크로배치 방식의 실시간 처리 및 머신러닝 라이브러리를 비롯해 빅데이터 처리와 관련된 다양한 라이브러리를 지원합니다.

책1.indb 8

2017-01-25 오전 11:45:37


01. 스파크 소개

9

데이터 분석 및 기타 소프트웨어 ■■ R:

데이터에 대한 수치 처리 및 그래픽 처리 기능을 제공합니다. 강력하고 다양한 통계 기능을 제공함으로써 다양한 데이터

분석에 활용되며, 최근에는 데이터 처리 성능의 증가와 더불어 스파크와도 일부 기능을 연동할 수 있게 되면서 응용 범위가 더 넓어졌습니다. ■■ 클라우데라(Cloudera),

호튼웍스(Hortonworks): 지금까지 살펴본 바와 같이 빅데이터를 다루기 위해서는 데이터 수집

부터 저장, 처리에 이르기까지 각 단계마다 적절한 소프트웨어들을 조합해서 사용해야 하는 경우가 많습니다. 하지만 하둡 을 비롯한 대부분의 제품은 오픈소스 형태로 운용되기 때문에 이들을 하나하나 직접 설치해서 사용하다 보면 서로 간의 라 이브러리 버전 충돌이나 환경 설정 문제가 발생할 수 있습니다. 따라서 전문 벤더에서 각종 배포판을 제작하게 됐고, 그중 에서 널리 알려지고 자주 사용되는 제품으로 클라우데라사에서 배포하는 CDH(Cloudera distribution Including Apache Hadoop)와 호튼웍스사에서 배포하는 HDP(Hortonworks data platorm)가 있습니다. 두 제품 모두 하둡을 기본으로 피그, 하이브, HBase 등 자주 활용되는 에코시스템을 포함하고 있다는 점에서는 비슷하지만 개발 및 인프라 운영상의 편의를 위 해 제공하는 각종 모니터링 및 관리 기능과 다양한 오픈소스 라이브러리를 통합하는 과정에서 발생하는 제품 커스터마이징 수준에서 각기 다른 특성을 보입니다. 단순히 어느 배포판이 더 좋다고 할 수는 없으며, 각 제품의 특성을 상세히 살펴보고 현재 업무 상황에 적합한 배포판을 선택해서 사용하는 것이 좋습니다.

1.1.4 스파크 최근에는 빅데이터라는 용어가 널리 알려지면서 개발자라면 누구나 한번쯤 들어봤음 직한 단어가 됐지만 빅데이터라는 용어가 이렇게 대중적으로 알려지게 된 데는 하둡의 탄생과 성공이 크게 기여 했다고 할 수 있습니다. 잘 알려진 것처럼 하둡은 구글이 대량의 데이터 처리와 관련해서 공개한 두 개의 논문을 더그 커팅 ( Doug Cutting)이 실제 제품으로 구현하면서 시작된 아파치 프로젝트를 가리키는 이름입니다. 이 후 하둡 프로젝트는 아파치 톱 레벨 프로젝트로 승격된 후 이듬해에 하둡 0.20.1 버전을 내놓으면 서 본격적인 활동을 시작하게 됩니다. 시기별로 보면 2003년에 구글이 지금의 HDFS( Hadoop file

system)의 기초가 된 ‘The Google File System’ 논문을 발표했고, 2004년에 맵리듀스 관련 논문 을 추가 공개했습니다. 그 뒤 2006년에 아파치 톱 레벨 프로젝트로 승격됐고 2009년에 0.20.1 버 전을 발표하게 됩니다. 하둡은 분산 환경의 병렬처리 프레임워크로서 크게 보면 분산 파일시스템인 HDFS ( Hadoop

distributed file system)와 데이터 처리를 위한 맵리듀스 프레임워크로 구성돼 있습니다. 또한 2.0 버전 이후부터는 CPU와 메모리 등 컴퓨팅 자원 관리를 전담하는 리소스 관리 시스템인 Yarn을 포 함해 기존 맵리듀스 프로그래밍 모델을 Yarn 기반으로 구축할 수 있도록 지원하고 있습니다.

책1.indb 9

2017-01-25 오전 11:45:37


10

빅데이터 분석을 위한 스파크 2 프로그래밍: 대용량 데이터 처리부터 머신러닝까지

하둡은 여러 대의 서버를 이용해 하나의 클러스터를 구성하며, 이렇게 클러스터로 묶인 서버의 자원 을 하나의 서버처럼 사용할 수 있는 클러스터 컴퓨팅 환경을 제공합니다. 기본적인 동작 방법은 분 석할 데이터를 하둡 파일시스템인 HDFS에 저장해 두고 HDFS 상에서 맵리듀스 프로그램을 이용 해 데이터 처리를 수행하는 방식입니다. 하둡 파일시스템은 하나의 네임노드와 여러 개의 데이터 노드로 구성되며, 하나의 네임노드가 나머 지 데이터 노드를 관리하는 형태로 동작합니다. ■■ 데이터를

저장할 때는 전체 데이터를 블록이라고 하는 일정한 크기로 나눠서 여러 데이터 노드에 분산해서 저장하는데, 이

때 각 블록들이 어느 데이터 노드에 저장돼 있는지에 대한 메타정보를 네임노드에 기록합니다. 그리고 맵리듀스 잡을 실행 할 때는 거꾸로 네임노드로부터 메타정보를 읽어서 처리할 데이터의 위치를 확인하고 분산처리를 수행합니다.

그림 1-2 하둡 파일시스템의 파일 저장 절차

맵리듀스 프레임워크는 하둡의 대표적인 데이터 처리 프레임워크로서 데이터를 여러 개의 맵 프로 세스와 리듀서 프로세스로 나눠서 처리하는 방식입니다. 맵 프로세스는 여러 데이터 노드에 분산 저 장된 데이터를 각 서버에서 병렬로 나누어 처리하며, 리듀서는 그러한 맵 프로세스들의 결과를 조합 해 최종 결과를 만들어 냅니다. 이때 데이터를 나누는 과정에서는 실제로 파일의 복사본이 각 서버로 나누어 전달되는 것은 아니고 네트워크를 통한 데이터 이동을 최소화하기 위해 데이터가 있는 서버에서 프로세스를 구동시킵니 다. 덕분에 데이터에 대한 지역성( locality)을 높이는 장점이 있습니다. 이러한 맵리듀스 잡의 제어는 네임노드에서 구동되는 잡 스케줄러와 태스크 스케줄러라는 프로세스 가 처리했습니다. 하지만 기본적으로 하나의 클러스터에서 한 개의 맵리듀스 잡만 구동할 수 있었기

책1.indb 10

2017-01-25 오전 11:45:37


01. 스파크 소개

11

때문에 CPU와 메모리 자원을 효율적으로 사용하지 못하는 문제가 있었습니다. 이 때문에 최근 배 포된 하둡 2.0부터는 데이터 처리 작업에 대한 스케줄링과 서버 자원 관리를 Yarn이라는 자원 관리 시스템에서 전담하면서 이러한 문제점이 개선됐습니다. 이처럼 하둡은 꾸준한 업데이트를 통해 빅데이터 처리의 핵심 프레임워크로 자리 잡았지만 앞에서 언급한 것처럼 하둡만으로 모든 데이터 처리를 수행하기에는 부족한 부분이 있었습니다. 먼저 하둡의 맵리듀스 잡은 대부분의 연산 작업을 파일시스템을 기반으로 처리했기 때문에3 스파크 같은 메모리 기반 데이터 처리 방식에 비해 상대적으로 높은 성능을 기대하기 어려운 면이 있었습 니다. 두 번째는 맵리듀스를 이용해 데이터를 처리하려면 대부분 자바 언어를 사용해 맵리듀스 프로그램 을 작성해야만 했습니다. 물론 맵과 리듀스 패턴이 막강해서 여러 복잡한 문제들을 이 방식으로 해 결할 수 있었다 하더라도 현업에서 만나는 다양한 데이터 분석 요구사항을 맵과 리듀서라는 하나의 패턴으로만 치환해서 처리하기는 쉬운 일이 아니었습니다. 또한 외부 라이브러리의 도움 없이 단위 테스트를 작성하거나 실제 데이터를 대상으로 간단한 시뮬 레이션을 해보기가 상대적으로 쉽지 않고, 무엇보다 자바 언어를 기반으로 프로그램을 작성하므로 파이썬이나 R 등 다른 분석용 도구를 연동해서 사용하려면 파일시스템과 같은 외부 스토리지를 중 간에 두고 결과 파일을 주고받아야만 하는 불편함이 있었습니다. 이에 반해 SQL on Hadoop으로 대표되는 하이브의 경우 개발자들에게 친숙한 SQL을 사용해 맵리 듀스 잡을 생성할 수 있다는 장점이 있었습니다. 하지만 이를 위해서는 미리 사용할 테이블과 데이 터를 설계해 준비해둬야 하고 복잡한 알고리즘을 구현할 때는 원하는 성능을 얻지 못하거나 구현 자 체가 맵리듀스 코드를 작성할 때보다 더 복잡해지는 경우가 있었습니다. 스파크는 하둡 기반의 맵리듀스 작업이 가진 이 같은 단점들을 보완하기 위한 것으로 2009년

UC Berkeley 대학의 연구로 시작되어 2012년에 미국 NSDI 학회에서 스파크의 핵심 개념인 RDD( resilient distributed dataset)에 대한 논문이 발표되면서 세상에 알려졌습니다. 스파크는 하둡과는 달리 메모리를 이용한 데이터 저장 방식을 제공함으로써 머신러닝 등 반복적인 데이터 처리가 필요한 분야에서 높은 성능을 보여줬습니다. 또한 작업을 실행하기 전에 최적의 처 리 흐름을 찾는 과정을 포함하고 있었기 때문에 성능 향상과 더불어 여러 개의 맵리듀스 잡을 직접

3

책1.indb 11

심지어 작업 수행 결과도 카운터와 파일을 통해서만 확인할 수 있습니다.

2017-01-25 오전 11:45:37


12

빅데이터 분석을 위한 스파크 2 프로그래밍: 대용량 데이터 처리부터 머신러닝까지

순차적으로 실행해야 하는 수고를 덜 수 있게 됐습니다. 특히 맵리듀스에 비해 훨씬 자연스럽고도 강력한 다수의 데이터 처리 함수를 제공함으로써 프로그램의 복잡도를 크게 낮춰준다는 점은 매우 큰 장점이라 할 수 있습니다. 게다가 스파크 2.0부터는 자바, 스칼라, 파이썬뿐만 아니라 R 스크립 트를 이용해서도 스파크 애플리케이션을 작성할 수 있게 되어 언어에 의한 장벽도 상당 부분 해소됐 습니다. 이 밖에도 실시간 스트리밍 데이터를 다루기 위한 “스파크 스트리밍”과 하이브와의 연동도 가능한 스키마 기반 데이터 분석 모듈인 “스파크 SQL”, 그래프 알고리즘 처리를 위한 “GraphX”, 통계 분 석 프로그램인 R과의 연동을 지원하는 “SparkR”, 머신러닝 알고리즘 수행을 위한 “MLlib” 등 각종 데이터 처리 분야에 특화된 라이브러리도 제공합니다. 이 책을 쓰고 있는 2016년 11월에는 스파크 1.x 버전에 비해 약 10배 정도 향상된 처리 속도를 보여 주는 스파크 2.0 버전이 출시됐고, 향후 더 다양한 소프트웨어와의 연동을 통해 더욱 강력한 기능을 제공할 것으로 기대되고 있습니다. 지금까지 하둡과 스파크에 대해 간단히 알아봤습니다. 한 가지 알아둬야 할 점은 스파크가 하둡의 많은 단점들을 보완해 준다고 해서 스파크가 하둡의 모든 영역을 대체할 것이라고 생각하면 안 된다 는 것입니다. 스파크는 하둡을 비롯한 기존 빅데이터 처리 도구의 부족한 부분들을 보완해 주는 것 이지 대체하기 위한 것은 아니라는 점을 염두에 두고 지금부터 좀 더 자세히 살펴보겠습니다.

1.1.5 RDD(Resilient Distributed Dataset) 소개와 연산 프로그램을 작성할 때 모델링( modeling)은 정말 중요합니다. 모델링의 의미는 적용되는 분야에 따 라 의미가 조금씩 달라질 수 있겠지만 프로그램 세계에서 모델링이란 현실 세계에 존재하는 사물이 나 개념을 프로그래밍 언어로 설명하는 과정이라 할 수 있습니다. 모델링의 대상은 사람이나 자동차 같이 눈에 보이는 사물부터 계약, 사회, 데이터 같은 무형의 추상 적인 개념까지 모두 아우릅니다. 또한 모델링을 할 때는 이런 대상의 모든 부분을 그대로 묘사하지 않고 프로그램에서 대상을 바라보는 특정 시각에 따라 특징적인 부분만 추려내서 표현합니다. 이런 과정을 거쳐서 최종적으로 대상에 대한 일종의 추상화된 모델이 생겨나는데, 이러한 모델이 만들어 짐으로써 비로소 우리가 프로그램 안에서 그러한 대상들을 식별하고 다룰 수 있게 됩니다. 스파크가 제공하는 RDD 역시 일종의 “분산 데이터”에 대한 모델이라고 할 수 있습니다. 스파크 홈 페이지( https://spark.apache.org)를 방문해 보면 아래와 같은 깔끔한 정의를 볼 수 있습니다. 다 소 어색하지만 우리말로 옮겨보자면 “RDD란 스파크가 사용하는 핵심 데이터 모델로서 다수의 서

책1.indb 12

2017-01-25 오전 11:45:38


01. 스파크 소개

13

버에 걸쳐 분산 방식으로 저장된 데이터 요소들의 집합을 의미하며, 병렬처리가 가능하고 장애가 발 생할 경우에도 스스로 복구될 수 있는 내성( tolerance)를 가지고 있다”라고 할 수 있습니다. “Spark revolves around the concept of a resilient distributed dataset (RDD), which is a faulttolerant collection of elements that can be operated on in parallel.”

즉 RDD란 스파크에서 정의한 분산 데이터 모델인데 내부에는 단위 데이터를 포함하고 있고 저장할 때는 여러 서버에 나누어 저장되며, 처리할 때는 각 서버에 저장된 데이터를 동시에 병렬로 처리할 수 있다는 의미입니다. 또한 데이터를 여러 서버에 나누어 저장하고, 처리하는 과정에서 일부 서버 혹은 데이터에 문제가 발생하더라도 스스로 에러를 복구할 수 있는 능력을 가지고 있는 데이터 모델 이라는 의미도 가지고 있습니다. 그럼 RDD가 분산 데이터 요소의 집합이라는 것을 소개했으니 이 부분에서부터 얘기를 시작하겠습 니다. 먼저 하나의 RDD에 속한 요소들은 파티션이라고 하는 더 작은 단위로 나눠질 수 있는데, 스 파크는 작업을 수행할 때 바로 이 파티션 단위로 나눠서 병렬로 처리를 수행합니다. 이렇게 만들어 진 파티션은 작업이 진행되는 과정에서 재구성되거나 네트워크를 통해 다른 서버로 이동하는, 이른 바 셔플링이 발생할 수 있습니다. 이런 셔플링은 전체 작업 성능에 큰 영향을 주기 때문에 주의해서 다뤄야 하며, 스파크에서는 셔플링이 발생할 수 있는 주요 연산마다 파티션의 개수를 직접 지정할 수 있는 옵션을 제공합니다.4 하나의 RDD가 이렇게 여러 파티션으로 나눠져 다수의 서버에서 처리되다 보니 작업 도중 일부 파 티션에 장애가 발생해서 데이터가 유실될 수 있는데, 스파크는 손상된 RDD를 원래 상태로 다시 복 원하기 위해 RDD의 생성 과정을 기록해 뒀다가 다시 복구해 주는 기능을 가지고 있습니다. RDD의 첫 글자인 resilient5라는 단어가 바로 이런 복구 능력을 의미하는데, 좀 더 정확하게 말하면 RDD 에 포함된 데이터를 저장해 두는 것이 아니고 RDD를 생성하는 데 사용했던 작업 내용을 기억하고 있는 것입니다. 그래서 문제가 발생하면 전체 작업을 처음부터 다시 실행하는 대신 문제가 발생한

RDD를 생성했던 작업만 다시 수행해서 복구를 수행합니다. 단 이렇게 복구를 수행하기 위해서는 한번 생성된 RDD가 바뀌지 않아야 한다는 조건이 필요합니 다. 만약 RDD가 생성된 이후에 변경이 가능하다면 단순히 RDD가 생성되는 데 관여한 작업뿐만 아니라 RDD를 변경시킨 모든 작업에 대한 기록을 다 저장하고 있어야 하기 때문입니다.

4

파  티션의 수는 곧 데이터 처리에 참여하는 병렬 프로세스의 수입니다. 즉, 하나의 데이터를 잘게 쪼개어 여러 개의 파티션을 만들면 여러 프로세스에서 동시에 작업을 처리 해서 처리 속도가 증가할 수 있지만 이 정도가 지나치면 오히려 전체 성능을 떨어뜨리는 요인이 됩니다.

5

책1.indb 13

(충격, 부상 등에 대해) 회복력 있는

2017-01-25 오전 11:45:38


14

빅데이터 분석을 위한 스파크 2 프로그래밍: 대용량 데이터 처리부터 머신러닝까지

아직 RDD에 대해 본격적으로 살펴보지 않았기 때문에 방금 설명한 내용이 잘 이해되지 않을 수도 있습니 다. 따라서 아직 RDD를 다루기 전이지만 RDD의 복원 시나리오를 이해하기 위해 RDD의 특성 몇 가지를 먼 저 설명드리겠습니다. 1) RDD는 스파크의 (추상적인) 데이터 모델이면서 동시에 프로그래밍 API입니다. 2) R  DD는 map, flatMap과 같은 메서드를 이용해 내부에 포함된 모든 데이터에 특정 연산을 적용할 수 있습니다. 예를 들어, 숫자 데이터만 가지고 있는 RDD가 있다면 map이라는 메서드를 이용해 모든 데 이터 요소에 10을 곱하거나 1을 더하는 등의 변경을 할 수 있습니다. 3) 이렇게 변경하게 되면 RDD의 요소로 지정돼 있던 데이터의 값이 바뀌는데, 이때 원래 있던 기존 RDD의 데이터가 바뀌는 것이 아니고 변경된 숫자로 구성된 새로운 RDD를 생성하게 됩니다. 4) 즉  , 덧셈이나 곱셈 같은 특정 연산을 수행하면 기존 RDD와 새로운 RDD, 이렇게 2개의 RDD가 만들 어집니다. 5) R  DD는 이와 같은 방식으로 어떤 종류의 연산이든 내부 데이터를 변경하게 되면 기존 RDD 정보는 그 대로 두고 계속해서 새로운 RDD를 만들어 냅니다. 6) 스  파크는 이렇게 만들어진 모든 RDD에 대해 기존의 어떤 RDD에 어떤 종류의 연산을 적용해서 만들 어진 것인지에 대한 정보를 기억하고 있습니다. 7) 이  제 RDD 중 일부가 장애로 인해 유실되는 문제가 발생하면 스파크는 해당 RDD가 어떤 단계를 거쳐 서 만들어진 것인지 기록해둔 정보를 끄집어내 필요한 절차를 반복 수행함으로써 유실됐던 RDD를 다 시 만들어 냅니다. 8) 이처럼 RDD는 한번 생성되면 새로운 RDD를 만들어 낼 수는 있어도 자신은 절대 변하지 않기 때문에 언제 어느 시점에 장애가 발생하더라도 동일한 방법으로 만든 RDD는 항상 동일한 데이터를 가지고 있음을 보장받을 수 있습니다.

정리하면, 스파크는 RDD가 생성되어 변경되는 모든 과정을 일일이 기억하는 대신 RDD를 한번 생 성되면 변경되지 않는 읽기 전용 모델로 만든 후 RDD 생성과 관련된 내용만 기억하고 있다가 장애 가 발생하면 이전에 RDD를 만들 때 수행했던 작업을 똑같이 실행해(똑같은 데이터를 가진 새로운

RDD를 만들어) 데이터를 복구하는 방식을 사용하는 것입니다. 이처럼 스파크에서 RDD 생성 작업을 기록해 두는 것을 리니지( lineage)라고 합니다. 결국 지금까 지 얘기한 내용을 종합해 보면 유명한 온라인 게임 이름이기도 한 ‘리니지’와 ‘읽기 전용’이라는 두 단 어가 키워드라고도 할 수 있을 것입니다. 사실 게임에 대해서는 잘 모르는데 문득 궁금한 생각이 드 네요.

RDD의 이런 읽기 전용 특성은 흔히 프로그래밍 모델이라고도 하는 프로그래밍 방식에도 영향을 주 어 일단 데이터를 RDD로 만든 후 데이터 변형이 필요하면 그 RDD로부터 변형된 새로운 RDD를 만들고 그것으로부터 또 다른 RDD를 생성해서 최종적인 모습의 RDD를 만들어 가는 형태로 데이

책1.indb 14

2017-01-25 오전 11:45:38


01. 스파크 소개

15

터를 처리합니다. 이때 기존 RDD는 변형되지 않고 매번 새로운 RDD가 재생성되기 때문에 장애가 발생하면 문제가 발생했던 구간의 작업만 수행해서 RDD를 재빨리 복원할 수 있는 것입니다.

그림 1-3 RDD 기반 데이터 처리

RDD는 크게 세 가지 방법으로 생성할 수 있습니다. 첫 번째 방법은 List나 Set 같은 기존 프로그램 의 메모리에 생성된 데이터를 이용하는 것으로 특별한 데이터 소스를 준비할 필요 없이 RDD의 기 능을 즉시 테스트해 볼 수 있어 테스트 코드 작성 등에 유용하게 사용할 수 있습니다. 두 번째 방법은 로컬 파일시스템이나 하둡의 HDFS 같은 외부 저장소에 저장된 데이터를 읽어서 생 성하는 방법인데, 스파크는 다양한 유형의 데이터 소스로부터 데이터를 읽고 RDD를 생성할 수 있 는 유용한 함수를 제공합니다. 마지막 세 번째는 기존에 생성돼 있는 RDD로부터 또 다른 RDD를 생성하는 방법인데, 실제로

RDD로부터 새로운 RDD를 만들어주는 “createRDD”와 같은 함수가 제공되는 것은 아니고 기존 RDD의 모든 요소에 1을 더하는 등의 연산을 적용하면 “한번 만들어지면 수정되지 않는다”는 RDD 의 특성으로 인해 새로운 RDD가 만들어지는 것을 의미합니다. 다음은 방금 말한 세 가지 RDD 생성 방법에 따라 RDD를 생성하는 코드의 일부입니다. 1. Collection 이용 [자바] JavaRDD<String> rdd = sc.parallelize(Arrays.asList("a", "b", "c", "d", "e")); [스칼라] val rdd = sc.parallelize(List("a", "b", "c", "d", "e")) [파이썬] rdd = sc.parallelize(["a", "b", "c", "d", "e"]) 2. 파일로부터 생성 [자바] JavaRDD<String> rdd = sc.textFile("<path_to_file>");

책1.indb 15

2017-01-25 오전 11:45:39


16

빅데이터 분석을 위한 스파크 2 프로그래밍: 대용량 데이터 처리부터 머신러닝까지

[스칼라] val rdd = sc.textFile("<path_to_file>") [파이썬] rdd = sc.textFile("<path_to_file>")

이 책의 모든 예제에서 <path>또는 <path_to_file>은 파일이 위치한 경로를 의미합니다. 스파크는 하둡에서 사용 가능한 모든 파일시스템을 지원하기 때문에 로컬 파일시스템부터 HDFS6, S3, FTP 등 다양한 파일시 스템 경로를 사용할 수 있습니다. 예를 들어, 로컬 파일시스템의 경우 “file:///~”와 같이 입력하고 hdfs의 경우 “hdfs://~”로 시작하는 경로 를 입력하면 됩니다. 단, HADOOP_HOME 시스템 환경변수가 등록돼 있을 경우 파일시스템에 대한 스킴 (scheme) 정보 없이 “/path1/path2”와 같이 시작하는 경로만 지정할 경우 hdfs 시스템 경로로 인식되므로 유의해야 합니다.

3. 기존 RDD로부터 새로운 RDD 생성 [자바 7] JavaRDD<String> rdd1 = rdd.map(new Function<String, String>() { @Override public String call(String v1) throws Exception { return v1.toUpperCase(); } }); [자바 8] JavaRDD<String> rdd1 = rdd.map(v -> v.toUpperCase()); [스칼라] val rdd1 = rdd.map(_.toUpperCase()) [파이썬] rdd1 = rdd.map(lambda s: s.upper())

아직 스파크 프로그래밍 모델을 살펴보기 전이기 때문에 다소 생소한 내용이 있을 수 있지만 RDD 를 생성하는 데 위와 같은 다양한 방법이 있다는 것을 기억하면 됩니다.

6

HDFS는 하둡의 파일시스템을 의미합니다. 하둡을 모른다고 해서 스파크를 사용할 수 없는 것은 아니지만 스파크가 제공하는 API는 하둡의 API를 기반으로 작성된 것들이 많으므로 하둡에 대해 기본적인 사항을 이해해둘 필요가 있습니다.

책1.indb 16

2017-01-25 오전 11:45:39


01. 스파크 소개

17

RDD를 생성하고 나면 RDD가 제공하는 다양한 연산을 이용해 데이터를 처리하면 되는데, 이때 RDD에서 제공하는 연산은 크게 “트랜스포메이션( Transformation)”과 액션( Action)”이라는 두 종류로 나눌 수 있습니다.7 엄밀한 의미에서 메서드(method), 함수(function), 연산(operation)은 뉘앙스가 서로 다르므로 구분해서 사 용하는 것이 맞습니다. 하지만 이 책에서는 연산과 메서드, 함수 등을 엄격하게 구분해서 사용하지 않고 상 황에 따라 섞어서 사용합니다. 예를 들어, RDD의 map() 메서드는 문맥에 따라 map 연산 또는 map 메서드 라고 표현될 수 있습니다. 주로 동작 자체의 의미에 중점을 두고 설명하고자 할 때는 “연산”이라는 용어를, 프로그래밍 API로서 설명할 때는 “메서드”라는 용어를 사용합니다.

이 가운데 트랜스포메이션 연산이란 어떤 RDD에 변형을 가해 새로운 RDD를 생성하는 연산으로, 기존 RDD는 바뀌지 않은 채 변형된 값을 가진 새로운 RDD가 생성됩니다. 예를 들어, 위 예제에서

rdd로부터 rdd1을 생성할 때 사용한 map 연산은 rdd에 있는 요소 각각에 소문자를 대문자로 바꾸 는 함수를 적용해 그 결괏값으로 구성된 새로운 RDD를 만들어냅니다. 한편 스파크는 이러한 rdd와 rdd1의 생성 과정을 따로 기록해뒀다가 메모리를 이용한 데이터 처리 과정에서 일부 데이터 유실이 발생하면 앞서 기록해둔 생성 과정을 다시 수행해서 데이터를 복구합 니다. 이러한 변환 연산이 가진 또 다른 중요한 특징은 연산이 호출되는 시점에 바로 실행되는 것이 아니 고 RDD에 대한 생성 계보만 만들면서 쌓여있다가 “액션”에 해당하는 연산이 호출될 때에 비로소 한꺼번에 실행된다는 것입니다. 변환 연산이 가진 이러한 지연( Lazy) 실행 방식의 장점은 본격적 인 작업 실행에 들어가기 전에 데이터가 어떤 방법과 절차에 따라 변형돼야 하는지 알 수 있다는 점 입니다. 따라서 최종 실행이 필요한 시점에 누적된 변환 연산을 분석하고 그중에서 가장 최적의 방 법을 찾아 변환 연산을 실행할 수 있습니다. 예를 들어, 어떤 온라인 쇼핑몰에서 발생한 1TB 규모의 구매 정보 로그가 총 10대의 서버에 무작위로 흩어져 저장돼 있고 이 로그 파일을 분석해서 각 상품 별 총 판매건수를 구한다고 할 때 다음과 같은 두 가지 방법을 생각해 볼 수 있을 것입니다. (방법 1) 1. 10대 서버에 저장된 모든 로그를 상품에 따라 재분류한다. 2. 분류된 각 그룹별로 총 판매건수를 계산한다.

7

어  떤 연산이 액션과 변환 연산 중 어떤 종류에 속하는지 알아두는 것은 필요하지만 실제 데이터를 처리하는 과정에서는 그때그때 필요한 연산을 자연스럽게 선택해서 사용 하면 되므로 처음부터 억지로 구분해서 암기하려고 할 필요는 없습니다.

책1.indb 17

2017-01-25 오전 11:45:40


18

빅데이터 분석을 위한 스파크 2 프로그래밍: 대용량 데이터 처리부터 머신러닝까지

(방법 2) 1. 전체 로그를 분류하기 전에 각 서버마다 상품별 총 판매건수를 계산한다. 2. 각 서버별로 계산된 상품별 판매건수를 모두 더한다.

“방법 1”의 경우 10대의 서버에 저장된 모든 로그 파일을 상품번호별로 재분류하는 것으로 작업을 시작합니다. 그런데 이때 동일한 상품번호를 가진 로그 파일들이 10대의 서버에 무작위로 흩어져 있기 때문에 같은 상품번호에 해당하는 로그가 분류 로직에 따라 한 서버에서 다른 서버로 네크워크 를 통해 이동하는 현상, 즉 “셔플( shuffle)”이 대량으로 일어납니다. 이에 반해 “방법 2”의 경우 셔플을 수행하기 전에 각 서버에서 먼저 상품별 부분 집계를 수행한 후 집계된 결과 파일만을 대상으로 네트워크를 통한 2차 합계 연산을 수행하기 때문에 “방법 1”에 비해 훨씬 적은 양의 데이터를 대상으로 셔플을 수행할 수 있습니다. 따라서 전체 처리 성능 면에서 볼 때 고비용 연산(네트워크를 통한 데이터 이동)을 더 효율적으로 수행한 “방법 2”가 더 우세합니다. 스 파크는 위 예제의 방법 2처럼 최종 결과를 계산하는 데 필요한 변환 연산을 전체적으로 분석하고 효 율적인 실행 방법을 찾기 위해 “액션” 연산이 필요할 때까지 변환을 수행하지 않습니다. 이때 액션 연산이란 그 연산의 결과로 RDD가 아닌 다른 값을 반환하거나 아예 반환하지 않는 연산 을 의미합니다. 예를 들면, RDD의 크기를 계산해서 Long 값을 반환한다거나 RDD를 화면에 출력 또는 외부 저장소에 저장하는 등의 동작이 이에 해당한다고 할 수 있습니다. RDD는 스파크에서 사용하는 데이터 모델이면서 동시에 스파크가 제공하는 실제 클래스의 이름이기도 합 니다. 앞에서 RDD의 연산 종류를 “변환” 연산과 “액션” 연산으로 나눈다고 했지만 실제로 스파크 RDD API 문서에 그런 구분이 따로 표시돼 있는 것은 아닙니다. 이 때문에 RDD 클래스가 제공하는 메서드 가운데 어떤 것이 변환에 속하는 메서드고 어떤 것인 액션에 속 하는 메서드인지 알아보려면 API 문서에서 메서드의 반환 타입을 확인해 보면 됩니다. 이때 연산의 수행 결 과가 RDD이면 변환 메서드고 RDD가 아닌 다른 타입의 값을 반환하면 액션에 해당하는 연산이라고 할 수 있습니다.

지금까지 RDD가 제공하는 메서드를 크게 액션과 트랜스포메이션 유형으로 구분할 수 있다는 것을 알아봤습니다. 그런데 RDD가 제공하는 이런 메서드 중에는 RDD를 구성하는 요소가 특정 타입일 때만 사용 가능한 것들이 있습니다. 예를 들어, RDD 에 포함된 모든 요소의 합계를 구하는 sum () 메서드나 표준편차를 구하는

stddev() 같은 메서드는 RDD를 구성하는 요소들이 모두 숫자 타입일 경우에만 사용할 수 있습니

책1.indb 18

2017-01-25 오전 11:45:40


01. 스파크 소개

19

다. 또한 RDD의 요소 중에서 같은 키( key)를 가진 것들끼리 모아주는 groupByKey()라는 메서드 는 키( Key)와 값( value) 쌍으로 구성된 RDD에만 사용할 수 있습니다. 이처럼 요소의 타입에 따라 서로 다른 다양한 메서드를 제공하는 것이 처음 시작하는 입장에서는 통 일성이 없고 복잡하게 느껴질 수도 있습니다. 하지만 데이터 유형에 상관없이 정해진 몇 가지 방법 만을 조합해서 모든 문제를 해결하는 것은 초기 학습은 빠를지 몰라도 현실에서 마주치는 다양하고 복잡한 문제를 해결하는 데는 오히려 더 많은 고민과 노하우가 필요해지는 경우가 많습니다. 따라서

RDD가 제공하는 메서드들을 한번에 다 습득하기는 만만치 않지만 수시로 API를 참고해서 스파크 가 제공하는 리치( Rich) API의 장점을 십분 활용하기 바랍니다.

1.1.6 DAG 독자분들 중에는 우지( oozie, http://oozie.apache.org)라는 이름을 들어봤거나 사용해본 분들이 있을 것입니다. 우지는 워크플로우 시스템의 하나로 여러 개의 하둡 맵리듀스 잡과 피그, 하이브 잡 을 스케줄링하고 연동할 수 있게 지원하는 도구입니다. 작업 스케줄 관리와 관련된 라이브러리라면 이미 널리 알려진 많은 제품들이 있지만 굳이 또 다른 도구를 사용하는 이유는 빅데이터 처리 과정 의 특성 때문이라고 할 수 있습니다. 데이터 처리를 하다 보면 한 번의 맵리듀스 작업으로 처리하면 데이터 처리 방법이 너무 복잡해지거 나 처리 대상 데이터의 크기가 너무 커져서 서버의 가용량을 넘어서는 경우가 생길 수 있습니다. 특 히 데이터를 처리하는 데 소요되는 시간도 데이터를 처리하는 방법에 따라 크게 차이가 나기 때문에 한 번의 작업으로 모든 것을 끝내기보다는 하나의 작업을 여러 개의 작은 작업으로 나눠 놓고 각 작 업을 최적화해서 일련의 순서대로 나누어 실행해야 하는 경우가 종종 있을 수 있습니다. 그런데 이때 각 단계마다 최적화된 작업을 수행하기 위해 사용해야 하는 데이터 처리용 라이브러리 가 다를 수 있기 때문에 서로 다른 라이브러리를 잘 조합해서 사용할 수 있는 라이브러리가 필요해 졌습니다. 우지는 이 같은 목적으로 사용하는 오픈소스 워크플로우 시스템 중 하나로 일련의 작업 흐름을 XML을 사용해 명시적으로 선언해 쓸 수 있습니다. 이때 일련의 작업 흐름을 나타내는 워크 플로우는 일종의 DAG( directed acyclic graph)를 구성하며, 이를 이용해 일련의 작업을 수행하면 서 HCatalog와 같은 라이브러리를 활용해 맵리듀스와 피그, 하이브 등 다양한 라이브러리를 상호 연동해서 사용하면서 데이터 처리를 수행합니다.

DAG란 그래프 이론에서 사용되는 용어로, 여러 개의 꼭짓점( vertex) 또는 노드( node)와 그 사이 를 이어주는 방향성을 지닌 선( directed edges)으로 구성되고, 그래프를 구성하는 어느 꼭짓점이

책1.indb 19

2017-01-25 오전 11:45:40


20

빅데이터 분석을 위한 스파크 2 프로그래밍: 대용량 데이터 처리부터 머신러닝까지

나 노드에서 출발하더라도 다시 원래의 꼭짓점으로 돌아오지 않도록 구성된 그래프 모델을 말합니 다. 빅데이터에서 DAG는 복잡한 일련의 작업 흐름을 나타내는 용도로 많이 사용되는데, 방금 설명 한 우지도 그중 한 예라고 할 수 있습니다.

시작

단어 수 세기 맵리듀스 작업

중지

종료

그림 1-4 우지(Oozie) 워크플로우

위 그림은 유명한 단어 수 세기 예제에 대한 처리 흐름을 DAG로 표현해 본 것으로서 같은 내용을 우지가 지원하는 XML 형식으로 표현하면 다음과 같습니다.8 <workflow-app name='wordcount-wf' xmlns="uri:oozie:workflow:0.1"> <start to='wordcount'/> <action name='wordcount'> <map-reduce> <job-tracker>${jobTracker}</job-tracker> <name-node>${nameNode}</name-node> <configuration> <property> <name>mapred.mapper.class</name> <value>org.myorg.WordCount.Map</value> </property> <property> <name>mapred.reducer.class</name> <value>org.myorg.WordCount.Reduce</value> </property> <property> <name>mapred.input.dir</name> <value>${inputDir}</value>

8 출처: http://oozie.apache.org/docs/4.3.0/DG_Overview.html

책1.indb 20

2017-01-25 오전 11:45:40


01. 스파크 소개

21

</property> <property> <name>mapred.output.dir</name> <value>${outputDir}</value> </property> </configuration> </map-reduce> <ok to='end'/> <error to='end'/> </action> <kill name='kill'> <message>Something went wrong: ${wf:errorCode('wordcount')}</message> </kill/> <end name='end'/> </workflow-app>

XML 내용을 보면 매퍼와 리듀서를 지정하는 부분과 HDFS의 입력과 출력 경로를 지정하는 부분이 있고, 작업이 성공 또는 실패했을 경우 어떻게 처리할지 나타내는 처리 흐름 등이 XML을 통해 선언 돼 있음을 알 수 있습니다. 만약 지금 막 우지에 대한 설명을 처음 들으신 분들이라면 “음 그래. 뭔지 대충 알겠어. 그럼 XML을 생성해 주는 툴을 사용해서 작성하면 되겠네”라고 생각하실지 모르겠지만 데이터 처리 시나리오를 작성하는 일은 생각보다 쉬운 일은 아닙니다. 같은 결과를 만들어내는 작업이라고 해도 처리 방법에 따라 성능상 큰 차이를 보이기 때문에 각 단계별 처리 과정을 명확하게 이해하고 적절하게 작업 단 계를 나누고 입력 데이터와 출력 데이터의 형식도 신중하게 고려해야 하기 때문입니다. 스파크는 트랜스포메이션과 액션의 조합으로 데이터 흐름을 손쉽게 표현할 수 있기 때문에 이로 인 한 고민을 효과적으로 줄일 수 있습니다. 또한 RDD 변환 연산을 이용해 필요한 코드를 작성해 두면 스파크가 실행하는 시점에 최적의 실행 경로를 판단해서 처리해 주기 때문에 편의성과 효율성 면에 서 훨씬 유리하다고 할 수 있습니다. 스파크에서 DAG 생성을 담당하는 부분을 DAG스케줄러라고 하는데, 이것의 전반적인 동작 방식 을 이해하기 위해 스파크의 작업 실행이 어떻게 수행되는지를 전체적으로 살펴보겠습니다. 먼저 스파크는 전체 작업을 스테이지( stage)라는 단위로 나누어 실행하고 각 스테이지를 다시 여 러 개의 태스크( task)로 나누어 실행합니다. 이때 스파크에서 잡을 구동하는 프로그램을 드라이버 ( Driver) 프로그램이라고 하는데, 특별히 어떤 인터페이스를 구현해야 하는 것은 아니고 main 함 수를 가진 POJO 형태로 작성하면 됩니다.

책1.indb 21

2017-01-25 오전 11:45:40


22

빅데이터 분석을 위한 스파크 2 프로그래밍: 대용량 데이터 처리부터 머신러닝까지

드라이버의 메인 함수에서는 스파크 애플리케이션과 스파크 클러스터의 연동을 담당하는 스파크컨 텍스트( SparkContext)라는 객체를 만들고 이를 이용해 잡을 실행하고 종료하는 역할을 수행합니 다. 드라이버가 스파크컨텍스트를 통해 RDD의 연산 정보를 DAG스케줄러에게 전달하면 스케줄러 는 이 정보를 가지고 실행 계획을 수립한 후 이를 클러스터매니저에게 전달합니다. 이때 스케줄러가 생성하는 정보는 주로 데이터에 대한 지역성을 높이는 전략과 관련된 것입니다. 특히 전체 데이터 처리 흐름을 분석해서 네트워크를 통한 데이터 이동이 최소화되도록 스테이지를 구성하는 것을 주 로 수행합니다. 예를 들어, 스파크가 제공하는 연산 중에는 앞에서 언급한 셔플이 반드시 필요한 것들도 있고 그렇 지 않은 연산도 있습니다. 따라서 각각을 서로 다른 스테이지로 나누고 셔플이 필요 없는 작업을 최 대한 모아서 먼저 수행한 뒤 셔플을 수행하는 방법을 사용할 수 있습니다. 이 경우 대상 데이터의 크 기를 줄여 셔플로 인한 부하를 최소화하는 것이 바로 스케줄링의 역할이라고 할 수 있습니다.

RDD 논문에서는 이를 좁은 의존성( narrow dependency)과 넓은 의존성( wide dependency)이 라는 용어로 설명하고 있습니다. 우선 하나의 RDD가 새로운 RDD로 변환될 때 기존 RDD를 부모

RDD, 새로운 RDD를 자식RDD라고 하겠습니다. 이때 부모RDD를 구성하는 파티션이 여러 개의 자식RDD 파티션과 관계를 맺고 있으면 넓은 의존성을 갖고 있다고 말하고, 그 반대의 경우는 좁은 의존성을 갖고 있다고 표현할 수 있습니다.

그림 1-5 좁은 의존성과 넓은 의존성

책1.indb 22

2017-01-25 오전 11:45:41


빅데이터 분석을 위한 스파크 2 프로그래밍 : 대용량 데이터 처리부터 머신러닝까지  

백성민 지음 | 데이터베이스 & 빅데이터 시리즈_015 | ISBN: 9791158390549 | 35,000원 | 2017년 02월 9일 발행 | 576쪽 | #RDD #Spark #대용량 데이터 처리 #머신러닝 #스파크 #실시간 스트리밍

Read more
Read more
Similar to
Popular now
Just for you