Tags

기존의 어플리케이션을 하둡 YARN 기반으로 손쉽게 전환하는 방법 (Apache Slide technical preview)

This article is based on Hortonworks Partner Content and Expertise

하둡에서 YARN이 도입이 되는 것이 어떤 의미인지는 그 동안 다른 기사들을 통해서 많이 소개드리고 있습니다.
하둡 2.0 YARN의 컨셉에 대한 검토와 도입 방법
현 시점에서 하둡 2.0을 도입해야 할 필요가 있는가?
하둡 YARN 기반으로 Spark 어플리케이션을 도입하는 방법

하둡의 YARN은 하둡 클러스터의 전체 리소스를 관리하는 기능을 담당하고 각 어플리케이션은 별도로 Application Master를 통해서 관리하도록 분리시키는 방법으로 하둡 위에서 다양한 처리 방식을 지원하는 어플리케이션을 개발할 수 있는 기반을 제공합니다.

즉, 각 어플리케이션은 YARN의 리소스 매니저에게 필요한 리소스를 할당받은 이후에 어플리케이션을 실행하는 방법으로 하나의 클러스터에서 다양한 어플리케이션을 운용할 수 있는 아키텍쳐를 가능하게 했습니다.

YARN 아키텍쳐에서 현재 어떤 형태의 데이터 처리 방식이 가능한 지 다이어그램을 보겠습니다.

slider

하둡의 에코시스템을 시스템, 엔진, API라는 세 가지 틀로 단순화시키면 위의 다잉어그램에서 보는 것과 같은 형태로 파악할 수 있습니다.

하둡파일시스템의 위에 YARN이 하둡 클러스터의 리소스를 담당하고 그 위에 배치 작업인지 SQL문을 실행시키는 방식인지 아니면 스트리밍 데이터를 실시간으로 처리하는 방식인지에 따라서 일종의 플랫폼이라고 할 수 있는 세 가지 엔진이 그 위에서 돌아갑니다.

이 세 가지 엔진 중에서 물론 맵리듀스와 같은 배치 처리 엔진이나 Tez와 같이 인터랙티브 쿼리(Interactive Query)를 실행하는 부분은 소개를 드렸지만 실시간 처리에 대한 슬라이드(Slide)에 대해서는 생소할 겁니다.

그 동안 스트리밍에 대해서는 스톰(Storm)을 직접 이용하는 형태로 도입이 이루어졌지만 점차 NoSQL의 연동을 통한 실시간 처리에 대한 수요가 부각되면서 비교적 최근에 하둡 에코시스템에 도입이 되었습니다.

그 외에도 YARN의 기능을 이용하는 다양한 어플리케이션을 손쉽게 개발하기 위한 방법이 필요하다는 니즈가 커지면서 본격적으로 그 효용성이 받아들여 지고 있습니다.

아파치 슬라이드(Slide)는 한 마디로 기존에 YARN 환경을 고려하지 않고 개발된 분산 어플리케이션을 YARN 환경에서 돌아갈 수 있도록 해 주는 플랫폼입니다.

아파치 슬라이드(Slide)는 호튼웍스에서 다음 네 가지 목표에 초점을 두고 프로젝트화한 플랫폼입니다.

Simplified on-boarding of existing apps to Hadoop YARN
그 동안 기업에서 많은 분산 어플리케이션을 개발해 왔는 데 이러한 어플리케이션을 거의 코드를 재수정하지 않고도 YARN에서 운용할 수 있도록 해 줍니다.

Full capabilities of a YARN application
아파치 슬라이드(Slide)는 어플리케이션이 론칭되고 모니터링하고 데이터 처리 수요에 따라 하둡 클러스터에서 확장되는 등의 많은 업무를 처리하는 플랫폼을 제공하여 분산 어플리케이션을 개발하는 업무에 집중할 수 있는 장점이 있습니다.

Automated lifecycle management
아파치 슬라이드(Slide)는 YARN상의 어플리케이션을 암바리와 연동하여 관리할 수 있는 옵션을 제공합니다.

