류프리

데이터 마이닝을 이야기 할 때, 가장 많이 인용되는 사례로 “맥주와 기저귀”의 예가 있습니다. 미국의 대형 편의점의 고객 구매 데이터에서 일회용 아기 기저귀를 사는 사람은 맥주도 같이 산다는 연관 규칙을 연관성 분석을 통하여 발견하였는데, 실제 고객을 조사한 결과 보통 아내가 남편에게 기저귀를 사오라고 하면 남편이 기저귀를 사면서 맥주도 같이 사간다는 것입니다. 이러한 연관 규칙은 맥주와 기저귀를 교차 판매하거나, 각 제품 판매 전략에 활용할 수 있습니다.

정장을 구매하는 고객은 넥타이와 셔츠를 구매한다.

진을 구매한 고객은 토닉과 레몬을 구매한다.

연관성 분석은 특히, 유통업체에서 바 코드 기술의 도입으로 개개의 세일즈 데이터를 저장하여 분석할 수 있어 그 활용도가 높습니다. 연관성 분석을 위한 입력 데이터는 트랜젝션 데이터로 각 레코드는 고객이 한번에 구입한 상품들로 구성됩니다. 즉, 각 트랜젝션에서 고객이 구입한 항목과 구입 날짜로 구성되는 이른바 장바구니 데이터(Basket data) 입니다.

[ 장바구니 분석(MBA, Market Basket Analysis)의 예시 ]

연관성 분석은 장바구니 분석(MBA, Market Basket Analysis), 교차 판매, 상승 판매 등 활용될 수 있는 분야는 매우 다양합니다.

지지도(Support), 신뢰도(Confidence), 향상도(Lift)

연관성 분석을 수행할 때 알고리즘은 설정된 최소 지지도와 최소 신뢰도를 데이터와 함께 고려하여 이 조건을 만족하는 모든 연관 규칙을 찾아줍니다. 또한, 연관성 분석의 결과를 해석하여 유용한 연관 규칙을 파악할 때, 연관 규칙과 함께 각 규칙을 정의하기 위한 측정치로 지지도, 신뢰도 그리고 리프트(Lift)등이 있습니다.

[ 집합 관계 ]

지지도(Support)

어떤 규칙의 지지도가 10%라면 전체 트랜젝션 중 그 규칙을 따르고 있는 트랜젝션이 10%를 차지한다는 의미이다. 즉, 두 품목 A와 B의 지지도는 전체 거래 항목 중에서 항목 A와 항목 B를 동시에 포함하는 거래의 비율을 말합니다.

 Support = P(A∩B)

품목A와 품목B를 포함하는 거래수 / 전체 거래 수

신뢰도(Confidence)

신뢰도는 항목 A의 거래중에서 항목 B가 포함된 거래의 비율을 말합니다.

Confidence = P(B|A) = P(A∩B) / P(A)

지지도(Support) / P(A)

향상도:향상도(Lift:Improvement)

A→B의 연관 규칙에서 임의로(Random) B가 구매되는 경우에 비해 A와의 관계가 고려되어 구매되는 경우의 비율이다. 즉, 연관 규칙이 오른쪽 항목을 예측하기 위한 능력이 얼마나 향상되었는가를 표현하는 값이다.

Lift = P(B|A) / P(B) = P (A∩B) / P(A)P(B)

신뢰도 / P(B)

연관 규칙 예제

1. 문제

셔츠를 구매한 고객이 넥타이도 함께 구매할 연관성에 대해서 분석하시오.

2. 풀이

1) P(A):셔츠 구매, P(B):넥타이 구매

2) 동시 거래수(셔츠, 넥타이) : 2번

3) 셔츠 구매 거래수 : 3번

4) 넥타이 구매 거래수 : 2번

5) 전체 거래수 : 4번

3. 결론

향상도가 1보다 크므로, 넥타이와 셔츠는 양의 관계이며, 동시에 구매할 가능성이 높습니다.

최근 인터넷이 활성화되면서 데이터베이스 기반이 아닌 무작위 형태의 새로운 데이터가 생성되는 경우가 많아지는 추세입니다. 특히, 전자상거래 관련 대부분의 웹사이트에는 사용자들로부터 정형화되지 않았지만 상당히 잠재적 가치를 지니고 있는 텍스트 데이터들이 엄청난 규모로 생성되고 있습니다. 최근, 기업에서 유용하고 잠재적인 정보를 발견하기 위해 많이 사용하는 데이터 마이닝 기술은 정형화된 형태의 데이터를 주대상으로 하고 있습니다.

그러나 대규모의 텍스트 데이터들은 구조적인 형태로 재구성하여 분석하기가 쉽지 않고, 대부분이 자연어로 쓰여진 문장 형태이기 때문에 함축된 정보를 추출하기가 쉽지 않습니다. 이러한 비 구조적인 텍스트 문서로부터 정보를 찾아 지식을 발견하는 것이 텍스트 마이닝입니다. 그러나, 텍스트마이닝은 정형화된 데이터를 위한 일반 데이터 마이닝에 비하여 정보 추출 능력이나 정확성 등 많이 떨어지는 경향이 있습니다.

데이터 마이닝이 구조적인 데이터를 대상으로 유용하고 잠재적인 패턴을 끌어내는 것이라고 한다면, 텍스트 마이닝은 자연어로 구성된 비구조적인 텍스트 안에서 패턴 또는 관계를 추출하여 지식을 발견하는 것으로 주로 텍스트의 자동 분류작업이나 새로운 지식을 생성하는 작업에 활용되고 있습니다.

오늘날 사용하는 대다수의 정보는 확실히 구조가 잡히지 않은 텍스트의 형태로 존재하기 때문에 자연어로 된 텍스트 문서의 자동화되고 지능적인 분석은 매우 중요합니다. 데이터 마이닝은 많은 기업들에서 데이터간의 관계, 패턴을 탐색하고 모형화하여 기업의 의사결정에 적용하기 위해 적용되며, 일반적인 데이터베이스와 같은 구조화된 자료에 초점이 맞춰져 있습니다. 따라서 데이터 마이닝 작업을 위해서는 적용될 데이터가 정확하고 표준화되어야 하며, 구조화가 잘 되어진 후에야 비로서 적용할 수 있을 것입니다.

데이터 마이닝의 개요

데이터 마이닝은 데이터베이스의 데이터처럼 정형화된 데이터를 대상으로 처리하기 때문에 텍스트 마이닝에 비하여 특성간의 연관성 파악이나 규칙 생성 등 매우 다양하고 강력한 알고리즘들이 많이 개발되고 있습니다. 특히 분류 작업의 경우 특성 벡터에 의존하는 텍스트 마이닝에 비하여 결정 트리, 신경망, 연관 규칙등 다양한 알고리즘이 지원될 수 있습니다.

데이터 마이닝의 이론은 실제적인 비즈니스 문제를 해결하는 솔루션으로 보다는 수학이나 통계 등으로 많은 사람들에게 알려져 왔습니다. 데이터 마이닝은 일반적으로 “대량의 데이터로부터 과거에 알려지지 않았던 유용한 정보를 발견하는 기술”로 정의될 수 있는데, 비즈니스 의사 결정에 마이닝의 결과를 활용할 수 있는 유용한 정보를 얻어내는 것이야 말로 성공적인 데이터 마이닝이라 할 수 있습니다.

데이터 마이닝이라는 용어가 등장한 것은 10년이 채 되지 않았으나, 실제 그 기술의 근원은 1950년대의 패턴 인식, 규칙 기반 추론(Rule Based Reasoning) 등의 인공지능 연구로 거슬러 올라가며, 주로 과학적인 적용 업무(Scientific Application)등에 사용되었습니다. 이후 관계형 데이터 베이스의 등장과 각 기업의 대량 데이터의 축적등이 데이터 마이닝 기술을 상업적 적용 업무(Commercial application)의 다양한 분야에 활용하게 하였습니다.

데이터 마이닝은 축적된 데이터에서 비즈니스에 대해서 알려지지 않은 정보를 발견하는 것입니다. 그런데, 데이터 마이닝을 이용하지 않고, 기본적인 통계 기술만을 이용하여 데이터베이스를 탐색하여 새로운 사실을 발견할 수도 있습니다. 실제로 비즈니스에 대하여 가설을 세우고, 그 가설을 증명하기 위한 분석 작업을 합니다.

데이터 마이닝 기술

일반적으로 데이터 마이닝 기술은 발견 마이닝(Discovery mining)과 예측 마이닝(Predictive mining)  2가지로 제공됩니다.

Discovery mining은 새로 발견될 패턴에 대한 사전 지식 없이 데이터 내에 숨겨진 패턴을 발견하는 기술입니다. Discovery mining은 다시3가지로 분류할 수 있습니다.

Clustering

클러스터링은 주어진 데이터를 속성이 유사한 그룹으로 나누는 기능을 갖습니다. 클러스터링의 목적은 이러한 유사 속성 그룹의 특성을 파악하고자 합니다.

Link analysis

아이템들간의 관계를 트랜잭션 데이터베이스에서 탐지하는 기능을 갖습니다.

Frequeny analysis

순서화된 데이터에 대한 분석과 관련된 기능을 갖습니다. 트렌잭션 데이터 또는 time sequence 데이터로 유사한 구조 또는subsequence를 탐지하고자 합니다.

Predictive mining은 과거 데이터 세트에서 변수간의 관계를 발견하는 기술입니다. 이 기술은 알려지지 않은 속성을 다른 속성들의 값을 기반으로 예측할 수 있는 모델을 생성합니다. 과거 데이터가 모델 생성시 사용되고 (훈련모드), 모델 생성시 사용되지 않았던 과거 데이터를 사용하여 모델을 테스트하고 (테스트 모드), 새로운 데이터를 사용하여 미래를 예측(적용모드) 합니다. Predictive mining은 다음과 같은 기법이 사용될 수 있습니다.

Classification

분류하고자 하는 데이터 필드를 포함하는 과거 데이터에서 모델을 생성합니다. 의사결정 트리가 대표적인 예이고, 고객 스코어링등에 사용됩니다. 적용모드에서 모델은 새로운 데이터에 적용되어 각 레코드별로 분류하고자 하는 데이터 필드(Classifier)에 값이 할당됩니다.

Value Prediction

예측하고자 하는 필드를 포함하는 과거 데이터에서 모델을 생성합니다. 각 레코드에 과거 데이터에 기반하여 가장 유사한 값을 예측하여 할당합니다.

데이터 마이닝의 중요 사항

데이터 마이닝의 가장 중요한 사항은 데이터를 수집하고 가공하는 이유가 무엇인지 이를 통해서 원하는 결과를 얻기 위하여 어떤 기법을 써야하는지에 대한 이해와 선택입니다. 데이터 분석은 지하에 묻힌 광물을 찾아낸다는 뜻을 가진 마이닝(mining)이란 용어로 부르게 된 것은 데이터에서 정보를 추출하는 과정이 탄광에서 석탄을 캐거나 대륙붕에서 원유를 채굴하는 작업처럼 숨겨진 가치를 찾아낸다는 특징을 가졌기 때문입니다.

데이터의 형태와 범위가 다양해지고 그 크기가 방대해지는 빅데이터의 출현으로 데이터 마이닝의 중요성은 한층 부각되고 있습니다. 특히 웹에서 엄청나게 빠른 속도로 생성되는 웹 페이지(web page) 콘텐츠와 웹 로그(web log), 소셜네트워크서비스의 텍스트 정보와 영상과 같은 비정형 데이터(Unstructured data)를 분석하기 위한 다양한 방법론이 등장해 데이터 마이닝의 포괄 범위는 확장되고 있습니다.

통계학과 데이터 마이닝의 유사점

데이터에서 정보를 찾아낸다는 관점에서 보면 데이터 마이닝은 통계학과 매우 비슷합니다. 데이터를 탐색하고 분석하는 이론을 개발하는 학문 분야가 통계학이기 때문입니다. 데이터 마이닝에서 주로 사용하고 있는 방법론인 로지스틱 회귀분석(logistic regression), 주성분 분석(principal analysis), 판별 분석(discriminant analysis), 군집 분석(clustering analysis) 등은 통계학에서 사용되고 있는 분석 방법론입니다.

통계학과 데이터 마이닝의 차이점

통계학과 데이터 마이닝의 차이를 살펴보면 통계학은 비교적 크지 않는 실험데이터를 대상으로 하는데 반해 데이터 마이닝은 비 계획적으로 축적된 대용량의 데이터를 대상으로 합니다. 통계학이 추정(estimation)과 검정(testing)이라는 이론을 중시하는 특징을 가졌다면 데이터 마이닝은 이해하기 쉬운 예측모형의 도출에 주목합니다. 즉 데이터 마이닝은 기업활동 과정에서 자연스럽게 축적된 대량의 데이터를 분석해 기업 경영에 필요한 가치 있는 정보를 추출하기 위해서 사용됩니다. 이러한 이유로 데이터 마이닝을 “규모, 속도, 그리고 단순성의 통계학(statistics at scale, speed, and simplicity)”이라 부릅니다.

데이터 마이닝과 KDD(Knowledge Discovery in Database)

데이터 마이닝과 관련된 용어로 KDD가 있습니다. KDD는 데이터로부터 유용한 지식을 찾아내는 과정을 분석에 필요한 데이터를 추출(Extraction)해서, 사전처리(Preprocessing)와 변환과정(Transformation)을 거쳐 분석(Data Mining)하고 결과를 해석하는 과정이라 말할 수 있습니다. 데이터 마이닝은 데이터 분석 과정의 핵심요소이며, 분석을 위한 데이터를 만드는 전 처리 과정이나 결과를 해석 평가하는 것은 넓은 의미로는 데이터 분석에 해당됩니다. 이런 관점에서 데이터 마이닝은 KDD의 구성요소라기보다는 KDD의 전 과정을 포괄하는 개념입니다.

[ KDD 구성도]

데이터 마이닝 분석 과정

