Scale Up vs Scale Out

빅데이터를 이야기하면 빼놓을 수 없는 아키텍처이다. 간단하게 단일서버내에서 용량을 추가하는 방식을 Scale Up, 노드를 추가하여 확장하는 방식을 Scale Out으로 볼 수 있다. 서버급 장비는 비싸기도 엄청 비싸다. 하지만 데스크탑 서버급을 하나 붙이는 정도라면? 그렇게 부담스럽지 않다. 이렇게 Scale Out방식을 선택해서 출발하게 된것이 바로 빅데이터 처리기술의 대명사 분산파일시스템과 맵리듀스 이다.

Hadoop

과거에는 기가, 테라급의 데이터면 빅데이터라고 볼 수 있었지만 이제는 아니다. 페타바이트를 처리해야하는 상황이다. 하둡은 이론상 6000대 이상 클러스터 구성이 가능하다고 한다. 1테라 하드를 가진 컴퓨터 6000대를 연결하면 6페타바이트 확보가 가능하다. 또한 6000대의 컴퓨터가 병렬로 연산한다면? 슈퍼컴퓨터 뺨치는 성능이 나온다. 야후는 최근 4000노드를 이용하여 단일클러스터를 구상했고 디스크공간이 16페타라고 한다. -_-;; 대단하다

1. HDFS

구글분산파일시스템을 보고 구현한 오픈소스가 바로 HDFS이다. 기존 대용량 파일시스템과의 가장 큰 차이점은 저사양서버를 이용해 스토리지를 구성할 수 있다. HDFS에 저장하는 데이터는 물리적으로 분산된 서버의 로컬디스크에 저장되며 HDFS에서 제공하는 API를 이용해서 처리한다.

HDFS는 다음의 네 가지 목표를 가지고 설계되었다.

장애복구

데이터를 저장할 때 복제 데이터를 같이 저장

스트리밍 방식의 데이터 접근

데이터처리량 중점의 배치작업에 적합하게 설계됨

대용량 데이터 저장

하나의 파일이 테라바이트 이상의 크기를 저장할 수 있음

데이터 무결성

저장데이터는 수정이 불가능하고 읽기만 가능

HDFS가 기존의 모든 대용량 파일시스템을 완전히 대체할 수는 없다. 트랜잭션 처리가 중요한 경우에는 적합하지 않으며, 대용량 데이터 저장 및 배치처리시 권장된다.

또한 HDFS의 경우 데이터 복재와 분산저장이 이루어지기 때문에 저장공간에 대해서 별도 RAID구성이 필요없다.

2. Map Reduce

분석로직에 대해서 Map과 Reduce만 개발자가 적절히 개발하면, 데이터에 대한 분산과 병렬처리는 프레임워크가 처리하게 된다. 네임노드에서 신규 잡이 제출되면 Job Tracker에 의해서 작업이 추적되며 이는 다시 태스크로 잘게 쪼개져서 각 데이터노드로 전달된다. 데이터노드에서는 입력데이터를 스플릿으로 나누어 각 맵퍼가 실행되며, 맵퍼출력결과는 정렬과 병합을 거쳐서 리듀서로 전달된다. 리듀서는 특별히 지정되지 않으면 1개가 동작하며 출력데이터가 다시 HDFS에 저장이 된다. 이러한 방식의 네임노드가 모든 잡을 추적해야한다는 부담이 생겨서 2.0 에서는 YARN을 통해 개선된 아키텍처가 적용된다.


3. Common, YARN, 기타

Hadoop Common의 경우 공통성 유틸리티를 모은 것이라고 생각하면 편리하다.

Hadoop YARN 은 클러스터상에서 자원관리와 Job 스케쥴링을 위한 프레임워크다.

그외에 provisioning을 위한 Ambari나 Hadoop Data처리를 빠르게 할 수 있는 Spark, 쿼리형태로 분산처리를 위한 Hive등이 Hadoop 연관 프로젝트로 등록되어 있다.


Hadoop 의 성능

이러한 구조를 바탕으로 놀라운 대용량 처리성능을 보여주고 있다. 2009년에 1TB를 62초에 정렬했다고 한다.. (3800클러스터로) DBMS에서 1TB 정렬조회하면 아마 다운될거다;;

Hadoop 의 단점

굉장히 멋지고 훌륭한 기술이지만 단점도 있다. ScaleOut의 단점은 복잡성이라고 이야기를 하는데, 하둡 역시 복잡하다. EndUser는 MapReduce에 접근하기 어렵고 설령 개발자라 해도 설계/개발에 상당한 시간을 투자해야 한다. 그런데 또 이러한 단점을 극복하기 위해서 MapReduce를 쉽게 할 수 있도록 Pig, Hive가 나타나서 이제는 단점이라고 보기도 어렵다.

또 하나의 단점은 오픈소스기반이다. 발전속도도 빠르고 구성하는 컴포넌트도 다양하다. 이 말은 바꿔보면 하나로 조합하기가 힘들다는 점이다. 각 컴포넌트마다 설정해야할 내용도 많고 컴포넌트간의 호환성도 검토해야 한다. 간신히 검토해서 한 세트를 맞춰놓으면 다음버전이 나온다.-_-;; 0.01 의 마이너 버전 업데이트임에도 불구하고 꽤나 많은 내용이 바뀌기 때문에 따라가기가 매우 버겁다는 점이다.

 

 

'BigData' 카테고리의 다른 글

Flume-Kafka-Elasticsearch 테스트  (0) 2016.03.14
Storm특징 및 Spark와의 차이점  (0) 2014.12.12
CAP 정리  (0) 2014.11.28
NoSQL  (0) 2014.11.28
BigData 정의  (0) 2014.11.28

+ Recent posts