류프리

구글 파일 시스템은 급속히 늘어나는 구글의 데이터 처리를 위하여 설계된 대용량 분산 파일 시스템입니다. 구글에서 사용하는 많은 소프트웨어는 GFS로부터 데이터를 읽어서 가공하고 그것을 다시 GFS에 저장합니다. GFS는 항상 파일들을 여러 개로 복제하여 보관합니다.

[ GFS 구조]

구글 파일 시스템은 마스터(Master), 청크 서버(Chunk Server), 클라이언트(Client)로 구성됩니다. 마스터는 GFS 전체의 상태를 관리하고 통제하는 중앙 서버 역할을 수행합니다. 청크서버는 물리적인 하드디스크에 실제 입출력을 처리하고, 클라이언트는 파일을 읽고 쓰는 동작을 요청하는 어플리케이션입니다.

[GFS 동작과정]

구글 파일 시스템의 동작과정을 살펴보면, 우선 클라이언트는 ①마스터에게 파일의 읽기/쓰기를 요청합니다. 요청을 받은 ②마스터는 클라이언트와 제일 가까운 청크서버의 정보를 클라이언트에게 전달해주고, ③클라이언트는 전달받은 정보를 바탕으로 청크서버와 직접 통신하며 파일의 읽기/쓰기를 실행합니다.

청크서버가 고장날 경우, 마스터는 고장나지 않은 청크 서버를 이용하여 파일의 읽기/쓰기를 실행할 수 있으며, 마스터 서버가 고장나는 경우, 별도의 외부 장비가 마스터 서버의 고장유무를 체크하여, 다른 서버가 마스터 서버의 기능을 대체하게 됩니다. 이러한 방식으로 무정지 기능(Failuer Tolerance)을 구현하고 있습니다.

인-데이터베이스는 데이터베이스 내에 분석을 직접 수행할 수 있는 기능을 포함하고 있습니다. 따라서 분석의 시점이 데이터베이스와 분석 소프트웨어의 분리로 인한 데이터의 처리 및 프로세스 등의 여러 단계를 거치지 않고 보다 신속하게 데이터를 분석할 수 있도록 지원할 수 있습니다.

또한 인-데이터베이스 방식은 자동화된 마이닝 프로세스와 실시간 혹은 실시간에 근접한 기능을 지원하는 분석을 가능하게 합니다. 이러한 기능을 지원하는 대표적인 인-데이터베이스는 테라데이터(Teradata), IBM 네티자(Netezza), 그린플럼(Greenplum), 애스터 데이터 시스템(Aster Data Systems)등과 같은 주요 데이터 웨어하우징 벤더들에 의해 지원됩니다.

이벤트 처리시스템의 도입 배경

최근의 기업의 경영환경은 빠르게 변화하고 있습니다. 기업은 시장과 고객요구 변화에 대한 실시간 이벤트 모니터링 및 문제 해결을 위한 신속한 의사결정과 민첩한 대응을 요구받고 있습니다. 이로 인하여 많은 기업들은 기업 내외의 이벤트들을 신속하고 효율적으로 처리해야하는 문제에 직면하고 있으며 이를 해결하기 위해서 많은 기업에서 복합 이벤트 처리 시스템을 도입하고 있습니다.

이벤트(Event)란?

이벤트란 특정 시스템 또는 영역 내에서 발생했거나, 발생한 것으로 간주되는 중요한 어떤 것을 말하며, 어떤 상태의 중요한 변화로도 정의할 수 있습니다. 이벤트 처리는 이벤트에 대한 처리를 수행하는 것으로, 보통의 이벤트 처리 수행은 읽기, 생성, 변형 그리고 삭제하는 것을 포함합니다

[ 이벤트 처리 ]

복합 이벤트 처리(CEP, Complex Event Processing)

복합 이벤트 처리는 이벤트 스트림이나 이벤트 클라우드 내에서 유의미한 이벤트를 식별하는 이벤트 처리 엔진이며, 분산된 다중의 이벤트를 처리하는 작업을 수행합니다. 복합 이벤트 처리는 공급망 관리, RFID, 금융시장 분석 그리고 비즈니스 활동 모니터링에서 중요한 기술입니다. 복합 이벤트 처리는 현재 산업에서의 필요성은 증가하고 있지만 연구는 아직 초기단계입니다.