데이터 마이닝은 기업 경영 활동 과정에서 발생하는 데이터를 분석하기 위한 목적으로 개발되었기 때문에 다양한 산업 분야에 공통적으로 적용되는 표준화 처리 과정이 제시되었습니다. 데이터 마이닝 표준 처리 과정(CRISP-DM, Cross Industry Standard Process for Data Mining)은 비즈니스 이해(Business Understanding), 데이터 이해(Data Understanding), 데이터 준비(Data Preparation), 모형(Modeling), 평가(Evaluation), 적용(Deployment)의 6단계로 구성되어 있습니다.

[ 데이터 마이닝 표준 처리 과정 (CRISP-DM) ]

데이터 마이닝은 학제적(interdisciplinary)인 특징을 가집니다. 기존의 통계적 분석방법론과 함께 기계학습(machine learning), 인공지능(artificial intelligence), 컴퓨터 과학(computer science) 등을 결합해 사용합니다. 통계적인 방법론뿐 아니라 기계학습, 신경망분석(neural network)등도 데이터로부터 정보를 추출하기 위한 다양한 접근방법 중 하나로 활용되고 있습니다. 기계학습 기법은 대량의 데이터를 강력한 계산능력을 활용해 빠르게 분석합니다.

데이터 마이닝은 전문적인 소프트웨어 사용이 중요하다

데이터 마이닝은 대용량 데이터를 활용해 다양한 분석방법론을 적용하기 때문에 전문 소프트웨어 사용이 필수적입니다. 데이터 마이닝 소프트웨어는 데이터베이스 공급업체가 제공하는 제품군과 통계분석용 전문 소프트웨어로 구분할 수 있습니다. 데이터베이스 공급업체가 제공하는 데이터 마이닝 소프트웨어로는 IBM의 Intelligent Miner, MS의 SQL Server 2005, 오라클의 Data Mining, 테라데이터의 Warehouse Miner가 있습니다.

데이터 마이닝 분석용 소프트웨어로는 SAS의 Enterprise Miner, IBM의 SPSS Modeler(구 SPSS Clementine)가 있습니다. 최근 주목받고 있는 R은 오픈소스 형태로 무료로 사용할 수 있는 소프트웨어입니다. 그러나 사용자 친화적으로 설계되어 있지 않기 때문에 일반인이 이용하기에는 어려움이 많습니다.

데이터 마이닝 활용분야

데이터 마이닝은 다양한 분야에서 활용됩니다. 천체 관측 사진에서 행성과 성운을 식별하는 패턴인식(pattern recognition) 기법은 방위 산업과 의료 진단 분야에서 활용하고 있습니다. 데이터 마이닝 활용이 가장 활발한 곳은 기업입니다. 널리 알려진 사례로는 장바구니 분석(Market Basket Analysis)이 있습니다. 할인점의 구매 데이터를 분석한 결과 아기용 기저귀와 맥주가 함께 팔리고 있다는 사실을 발견해 할인 행사나 매장의 상품 배치에 활용한 사례입니다.

반도체나 자동차, 소비재 등 제조업에서는 생산 공정 단계에서 발생하는 데이터를 분석해 불량품이 발생하는 원인을 규명하고 예방하는 품질 관리(Quality Control)에 활용합니다. 금융 분야에서는 고객의 신용 등급에 따라 대출 규모와 이자 등을 결정하는 신용 점수 (Credit Score) 산정에 데이터 마이닝이 활용됩니다. 특이한 거래 행위에서 부정 행위를 적발(fraud detection)하는 분야에도 활용됩니다. 잃어버린 신용카드의 부정 이용, 보험회사의 허위.과다 청구를 예방하기 위해 사용될 뿐 아니라 국민연금이나 의료보험의 부당 청구와 같은 영역에도 활용하고 있습니다.

[ 데이터 마이닝의 적용 분야 (출처: IBM) ]

고객관계관리(CRM, Customer Relationship Management)

데이터 마이닝은 고객관계관리(CRM) 개념과 밀접한 관련을 맺고 있습니다. 고객관계관리는 기업이 소비자에게 상품과 서비스를 판매하는 과정에서 발생한 데이터가 중요한 정보로 활용될 수 있다는 생각이 확산되면서 등장했습니다. 고객관계관리는 기존의 데이터베이스 마케팅(Database Marketing) 개념에서 한 걸음 더 나아가 생산자 중심의 기업 활동을 소비자 중심으로 바꾸는 패러다임의 전환을 의미합니다.

고객의 행동을 파악하기 위해서는 데이터 관리와 분석이 필수적입니다. 이를 위해 데이터를 효과적으로 수집하고 분석하는 정보기술(IT, Information Technology)에 주목하게 됩니다. 데이터웨어하우스(DW, Data Warehouse)는 기업이 보유하는 대규모 데이터를 효과적으로 저장하고 관리할 수 있게 지원하는 시스템이다. 데이터 마이닝을 활용한 고객 데이터 분석도 이러한 효과적인 데이터 관리시스템이 지원했기 때문에 가능한 일이었습니다.

데이터의 양이 폭증하고 비정형 데이터가 중요한 의미를 지니는 빅데이터 환경에서 기존의 정보기술이나 분석 방법론은 새로운 전기를 맞고 있습니다. 그러나 소비자의 관점에서 기업 활동을 한다는 고객관계관리의 기본 사상은 변하지 않고 더욱 강조될 것으로 보입니다.

데이터 마이닝의 사례

유통업자로서 다음과 같은 가설을 세운다면, “도심에 거주하는 고객 군이 상점에 방문 횟수는 작고 1회 구매 금액은 매우 크다.” 이 가설을 증명하기 위하여 데이터베이스내에 관련된 정보(상점, 지역, 매출액, 고객정보등)를 통합하여 쿼리합니다. 반대로 고객이 어떤 행동을 나타낼지 모르는 상태에서 “고객이 거주하는 지역과 고객의 소비패턴과 어떤 관계가 있는가? 라는 질문에 답하려면, 데이터 마이닝이 그 역할을 담당할 수 있습니다.

즉, 사용자 대신 데이터 마이닝이 가설을 세우고 이러한 질문에 답을 하게 되는데, 데이터 마이닝의 결과로 다음과 같은 사실을 발견할 수 있습니다. “특정 지역에 거주하는 고객 중 소수의 수익성이 매우 좋은 고객군이 주말에 구매 금액이 매우 크다.” 다음 그림에서 보는 바와 같이 데이터 마이닝은 다른 분석 기법(쿼리, 다차원 분석등)과 차별화 됩니다.

[ 표준 vs. 데이터 마이닝 접근법 (출처: IBM) ]

리소스 매니저(Resource Manager)의 구성 요소

리소스 매니저는 다음의 구성요소를 가집니다.

① 리소스 매니저와 클라이언트간의 통신하는 구성요소들

ClientServie

리소스 매니저의 클라이언트 인터페이스입니다. 이 컴포넌트는 애플리케이션 제출, 애플리케이션 종료, 큐 정보 획득, 클러스터 상태 등과 같은 작업을 포함하여 클라이언트에서 리소스 매니저로 오는 모든 RPC 인터페이스를 관리합니다.

AdminService

관리자의 요청(Admin request)이 일반 사용자의 요청 때문에 실행되지 못하는 경우가 없도록 작업 명령에 더 높은 우선 순위(Higher priority)를 부여합니다. 노드-목록(node-list)을 새로 고치거나, 큐의 설정(Queues’ onfiguration) 등과 같은 관리자 작업(Admin Operation)은 별도의 인터페이스를 통하여 제공합니다.

② 리소스 매니저와 노드들을 연결하는 컴포넌트들

ResourceTrakerService

이 컴포넌트는 모든 노드에서 오는 RPC에 응답을 합니다. 새로운 노드를 등록하거나, 유효하지 않거나 사용이 중지된 노드로부터의 연결을 거부하거나, 노드의 하트비트(Heartbeat) 획득해서 얀 스케쥴러(YarnSheduler)에게 전달합니다. 리소스 트랙커 서비스(ResoureTrakerServie)는 NMLivelinessMonitor 와 NodesListManager와 긴말하게 협력합니다.

NMLivelinessMonitor

정상적으로 동작하는 노드들을 추적하고, 특히, 죽은 노드를 내리기 위해서 이 구성요소는 각 노드의 마지막 하트비트(Heartbeat) 시간을 추적합니다. 노드들이 설정된 간격(기본 10분) 안에 하트비트를 보내지 않으면 죽은것으로 간주하고, 리소스 매니저가 죽은 노드의 사용을 만료시킵니다. 만료된 노드에서 현재 수행중인 모든 컨테이너는 죽은것으로 표시되며, 그 노드에게는 새로운 컨테이너를 배정하지 않습니다.

NodesListManager

유효하거나 제외된 노드들의 집합입니다. yarn.resourcemanager.nodes.inlude-path와 yarn.resouremanager.nodes.exclude-path를 통해 지정된 호스트 설정 파일을 읽고, 그 파일를 기반으로 노드의 초기 목록을 생성을 담당합니다. 또한 시간이 진행됨에 따라 폐기하는 노드를 추적합니다.

③ 응용 프로그램별 ApplicationMasters와 통신하는 구성요소

AppliationMasterServie

모든 ApplicationMasters와의 RPC에 응답하는 구성 요소입니다. 그것은 새로운 ApplicationMasters의 등록과 종료되는ApplicationMasters에서의 종료/해제 요청, 동작중인 모든 ApplicationMasters에서의 컨테이너 할당/해제 요청을 받아 YarnSheduler로 전송하는 역할을 담당합니다. 이 요소는 아래에 설명된 AMLivelinessMonitor와 밀접하게 연관되어 있습니다.

AMLivelinessMonitor

살아 있는 ApplicationMasters의 리스트와 정지/응답하지 않는 ApplicationMasters의 리스트에 대한 관리를 돕기 위해서, 이 구성 요소는 각 ApplicationMasters의 추적과 마지막 하트비트(Heartbeat) 시간을 유지합니다. 미리 정의된 간격(기본 10분) 내에 하트비트를 보내지 않는 ApplicationMasters는 정지한 것으로 여기고, ResourceManager에 의해서 만료됩니다. 만료된 ApplicationMasters에서 현재 동작하거나/할당된 모든 컨테이너는 죽은(dead) 것으로 표시됩니다. ResoureManager은 동일한 ApplicationMasters을 새로운 컨테이너에 동작시키기 위해서 스케쥴합니다. 이러한 동작은 최대 4번 시도될 수 있습니다.

④ ResoureManager의 핵심 – 스케쥴러와 관련된 구성 요소들

ApplicationsManager

제출된 응용프로그램의 컬렉션(Colletion, 집합)을 유지 관리할 책임이 있습니다. 또한 웹 UI나 응용 프로그램의 명령행을 통해서 사용자가 요청할 수 있도록 응용 프로그램의 캐시를 유지합니다.

ApplicationACLsManager

사용자가 클라이언트(Client) APIs와 관리 요청(Admin requests) APIs를 사용하려면 권한이 부여된 사용자만 접근할 수 있는 문(Gate)이 필요합니다. 이 구성요소는 응용 프로그램 당 ACL(Access-Control-List)의 목록을 유지하고, 응용 프로그램의 상태를 보거나 응용 프로그램을 중단과 같은 요청을 받을 때마다 권한을 적용합니다.  

ApplicationMasterLauncher

몇가지 이유로 인하여 종료된 이전 Application Master의 시도들과 새로 제출된 응용 프로그램의Application Master를 개시하기 위한 스레드 풀(Thread-pool)를 관리합니다. 또한 응용 프로그램이 정상적으로 또는 강제적으로 종료되었을 경우에 Application Master를 마무리 할 책임이 있습니다.

YarnScheduler

스케쥴러는 용량(Capacity), 큐(Queue) 등의 제약사항에 따라서 다양하게 실행되는 응용 프로그램에게 자원(Resource)을 할당하는 책임이 있습니다. 또한 메모리, CPU, 디스크, 네트워크 등과 같은 응용 프로그램의 자원 요구 사항을 기반으로 스케쥴링 기능을 수행합니다. 스케쥴러 기능은 현재 메모리만 제공하고 있으며, CPU에 대한 지원도 곧 완료될 예정입니다.

ContainerAllocationExpirer

이 구성요소는 모든 할당된 컨테이너들이 Application Master들을 통해서 사용되고 있으며, 이후에 컨테이너가 해당되는 노드 매니저에서 실행되고 있는지 보장할 책임이 있습니다. Application Master들은 신뢰할 수 없는 사용자 코드를 실행하고, 잠재적으로 그들을 사용하지 않고 할당을 유지할 수 있으며, 이로 인하여 클러스터를 충분히 활용하지 못하는 원인이 될수 있습니다.

이러한 문제를 해결하기 위해서, ontainerAllocationExpirer는 해당하는 노드 매너저에서 사용되지 않는 할당된 컨테이너들의 목록을 유지합니다. 어떠한 컨테이너이든 해당하는 노드 매니저가 정해진 시간(기본 10분) 안에 Resource Manager에게 컨테이너의 동작 상태를 보고하지 않으면 컨테이너가 정지했다고 간주하고 Resource Manager에 의해서 만료됩니다.

⑤ TokenSecretManagers (for security)

리소스 매니저는 토큰(Token)을 관리하고, 다양한 RPC 인터페이스에 대한 요청을 인증/권한부여 하는데 사용되는 비밀키(Secret-key)들을 청구하는 SecretManager의 콜렉션을 가지고 있습니다. 얀 보안에 대한 미래의 글에는 토큰, 비밀키, Secret-Manager들에 대한 상세한 설명을 포함할 것이며, 지금은 아래에 간략하게 요약만 합니다.

ApplicationTokenSeretManager

리소스 매니저 스케쥴링 요청을 보내는 임의의 프로세스를 피하기 위해서, 리소스 매니저는 애플리케이션 토큰(ApplicationTokens)을 사용합니다. 이 구성요소는 응용 프로그램이 종료될 때까지 메모리에 지역적으로 토큰을 저장하고, 유효한 Application Master 처리에서 발생하는 요청들을 인증하는데 사용됩니다.

