Hadoop 1.0, 2.0 비교

출처 : http://www.mund-consulting.com/Blog/Posts/hadoop-2-0-YARN-and-REEF.aspx

 출처 : http://asdtech.co/blog/%ED%95%9C%EA%B5%AD%EC%96%B4-%ED%98%84-%EC%8B%9C%EC%A0%90%EC%97%90%EC%84%9C-%ED%95%98%EB%91%A1-%ED%94%84%EB%A1%9C%EC%A0%9D%ED%8A%B8%EB%8A%94-%EB%B0%98%EB%93%9C%EC%8B%9C-%ED%95%98%EB%91%A1-2-0/?lang=kr

이 다이어그램은 하둡 1.0과 비교해서 하둡 2.0 아키텍쳐가 어떻게 변모했는 지를 보여 주고 있습니다.
그렇다면 하둡 2.0과 1.0의 가장 결정적인 차이점은 무엇일까요?
사실 세부적인 요소들이 추가되고 수정되는 부분에 집중하다 보면 도입을 위한 의사 결정에 잘못된 판단을 할 수도 있습니다.

Single Use System -> Multi Use System
가장 핵심적인 차이는 배치 처리에 특화된 시스템인가 아니면 배치, 인터랙티브, 온라인, 스트리밍과 같이 다양한 데이터 처리 형태를 지원하는 가입니다.
하둡 1.0은 가용성과 확장성이 높은 하둡 파일시스템(HDFS)과 이렇게 분산된 대량의 데이터를 읽어 들여서 하나의 결과를 도출하는 맵리듀스(MapReduce)로 이루어진 단일 용도 시스템의 성격이 큽니다.

이전에 HDFS 2.0의 진화와 로드맵에 대해서 설명을 드렸지만 기본적으로는 그 철학을 그대로 유지하고 컨셉이 변모하지는 않았습니다.
하지만 데이터 처리에 대한 부분에서 맵리듀스(MapReduce)는 다른 많은 처리 방법 중의 하나로 그 위상이 크게 변모했습니다.

그 이유는 YARN(Yet Another Resource Negotiator)라는 레이어가 HDFS와 결합했다는 것이 가장 큰 의미를 내포하고 있습니다.
YARN의 가장 핵심적인 아이디어는 하둡 1.0에서 데이터 처리를 주관하던 잡트랙커(JobTracker)의 두 가지 기능을 분리하자는 것입니다.
기존에 잡트랙커(JobTracker)는 하둡 클러스터의 리소스를 관리하는 것과 맵리듀스 잡(MapReduce Job)을 스케쥴링하고 모니터링하는 두 가지 역할을 하고 있었습니다.

이것을 하둡 클러스터의 전체적인 리소스를 관리하는 리소스 매니저(RM)와 ‘각’ 어플리케이션의 스케쥴링과 모니터링을 담당하는 어플리케이션 매스터(AM)로 나누었습니다.
그래서 하나의 RM에서 맵리듀스 AM, 스트리밍 AM, SQL AM 등 특정한 어플리케이션을 동시에 운영하도록 됐습니다.
(그래서 YARN은 ‘또 하나의 리소스 협상자’입니다. 각 어플리케이션이 써야 하는 리소스를 중앙에서 중재해 줍니다.)

이른바 “Interact with all data in multiple ways simultaneously”라는 멀티 유스 플랫폼으로 변모한 것입니다.

즉, 기업의 입장에서 일 주일에 한 번이나 혹은 한 달에 한 번 특정 데이터셋에 대한 분석 데이타를 만들어야 하는 상황이라면 하둡 1.0이 훨씬 빠르고 안정적으로 구축할 수 있으며 운영 측면에서도 버든이 없습니다.

그러나 다양한 데이터셋에 대해서 기업 환경의 변화에 맞게 유연한 환경을 구축하는 로드맵을 가져가려고 한다면 하둡 2.0으로 시작할 필요가 있습니다.
이 경우에는 하나의 클러스터에서 다양한 형태의 AM이 운영된다는 측면 때문에 각 어플리케이션이 가지는 속성들을 이해하고 이른바 ‘클러스트 리소스 튜닝’ 작업을 해서 최적화시키는 단계가 하나 더 필요하다는 점을 숙지할 필요가 있습니다.