호튼웍스에서 HBase, Accumulo, Storm의 세 가지에 대해서 슬라이드와 연동해서 운영할 수 있는 샘플을 제공하고 있으니 자세한 사항은 이 부분을 참조해 주시기 바랍니다.

기존의 분산 어플리케이션을 슬라이드를 이용해서 연동하기 위한 방법

이 링크에서 실제로 YARN에서 돌아가는 세 가지 어플리케이션의 버전을 직접 다운로드할 수 있습니다.

기존에 기업들이 개발해 온 많은 데이터 처리 어플리케이션을 하둡 위에서 운용하기 위한 부분은 아주 중요한 영역이지만 많은 노력이 필요로 합니다.

아직은 인큐베이팅 프로젝트이지만 슬라이드(Slide)가 가진 가능성은 아주 크다고 생각합니다.

아래 Technical Preview 문서를 참조해서 직접 샘플을 돌려 보시고 기존의 어플리케이션을 어떻게 하둡과 연동할 지에 대한 방법도 함께 고려하면 좋을 듯 합니다.

Apache Slide Technical Preview <-- 클릭

아파치 슬라이드의 도입과 더불어서 많은 기업용 어플리케이션들이 하둡과 연동해서 빅데이터 어플리케이션으로 효용성을 높힐 수 있는 계기가 되었으면 합니다.

-----------------------------------------------------------------------------------------------------------
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
———————————————————————————————————–

하둡 데이터의 거버넌스(governance) 체계를 자동화하는 방법 (Apache Palcon)

This article is based on Hortonworks Partner Content and Expertise

하둡을 기업 환경에서 본격적으로 수용하기 위해서 고려해야 할 점들을 많이 소개하고 있습니다.
기업에서 하둡을 도입할 때 반드시 고려해야 할 점
하둡 기반의 기업용 데이터 관리 시스템을 쉽게 구축하는 방법

하둡의 데이터도 기업의 IT 거버넌스(Governance)의 입장에서 봤을 때는 정책이 적용되고 관리되어야 하는 중요한 자산으로 파악을 해야 합니다.
하둡 에코 시스템의 입장에서도 하둡이 기업에 본격적으로 도입을 하기 위해서는 이러한 데이터 관리 정책을 적용하고 추적할 수 있는 방법이 핵심이라는 점을 인지하고 있습니다.

그래서 현재는 아파치 팔콘(Apache Palcon)이라는 프로젝트를 통해서 이러한 기업의 하둡 데이터 거버넌스 니즈를 수용하고자 하고 있습니다.
팔콘은 비교적 새로 하둡 에코시스템에 편입된 컴포넌트이지만 이미 인모비(Inmobi)라는 온라인 광고 회사에서 2년 이상 활용되고 진화되어 온 데이터 관리 시스템입니다.
호튼웍스는 호튼웍스 데이터 플랫폼(HDP) 2.1 버전에 정식으로 팔콘을 통합할 계획을 가지고 있으므로 HDP에 통합된 형태로 이용할 수 있게 되었습니다.

아파치 팔콘은 한 마디로 데이터 관리 정책을 정의하고 스케쥴링하고 모니터링하는 데이터 거버넌스 엔진입니다.
(Apache Falcon is a data governance engine that defines, schedules, and monitors data management policies.)

falc1

다이어그램을 보면 팔콘은 기본적으로 다음 세 가지를 수행하기 위해서 다른 하둡 에코시스템을 이용하고 있습니다.
- 데이터 파이프라인(Data Pipeline)을 정의하기
- 암바리(Ambari)를 이용해서 이러한 데이터 파이프라인의 처리 현황을 모니터링하기
- 데이터 파이프라인의 처리 흐름을 추적하기

팔콘은 이러한 복잡한 처리 과정을 단순화하기 위해서 엔터티(Entity)를 정의하는 방법으로 정책을 지정하고 Apache Oozie의 워크플로우를 통해서 스케쥴링하는 방법으로 복잡한 거버넌스 절차를 자동화합니다.

정책을 정의하기 위한 엔터티는 세 가지로 이루어져 있습니다.

falc3