ContainerTokenSecretManager

컨테이너 토큰(ContainerToken)은 리소스 매니저가 특정 노드에 존재하는 컨테이너를 관리하고 있는 Application Master에게 발급한 특별한 토큰입니다. ContainerTokenSecretManager는 ContainerToken을 위한 SecretManager입니다.

ContainerToken은 컨테이너가 할당된 해당 노드 매니저와의 연결을 생성하는 Application Master에 의해서 사용됩니다. 이 구성요소는 리소스 매니저 특정이고, 기본 마스터와 비밀키를 추적하고 가끔 키들을 롤백(Roll)합니다.

RMDelegationTokenSecretManager

ResourcManager specific delegation-token secret-manager. 이 구성요소는 리소스 매니저와 인증되지 않은 프로세스로 작업하길 원하는 클라이언트에게 위임 토큰(Delegation token)을 생성할 책임이 있습니다.

⑥ DelegationTokenRenewer

보안 모드에서 리소스 매니저는 Kerberos 인증이며, 응용 프로그램을 대신하여 파일 시스템 토큰을 갱신하는 서비스를 제공합니다. 이 구성요소는 응용 프로그램이 실행되는 동안 그리고 토큰이 더 이상 갱신할 수 없을때까지 제출된 응용프로그램의 토큰을 갱신합니다.

결론

얀에서 리소스 매니저는 주로 스케쥴링 작업에 국한됩니다. 예를 들면 단지 경쟁 응용 프로그램들 간의 시스템에서 사용 가능한 자원을 중재하고 응용프로그램들의 상태 관리는 관심을 가지지 않습니다. 이 때문에 위에서 설명한 모듈 방식과 더불어 분명한 책임의 분리 그리고 이전 포스트에서 설명한 강력한 스케쥴러 API로 인하여, 리소스 매니저는 확장성과 다른 프로그래밍 패러다임에 대한 지원등 가장 중요한 설계 요구 사항을 충족할 수 있습니다. 서로 다른 정책 제한을 허용하기 위해서 리소스 매니저는 플러거블(Pluggable)하고 다른 알고리즘 사용을 허가합니다.

[ 리소스 매니저 ]

노드 매니저(Node Manager)의 구성 요소

노드 매너저는 노드(Node) 마다 설치되는 에이전트이며, 하둡 클러스터에 있는 각 연산 노드를 처리합니다. 여기에는 리소스 매니저와의 동기화, 컨테이너의 생명주기 관리를 감독하고, 각 컨테이너의 리소스(메모리, CPU) 사용을 모니터링하며, 노드의 건강, 로그의 관리, 다른 얀 응용 프로그램에 의해 악용될 수 있는 보조 서비스들을 감시합니다.

NodeStatusUpdater

시작 시점에 이 구성요소는 리소스 매니저에 등록을 수행하고, 노드에서 사용할 수 있는 자원에 대한 정보를 전송합니다. 그 후에 노드 마스터와 리소스 매니저간의 통신은 컨테이너의 상태에 대한 업데이트를 제공합니다. (노드에서 동작중인 새 컨테이너의 상태, 완료된 컨테이너, 기타). 또한 리소스 매니저는 이미 실행중인 컨테이너를 잠재적으로 종료하기 위해서 NodeStatusUpdater에게 신호를 줄 수 있다.

ContainerManager

ContainerManager는 노드 매니저의 핵심입니다. 노드에서 실행되는 컨테이너를 관리하는데 필요한 기능의 일부를 수행하는 하위 구성 요소로 구성됩니다.

ⓐ RPC server

컨테이너 매니저(ContainerManager)는 애플리케이션 마스터(Application Master)로부터 새로운 컨테이너를 시작하거나 실행중인 컨테이너를 정지하도록 요청을 받습니다. 컨테이너 매니저(ContainerManager)는 아래에서 설명할 ‘ContainerTokenSecretManager’와 작업하여 모든 요청을 인증합니다. 이 노드에서 실행중인 컨테이너에서 수행되는 모든 작업은 보안 툴에 의해서 후 처리될수 있도록 감사 로그(audit-log)에 기록됩니다.

ⓑ ResourceLoalizationService

컨테어너가 필요한 다양한 파일 리소스를 안전하게 다운로드하고 관리합니다. 이 구성 요소는 가능한 모든 디스크에 파일을 분산하도록 노력합니다. 또한 다운로드 받은 파일들의 접근권한과 적절한 사용량을 제한합니다.

ⓒ ContainersLauncher

컨테이너를 가능한 빠르게 준비하고 시작하기 위해서 스레드 풀을 유지합니다. 또한 리소스 매니저나 애플리케이션 마스터에서 보내진 요청이 있다면 컨테이너의 프로세스들을 정리합니다.

ⓓ AuxServices

노드 매니저는 보조 서비스를 구성하여 노드 매니저의 기능을 확장하기 위한 프레임 워크를 제공합니다. 이 기능은 특정한 프레임 워크들이 필요로 하는 노드 별 커스텀 서비스 사용을 허가하면서 여전히 노드 매니저의 다른 부분으로부터 분리합니다. 이 서비스는 노드 매니저가 시작하기 전에 설정되어야 합니다. 보조 서비스들은 노드에서 응용 프로그램의 첫번째 컨테이너가 시작될때와 응용 프로그램이 완료된 것으로 간주될 때 통지 됩니다.

ⓔ ContainersMonitor

컨테이너가 시작되면 이 구성 요소가 컨테이너가 실행되는 동안의 자원 활용에 대한 관찰를 시작합니다. 메모리 같은 자원의 공정한 공유와 격리를 강화하기 위해서, 각 컨테이너는 리소스 매니저에게 이러한 자원의 일부를 할당 받습니다. ContainersMonitor는 각 연속적인 컨테이너의 사용을 모니터링하고, 컨테이너가 할당을 초과할 경우, 컨테이너를 종료시키기 위해 신호를 보냅니다. 이것은 동일한 노드에서 실행중인 정상 컨테이너들에게 영향을 미치는 모든 폭주 컨테이너를 방지하기 위한 것입니다.

ⓕ LogHandler

컨테이너의 로그들을 로컬 디스크에 유지하거나 압축하여 파일 시스템에 업로드할 수 있도록 설정할 수 있는 탈착 가능한 구성 요소입니다.

ContainerExeutor

컨테이너가 필요로 하는 파일 및 디렉토리를 안전하게 배치시키기 위해서 그리고 안전한 방법으로 컨테이너에 상응하는 프로세스들을 시작하거나 정리하기 위해서 기본 운영 체제와 상호 작용합니다.

NodeHealthCheckerService

이 구성 요소는 자주 구성된 스크립트를 주기적으로 실행하여 노드의 상태를 검사하는 기능을 제공합니다. 또한 디스크에 가끔 임시 파일을 생성하여 디스크의 상태를 모니터링합니다. 시스템의 모든 상태 변화를 차례로 리소스 매니저로 전송하는 NodeStatusUpdater로 통보 됩니다.

Security

ⓐ ApplicationACLsManager

노드 매니저는 권한이 부여된 사용자만 접근할 수 있도록 웹UI에 컨테이너 로그 표시와 같은 API를 직접 대면하는 사용자가 필요합니다. 이 구성 요소는 응용 프로그램 당 ACL 목록을 유지하고 요청을 수신 할 때마다 이를 적용합니다.

ⓑ ContainerTokenSeretManager

모든 수신 작업이 제대로 리소스 매니저에 의해서 승인되는 것을 보장하기 위해서 다양한 도착 요청을 확입합니다.

WebServer

응용 프로그램 주어진 시점에서 실행중인 컨테이너들과 노드 건강 정보 및 컨테이너에 의해서 생성된 로그들의 목록을 보여준다.

[ 노드 매니저 ]

아파치 하둡 얀은 리소스 관리와 컴포넌트 처리를 분리한 하둡 2.0에 도입된 아파치 소프트웨어 재단의 서브 프로젝트입니다. 얀은 맵-리듀스의 차세대 기술로서 맵-리듀스의 확장성과 속도문제를 해소하기 위해 새로 개발된 프로젝트입니다. 얀 이전의 맵-리듀스에서는 4000노드 이상의 클러스터에서 시스템 확장에 문제가 발생하여 야후(Yahoo)에서 새로 설계하였습니다.

가장 큰 변화로는 얀 자체로 맵-리듀스를 구동할 수 있으며, 추가로 다른 분산 처리 프레임워크(Tez, HBase, Giraph, Spark 등)를 사용자의 인터페이스 개발만으로 구동이 가능하게 되었습니다.

[ 하둡 2.0 스택 ]

얀(YARN)은 하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)의 상단에서 빅 데이터용 애플리케이션들을 실행하는 대용량 분산 운영체제 역할을 수행합니다. 얀(YARN)을 이용하면 안정적인 기반에서 배치 작업과 양방향 실시간 작업을 수행할 수 있습니다. 아파치 재단은 얀(YARN)을 ‘맵-리듀스 버전 2(MRv2)’로 명명했습니다.

YARN의 구조

얀(YARN)은 크게 리소스 매니저(Resource Manager), 노드 매니저(Node Manager), 애플리케이션 마스터(Application Master), 컨테이너(Container)로 구성되어 있습니다.

① 리소스 매니저(Resource Manager)

클러스터 전체를 관리하는 마스터 서버의 역할을 담당하며, 응용 프로그램의 요청을 처리합니다. 리소스 매니저는 클러스터에서 발생한 작업을 관리하는 애플리케이션 매니저(Applications Manager)를 내장하고 있으며, 응용 프로그램들 간의 자원(resource) 사용에 대한 경쟁을 조율합니다. 여기서 말하는 자원이란 CPU, 디스크(disk), 메모리(memory)등을 의미합니다.

② 노드 매니저(Node Manager)

노드당 하나씩 존재하며, 슬레이브 노드(slave node)의 자원을 모니터링(monitoring) 하고 관리하는 역할을 수행합니다. 노드 매니저는 리소스 매니저의 지시를 받아 작업 요구사항에 따라서 컨테이너를 생성합니다.

③ 애플리케이션 마스터(Application Master)

노드 매니저와 함께 번들로 제공되며, 작업당 하나씩 생성이 되며, 컨테이너를 사용하여 작업 모니터링과 실행을 관리합니다. 또한, 리소스 매니저와 작업에 대한 자원 요구사항을 협상하고, 작업을 완료하기 위한 책임을 가집니다.

④ 컨테이너(Container)

CPU, 디스크(Disk), 메모리(Memory) 등과 같은 속성으로 정의됩니다. 이 속성은 그래프 처리(Graph processing)와 MPI와 같은 여러 응용 프로그램을 지원하는데 도움이 됩니다. 모든 작업(job)은 결국 여러 개의 작업(task)으로 세분화되며, 각 작업(task)은 하나의 컨테이너 안에서 실행이 됩니다. 필요한 자원의 요청은 애플리케이션 마스터(Application Master)가 담당하며, 승인 여부는 리소스 매니저(Resource Manager)가 담당합니다. 컨테이너 안에서 실행할 수 있는 프로그램은 자바 프로그램뿐만 아니라, 커맨드 라인에서 실행할 수 있는 프로그램이면 모두 가능합니다.

[ YARN의 전체 구성도 ]

리소스 매니저(Resource Manager)의 구조

리소스 매니저는 클러스터마다 존재하며, 클러스터 전반의 자원 관리와 작업(task)들의 스케쥴링을 담당합니다. 리소스 매니저는 클라이언트로부터 애플리케이션 실행 요청을 받으면 그 애플리케이션의 실행을 책임질 애플리케이션 마스터(Application Master)를 실행합니다. 또한 클러스터 내에 설치된 모든 노드 매니저(Node Manager)와 통신을 통해서 각 서버마다 할당된 자원과 사용중인 자원의 상황을 알 수 있으며, 애플리케이션 마스터들과의 통신을 통해 필요한 자원이 무엇인지 알아내어 관리하게 됩니다.

리소스 매니저(Resource Manager) 내부에는 여러 개의 컴포넌트들이 존재하며, 스케쥴러(Scheduler), 애플리케이션 매니저(Application Manager), 리소스 트랙커(Resource Tracker) 세개의 메인 컴포넌트가 있습니다.

① 스케쥴러(Scheduler)

노드 매니저(Node Manager)들의 자원 상태를 관리하며 부족한 리소스들을 배정합니다. 스케쥴러는 프로그램의 상태를 검사하거나 모니터링 하지 않으며, 순수하게 스케쥴링 작업만 담당합니다. 스케쥴링이란 자원 상태에 따라서 작업(task)들의 실행 여부를 허가해 주는 역할만 담당하며, 그 이상의 책임은 지지 않습니다. 즉, 프로그램 오류나 하드웨어의 오류로 문제가 발생한 프로그램을 재 시작시켜주지 않으며, 프로그램에서 요구하는 리소스(CPU, Disk, 네트워크등)에 관련된 기능만 처리합니다.

② 애플리케이션 매니저(Application Manager)

노드 매니저(Node Manager) 에서 특정 작업을 위해서 애플리케이션 마스터(Application Master)를 실행하고, 애플리케이션 마스터(Application Master)의 상태를 관리합니다. 여기서 애플리케이션 마스터(Application Master)라는 용어가 나오는데 얀에서 실행되는 하나의 작업(task)을 관리하는 마스터 서버를 말합니다.

③ 리소스 트랙커(Resource Tracker)

컨테이너(Container)가 아직 살아 있는지 확인하기 위해서, 애플리케이션 마스터(Applications Master) 재 시도 최대 횟수, 그리고 노드 매니저(Node Manager)가 죽은 것으로 간주 될 때까지 얼마나 기다려야 하는지 등과 같은 설정 정보를 가지고 있습니다.

[ 리소스 매니저: 서브 컴포넌트 ]

노드 매니저(Node Manager)의 구조

