Tags

엔터프라이즈 플랫폼을 위한 하둡의 현재 위치 및 발전 방향 (summary of Hadoop summit 2014)

This article is based on Hortonworks Partner Content and Expertise

이번 하둡 서밋 2014는 여러 가지 의미를 가지고 있습니다만 개인적으로는 드디더 하둡이 엔터프라이즈 데이터 허브로서 적용될 수 있는 프레임워크를 완성했다는 것에 두고 싶습니다.

먼저 호튼웍스의 키노트 영상을 먼저 보겠습니다.

다양한 사례들과 하둡의 향후 모습에 대해서 미리 엿볼 수 있습니다만 그 중에서도 뒤쪽에 있는 ‘Hadoop Innovation’이라는 부분에 주목을 하는 것이 좋을 듯 합니다.

하둡에 대해서 많은 얘기들이 나오고 있지만 아직은 하둡 1.0의 패러다임과 하둡 2.0의 새로운 진화가 공존하고 있는 상황으로 보입니다.
하둡 2.0이 ‘빅데이터 저장 및 관리’ 와 ‘빅데이터 처리’의 두 가지 관점에서 어떻게 변했고 앞으로 어떻게 변해갈 것인지 이해하는 부분이 중요해 보입니다.

더이상 하둡은 하둡파일시스템과 배치 처리를 위한 맵리듀스가 결합된 단일 목적의 빅데이터 처리 플랫폼이 아니라 다양한 어플리케이션이 공통의 저장 패러다임을 공유하면서 목적에 맞게 다양한 데이터 처리 방식을 수용하는 플랫폼이 되었다는 것에 대해 인사이트를 얻을 수 있을 것입니다.

hadoop_second

현재까지 진행된 상황을 한 페이지로 요약한 다이어그램입니다.

- 데이터 관리
- 데이터 접근(Access)
- 거버넌스(Governance) 와 연동 혹은 통합(Integration)
- 보안
- 운영 (Operations)

5가지의 핵심적인 요소들이 이 블로그에서 소개드린 다양한 에코시스템의 통합을 통해서 지원하는 수준으로 발전했습니다.

그리고 그 동안 하둡이 엔터프라이즈에 적용되면서 나왔던 니즈들을 어떻게 수용하게 되었는 지도 한 번 검토해 볼 필요가 있습니다.

hadoop_third

먼저 데이터 관리의 측면에서 하둡의 새로운 아키텍쳐가 어떻게 기업의 니즈를 수용했는 지에 대한 개요입니다.
그 동안 많은 요구가 있었던 안정성 측면에서 이른바 ‘FullStack HA’구성이 가능해 진 점과 멀티 데이터센터의 DR(Disaster Recovery)를 수용하게 되었다는 점에 주목하시면 좋을 듯 합니다.

hadoop-yarn

많은 기사를 통해서 소개드리고 있는 데이터 접근 측면의 변화입니다.
아마도 기존의 하둡의 접근과 완전히 달라졌기 때문에 혼란이 많이 있는 영역이지만 이제는 YARN(Yet Another Resource Negotiator)의 도입으로 기존에 맵리듀스의 배치처리 방식 뿐만 아니라 Batch, Interactive, Realtime, Streaming의 네가지 주요 데이터 처리 방식을 모두 지원하게 되었습니다.

YARN은 하둡 클러스터의 전체 리소스를 관리하는 시스템으로서 각 어플리케이션에 필요한 리소스를 할당하고 모니터링하는 업무에 집중함으로써 다양한 어플리케이션이 하둡 클러스터의 리소스를 공유할 수 있도록 탈바꿈하게 만든 핵심 요소입니다.

그 외에 기업 환경에 적용하는 데 핵심적인 보안 및 운영 관리의 측면에도 기업 니즈를 반영함으로써 엔터프라이즈 데이터 허브에 적합한 플랫폼을 갖추게 되었습니다.