여기서 클러스터(Cluster) 엔터티는 팔콘이 이용하는 모든 서비스 인터페이스를 지정하는 상위 엔터티이고 데이터셋을 지정하는 피드(Feed)와 스케쥴링을 지정하는 프로세스(Process)는 이 클러스터 엔터티에 의존하게 됩니다.
그래서 항상 클러스터 엔터티를 먼저 지정하고 다른 두 엔터티를 지정하는 형태로 설정을 합니다.

각 정책 마다 어떤 데이터셋이 적용 대상인지에 대한 피드 엔터티를 지정하고 어떤 파이프라인을 통해서 처리할 것인지를 프로세스 엔터티에 지정하여 간단하게 데이터 거버넌스 정책을 자동화할 수 있습니다.

falc2

이렇게 정의된 엔터티들의 정책은 워크플로우 엔진에 Oozie를 통해서 실행이 되고 처리 현황은 다시 팔콘으로 피드백이 됩니다.

다음에는 구체적으로 어떻게 정책을 적용할 수 있는 지 실사례들을 중심으로 살펴 보도록 하겠습니다.

—————————————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

ASD Technologies는 펜타호(Pentaho Inc)와의 Consulting and Distribution Partnership을 통해서
빅데이터에서 비즈니스 인사이트를 얻기 위한 방법을 함께 모색하고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
—————————————————————————————————————————–

호튼웍스 하둡과 오픈스택의 연동 아키텍쳐 (From Mirantis and Hortonworks)

This article is based on Hortonworks Partner Content and Mirantis

이전에 하둡과 오픈스택의 관리 체계를 통합하여 오픈스택에서 하둡 클러스터를 프러비저닝(Provisioning)하고 통합해서 관리하는 움직임에 대해서 소개해 드린 적이 있었습니다.

하둡과 오픈스택의 연동 로드맵

최근에 오픈스택의 커뮤니티와 하둡의 커뮤니티가 본격적으로 클라우드 환경에서의 하둡 데이터 플랫폼에 대한 프로젝트에 착수했고 이 프로젝트는 아파치에서 Savanna라는 형태로 구체화되고 있습니다.

물론 이론적으로 Bare-metal의 하드웨어 기반으로 설계된 하둡이 가상화 환경(Virtualization)에 적합한 것인가에 대한 논의는 많이 있었고 다양한 결론이 도출되었지만 기본적으로는 성능면에서 큰 메리트를 얻을 수 없다는 것이 가설이었습니다.
하둡 클러스터와 가상화에 대해서는 다른 많은 전문적인 텍스트를 참조하시면 되겠습니다.

하지만 현실적으로 대규모의 하둡 클러스터를 기업이 투자하는 과정은 많은 중간 단계를 거쳐서 이루어 지고 있다는 점에도 주목해야 할 것입니다.
대규모의 빅데이터 프로젝트가 한 번의 결정으로 기업의 데이터센터 내부에 하둡 클러스터를 대규모로 구축하는 경우는 아주 드물고, 실제로는 Poc를 거치고 단위 작업에 대한 Test/Evaluation을 몇 번 거친 이후에 기업 환경에 구축이 됩니다.

이러한 Poc, Test/Evaluation 단계를 신속하게 진행하기 위해서 많은 기업들이 클라우드 환경에서 테스트용 하둡 클러스터를 구축하고자 하는 니즈는 많이 표출되고 있습니다.

그리고 점차 기업 내부의 데이터센터를 클라우드 환경으로 구축하는 과정에서 하둡 시스템도 통합해서 관리하고자 하는 니즈도 점차로 커지고 있습니다.

그래서 Mirantis, Hortonworks와 같은 기업들을 중심으로 오픈스택과 하둡의 최적화된 관리 방법을 모색하자는 프로젝트가 Savanna로 모아지고 있습니다.

savanna-architecture

이것은 Savana의 아키텍쳐를 개념적으로 설명하는 다이어그램입니다.
핵심적인 컴포넌트에 대해서 간단히 소개드리겠습니다.