노드 매니저는 노드(컴퓨터) 당 한 개씩 존재합니다. 해당 컨테이너(Application Container)의 리소스 사용량을 모니터링 하고, 관련 정보를 리소스 매니저에게 알리는 역할을 담당합니다. 애플리케이션 마스터(Application Master)와 애플리케이션 컨테이너(Application Container)로 구성되어 있습니다.

① 애플리케이션 마스터(Application Master)

하나의 프로그램에 대한 마스터 역할을 수행하며, 스케쥴러로부터 적절한 애플리케이션 컨테이너(Application Container)를 할당 받고, 프로그램 실행 상태를 모니터링하고 관리합니다.

② 애플리케이션 컨테이너(Application Container)

프로그램에 할당된 자원을 나타냅니다.

얀의 작업 순서

다음 그림은 얀 클러스터(YARN Cluster)에서 응용 프로그램이 실행되는 과정을 보여줍니다.

①  클라이언트(Client)가 새 응용 프로그램을 요청하기 위해서 리소스 매니저(Resource Manager)와 통신을 합니다. (리소스 매니저(Resource Manager)의 애플리케이션 매니저(Application Manager) 담당)

②  리소스 매니저(Resource Manager)는 애플리케이션 아이디(Application Id)를 클라이언트(Client)에게 보냅니다.

③  클라이언트(Client)는 메모리(Memory), CPU, 우선 순위(Priority) 등과 같은 세부 요구 사항을 요청하는 Application Submission Request 생성합니다.

④  애플리케이션 매니저(Application Manager)는 클라이언트(Client)로부터 요청을 받으면, 노드 매니저(Node Manager)에게 작업(Job) 당 하나의 애플리케이셔 마스터(Application Master)를 생성하도록 요청합니다.

⑤  노드 매니저(Node Manager)는 애플리케이션 마스터(Application Master)를 생성합니다.

⑥  애플리케이션 마스터(Application Master)는 리소스 매니저(Resource Manager)에게 리소스 할당에 대한 요청을 생성합니다. 애플리케이션 마스터는 작업(Job)이 종료될 때까지 작업에 대한 책임을 집니다.

⑦  리소스 매니저(Resource Manager)는 컨테이너(Container)의 리스트를 반환합니다.

⑧  애플리케이션 마스터(Application Master)는 노드 매니저(Node Manager)에게 특정 작업에 대한 컨테이너(Container)의 시작을 요청합니다.

⑨  노드 매니저(Node Manager)는 컨테이너(Container)를 생성합니다. 컨테이너는 클라이언트의 특정 코드를 실행합니다.

⑩  애플리케이션 매니저(Application Manager)는 작업(Job)이 완료될때까지 작업 실행을 관리합니다.

⑪  클라이언트(Client)는 응용 프로그램의 상태 보고서를 요청합니다.

[ 얀의 작업 순서 ]

맵-리듀스(Map-Reduce)는 구글이 분산 컴퓨팅을 지원하기 위한 목적으로 제작하여, 2004년 발표한 소프트웨어 프레임워크입니다. 이 프레임워크는 대용량 데이터를 신뢰할 수 없는 컴퓨터로 구성된 분산 클러스터 환경에서 대규모 데이터를 병렬로 처리하기 위해 개발되었습니다.

맵-리듀스의 혁신적인 부분은 데이터 집합에 대한 쿼리를 입력 받아, 분할 한 후, 여러개의 노드에서 병렬로 처리하는데 있습니다. 이러한 분산 처리는 단일 장비에서 처리하기에는 부적합한 대규모 데이터 처리 문제를 해결합니다.

[ 분산 환경에서의 Map-Reduce 실행 ]

위의 그림은 네임노드(NameNode)의 잡트랙커(JobTracker)가 데이터노드(DataNode)의 테스크트랙커(TaskTracker)에게 일을 분배해 주는 개념도입니다. 데이터노드는 컴퓨터 한대라고 생각하시면 되며, 맵-리듀스 함수들은 컴퓨터 마다 상주하여 병렬로 작업을 수행함으로써 대규모 데이터를 짧은 시간안에 처리할 수 있습니다.

맵-리듀스(Map-Reduce)의 개념

맵-리듀스는 맵 단계와 리듀스 단계로 처리 과정을 나누어 작업합니다. 맵(map)은 흩어져 있는 데이터를 관련 있는 데이터끼리 묶는 작업을 통해서 임시 데이터 집합으로 변형되며, 리듀스(Reduce)는 맵 작업에서 생성된 임시 데이터 집합에서 중복 데이터를 제거하고 원하는 데이터를 추출하는 작업을 진행합니다.

[ Map-Reduce 작업 ]

맵-리듀스 처리 순서

맵리듀스가 분산, 병렬 처리하기 좋은 이유는 입력 데이터에 대한 맵 함수는 동시에 독립적으로 병렬 처리할 수 있는 구조이기 때문입니다. 아래 그림을 통해서 맵-리듀스에서 파일안에 있는 단어들의 합을 구하는 단순한 작업에 대해서 간략하게 알아보겠습니다.

[ 맵-리듀스 처리 방법 ]

처음 작업은 입력 데이터를 라인 단위로 분할(Splitting) 합니다. 분할된 라인 단위의 문장을 맵(map) 함수로 전달하면, 맵 함수는 공백을 기준으로 문자를 분리 한 후에 단어의 개수를 계산합니다. 메모리에 저장되어 있는 맵 함수의 출력 데이터를 파티셔닝과 정렬을 해서 로컬 디스크에 저장한 후에 네트워크를 통해서 리듀서에게 전달하는 셔플링(Shuffling) 작업을 진행합니다. 리듀스(reduce) 함수는 단어 목록들을 반복 수행하면서 합을 계산하여 클라이언트에게 결과 파일을 제공합니다.

Data Processing: Map

파일을 작은 블록으로 나눈 후에 클러스터를 통해서 확산을 시키면 매우 빠르고 효율적인 병렬처리를 제공할 수 있습니다. 하둡에서 핵심 서비스에 해당하는 병렬 처리 프레임워크(Parallel Processing Framework)는 맵-리듀스(Map-Reduce)에서 담당을 합니다. 맵-리듀스의 이름도 맵 작업과 리듀스 작업의 이름을 따서 만들어졌습니다.

첫번째 순서인 맵 처리(Map Process)는 로컬 블록의 데이터에서 계산을 수행하기 위해서 동시에 데이터 노드에게 작업을 요청합니다. 여기서는 File.txt 안에 존재하는 ‘Refund’ 단어의 출현 빈도수를 계산하기 위해서 데이터 노드에게 요청을 합니다. 이 작업을 시작하기 위해서 먼저 클라이언트(Client)는 “File.txt 안에 ‘Refund’ 단어가 몇번 나오는지” 에 대한  맵-리듀스 작업을 잡 트랙커(Job Tracker)에게 요청합니다.

잡 트랙커(Job Tracker)는 File.txt의 해당 블록을 가진 데이터 노드(Data Node)들의 위치를 알기 위해서 네임 노드(Name Node)에게 물어봅니다. 잡 트랙커는 File.txt와 연관된 데이터 노드들에게 ‘Refund’의 출현 빈도수를 알아내기 위해서 데이터 노드(Data Node)에서 동작중인 태스크 트랙커 (Task Tracker)에게 작업을 지시합니다.

태스크 트랙커(Task Tracker)는 ‘Refund’의 출현 빈도수를 알아내기 위해서 맵 작업을 시작하고, 작업의 진행 상황을 모니터링합니다. 또한 태스크 트랙커는 ‘heartbeats’와 작업의 상태를 잡 트랙커에게 제공합니다. 맵 작업이 완료가 되면 각 노드들은 임시 로컬 저장소(Temporary local storage)에 계산 결과를 저장하며, 저장되는 데이터를 중간 데이터(Intermediate data) 라고 부릅니다.

다음 단계는 데이터 노드에서 생성된 중간 데이터 파일들을 네트워크를 통하여 리듀스 작업(Reduce task)을 하기 위해서 작업을 담당하는 데이터 노드에게 중간 데이터 파일들을 전송합니다.

[ Map Task ]

What if data isn’t local?

잡 트랙커는 항상 맵 작업을 위해서 데이터 노드들을 선택하여 작업을 해야 하지만, 그렇지 못한 경우가 발생을 합니다. 그 이유중 하나로는 데이터 노드들이 로컬 데이터를 사용하여 이미 다른 작업을 진행중이어서 더 이상 작업을 진행할 수 없는 경우입니다. 이러한 경우가 발생을 하면 잡 트랙커는 동일한 랙(rack)에 있는 다른 데이터 노드을 선택하기 위해서 네임 노드에 있는 랙 인식(rack awareness) 정보를 참조합니다.

잡 트랙커는 동일한 랙에 있는 데이터 노드에게 작업을 할당하고, 자신에게 없는 데이터 블록을 가져오기 위해서 네임 노드을 통하여 해당 데이터 노드로부터 데이터 블록을 가져옵니다.

[ What if Map Task data isn’t local? ]

Data Processing: Reduce

맵-리듀스 프레임워크의 두번째 단계는 리듀스(reduce) 작업입니다. 맵 작업(map task)은 중간 데이터(intermediage data)들을 생성하여 각자의 데이터 노드에 저장하는 단계입니다. 이제 우리는 최종 결과를 얻기 위해서 분산되어 저장되어 있던 중간 데이터들을 정제하고 결합하기 위해서 데이터들을 한곳으로 모아야 합니다.

잡 트랙커는 클러스터에 있는 하나의 노드에서 리듀스 작업(reduce task)를 시작하고, 리듀스 작업(reduce task)은 맵 작업(map task)에서 완료된 중간 데이터들을 수집합니다. 여러 곳에서 분산되어 실행되던 맵 작업의 중간 데이터들은 각자의 데이터 노드의 번호로 구분되어 TCP를 통하여 거의 동시에 리듀서(reducer)에게 응답을 합니다. 리듀스 작업은 중간 데이터를 수집하고 최종 계산 작업을 진행할 수 있습니다.

이 예제의 경우에는 “Refund” 단어의 출현 빈도수를 합산하여 결과를 ‘Results.txt’ 파일에 저장합니다. 작업이 완료되면 클라이언트는 하둡 분산 파일 시스템(HDFS)에 저장되어 있는 ‘Results.txt’을 읽을 수 있습니다.

[ Reduce Task computes data received from Map Tasks ]

맵-리듀스의 문제점

최근까지 하둡은 하둡 분산 파일 시스템(HDFS)의 대규모 데이터를 처리하는 계층으로 맵-리듀스를 선택했습니다. 하지만 최근 소개된 차세대 하둡으로 알려진 얀(YARN, Yet Another Resource Negotiator)은 하둡 환경의 맵-리듀스에 대한 의존성을 제거하였습니다.

이러한 변화에는 맵-리듀스가 가지고 있는 확장성 문제와 처리 속도가 느리다는 제약사항 때문입니다. 맵-리듀스의 이러한 한계로 인하여 많은 개발업체들이 속도 향상를 위하여 다른 방법을 생각하도록 유도하였습니다. ( 예를 들면 IBM의 어댑티브 맵-리듀스(Adaptive Map-Reduce)을 들수 있다.)

[ 하둡 2.0 스택 ]

위의 그림을 보시면 하둡 2.0에서는 클러스터 리소스 관리(Cluster Resoruce Management)를 맵-리듀스 대신에 얀(YARN)이 담당하고 있습니다. 얀은 기존의 맵-리듀스 API와의 호환성을 유지하면서도 타 회사에서 개발된 다양한 도구에서도 실행될 수 있도록 확장성을 부여하였습니다. 이를 통해서 속도가 느린 맵-리듀스의 단점을 해결할 수 있는 기반을 마련한 것입니다.

랙 인식(Rack Awareness)

하둡에는 랙 인식(Rack Awareness)이라는 개념이 있습니다. 하둡의 관리자가 수동으로 클러스터의 각 슬레이브 데이터 노드의 랙 번호(Rack number)를 정의할 수 있습니다. 데이터 복제시 랙을 선택하는 문제는 데이터의 손실을 방지하는 것과 네트워크의 성능을 높이는 측면에서 아주 밀접한 관계가 있습니다.

우리가 다시 기억해야 될 사항은 데이터를 여러곳에 복제해 놓지 않으면, 데이터를 가지고 있는 노드가 고장날 경우에 서비스가 중단이 됩니다. 또한 데이터의 복사본들이 동일한 랙에 저장이 되면, 스위치(Switch) 장비의 고장이나 정전으로 인하여 복제를 했는데도 마찬가지로 서비스를 받지 못하게 됩니다. 이러한 문제를 미연에 방지하기 위해서 데이터 복제본이 클러스터의 어느 장소에 위치시켜야 하는지에 대한 지적인 결정(Intelligent decision)을 해야 하는데, 바로 네임 노드(Name Node)에서 담당을 합니다.

네트워크 성능면에서 비교를 하면, 동일한 랙안에 존재하는 두 노드가 서로 다른 랙에 각각 존재하는 두 노드보다 대역폭(Bandwidth)이 크고, 낮은 지연시간(Lower latency)을 가집니다. 이러한 사실을 토대로 네트워크 성능만을 고려한다면, 데이터 손실로 인한 지속적인 서비스 제공이 어렵게 됩니다.

복사본들이 어떤 랙의 어느 위치에 저장되는 것이 네트워크 성능 측면과 데이터 손실 측면에서 가장 합리적인지에 대한 결정을 해야 되는데, 이은 네임 노드(Name node)의 역할이며, 클라우드에 있는 전체 데이터 노드(Data Node)에서 서비스 가능한 데이터 노드들에 대한 정보를 최신으로 유지해야 가능합니다. 더욱 흥미로운 사항은 오픈플로우(OpenFlow)를 사용할 경우에는 오픈플로우 컨트롤러(Controller)에게 물어본 후에 결정할 수도 있으며, 언제든지 컴퓨터를 통해서 수동으로 정보를 갱신할 수도 있습니다.

Preparing HDFS writes