[ 이벤츠 처리 과정 ]

이벤트 처리 유형에 따른 분류

많은 양의 이벤트를 처리하는 방법에는 심플 이벤트 처리(Simple Event Processing), 스트림-이벤트 처리(Stream-Event Processing)과 복합 이벤트 처리(Complex Event Processing) 가 있습니다. 심플 이벤트 처리는 발생한 이벤트들을 모두 의미 있는 이벤트로 간주하며, 이벤트 스트림 처리는 의미 있는 이벤트와 무 의미한 이벤트가 같이 발생하며, 주로 대량의 이벤트를 대상으로 하여 필터링을 통해서 의미 있는 이벤트를 추출합니다. 복합 이벤트 처리는 이벤트와 이벤트 사이의 상관관계를 이용한 복합 이벤트를 분석하여 각각의 이벤트를 검출하는데 중점을 두고 있습니다.

이 두 기술은 상호 보완적인 관계에 있으며, 이벤트 스트림 처리 기술을 복합 이벤트 처리 기술의 일부 요소로 보기도 합니다. 이벤트 처리의 핵심은 단순히 많은 이벤트 사례를 확보하는 것이 아니라 서로 다른 다양한 이벤트의 상관관계를 분석하여 조치 가능한 패턴을 검출하는 것입니다. 복합 이벤트 처리에는 타임스탬프와 같은 시제적인 제약조건을 사용할 수 있습니다.

이벤트 처리과정은 크게 1) 이벤트 수신 단계, 2) 이벤트 수집, 분석, 필터링 단계 3) 새로운 액션으로 연결시키는 단계 등으로 나눌수 있습니다. 

RSS(Really Simple Syndication)를 통한 데이터 수집

RSS(Really Simple Syndication)는 다양한 웹 사이트의 콘텐츠를 요약하고 상호 공유 할 수 있도록 만든 XML기반의 간단한 콘텐츠 배급 프로토콜입니다. RSS는 뉴스나 공지 사항과 같이 콘텐츠가 자주 갱신되는 웹 사이트의 정보를 이용자들에게 실시간으로 쉽고 빠르게 제공하기 위해 만들어진 포맷입니다.

RSS 제공자는 RSS 피드 (feed)의 형태를 통하여, 콘텐츠를 배포하고, 이용자는 RSS 리더 프로그램을 이용하여 RSS 채널을 등록하고 원하는 RSS 피드를 읽을 수 있습니다.

[ RSS 네트워크 ]

RSS의 네트워크는 3개의 주용한 컴포넌트로 구성이 되어져 있습니다. 1)컨텐츠 제공자 (Content Provider)는 각 제공 뉴스 정보와 자신의 정보에 관한 RSS 파일을 제공합니다. 2)수집자 (Content Aggregator)는 다양한 경로를 통해 RSS 정보를 읽거나 수집하는 콘텐츠 수집자 (Content Aggregator)로서 인덱스를 수집하고 그 인덱스를 통해 화제가 되는 특정 뉴스의 헤드라인을 수집하고 제공합니다.  3)헤드라인 뷰어 (Headline Viewer)는 이용자가 RSS 리더 프로그램을 통하여 콘텐츠를 제공 받고 읽을 수 있습니다.

주도적 정보생산을 통한 직접적인 데이터의 수집

마지막 수집 방법으로는 정보생산 주체로부터 직접 데이터를 수집 받는 방법입니다. 웹사이트 홈페이지를 통하여 설문조사와 같이 사용자로부터 직접 데이터를 수집하는 방법등이 여기에 해당합니다.

데이터를 직접 수집의 장점으로는 수집되는 데이터가 명확히 정의되어 있어 활용이 쉽다는 것입니다. 왜냐하면 기존에 운영중인 데이터베이스에 저장된 데이터를 활용한다는 것은 이미 데이터와 관련된 정보구조를 가지고 데이터를 이미 확보하였기 때문입니다. 또 다른 장점으로는 데이터 수집 시 수집정보의 동의에 있어서 명확히 사용자의 동의를 받을 수 있다는 점입니다.

웹 크롤러(WebCrawler)