Cluster Configuration Manager
오픈스택을 통해서 프로비져닝(Provisioning)하는 하둡 클러스터에 대한 제반 설정 정보 등을 관리하는 핵심적인 컴포넌트입니다.
이 컴포넌트는 사용자로부터 혹은 클라이언트로부터 받은 하둡 클러스터에 대한 정보를 바탕으로 ‘VM Provisioing’ 혹은 별도의 ‘Deployment Engine’을 통해서 각 역할을 가진 하둡 에코 시스템의 구성 요소를 설치하게 됩니다.

Auth component
이 컴포넌트는 클라이언트의 인증과 권한 관리를 하는 모듈로서 기존 오픈스택의 Key Stone 컴포넌트와 연동해서 진행하는 것도 가능합니다.

DAL – Data Access Layer
하둡 클러스터를 위한 내부 모델을 데이터베이스에 저장하는 기능입니다.

VM Provisioning
이 컴포넌트가 오픈스택의 Nova와 Glance와 통신해서 실행하는 역할을 담당합니다.

Deployment Engine
일종의 플로그인 구조로 되어 있어서 기존 아파치의 Ambari 혹은 다른 관리 콘솔을 통해서 하둡 클러스터를 관리할 수 있도록 되어 있습니다.

REST API – exposes Savanna functionality via REST

openstack-interop

Savana는 기존의 하둡 클러스터 관리 솔루션을 자유롭게 ‘Deployment Engine’으로 활용할 수 있는 데 초점을 맞추고 있고 하둡 클러스터의 VM 이미지를 오픈스택의 Glacier를 이용하는 등의 방법으로 오픈스택과의 원활한 연동을 보장하고 있습니다.

저희 회사가 미란티스 및 호튼웍스와 파트너쉽을 가지고 있어서 Hadoop on Cloud는 관심을 많이 가지고 연구하고 있는 주제입니다.
아직 성능이라는 측면과 관리의 용이성, 마이그레이션 등의 다양한 영역에서 보완되어야 할 것이 많은 분야입니다.

그래서 별도로 오픈스택과의 연동 로드맵을 발표하여 향후에 지속적으로 진화시켜나가고 있는 프로젝트입니다.

—————————————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

ASD Technologies는 펜타호(Pentaho Inc)와의 Consulting and Distribution Partnership을 통해서
빅데이터에서 비즈니스 인사이트를 얻기 위한 방법을 함께 모색하고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
—————————————————————————————————————————–

호튼웍스 하둡을 이용한 정유(Oil & Gas)산업의 현대적인 아키텍쳐 제안 (From Hortonworks)

This article is based on Hortonworks Partner Content and Expertise

그 동안 각 산업 영역별로 가진 문제점들과 하둡을 이용한 해결 방안에 대해서 소개해 드리고 있습니다.

의료 산업의 혁신을 위한 하둡 아키텍쳐
제조업을 위한 하둡 아키텍쳐
통신사를 위한 하둡 아키텍쳐
유통업을 위한 하둡 아키텍쳐
광고 산업의 혁신을 위한 하둡 아키텍쳐

그 외에 하둡이 가진 유연함(Flexibility)를 활용하여 기업의 데이터 정제 아키텍쳐로 활용하는 방법에 대해서도 소개해 드렸습니다.

소개해 드리면서도 강조하는 사항입니다만 실제 아키텍쳐보다는 이러한 산업들이 가지고 있었던 문제점들을 데이터의 관점에서 바라보고 어떤 부분에 적용하는 것이 가장 적합할 지에 대한 문제의식으로 파악하는 것이 더 중요하다는 생각입니다.

그 동안 호튼웍스의 여러 파트너사들을 통해서 다양한 산업 분야의 사례가 정리되고 있지만 정유 산업은 그 규모는 물론이고 레거시 시스템의 정합성 등의 여러 가지 부분에서 보다 더 유연한(Flexible)한 접근 방식이 중요한 분야라고 합니다.