클라이언트(Client)는 'File.txt'를 여러 개의 블록으로 나누고, 블록들을 저장하기 위해서 네임 노드(Name Node)에게 블록들이 저장될 데이터 노드(Data Node)들의 위치를 묻습니다. 네임 노드는 'Rack Awareness' 데이터를 사용하여 합리적인 데이터 노드의 리스트를 클라이언트에게 보냅니다. 네임 노드(Name Node)에서 데이터를 저장할 데이터 노드(Data Node)를 선택하는 가장 중요한 규칙은 하나의 랙(Rack)안에 두개의 복사본을 저장하고, 다른 랙에 나머지 복사본을 저장하는 방법입니다.

[ Preparing HDFS Writes ]

클라이언트는 File.txt에서 분할된 블록들을 클러스터로 복사하기전에 관련된 모든 데이터 노드들에게 블록을 받을 준비가 되었는지 확인하는 작업을 진행합니다. 먼저 클라이언트는 ‘Data Node 1’ 에게 TCP의 50010(Port)를 통해서 블록을 받을 준비가 되었는지 물어봅니다. 마찬가지로 ‘Data Node 1’ 은 TCP를 통해서 ‘Data Node 5’에게 데이터를 수신할 준비가 되었는지 물어봅니다. 동일한 방법으로 ‘Data Node 5’ 역시 ‘Data Node 6’에게 물어봅니다.

준비 요청에 대한 승인 여부는 마지막 노드에서 처음 노드로 역순으로 ‘Ready’ 메시지를 보내줍니다. ‘Data Node 6’에서 ‘Data Node 5’와 연결되어 있는 TCP의 파이프라인을 통해서 ‘Ready’ 메시지를 보내고, ‘Data Node 5’는 ‘Data Node 1’에게 보내고, 최종적으로 ‘Data Node 1’은 클라이언트에게 ‘Ready’ 메시지를 보내면 블록을 복사할 준비가 끝나게 됩니다.

HDFS Write Pipeline

블록을 클러스터에 복사하기 위해서 이미 데이터 노드들간에 연결된 TCP 통신을 통해서 이루어집니다. 즉, 데이터 노드가 블록을 받자 마자 다음 데이터 노드에게 블록을 바로 전송한다는 말입니다. 다음 그림은 클러스터 성능을 향상시키기 위해서 네임 노드가 ‘Rack Awareness’ 데이터를 활용하는 방법을 나타낸 것입니다.

‘Data Node 5’와 ‘Data Node 6’은 같은 ‘Rack 5’에 위치하고 있습니다. 이 말은 ‘Data Node 1’이 ‘Data Node 5’로 데이터를 전송하기 위해서는 하나의 스위치(Switch)만 거치면 되며, 두개의 데이터 노드들이 동일한 랙을 횡단할 필요가 없으며, 동일한 랙에 있기 때문에 높은 대역폭과 낮은 대기 시간으로 네트워크 성능을 높일 수 있습니다. 또한 현재 블록의 복사 작업이 완료가 되지 않으면 다음 블록에 대한 작업은 시작하지 않습니다.

[ HDFS Write Pipeline ]

Pipelined Write

세개의 데이터 노드들이 성공적으로 블록을 받게 되면, 메시지를 성공적으로 받았다고 네임 노드에게 ‘Block Received” 메시지를 보냅니다. 마찬가지로 “Success” 메시지를 TCP 통신을 통해서 클라이언트에게도 보낸후에 기존에 연결된 TCP 세션을 닫습니다. 클라이언트는 “Success” 메시지를 받으면 네임 노드에게도 “Success” 메시지를 보냅니다. 네임 노드는 “Success” 메시지를 받으면 블록의 노드 위치와 정보를 자신의 메타 데이터에 반영합니다. 이러한 절차가 완료가 되면 클라이언트는 다음 블록에 대한 작업을 진행합니다.

[ HDFS Pipeline Write Success ]

Multi-block Replication Pipeline

하둡은 빅데이터와 같은 대규모의 데이터를 저장하는데 사용되며, 이 때문에 네트워크 대역폭 또한 많이 사용합니다.일반적으로 테라 바이트(TB, Tera Byte) 크기의 파일들을 다루고 있으며, 기본적으로 3번의 복제가 이루어집니다. 만약1TB의 파일이 있는 경우에는 3TB의 네트워크 대역폭과 3TB의 디스크 공간이 필요합니다.

[ HDFS Multi-block Replication Pipeline ]

Name Node

네임 노드는 클러스터의 모든 파일 시스템 메타데이터(File System metadata)를 보유하고, 데이터 노드를 관리하며, 데이터에 대한 접근을 조정합니다. 네임 노드는 하둡 분산 파일 시스템(HDFS)의 중앙 컨트롤러(Central Controller) 입니다. 이 말은 네임 노드가 정상적으로 동작하지 않으면, 하둡 분산 파일 시스템은 서비스를 멈추게 됩니다. 네임 노드는 파일들이 어떤 블록들로 구성되어져 있고, 그 블록들이 클러스터의 어느 위치에 저장되어 있는지에 대한 정보를 알고 있습니다.

데이터 노드는 네임 노드에게 TCP 핸드쉐이크(handshake)를 통해서 매 3초마다 ‘heartbeat’를 보냅니다. TCP 핸드쉐이크는 보통 9000포트를 사용합니다. 매번 10번째 ‘heartbeat’는 데이터 노드들이 보유한 블록들의 정보를 네임 노드에게 보고합니다. 네임 노드는 이를 통해서 메타 데이터를 구축하고, 블록들의 사본들이 저장되어 있는 랙(Rack)과 노드(Node) 정보를 수집합니다.

네임 노드는 하둡 분산 파일 시스템의 핵심 컴포넌트입니다. 네임 노드가 없으면 하둡 분산 파일 시스템에 블록을 작성하거나 읽을 수 없으며, 스케쥴(Schedule)이 불가능하며, 맵-리듀스 작업을 할 수 없습니다. 이 때문에 네임 노드는 엔터프라이즈급(Enterprise class) 서버에 구성하는 것이 좋습니다.

[ Name Node ]

Re-replicating missing replicas

네임 노드는 데이터 노드에서 ‘heartbeat’를 수신받지 못하면, 그 데이터 노드는 죽은것으로 가정합니다. 네임 노드는 죽은 데이터 노드가 이전에 보냈던 블록 리포트(Block Report) 정보를 참조하여 다른 데이터 노드에 복제를 결정할 수 있습니다.

네임 노드는 블록의 사본을 새로운 데이터 노드에 복제하기 위해서 ‘Rack Awareness’ 데이터를 참조하여 결정을 합니다. 결정시, 하나의 랙(Rack)에 두개의 복사본을 저장하고, 또 다른 랙에 나머지 하나의 복사본을 복제해야 하며, 랙 스위치의 장애 또는 전원 장애로 인한 문제시에도 시스템이 정상적으로 작동되도록 고려합니다.

[ Re-replicating Missing Replicas ]

Secondary Name Node

