chapter_3 하둡과 데이터 과학

살짝가식 2021. 11. 20. 17:27

chapter_3

3. 하둡과 데이터 과학¶

이 장에서 다룰 내용

하둡이란 무엇인가
하둡의 진화 과정
데이터 과학을 위한 하둡 도구
데이터 과학을 위한 피그와 하이브
데이터 과학을 위한 스파크
데이터 과학자들은 왜 하둡을 애용하는지

다른 분야와 마찬가지로 데이터 과학에도 적절한 도구가 필요하다. 오늘날 하둡은 데이터 과학자들이 자유롭게 활용할 수 있는 강력한 도구로 자리매김했다. 이 장에서는 하둡의 정의, 하둡의 역사와 진화, 하둡 생태계에 추가된 새로운 도구, 하둡이 데이터 과학자에게 중요한 이류를 설명한다.

3.1 하둡이란 무엇인가?¶

아파치 하둡은 대규모 검색 색인을 구축하려고 자바로 개발된 오픈 소스 분산 컴퓨팅 플랫폼이다. 하둡의 원래 개발 목적은 검색 색인에 있었지만, 사람들은 곧 하둡의 핵심 개념을 다른 일반적인 문제에도 폭넓게 적용할 수 잇다는 것을 깨달았다. 그 후로 하둡은 여러 해 동안 다방면에 활용되고 개선되면서 대규모 원시 데이터를 처리하고 분석하는 데이터 센터 운영 시스템의 핵심 소프트웨어 생태계를 이뤘다.
초창기부터 강조된 하둡의 핵심 기능은 장애 허용이다. 하둡은 확장성을 높이려고 하드 디스크 손상 같은 장비나 노드의 장애를 당연히 발생할 수 있는 일로 간주하면, 기반 소프트웨어 시스템이 실패한 작업을 책임지고 재시도하게 설계되었다. 이와 같은 소프트웨어 복원성은 몇몇 경제적 이점을 주었다. 특히 하드웨어 레이거가 아닌 소프트웨어 레이어에서 복원 기능을 제공하므로, 다소 불안정하지만 저렴한 하드웨어로도 매우 안정적인 시스템을 구성할 수 있다. 또한, 하드웨어의 수리 작업을 발생 즉시 처리할 필요 없이 대기열에 누적한 후 일괄적으로 처리할 수 있어서 노드당 필요한 시스템 운영 인력을 감축할 수 있다.
하둡의 핵심 기술은 2005년에 처음으로 커밋된 이후 크게 확장됐지만, 그 기초를 이루는 구성 요소는 몇개 되지 않는다.

분산 파일 시스템
리소스 관리자와 스케줄러
분산 데이터 처리 프레임워크

3.1.1 분산 파일 시스템¶

하둡의 스토리지로 선택할 수 있는 분산 파일 시스템은 여러 가지지만, 하둡의 핵심 파일 시스템으로 처음 개발된 HDFS가 여전히 널리 사용된다. 구글의 GFS를 기반으로 설계된 HDFS는 데이터의 중복 저장이란 개념을 바탕으로 한 대규모 분산 파일 시스템이다. HDFS는 일반적인 파일 시스템을 가진 여러 노드를 묶어 하나의 분산 파일 시스템을 구축하도록 설계되었다. 이러한 설계 덕분에 파일 시스템을 손쉽게 확장해 몇 페타바이트에 이르는 대용량 데이터까지 저장할 수 있다. HDFS의 설꼐에는 몇 가지 가정이 반영되었다. 첫째, 데이터의 풀스캐닝을 지원하기 위해 파일 순차 읽기 속도가 빨라야 한다. 둘째, 데이터가 계산이 수행되는 곳으로 옮겨지는 게 아니라, 데이터가 저장된 곳에서 계산이 수행될 수 있게 파일 시스템의 노드들이 각자 자신이 저장한 데이터의 위치 정보를 충분히 교환해야 한다. 셋째, 노드의 장애를 소프트웨어 레이어에서 극복해야 한다.
데이터는 HDFS 내부에 블록 형태로 저장되며, 블록은 HDFS에 의해 투명하게 복제돼 여러 노드에 분산된다. HDFS의 리플리케이션 메커니즘은 데이터를 단순히 여러 노드에 저장하는 방식이 아닌, 데이터가 여러 랙에 분산 저장되도록 보장하는 다양한 전략을 사용한다. 이러한 리플리케이션 전략은 단일 노드나 단일 랙의 장애가 데이터의 유실로 이어지는 사태를 방지한다.

Note : 위치 투명서¶

컴퓨터 네트워크에서 말하는 위치 투명성이란 파일의 물리적인 섹터가 여러 장소(디스크 또는 네트워크)에 나눠 저장돼도 파일 이름만으로 파일에 접근할 수 있는 특징을 말한다. 다른 컴퓨팅 분야에서도 투명성은 물리적인 상황을 논리적인 개념으로 추상화한 것을 의미한다.

데이터 블록이 저장된 위치를 파악하고 계산 작업이 실행될 최적의 장소를 전체시스템이 결정할수 있어서 작업이 데이터와 가까운 위치에서 실행될 확률이 높다. 이러한 최적화 덕분에 연산을 수행할 노드로 데이터를 전송하는 데 걸리는 시간을 크게 단축시킬 수 있다. 그 결과 HDFS는 리플리케이션된 블록과 데이터 지역성을 바탕으로 대규모 계산에 이상적인 요소인 높은 안정성과 종합 대역폭을 달성했다. 그림 3-1은 HDFS의 아키텍처를 개략적으로 보여준다.
하둡 시스템의 일반적인 구성과 여러 액터가 HDFS 시스템과 어떻게 데이터와 정보를 주고받는지 한눈에 볼 수 있다. 분산 시스템의 데이터를 읽거나 저장하려는 클라이언트(또는 개별 프로그램)는 필요한 HDFS 일부분과 직접 통신한다. 더 정확히 설명하면 단순히 파일 목록이 필요한 클라이언트는 네임노드에 직접 접속해 메타데이터를 요청한다. 반면, 데이터를 읽거나 저장하려는 클라이언트는 네임노드에 필요한 블록(HDFS 데이터의 하위 구성단위)의 위치를 요청한 후 이 블록들을 저장하는 서버들과 직접 통신한다. 이러한 HDFS의 아키텍처는 병목 현상(예를 들면 모든 데이터가 네임노드를 거쳐가는 현상)의 가능성을 최대한 억제하면서 시스템 일부를 필요한 만큼만 사용할 수 있다는 장점이 있다. 거의 모든 하둡 베포판에서 보조 네임노드를 사용한다. 보조 네임노드는 네임노드 설정에 필요하진 않지만, 클러스터에 포함하는 편이 좋다. 사실 보조 네임노드라는 용어에는 다소 오해의 소지가 있다.(지금은 체크포인트 노드라고 부른다.)이 서버는 장애 극복을 위해 대기하는 보조 노드가 아니며, 네임노드에 장애가 발생해도 이를 대신할 수 없다. 대신 보조 네임노드는 네임노드의 장애에 대비해 장애 발생 직전의 마지막 상태를 보존하는 체크포인트를 주기적으로 저장한다. 더 자세한 HDFS 사용법을 알아보려면 부록A.1 HDFS 퀵스타트를 참조하기 바란다.

3.1.2 리소스 관리자와 스케줄러¶

좋은 분산 시스템이 갖춰야 할 핵심 요소는 스케줄링과 리소스 관리기능이다. 하둡에도 가장 효율적인 방법으로 계산 리소스를 할당하고 사용자 애플리케이션을 스케줄링하는 시스템이 존재하며, 이를 YARN이라 부른다.
YARN은 스케줄링과 리소스 관리로 데이터 지역성을 극대화하고 계란량이 많은 애플리케이션이 리소스를 독점하지 않게 제어한다. YARN은 교체 가능한 스케줄링 시스템을 지원하며, 사용자당 리소스 제한이나 작업 대기열당 리소스 할당량 등 공용 리소스 시스템의 스케줄링에 필요한 기본적인 환경 설정을 스케줄러에 입력할 수 있다.
YARN은 클러스터의 리소스를 컨테이너로 분할한다. 컨테이너는 기본으로 할당되는 CPU 코어 수와 메모리 용량으로 정의되며 추가 리소스(추가 CPU 코어, 추가 메모리, CPU,스토리지)를 포함할 수도 있다. 또한 YARN은 실행 중인 컨테이너들을 모니터링하면서 컨테이너가 리소스(CPU, 메모리, 디스크, 네트워크 등)의 최대 할당량을 초과하지 않게 억제한다. 다른 워크플로우 스케줄러와 달리 YARN은 데이터 지역성도 리소스로 제공한다. 다시 말해, YARN 애플리케이션(예를 들면 맵리듀스)은 특정 컨테이너가 특정 데이터를 저장하고 있는 서버(또는 특정 데이터와 최대한 가깝게 연결된 서버)에서 실행되도록 요청할 수 있다. 이처럼 YARN은 클러스터의 리소스를 컨테이너로 관리함으로써 분산 시스템을 전체적으로 원활하게 운영하고, 클러스터의 리소스를 다수의 애플리케이션에 공평한 방식으로 공유한다. 또한 컨테이너를 비공개로 설정할 수 있고(컨테이너를 사용자별로 분리할 수 있고) 사용자가 요청한 작업을 적절한 시점에 시작할 수도 있다.

3.1.3 분산 데이터 처리 프레임워크¶