미국은 이른바 쉐일가스 혁명 등의 일련의 사건들로 인해서 정유 산업이 막대한 투자가 이루어 지는 영역으로 떠 올랐습니다.
심지어 한 국제 에너지 기구(International Energy Agency)에 의하면 2016년 이면 사우디 아라비아와 러시아를 넘어서 최대 산유국이 되리라는 전망이 나오고 있습니다.
하지만 다른 어떤 영역보다도 이른바 투입-대비-산출 비율이 중요한 곳이고 효율성이 강조된다는 측면에서 이 산업을 효율적으로 서포트하기 위한 현대적인 데이터 아키텍쳐에 대한 적용 사례도 나오기 시작하고 있습니다.

정유 산업은 새로운 장치들의 도입, 프로세스 자동화 및 다양한 조직간의 협업의 증대 등의 비즈니스적인 요구는 물론이고 이른바 센서, 지리정보에서 부터 날씨와 방대한 채굴 정보와 지진계측 데이터까지 다양한 데이터 소스를 활용해야 하는 영역입니다.

Oil-and-Gas-Ref-Arch

아키텍쳐는 사실 현대적인 하둡 데이터 아키텍쳐에서 설명드렸던 부분과 크게 다른 면은 없습니다.

그렇다면 정유 산업에 적용될 사례에 대해서 조금 더 자세히 검토해 보겠습니다.

Slow Decline Curves with Production Parameter Optimization
정유 회사는 현재 채굴 중인 유전에서 생산량이 감소하는 것을 항상 관리해야 합니다. 왜냐하면 신규 유전을 발굴하는 과정은 항상 더 많은 투자를 수반하기 때문입니다.
각 유전의 현재까지의 채굴량에 대한 데이터를 분석하는 방법(Decline Curve Analysis)을 통해서 향 후 이 유전의 생산량에 대한 예측과 투자 시점 등의 중요한 의사결정에 근거를 제공할 수 있습니다.
언뜻 간단한 분석처럼 보이지만, 실제로 보통의 DCA는 일정한 비율로 감소하는 선형적인 과정인데 비해서 유전이 처음 채굴되서 수명이 다하기까지의 과정은 복잡한 non-linear 패턴을 보이기 때문에 채굴을 어떻게 하느냐에 따라서 생산량을 필요에 맞게 분배할 수 있는가에 대한 해답을 찾기가 어려운 과정입니다.

예를 들면, 유전의 압력, 유전의 흐름(Flow rates), 원유의 온도 등과 같은 다양한 퍼래미터(Production parameter)에 따라서 생산량을 조절하고 퍼래미터를 조절하는 작업에 의해서 생산량을 최적화할 수 있다고 합니다.
이전에는 이러한 방대한 퍼래미터 데이터값을 저장하고 처리하기 위한 데이터 처리 플랫폼을 구축하는 것은 많은 시간과 비용이 들어 가는 작업이었지만 하둡 데이터 플랫폼은 많은 문제를 해결할 수 있습니다.

Define Operational Set Points for Each Well & Receive Alerts on Deviations
일단 위에서 최적화된 운영 퍼래미터를 식별한 이 후에는 최적화된 퍼래미터 값을 실제 운영 환경에서 유지하고 관리하는 것이 필수적입니다.
하둡 데이터 플랫폼에서 스톰(Storm)과 같은 스트리밍 데이터 처리 플랫폼은 실시간으로 이러한 퍼래미터 값을 식별하고 원하는 값이 실제로 적용되고 있는 지와 차이가 많이 나는 경우에 경고(Alert)를 보냄으로써 운영 환경을 실시간으로 조정할 수 있습니다.
스톰(Storm)은 펌프의 압력, RPM, 유전의 흐름, 온도 등의 데이터셋을 실시간으로 스트리밍하여 문제를 식별함으로서 최적화된 환경을 운영하는 데 큰 역할을 담당할 수 있습니다.

