[Hadoop] 기초

Hadoop의 등장 배경

우리는 데이터의 세상 속에 살고 있다.
데이터는 끊임 없이 생성되며, 디지털이 아닌 아날로그 데이터까지도 점점 데이터로 옮겨지고 있다.
데이터의 용량은 크기 대비 증가하고 있으며, 어차피 물리적인 크기를 늘리면 되니까 문제가 되지 않는다.
문제는 데이터를 읽는 속도이다. 처리해야 할 데이터는 점점 많아지는데 이를 처리하는 속도는 늘지 못하고 있다.
그래서 여러 개의 디스크에 병렬로 쓰고 읽으려고 한다.

이때 두 가지의 문제점이 생기는데,
1. 하드웨어가 많아질 수록 장애가 발생할 확률도 높아진다.
-> 이에 대비해서 데이터를 여러 곳에 저장한다.
2. 분할된 데이터를 어떤 식으로든 결합해야 한다. 데이터를 병합하되 정합성을 지켜야 한다.
-> 문제를 데이터를 키-값 쌍의 계산으로 변환한다.

이를 해결한 것이 하둡이며, 하둡은 확장성이 높은 저장 및 분석 플랫폼을 제공한다.

RDBMS와의 비교

	전통적인 RDBMS	맵리듀스
데이터 크기	기가바이트	페타바이트
접근 방식	대화형과 일괄 처리 방식	일괄 처리 방식
변경	여러 번 읽고 쓰기	한 번 쓰고 여러 번 읽기
트랜잭션	ACID	없음
구조	쓰기 기준 스키마	읽기 기준 스키마
무결성	높음	낮음
확장성	비선형	선형

일괄 질의 처리

Hadoop의 맵리듀스는 일괄 질의 처리기고, 전체 데이터셋을 대상으로 비정형(ad hoc) 쿼리를 수행하며 합리적인 시간 내에 그 결과를 보여주는 능력을 지니고 있다.
다만 대화형 분석에는 적합하지 않다. 보통 실행 후 수 초 이내에 결과를 받는 것은 불가능하며 따라서 오프라인 용도로 적합하다.
하지만 최초에는 일괄 처리를 위해 만들어졌으나 지금은 이를 벗어나 진화하고 있다.
대화형 SQL, 반복 처리, 스트림 처리, 검색 등 다양한 처리 패턴이 새로 생겨났다.

하둡의 일괄 처리는 RDBMS의 단점을 보완할 수 있다.
만약 데이터 접근 패턴이 탐색 위주라면 데이터셋의 커다란 부분을 읽거나 쓰는 작업은 전송 속도에 좌우되는 스트리밍 조작보다 더 오래 걸릴 것이다. 다만 일부 레코드를 변경하는 작업은 전통적인 B-트리가 적합하다. 많은 부분을 변경할 때는 이는 데이터베이스를 재구성하기 위해 Sort/Merge를 사용해야 하므로 맵리듀스보다 효율적이지 못하다.

RDBMS는 상대적으로 작은 양의 데이터를 낮은 지연 시간에 추출하고 변경하기 위해 데이터셋을 색인하기 때문에 특정 쿼리와 데이터 변경에 적합하다. 맵리듀스는 데이터를 한 번 쓰고 여러 번 읽는 애플리케이션에 적합하지만, 관계형 데이터베이스는 지속적으로 변경되는 데이터셋에 적합하다고 할 수 있다. 참고

처리하는 데이터의 종류

하둡과 RDBMS의 다른 차이점은 데이터셋 내부에서 처리되는 구조의 양이다.
정형 데이터(structured data)는 미리 정의된 특정 스키마를 가진 데이터베이스 테이블과 같이 형식이 정의된 항목으로 구조화되어 있으며, 이는 RDBMS의 영역이다.
반정형 데이터(unstructured data)는 이에 비해 스키마가 유옇나거나 생략될 수도 있다.
비정형 데이터(unstructured data)는 어떠한 내부 구조도 없다. 하둡은 처리 시점에 데이터를 해석하도록 설계되어 있기 때문에 비정형 데이터나 반정형 데이터도 잘 처리할 수 있다.
이는 읽기 시점 스키마(schema-on-read)라고 불리는데, 유연성을 제공하고, 데이터를 불러오는 비용이 많이 드는 단계를 피할 수 있다.

정규화