효율적인 데이터 읽기/쓰기(I/O) 기능은 분산 시스템을 구착하는 데 필요한 토대이지만, I/O만으로는 유용한 시스템을 만들 수 없다. YARN은 컴퓨터 클러스터 전체에 계산을 분산하고 HDFS에 보관된 데이터를 확장 가능한 방식으로 처리하는 방법을 추상화해 제공할 뿐이다. 반면 이 장의 남은 부분은 계산을 표현하는 방법에 초점을 맞출 것이다.
하둡이 맨 처음에 지원한 데이터 처리 모델은 구글이 발표한 맵리듀스다. 맵리듀스의 개념은 많은 문제를 해결할 수 있고 매우 단순한 모델에 기반을 둔다. 따라서 분산 시스템 문외한도 분산 시스템의 소프트웨어 인프라 구축을 고민할 필요 없이 맵리듀스로 당면한 문제를 해결할 수 있다. 그덕분에 사용자는 해결할 문제에만 집중할 수 있다.
맵리듀스의 병렬 처리 모델은 문제를 맵단계, 셔플단계, 리듀스단계로 나눠 수행한다. HDFS의 데이터 지역성과 YARN의 작업 및 리소스 관리 기능 덕분에 맵리듀스는 이 세 단계 계산을 효율적으로 수행할 수 있다. 맵 단계에서는 입력 데이터가 클러스터에서 병렬로 처리되면 이 맵 단계를 수행하는 매퍼 함수는 원시 데이터를 키와 값의 쌍으로 변환한다. 변환된 데이터는 키를 기준으로 정렬돼 버킷으로 셔플링된다.(즉, 키가 같은 값들은 모두 동일한 리듀서로 전달된다.) 마지막으로 리듀서는 모든 키의 값을 처리하며 결과를 HDFS나 다른 영구 저장소에 저장한다.
맵리듀스의 주목할 만한 특징은 맵, 셔플, 리듀스 세 단계가 각각 무상태이거나 극히 제한적인 상태만 유지한다는 점이다. 예를 들어 실제로 계산하는 매퍼나 리듀서는 현재 입력 받은 데이터를 이전에 받은 데이터와 무관하게 처리하는데, 이는 각 단계의 매퍼 또는 리듀서가 어느 노드에서 실행될지 알 수 없기 때문이다. 단, 리듀스 단계에서는 키 값이 같은 모든 데이터를 참조한다. 이 같은 연산 방식은 매우 엉성해 보일 수도 있지만 많은 문제를 해결하기에 충분하다.
맵리듀스를 설명하는 가장 표준적인 예제는 대량의 코퍼스에 포함된 단어의 빈도를 세는 word-count 문제다. 이 문제를 맵리듀스 과정의 단계로 나눠 살펴보자. 우선 텍스트 데이터가 HDFS에 저장되면 하둡은 자동으로 데이터를 블록 단위로 쪼갠 뒤 HDFS 서버로 분산해 중복 저장한다. 그런 다음 여러 개로 분산된 매퍼가 각 블록을 병렬로 읽어들여 텍스트 데이터에 포함된 단어를 키-값 쌍 하나로 만든다(즉, 단어가 하나씩 발견될 때마다 키-값 쌍 하나(word, 1)를 만든다. 이 예제에서는 word라는 단어가 한 번 발견되었다는 뜻이다.)이 키-값 쌍은 word라는 단어가 나올 때마다 하나씩 생성된다. 키-값 쌍이 생성되면 매퍼에서 같은 키를 모두 모아 셔플링한 후 리듀서에 전달한다. 결과적으로 리듀서의 입력 데이터는 특정 단어를 가진 모든 키-값 쌍이 된다. 여기서 리듀서는 같은 단어(같은 키)를 가진 모든 값을 단순히 더하는 계산을 수행한다. 마지막으로 리듀서는 각 단어와 단어별 총 출현 빈도를 파일에 기록한다.

Note : 맵리듀스를 이해해 보자.¶

word-count는 맵리듀스 모델을 설명하는 표준적인 예제지만, 하둡을 처음 접하는 독자에게는 잘 와닿지 않을 수도 있다. 더 쉽고 재밌는 예제로 맵리듀스를 이해해 보자.
컴퓨터가 없었던 조선 시대로 돌아가자. 어느 날 심심한 전하께서 영의정을 부르셨다.

"영의정, 조선의 백정 중 남자는 몇이나 되고 여자는 몇이나 되는가? 다음 쿼리를 실행토록 하라."
SELECT 성별, count(*) FROM 조선.백성 GROUP BY 성별

영의정은 조선 시대에 빅데이터를 들이댄 전하를 속으로 욕하며 중신들을 모아 다음과 같이 전하의 쿼리를 수행하기로 했다.

1. 조선의 모든 고을에 어명을 하달해 각 남자의 짚신 한 짝과 각 여자의 비녀 한 개씩을 모아 대궐로 이송한다.
1. 각 고을의 사또는 담당 고을을 일정 구획으로 나누고 구획별로 포졸을 고르게 풀어 남자에게서 짚신을, 여자에게서 비녀를 징집한다.
1. 각 고을의 이방은 포졸이 모아 온 짚신과 비녀를 수레에 담고 대궐로 운반한다.
1. 대궐에는 모든 고을에서 진상한 짚신과 비녀가 몰려들 것이다. 짚신은 좌의정이, 비녀는 우의정이 각각 모아 전체 숫자를 집계하기로 한다.
1. 이방인들은 수레를 이리저리 끌고 다니며, 좌의정에게 짚신을 전달하고 우의정에게 비녀를 전달한다.
1. 좌의정과 우의정은 각각 짚신과 비녀를 열심히 세서 그 숫자를 영의정에게 보고한다.

이 이야기에는 데이터 리플리케이션을 제외한 맵리듀스의 거의 모든 개념이 담겨 있다.

여기서 '백성'은 '원시데이터'다. 그리고 '고을'은 백성이란 데이터를 담은'HDFS 노드'라고 볼 수 있다. 여기서 하둡의 데이터 지역성이란 개념이 등장한다. 데이터 지역성이란 그 고을의 데이터는 그 고을에서 처리하는 것이 더 좋다는 것이다. 옆 고을 포졸이 와서 비녀와 짚신을 가져갈 순 없지만 그만큼 시간과 노력이 든다.
'2번째 단계'는 '맵 단계'로, 여기서 짚신과 비녀를 모아 오는 '포졸'은'매퍼'로 볼 수 있다. 여기서 하둡의 소프트웨어 복원성이란 개념이 등장한다. 소프트웨어 복원성이란 일부 포졸이 지쳐 쓰러져도 해당 구획에 다른 포졸을 보내 짚신과 비녀를 다시 모으면 된다는 것이다. 포졸의 신체(하드웨어)가 강인할 필요는 없다.
'5번째 단계'는 '셔플 단계'로, 여기서 '짚신'과'비녀'를 데이터를 '키'로 볼 수 있다. 맵 단계에서 이방 한 명이 들고 다녔던 '짚신'과'비녀'를 셔플 단계에 이르러서는 각각 '좌의정'과 '우의정'에게 나눠 줘야 한다. 이 과정에서 수많은 이방이 '좌의정'과'우의정'에게 몰려들면서 수레를 나눠 주기 때문에 이를 셔플 단계라고 부른다. 하지만 이 과정에서 데이터가 서로 섞이지는 않는다. 모든 '짚신'은 오직 '좌의정'에게 전달되며, 모든'비녀'는 오직'우의정'에게만 전달된다.
'6번째 단계'는'리듀스 단계'로, 여기서'좌의정'과'우의정'은 두 개의 '리듀서'라고 볼 수 있다. 듀 리듀서는 전달받은'짚신'과'비녀'를 다 모아 전체 숫자를 열심히 센다. 조금 더 편리한 방법은 각 이방이 '짚신'과'비녀'의 숫자를 미리 세서 전달하는 것인데, 이를 combiner라고 한다(이 책에서는 설명하지 않는다).

맵리듀스의 기본 개념은 많은 문제를 해결할 수 있다. 특히 대수적 해법, 즉 문제를 부분 결과로 나눈 뒤 합계, 평균, 계수 등의 방법을 사용해 최종 결과로 병합하는 방식으로, 다양한 문제를 손쉽게 맵과 리듀스 작업으로 구성할 수 있다. 더 복잡한 문제 역시 (모든 문제에 해당하지는 않지만) 여러 맵리듀스 작업으로 구성할 수 있다.
하지만 모든 문제를 맵리듀스 작업으로 해석할 수 있는 것은 아니며, 맵리듀스로 변환할 수 있다고 해도 변환이 복잡하거나 효율성이 떨어지는 경우가 있다. 특히 맵리듀스는 반복이 많은 작업에 적합하지 않다. 반복되는 작업을 여러 맵리듀스 작업으로 구성할 수는 있지만, 반복의 중간 결과를 항상 파일로 저장하고 프로그래머가 직접 여러 단계의 맵리듀스 워크플로우를 관리하며 작업이 실패할 때마다 중간부터 작업을 수동으로 재시작해야 하는 불편함이 따른다. 이러한 상황은 반복적인 수렴 과정이 필요한 과학 실험이나 머신 러닝 알고리즘을 구현할 때 자주 발생한다. 예를 들어 선형대수학(예를 들면 고유벡터를 찾는 데 사용되는 멱방법)이나 머신 러닝에서 자주 활용되는 최적화(예를 들면 경사 하강법) 문제에서 이러한 반복적인 알고리즘을 쉽게 발견할 수 있다.

Note : 멱방법¶

멱방법(power method)은 행렬의 고윳값(eigenvalue)과 고유벡터(eigenvector)를 계산하는 알고리즘이다. 행렬을 분해하거나 복잡한 계산을 적용하는 대신, 초기 벡터를 무작위로 만든 후 이 벡터에 행렬을 계속 곱해 나가면서 곱셈의 결괏값이 더는 크게 변하지 않고 수렴할 때까지 반복한다.

Note : 경사 하강법¶

경사 하강법(gradient descent)은 주어진 비용 함수(cost function)의 지역 최적 해(local minimum)를 찾는 최적화(optimization) 알고리즘이다. 무작위로 설정된 위치에서 시작해 현재 위치에서 계산한 기울기(gradient)의 역(negative)방향으로 위치를 조금씩 반복해서 옮기다 보먄, 결국 가장 낮은 함숫값을 가진 위치로 수렴한다.

