IT Life

[Technology Inside] '빅데이터’ 플랫폼의 미래

2013. 2. 25. 18:59



'Technology Inside’는 IT업계에 종사하시는 분들에게 최근의 IT트렌드와 각 분야별 IT기술의 특징과 전망을 소개하는 칼럼입니다. 이 컨텐츠를 통해서 IT분야에 대한 식견을 넓히시는 기회가 되시기 바라며, 보다 심도있는 내용을 탐구하고자 하시는 분은 첨부된 PDF 파일을 참고하시기 바랍니다. 


 


현재는 이른바 빅데이터의 시대입니다. 최근 각종 IT 매체에서 이야기 하는 가장 뜨거운 아이템 중 하나가 ‘빅데이터’ 이지요. 하지만, 과거에도 커다란 데이터는 있었을 텐데 왜 최근 들어 빅데이터라는 이름으로 다시 거론되는 걸까요? 유행처럼 지나가는 버즈워드(Buzz word)일까요? 필자 생각에는 빅데이터가 새삼 주목 받는 가장 큰 이유는 빅데이터로부터 가치 창출이 가능할 만큼 관련 기술이 성숙되었기 때문입니다. 그래서 오늘은 핵심 기술이라고 할 수 있는 빅데이터 플랫폼에 대해 이야기해보고자 합니다.

 


쉽게 정의해 보자면, 빅데이터 플랫폼은 빅데이터 기술의 집합체이자 기술을 잘 사용할 수 있도록 준비된 환경입니다. 기업들은 빅데이터 플랫폼을 사용하여 빅데이터를 수집, 저장, 처리 및 관리 할 수 있습니다. 빅데이터 플랫폼은 빅데이터를 분석하거나 활용하기 위해 필요한 필수 인프라(Infrastructure)인 셈이죠.

 


<빅데이터 플랫폼의 역할과 기능>

빅데이터 플랫폼은 빅데이터라는 원석을 발굴하고, 보관, 가공하는 일련의 과정을 이음새 없이(Seamless) 통합적으로 제공해야 합니다. 이러한 안정적 기반 위에서 전처리된 데이터를 분석하고 이를 다시 각종 업무에 맞게 가공하여 활용한다면 고객이 원하는 가치를 정확하게 얻을 수 있게 될 것입니다. 이것이 궁극적으로 가능하려면 빅데이터 플랫폼은 고객이 지불한 비용과 시간 내에 빅데이터를 관리하여 원활히 처리할 수 있어야 합니다.

 

 


<하둡 마스코트 노란 코끼리, 출처 : the verge>

여기 블로그에서도 이미 소개(http://blog.lgcns.com/61)드린 바와 같이 빅데이터 플랫폼에 있어 하둡(Hadoop)이라는 오픈 소스 분산 컴퓨팅 프레임워크(Framework)가 사실상의 표준(De facto) 기술로 자리매김했습니다. 하지만, 하둡에는 몇 가지 한계가 존재하고, 이는 고스란히 빅데이터 플랫폼의 제약 사항이 되고 있는데요. 주요한 몇 가지를 말씀드리면 다음과 같습니다.


1) 실시간 데이터 처리 한계: 하둡은 일정기간 수집된 자료를 대상으로 하는 일괄처리(Batch) 방식으로 데이터 처리를 하기 때문에 실시간 데이터 처리가 안됩니다.


* 일괄처리(Batch Processing): 자료를 축적하여 두었다가 일정 시점 단위로 일괄해서 처리하는 자료처리 방식입니다. (출처: 두산백과) 


2) 다양한 데이터 연산 한계: 데이터간 통신이 필수적인 복잡 연산 등은 처리하기 어렵습니다.


3) 다수의 작은 파일 관리 어려움: 설정에 따라 바뀔 수 있지만, 64 메가바이트(MB) 가량의 큰 파일이 아닌 상대적으로 작은 파일을 저장하면 효율적인 데이터 관리와 처리가 어렵습니다. 따라서, 작은 파일들은 큰 파일로 합쳐서 저장해야 합니다.


4) 단일 고장점(Single Point of Failure) 존재: 하둡에서는 저장된 파일의 위치와 이름 등의 메타 정보를 관리하는 마스터 서버가 이중화 구성을 지원하지 않습니다. 하지만, 이는 별도의 이중화 기술과 솔루션 등으로 극복할 수 있습니다.


* 단일 고장점 : 시스템 구성 요소 중에서, 동작하지 않으면 전체 시스템이 중단되는 요소를 말합니다. (출처 : 위키피디아) 


* 메타 정보(메타데이터(metadata)): 메타데이터는 데이터(data)를 위한 데이터를 말합니다. 어떤 데이터 즉 구조화된 정보를 분석, 분류하고 부가적 정보를 추가하기 위해 그 데이터 뒤에 함께 따라가는 정보입니다. ex). 촬영사진파일에 따르는 일자, 해상도 정보


