빅데이터 플랫폼과 하둡 분산 처리

앞 두 노트가 빅데이터가 무엇이고 왜 값을 갖는가였다면, 이 노트는 그것을 실제로 담고 돌리는 기계 쪽입니다. 1과목에서 계산 비슷한 것이 나오는 거의 유일한 자리이기도 합니다 — 블록 수와 복제본 수를 세는 문항이 그렇습니다. 이름을 나열해 외우면 보기 넷이 전부 실재하는 도구라 안 갈리므로, 각 도구가 어느 계층에서 무슨 일을 하는가로 자리를 잡아 두어야 합니다.

플랫폼의 세 계층

빅데이터 플랫폼은 데이터를 수집·저장·처리·분석하는 데 필요한 것을 한 벌로 묶어 둔 환경입니다. 흔히 세 계층으로 그립니다.

가운데 계층이 있는 이유가 핵심입니다. 서버가 백 대여도 「이 작업을 어느 대에서 언제 돌릴지」를 정해 주는 것이 없으면 쓸 수 없습니다. 뒤에 나올 YARN이 정확히 그 자리에 있는 소프트웨어입니다.

병렬 컴퓨팅과 분산 컴퓨팅

바탕이 되는 두 낱말을 먼저 가릅니다. 병렬 컴퓨팅은 한 대 안의 여러 프로세서가 메모리를 공유하며 한 문제를 나눠 푸는 것이고, 분산 컴퓨팅은 네트워크로 이어진 여러 대가 각자의 메모리를 가지고 나눠 푸는 것입니다.

빅데이터가 분산 쪽을 고른 이유는 단순합니다 — 한 대를 키우는 데는 한계와 값이 있고, 싼 기계를 여러 대 늘리는 데는 없기 때문입니다. 대신 한 대쯤은 늘 고장 나 있다는 전제를 받아들여야 하고, 하둡의 설계 전체가 그 전제 위에 서 있습니다.

HDFS — 쪼개서 담고 세 벌씩 둔다

하둡(Hadoop)은 대용량 데이터를 여러 대에 나눠 저장하고 처리하는 오픈소스 프레임워크이고, 그 저장 담당이 HDFS(Hadoop Distributed File System)입니다.

HDFS는 파일을 통째로 두지 않고 블록으로 쪼갭니다. 블록 크기는 기본 128MB이고(하둡 1.x 시절에는 64MB였습니다) 조각마다 서로 다른 기계에 흩어져 저장됩니다. 그리고 각 블록을 복제해 여러 벌 둡니다 — 기본 복제 계수는 3입니다.

역할을 맡은 노드가 둘입니다.

네임노드는 데이터 자체를 갖고 있지 않습니다. 그래서 네임노드가 죽으면 데이터는 멀쩡한데 어디에 무엇이 있는지를 잃어 파일을 못 읽습니다. 하둡의 단일 장애점이 여기라는 것이 자주 나오는 문항입니다.

블록 수를 세는 계산은 이렇습니다. 500MB 파일을 128MB 블록으로 담으면 128·128·128·116으로 네 블록이 나오고, 복제 계수가 3이면 클러스터에 실제로 저장되는 블록은 $4 \times 3 = 12$ 개, 차지하는 용량은 약 $500 \times 3 = 1{,}500$ MB입니다. 마지막 블록은 남은 만큼만 쓰므로 128MB를 다 채우지 않습니다.

맵리듀스 — map, shuffle, reduce

맵리듀스(MapReduce)는 흩어진 데이터를 각자 자리에서 처리하고 그 결과를 모으는 처리 모델입니다. 단계가 셋입니다.

1. map — 각 데이터노드가 자기가 가진 조각을 읽어 키-값 쌍을 뱉는다.
2. shuffle (과 sort) — 같은 키끼리 한 리듀서로 모이도록 네트워크로 옮기고 정렬한다.
3. reduce — 키마다 모인 값들을 합쳐 최종 결과를 낸다.

단어 세기로 보면 한눈에 들어옵니다.

from collections import defaultdict