YARN이 컴퓨터 모델의 리소스 할당 작업을 일반화하게 되면서 하둡은 단순한 맵리듀스를 넘어 다양한 계산 모델 및 데이터 처리 엔진의 가능성을 열었다. YARN은 하둡에 비교적 최근에 추가된 개념이며 다양한 유형의 모델(예를 들면 MPI를 사용하는 고전적인 클러스터 컴퓨팅 모델)에 대한 지원이 앞으로도 계속 추가되기를 기대한다. 또한 YARN에 기반한 아파치 테즈, 아파치 스파크, 아파치 플링크 같이 최근에 새로 등장한 처리 엔진은 하둡의 기능을 더욱 풍부하게 확장하는 데 기여했다.
많은 문제가 하나의 맵리듀스 단계를 넘어 여러 리듀스 단계로 확장될 수 있는데, 간혹 이 리듀스 작업 간에 교환되는 데이터를 정렬할 필요가 없는 경우도 있다. 아파치 테즈는 이러한 유형의 문제를 더 효율적으로 실행할 수 있는 소프트웨어 레이어로 개발되었다. 아파치 테즈의 주요 목적은 복잡한 데이터의 흐름을 좀더 효율적으로 구현하고 기본 하둡 SQL 엔진인 하이브의 데이터 조인 쿼리를 더 효율적으로 실행하는 것이다. 테즈는 사용자가 직접 사용하는 도구는 아니며, 다른 하둡 프로젝트가 사용할 수 있는 저수준 소프트웨어 API라고 할 수 있다. 무엇보다 테즈 모델을 사용 하면 한 작업의 리듀서가 중간 데이터를 HDFS에 저장하지 않고 직접 다른 리듀서로 전송 할 수 있다. 또한 다중 조인 작업을 매퍼와 리듀서의 일직선 파이프라인으로 표현하는 대신 이보다 직관적인 방향성 비순한 그래프로 표현할 수도 있다.
아파치 스파크는 데이터 과학에서 자주 등장하는 반복 연산에 더 적합한 개념과 기능을 제공하는 인-메모리 데이터 처리 엔진이다. UC Berkeley의 AmpLab에서 최초로 개발한 스파크는 기본적인 분산 처리 기능뿐만 아니라 스파크 SQL, MLlib, 스트리밍 등 여러 구성 요소를 추가하며 가장 인기 있는 아파치 프로젝트로 성장했다. 스파크에서 사용하는 기본 데이터 구조는 객체의 분산 시퀀스인 RDD로 휘발성 메모리인 RAM에 저장되면서 자동으로 장애를 극복하는 메커니즘을 지원한다. 스파크는(주로 장애 때문에)RDD 데이터가 누락되었다면 데이터의 일부분에 대한 연산만 재실행해 복원할 수 있다. 또한 UNION, DISTINCT, FILTER, JOIN 같은 관계형 연산자를 기본으로 제공하는데, 이 연산자들이 RDD를 실제로 계산하는 시점은 연산자를 적용한 시점보다 지연된다.
아파치 스파크와 유사한 인-메모리 처리 엔진으로 실시간 데이터 스트림 처리에 특화된 아파치 플링크를 사용할 수도 있다.

Note : 스파크는 왜 빠를까?¶

맵리듀스 대규모 데이터의 일괄 처리에는 뛰어나지만, 저지연(low-latency) 애플리케이션과 반복 연산(머신 러닝, 그래프 연산등)을 효과적으로 지원하지 못한다. 스파크는 데이터를 분산 메모리로 캐싱(caching)할 수 있어서 빠른 연산과 저지연 응답 속도를 달성했다. 또한 메모리에 올려 둔 데이터셋을 반복적으로 사용할 수 있어 머린 러닝 알고리즘에서도 더 빠른 속도로 대규모 데이터를 활용할 수 있다.

Note : 스파크를 이해해 보자¶

스파크 RDD가 제공하는 연산지는 크게 변환(transfomation)과 행동(action)으로 나뉜다. 그중 변환 연산자는 연산자가 쓰인 시점에 계산되지 않고 지연된다. 스파크는 사용자가 변환 연산자를 연속으로 사용하면 일단 이 내용을 DAG형태로 기억해 두었다가 행동 연산자가 사용된 시점에 이르러서야 변환 연산자와 행동 연산자를 빠르게 처리한다.
다시 조선 시대로 돌아가서 스파크의 지연 연산을 이해해 보자. 어느 날 또 심심해진 전하께서는 조선 농부의 근력과 쌀 생산량 간의 관계를 살펴보고 싶어졌다. 하지만 어떻게 분석할지 아직 감이 없었던 전하께서는 매일같이 영의정을 불러 다음과 같은 산발적인 질문을 마구 던지기 시작했다.
- 1.영의정, 각 농부가 쇳덩이를 몇 개 들어 올릴 수 있는지 다 조사해 보시오.
- 2.영의정, 각 농부가 몸무게는 얼마나 되는지 중요할 듯하오. 조사해 보시오.
- 3.영의정, 생각해 보니 몸무게도 중요하지만 키도 필요하오. 조사해 보시오.
- 4.영의정, 농부의 키와 몸무게를 곱하고 이를 분모로 쇳덩이 개수를 나누시오.

영의정은 속에서 깊은 울화를 느꼈지만, 꾹 참고 어명을 받아 적었다. 그런데 생각해 보니 전하께서 막 던질 때마다 바로바로 어명을 전달할 필요가 없을 것 같았다. 영의정은 전하께서 던지는 질문들을 각 고을에 하달하지 않고 묵묵히 계속 받아만 적었다.
어느날 전하께서는 모든 산발적인 질문을 마치고, 다음과 같이 물어봤다.

영의정, 저번에 시켰던 것들 한번 봅시다. 고을별로 샘플 10개씩 보여 주시오.

영의정은 이때다 싶어 앞서 받아 적었던 모든 어명을 한꺼번에 각 고을에 하달했다. 여기서 농부별로 조사해야 하는 모든 '측정 작업'은 '변환'연산자에 해당하며, 마지막에 요청된'샘플 조회'는 '행동'연산자에 해당한다. 이처럼 변환 연산자는 행동 연산자가 있을 때까지 실행이 지연될 수 있다.

3.2 하둡의 진화 과정¶

최초에 아파치 넛치가 존재했다. 아파치 넛치는 오픈 소스로 공개된 검색 엔진 소프트웨어였다. 그리고 2005년 인터넷 아카이브의 검색 팀장이었던 더그 커팅과 워싱턴 대학의 대학원생이었던 마이크 카파렐라는 하둡의 초기 모듈을 개발해 넛치 프로젝트를 지원했다. 이 모듈의 구현은 앞서 언급한 2003년의 구글 파일 시스템 논문과 2004년에 구글이 발표한 맵리듀스 논문의 영향을 받았다.
2006년 넛치 프로젝트의 발전과 더그 커팅의 야후! 합류를 기점으로, 그가 개발한 넛치 프로젝트속의 이 특별한 모듈은 야후!의 인프라 소프트웨어에서 중요한 역할을 차지하게 되었다. 당시에는 검색 엔진의 일부 모듈에 불과했지만, 더 다양한 문제에 적용할 수 있는 독립적인 분산 처리 프레임워크 프로젝트로 발전할 가능성이 분명했다. 그리하여 더그 커팅의 다섯 살배기 아들이 가지고 놀던 장난감 코끼리의 이름을 딴, 하둡이라는 별도의 오픈 소스 프로젝트가 탄생했다.
그로부터 성순한 플랫폼으로 거듭나기 위한 긴 여정이 시작되었다. 야후!는 웹 검색 색인을 하둡으로 이전하는 작업에만 수년을 매달렸다. 그 결과 야후!는 자사의 데이터 과학자들이 연구에 매진할 수 있는 그리드 인프라를 구축하는 데 성공했고, 하둡은 야후!의 대규모 데이터 과학 프로젝트를 위한 필수 인프라로 자리매김했다. 하둡 인프라는 아직 미성숙한 데이터 과학 프로젝트가 지닌 결함을 용서하고 더 성숙할 시간을 벌어주는 보호 환경이 될 수 있었다.
얼마 지나지 않아 하둡은 야후!의 핵심 인프라로 성장하며 야후!의 다양한 데이터를 분석하는 만능 머슴 같은존재로 발전했다. 또한 스케줄링 관련 기능이 추가되고 현대 인터넷의 대규모 검색 엔진을 위한 비즈니스 요구 사항에 부합하는 성능을 보장할 수 있었다. 당시 하둡의 사용자들은 검색 엔진을 위한 비즈니스 요구 사항에 부합하는 성능을 보장할 수 있었다. 당시 하둡의 사용자들은 검색 엔진을 넘어 더 다양한 비즈니스에서 하둡을 핵심 기술로 활용할 수 있다는 사실을 깨달았고 이러한 통찰은 하둡의 보급을 목적으로 하는 새로운 회사의 창업 기회로 이어졌다.
2008년 마이크 올슨과 구글 출신의 크리스토프 비실리아, 야후!출신의 아마 아와델라, 페이스북출신의 제프 하머바커는 클라우데라를 창업했다. 클라우데라는 실리콘밸리를 넘어 더 넓은 세상에 필요한 ( 그 필요성이 막 대두되었지만 점점 증가하던) 하둡의 전문성을 널리 전파하는 것을 목적으로 했다. 더그 커팅도 머지않아 야후!를 떠나 클라우데라에 합류했고 하둡을 계속 발전시키고 전파하는 데 힘을 보탰다.
클라데우라의 성공은 다른 이의 눈에 띄지 않을 수 없었고, 하둡 시장은 더 넓고 분명해 보였다. 2011년에 야후!는 호튼웍스라는 스핀 아웃 회사를 창업했다. 그동안 하둡을 사랑스럽게 돌보던 야후!의 직원들이 호튼웍스에 합류했고 하둡을 더 넓은 업계로 전파하는 노력을 기울였다.
기업용 하둡 배포판을 만드는 사업에 뛰어든 것은 비단 스타트업만이 아니었다. EMC나 인텔 같은 대기업도 하둡 사업에 진입하기 시작했다. 또한 MapR과 글라우데라는 오픈 소스 비즈니스를 벗어나 하둡의 불편하고 거친 사용성을 개선한 독자적인 하둡 배포판을 제공했다.
그 후, 더욱 확장된 기능으로 하둡을 더 매력적으로 만들어 준 하둡 2.0이 등장했다. 새로운 하둡은 하나의 맵리듀스 시스템에서 나아가 대규모 분석 애플리케이션을 실행할 수 있는 데이터 센터 운영시스템으로 거듭났다. 그와 동시에 하둡을 대규모 기업형 데이터 센터에 걸맞은 기술로 발전시키기 위해, 지금까지는 다소 부족했던 보안과 스케줄링 기능을 강화하는 시도가 집중적으로 이루어 졌다.