웹의 크기가 폭발적으로 증가함에 따라 인터넷에서 정보를 얻는 수단으로 검색엔진의 존재는 매우 중요합니다. 검색엔진은 웹 페이지를 수집, 색인하여 검색 결과를 사용자에게 보여주는 역할을 담당합니다. 검색엔진의 근간이 되는 웹 크롤러는 인터넷상에 존재하는 웹 문서들을 추적하여 필요한 정보를 수집하는 기술을 말하며, 검색시스템, 전자상거래 상품검색, 인트라넷 검색 소프트웨어 등 현재 대부분 인터넷 산업의 근간이 되는 핵심 기술입니다.

또한 웹 크롤러는 링크 체크나 HTML 코드 검증과 같은 웹 사이트의 자동 유지 관리 작업을 위해 사용되기도 하며, 자동 이메일 수집과 같은 웹 페이지의 특정 형태의 정보를 수집하는 데도 사용됩니다.

웹 크롤러는 최초의 탐색을 위하여 시드(seed)라고 불리는 URL 리스트를 이용하여 탐색을 시작하며, 페이지 내에 존재하는 모든 하이퍼링크를 인식하여 URL리스트를 갱신하고, 갱신된 URL 리스트는 재귀적으로 다시 방문합니다.

웹 서버를 순회하며 각 홈페이지에 있는 텍스트 정보, 수치 정보, 사실 정보, 그림 정보, 멀티미디어 정보 등 수 많은 정보를 수집하며, 자동으로 웹 페이지의 내용을 분석하고 그 안의 포함되어 있는 URL들을 추출한 후 그 URL들로 하나씩 이동하면서 정보를 수집합니다.

웹 크롤러의 기본적인 요구사항으로 문서 수집 속도가 빠른 웹 크롤러가 가장 성능이 우수한 웹 크롤러라고 말할 수 있습니다. 속도를 향상시키기 위해서 멀티프로세스 (또는 멀티 쓰레드)를 사용합니다. 주의할 사항은 멀티프로세스가 같은 서버에 동시에 접속을 하게 되면 네트워크와 서버에 과부하를 발생시킬 수 있으므로 일정 시간 간격을 두고 접근하도록 통제를 해야 합니다.

기업에서 관리하고 있는 데이터베이스(B, Database)에 저장되어 있는 정형데이터를 수집하는 기술로는 아파치에서 만들어진 스쿱(Sqoop)프로그램이 있습니다.

아파치 스쿱(Apache Sqoop)

스쿱(Sqoop)은 하둡(Hadoop)과 관계형 데이터베이스간에 정형 데이터를 전송할 수 있도록 설계된 도구입니다. MySQL이나 오라클(Oracle)과 같은 관계형 데이터베이스 관리 시스템(RDBMS)으로부터 하둡 분산 파일 시스템(HDFS)으로 데이터를 가져오는데 스쿱을 이용할 수 있습니다. 스쿱은 데이터를 가져오고 내 보내는데 있어서 병렬연산과 고장방지기능을 제공하는 맵리듀스(MapReduce)를 사용합니다.

예를 들면, Oracle DB상에 적재된 대량의 로그성 데이터를 HDFS로 옮겨 분산처리를 하기위해, 쉽게 데이터를 Import 할 수 있으며, 반대로 분석의 결과나 HDFS의 데이터를 RDB로 Export 할 수 있습니다. 또한 저장된 결과를 Hive, Pig, HBase 등을 통해서 확인 할 수 있습니다.

[ Sqoop Import / Export ]

Sqoop Import

Import 하는 과정은 먼저 가져올 데이터의 메타 정보를 가져온 후에, Map-only Hadoop Job으로 데이터를 클러스터로 보냅니다.

[ Sqoop Import ]

Import 프로세스의 입력은 데이터베이스 테이블입니다. Sqoop은 테이블을 행 단위로 HDFS로부터 읽어들입니다. 출력은 가져온 테이블의 복사본을 포함하는 파일 집합입니다.

Sqoop Export

HDFS 상의 데이터를 RDB로 Export하는 경우도 마찬가지입니다. 먼저 데이터베이스의 메타데이터를 가져온 후, 데이터를 이동시킵니다.

[ Sqoop Export ]