def mapper(line):                          # 1. map
    return [(w, 1) for w in line.split()]

def shuffle(pairs):                        # 2. shuffle — 같은 키끼리 모은다
    grouped = defaultdict(list)
    for key, value in pairs:
        grouped[key].append(value)
    return grouped

def reducer(key, values):                  # 3. reduce
    return key, sum(values)

lines = ["데이터 분석 데이터", "분석 기획"]
pairs = [p for line in lines for p in mapper(line)]
result = dict(reducer(k, v) for k, v in shuffle(pairs).items())
print(result)   # {'데이터': 2, '분석': 2, '기획': 1}

가운데 shuffle이 유일하게 네트워크로 데이터가 크게 움직이는 단계라 맵리듀스에서 가장 느린 자리입니다. 성능을 묻는 문항의 답이 대개 여기로 옵니다.

그리고 맵리듀스의 근본 아이디어는 「데이터를 계산이 있는 곳으로 옮긴다」의 반대입니다 — 계산을 데이터가 있는 곳으로 보냅니다. 수백 GB를 네트워크로 끌어오는 것보다 코드 몇 KB를 보내는 편이 싸기 때문입니다.

YARN — 누가 어느 자원을 쓸지 정한다

하둡 1.x에서는 맵리듀스가 자원 관리까지 겸했습니다. 그래서 맵리듀스가 아닌 처리 방식은 클러스터에 들어올 수 없었고, 작업을 배분하는 JobTracker 한 곳에 부하가 몰렸습니다. 하둡 2.x가 그 일을 떼어 낸 것이 YARN(Yet Another Resource Negotiator)입니다.

이 분리 덕분에 같은 클러스터 위에서 맵리듀스와 스파크가 나란히 돌 수 있게 됐습니다. YARN이 앞에서 말한 플랫폼 계층의 자리를 차지한 것입니다.

생태계의 이름들

하둡 위에 얹혀 각자 다른 일을 하는 도구들입니다. 갈리는 기준을 오른쪽 열에 적었습니다.

가장 자주 틀리는 짝이 HBase와 Hive입니다. 둘 다 하둡 위에 있지만 Hive는 대용량을 훑는 배치 질의용이라 응답이 초 단위 아래로 안 내려가고, HBase는 키로 한 행을 집어 오는 실시간 조회용입니다. 「밀리초 안에 특정 사용자 프로필을 읽어야 한다」가 나오면 HBase입니다.

스파크 — 디스크를 덜 밟는다

맵리듀스의 약점은 단계마다 중간 결과를 디스크에 썼다가 다시 읽는다는 것입니다. 한 번 훑고 끝나는 작업은 괜찮지만, 같은 데이터를 수십 번 반복해 도는 기계학습에서는 그 왕복이 시간의 대부분을 먹습니다.

스파크(Spark)는 중간 결과를 메모리에 두고 다음 단계로 넘깁니다. 이것이 인메모리 처리이고, 반복이 많은 작업에서 맵리듀스보다 훨씬 빠른 이유가 여기 하나입니다. 스파크는 데이터를 RDD(Resilient Distributed Dataset)라는 단위로 다루는데, 이는 여러 노드에 흩어져 있으면서 어떻게 만들어졌는지의 계보를 함께 들고 있는 읽기 전용 데이터 묶음입니다. 노드가 죽어도 그 계보를 따라 다시 계산하면 복구되므로, 메모리에 두면서도 고장을 견딜 수 있습니다.

스파크가 하둡을 대체했다고 읽으면 안 됩니다. 스파크는 처리 엔진이고 저장은 여전히 HDFS나 클라우드 스토리지가 맡으며, 자원 관리도 YARN에 얹어 쓰는 경우가 많습니다. 문항이 「하둡을 완전히 대체한다」고 적어 두면 그것이 오답 표시입니다.

연습 문제

1. HDFS의 네임노드에 대한 설명으로 옳은 것은?
   ① 블록의 실제 데이터를 저장한다
   ② 파일과 블록의 위치 정보인 메타데이터를 관리한다
   ③ 맵 태스크를 실행한다
   ④ 클러스터의 CPU와 메모리를 응용에 배분한다

   ②. 실제 블록은 데이터노드가 갖습니다. ④는 YARN 리소스 매니저의 일입니다.