3.3 데이터 과학용 하둡 도구¶

데이터 과학자는 자신에게 익숙한 하둡 도구를 골라 데이터 입수, 데이터 품질 분석, 데이터 정제, 스크립팅, 통계 계산, 분산 처리, 시각화 등의 다양한 업무에 활용한다. 데이터 과학자가 하둡과 함께 주로 사용하는 도구와 프레임워크를 살펴보자.

3.3.1 아파치 스쿱¶

아파치 스쿱은 하둡과 정형 데이터베이스(예를 들면 관계형 데이터베이스나 NoSQL 데이터베이스)간의 효율적인 대용량 벌크 데이터 전송을 지원하는 도구다.
스쿱 버전 1을 사용해 외부 시스템의 데이터를 HDFS로 가져와 하이브나 HBase 테이블에 삽입할 수 있다. 또한 스쿱은 플러그인을 지원하는 커넥터 기반 아키텍처로 구현되어 스쿱에 새로운 유형의 외부 데이터 소스를 연동할 수도 있다. 스쿱이 기본으로 제공하는 데이터베이스 커넥터는 MySQL, PostgreSQL, Oracle, SQL Server, DB2 등이 있다. 스쿱이 버전 1에서 버전 2로 업그레이드 되면서 많은 변화가 있었다. 스쿱에 관한 더 자세한 정보는 4장 하둡을 활용한 데이터 입수를 참조하자.
스쿱은 전송할 데이터를 파티션으로 분할하고 각 파티션에 매퍼 작업을 할당해 파티션의 데이터를 목적지로 전송한다. 다음 예제는 4개의 매퍼 작업을 사용해(-m 4 옵션) 지리 정보를 저장한 외부 MySQL 데이터베이스에서 캐나다의 도시 목록을 모두 가져온다. 이 예제의 실행 결과는 HDFS에 저장된다.

sqoop --options-file world-options.txt -m 4 --target-dir \
/user/hdfs/sqoop-mysql-import/canada-city --query"SELECT ID, Name \
from City WHERE CountryCode='CAN' AND \&CONDITIONS" --split-by ID

앞에서 언급했듯이 4장 하둡을 활용한 데이터 입수에서 아파치 스쿱에 관한 자세한 예제를 참조할 수 있다.

3.3.2 아파치 플럼¶

아파치 플럼은 서버에서 생성되는 대용량 로그 데이터를 효율적으로 수집해 HDFS로 전송하는 안정적인 분산 서비스다. 플럼의 단순하고 유연한 아키텍처는 소스에서 저장소로 데이터를 보내는 역할을 하는 에이전트로 구성돼 있다. 또한 플럼은 안정성의 조절과 다양한 장애 복구 메커니즘으로 견고한 장애 허용을 제공한다.
플럼을 사용하려면 플럼 에이전트가 최소 두 개 필요하다(소스에 하나, 저장소에 하나.)플럼은 여러 소스에서 데이터를 수집할 수 있으며 여러 플럼 에이전트를 파이프라인으로 구성할 수도 있다. 다음은 소스 호스트(예를 들면 웹 서버)에서 미리 준비된 설정 파일(web-server-source-agent.conf)을 사용해 소스 에이전트를 구동하는 명령이다.

flume-ng agent -c conf -f wed-server-source-agent.conf -n source_agent

하둡클러스테에서 실행되는 콜렉터 에이전트는 소스 데이터를 수신해 HDFS에 저장한다. 다음 명령과 같이 콜렉터 에이전트 설정 파일(web-server-target-agent.conf)을 사용해 콜렉터 에이전트를 구동할 수 있다.

flume-ng agent -c conf -f wed-server-target-agent.conf -n collector

아파치 우지와 아파치 팔콘은 하둡의 데이터 처리 및 관리 솔루션이다. 우지와 팔콘은 데이터 이동, 데이터 파이프라인 조정, 데이터 생명 주기 관리, 데이터 검색에 이르는 다양한 단꼐의 관리 기능을 제공한다. 팔콘은 데이터의 최종 소비자가 하둡 클러스터에 저장된 데이터와 이 데이터를 처리하고 관리하는 작업을 빠르게 파악할 수 있는 데이터 관제 기능을 제공한다. 4장 하둡을 활용한 데이터 입수에서 아파치 플럼, 우지, 팔콘에 관한 더 자세한 예제를 볼 수 있다.

3.3.3 아파치 하이브¶

아파치 하이브는 SQL로 하둡 데이터를 분석하려는 페이스북 엔지니어들의 요구로 페이스북 내부에서 개발되었다. 그 후 오픈 소스로 공개돼 많은 개발자가 활발하게 참여하는 프로젝트가 되었다. 하이브 쿼리는 테즈의 DAG 작업으로 컴파일되며 테즈 엔진으로 하둡 클러스터에서 실행된다. 과거의 하이브는 주로 수 시간에서 수일까지도 걸릴 수 있는 대규모 SQL 쿼리를 실행할 목적으로 설계되었지만, 하이브 개발자 커뮤니티의 끊임없는 개선 노력으로 하이브의 실행 속도가 훨씬 빨라져서 이제는 대화형 쿼리와 실시간 쿼리까지 지원한다.
SQL은 상당 기간 현역 데이터 과학자의 도구로 애용되어 왔기 때문에 SQL을 장착한 하이브도 마찬가지로 주목을 받는 게 그리 놀라운 일은 아니다. SQL의 중요한 장점은 사용자가 데이터의 모양과 본질적인 특성을 손쉽게 이해할 수 있다는 점이다. SQL의 중요한 장점은 사용자가 데이터의 모양과 본질적인 특성을 손쉽게 이해할 수 있다는 점이다. 하이브를 사용하는 방법은 여러 가지다. 하이브와 JDBC나 ODBC로 연동된 여러 서드파티 도구를 통하거나, 하이브와 직접 연결된 강력한 명렬줄 인터페이스 프로그램을 사용할 수도 있다.
또한 하이브 커스텀 함수를 래퍼 형태로 추가할 수 있는 훌륭한 프로그램 확장 기능을 제공한다. 이 확장 기능은 진취적인 데이터 과학자에게 자바 생태계에서 쌓여 있는 수많은 툴체인을 제공하는 길을 열어 주었다. 하이브가 지원하는 확장 기능은 다음 두 가지다.

사용자 정의 함수
사용자 정의 집계 함수

사용자 정의 함수는 주어진 입력 데이터만을 기반으로 작동한다. 즉, 함수로 전달된 데이터 외에는 어떤 정보도 참조하지 않는다. 얼핏 보기엔 불편한 제약같지만, 사실 굉장히 유용하다. 특히 데이터가 복잡할 때는 단 한 조각의 데이터만으로도 상당히 많은 일을 할 수 있다. 예를 들어 OpenNLP에서 제공하는 자연어 처리 함수를 하이브 UDF로 추가하면 여러 흥미로운 데이터 분석 기능을 사용할 수 있다.
사용자 정의 집계 함수는 전체 데이터셋에 적용되는 함수로 데이터의 규모에 비례하지 않는 일종의 집계 상태를 계산한다. 예를 들어 일정 크기의 버킷으로 데이터를 집계하는 히스토그램 함수를 사용자 정의 집계 함수로 구현할 수 있다. 여기서 집계 상태는 버킷과 버킷별 데이터 개수이며, 이 함수에 데이터를 흘려보낼 때마다 데이터에 해당하는 버킷의 데이터 개수가 갱신된다. 사용자 정의 집계 함수에서 주목할 만한 점은 이 함수가 대수적 성질(즉, 전체를 작은 부분으로 분할하고 분할된 각 부분의 집계 결과가 다시 전체로 병합될 수 있는 성질)을 지녔다는 것이다. 다시 말해 대규모 분산 노드에 사용자 정의 집계 함수를 적용한 다음, 각 집계를 연산 결과를 디류서에서 다시 병합할 수 있다. 사용자 정의 집계 함수를 만들면서 이러한 세부적 구현 로직까지 알 필요는 없지만, 시스템의 기본 가정을 이해해 두면 분명 도움이 될 것이다.
일본 정보 기술 연구소에서 개발한 Hivemall은 하이브의 확장 기능을 활용해 머신 러닝의 기본 기능을 구현한 사용자 정의 함수다. Hivemall은 분류 및 회귀 알고리즘과 정보 검색 분야의 기본 함수(예를 들면 집합 유사도 기반의 대규모 데이터 군집화를 수행하는 지역성 민감 해시의 일종인 MinHash 알고리즘) 등 다양한 머신 러닝 기능을 갖췄다. 이는 하이브가 제공하는 확장 기능이 그만큼 강력하다는 방증이기도 하다.
하이브는 수많은 기능을 갖춘 매우 복잡한 시스템이므로 여기서 모든 기능을 다룰 수는 없다. 하이브를 더 자세히 알고 싶다면 에드워드 카프리올로, 딘 윔플러, 제이슨 러더글렌이 쓴 <하이브 완벽 가이드>(한빛미디어, 2013)를 읽어 볼 것을 추천한다.
앞서 설명한 word-count 문제를 하이브에서 구현한 예제를 살펴보자. 이 예제는 하이브 명령줄 유틸리티나 JDBC기반 SQL 유틸리티로 실행할 수 있다.