하둡은 보조 네임 노드(Secondary Name Node)라는 서버를 가지고 있습니다. 보조 네임 노드에 대해서 오해하는 사항은 네임 노드에 대한 고 가용성 백업(High availability backup) 기능을 수행한다는 것인데, 이것은 사실이 아닙니다. 보조 네임 노드는 네임 노드에 접속을 해서 네임 노드의 메모리에 있는 메타데이터와 파일들의 사본을 주기적((기본 1시간 간격) 으로 가져옵니다.

보조 네임 노드는 자체적으로 복사본을 유지하면서, 파일 집합의 정보를 통합하여 네임 노드에게 다시 제공합니다. 네임 노드가 죽을 경우에 보조 네임 노드에 남아 있는 파일들을 통해서 네임 노드를 복구하는데 사용할 수 있습니다.

[ Secondary Name Node ]

Client reading files from HDFS

클라이언트가 하둡 분산 파일 시스템으로부터 파일을 가져올 때, 네임 노드와 상담하고 파일의 블록 위치를 요청합니다. 네임 노드는 파일의 블록을 가지고 있는 데이터 노드의 리스트를 반환합니다. 클라이언트는 블록 리스트로부터 데이터 노드를 선택하고, TCP 50010 포트를 통해서 한번에 하나의 블록을 읽습니다. 이전 블록의 작업이 완료되기 전까지 다음 블록의 작업은 진행되지 않습니다.

[ Client Read from HDFS ]

빅데이터 환경에서 생산되는 데이터는 그 규모와 크기가 방대하기 때문에 기존의 파일 시스템 체계를 그대로 사용할 경우 많은 시간과 높은 처리 비용을 필요로 합니다. 따라서 대용량의 데이터를 분석하기 위해서는 두대 이상의 컴퓨터를 이용하여 적절히 작업을 분배하고 다시 조합하며, 일부 작업에 문제가 생겼을 경우 문제가 발생된 부분만 재 처리가 가능한 분산 컴퓨팅 환경을 요구합니다.

하둡 분산 파일 시스템(HDFS)은 아파치 하둡 프로젝트의 분산 파일 시스템으로 처음에는 아파치 너치(Apache Nutch) 라는 웹 검색 엔진 프로젝트를 위한 하부 구조를 위해서 만들어졌습니다. 아파치 너치는 확장 가능한 오픈 소스 웹 크롤러 소프트웨어 프로젝트입니다.

2002년 미국 출신의 프로그래머인 더그 컷팅(Dug Cutting)과 마이크 카페렐라(Mike Cafarella)가 검색 소프트웨어를 개발하면서 루씬(Lucene)이라는 텍스트 검색 엔진을 만들고 이에 대한 파서(Parser)및 크롤러(Crawler)로서 너치(Nutch)라는 프로젝트를 진행하였는데, 너치에서 가져오는 웹사이트에 대한 방대한 데이터를 처리할 길이 없어 난감하던 차에2004년 Google이 발간한 구글 파일 시스템(GFS, Google File System) 논문과 맵-리듀스(Map-Reduce) 논문을 기초로 하여 약 3~4개월간의 프로그래밍을 통해 하둡 분산 파일 시스템(HDFS)을 너치에 이식하였습니다.

하둡 분산 파일 시스템(HDFS)은 대용량 파일을 저장하고 처리하기 위해서 개발된 파일 시스템입니다. 하둡 분산 파일 시스템(HDFS)은 하나의 서버에서 동작하는 것이 아니라, 여러 개의 서버에 설치되어서 서비스가 됩니다. 하둡 분산 파일 시스템(HDFS)만을 위한 별도의 스토리지가 필요 없으며, 일반 리눅스 장비에 탑재되어 있는 로컬 디스크를 이용해서 확장 가능한 유연성 있는 구조를 가지고 있습니다.

하둡 클러스터의 이해

하둡 핵심 서비스는 중요한 역할을 담당하는 세가지 모듈로 분류할 수 있습니다. 세가지 모듈로는 클라이언트 머신(Client machines)과 마스터 노드(Master node) 그리고 슬레이브 노드(Slave node)가 있습니다.

[ 하둡 서버의 역할 ]

마스터 노드(Master node)

마스터 노드(Master node)는 많은 양의 데이터를 하둡 분산 파일 시스템(HDFS)에 저장하고 맵-리듀스(Map-Reduce)를 통하여 병렬 계산(Parallel computation)을 수행하는 두 가지 핵심 기능을 담당합니다. 잡 트랙커(Jab Tracker)가 맵(Map)과 리듀스(Reduce)를 사용하여 데이터의 병렬 처리(Parallel processing)를 관리하고 조정하는 동안에 네임 노드(Name Node)는 하둡 분산 파일 시스템(HDFS)의 데이터 저장 기능을 관리하고 조정합니다.

슬레이브 노드(Slave node)

슬레이브 노드는 머신(Machine)의 대부분을 구성하고 데이터를 저장하고 계산을 실행하는 세부적인 일들을 담당합니다. 각 슬레이브는 서로간에 통신을 하고, 마스터 노드(Master Node)의 지시를 받기 위해서 데이터 노드(Data Node)와 태스크 트랙커(Task Tracker) 데몬을 실행합니다. 태스크 트랙커 데몬(Task Tracker daemon)은 잡 트랙커(Job Tracker)의 슬레이브이며, 데이터 노드 데몬(Data Node daemon)은 네임 노드(Name Node)의 슬레이브입니다.

클라이언트 머신(Client machine)

클라이언트 노드는 모든 클러스터 설정(Cluster setting)이 완료된 하둡 시스템(Hadoop System)을 가지고 있지만, 이것은 마스터 노드 또는 슬래이브 노드를 말하는 것은 아닙니다. 클라이언트 머신의 역할은 클러스터에 작업 데이터를 보내어서 맵(Map)과 리듀스(Reduce) 작업을 통하여 데이터를 분석한 후에 완료된 작업 결과를 사용자에게 보여주는 역할을 담당합니다.

하둡 클러스터(Hadoop Cluster)의 구성

실제로 제품 클러스터(Production cluster)에서는 서버 가상화(Server virtualization)나 하이퍼바이저 레이어(Hypervisor layer)가 없는데, 이러한 이유로는 성능을 저해하는 불필요한 오버헤드(Overhaed)라고 보기 때문입니다. 다음 그림은 하둡 클러서터의 일반적인 구조를 나타냅니다.

[ 하둡 클러스터 ]

우선 랙(Rack)이란 용어를 알아야 하는데, 랙(Rack)은 전산실을 구성할 때 작은 공간을 효율적으로 사용하고 장비들을 안정적으로 보호하기 위해서 사용하는 도구로써, 서버나 네트워크 장비들을 수용하기 위해서 사용되는 철제 프레임을 말합니다. 랙 안에는 여러대의 서버들로 구성되어 있습니다. 서버의 구성은 마스터(Master)역할을 담당하는 네임 노드(Name Node)와 잡 트랙커(Job Tracker), 슬래이브 역할을 담당하는 데이터 노드(Data Node)와 태스크 트랙커(Task Tracker)로 구성이 되어 있습니다.

스위치(Switch)의 역할은 네트워크 단위들을 연결하는 통신 장비로서 허브보다 전송 속도가 빠릅니다. 속도가 빠른 이유는 컴퓨터에서 주고 받는 데이터를 허브처럼 다른 모든 노드에 전송하는 것이 아니라, 데이터를 필요로 하는 노드에만 전송하기 때문입니다. 랙(Rack)안에 있는 스위치(Switch)는 클러스터를 형성하기 위해서 균일한 대역폭으로 상위의 스위치(Switch)와 연결이 되어 있습니다. 이 스위치는 다른 랙들과의 연결을 담당합니다.

랙(Rack)

랙(Rack) 안의 존재하는 대부분의 서버들은 슬레이브 노드(Slave Node) 역할을 담당하며, 몇 개의 서버들만 마스터 노드(Master Node)의 역할을 담당합니다. 그리고 각각의 서버들은 로컬 디스크 스토리지(Local Disk Storage)와 CPU와DRAM으로 구성되어 있습니다.

하둡 분산 파일 시스템(HDFS)의 구성

하둡 분산 파일 시스템(HDFS) 클러스터는 일반적으로 네임노드(Namenode)를 담당하는 서버가 한대 존재하며, 하나의 노드에 붙은 스토리지(Storage)를 관리하는 수 많은 데이터노드(Datanode)로 구성이 됩니다.

블록(Block) 단위로 읽기 쓰기 수행

하둡 분산 파일 시스템(HDFS)는 파일을 저장할 때 블록 단위로 읽기(Read)와 쓰기(Write)를 수행합니다. 하나의 파일이 물리적인 저장소에 저장될 때에도 블록 단위로 분할해서 저장이 됩니다. 하둡 분산 파일 시스템(HDFS)에서의 블록 사이즈는 기본적으로 64MB로 설정되어 있으며, 블록의 크기를 변경하고 싶다면 환경설정을 통해서 손 쉽게 변경할 수 있습니다. 보통은 128MB를 사용합니다.

[ 하둡 분산 파일 시스템(HDFS)의 구조 ]

네임노드(Namenode)는 마스터 노드(Master node) 또는 파일 시스템 네임스페이스(File System Namespace) 역할을 담당하는 노드로써, 파일과 디렉토리에 대한 메타 데이터(Meta data) 정보를 저장하는 역할을 담당합니다. 메타 데이터에는 디렉토리(Directory)의 구조, 파일에 대한 정보와 파일이 저장되어 있는 물리적인 위치와 같은 정보가 저장됩니다. 또한 데이터노드로의 블록 매핑을 판단합니다. 데이터노드(Datanode)는 요청한 파일을 읽거나 저장하는 역할을 담당하고 네임노드의 지시에 따라 블록을 생성, 삭제 그리고 복제 작업을 수행합니다.

네임노드와 데이터노드는 컴퓨터에서 실행하도록 설계된 소프트웨어의 조각입니다. 이러한 컴퓨터들은 일반적으로 GNU 리눅스(Linux) 운영체제를 사용합니다. 하둡 분산 파일 시스템(HDFS)은 자바 언어(Java Language)를 사용하여 만들어졌습니다. 자바를 지원하는 어떤 컴퓨터에서도 네임노드 또는 데이터노드 소프트웨어를 수행할 수 있습니다. 높은 이식성의 자바 언어의 사용은 하둡 분산 파일 시스템(HDFS)가 광범위한 컴퓨터에 배포될 수 있음을 의미합니다.

파일 쓰기 동작 설명

클라이언트(Client)가 파일을 디스크에 저장하기 위해서 먼저 ①네임노드(Namenode)에게 파일을 저장해도 되는지 물어봅니다. 쓰기 권한이 있는 경우에는 네임노드(Namenode)에서 블록을 저장할 데이터노드(Datanode)의 정보를 클라이언트에게 알려줍니다. ②클라이언트는 블록(Block)들을 지정된 데이터노드(Datanode)에 저장합니다.  

[ HDFS Write Operation ]

데이터 복제(Data Replication)

클라이언트(Client)는 파일을 128MB(기본, 64MB) 작은 블록(Block) 단위로 분할하고, 같은 블록을 클러스터(Cluster)에 있는 세곳의 노드(Node)에 복제(Replication)시킵니다. 동일한 블록으로 분할되기 때문에 병렬 처리(Parallel Processing)가 가능하며, 작업 노드(Node)에서 문제가 발생하여 데이터를 참조하지 못할 경우에도 다른 노드에 복제되어 있는 내용으로 작업을 계속할 수 있으므로 지속적인 서비스가 가능합니다. 하둡에서 동일한 데이터를 복제하는 기본값은 3이며, ‘hdfs-site.xml’에 있는 ‘dfs.replication’ 파라메터를 통하여 재 설정할 수 있습니다.

아래의 그림은 클라이언트에서 파일을 A, B, C 블록으로 분할하고, A 블록을 클러스터의 어느 위치에 저장할지를 물어봅니다. 네임 노드(일반적으로 TCP 9000)는 A블록을 저장할 데이터 노드의 목록을 클라이언트에게 보냅니다.

클라이언트는 데이터 노드(일반적으로 TCP 50010)에 직접 A블록을 기록합니다. 수신받은 데이터 노드는 다른 데이터 노드에 블록을 복제하고, 나머지 블록에 대해서도 반복적으로 작업을 합니다. 네임 노드는 데이터의 경로를 가지고 있지 않으며, 데이터가 클러스터의 어느 위치에 저장되어 있는지에 대한 지도를 제공합니다. 즉 네임 노드는 랙안의 노드들의 정보와 메타 데이터에 저장된 노드 정보를 이용하여 데이터의 위치를 찾을수 있습니다.

[ 하둡의 데이터 복제 ]

2005년 더그 커팅과 마이크 카파렐라에 의해 개발된 하둡(Hadoop, High-Availability Distributed Object-Oriented Platform)은 대량의 자료를 처리할 수 있는 클러스터 컴퓨터 환경에서 동작하는 분산 응용 프로그램을 지원하는 프레임워크입니다. 하둡에 대해서 간단히 말하자면, 방대한 양의 데이터를 분산 처리하여 빠른 시간 내 결과를 제공하는 오픈소스 기반 데이터 처리 기술입니다.

하둡의 탄생은 구글(Google)이 대규모 자료를 검색하고 분석하는데 사용한 구글 파일 시스템(GFS, Google File System)과 맵-리듀스(Map-Reduce)에 대한 논문을 접하고 이를 참고하여 구현하였습니다. ‘하둡’ 이란 명칭은 더그 커팅의 아들이 가지고 놀던 장난감 코끼리의 이름을 따서 지어졌다고 전해집니다.

[ 하둡의 심볼 ]

지금까지의 데이터 분석 기술은 대부분 컴퓨터 한대로 메모리, 파일시스템, 데이터베이스에 데이터를 저장하고, 이를 기반으로 데이터를 분석하는 구조였는데 하둡이 보급되면서 저가의 x86 컴퓨터들을 이용하여 대규모 데이터를 저장하고 분석할 수 있는 길이 열린것입니다.

하둡 에코 시스템 1.0

아래의 그림은 하둡 초기 버전인 하둡 에코 시스템 1.0에 대한 전체 구성도입니다. 하둡 에코 시스템 1.0에 대해서 간략하게 설명을 드리겠습니다.

[ 하둡 에코 시스템 1.0 ]

데이터 수집 기술

하둡에서 데이터 수집을 담당하는 기술로는 아파치의 스쿱(Apache’s Sqoop), 클라우데라의 플룸(Cloudera’s Flume), 아파치의 척와(Apache’s Chukwa)등이 있으며, 하둡에서 제공하는 데이터 수집 기술은 아니지만,  페이스북에서 만들어서 사용하고 있는 스크라이브(Facebook’s Scribe)등이 있습니다.

대용량 데이터는 정형데이터와 비정형데이터 두가지 형태로 분류할 수 있습니다. 정형데이터는 저장된 형태가 규칙적인 데이터를 말하며, 비정형 데이터는 저장된 형태가 규칙적이지 않는 데이터를 말합니다. 정형데이터는 기업이나 공공기관에서 관리하고 있는 관계형 데이터베이스(RDB, Relational Database)를 말하며, 비정형데이터는 트위터(Twitter), 페이스북(Facebook)과 같은 소셜 네트워크 서비스(SNS, Social Network Service)에서 만들어지는 데이터를 말합니다.

정형데이터를 수집하는 기술로는 스쿱(Sqoop)이 있으며, 비정형데이터를 수집하는 기술로는 클라우데라(Cloudera)의 플룸(Flume)과 아파치(Apache) 척화(Chukwa)등이 있으며, 페이스북에서 사용하는 스크라이브(Scribe)도 비정형데이터 수집 기술입니다.

데이터 저장 및 관리 기술

하둡에서 핵심 코어에 속하는 기술로는 데이터를 저장하는 하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)과 저장된 데이터를 관리하는 맵-리듀스(Map-Reduce)등이 있습니다. 하둡 분산 파일 시스템(HDFS)은 대용량 파일을 지리적으로 분산되어 있는 수많은 서버에 저장하는 솔루션이며, 맵-리듀스는 분산되어 저장된 대용량 데이터를 병렬로 처리하는 솔루션입니다.

초기에 설계된 하둡 에코 시스템 1.0의 경우 배치 처리(Batch processing)를 목적으로 만들어진 시스템으로 맵과 리듀스간의 셔플링(Shuffling) 작업에 많은 시간을 허비하여 실시간 분석에 적합하지 않으며, 기존에 사용하고 있거나 새로 만들어진 솔루션을 확장하여 적용하는데 문제점을 가지고 있었습니다.

이러한 하둡 에코 시스템 1.0의 문제점은 관계형 데이터베이스 분석 시스템에 익숙한 많은 분석가들과 사용자들을 하둡으로 끌어들이는데 실패하는 원인이 되었으며, 이러한 문제점를 해결하기 위해서 하둡 에코 시스템 2.0에서는 맵-리듀스(Map-Reduce)를 버리고 YARN(Yet Another Resource Negotiator)을 채택하여 확장성과 데이터 처리 속도를 개선시켰습니다.

[ 하둡 에코 시스템 1.0 과 2.0 변경 사항 ]

분산 데이터베이스 H베이스(HBase)

하둡에서 제공하는 NoSQL(Not Only SQL) 데이터베이스입니다. H베이스는 자바 언어로 만들어졌으며, 하둡 분산 파일 시스템(HDFS)를 이용하여 분산된 컴퓨터에 데이터를 저장합니다. H베이스는 압축 기능과 자주 사용되는 데이터를 미리 메모리에 캐싱하는 인-메모리(In-Memory) 기술을 사용하여 데이터 검색 속도를 높입니다. 

하둡에서 사용하는 데이터베이스는 관계형 데이터베이스가 아닌 NoSQL(Not Only SQL) 입니다. 관계형 데이터베이스는 대용량 데이터를 처리하기 위해서 만들어진 시스템이 아니며, 국가나 회사에서 관리하는 정보 자원을 저장하고, 사용자가 손쉽게 SQL언어를 사용하여 저장된 정보를 다양한 방법으로 분석해 주는 시스템입니다. 현재도 많은 분석가들과 사용자들이 관계형 데이터베이스를 사용하고 있는데, 이러한 이유로는 관계형 데이터베이스를 통하여 정보(Information)를 다양한 도구를 사용하여 여러가지 측면에서 분석이 가능하며, 또한 결과를 실시간으로 조회할 수 있기 때문입니다.

NoSQL(Not Only SQL)은 대용량 데이터를 처리하기 위해서 탄생된 데이터베이스입니다. 대용량 데이터를 저장하고 처리하기 위해서는 지리적으로 분산되어 있는 노드들에 대한 안정적인 관리가 필요하며, 속도보다는 데이터를 손실하지 않고 저장하는 방법과 더 많은 데이터를 처리하기 위해서 노드들을 쉽게 확장할 수 있는 방법에 중점을 두고 설계가 되었습니다. 이로 인하여 현장에서 데이터베이스를 운영하고 관리하는 분석가들과 사용자들이 원하는 빠른 속도와 쉬운 분석 방법 제공 그리고 관계형 데이터베이스에서 사용하고 손에 익었던 도구들을 그대로 사용하고 싶은 욕구를 충족시키지 못하는 문제점을 가지고 있습니다.

NoSQL(Not Only SQL) 데이터베이스에는 다양한 제품들이 있으며, 이 제품들을 특성에 맞게 'Key-Value store', 'Graph Database', 'Document Store', 'Wide Column Store' 4개의 제품군으로 군집화 시킬수 있습니다. 

'Key-Value store' 제품군으로는 멤캐시드(Mem-Cached)와 레디스(Redis, Remote Dictionary Server)등이 있으며, 키-밸류 형태로 이루어진 비교적 단순한 데이터 타입을 데이터베이스에 저장합니다. 'Graph Database' 제품에는 네오포제이(Neo4j)가 있으며, 그래프 모델에서 필요한 정점(Vertex)와 간선(Edge) 그리고 속성(Property)등과 같은 정보를 데이터베이스에 저장합니다. 'Document Store' 제품군에는 카우치DB와 몽고DB가 있으며, 문서 형태의 정보를 JSON 형식으로 데이터베이스에 저장합니다. 마지막으로 'Wide Colum Store' 제품군에는 H베이스(HBase)와 카산드라(Cassandra)가 있으며, 컬럼안에 여러 정보들을 JSON 형태로 저장할 수 있습니다.

하둡 진영에서는 관계형 데이터베이스에 호감을 가지고 있는 분석가와 사용자들의 마음을 돌리기 위해서, 빠른 속도와 손 쉬운 사용 그리고 관계형 데이터베이스에서 사용하던 도구들을 이용할 수 있는 시스템을 만들기 위해서 노력하고 있습니다. 우리는 이러한 데이터베이스 제품들을 'NewSQL'이라고 부르고 있으며, 여기에는 그루터(Gruter)의 타조(Tajo), 구글의 드레멜(Dremel), 호튼웍스의 스팅어(Stinger), 클라우데라의 임팔라(Impala)등이 있습니다. 

하이브(Hive)

