얀(YARN), 맵리듀스의 손아귀에서 하둡을 해방하다
OSS
게시글 작성 시각 2013-11-27 18:08:39
2013년 11월 27일 (수)
ⓒ ITWorld, James Kobielus | ITWorld
처음 시장에 소개된 이후 하둡(Hadoop)은 각기 다른 오픈소스 활동들을 빅 데이터 아키텍처로 통합하는 중심축으로 역할을 해왔다.
일부는 하둡의 본질을 단순한 하둡 분산형 파일 시스템(Hadoop Distributed File System, HDFS)으로 정의하기도 하지만, H베이스(Hbase), 카산드라(Cassandra) 등 일련의 HDFS-대안 데이터베이스는 이런 주장의 설득력을 약화시키는 것이 사실이다.
최근까지 하둡은 HDFS의 발현 형태 가운데 하나인 한 개 혹은 그 이상의 대안으로, 초병렬 데이터 지속 계층에서 실행 기반을 둔 특수 작업 실행 계층의 맵리듀스(MapReduce)와 함께 존재해왔다. 하지만 최근 소개된 차세대 하둡으로 알려진 얀(Yet Another Resource Negotiator, YARN)은 하둡 환경의 맵리듀스에 대한 큰 의존성을 제거했다.
변화의 핵심적 의의는, 얀이 맵리듀스의 초기부터 확장성 및 프로세싱 속도에 제약을 안겨주는 문제점으로 제기되어 온, 단일 잡트래커(JobTracker)를 통한 배치 프로세스(batch process)로써의 실행으로 인한 작업 실행 병목 현상을 해결했다는 데 있다.
맵리듀스의 이러한 한계는 많은 개발업체들이 병목을 우회할 자체적 속도 향상 도구를 실행토록 하는 요인이 됐다(그 예로 IBM의 어댑티브 맵리듀스(Adaptive Mapreduce)를 들 수 있다).
이런 현상은 우리에게 과연 '하둡'이 여타 빅 데이터 및 애널리틱스 플랫폼, 툴과 구별되는 '스택(stack)'적 특징이 무엇인가라는 의문을 제기한다. 그리고 이에 대한 해답을 제시하는 것이 바로 얀이다.
얀은 진화하는 빅 데이터 모자이크의 근간 요소라 할 수 있다. 얀은 전통적 하둡을 데이터 관리, 애널리틱스, 교류 컴퓨팅 작업 전반의 처리를 위한 목적 부합형 플랫폼과 좀더 큰 규모의 구성 가능 맥락에 집어넣는다.
얀은 하둡을 오픈소스 활동의 본래 목적인 분산형 작업 실행 계층으로 변화시킨다. 비록 맵리듀스 API와의 하위 호환성을 유지하고, 또 맵리듀스 작업을 실행하긴 하지만, 얀 엔진은 다른 언어로 개발된 다양한 범위의 작업을 실행할 역량을 갖추고 있다.
이에 못지 않게 중요한 사실은 얀이 빅 데이터를 둘러싼 여러 아파치 오픈 소스 활동들을 하나로 엮는 역할을 할 수 있다는 점이다. 얀의 가장 큰 성과는 '맵리듀스 자체가 여러 사람에게 하둡을 통한 데이터 발굴을 가능케 하는 역할을 할 수 있게 되었다'는 것이다.
이것이 얀이 시장에 하는 약속이지만, 그 가치를 인식하기 위해서는 기존의 하둡 스택과 툴을 여기에 맞춰 재조정하는 산업의 노력이 수반돼야 할 것이다.
인포월드의 기사를 인용하자면, '아파치는, 일부 이식 과정이 요구되긴 하지만, 어떤 분산형 애플리케이션이라도 얀 상에서 구동될 수 있음을 주장한다. 이를 위해 아파치는 얀 호환 가능한 애플리케이션 목록(페이스북 등에서 이용되는 소셜-그래프 분석 시스템 아파치 지라프(Apache Giraph) 등)을 관리하고 있다. 다른 영역에서도 더 많은 변화들이 진행되고 있다.'
분면 긍정적인 흐름이지만, '일부 이식 과정이 요구된다'는 단서 조항은 간과하고 넘어가선 안될 것으로 보인다.
얀의 적합성 검사는 자신들의 분석 개발 툴의 도출 결과물을 얀에 부합하도록 복제한 개발업체들을 대상으로만 이뤄진다. 개발 언어를 얀에 복제하는 과정은 사소한 노력이 아니다.
이런 과정이 산업 전반에 걸쳐, 그리고 다양한 아파치, 혹은 여타 오픈소스 커뮤니티에서 지속적으로 발생할 수 있을까? 어느 정도까지? 이런 물음에 대한 답이 흔히 '아파치 2.0'이라 불리는 개념의 핵심 기능인 얀이 확보하게 될 시장 장악력을 결정지어 줄 것이다.
하둡 2.0이 맵리듀스의 하위 호환성을 보호하긴 하지만 얀은 맵리듀스 애플리케이션의 속도 확보를 위해 일부 조정을 요구한다는 사실을 기억하자. 이 사소하지 않은 노력은 개발자들이 이 새로운 프레임워크를 받아들이는 과정서 발목을 잡을 것으로 보인다.
또한, 빅데이터 개발의 근간이 되는 일련의 대안적 언어인 R과 대안적 플랫폼(각종 NoSQL 접근법)을 고려한다면, 하둡 1.0, 혹은 2.0이 언제까지 현재와 같은 시장 지위를 유지할 지는 의문이 가는 것이 사실이다.
일부는 하둡의 본질을 단순한 하둡 분산형 파일 시스템(Hadoop Distributed File System, HDFS)으로 정의하기도 하지만, H베이스(Hbase), 카산드라(Cassandra) 등 일련의 HDFS-대안 데이터베이스는 이런 주장의 설득력을 약화시키는 것이 사실이다.
최근까지 하둡은 HDFS의 발현 형태 가운데 하나인 한 개 혹은 그 이상의 대안으로, 초병렬 데이터 지속 계층에서 실행 기반을 둔 특수 작업 실행 계층의 맵리듀스(MapReduce)와 함께 존재해왔다. 하지만 최근 소개된 차세대 하둡으로 알려진 얀(Yet Another Resource Negotiator, YARN)은 하둡 환경의 맵리듀스에 대한 큰 의존성을 제거했다.
변화의 핵심적 의의는, 얀이 맵리듀스의 초기부터 확장성 및 프로세싱 속도에 제약을 안겨주는 문제점으로 제기되어 온, 단일 잡트래커(JobTracker)를 통한 배치 프로세스(batch process)로써의 실행으로 인한 작업 실행 병목 현상을 해결했다는 데 있다.
맵리듀스의 이러한 한계는 많은 개발업체들이 병목을 우회할 자체적 속도 향상 도구를 실행토록 하는 요인이 됐다(그 예로 IBM의 어댑티브 맵리듀스(Adaptive Mapreduce)를 들 수 있다).
이런 현상은 우리에게 과연 '하둡'이 여타 빅 데이터 및 애널리틱스 플랫폼, 툴과 구별되는 '스택(stack)'적 특징이 무엇인가라는 의문을 제기한다. 그리고 이에 대한 해답을 제시하는 것이 바로 얀이다.
얀은 진화하는 빅 데이터 모자이크의 근간 요소라 할 수 있다. 얀은 전통적 하둡을 데이터 관리, 애널리틱스, 교류 컴퓨팅 작업 전반의 처리를 위한 목적 부합형 플랫폼과 좀더 큰 규모의 구성 가능 맥락에 집어넣는다.
얀은 하둡을 오픈소스 활동의 본래 목적인 분산형 작업 실행 계층으로 변화시킨다. 비록 맵리듀스 API와의 하위 호환성을 유지하고, 또 맵리듀스 작업을 실행하긴 하지만, 얀 엔진은 다른 언어로 개발된 다양한 범위의 작업을 실행할 역량을 갖추고 있다.
이에 못지 않게 중요한 사실은 얀이 빅 데이터를 둘러싼 여러 아파치 오픈 소스 활동들을 하나로 엮는 역할을 할 수 있다는 점이다. 얀의 가장 큰 성과는 '맵리듀스 자체가 여러 사람에게 하둡을 통한 데이터 발굴을 가능케 하는 역할을 할 수 있게 되었다'는 것이다.
이것이 얀이 시장에 하는 약속이지만, 그 가치를 인식하기 위해서는 기존의 하둡 스택과 툴을 여기에 맞춰 재조정하는 산업의 노력이 수반돼야 할 것이다.
인포월드의 기사를 인용하자면, '아파치는, 일부 이식 과정이 요구되긴 하지만, 어떤 분산형 애플리케이션이라도 얀 상에서 구동될 수 있음을 주장한다. 이를 위해 아파치는 얀 호환 가능한 애플리케이션 목록(페이스북 등에서 이용되는 소셜-그래프 분석 시스템 아파치 지라프(Apache Giraph) 등)을 관리하고 있다. 다른 영역에서도 더 많은 변화들이 진행되고 있다.'
분면 긍정적인 흐름이지만, '일부 이식 과정이 요구된다'는 단서 조항은 간과하고 넘어가선 안될 것으로 보인다.
얀의 적합성 검사는 자신들의 분석 개발 툴의 도출 결과물을 얀에 부합하도록 복제한 개발업체들을 대상으로만 이뤄진다. 개발 언어를 얀에 복제하는 과정은 사소한 노력이 아니다.
이런 과정이 산업 전반에 걸쳐, 그리고 다양한 아파치, 혹은 여타 오픈소스 커뮤니티에서 지속적으로 발생할 수 있을까? 어느 정도까지? 이런 물음에 대한 답이 흔히 '아파치 2.0'이라 불리는 개념의 핵심 기능인 얀이 확보하게 될 시장 장악력을 결정지어 줄 것이다.
하둡 2.0이 맵리듀스의 하위 호환성을 보호하긴 하지만 얀은 맵리듀스 애플리케이션의 속도 확보를 위해 일부 조정을 요구한다는 사실을 기억하자. 이 사소하지 않은 노력은 개발자들이 이 새로운 프레임워크를 받아들이는 과정서 발목을 잡을 것으로 보인다.
또한, 빅데이터 개발의 근간이 되는 일련의 대안적 언어인 R과 대안적 플랫폼(각종 NoSQL 접근법)을 고려한다면, 하둡 1.0, 혹은 2.0이 언제까지 현재와 같은 시장 지위를 유지할 지는 의문이 가는 것이 사실이다.
※ 본 내용은 한국IDG(주)(http://www.itworld.co.kr)의 저작권 동의에 의해 공유되고 있습니다.
Copyright ⓒITWORLD. 무단전재 및 재배포 금지
[원문출처 : http://www.itworld.co.kr/news/84868]
번호 | 제목 | 조회수 | 작성 |
---|---|---|---|
공지 | [Open UP 활용가이드] 공개SW 활용 및 개발, 창업, 교육 "Open UP을 활용하세요" | 359011 | 2020-10-27 |
공지 | [Open UP 소개] 공개SW 개발·공유·활용 원스톱 지원 Open UP이 함께합니다 | 348838 | 2020-10-27 |
2435 | 페이팔, 자바에서 노드JS로 개발 프레임워크 교체 | 3665 | 2013-11-28 |
2434 | 초연결사회 구현 핵심기술, ‘사물인터넷(IoT)·빅데이터’ | 3558 | 2013-11-28 |
2433 | SK텔레콤, 인디 웹앱 개발자 지원 확대 | 3644 | 2013-11-27 |
2432 | “파이어폭스OS, 내년 상반기 한국어 지원” | 3819 | 2013-11-27 |
2431 | LG 스마트TV, 웹OS로 '脫구글'하나 | 3593 | 2013-11-27 |
2430 | `HTML5 융합기술포럼` 내년 출범 | 3656 | 2013-11-27 |
2429 | “공인인증서에도 웹표준 적용해야“ | 3239 | 2013-11-27 |
2428 | 얀(YARN), 맵리듀스의 손아귀에서 하둡을 해방하다 | 3465 | 2013-11-27 |
2427 | 펜타시스템, KISTI와 빅데이터 시범 분석 공동 수행 | 3593 | 2013-11-27 |
2426 | 정보융합 플랫폼 구축전략 궁금하다면… | 3431 | 2013-11-27 |
0개 댓글