RDBMS는 무결성을 유지하고 중복을 제거하기 위해 데이터베이스를 정규화한다.
정규화는 하둡에서는 문제가 되는데, 하둡은 비지역 연산으로 레코드를 읽고, 하둡의 핵심 전제는 고속의 순차적 읽기와 쓰기를 수행하는 것이기 때문이다. 따라서 정규화되지 않은 레코드셋을 처리하기가 좋다. 하지만 자주는 아니어도 하둡은 조인을 수행할 수 있다.
(하둡에선 데이터를 한 번 쓰고 여러 번 읽는다. 즉 데이터의 수정이 잘 일어나지 않는다는 뜻이다. RDBMS에서도 이런 특성을 가진 데이터베이스를 설계할 때 일부러 정규화를 진행하지 않기도 한다. 정규화를 해서 읽기 때마다 조인이 일어나면 그만큼 시간이 더 걸리기 때문이다.)

확장

하둡은 데이터의 크기에 따라 선형으로 확장된다. 데이터는 분할되고 맵과 리듀스같은 기본 함수는 분리된 파티션에서 병렬로 데이터를 처리할 수 있다. 입력 데이터의 크기가 두 배라면 작업은 두 배 느리다. 하지만 클러스터(머신)의 크기가 두 배가 된다면(= 처리하는 컴퓨터를 한 대 더 두면) 그 작업은 기존보다 더 빠르게 수행될 것이다. 일반적으로 관계형 데이터베이스의 SQL 쿼리는 그렇지 못하다.

하둡 확장이 선형적인 이유

그리드 컴퓨팅

계산 노드 배치

고성능 컴퓨팅과 그리드 컴퓨팅 커뮤니티는 서로 메시지를 전달하며 의사소통하기 위한 메시지 전달 인터페이스 (Message Passing Interface, MPI)와 같은 API를 이용하여 수년간 대규모 데이터를 처리하고 있다.
하지만 계산 중심의 작업에서는 좋은 결과를 얻지만 계산 노드들이 대용량 데이터에 접근해야 할 때는 네트워크 대역폭 때문에 병목 현상이 생기고 데이터를 다운받는 동안 계산 노드가 빈둥거리게 되는 문제가 발생한다.

하둡은 가능하면 계산 노드에 데이터를 함께 배치한다. 데이터가 로컬에 있기 때문에 접근도 빠를 수 밖에 없다. 데이터가 있는 곳에서 계산을 수행해야 한다.
하둡은 데이터 센터의 환경에서 가장 중요한 자원은 네트워크 대역폭이라는 점을 확실히 인식했다.
데이터가 이리저리 반복적으로 복사하면 네트워크 링크가 쉽게 포화 상태가 된다.
하둡은 네트워크 토폴로지를 명화갛게 모델링하는 방법으로 네트워크 대역폭을 보존한다.

프로세스 조율

대규모 분산 컴퓨팅에서 수많은 프로세스를 조율하는 것은 엄청난 과제다.
가장 어려운 점은 원격 프로세스가 실패했는지 정상인지 알 수 없을 때와 같은 부분 실패에 현명하게 대처하는 것과, 전체적인 계산의 진행을 이어가는 것이다.
맵리듀스는 실패한 태스크를 자동으로 감지하여 장애가 없는 머신에 다시 배치하도록 구현되어 있기 때문에 개발자는 실패에 대해 크게 고민하지 않아도 된다.

맵리듀스는 태스크 간의 상호 의존성이 없는 비공유(shared-nothing) 아키텍처이기 때문이다. 맵리듀스 시스템은 모든 것을 통제할 수 있다. 맵리듀스는 실패한 맵이 아닌 실패한 리듀서를 재실행하는 데 주력한다. 리듀서는 필수적인 맵의 출력을 다시 추출해야 하는데 그게 안 되면 맵을 다시 해야 하기 때문이다. (아키텍처 특성 상 리듀서만 신경 써도 맵은 알아서 재실행이 된다.)
따라서 개발자의 관점에서 보면 태스크의 실행 순서는 중요하지 않다.

MPI 프로그램은 자신의 체크포인트와 장애 복구를 명확하게 관리해야 한다.
개발자에게 더 많은 제어권을 주지만 프로그램을 작성하는 것은 그만큼 더 힘들다.
(프레임워크의 일반적인 특성)

요약

하둡은 데이터를 분산해서 처리하기 위한 오픈소스 프레임워크이다.
하둡은 데이터를 한 번 쓰고 여러 번 읽기에 적합하다.
하둡은 큰 데이터에 기반한 일괄 질의 처리에 적합하다.
하둡은 비/반정형 데이터 처리에 적합하며 정규화를 지양한다.
하둡은 계산 노드를 데이터와 같이 둔다.
하둡은 비공유 아키텍처로, 여러 태스크의 순서와 장애를 자동으로 관리해준다.