아파치의 하이브(Hive)는 ‘SQL 온 하둡(SQL On Hadoop)’ 시스템입니다. 'SQL 온 하둡'은 하둡에서 SQL 언어를 사용하여 편리하게 정보를 조회(Query)하는 방법을 제공합니다. 하둡은 하이브(Hive)가 없었던 시절에는 맵-리듀스(Map-Reduce) 언어를 사용하여 하둡 분산 파일 시스템(HDFS)에 저장된 정보들을 조회(Query) 했습니다. 프로그램을 모르는 일반 사용자들이 맵-리듀스 언어를 사용하여 조회(Query)하는 일이 어려웠습니다. 하이브는 하이브큐엘(HiveQL)이라는SQL과 거의 유사한 언어를 사용하여 일반 사용자들이 쉽게 데이터를 조회(Query)할 수 있도록 지원합니다. 

하지만 하이브에도 몇가지 단점이 있습니다. 하이브큐엘(HiveQL)을 통해서 조회(Query)를 실행하면 내부적으로 맵-리듀스 언어로 변환하는 작업을 거칩니다. 맵-리듀스는 맵과 리듀스간의 셔플링 작업으로 인하여 속도가 느리다는 단점이 있습니다. 하이브큐엘(HiveQL)이 일반 사용자들에게 손쉽게 조회(Query)할 수 있는 방법을 제공하고 있지만 처리 속도가 느리다는 문제점은 여전히 가지고 있습니다. 또한 하이브큐엘(HiveQL) 언어는 SQL과 비슷한 언어이지만 표준 SQL(Ansi SQL)의 규칙을 준수하지 않으며, 사용자들은 이러한 차이점을 다시 배워야하는 문제점을 가지고 있습니다.   

SQL 온 하둡(SQL On Hadoop)

하이브가 가지고 있는 문제점을 개선하기 위한 하둡 진영은 크게 두 갈래로 나뉩니다. "하이브를 완전히 대체하는 새 기술을 쓸 것인가?" 아니면 "하이브를 개선해 속도를 높일 것인가?"

하이브를 살려야 한다는 입장을 가장 강력하게 내세운 회사는 호튼웍스입니다. 호튼웍스는 하이브를 최적화하고 파일 포맷 작업을 통해 하이브 쿼리 속도를 100배 끌어올리겠다는 비젼을 내 놓았습니다. 이것이 바로 스팅어(Stinger)입니다.

하이브를 버리고 새로운 엔진을 찾아야 한다는 진영은 그루터의 타조와 클라우데라의 임팔라가 있습니다. 타조는 하이브를 개선하는데 한계가 명확하기 때문에 대용량 SQL 쿼리 분석에 적합하지 않다는 입장이며, 기획 단계부터 하이브를 대체하는 새로운 엔진을 개발하고 있습니다.

클라우데라의 임팔라는 좀 특이한 경우인데, 일정 규모 이상의 데이터는 임팔라로 분석이 불가능합니다. 임팔라는 메모리 기반 처리 엔진이어서, 일정 용량 이상에서는 디스크 환경의 하이브를 사용해야 합니다. 하지만 전체 틀에서는 하이브를 버리는 쪽으로 무게를 두고 있습니다.

[ 임팔라 스택 ]

대표적인 Hadoop 솔루션 업체로는 클라우데라(Cloudera)와 호튼웍스(Hotonworks)가 있습니다. 클라우데라는 빅데이터와 클라우드시장의 고육 및 기술지원을 제공하고 있으며, 호튼웍스는 하둡 코어기술과 아키텍처 개선을 담당하고 있습니다. 또, IBM은 아파치 하둡 (Apache Hadoop)을 기반으로 자신들의 Basic, Enterprise 배포판을 가지고 있고, 오라클(Oracle)은 자신들의 하드웨어에 클라우데라를 결합한 하둡 어플라이언스(Hadoop Appliance)를 제공하고 있습니다.

타조는 그루터에서 만든 하둡 기반의 차세대 빅데이터 분석 처리 엔진입니다. 기존 시스템과 통합을 하거나 이를 대체할 수 있도록 표준 SQL을 지원합니다. 또한 CPU와 메모리를 적절히 활용하여 높은 처리 성능을 보장합니다. 타조는 기존 하둡 빅데이터 처리엔진인 하이브(Hive)보다 10배에서 100배까지 빠르게 데이터를 처리할 수 있습니다. 타조와 같은 인터렉티브 분석(IA, Interactive Analysis) 기술과 하둡 생태계 기술들을 최적화할 경우, 관계형 데이터베이스에서 제품군에서 제공하는 뛰어난 성능의 상용 데이터웨어하우스(DW, Dataware house) 제품들을 대체할 수 있습니다.

타조는 하둡 기반의 대용량 데이터웨어하우스(DW) 시스템을 목표로 하는 솔루션으로 현재 아파치 인큐베이션 프로젝트(http://tajo.incubator.apache.org/)로 진행중인 오픈 소스 프로젝트이며, 그루터가 개발을 주도하고 있습니다. 타조는 분산된 저장소에 저장된 데이터를 SQL질의를 분산 실행시켜 빠르게 데이터를 처리하는 기능을 제공하는 플랫폼입니다.

기존 맵-리듀스 기반 분석 시스템

하둡(Hadoop)은 대규모 데이터의 분산처리를 위한 오픈 소스 프레임워크입니다. 하둡은 크게 데이터를 저장할 수 있는 하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)과 저장된 데이터를 처리하는 맵-리듀스(Map-Reduce)로 구성되어 있습니다. 하둡은 크게 3가지의 장점을 가지고 있습니다.

첫번째는 유연성입니다. 데이터베이스에 저장되어 있는 정형화된 데이터나, 트위터와 페이스북에서 생성되는 비정형화된 데이터등 여러 형태의 다양한 데이터 포맷을 지원해 주며, 자바(Java), 루비(Ruby), 파이썬(Python)등과 같은 범용 프로그래밍 언어를 이용하여 다양한 분석 알고리즘 적용이 가능합니다.

두번째는 확장성입니다. 하둡은 노드(Node)를 증가함에 따라서 성능과 용량이 선형적으로 증가합니다. 시스템의 성능을 높이기 위해서 프로그램과 리소스를 튜닝하는것보다 노드(Node)와 같은 장비를 확장함으로써 더 좋은 성능을 발휘할수 있습니다.

마지막으로 비용입니다. 하둡은 x86과 같은 저가의 노드(Node)들을 서로 연계시켜도 성능면에서 떨어지지 않는 장점을 가지고 있습니다. 또한 이러한 저가의 서버들을 수십대에서 수만대까지 연계시킬 수 있으므로 대용량의 데이터를 처리하는데 저 비용으로 시스템을 구축할 수 있습니다.

하이브(Hive)

하이브는 하둡 기반의 데이터웨어하우스(DW, Data warehouse)입니다. 하이브는 HiveQL(Hive Query Language)이라는 SQL과 유사한 언어로 만들어졌습니다. 하이브는 사용자가 HiveQL으로 명령어를 입력하면 하이브는 내부적으로 맵-리듀스 작업으로 변환하여 처리를 합니다. 초기에 하이브가 사용자들에게 사랑을 받은 이유가 맵-리듀스라는 프로그래밍 언어를 알지 못해도, HiveQL를 사용하여 쉽게 하둡 분산 파일 시스템에 저장되어 있는 데이터를 분석할 수 있습니다.

맵-리듀스의 문제점

맵-리듀스는 배치 처리(Batch processing)를 목적으로 만들어진 시스템으로 맵과 리듀스간의 셔플링(Shuffling) 작업에 많은 시간을 허비하여 실시간 분석에 적합하지 않은 문제점을 가지고 있습니다.

셔플링(Shuffling)이란 메모리에 저장되어 있는 맵 함수(Map function)의 출력 데이터를 파티셔닝과 정렬을 해서 로컬 디스크에 저장한 후에 네트워크를 통해 리듀서의 입력 데이터로 전달하는 과정을 말합니다.

문제는 분산된 수많은 노드(Node)에서 수집한 맵 함수에 대한 결과들을 하나의 리듀스 서버로 전달을 해야 합니다. 이 과정에서 네트워크에 많은 부하가 발생하게 되며, 맵 과정에서도 빈번하게 하둡 분산 파일 시스템(HDFS)에 데이터를 읽고 쓰는 작업을 반복해야 함으로써 분석 성능을 저하시키는 원인이 됩니다.

하이브의 문제점

하이브는 HiveQL이라는 언어를 통해서 맵-리듀스 언어로 변환이 되어서 맵-리듀스 처리를 해야합니다. 이러한 이유로 맵-리듀스의 모든 문제점을 가지고 있습니다. 맵-리듀스을 처리하기 위해서 수행되는 여러 개의 태스크(Task)들이 실행되어서 준비되는 시동시간이 5~15초에 달합니다. 그리고 HiveQL이 SQL과 유사한 언어이지만, 표준 SQL(Ansi SQL)과는 많은 차이가 있습니다.

SQL 온 하둡

하둡 기반의 차세대 분석 엔진을 의미합니다. 기존 하둡이 가지고 있는 맵-리듀스와 하이브(Hive)의 문제점을 개선하여 실시간 분석이 가능하도록 시스템을 개선한 것입니다. SQL 온 하둡의 특징은 다음과 같습니다.

① SQL 표준 지원

기존 관계형 데이터베이스에서 사용하던 SQL을 그대로 사용하도록 표준 SQL 문법을 준수합니다. 이를 통하여 SQL에 친숙한 분석가들과 사용자들을 하둡으로 전향할 때 발생할 수 있는 거부감을 줄여줄수 있습니다.

② 높은 처리 성능

기존의 맵-리듀스를 사용하지 않고 실시간 분석이 가능한 새로운 분산 처리 프레임워크를 사용하고 인-메모리(In-Memory) 기능의 활용과 CPU 사용을 극대화 시키는 기술을 도입하여 낮은 반응 시간(Low latency)이 나오도록 지원합니다.

③ 성능에 대한 보장

맵-리듀스는 프로그래밍 언어로서 개발자의 역량이 중요합니다. 같은 내용의 프로그램이라고 할지라도 누가 만들었는지 어떤 방식으로 설계했는지에 따라서 성능에 큰 차이가 나타날 수 있습니다. 또한 존재하는 버그를 찾는데 많은 시간과 노력을 필요로 합니다. 하이브(Hive)의 경우에도 사용자가 어떻게 질의를 했는가에 따라서 성능에 큰 영향을 미칩니다. SQL 온 하둡은 사용자에 의해서 발생할 소지가 있는 문제점들을 분석 시스템에서 자동적으로 보정해주는 작업을 진행하여 똑같은 성능이 나오도록 보장을 해 줍니다.

타조의 특징

타조는 하둡 기반의 데이터웨어하우스(DW, Data warehouse)이며, HDFS및 다양한 형태의 데이터를 추출하고 분석 시스템에 전송하여 집계 및 연산, 조인, 정렬 기능을 제공합니다.

① 호환성

표준 SQL을 지원하여 기존 사용자들이 사용하는데 거부감이 없으며, 사용자들이 함수를 작성하여 사용할수 있도록UDF(User Defined Function)를 지원합니다. 그리고 JDBC를 지원하고 있으며, ODBC는 추후 지원할 계획입니다.

② 고성능 및 낮은 반응 시간(Low latency)

맵-리듀스를 사용하지 않고 유연하고 효율적인 분산 처리 엔진을 자체 개발하여 사용하고 있으며, 비용 기반 최적화 엔진(cost-based optimization)과 JIT Query Compliation 및 Vectorized 질의 엔진을 사용하고 있습니다.