hadoop-streaming

일례로 스톰(Storm) 어플리케이션이 YARN 위에서 돌아가면서 기존의 배치 처리와 상반되어 보이는 머신로그, 센서로그, 서버로그 등의 스트리밍 데이터를 실시간으로 처리하는 기반이 완성되었습니다.

저희도 많은 관심을 갖는 분야이고 지속적으로 소개해 드리고 있습니다.

hadoop-storage

그리고 기존의 하둡의 이미지라고 할 수 있는 로컬디스크가 달린 서버를 균등하게 연결하는 시스템도 기업의 니즈에 의해 변모했습니다.
바로 전의 기사에서 소개드린 것처럼 메모리, SSD 스토리지, 하드디스크 등의 기업 현장의 스토리지를 충분히 이용하는 방향으로 발전이 이루어 지고 있습니다.

hadoop-slide

하지만 가장 주목해야 할 부분은 바로 ‘Others’입니다.
한국에도 많은 기업용 솔루션을 기존에 개발한 회사들도 있고 운용 중이지만 이러한 솔루션을 어떻게 빅데이터를 처리할 수 있도록 할 것인가는 아주 실질적인 문제이고 중요한 문제입니다.

이제는 기존의 어플리케이션을 직접 하둡 클러스터에 적용되어서 빅데이터 솔루션으로 변모하기 위한 프레임워크인 슬라이드(Slide)의 발표가 있었습니다.
참고로 호튼웍스에서 NoSQL을 YARN에서 바로 동작하는 샘플을 발표했으니 함께 검토해 보시기 바랍니다.

전체적으로 빅데이터 시대를 위한 가장 비용 효율적이고 범용적인 플랫폼이 등장했다는 인사이트에 집중해서 보시면 좋을 듯 합니다.

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

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

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

하둡 파일 시스템의 이기종 스토리지 지원 모델의 진화

This article is based on Hortonworks Partner Content and Expertise

하둡 2.0은 기존의 하둡 1.0과는 전혀 다른 아키텍쳐라는 의견들이 많습니다.
이러한 빠른 발전때문에 오히려 초창기부터 하둡을 접했던 아키텍트들은 이러한 많은 변화를 수용하는 데 어려움을 많이 느끼고 있다는 생각이 듭니다.

그 동안 데이터를 처리하는 YARN(Yet Another Resource Negotiator)의 관점에서 많은 토픽을 잡았지만 사실 하둡 파일 시스템 자체도 많은 컨셉의 변화가 있었습니다.

그 동안 다뤘던 부분은 다음과 같습니다.
하둡 파일 시스템의 새로운 아키텍쳐
하둡 파일 시스템을 기업의 다양한 스토리지 환경에 적용하는 방법

전통적으로 하둡 파일 시스템은 균일한 로컬 하드디스크에 초점을 두고 만들어졌습니다.

대용량 파일을 일정한 단위(Data Block)로 쪼개서 많은 서버의 로컬 하드디스크에 저장하고 분석을 위한 코드를 직접 이 서버에 보내서 각 서버 상에서 분석을 실행한다

아마 일반적으로 하둡에 대한 이미지는 위의 컨셉을 기반으로 하고 있습니다.
하지만 엔터프라이즈 환경은 많은 다양한 스토리지 시스템에 대한 투자가 이미 이루어져 있으며 최근에 이른바 메모리 기반 스토리지(Full SSD Stoage) 등이 보다 신속하고 실시간 분석을 위해서 도입이 되고 있습니다.

하둡 파일 시스템은 본격적으로 엔터프라이즈의 이러한 니즈에 대응하기 위해서 기업의 다양한 스토리지 환경을 최대한 이용해서 최고의 성능을 낼 수 있도록 진화를 했습니다.

heterostorage