Export 프로세스는 병렬로 HDFS로부터 구분된 텍스트 집합을 읽어서, 레코드의 형태로 구문 분석하고 목적 데이터베이스 테이블의 새 행으로 레코드들을 삽입합니다.

빅데이터 분석 가시화 기술은 비 전문가가 데이터 분석을 수행할 수 있는 환경을 제공하는 분석도구 기술과 분석 결과를 함축적으로 표시하고 직관적인 정보를 제공하는 인포그래픽스 기술로 구성됩니다.

대표적인 분석도구 기술의 예로 R이 있으며, 인포그래픽스 기술로 InVis(An Interactive Visualization Framework for Massive Data supporting Multiple Users)가 있다.

R은 데이터 분석을 위한 통계 및 그래픽스를 지원하는 무료 소프트웨어 기반의 데이터 분석 엔진입니다. 그 뿌리는 벨 연구소의 S 언어에 두고 있으며, R은 S 언어를 근간으로 뉴질랜드의 오클랜드 대학교(University of Auckland)에서 로스 이하카(Ross Ihaka)와 로보트 젠틀맨(Robert Gentleman)이 만든 것이 그 시작입니다. 최근에는 하둡과의 연동을 지원하는 라이브러리로 인하여 빅데이터 분석과 데이터 마이닝 툴로 급격히 관심을 받고 있습니다.

R은 하나의 완성된 언어 체계이며, 자유롭게 데이터 분석을 R 안에서 수행할 수 있다는 장점이 있습니다. 또한 R은 통계, 머신 러닝, 금융, 바이오 인포머틱스, 그래픽스에 이르는 다양한 통계 패키지를 가지고 있으며, 이 모든 것이 무료로 제공됩니다.

무료이지만 기능면에서 상용 플랫폼들과 등등하거나 뛰어난 기능을 제공합니다. 윈도우(Window), 맥(Mac), 리눅스(Linux) 등 대부분의 OS에서 동작하며 객체지향 특성과 함수형 언어의 특성을 모두 지원합니다. 또한 많은 통계학자들이 수 많은 함수를 무료로 공유하고 있습니다.

R의 가장 큰 장점은 우리가 생각하는 기능들을 이미 누군가가 패키지로 만들어 두었고 또한 누구나가 패키지로 만들어 공유할 수도 있습니다. R을 잘 사용하는 방법은 어떤 패키지를 선택하여 사용하면 되는지를 아는것입니다.

시각화의 중요성

빅데이터에서는 자료의 양이 방대해서 사람이 일일이 검토하는 것은 불가능에 가깝습니다. 분석 내용을 간단하게 평균, 표준편차 등의 요약된 통계량을 가지고서는 복잡한 문제를 설명하기에는 부족한 면이 많습니다. 또한 이를 기반으로 타인을 설득하기에도 한계가 있으며, 빅데이터 처리 플랫폼에서 분석 내용을 빨리 산출한다고 해도 사람들에게 분석 내용의 가치를 인정 받지 못하면 소용이 없습니다. 이로 인하여 데이터의 중요성을 고객에게 빠르게 설득시킬수 있는 데이터 시각화가 필요한 것입니다.

R 프로그래밍

R은 AT&T에서 개발된 S언어의 오픈소스 버전으로 약 20년이 넘는 역사를 가진 통계 컴퓨팅(Statistical Computing) 언어이며 데이터 시각화를 위한 훌륭한 환경입니다. 대표적인 함수형 언어인 Lisp에서 파생된 언어 특징을 포함하고 있으며, 그와 동시에 절차적인 문법구조도 지원하며 모듈화된 패키지 개발을 위해 객체 지향적인 요소들도 포함하고 있습니다. 특히나 함수형 언어의 특징 덕분에 간결한 코드를 구현할 수 있으며, 병렬화 처리 전환이 쉬운 장점이 있습니다.

인테렉티브 쉘을 제공하고 있어서 코드 결과를 바로 실행해서 확인할 수도 있으며, 이로 인하여 정확하고 빠른 프로그래밍이 가능합니다. R은 분석 업무를 구석 구석 최고로 다룰 수 있는 툴과 같은 역할을 담당하며 통합 개발 환경(IDE)도 제공하고 있습니다.