③ 오픈 소스 (http://tajo.incubator.apache.org)

클라우데라에서 만든 임팔라의 경우 오픈 소스이지만, 사용자들이 개발에 참여할 수 없지만, 타조는 오픈 소스이며 사용자 참여가 모두 가능합니다.

타조의 목표

① 잘못된 질의에 대한 최적화

맵-리듀스와 하이브의 경우에는 작성하는 개발자의 능력에 따라서 성능이 다르게 나오는 문제점을 가지고 있으며, 하이브에서는 ‘From’ 절의 배치 순서에 따라서 나오는 결과가 수분 또는 몇시간이 걸릴 수 있습니다. 타조에서는 사용자가 입력한 질의에 대해서 엔진에서 최적화가 될수 있도록 보정 작업을 진행합니다.

② 분산 처리 프레임워크

맵-리듀스의 경우 하나의 테스크를 시작하는데 걸리는 시간이 수십밀리 초에서 1초 정도 걸리고 맵과 리듀스 작업을 위해서 데이터를 네트워크를 통해서 전송하는데 많은 병목현상이 발생합니다. 이러한 문제점을 해결하여 실시간 분석이 가능한 분산 처리 프레임워크를 개발하였습니다.

Master-Worker 모델

전형적인 Master-Worker 모델입니다. 마스터(Master)가 존재하고 마스터가 발생하는 작업들을 하부에 있는 워커(Worker)들에게 할당하는 구조입니다. 네티(Netty)나 Protocol Buffer등을 이용하여 RPC(Remote Procedure Call)로 마스터와 워커간의 통신을 담당합니다.

① 마스터(Master)

타조 마스터는 쉘 커맨드나 프로그램에서 보내온 질의에 대한 처리를 담당하며, 카탈로그 서버(메타 서버)에서 테이블 스키마나 물리적인 정보와 각종 통계 자료들을 보유하고 있습니다. 마스터는 또한 쿼리를 파싱하고 최적화하여 동일한 성능을 보장을 해주며, 클러스터 자원들을 관리하는 역할를 수행합니다.

② 워커(Worker)

워커는 쿼리 마스터(Query Master)와 타조 워커(Tajo Worker)로 구성이 되어 있으며, 질의에 대한 처리를 담당합니다. 질의 하나당 쿼리 마스터 하나가 생성되며, 질의에 대한 수행 계획과 최적화 작업을 진행합니다. 쿼리 마스터가 여러 개의 타조 워커(Tajo Worker)를 띄워서 물리적인 데이터를 HDFS에 데이터를 쓰고, 읽는 작업을 진행합니다. 그리고 로컬에 질의 엔진을 가지고 있어서 할당 받은 작업을 수행합니다. 타조 워커는 기존에 자바로 구현이 되어 있는데, 속도 향상을 위해서 C++로 대체하는 작업을 진행중입니다.

다음 그림은 타조의 구조를 나타냅니다. 타조 클라이언트에서 질의가 들어오면 타조 마스터에서 질의에 대한 계획을 세우고 리소스를 받아서 쿼리 마스터를 띄워서 질의를 수행하기 위해서 타조 워커(Tajo Worker)에게 질의를 할당하는 작업을 진행합니다.

[ 타조의 구조 ]

질의 계획 및 최적화 엔진

① 비용 기반 최적화 (Cost-based optimization)

조인 순서를 사용자에게 의존하지 않고 최적의 성능이 나오도록 엔진이 스스로 조인 순서를 결정합니다.

② 확장 가능한 Rewrite Rule 엔진

기존에 상용 데이터베이스에서 지원하는 확장 가능한 Rewrite rule를 사용하여 튜닝이 가능하도록 지원합니다.

③ 적응형 최적화 (Progressive query reoptimization)

질의가 실행되는 시간에 통계 정보를 바탕으로 질의의 남은 부분들을 최적화할 수 있으며, 나쁜 질의에 대해서는 회피도 가능합니다.

④ 데이터 셔플(Shuffle) 방법

기존에 맵-리듀스에서 사용하던 해쉬(Hash) 뿐만 아니라 레인지 파티션(Range Partition)도 지원합니다. 레인지 파티션은 각각의 서버들에게 할당된 범위안에서 데이터 처리를 분배해주는 방법입니다.

⑤ 데이터 전송 방법

기존의 데이터 전송 방식은 풀(Pull) 방식입니다. 풀 방식이란 중간 데이터를  저장을 해 놓으면 필요한 워커들이 데이터를 끌어가는 방식을 말합니다. 지금은 푸쉬(Push) 방식을 사용하는데 중간 과정의 데이터를 디스크에 저장하지 않고 다른 워커에게 전송하는 방식입니다. 이 방식은 자원을 즉시 사용할 수 있어서 실시간 처리에 적합한 구조입니다.

⑥ Vectorized Engine

컬럼(Column) 방식으로 데이터를 처리합니다. 하나의 테이블이 있으면 컬럼 단위로 분할을 하며 분할된 컬럼들을 백터(Vector)라고 부릅니다. 벡터의 크기는 CPU 캐시 크기에 맞추어서, 행(row) 데이터 조회시 빠른 결과를 얻을 수 있습니다. 데이터 처리는 벡터 단위로 루프(Loop)를 반복해서 처리를 하며, 셀렉션 벡터(Selection vector)등과 같은 여러가지 기능들을 제공합니다.

[ Vectorized Engine ]

⑦ JIT (Just In Time) 코드 생성기

데이터 조회에 필요한 프리미티브(Primitive)를 미리 만들어 놓지 않고, LLVM(Low Level Virtual Machine)을 이용해서 런타임시에 실시간으로 생성합니다. LLVM은 프로그래밍 언어 컴파일러 집합으로 컴파일 시간이나 런타임 시간등 다양한 상황에서 최적화를 쉽게 구현할수 있도록 구성되어 있습니다.

NewSQL은 NoSQL처럼 높은 확장성과 성능을 갖춘 RDB를 일컫는다. SQL을 지원하고, SQL이 트랜잭션 데이터를 처리하기 위해 기업이 갖추고 있어야 할 4가지 속성인 ACID(Atomicity, Consistency, Isolation, Durability) 등록 정보를 준수합니다. 여기에 NoSQL의 특징인 확장성과 유연성을 데이터베이스 관리 시스템(DBMS)에 더했습니다. SQL과 NoSQL에서 장점만 뽑아 결합한 형태입니다.

하둡의 엔터프라이즈 시장 진입

빅데이터 표준 플랫폼은 하둡(Hadoop) 입니다. 하둡과 빅데이터의 엔터프라이즈 시장 진입이 계속 늦어지고 있습니다. 하둡 진영은 SQL 쿼리 분석을 하둡에서 보다 빠르게 수행할 수 있느냐를 열쇠로 보고 관련 기술을 개발하기 위해 노력중입니다.

SQL-온-하둡

‘SQL-온-하둡(SQL on Hadoop)” 혹은 ‘대화형(Interactive) 쿼리 엔진(Query Engine)’ 등으로 불리는 기술은 2012년부터 본격적인 개발경쟁 양상을 보였습니다. 클라우데라의 임팔라(Impala), 호튼웍스의 스팅거(Stinger), 맵R의 드릴(Drill)등이 대표적인 제품입니다. EMC 자회사 피보탈이니셔티브가 올해초 호크(HAWK)를 내 놓으며 엔터프라이즈 시장 진입에 출사표를 던졌습니다. 한국의 그루터도 ‘타조(Tajo)’ 개발에 박차를 가하고 있습니다.

아파치(Apache)의 하이브(Hive)

이 같은 움직임의 중심에 아파치 하이브(Hive)가 있습니다. 하이브는 하둡 분산 파일 시스템(HDFS, Hadoop Distributed File System)에 저장된 데이터를 SQL과 유사한 하이브QL(HiveQL)로 분석하게 해주는 기술입니다. 하지만 대용량 병렬처리(MPP, Massively Parallel Processing) 기반의 데이터웨어하우스(DW)에 비하면 하이브의 쿼리속도는 현저히 느립니다. 질의를 던질때마다 맵리듀스 작업을 매번 수행하기 때문입니다. 질의를 던지고 결과를 받기까지 수시간을 기다려야 합니다. 이 때문에 대화형 쿼리 분석엔 적합하지 않다는 평을 받고 있습니다..

빅데이터 관련업계는 하이브의 이 같은 한계를 극복해야 하둡이 엔터프라이즈 시장에 진입할 수 있을 것으로 보고 있습니다. 하이브가 SQL에 익숙한 사람들에게는 성에 차지 않습니다.

'SQL-온-하둡'의 두갈래 대처 방안

진영은 두갈래로 나뉩니다. 하이브를 완전히 대체하는 새 기술을 쓸 것인가? 아니면 하이브를 개선해 속도를 높일 것인가? 하지만, 하이브는 사실상 시한부 판정을 받았다는 쪽으로 여론이 흐르고 있습니다. 하이브를 만든 페이스북조차 ‘프레스토’란 새로운 데이터웨어하우스(DW) 엔진을 만들었습니다.

호튼웍스의 스팅어

하이브를 살려야 한다는 입장을 가장 강력하게 내세운 회사는 호튼웍스다. 호튼웍스는 하이브를 최적화하고 파일 포멧 작업을 통해 하이브 쿼리속도를 100배 끌어올리겠다는 비젼을 내놓았습니다. 호튼웍스는 하이브야말로 SQL-온-하둡을 위한 최고의 선택이라며 3단계에 걸친 개선계획을 발표했습니다. 이것이 바로 스팅어(Stinger)입니다.

호튼웍스는 하이브의 성능을 35~45배 끌어올리기로 했습니다. 다양한 쿼리 기능을 추가하고 ORCFile 같은 파일 포맷으로 성능을 끌어올리는 것이 2단계입니다. 그리고 맵-리듀스 대신 아파치 테즈(Tez)란 새 기술을 이용해 하이브에 접목합니다. 이를 통해 최종적으로 하이브의 SQL 쿼리 속도를 100배 향상시킨다는 것입니다.

그루터의 타조

하이브를 버리고 새로운 엔진을 찾아야 한다는 진영은 타조가 대표적이다. 타조는 하이브를 개선하는데 한계가 명확하기 때문에, 대용량 SQL 쿼리 분석에 적합하지 않다는 입장입니다. 애초 기획 단계부터 하이브를 대체하는 새로운 엔진으로 개발되고 있습니다.

클라우데라의 임팔라

클라우데라의 임팔라도 하이브를 대체하는 엔진입니다. 그러나 일정 규모 이상의 데이터는 임팔라로 분석할 수 없습니다. 임팔라가 메모리 기반 처리 엔진이어서, 일정 용량 이상에선 디스크 환경의 하이브를 사용해야 합니다. 그러나 SQL on Hadoop이란 전체 틀에선 하이브를 버리는 쪽으로 무게를 두고 있습니다.

하이브의 한계

구도상 하이브에 주요 회사중에서 호튼웍스만 전력을 기울이는 것처럼 보인다. 하지만, 호튼웍스도 장기적으로는 하이브를 유지하자는 입장으로 단정하기는 어렵다. 바로 스팅어의 핵심인 테즈 때문입니다. 테즈는 SQL 처리시 맵-리듀스를 대신하는 새 기술입니다. 다수 개발자들은 맵리듀스를 사용하지 않는 하이브는 하이브가 아니다라고 반문합니다. 맵-리듀스 와 하이브 조합을 버리는 순간 하이브라 부를수 없다는 것입니다.

호튼웍스의 입장을 십분 받아들인다고 해도 하이브의 한계는 뚜렷합니다. 호튼웍스가 최근 올린 블로그가 그 한계를 스스로 보여줍니다. TPC-DS 벤치마크에서 호튼웍스 데이터 플랫폼(HDP)2.0을 사용했을 때 44배의 속도개선을 보였다고 주장했습니다. 그런데 그 비교 대상이 최근버전인 하이브 0.11이 아니라 하이브 0.10버전입니다.

하이브는 0.10 버전에서 0.11버전으로 업데이트되면서 이미 32배의 속도 개선을 이루었습니다. 즉 호튼웍스의 주장은2007년에 만들어져 이제 거의 사용되지 않는 버전보다 44배 빠르다는 것이다. 직접 버전인 0.11과 비교하면 30% 가량 빨라졌을뿐입니다.

하이브의 미래

하이브의 미래에 대한 징후는 현재 개발되는 하이브 0.12버전의 코드 기여도 통계에서도 나타납니다. 호튼웍스가 공개한 자료에 의하면, 하이브 0.12 코드라인 기여자 소속회사 통계(8월 30일 기준)에서 호튼웍스는 8만 3천 742라인으로 절반을 훌쩍 넘긴 비중을 차지합니다. 다음으로 페이스북이 3만 148라인을 차지합니다. 세번째로 많은 기여자는 한국의KT 넥스알입니다. KT 넥스알은 1만2천 103라인을 기여했습니다. 다음은 4천244라인을 기부하였으며, 클라우데라는 3천528라인을 기부했습니다.

주목할 부분은 페이스북과 클라우데라 입니다. 페이스북은 하이브 0.10을 내 놓는데 가장 많은 비중을 차지했던 회사입니다. 그런 페이스북이 점차 하이브에 대한 관심을 줄여가고 있는 것입니다. 호튼웍스와 함께 아파치 하둡 프로젝트의 주요 기여자인 클라우데라의 기여도는 호튼웍스의 2%에 불과합니다. 주요 기여자의 참여축소와 기타 기여자의 비중도 확연히 줄었습니다.

하둡 진영이 ‘SQL-온-하둡’에 열을 올리는 이유

하둡 생태계는 왜 하이브와 SQL on Hadoop에 이토록 열을 올리고 있는가? 이는 SQL을 쓸수 있는냐가 엔터프라이즈 시장에서 하둡을 사용하느냐로 직결되기 때문입니다.

엔터프라이즈는 데이터웨어하우스(DW) 시스템과 고급 분석도구, 비즈니스 인텔리젼스(BI)를 사용하는 집단입니다. 기업의 분석가 집단이 주요 사용자입니다. 이들은 정형화된 데이터를 이용해 여러 분석을 시도하는데, 간단한 SQL 쿼리만 활용할 뿐 복잡한 프로그래밍 능력은 갖고 있지 않습니다. 프로그래밍은 IT 부서의 일이라 여깁니다. 분석가는 분석을 할 뿐 기술엔 관심이 없습니다.

기업 분석가 집단이 보기에 하둡은 생소하고 어려운 기술일 수밖에는 없습니다. 자신들은 잘 알지도 못하는 다양한 프로그래밍 작업을 요구하기 때문입니다. 현존 데이터 분석도 만족스러운데 굳이 본업도 아닌 프로그래망까지 하려니 당연히 필요성을 못 느낍니다. SQL과 유사한 도구인 하이브도 그 속도가 너무 느립니다.

하이브를 만들어낸 회사는 인터넷서비스 회사인 페이스북입니다. 하이브를 가장 많이 활용하는 회사도 페이스북입니다. 하둡과 하이브를 다양하게 사용하는 회사도 야후, 넷플릭스, 트위터, 페이스북과 같은 인터넷 서비스 회사들은 여러 사람이 사용하기 바라는 마음으로 하둡과 하이브를 만들지 않았습니다. 이 회사의 개발자들은 자사의 서비스를 개선하는 과정에서 SW를 만들고, 그를 외부에서도 쓸 수 있게 공개한 것 뿐입니다. 페이스북이 만든 하이브라면 페이스북 개발자가 활용하기 좋은 수준 정도로 만들어집니다. 엔터프라이즈 기업의 기대치와 당연히 거리가 있습니다.

개발자 입장에선 하둡과 하이브를 이용해 분석하는데 거리낌이 적습니다. 개발자로서 전문 분석가는 아니지만, 예전에 하지 못했던 분석을 할 수 있게 됐으니 그 정도 성능이면 충분하다고 느끼는 것입니다.

엔터프라이즈의 분석가와 인터넷 서비스 업체의 개발자 사이엔 높고 두터운 벽이 존재합니다. 빅데이터와 하둡이 엔터프라이즈 시장으로 진입하려면 기업 내 분석가를 설득해야 합니다. 데이터웨어하우스(DW)와 성능도 비슷하고 분석도 쉽다는 메시지를 앞세워야 합니다. SQL-온-하둡은 바로 이 벽을 지나는 문입니다.