위의 다이어그램에서 보는 것처럼 워크로드에 따라서 메모리, SSD Storage, 하드디스크 그리고 분산파일시스템의 스토리지까지 이른바 이기종(Heterogeneous) 환경을 지원하는 형태로 변화했습니다.

최근에는 각 서버의 메모리 용량이 커지고 가격도 지속적으로 하락하여 처리 속도를 향상시키기 위해서 메모리를 캐싱(Caching Storage) 스토리지로 이용하고자 하는 니즈가 더욱 커졌습니다.

현재는 이른바 요청이 많은 파일(hot file)에 일종의 태그(Tag)를 붙임으로써 이러한 파일이 캐싱이 되는 형태로 구현이 되어 있습니다.

하지만 앞으로는 파일의 사용 패턴에 따라서 이 과정을 자동화하기 위한 연구가 계속되고 있으며 하둡 에코시스템의 성능을 전반적으로 향상시키기 위해서 많은 노력을 기울이고 있는 분야입니다.

그 중에서 핵심적이라고 할 수 있는 DDM(discardable distributed memory)라는 새로운 컨셉에 대해서 잠깐 더 살펴보고자 합니다.

향후 실시간 분석에 대한 니즈가 커지고 분석 성능을 향상시키고 기존의 인프라 투자를 최대한 효율적으로 이용한다는 여러 가지 측면에서 반드시 검토해 볼 필요가 있습니다.

DDM의 목적은 메모리 스토리지를 추상화시켜서 하둡 에코시스템 및 어플리케이션이 이용할 수 있도록 하는 형태로 제공하는 것입니다.

DDM은 SSD 스토리지를 이용하는 정책 등과 함께 연동되어서 위의 다이어그램에서 본 것처럼 이기종 스토리지를 충분히 활용하기 위해서 메모리를 스토로지의 한 형태로 제공하는 기술입니다.

보다 자세한 사항은 아래 페이지를 참조하시기 바랍니다.
HDFS-5851

이러한 기술들은 워크로드의 데이터 니즈에 따라서 가장 효과적인 스토리지로 데이터를 자동으로 옮기는 이른바 스토리지 티어링(Storage tiering)을 위해서도 핵심적인 요소입니다.

이기종 스토리지의 동작 방식은 다음과 같습니다.

- 데이터노드(Datanode)는 데이터 블록을 저장할 스토리지의 타입을 인식하여 이것을 네임노드(NameNode)에 리포트합니다.

- 네임노드는 각 데이터블록의 위치뿐만 아니라 각 데이터노드가 관리하는 스토리지의 타입도 지속적으로 추적해서 업데이트합니다.

- 클라이언트는 데이터 블록의 위치와 더불어 저장되어 있는 스토리지 타입에 대한 정보도 네임노드를 통해서 얻게 됩니다.

이러한 이기종 스토리지 지원을 통해서 다양한 용도에 이 모델을 적용할 수 있습니다.

1. 특정 어플리케이션은 파일을 생성하고 이 파일을 구성하는 데이터 블록(Data Block)을 특정한 스토리지 타입에 저장되도록 지정할 수 있습니다.

예를 들어, 3개의 복제 데이터 중에 2개는 일반적인 하드디스크에 저장하고 1개는 빠른 SSD타입 스토리지에 저장되도록 세팅할 수도 있습니다.
이러한 세팅은 기존의 값비싼 SSD 타입 스토리지의 투자를 충분히 활용할 수 있습니다.

2. 특정 어플리케이션은 어떤 파일의 저장 스토리지를 다른 타입으로 변경해서 저장할 수 있습니다.

즉, 일전에는 분석 작업의 주기가 길어서 하드디스크에 저장했던 데이터를 분기나 혹은 특정 시기에 빠른 분석이 필요할 때 SSD와 같은 빠른 스토리지 타입으로 옮긴 이후에 작업을 진행할 수 있습니다.

3. 하둡 시스템 관리자는 각 스토리지 타입별로 쿼터(Quata)를 지정해서 효율적으로 관리할 수 있습니다.