* 이중화: 시스템의 일부에 어떠한 장애가 발생했을 경우에 대비하여, 장애 발생 다음에도 시스템 전체의 기능을 계속 유지하도록 예비 장치를 평상시부터 운용하는 일을 말합니다. (출처 : 위키피디아, 일부 수정) 



5) 높은 기술적 숙련 필요: 빅데이터를 처리하기 위해서는 데이터 처리 로직(Logic)을 맵리듀스(MapReduce) 처리 방식에 알맞도록 변환하고 프로그램을 개발해야 하는데, 이는 해당 업무 지식 뿐 아니라 하둡에 대한 높은 기술적 숙련이 요구됩니다.


* 맵리듀스(MapReduce): 구글에서 분산 컴퓨팅을 지원하기 위한 목적으로 제작하여 2004년 발표한 소프트웨어 프레임워크)


물론 이와 같은 한계 및 제약이 절대적인 것은 아니며, 적절한 방법으로 해결할 수 있습니다. 하지만, 결국 빅데이터 플랫폼과 관련 기술들은 이러한 한계들을 극복하는 방향으로 진화하고 있습니다.


 


하둡 프로젝트 창시자인 더그커팅(Doug Cutting)은 최근 한 컨퍼런스에서 다음과 같이 말했습니다.


구글이 우리에게 방향을 제시했습니다. 구글은 그들의 GFS(Google File System)와 MapReduce 논문을 발표하기 시작했고, 우리는 재빠르게 그것을 하둡 프로젝트에 복제했습니다. 몇 년 동안 구글은 오픈소스 진영에 영감을 준 많은 방법들을 발표했습니다.


구글이 자신의 플랫폼 노하우를 논문으로 발표하고 이를 더그커팅이 오픈소스로 개발함으로써 하둡 프로젝트가 시작되었습니다. 구글의 영감은 하둡에만 그친 것이 아니라 하둡을 비롯한 현재, 미래의 빅데이터 플랫폼 기술 전반에 지속적인 영향을 끼치고 있습니다. 한마디로 구글은 빅데이터 플랫폼의 청사진인 셈이지요. 구글이 발표한 논문과 이를 구현한 오픈소스 프로젝트를 비교한 표를 보시면 이해되실 겁니다.



구분

글 논문

하둡과 에코시스템

설명

파일 시스템

 2003년 GFS

 2006년 HDFS

 분산 파일 시스템

 2010년 Colossus

 -

 GFS 단점 보완

데이터 처리

 2004년 MapReduce

 2006년 MapReduce

 분산병렬처리

 2005년 Sawzall

 2008년 Pig, Hive

 빅데이터 쿼리(일괄처리)

 2009년 Pregel

 개발 중 Giraph

 대규모 그래프 데이터 처리

 2010년 Dremel

 개발 중 Drill, Impala

 실시간 빅데이터 쿼리

데이터베이스

 2006년 BigTable

 2008년 HBase

 Schemaless NoSQL DB

 2012년 Spanner

-

 빅데이터 트랜잭션 처리

서버 관리

 2006년 Chubby

 2008년 Zookeeper

 서버 락(Lock) 서비스

<구글 논문과 하둡 관련 오픈소스 비교>


앞서 언급한 하둡의 한계와 위의 사항을 종합해 보면 빅데이터 플랫폼의 미래는 다음과 같은 방향으로 진화할 것입니다.


1) 실시간 빅데이터 처리

기존 맵리듀스(MapReduce)의 일괄처리 방식이 아니라 온라인으로 연결된 상태에서 빅데이터 처리 요청과 응답을 즉각 주고 받을 수 있는 실시간 처리 기술이 발전할 것입니다. 이것은 준구조화(Semi-Structured)된 빅데이터를 컬럼 테이블 형태로 저장하고 분산병렬 SQL 쿼리를 실행함으로써 가능합니다. 구글의 드레멜(Dremel), 오픈소스로는 클라우데라(Cloudera)의 임팔라(Impala), 아파치 재단의 드릴(Drill)이 대표적 구현체입니다만, Impala, Drill은 아직 개발 단계입니다.


* SQL(structured query language): 구조화 질의언어(query language)라고도 하는, 데이터베이스를 사용할 때, 데이터베이스에 접근할 수 있는 데이터베이스 하부 언어를 말합니다.


2) 다양한 분산병렬 처리 방법 제공

맵리듀스(MapReduce)는 분할, 병렬 처리와 그 결과의 합산 방식이기 때문에 꼭지점(Vertex)과 선(Edge)을 처리하는 그래프 연산과 조건을 충족할 때까지 특정 데이터 처리를 반복하는 순환 연산에 비효율적입니다. 이는 정확히 하둡의 한계라기 보다는 MapReduce라는 프로그래밍 모델의 한계죠. 어쨌든 하둡과 하둡을 기반으로하는 빅데이터 플랫폼은 기존 MapReduce와 함께  그래프 연산과 MPI(Message Passing Interface) 등 다양한 데이터 처리 라이브러리도 지원하도록 보편적 분산병렬 프레임워크로 진화하고 있습니다.