Optimize Lease Bidding with Reliable Yield Predictions
정유 산업은 잠재적인 유전의 채굴 권리를 획득하기 위해서 장기 리스 계약을 해야 하고 이 가격을 결정하는 문제는 향 후 사업의 수익성을 확보하는 데 결정적인 영향을 미칩니다.
하지만 이 유전을 통해서 미래에 얻을 수 있는 수익을 예상해서 비딩하기 위해서는 의사 결정을 위한 근거가 필요합니다.
기존에 회사의 경험을 통해 축적된 데이터뿐만 아니라 제3의 기관의 데이터나 사전 데이터를 축적하기 위한 센서 데이터 등을 함께 조인하고 블렌딩하는 유연한 플랫폼을 통해서 최적화된 비딩 가격을 제시하는 데 이용할 수 있습니다.

Repair Equipment Preventatively with Targeted Maintenance
그 외에도 제조업을 위한 하둡 기반 아키텍쳐에서 제시해 드렸던 것처럼 머신 로그 데이터 분석을 통해서 다양한 장치들의 고장 및 오작동을 예측하고 신속하게 대응하는 데 적용하는 등에서도 활용할 수 있습니다.

현대적인 데이터 플랫폼의 요건은 다양한 데이터셋에 대해서 분석 결과를 얻어 내는 과정을 합리적인 비용으로 수행할 수 있느냐가 관건이고 이것은 하둡 파일시스템이 가진 확장성과 YARN(Yet Another Resource Negotiator)를 통해서 가져 온 유연한 데이터 처리 플랫폼을 통해서 가장 합리적인 해결책을 제시할 수 있습니다.

앞으로도 각 산업 영역에 적용되는 아키텍쳐와 사례에 대해서 계속 공유드리도록 하겠습니다.

—————————————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

ASD Technologies는 펜타호(Pentaho Inc)와의 Consulting and Distribution Partnership을 통해서
빅데이터에서 비즈니스 인사이트를 얻기 위한 방법을 함께 모색하고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
—————————————————————————————————————————–

하둡 2.0 YARN의 컨셉에 대한 검토 및 적용 방법

This article is based on Hortonworks Partner Content

지금까지 다양한 적용사례나 아키텍쳐에 대한 검토를 할 때 자연스럽게 하둡 2.0 기반을 전제로 소개하고 있습니다.
그 핵심적인 이유에 대해서는 아래 블로그들에서 충분히 이해할 수 있을 듯 합니다.

현 시점에서 하둡 2.0을 반드시 적용해야 할 필요가 있을까?
기업의 데이터 정제 아키텍쳐로 하둡을 보는 관점
유통업을 위한 하둡 아키텍쳐
하둡 파일시스템(HDFS)의 새로운 아키텍쳐 – HDFS 2.0

이러한 다양한 적용 사례에서 공통적으로 활용되는 부분을 요약하자면 하나의 하둡 클러스터에서 배치, SQL 인터랙티브, 온라인, 실시간 스트리밍 처리와 같은 다양한 데이터 처리 방식을 요구 사항에 맞게 적용할 수 있다는 점입니다.
이것이 하둡 2.0을 기반으로 적용해야 할 가장 핵심적인 이유가 되겠습니다.

그래서 하둡 2.0에 이러한 유연성을 가져 오게 한 YARN(Yet Another Resource Negotiator)의 컨셉에 대해서 조금 더 검토해 보고자 합니다.

하둡 1.0의 맵리듀스(MapReduce)가 하둡 클러스터에서 동작하는 방식은 아래와 같습니다.

1.0

여기서 잡트랙커(JobTracker)는 사실 두 가지 기능을 함께 수행하고 있습니다.
첫째는, 실제로 분석이 이루어 지는 노드들(TaskTrackers)의 리소스(가용한 스토리지 등)가 이용 가능한지, 얼마나 사용되고 있는 지 등을 관리하는 리소스 관리 기능입니다.
두번째는, 실제로 분석을 실행하는 맵리듀스 잡(MapReduce Job)을 배포하고 스케쥴링하고 모니터링하는 실행 관리 기능입니다.

이 구조에서 TaskTracker는 잡트랙커(JobTracker)에서 일을 받아 와서 실행하고 실행 현황을 다시 보고하는 아주 단순한 역할을 수행합니다.

다음에는 하둡 2.0의 YARN(Yet Another Resource Negotiator)가 하둡 클러스터에서 동작하는 방식을 보겠습니다.