4. 파일에 대한 액세스 패턴(Access Pattern)에 따라서 가장 많이 쓰이는 데이터를 가장 빠른 스토리지로 자동으로 옮기도록 세팅할 수 있습니다.

하둡 파일 시스템은 엔터프라이즈 데이터 플랫폼으로 진하하는 데 반드시 필요한 스토리지 자원의 극대화에 대해서도 점차 완전하게 지원하는 쪽으로 진화하고 있습니다.

이러한 진화에 대해서는 앞으로도 자주 소개하도록 하겠습니다.

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

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

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

하둡 서밋 2014를 통해 본 하둡의 로드맵 (Hadoop summit 2014 comment)

This article is based on Hortonworks Partner Content and Expertise

올해의 Hadoop summit 행사는 하둡이 엔터프라이즈 데이터 허브로 자리매김하는 데 필요한 플랫폼을 드디어 완비했다라고 하는 부분을 알리는 것으로 요약된다고 생각합니다.
마침 생중계를 해 주어서 아주 관심을 가지고 지켜 본 행사이고 데이터 허브로서의 하둡에 대한 위상과 가치에 대해서 다시 생각해 보는 계기가 되었습니다.

먼저 호튼웍스 SVP의 인터뷰 영상을 소개드립니다.

잠깐 하둡이라는 틀을 버리고 큰 관점에서 바라 보면 대부분의 기업용 시스템의 진화는 데이터를 어떻게 효율적으로 처리할 것인가에 대한 노력이었다고 보고 싶습니다.

기업이 어떤 데이터 소스의 어떤 데이터셋을 어떤 방식으로 처리하는 가에 대한 수많은 방법들이 개별적으로 진화해 왔다고 볼 수 있습니다.

Structured, Semi-Structured, Unstructured 등으로 나눌 수 있는 데이터셋의 다양한 속성에 맞게 관계형 데이터베이스 부터 최근의 NoSql 그리고 맵리듀스 등이 개별적으로 진화해 왔습니다.

데이터를 어떤 방식으로 처리할 것인가의 니즈도 한 달에 한 번 혹은 몇 주에 한 번 배치 작업을 하는 지, 아니면 필요한 때 필요한 데이터에 대해 쿼리를 던져서 결과를 얻을 것인지, 그리고 실시간으로 스트리밍 데이터를 처리해야 하는 부분까지 각 다양한 방식에 따라서 데이터웨어하우스 부터 각종 로그분석시스템까지 진화를 해 왔습니다.

하지만 최근에 이른바 데이터 빅뱅(Data Bigbang)을 가장 먼저 경험한 구글, 야후 등의 인터넷 기업들을 중심으로 이러한 다양한 데이터셋을 다양한 방식으로 처리할 수 있는 공통의 프레임워크를 가질 수 없는가에 대한 논의가 시작이 되었습니다.

그래서 여러 커뮤니티의 협업과 기업들의 노력으로 현재 시점에서 아래와 같이 하나의 프레임워크를 통해서 모든 데이터 형태 및 유스케이스를 커버할 수 있는 데이터 처리 플랫폼으로서의 하둡이 점차 현실화되고 있습니다.

slider

간단한 다이어그램이지만 많은 의미를 함축하고 있습니다.
이미 여러 기사를 통해서 YARN(Yet Another Resource Negotiator)에 대해서 설명을 드렸지만 비로소 하둡 클러스터에서 다양한 데이터 처리 어플리케이션이 공존할 수 있는 기반이 만들어 지면서 데이터 처리 공통 플랫폼으로서의 하둡이 이른바 데이터 허브로서 기업의 핵심 시스템으로 자리잡을 수 있게 되었습니다.

YARN에 대해서는 다음 기사들을 참조하세요.
기존의 어플리케이션을 YARN 기반으로 전환하는 방법
하둡 2.0 YARN의 컨셉과 적용 방법
하둡 YARN 클러스터에서 Spark application을 실행하는 모델