3) 관계형 데이터 모델과 대규모 업무 트랜잭션 제공

아마도 이 글을 읽는 내내 독자분들께서 이런 생각을 하셨을지 모르겠습니다. 빅데이터를 오라클, IBM DB2와 같은 관계형 데이터베이스에 저장, 처리할 수 있다면 좋을텐데… 라고 말이죠. 빅데이터 기술 역시 그와 비슷한 방향으로 발전하고 있습니다. 즉, 관계형 데이터베이스에 NoSQL(Not only SQL) 확장성과 고성능 기능을 부여하여 빅데이터 저장, 트랜잭션 및 SQL처리가 가능하도록 빅데이터 플랫폼이 진화하고 있습니다.


 * 관계형 데이터베이스(relational database): 일련의 정형화된 테이블로 구성된 데이터 항목들의 집합체입니다. 사용자와 관계형 데이터베이스를 연결시켜 주는 표준검색언어를 SQL이라고 하는데, SQL 문장은 관계형 데이터베이스에 있는 데이터를 직접 조회하거나 또는 보고서를 추출하는 데 사용됩니다. 


기존 빅데이터 플랫폼에서 주요하게 채용된 NoSQL은 분산처리와 확장성이 뛰어나지만 스키마와 관계형 데이터 모델이 지원되지 않습니다. 이를 보완하여 일반적 목적의 트랜잭션 처리나 관계형 데이터 모델이 가능하면서도 빅데이터를 처리할 수 있도록 보완한 이른바 NewSQL이 등장한 것이지요. 하지만, 기술적 성숙도는 아직 낮습니다.


* 스키마(schema): 데이터베이스에 존재하는 자료의 구조 및 내용 그리고 이러한 자료들에 대한 논리적, 물리적 특성에 대한 정보들을 표현하는 데이터베이스의 논리적 구조를 지칭합니다. 일반적으로 데이터베이스에서는 자료의 독립성을 위하여 여러 계층의 스키마를 사용하여 데이터베이스를 표현하고 있습니다.


4) 파일 관리 효율화

앞서 작은 파일들 저장이 비효율적이라고 했는데요, 이는 파일 정보를 관리하기 위한 메모리 공간의 낭비를 초래하기 때문입니다. 그리고 작은 파일이든 큰 파일이든 하둡이 3개의 파일 복사본을 유지하는 것도 비효율적이죠. 그래서 향후의 빅데이터 기술은 이러한 낭비를 줄이는 방향으로 발전하고 있는데요. 저장 파일 정보를 분산해시테이블(Distributed Hash Table)로 관리하면 작은 파일도 메모리 공간 낭비 없이 저장할 수 있고, 원본 복구가 가능한 알고리즘을 활용하여 데이터 복구 정보를 관리한다면 기존 대비 절반 정도의 저장 공간을 절약할 수 있습니다.

 



지금까지 주요한 빅데이터 플랫폼의 진화 방향을 살펴 보았습니다. 기술적으로는 굉장히 많은 분량의 설명이 필요하지만, 빅데이터 플랫폼의 미래를 한마디로 요약하자면 빅데이터의 비전을 완벽하게 현실화하는 것에 있습니다.


- 빅데이터의 크기(Volume): 페타바이트(PB) 규모를 넘어 엑사바이트(EB), 제타바이트(ZB) 까지 저장, 관리하고 단일 지역이 아닌 범 지구적으로 분산된 데이터베이스를 마치 하나의 시스템처럼 제공하는 플랫폼


- 빅데이터 형식의 다양성(Variety): 정형, 비정형 데이터 처리 뿐 아니라 보편적 분산병렬처리로 다양한 빅데이터 처리 방법을 제공하는 플랫폼


- 빅데이터 유통의 속도(Velocity): 실시간으로 생성, 유통되는 빅데이터를 실시간으로 수집하여 실시간으로 처리하는 플랫폼


이와 같은 빅데이터의 비전을 구현하기 위해 많은 기술자들이 노력하고 있고, 또 성과도 계속해서 나오고 있습니다. 빅데이터 기술이 빠르게 발전하는 만큼 멀지 않은 미래에 현실화 되기를 기대해 봅니다.


글 | LG CNS 신기술개발그룹 이주열 부책임연구원(jooyoul.lee@lgcns.com)


*첨부파일 


LG CNS 빅데이터.pdf

Posted by IT로 만드는 새로운 미래를 열어갑니다 LG CNS

댓글을 달아 주세요

위로