2.0

이 구조에서는 잡트랙커(JobTracker)의 두 가지 기능이 두 개의 모듈로 나누어 집니다.

Resource Manager(RM)
YARN에서 RM는 기본적으로 순수하게 하둡 클러스터의 전체적인 리소스 관리만을 담당하는 심플한 모듈입니다.
현재 가용한 리소스들(Job을 실행시킬 노드나 스토리지 등)에 대한 정보를 바탕으로 이러한 리소스들을 ‘각’ 어플리케이션에 일종의 정책으로서 부여하고 그 이용 현황을 파악하는 업무에 집중합니다.

Application Master(AM) & Node Manager(NM)
YARN에서 AM의 정확한 정의는 특정 프레임워크(MapReduce, Storm 등 다양한 어플리케이션) 별로 잡(Job)을 실행시키기 위한 별도의 라이브러리입니다.
예를 들면, 기존의 맵리듀스는 맵리듀스 AM에서, 기존의 스트리밍 처리는 스톰(Storm) AM에서 각자 담당하고 책임을 지게 됩니다.

AM은 다음과 같은 역할을 하는 모듈입니다.
1. RM과 협상하여 하둡 클러스터에서 자기가 담당하는 어플리케이션에 필요한 리소스를 할당받습니다.
2. NM과 협의하여 자기가 담당하는 어플리케이션을 실행하고 그 결과를 주기적으로 모니터링합니다.
3. 자기가 담당하는 어플이케이션의 실행 현황을 주기적으로 RM에게 보고합니다.

즉, 특정한 어플리케이션의 처리 라이브러리를 AM에 올림으로써 하나의 하둡 클러스터에서 다양한 어플리케이션이 돌아 가도록 하는 것이 핵심입니다.
이러한 구조의 변화에 의해서 사용자는 데이터의 속성에 맞는 다양한 어플리케이션을 처리하는 별도의 AM을 만들어서 확장시킬 수 있습니다.

그래서 다음과 같이 하둡 2.0이 진정한 데이터 플랫폼으로 진화하는 기반이 되었습니다.

YARN

오히려 이 그림에서는 ‘Others’에 주목하면 어떨까 싶습니다.
기존에 기업에서 활용하는 다양한 솔루션을 YARN에서 동작하는 어플리케이션으로 개발하여 플러그인할 수 있습니다.

최근에 다양한 기업들이 하둡 2.0을 지원한다고 발표하면서 자사의 솔루션과 하둡을 연동하는 움직임이 활발합니다.
블로그에서 소개해 드린 SAP, RedHat, IBM, EMC 등등 기사를 보시면 거의 대부분의 벤더들이 지원을 하고 있습니다.

이유는 하둡 2.0에서야 비로소 다른 솔루션 혹은 어플리케이션을 수용할 수 있는 ‘확장성’을 얻었기 때문입니다.
앞으로 글로벌 벤더만이 아니라 한국의 기업들도 자신만의 특화된 솔루션을 하둡과 연동시켜서 이 시장이 활발해 졌으면 하는 바램입니다.

기업 입장에서도 하둡 2.0을 기반으로 적용함으로써 현재 이용 가능한 어플리케이션 뿐만 아니라 다양한 다른 어플리케이션을 언제든지 기존에 구축한 하둡 클러스터에 응용할 수 있기 때문에 유연한 데이터 플랫폼으로 계속 진화할 수 있습니다.

—————————————————————————————————————————–
ASD Technologies는 호튼웍스(Hortonworks Inc)와의 Consulting Partnership을 통해서
빅데이터에 대한 도입 컨설팅 및 구축을 도와드리고 있습니다.

ASD Technologies는 펜타호(Pentaho Inc)와의 Consulting and Distribution Partnership을 통해서
빅데이터에서 비즈니스 인사이트를 얻기 위한 방법을 함께 모색하고 있습니다.

호튼웍스 파트너 홈페이지
ASD Technologies Korea 홈페이지

Contact Point : sunung@asdtech.co
—————————————————————————————————————————–

Page 1 of 212