기업에 도입되어서 실제적으로 기존 시스템과 협업하여 데이터 허브의 역할을 하는 하둡은 이미 가능한가 불가능한가 혹은 성능이나 확장성에 문제가 있는 지 없는 지 등의 논의를 넘어서 이제 하나의 공통 데이터 플랫폼으로 그 로드맵을 확실히 잡았다고 보여 집니다.

빅데이터의 활용을 위한 목적의식과 목표만 확고하게 있다면 기술적 기반의 문제는 점차 사라지고 있다는 것이 이번 하둡 서밋의 요약된 메시지가 아닌가 싶습니다.

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

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

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

기존의 어플리케이션을 하둡 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
———————————————————————————————————–

하둡 YARN 클러스터에서 Spark Application을 실행하는 모델 (Hadoop Yarn and Spark App model)

This article is based on Hortonworks Partner Content and Expertise

하둡 2.0의 리소스 관리 플랫폼이라고 할 수 있는 YARN(Yet Another Resource Negotiator)에 대해서는 여러 기사에서 소개를 드렸습니다.

하둡 2.0 YARN의 컨셉에 대한 검토와 적용방법
현대적인 하둡 아키텍쳐의 구성요소와 역할

일반적으로 하둡을 경험하면 하둡파일시스템(HDFS)와 맵리듀스(MapReduce)의 패러다임에서 생각을 하게 됩니다만 하둡 2.0에서 YARN의 컨셉이 적용되면서 맵리듀스도 많은 다양한 데이터 처리 방식 중의 하나로 받아들여 지게 되었습니다.
현재 맵리듀스 어플리케이션 다음으로 많이 적용되는 데이터 처리 방식이 스파크(Spark)가 아닐까 싶습니다.

바로 얼마전에 드디어 Spark 1.0이 발표가 되면서 비로소 기업 현장에서 적용할 수준으로 안정화가 되었다는 기대감을 갖게 됩니다.
스파크(Spark)는 맵리듀스가 가진 퍼포먼스에 대한 약점을 보완하는 가장 현실적인 방법으로 받아들여 지고 있지만 제대로 적용하기 위해서는 맵리듀스와의 차이점에 대해서 확실히 할 필요가 있습니다.

그 중에서 하둡 클러스터에서 적용하는 단계에서 가장 현실적인 차이점을 알아 보겠습니다.
간단히 요약하자면, 맵리듀스는 잡(Job)이 하나의 큰 단위로서 인풋 데이터를 받아서 Map task와 Reduce task를 실행시켜서 결과를 저장하는 흐름입니다.
스파크(Spark)는 물론 잡이라는 개념을 사용하고 있지만 많은 잡들을 순차적으로 혹은 병렬적으로 실행시키는 어플리케이션(Application)이라는 상위 단위를 가지고 있습니다.
이 부분은 많은 의미를 가지고 있고 YARN과의 연동 지점에서도 큰 의미를 가지고 있습니다.

“SQL문을 HIVE를 통해서 맵리듀스 잡으로 변환하여 처리하는 경우에 스파크를 사용하면 연관이 있는 잡들을 순차적 때로는 병렬적으로 실행시켜서 성능을 획기적으로 향상시킨다.”
아주 단순하게 얘기하자면 이렇게 요약할 수 있겠습니다.
이 부분을 기술적으로 이해하기 위해서는 DAG 처리 알고리즘에 대한 다른 문서들을 참조하시기 바랍니다.

간단한 스파크 어플리케이션의 구조를 살펴보겠습니다.

spark