메뉴 방식으로 분석을 수행할 수 있는 R-커맨더, 데이터 마이닝(Data mining)을 보다 편하게 할 수 있는 래틀(Rattle), 분석에 있어서 사용자의 편의성을 높인 레드(Red)-R, R 스크립트 작성을 보다 편리하게 할 수 있는 R 스튜디어, 엑셀과 쉽게 연동해서 분석할 수 있는 R-엑셀등의 부가적인 패키지들을 제공하고 있습니다.

R 프로그래밍에 대한 구체적인 내용은 “R 기반의 데이터 시각화” 한글 문서를 참고해 주십시오.

R과 하둡(Hadoop)과의 연계

빅데이터의 분석을 위한 오픈소스 플랫폼인 하둡(Hadoop)은 페이스북, 아마존, 야후, 트위터 등에서 사용되면서 각광을 받고 있습니다. R은 하둡 스트리밍 기술을 활용하여 분산 처리에 기반한 데이터 분석 엔진으로 활용되어지고 있습니다. 특히 패키지 RHIPE(R and Hadoop Integrated Processing Environment)가 소개되며, R은 하둡에서 통계분석을 위한 엔진으로 자리를 잡았습니다. 

R을 활용하는 업체들

① Revolution Analytics

Revolution Analytics사의 Revolution R은 표준 R 환경에 기능 확장을 추가하여 병렬 분산 처리를 가능하게 하는 소프트웨어 제품을 판매하고 있습니다. R은 CRAN의 패키지등을 이용하여 병렬 분산 처리 환경을 구축할 수도 있지만Revolution Analytics의 R을 이용해도 동일한 환경을 구축할 수 있습니다.

② 오라클

Oracle R Enterprise라는 제품이 나와 있습니다. R 언어의 명령어, CUI 조작성은 그대로 유지하면서 오라클 데이터베이스에 접속하여 대용량 데이터를 이용한 통계 분석을 할 수 있습니다.

③ IBM 네티자(Netezza)

R 언어의 명령어, CUI 조작성은 그대로 유지하면서 Netezza 내부에 저장된 대용량 데이터에 대해 직접 통계 분석을 할 수 있습니다. Netezza 상의 R 언어는 분석 처리를 수식과 데이터에 대한 포인터로 보유하여 데이터 연산이 필요한 시점에 데이터를 불러와서 고속 병렬 처리를 할 수 있습니다.

④ SAP Sybase

SybaseIQ는 컬럼 지향 데이터웨어하우스(DW, Data Warehouse)의 대표 주자로 분석용 데이터웨어하우스로서 고속 성능을 기대할 수 있는 제품입니다. 또한 어플라이언스 제품이 아닌 소프트웨어 기반의 데이터웨어하우스이므로 확장성도 우수한 것으로 알려져 있습니다.

⑤ SAP HANA

독일 SAP사의 인-메모리(In-Memory) 데이터베이스 HANA도 R과의 연계 강화에 노력하고 있습니다. HANA DB 내부에서 R 스크립트를 실행할 수 있으며, R 언어가 가진 고급 통계 분석 기법을 HANA 상에서 이용할 수 있습니다.

R의 경쟁 제품들

R와 SAS, SPSS 등의 다른 통계 분석 소프트웨어의 가장 큰 차이점은 R은 오브젝트 기반 개체 지향 언어라는 것입니다.  또한 자바나 파이썬(Python), 닷넷, 비주얼 스튜디어 등의 다른 개발 플랫폼과 인터페이스를 위한 API(Application Programming Interface)를 제공해서 쉽게 연동이 가능합니다. 이를 통해서 패키지를 쉽게 구현할 수 있습니다.

① SAS

최근 R이 데이터 분석 소프트웨어로 주목을 받고 있지만 선두주자는 SAS라 할수 있습니다. SAS/IML을 이용하면 R에서 생성된 행렬 및 데이터 프레임을 SAS 데이터 셋으로 변환하거나 R 코드를 그대로 실행하여 결과를 SAS로 받아오는 것이 가능합니다.

② IBM SPSS

SPSS에서도 R 언어와의 연동을 가능하게 해주는 패키지를 보유하고 있습니다.

R 개발 참고 사이트

①    R 홈페이지

http:://www.r-project.org

②    R 소스코드