CREATE TABLE docs (line_text STRING);
LOAD DATA INPATH '/user/demo/text_file.txt' OVERWRITE INTO TABLE docs;
CREATE TABLE word_count AS
- SELECT word, count(1) AS count FROM
  - (SELECT explode(split(line_text, '\s')) AS word FROM docs) word
- GROUP BY word
- ORDER BY word;

Warning¶

여기서 입력 파일로 사용한 /user/demo/text_file.txt는 책의 예제 코드에 없다. 대신 띄어쓰기가 포함된 텍스트 파일을 아무거나 하나 골라 적용해 보면 된다. 하이브의 strict 모드에서 ORDER BY를 제한하므로 쿼리 실행 중 에러가 발생할 수 있다. 이때는 다음과 같이 우회하자.

임시로 nonstrict 모드로 변경한다. 해당 쿼리를 실행하기 전에 다음 설정을 실행하면 된다. 하지만 리듀서 한 개로 정렬 작업을 처리하므로 데이터가 매우 많을 경우 쿼리의 실행 시간이 길어진다.
set hive.mapred.mode=nonstrict;
ORDER BY를 SORT BY로 변경한다. ORDER BY는 전체 데이터의 순서를 정렬하는 반면, SORT BY는 리듀서별로 데이터의 순서를 정렬한다. 따라서 만약 복수의 리듀서가 사용된 경우, 전체 데이터가 정렬되지 않는다. SORT BY는 DISTRIBUTE BY와 같이 사용돼 데이터를 특정 부분별로 정렬해야 할 때 유용하다(예를 들어, 각 고객별로 가장 많이 구매한 상품을 내림차순으로 정렬하고자 한다면 SQL에 'DISTRIBUTE BY customer_id SORT BY purchase_cnt DESC'를 적용할 수 있다.)
SELECT 문 마지막에 LIMIT를 추가해 데이터를 일부 제한한다.

또한 /user/demo/라는 HDFS 경로도 독자가 하둡 클러스터 안에서 권한을 부여받은 결로로 바꿔 주어야 한다. 호튼웍스 샌드박스에서 root 계정으로 실행할 경우에는 HDFS의 모든 경로에 권한을 가지고 있다.

3.3.4 아파치 피그¶