스파크 어플리케이션의 본질은 SparkContext 클래스의 인스터스로 보면 됩니다.
물론 어플리케이션은 하나의 잡을 실행시켜서 맵리듀스와 동일한 동작을 하는 형태로도 이용가능하지만 그 힘은 잡을 실행시키고 있지 않더라도 독자적으로 실행되고 있는 ‘Executors’라는 요소에 있습니다.
이 구조를 통해서 데이터를 미리 메모리에 집적시켜서 처리하거나 여러 가지 잡을 실행할 수 있는 기반을 제공합니다.

아키텍쳐에서 보면 두 개의 잡이 있지만 각각 Executor에서 태스크들을 병렬적으로 실행할 수 있는 구조라는 점을 보여 줍니다.
위 다이어그램에서 스파크 드라이버(Spark Driver)는 맵리듀스의 잡트래커처럼 잡과 태스크를 분배하고 매니징하는 프로세스로 이해하시면 됩니다.

맵리듀스에서의 태스크는 각자 프로세스에서 돌아가고 태스크가 종료되면 프로세스도 종료되지만 스파크 구조에서는 하나의 프로세스에서 여러 개의 태스크를 실행할 수 있음으로써 성능을 향상시키고 보다 복잡한 데이터 처리를 할 수 있는 유연성을 제공한다는 점이 가장 큰 차이점입니다.

그러면 이러한 스파크 어플리케이션을 YARN 클러스터에서 어떻게 구현하고 있는 지 핵심적인 모델을 살펴보도록 하겠습니다.

yarnspark

YARN은 일종의 하둡 클러스트의 리소스를 전체적으로 관리하는 리소스 매니저라는 부분을 통해서 이 아키텍쳐를 보면 앞에서 설명했던 ‘Executors’는 YARN의 컨테이너로서 동작한다는 것을 이해할 수 있습니다.

맵리듀스가 YARN의 컨테이너에서 각 태스크마다 별도의 JVM을 실행시키는 것과 달리 스파크는 하나의 컨테이너에서 여러 개의 태스크를 실행하고 태스크가 종료되더라도 남아 있다라는 차이를 다시 한 번 생각해 볼 필요가 있습니다.

스파크 어플리케이션이 YARN에서 실행되면 먼저 어플리케이션 매스터(Application Master) 프로세스가 생성이 되는 데 이것이 바로 Spark Driver를 실행하는 컨테이너가 됩니다.
그리고 이 Spark Driver가 YARN의 리소스 매니저와 협상하여 이 어플리케이션을 실행하기 위한 리소스를 받아냅니다.
리소스를 받아내면 YARN 노드 매니저(Node Manager)에게 Spark Executor를 실행하기 위한 컨테이너를 생성하도록 지시합니다.
이 후에 이 Spark Executor가 태스크들을 할당받아서 실제로 태스크를 수행하는 프로세스입니다.

스파크에 대한 자세한 설명은 다음 문서를 참조하시기 바랍니다.
Spark Documentation <-- 다운로드

실제로 스파크는 성능 및 유연성에서 맵리듀스보다 구조적으로 월등하기 때문에 특히 SQL구문을 통해서 결과를 바로 얻어내기 위한 시나리오에서는 맵리듀스보다 탁월합니다.
그리고 자체적으로 맵리듀스의 기능도 포함하기 때문에 앞으로는 보다 더 많은 분야에 활용될 것으로 기대가 되고 있습니다.

하지만 스파크 어플리케이션을 YARN 클러스터에서 세팅하고 운영하는 부분은 아직 쉽지 않습니다.
호튼웍스 데이터 플랫폼은 이러한 스파크 어플리케이션을 위해 클러스터를 세팅하고 운영하는 부분을 직관적으로 하기 위해서 배포판에 통합하여 제공하고 있으니 실제 도입 시에는 통합 테스트가 된 배포판을 이용함으로써 많은 시행착오를 줄일 수 있을 것입니다.

앞으로는 Spark Application을 어떻게 활용할 것인지를 중심으로 소개드리도록 하겠습니다.

-----------------------------------------------------------------------------------------------------------------------------
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 1112345...10...마지막페이지