CRAN(Comprehensive R Archive Network) http://cran.r-project.org 에서 R의 소스코드 및 Windows, Linux, Mac OS X 용으로 컴파일된 바이너리 파일을 얻을 수 있습니다. 통계 분석에 특화된 패키지도 이곳에서 제공합니다.

③    R 참고자료

 •       An Introduction to R

 •       Practical Regression and ANOVA in R

 •       R by Example

•       UCLA’s R resources

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

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

[ 하둡 2.0 스택 ]

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

YARN의 구조

YARN은 리소스 매니저(Resource Manager)와 노드 매니저(Node Manager) 두 종류의 데몬(Daemon)으로 구성되어 있습니다. Resource Manager는 클러스터 전체를 관리하는 마스터 서버의 하나 존재하고 각 노드마다 Node Manager 존재하며, 각 프로그램 마다 Application Master가 존재합니다. 기존의 맵-리듀스에서는 프로그램에서 맵과 리듀스 작업만을 담당했지만, YARN에서는 맵-리듀스 작업도 가능하고 다른 용도의 분산 프로그램 또한 만들수 있습니다. 그 대표적인 예로 UC Berkeley AMPLab의 Spark나 클라우데라의 임팔라(Impala) 등이 있습니다.

[ YARN의 전체 구성도 ]

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

리소스 매니저(Resource Manager) 내부에는 스케쥴러(Scheduler)와 프로그램 매니저(Application Manager)라는 두개의 메인 컴포넌트로 구성되어 있습니다. Scheduler는 Node Manager들의 자원 상태를 관리하며 부족한 리소스들을 배정합니다. 또한 프로그램의 상태를 검사하거나 모니터링 하지 않으며, 순수하게 스케쥴링 작업만 담당합니다. 프로그램 오류나 하드웨어의 오류로 문제가 발생한 프로그램을 재 시작시켜주지 않으며 프로그램에서 요구하는 리소스(CPU, Disk, 네트워크등)에 관련된 기능만 처리합니다.

Application Manager는 Node Manager 데몬에서 특정 작업을 위해서 Application Master를 실행하고, Application Master의 상태를 관리합니다. 여기서 Application Master라는 용어가 나오는데 YARN에서 실행되는 하나의 작업을 관리하는 마스터 서버를 말합니다.

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

노드 매니저는 노드(컴퓨터) 당 한 개씩 존재합니다. 해당 컨테이너(Application Container)의 리소스 사용량을 모니터링 하고 관련 정보를 리소스 매니저에게 알리는 역할을 담당합니다. 프로그램 마스터(Application Master)와 프로그램 컨테이너(Application Container)로 구성되어 있습니다. 먼저 Application Master는 하나의 프로그램에 대한 마스터 역할을 수행하며 스케쥴러로부터 적절한 Application Container를 할당 받고, 프로그램 실행 상태를 모니터링하고 관리합니다. Application Container는 프로그램에 할당된 자원을 나타냅니다.

[ YARN 상세 구조도 ]

YARN의 맵-리듀스 절차

① 사용자에게 맵-리듀스 작업을 요청 받습니다.

② Application Manager는 Scheduler에게 Node Manager를 할당 받습니다.

③ 해당 Node Manager의 Application Master의 실행을 요청 합니다.

④ Application Master는 Scheduler에게 Application Container를 실행하기 위해서 Node Manager의 목록을 할당 받습니다.

⑤ Application Master는 Application Container를 실행합니다.

구글 ‘빅 쿼리’는 빅 데이터를 클라우드 상에서 대화식으로 신속하게 분석해주는 클라우드 기반의 서비스입니다. 이용자가 구글 클라우드 스토리지에 분석하고자 하는 데이터를 업로드하면 웹 브라우저를 통해 해당 데이터가 분석됩니다. 따라서 기업은 별도 인프라를 구축하지 않고도 데이터를 분석할 수 있습니다.

빅 쿼리는 초당 수십억 행 단위 데이터를 다룰 수 있도록 도와주는 온라인 분석 프로세싱(OLAP) 시스템으로, 탐색 범위를 테라(Tera) 바이트 규모까지 확장할 수 있습니다. 빅 쿼리 인프라를 사용해 기업들은 자체 서버와 솔루션을 구축하지 않고도 데이터를 저장하고, 이를 실시간으로 다룰 수 있도록 초점을 맞추고 있으며, 분석하는 프로그램 역시 빅 쿼리를 통해 개발해서 서비스를 운영할 수 있습니다.