2. 블록 크기가 128MB, 복제 계수가 3인 HDFS에 500MB 파일을 저장했습니다. 클러스터에 실제로 저장되는 블록의 총 개수는?
   ① 4개
   ② 8개
   ③ 12개
   ④ 15개

   ③. 500 ÷ 128 = 3.9…이므로 블록은 128·128·128·116의 네 개이고, 복제 계수가 3이니 4 × 3 = 12개입니다. 마지막 블록은 116MB만 차지합니다.
3. 맵리듀스에서 네트워크 전송이 가장 크게 일어나 병목이 되기 쉬운 단계는?
   ① map
   ② shuffle
   ③ reduce
   ④ 최종 출력 쓰기

   ②. map은 각 노드가 자기 데이터를 제자리에서 읽고, reduce는 이미 모인 값을 합칩니다. 같은 키를 한 리듀서로 옮기는 shuffle만 노드 사이로 데이터를 크게 움직입니다.
4. 하둡 2.x에서 YARN을 도입해 얻은 것으로 가장 알맞은 것은?
   ① 맵리듀스 프로그램을 SQL 문으로 작성할 수 있게 됐다
   ② 자원 관리가 처리 모델에서 분리되어 맵리듀스 외의 엔진도 같은 클러스터에서 돌 수 있게 됐다
   ③ 네임노드가 블록 데이터를 직접 저장하게 됐다
   ④ 복제 계수가 3에서 1로 줄어 저장 공간을 아끼게 됐다

   ②. 1.x에서는 맵리듀스가 자원 관리를 겸해 다른 엔진이 들어올 자리가 없었습니다. 그 일을 떼어 낸 것이 YARN이고, 스파크가 같은 클러스터에 얹히는 것도 이 덕분입니다.
5. 사용자 프로필을 사용자 ID로 밀리초 안에 읽고 쓰는 기능을 하둡 생태계에서 구현하려 합니다. 가장 알맞은 것은?
   ① Hive
   ② Pig
   ③ HBase
   ④ Sqoop

   ③. 키로 한 행을 집어 오는 실시간 조회·갱신이 HBase의 자리입니다. Hive는 대용량을 훑는 배치 질의용이라 응답이 그만큼 안 내려가고, Sqoop은 RDBMS와 HDFS 사이의 이관 도구입니다.
6. 스파크가 맵리듀스보다 반복 작업에서 빠른 가장 큰 이유는?
   ① 데이터를 압축해 저장하기 때문
   ② 단계 사이의 중간 결과를 디스크 대신 메모리에 두기 때문
   ③ HDFS를 쓰지 않고 자체 파일 시스템을 쓰기 때문
   ④ 복제본을 두지 않아 쓰기가 빠르기 때문

   ②. 맵리듀스는 단계마다 중간 결과를 디스크에 썼다가 다시 읽습니다. 스파크는 저장을 여전히 HDFS 같은 곳에 맡기므로 ③은 틀립니다.
7. 병렬 컴퓨팅과 분산 컴퓨팅을 가르는 기준으로 가장 알맞은 것은?
   ① 처리하는 데이터의 크기
   ② 메모리를 공유하는가, 각자 가지고 네트워크로 통신하는가
   ③ 오픈소스인가 상용인가
   ④ 실시간인가 배치인가

   ②. 한 대 안에서 메모리를 공유하면 병렬, 네트워크로 이어진 여러 대가 각자의 메모리를 가지면 분산입니다. 그래서 분산 쪽은 대수를 늘려 확장하고 한 대가 서도 나머지가 돕니다.

이 절의 이름들을 외울 때는 계층과 역할의 두 칸을 함께 적어 두는 편이 낫습니다. 저장인가 처리인가 조율인가, 그리고 배치인가 실시간인가 — 이 둘만 잡히면 Hive와 HBase, YARN과 Zookeeper처럼 함께 보기에 오르는 짝이 갈립니다.