아파치 피그는 하둡의 복잡한 추출, 변환, 적재 작업을 손쉽게 구현하려는 요구로 야후! 내부에서 개발되었다.
피그는 ETL 작업을 지원하기 위해 설계된 도메인 특화 언어다. 피그는 관계형 기본 함수를 제공하며, 최소 개수의 맵리듀스 또는 테즈 작업으로 구성된 논리 단계로 연산을 변환하고 실행하는 최적화 기능을 갖추고 있다.
하이브가 단발적인 애드혹 쿼리에 적합하다면, 피그는 다수의 중간 결과물이 필요한 좀더 복잡한 분석 쿼리에 적합하다. 대량의 조인 연산이나 중간 테이블이 필요한 경우에는 하이브 대신 피그 쿼리를 사용하는 것이 낫다.
하이브와 마찬가지로 피그에서도 사용자 정의 함수로 기능을 확장할 수 있다. 예를 들어 JAM언어로 사용자 정의 함수를 구현해 사용하거나 다른 언어로 구현된 스트리밍 사용자 정의 함수를 피그 프로세스 안에서 호출할 수도 있다(JVM 언어를 사용할 경우에는 연산 성능이 다소 떨어진다).
하이브의 사용자 정의 함수인 Hivemall처럼, 피그에도 아파치 DataFu라는 데이터 과학용 사용자 정의 함수가 있다. 아파치 DataFu는 하둡 플랫폼에서 데이터 과학 작업을 좀더 쉽게 수행할 수있는 여러 도구를 제공한다. DataFu는 링크드인에서 최초로 개발되었으며, 이후 아파치 인큐베이팅 프로젝트로 분리되었따. DataFu는 피그가 기본으로 제공하는 샘플링 기능보다 견고하고 다양한 샘플링 기술을 제공한다. DataFu의 샘플링 기술에는 비율 대신 정해진 개수를 뽑아내는 균등 샘플링, 가중 샘플링, 복원 샘플링 등이 있다. 또한 분위수, 중앙값, 분산 같은 기술 통계의 기본 기능을 지원한다. 추가로 기술 통계량을 스트리밍 알고리즘으로 계산해 분위수, 중앙값, 개수등을 더 효율적으로 추정하는 사용자 정의 함수도 제공한다.
여기서 피그의 모든 내용을 일일이 다루지 않는다. 피그에 관한 더 많은 내용은 알란 게이트가 쓴 Programming Pig)(O'Reilly,2011)를 참조하기 바란다. 대신 grunt(피그용 명렬줄 셸)에서 실행할 수 있는 피그 스크립트 예제를 살펴보자. 이 예제에서는 앞서 하이브 예제와 유사한 word-count 연산을 실행한다.

SENTENCES = load '/user/demo/text_file.txt';
WORDS = foreach SENTENCES generate flatten(TOKENIZE((chararray)$0)) as word;
WORD_GRP = group WORDS by word;
WORD_CNT = foreach WORD_GRP generate group as word, COUNT(WORDS) as count;
store WORD_CNT into '/user/demo/wordcount';

위 예제에서는 입력 파일을 텍스트 줄로 구성된 SENTENCES 릴레이션 형태로 HDFS에서 불러온다. 그런 다음 내장 TOKENIZE 함수와 foreach 프로젝션 연산자로 각 줄의 단어를 분할한다. 다음으로, group by 연산자와 내장 COUNT 함수를 연이어 호출해 각 단어의 출현 횟수를 집계한다. 집계 결과를 HDFS의 wordcount 폴더에 저장한다.

3.3.5 아파치 스파크¶

앞서 설명했듯이 비교적 최신 프로젝트에 속하는 아파치 스파크는 분산 인-메모리 데이터처리 프레임워크다. 스파크 스칼라와 파이썬을 지원하는 대화형 데이터 처리 기능을 제공하며 이를 통해 데이터 전처리를 매우 효과적으로 수행할 수 있다.
스파크에서 주로 사용되는 추상화 객체는 RDD로, 다양한 관계 대수 연산자(SELECT, FILTER, JOIN, GROUP BY등)와 기타 스칼라 및 파이썬 변환 로직의 피연산자로 적용될 수 있다.
또한 최근 RDD를 기반으로 구현된 DataFrame은 좀더 손쉬운 데이터 슬라이싱과 다이싱 기능을 제공한다. 이 기능은 파이썬 Pandas 라이브러리의 슬라이딩/다이싱 APL와도 유사하다.
스파크의 스칼라 명령 셸로 실행할 수 있는 word-count 예제를 살펴보자.

val file = sc.textFile("/user/demo/text_file.txt")
val count = file.flaMap(line => line.split(" "))
```
         .map(word => (word, 1))
         .reduceByKey(_ + _)
```
counts.saveAsTextFile("/user/demo/wordcount")

스파크는 발전을 거듭해 단순한 RDD 기반 처리 엔진을 넘은 다양한 기능을 제공한다.
스파크 SQL은 하이브를 대체할 수 있는 분산 SQL 처리 엔진이다. 스파크 코어를 기반으로 구현된 스파크 SQL은 기존 SQL 쿼리문을 지원하는 것은 물론이고 대규모 데이터셋을 빠르고 효율적으로 처리하는 관계형 대수 연산 APL인 DataFrame을 제공한다. 스파크 SQL의 가장 흥미로운 장점은 SQL 실행 결과로 얻은 데이터를 디스크에 쓰지 않고 바로 스파크로 가져올 수 있다는 점이다.
스파크 MLlib는 분산 데이터셋에 적용할 수 있는 다양한 머신 러닝 알고리즘을 구현해 스파크 툴셋과 연동한 머신 러닝 라이브러리다. 현재 스파크 MLlib가 지원하는 머신 러닝 알고리즘으로는 선형 및 로지스틱 회귀, 서포트 벡터 머신, 의사 결정 트리, 랜덤 포레스트, k-평균 군집화, SVD 등이 있으며 새 릴리스가 나올 때마다 지원하는 알고리즘이 늘고 있다.
스파크 GraphX는 스파크 기반 그래프 라이브러리와 그래프 병렬 연산 라이브러리로 페이지랭크, 레이블 전파, 삼각 계수 등의 그래프 알고리즘을 지원한다. 스파크 스트리밍은 아파치 스톰과 유사한 스파크 모듈로 확장성과 장애 허용을 갖춘 스트리밍 애플리케이션을 구축하는 플랫폼이다. 스파크 스트리밍의 스트리밍 기능은 스파크의 기본 API를 확장해 슬라이스 데이터를 처리하는 방식으로 설계되었다. 스파크의 기본 데이터셋 추상화 객체가 RDD인 반면, 스파크 스트리밍의 데이터셋 추상화 객체는 DStteam이다. 즉, 스파크 스트리밍은 데이터 스트림을 개별 세그먼트로 나눈 다음 각 세그먼트의 데이터를 스파크 엔진으로 처리한다.

R¶

R은 데이터 처리, 연선, 통계 분석, 그래픽 시각화용 오픈 소스 언어 및 환경이다. AT&T 연구소에서 처음으로 개발된 R은 수학 연산, 통계 분석, 머신 러닝을 지원하는 강력하고 성숙한 언어로 주목 받는다.
R은 데이터 과학자가 대화형 데이터 분석을 시작할 때 가장 먼저 사용하는 도구이기도 하다. R은 급속도로 발전을 거듭해 현재 6천 개가 넘는 패키지를 지원한다.
또한 R은 널리 사용되는 데이터 모델링 및 시각화 도구이며 분류, 회귀, 군집화, 베이지안 학습과 다양하고 강력한 패키지를 지원한다. R이 제공하는 기능을 다음과 같이 요약할 수 있다.

기본적으로 제공되는 데이터 프레임 기능과 강력한 확장 패키지: data.table, dplyr등
기본으로 지원되는 일반 선형 모델: lm(), glm() 등
머신 러닝 알고리즘을 위한 다양한 R 패키지: randomforest(랜덤 포레스트), gbm(그래디언트 부스팅 머신), glmnet(LASSO와 Elastic Net 등 일반 선형 모델), nnet(인공 신경망), rpatt(의사 결정 트리), cluster(군집 분석)등
강력한 시각화 기능: 기본 R 환경 또는 ggplot과 같은 확장 패키지
텍스트 마이닝 기능: tm 패키지 등

또한 다음과 같이 R 환경 내에서 하둡과 연동할 수 있는 다양한 R 패키지가 개발되었다.

R Hadoop: RMR(R에서 맵리듀스를 실행), RHDFS(R을 통해 HDFS 파일에 접근), RHBASE 등을 지원하는 프로젝트
R Plyr: HDFS 데이터를 가공/처리하는 다양한 기능을 제공(plyr와 유사)
RODBC: R 환경용 ODBC 인터페이스 패키지. 주로 R 콘솔에서 직접 하이브에 접속하는데 사용한다.

RMR로 구현한 word_count의 예제를 살펴보자. 다음 코드는 RStudio나 R 명령줄에서 실행할 수 있다.

library(rm2)
wordcount = function(input, output=NULL) {
$\quad$wc.map = function(., lines) {
$\quad$$\quad$keyval(unlist(strplit(x = lines, split = " ")),1)
} $\quad$wc.reduce = function(word, counts) {
$\quad$$\quad$keyval(word, sum(counts))
} $\quad$mapreduce(input, output, input.format="text",
$\quad$$\quad$$\quad$$\quad$map=wc.map, reducer=wc.reduce, combine=T)
}

Note : RHadoop 환경¶

앞의 R 코드를 실행하려면 다소 복잡한 환경 설정이 필요하다. RHadoop 설치와 사용에 관련한 정보는 RHadoop 깃허브 페이지(https://github.com/RevolutionAnalytics/RHadoop/wiki)를 참조하자.

SparkR 프로젝트는 R 분야에 새로 등장한 유망주로 다음과 같이 흥미로운 (하지만 아직은 제한적인)스파크 연동 기능을 제공한다.(현재는 아파치 스파크 프로젝트에 공식으로 포함돼 있다.)

익숙한 스파크 DataFrame API: data-frame과 유사한 대규모 데이터셋을 하둡에서 다루는데 유용하다.
하둡에 저장된 데이터에 SQL 쿼리를 실행하는 기능
머신 러닝 알고리즘의 초기 지원: 일반 선형 모델, 나이브-베이즈, k-군집화 등 몇몇 알고리즘을 R 환경에서 스파크로 실행하게 지원한다.

3.3.7 파이썬¶

최근 데이터 처리와 머신 러닝을 위한 강력한 파이썬 패키지가 많이 개발된 덕분에 범용 프로그래밍 언어인 파이썬을 데이터 과학에 활용하는 사례가 증가하는 추세다. 파이썬에서 사용하는 데이터 과학 패키지는 다음과 같다.

Pandas: 데이터 프레임 추상화 객체를 사용해 데이터를 처리하고 분석하는 강력한 파이썬 패키지
NumPy: 과학 컴퓨팅을 위한 핵심 라이브러리, 편리한 N차원 배열 객체와 선형대수, 푸리에 변환, 난수 생성 등을 위한 강력한 기능을 제공한다.
SciPy: 과학과 수학 분야에서 연산과 최적화를 수행하는 핵심 라이브러리
matplotlib: 데이터 시각화에 주로 사용되는 2D 차트 생성 라이브러리
NLTK: 텍스트 마이닝과 자연어 처리에 사용하는 라이브러리
spaCy: 성능과 안정성에 중점을 둔 기업용 자연어 처리 라이브러리
scikit-learn: NumPy 및 Pandas와 원활하게 연동되는 머신 러닝 라이브러리

또한 파이썬은 하둡 애플리케이션 개발에 두 번째로 많이 사용되는 언어이기도 하다(물론 자바가 가장 많이 사용된다).

파이썬은 하둡 스트리밍, 피그, 하이브 UDF를 사용하는 맵리듀스 애플리케이션을 개발할때 자주 사용된다.
스파크는 파이썬 API(PySpark)를 기본으로 지원한다.
파이썬 환경에서 하둡과 연동할 수 있는 다양한 패키지(예를 들면 Pydoop)가 있다.

스파크의 PySpark 명령 셸로 실행할 수 있는 word-count 예제를 살펴보자.

file = sc.textFile("hdfs://some-file")
counts = file.flatMap(lambda lind: line.split(" "))\ $\quad$$\quad$$\quad$$\quad$.map(lambda word: (word,1)) \ $\quad$$\quad$$\quad$$\quad$.reduceByKey(lambda a, b: a+ b)
conts.saveAsTextFile("hdfs://wordcount-out")

3.3.8 자바 머신 러닝 패키지¶

데이터 과학 커뮤니티에서 모델링에 가장 많이 사용하는 언어는 R과 파이썬이지만, 자바 역시 유력한 경쟁자로 데이터 전처리와 모델링용 자바 라이브러리가 여럿 개발되었다.

WEKA: 다양한 데이터 마이닝 작업용 머신 러닝 알고리즘 라이브러리
Vowpal Wabbit: 빠른 성능을 보이는 자바 기반 머신 러닝 라이브러리. 야후!에서 처음 개발했으나 마이크로소프트 연구소가 프로젝트를 이어나갔다.
OpenNLP, CoreNLP, Mallet: 통계 기반 자연어 처리와 기타 텍스트 마이닝 기능을 제공하는 자바 기반 패키지

자바는 하둡 생태계의 주 구성원답게 맵리듀스, 테즈, 스파크 기반 애플리케이션의 전처리 작업과 피그 및 하이브의 사용자 정의 함수, Cascading 등에서 계속 중요하게 사용된다.

3.4 하둡이 데이터 과학자에게 유용한 이유¶

데이터 과학은 가설을 세우고 실험을 설계하는 과정의 반복이다. 하둡이 데이터 과학을 최소한의 저항으로 지원하는 핵심적인 속성은 다음과 같다.

장애 허용을 갖춘 저비용 스토리지
다양한 언어 지원
스키마 온 리드
견고한 스케줄링과 리소스 관리
분산 시스템 추상화 레벨
대규모 데이터 기반한 모델 구축
모델에 대규모 데이터를 적용

3.4.1 저비용 스토리지¶

하둡은 상용 하드웨어로도 장애를 극복하는 복원성을 갖춘 오픈 소스 소프트웨어이며, 하둡을 도입하면 테라바이트당 비용을 크게 절감하는 행복한 결과로 이어질 수 있다. 또한, 하둡은 기업에 지금까지 쉽게 얻을 수 없었던 기회와 가능성을 제공한다.
첫째, 페타바이트 규모의 데이터를 처리하도록 설계된 시스템을 저렴한 비용으로 보유할 수 있다는 것은 결국 더 많은 데이터를 수집할 수 있다는 뜻이다. 이는 어떠한 데이터를 수집할 것인지를 결정하는 조직의 기준이 과거의 폐쇄적인 모델에서 더 개방적인 모델로 변해야 함을 시사한다. 다시 말해, 과거 상당수 기업의 정책은 이미 유용하다고 알려진 데이터만 수집하는 기조였다. 하지만 이제 더많은 데이터를 훨씬 저렴한 비용으로 저장하고 처리할 수 있으므로 완전히 쓸모없다고 판단하지 않는 한, 최대한 모든 데이터를 저장하는 새로운 정책을 수립해야 한다.
둘째, 중간 데이터를 저장하는 데이터 변환 파이프라인을 구축해 데이터 분석을 효과적으로 지원하고 데이터를 찾아 헤매는 데이터 과학자의 고충을 해결할 수 있다. 또한 데이터 변환 파이프라인에서 데이터 흐름을 손쉽게 추적할 수 있어서 데이터 과학자가 데이터 저변의 가정을 더 잘 이해할 수 있으며, 변환된 데이터를 어쩔 수 없이 삭제하는 경우에도 다시 복구할 수 있다. 이는 모든 데이터 파이프라인의 첫 번째 변환이 항상 항등 변환 이어야 함을 의미한다. 다시 말해, 첫 번째 단계에서는 데이터를 원시 형태 그대로 플랫폼에 저장해야 한다. 그런 다음 여러 팀이 공동으로 사용하는 데이터 변환 과정을 데이터 정제 작업의 일부로 저장해나가야 한다. 이렇게 저장한 변환 과정의 트리는 데이터의 계보로 보관되며, 데이터 과학자가 기업의 다양한 데이터를 이해하는 데 도움이 된다.
마지막으로 데이터가 제공하는 구체화 뷰를 유지하며 데이터에 대한 이해를 돕는 시스템에서 한 걸음 더 나아가, 시스템이 중간 데이터나 임시 데이터를 더 오래 유지하는 유연성까지 갖춘다면 하둡 플랫폼을 더욱 편리하게 활용할 수 있다. 중간 데이터가 반드시 데이터 과학자의 시야나 흥미를 넘어선 데이터일 필요는 없지만, 데이터의 여러 스냅샷을 유지하는 정책은 많은 작업을 매우 단순하게 만들어준다.

3.4.2 스키마 온리드¶

관계형 데이터베이스와 연동된 기존 시스템에서는 RDBMS에 데이터를 배치하기에 앞서 데이터의 스키마를 완벽하게 확정하는 데 모든 노력을 집중했다.(이를 스키마 온 라이트라고 한다). 데이터 스키마를 확정하려면 시스템 성능과 데이터 사용 패턴 등의 여러 사항을 사전에 고려해야 했고, 여기에는 엔지니어링팀을 포함해 데이터 과학팀, 분석팀, 그 외 수많은 팀의 이해관계가 얽혀 있었다. 특히 데이터가 매우 복잡한 경우에는 데이터 스키마 합의에 상당한 시간이 소요되어 데이터 입수 및 분석 작업이 지연되는 결과를 초래했다.
반면 하둡과 하둡 생태계의 소프트웨어는 NoSQL 시스텝과 유사한 스키마 온 리드 모델을 지향한다. 스키마 온 리드는 이미 입수된 데이터가 실행 시점에 해석됨을 의미한다.(하이브,피그, 스파크SQL의 경우에는 쿼리 시점). 스키마 온 리드에서는 데이터를 읽어 들이는 스키마가 디스크에 저장된 데이터의 실제 구조와 분리돼 있으므로 데이터 저장과 데이터 해석도 별개로 분리 할 수 있다. 예를 들어 스키마 온 리드에서는 데이터를 서로 다른 형식(예를 들면 JSON이나 XML포맷)으로 저장하면서도 이를 동일한 테이블 형식으로 읽어 들인다.
이는 데이터 입수 전에 끝마쳐야 했던 사전 작업과 협상에 소모되는 노력을 크게 줄여주며, 데이터의 입수부터 분석까지 걸리는 시간을 획기적으로 단축한다. 또한 하둡의 저비용 스토리지 특성과 맞물려 데이터 입수가 끝나자마자 데이터를 이해하고 변환하는 작업을 조직 내 각 부서에서 동시에 진행할 수 있다. 일단 데이터를 이해하면 데이터의 활용 사례와 공동으로 활용할 수 있는 구체화 뷰를 도출할 수 있다. 이 같은 과정은 훨씬 더 유기적으로 진행될 수 있으며, 사전 작업을 줄여주면서도 결과적으로 모든 이해 관계자의 각기 다른 요구 사항을 과도하게 통합한 뷰를 설계할 확률을 낮춘다. 더 나아가 스키마 온 리드에서는 동일한 원시 데이터에 여러 다른 해석을 중첩할 수도 있다.

Note : 스키마 온 리드에는 통합 테이블이 필요 없다.¶

기존 데이터 웨어하우스에서는 다양한 요구 사항에 부합하기 위해 거대한 통합 테이블을 구축하고 관리해야 했다. 이통합 테이블이 완성되기 전까지는 제대로 된 데이터 분석을 시작할 수 없었고, 완성된 뒤에도 요구 사항과 상황의 변화로 거대한 통합 테이블과 복잡하게 얽힌 데이터 파이프라인을 수정하는 일도 잦았다. 반면, 하둡에서는 통합 테이블을 만들 필요 없이 각각의 활용 사례를 위한 별도의 구체화 뷰를 만들 수 있을 만큼 스토리지가 넉넉하다.

3.4.3 비정형 데이터와 반정형 데이터¶

최근 대부분의 데이터 웨어하우스는 해석할 수 없는 데이터를 저장해서는 안 된다는 원칙이 있다. 이런 원칙이 만들어진 배경에는 스토리지가 비싸다는 문제와 읽기/쓰기 스키마가 강하게 엮여 있다는 한계가 일부 깔려 있다. 하지만 비정형 데이터나 반정형 데이터는 대개 규모가 방대하고 대부분의 경우 해석이 간단하지 않다. 이 데이터는 보통 텍스트나 로그 데이터 형식으로 저장되며, 데이터 입수 시점에서 모든 이해 관계자가 합의한 스키마 구조에 맞춰 데이터를 해석하기는 매우 어렵다. 그러나 보니 지금까지는 비정형 데이터와 바정형 데이터를 버리는 경우가 일반적이었다. 데이터를 먼저 원시 형태로 저장하고 데이터를 이해한 다음에 변환 파이프라인을 구축하는 하둡의 철학은 저비용 스토리지와 맞물려 비정형 및 반정형 데이터를 입수하기 위해 넘어야 했던 전통적인 장벽을 상당 부분 허물었다. 데이터를 일단 하둡에 가져온 다음, 데이터의 긴급성과 가치에 따라 즉시 또는 나중에 분석할 수 있고 언제든지 분석가가 원하는 시점에 변환해 기존 데이터셋을 보강할 수도 있다
비정형 및 반정형 데이터가 전통적인 방식으로 입수되던 시절에는 데이터를 저장하기 전에 정형 데이터로 변환해야 했다. 이 과정에서 변환 작업의 오류나 실수로 데이터를 일부 다시 입수해야 하거나 지금까지 처리한 모든 데이터를 처음부터 다시 입수해야 하는 불상사가 벌어지기도 했다.>
하둡은 데이터를 분산 컴퓨팅 환경에 저장하므로 비정형 및 반정형 데이터의 정제 작업 중 생기는 오류나 실수를 교정할 수 있으며, 데이터를 선형 시간안에 다시 입수할 수도 있다. 물론 오류가 발생해서는 안 되지만 비상식적인 비용을 들이지 않고도 오류를 수정할 수 있다면 불행 중 다행이라고 할 수 있다.

3.4.4 다양한 언어 지원¶

지금까지 하둡(하이브, 피그, 스파크 등)의 스크립트 언어에 대해서 소개했지만, 하둡의 또 다른 장점은 자바 이외의 다양한 언어와도 연동할 수 있다는 것이다. 데이터 과학자마다 주로 활용하는 데이터 과학 도구가 다르며 당면한 문제마다 다른 언어를 사용하기도 한다. 데이터 과학자들의 대체적인 견해는'상황에 맞는 도구를 쓴다'는 것이다.
하둡은 주로 자바로 개발돼서 자바와 JVM 언어를 기본으로 지원한다. 하지만 스트리밍 시스템을 사용하면 더 저수준에서 모든 형태의 실행 파일을 하둡과 연동할 수 있다. 스트리밍 기능은 표준 유닉스 방식인 stdin과 srdout을 통해 별도의 언어로 구현한 매퍼 및 리듀서를 하둡과 연결한다. 이보다 한 단계 상위 수준의 연동 방법은 스크립트 언어를 사용하는 하이브와 피그의 사용자 정의 함수를 JVM 언어(자이썬, 자바스크립트, 스칼라, 클로저 등)로 개발하는 것이다. 하이브와 피그가 지원하는 스트리밍 UDF 형식을 사용하면 JVM 외의 언어로도 사용자 정의 함수를 개발할 수 있다. 또한 스파크 API는 스칼라, 자바, 파이썬을 지원한다.
다양한 시스템을 선택할 수 있는 자유에 익숙한 사람들이 점점 더 하둡에 관심을 보이면서, 더 많은 확장 포인트와 연동 기능이 개발된다. 특히 여러 유형의 분산 커뮤니케이션 프레임워크를 지원하는 YARN의 등장은 이러한 추세를 더욱 가속화시켰다.YARN이 등장하기 전의 하둡 연동 사례에는 하둡의 데이터를 다른 외부 독점 시스템으로 가져가서 분석하는 경우가 많아지만, YARN에서는 다양한 분석 시스템을 하둡 플랫폼에서 실행할 수 있다.
이미 SAS나 SAP 같은 독점 솔루션 업체는 자사 시스템을 하둡 플랫폼에서도 실행하게 개발했다. 마이크로소프트도 Revolution Analytics 사를 인수해 R to Hadoop 같은 오픈 소스 시스템과의 직접 연동 기능을 개발한다. 데이터 센터 내 하둡의 존재감이 커질수록 더욱 많은 사람이 하둡과 긴밀하게 협업할 것이다.

3.4.5 견고한 스케줄링과 리소스 관리¶

앞서 몇 차례 하둡을 분석 애플리케이션 운영 체제에 비유했던 내용을 되짚어 보면 하둡의 화룡점정은 결국 리소스 관리와 스케줄링 기능임을 알 수 있다. 현대 운영 체제의 주 역할 중 하나는 CPU, 메모리, 디스크 리소스가 한정된 상황에서도 많은 사용자가 동시에 애플리케이션을 실행하게 지원하는 것이다. 운영 체제와 마찬가지로 하둡 역시 리소스가 한정된 단일 하둡 클러스터에서 여러 애플리케이션을 동시에 지원해야 한다.
여기서 하둡의 리소스란 클리스터가 보유한 CPU와 메모리 리소스를 말한다. 데이터 과학자는 하둡의 리소스 관리와 스케줄링 기능을 사용해 자신의 알고리즘을 어떻게 클러스터에 분산할지 결정할 수 있다. 예를 들어 어떤 알고리즘은 대량의 데이터를 처리할 많은 메모리를 요구하는 반면, 어떤 알고리즘은 제한된 메모리와 적은 양의 데이터만으로도 충분히 실행할 수 있다. 이처럼 다양한 유형의 작업 부하를 한 클러스터만으로 감당하면서, 클러스터의 리소스를 더 효율적으로 활용 할 수 있을 뿐만 아니라 부서나 그룹이 가진 모든 컴퓨팅 리소스를 하나로 모아 강력한 성능을 지닌 대규모 단일 클러스터를 구성할 수도 있다.
또한 하둡은 애플리케이션 유형별로 독립적인 연산 리소스를 할당할 수 있다. 애플리케이션의 그룹이나 유형별로 클러스터의 스케줄링과 리소스를 관리할 수 있어서 서비스 수준 협약은 약하지만 작업 우선순위가 높고 특정 기간 안에 반드시 실행이 완료돼야 하는 데이터 과학 실험도 동일한 클러스터로 실행할 수 있다.

Note : YARN의 리소스 할당¶

YARN의 유형별 리소스 할당 기능의 자세한 내용은 다음 클라우데라의 자료를 참고하자.

Untangling Apache Hadoop YARN, Part 3: Scheduler Concepts
https://blog.cloudera.com/blog/2016/01/untangling-apache-hadoop-yarn-part-3/
Untangling Apache Hadoop YARN,Part 4: Fair Scheduler Queue Basice
https://blog.cloudera.com/blog/2016/06/untangling-apache-hadoop-yarn-part-4-fair-scheduler-queue-basice/

3.4.6 분산 시스템 추상화 레벨¶

얼론에서 하둡에 관해 이야기하는 내용을 보면, 하둡이 페타바이트급 데이터에 SQL을 분산 실행할수 있는 시스템이라는 인상을 받을 것이다. 하지만 진실은 언제나 더 흥미롭고 복잡하기 마련이다. 데이터 과학자는 하둡이 제공하는 여러 추상화 레벨로 분석 애플리케이션을 구축하고 데이터를 분석할 수 있다. 먼저 가장 낮은 추상화 레벨로, 맵리듀스 같은 원시 분석 모델을 사용할 수 있다. 구축하고자 하는 애플리케이션이나 질의가 비교적 단순하고 낮은 추상화 레벨과 잘 맞는다면 원시 분석 모델이 유용할 수 있다. 예를 들어 어떤 질의를 단일 맵리듀스 작업으로 바로 변환할 수있다면 맵리듀스를 사용하는 것이 좋다. 원시 분석 모델은 대체적으로 실행 속도가 빠르다는 장점이 있지만 스칼라나 자바와 같은 범용 프로그래밍 언어를 사용해 저수준 모듈과 연동하는 다소 복잡한 작업이 필요하다는 단점도 있다.
그드음 추상화 레벨은 사용자의 질의를 복수의 맵리듀스 작업이나 테즈 플로우 같은 기본 연산 단위로 분해하는 방식이지만, 여전히 프로그래밍이 필요하다. 이 레벨의 장점으로는 질의의 표현력이 더 좋다는 점과 더욱 강력하고 고도화된 함수를 기본으로 제공한다는 점을 들 수 있다. 예를 들어 관꼐 함수와 집합 함수를 기본으로 제공하는 스파크가 여기에 해당한다. 반면 단점은 복잡한 함수를 사용할수록 함수의 성능적 특성을 예상하기 어려워 사용자는 이러한 함수를 사요했을 때 발생할 결과를 잘 이해해야 한다는 것이다. 또다른 단점은 여전히 스칼라나 자바 같은 복잡한 범용 프로그래밍 언어를 사용할 줄 알아야 한다는 것이다.

Note : 스파크의 성능 특성¶

특히 스파크는 분산 처리에 관련된 설정에 따라 계산 성능이 크게 좌우된다. 따라서, 스파크를 더 효율적으로 사용하려면 파티션(partition),병렬 설정(parallelism), 브로드캐스트 변수, 메모리 캐시 등의 성능 최적화 기법을 잘 이해해야 한다. 스파크의 성능 튜닝에 관한 더 자세한 내용은 다음 클라우데라 자료를 참조하자.

아파치 스파크 작업을 튜닝하는 법 - 1부
https://blog.cloudear.com/blog/2015/03/how-to-tune-your-apache-spark-jobs-part-1/

한 단계 더 높은 추상화로, 특정 데이터 사용 패턴에 특화된 스크립트 언어를 사용할 수 있다. 하둡 스크립트 언어로는 ETL 작업용 피그나 관계 및 정형 쿼리용 SQL(하이브 SQL 또는 스파크 SQL)언어가 있다. 스크립트 언어는 일반적으로 배우기 쉽다는 장점이 있지만 분석 작업이 스크립트 언어의 데이터 사용 패턴과 크게 다를 경우 스크립트 언어를 작업에 아예 사용할 수 없거나, 억지로 사용하더라도 작업의 연산 성능을 악화한다는 단점도 있다.
가장 높은 레벨의 추상화인 도메인 특화 애플리케이션은 오직 한 질문에 최선을 다해 답하는 것을 목표로 한다. 이러한 애플리케이션들은 대부분 사용자가 바로 활용할 수 있는 차트나 리포트를 생성한다. 이에 상응하는 단점은 정해진 매개변수만 리포트에 입력할 수 있으며, 이를 벗어나는 요구 사항을 수용할 수 없다는 점이다. 하지만 주어진 구체적인 요구 사항에 맞춰 애플리케이션을 최적화할 수 있어서 리포트의 실행 속도가 빠르고 리포트에 사용자가 요구하는 모든 기능을 탑재 할 수 있다.

3.4.7 대규모 데이터에 기반한 모델 구축¶

지금까지 소개한 하둡의 훌륭한 기능은 데이터 과학자와 데이터 애플리케이션 개발자, 하둡 클러스터를 관리하는 비즈니스의 공통 관심사에 초점을 맞추었다. 하지만 데이터 과학자의 주요 관심사는 역시 하둡을 활용한 대규모 모델 구축이다.
기본 통계 모델 또는 머신 러닝 모델을 구축하는 작업은 데이터의 집계, 샘플링, 분석으로 데이터를 탐색하는 과정이다. 하둡은 이러한 과정에 분명이 도움이 된다.
지도 학습 모델은 관측값의 특징 벤터와 목표 변수로 구성된 학습 예제를 알고리즘에 주입해 아직 결과가 알려지지 않은 미래의 데이터에 적용할 수 있는 모델을 구축한다. 지도 학습 모델의 구축과정을 크게'데이터 준비 및 특징 벡터 추출'과 '모델 훈련'단계로 나눌 수 있다.
데이터 준비 단계는 ETL 과정과 마찬가지로 데이터를 병합, 보충, 집계, 변환해 모델 훈련 단계에 전달할 특징 행렬을 만드는 단계다. 이러한 작업에는 피그나 스파크 같은 하둡 도구가 적합하다.
모델 훈련 단계는 사용ㅇ하는 머신 러닝 알고리즘에 따라 하둡 도구의 선택이 달라질 수 있다. 스파크 MLlib는 분산 병렬 처리 방식으로 구현된 견고한 머신 러닝 라이브러리(예를 들면 일반 선형 모델, 의사 결정 트리, 랜덤 포레스트)를 제공해 데이터 과학자가 하둡 클러스터를 이용하게 지원한다.
사용하려는 알고리즘이 병렬 방식으로 구현될 수 없거나 스파크 MLlib에서 아직 지원하지 않더라도 여전히 하둡을 사용할 수 있는 ㄴ몇가지 방법이 있다. 우선 하둡으로 학습에 사용할 데이터를 샘플링할 수 있다. 또한 다수의 샘플 데이터셋을 추출해 여러 모델을 병렬로 학습시키거나 초매개변수의 최적화를 병렬로 진행할 수도 있다.3부 곳곳에서 더 자세히 설명하겠지만, 여기서는 하둡이 어떻게 모델 구축 단계를 지원할 수 있는 지를 간략하게 살펴봤다.

Note : 초매개변수¶

머신 러닝에서는 매개변수(parameter)와 초매개변수(hyper-parameter)라는 용어를 별도로 사용하지만 그 차이를 분명히 구분하는 공식적인 정의는 찾아보기 쉽지 않다. 역자가 생각하는 정의는 다음과 같다. 매개변수는 데이터를 기반으로 최적화된 머신 러닝 모델의 변수(예를 들면 의사 결정 트리의 분기 조건)로, 모델의 예측 단계에 전달되는 변수라고 생각할 수 있다. 반면, 초매개변수는 모델의 학습 단계에 전달되는 매개변수(예를 들면 서포트 벡터 머신의 regularization factor인 C)로 모델의 학습에 필요한 다양한 설정값으로 생각할 수 있다.

3.4.8 대규모 데이터 모델을 적용¶

대규모 데이터셋에 모델을 적용하거나 평가하는 작업은 병렬로 처리할 수밖에 없으므로 맵리듀스, 피그, 하이브, 스파크 같은 고수준 추상화가 적합하다.
일반적으로 모델의 적용 방안에는 두 가지가 있다. 첫 번째는 모델을 대규모 데이터셋에 일괄로 적용하는 방안이며 두 번째는 실시간 애플리케이션에서 흐르는 데이터 플로우에 모델을 적용하는 방안이다.
모델을 일괄적으로 적용하는 경우에는 작업을 하둡 클러스터로 분산시켜 빠르게 처리할 수 있다. 모델을 자바 언어로 실행할 수 있는 경우에는 모델을 피그나 하이브의 사용자 정의 함수로 개발하거나 스파크 또는 맵리듀스 같은 프로그래밍 인터페이스에 모델을 직접 호출할 수도 있다. 모델을 JVM으로 실행할 수 없는 경우에는 하둡 스트리밍으로 맵리듀스 작업의 매퍼와 리듀서 단계에서 모델의 실행 파일을 호출할 수 있다. 모델을 JVM으로 실행할 수 없는 경우에는 하둡 스트리밍으로 맵리듀스 작업의 매퍼와 리듀서 단계에서 모델의 실행 파일을 호출할 수 있다. 이 하둡 스트리밍 기능은 R 이나 C/C++ 또는 파이썬으로 모델을 구축한 경우 특히 유용하다. 하둡 스트리밍을 사용하면 약간의 성능 저하가 있을 수 있지만, 모델을 대규모 애플리케이션에 적용하는 이점을 고려하면 무시할 만한 수준이다.
또한 학습된 모델을 예측 모델링 마크업 언어로 내보낼 경우, 몇몇 특수한 라이브러리와 유틸리티를 이용해 하둡 안에서 PMML 모델을 사용할 수 있다. 스톱이나 스파크 스트리밍 같은 하둡의 스트리밍 프레임워크는 실시간 애프리케이션 플로우와 모델을 매끄럽게 연동하는 방법을 제공한다. 예를 들어 학습이 완료된 이상 거래 탐지 모델을 스트리밍 프레임워크에 적용해 사기로 의심되는 거래를 실시간으로 탐지할 수 있다.

3.5 요약¶

하둡 플랫폼의 역사와 진화 과정을 살펴봤다.
하둡에서 사용 가능한 HDFS, YARN, 하이브, 피그, 스파크, 스쿱, 플럼 같은 주요 데이터 처리 엔진과 데이터 과학에서 널리 사용되는 R, 파이썬 등의 모델링 도구를 살펴봤다.
데이터 과학자가 하둡을 즐겨 사용하는 이유는 무엇이며, 어떻게 데이터 과학자에게 하둡의 여러 특성(저렴한 스토리지와 스키마 온 리드, 정형 및 비정형 처리 기능 등)을 효율적이고 생산적으로 지원할 수 있는지 논의했다.

출처 : "하둡과 스파크를 활용한 실용 데이터과학"