빅 쿼리는 현재 웹 기반의 사용자 인터페이스, REST API, 커맨드 라인 도구 등 다양한 방법을 통해 이용할 수 있으며 데이터는 구글 빅 쿼리 서버에 CSV 형식으로 저장하게 됩니다. 이용 요금은 저장된 데이터 용량 및 쿼리 볼륨에 따라 달라질 수 있습니다.

구글 빅쿼리(BigQuery) 다중 데이터 처리

테라 바이트 크기의 테이블을 연결시키는 작업은 데이터 분석가들에게는 어려운 작업입니다. 복잡한 맵-리듀스를 개발해야 하는 프로그래밍 능력이나 강력한 하드웨어를 보유하고 있어야 하며, 분석을 하기 위해서는 오랜 시간을 기다려야 합니다.

구글에서는 하둡(Hadoop) 대신에 빅 쿼리를 통해서 비용을 절감할 수 있다고 광고하고 있습니다. 하둡을 구동하기 위해서 필요한 프로그래밍 능력이나 하드웨어 시설들이 필요없으며, 단지 처리되는 쿼리에 대해서만 비용을 지불하면 됩니다.

기존의 빅쿼리의 조인 항목은 8MB이하의 데이터 집합에 대해서만 이용할 수 있었지만 새로운 조인 이치(JOIN EACH) 항목에서는 데이터 용량 제한이 없어졌습니다. 이러한 이유로 하둡의 하둡 분산 파일 시스템(HDFS)의 데이터 처리를 담당하고 있는 맵-리듀스의 대체품으로 활용될 가능성이 높습니다.

현재 많은 하둡 업무는 분산 환경에 저장되어 있는 대용량 데이터를 조합하여 작업을 진행해야 합니다. 개발자들은 이를 위해서 맵-리듀스 프로세스를 새로 작성해야 하는 번거로움이 있습니다. 이 때문에 많은 시간과 자원이 요구됩니다. 이에 반해서 조인 이치는 SQL문을 이용하여 대화식으로 처리하기 때문에 별다른 수정사항 없이 결과를 바로 확인할 수 있습니다.

BigQuery 신청 방법 및 BigQuery 사용하기

Google BigQuery 사이트에서 확인할 수 있습니다.

요금체계

https://developers.google.com/bigquery/pricing 에서 확인할 수 있습니다.

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

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

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

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

SMAQ (Storage, Map-Reduce and Query) 시스템

맵-리듀스가 널리 활용되기 시작하면서 스토리지(Storage), 맵-리듀스(Map-Reduce), 쿼리(Query) 레이어로 구성된 빅데이터 시스템 스택(Stack)이 탄생하였습니다. SMAQ 시스템은 오픈소스로 일반 범용 하드웨어에서 분산 운용되는 것을 특징으로 합니다.

[ SMAQ 시스템 ]

리눅스(Linux), 아파치(Apache), MySQL, PHP 레이어로 구성된 범용 LAMP(Linux, Apache, MySQL, PHP) 스택이 웹 애플리케이션의 지평을 바꾸어 놓은 것과 마찬가지로 SMAQ 시스템은 빅데이터 처리의 지평을 확대하는데 큰 역할을 하고 있으며, 데이터 중심의 제품 및 서비스의 새로운 시대를 선도할 것입니다.

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

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

[ Map-Reduce 작업 ]

맵-리듀스 처리 순서

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

① 분할(Splitting)

입력 파일의 값을 라인 단위로 분할합니다.

② 매핑(Mapping)

분할된 라인 단위 문장을 맵(Map) 함수로 전달하면, 맵 함수는 공백을 기준으로 문자를 분리한 후에 단어의 개수를 계산합니다. 맵 함수를 거치면서 임시 데이터 결과가 메모리에 저장됩니다.

③ 셔플링(Shuffling)

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

④ 리듀싱(Reducing)

리듀스(Reduce) 함수는 단어 목록들을 반복 수행하면서 합을 계산하여 표시합니다.

맵-리듀스의 문제점

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

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

[ 하둡 2.0 스택 ]

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