빅데이터를 위한 플랫폼들

빅데이터를 위한 플랫폼들

빅데이터 기술이란, 많은 양의 데이터를 저장할 수 있으면서 그 안에서 의미 있는 데이터를 검색하여 시각화하고 이를 바탕으로 예측/분석하는 기술과 비즈니스 프로세스에 내재화하여 적용하는 기술을 말합니다. 이 글에서는 빅데이터 분석에 대한 기술적인 내용을 플랫폼 관점에서 설명할 것입니다.

미래의 문제를 해결하려면

데이터에 기반한 의사 결정은 이를 사용하는 개인이나 조직의 경쟁력에 결정적인 영향을 미친다. MIT Sloan Management Review지에서 전 세계 기업인을 대상으로 조사한 바에 따르면, 해당 비즈니스 분야에서 주도적인 기업은 데이터에 기반해 의사 결정을 내리며, 조직적, 문화적으로 데이터에 기반한 의사 결정을 내재화한다고 한다. 다음 그림에서처럼, 약 2년 후에는 과거의 추세를 분석하고 이를 보고하는 기술보다 데이터를 시각화하고 예측하는 기술이나 분석 기술이 사업 프로세스에 내재화될 때 더 많은 가치를 낼 것이라 보고 있다.

그림 1 현재와 미래에 유용하게 사용할 기술(원본 출처: Big data, Analytics and the Path from Insights to Value, MIT Solan management review, Winter 2011.)

빅데이터를 본격적으로 다루기 전에 다음과 같은 내용을 염두에 두어야 할 것이다.

첫째, 데이터는 원래부터 중요한 것이다. 데이터의 양이 많아져서 중요해진 것이 아니다. 문제는 데이터의 양이 많아져서 기존의 소프트웨어로는 처리하기가 어려워진 것이다.

둘째, 데이터와 기술적인 요소는 이를 분석/사용하고 판단하는 사람과의 반복해서 상호 작용이 이루어질 때에만 의미 있는 결과를 낼 수 있다. 애플리케이션이나 비즈니스에 대한 이해가 반드시 있어야 하고, 풀어야 할 문제를 정확히 정의하고 어떤 데이터를 분석/처리할 것인가를 결정해야 한다. 어떻게 데이터를 가공할 것인지, 어떤 분석 알고리즘을 사용할 것인지, 어떤 처리 시스템을 사용하고 결과를 해석할 것인지 등 이 모든 것을 자동화해 주는 시스템은 없다.

마지막으로 이러한 데이터 기반의 분석이 해당 조직의 관리나 업무 프로세스에 밀접하게 연결되어야 한다.

빅데이터란?

빅데이터는 보통의 데이터베이스 소프트웨어로는 수집, 저장, 관리, 분석이 어려울 정도로 많은 데이터를 의미한다.

빅데이터에 대해 이야기할 때에는 보통 다음의 세가지 측면에서 이야기한다.

• 양(Volume): 저장할 데이터의 양과 의미 분석과 데이터 가공을 많이 해야 하는 처리 요구량
• 속도(Velocity): 저장 속도와 처리 속도
• 다양성(Variety): RDBMS에서 사용하는 테이블의 레코드와 같이 정형화되고 사전에 정의할 수 있는 정제된 형태의 데이터뿐만 아니라 텍스트, 이미지와 같은 비정형 데이터

이 세가지 측면에 데이터를 분석해야만 가치를 발생시킬 수 있다는 관점에서 '가치(Value)' 측면을 추가하기도 한다.

그렇다면 저장해야 할 데이터에는 무엇이 있을까?

고객 정보, 서비스 로그, ERP(전사적 자원관리) 데이터 등 기업 환경에서 발생하는 데이터가 우선 생각날 것이다. 이 밖에도 통신 회사에서 발생하는 CDR(Call Detailed Record)이나 비행기, 송유관, 송전관 같은 기계나 플랫폼에서 생성되는 센서 데이터, 미터링 데이터도 있다. 웹 서버나 응용 프로그램의 로그도 대상이 될 수 있고, 소셜 미디어나 블로그, 메일, 게시판 등에서 사용자가 만들어내는 데이터도 있다. 한 마디로 말해 측정하고 저장할 수 있는 모든 것이 분석 대상이 될 수 있다.

이러한 데이터는 오래전부터 관리하고 분석했던 데이터이다. 하지만 왜 근자에 빅데이터라는 용어가 대두하고 있는 것일까? 빅데이터를 매력적으로 만든 데에는 소셜화, 모바일, 클라우드 컴퓨팅, 대용량 처리 기술이라는 환경적 요소가 있다.

그림 2 빅 데이터를 매력적으로 만드는 요소

개인화 서비스와 소셜 서비스의 부상으로 기존 인터넷 서비스 환경이 재구성되고 있다. 검색과 포털 위주였던 인터넷 웹 서비스 환경이 최근에는 통신, 게임, 음악, 검색, 쇼핑 등의 전 서비스 영역에서 개인화 서비스와 소셜 서비스를 제공해야 하는 환경으로 바뀌고 있다. 그렇기 때문에 저장소의 수직적 확장(scale-up)보다는 수평적 확장(scale-out) 기술이 중요해지고 있는 것이다. 또한 개인 간의 관계 분석이나 개인의 취향을 분석하는 복잡한 기능과 저장 크기와 처리 요구량에 있어서 OLTP(Online Transaction Processing) 범위를 넘어서는 데이터 처리 기술이 중요해지고 있는 것이다.

모바일 환경의 보편화에 의해 기존 데이터가 생성되고 소비되는 원천 환경에 많은 변화가 생겼다. 사용자의 이동 정보나 활동 정보 등이 저장하고 분석해야 할 데이터가 되고 있다. 또한 스마트 폰, PC, TV 등과 같은 이종 기기간 사용자의 이동성을 보장하기 위해 클라우드 기반의 정보 공유 처리 기술이 현실화되었다.

클라우드 컴퓨팅으로 대변되는 IT 환경(IaaS, Infrastructure as a Service), 플랫폼 환경(PaaS, Platform as a Service), 서비스 환경(SaaS, Software as a Service)의 고도화 경향에 따라 대량의 데이터를 저장하고, 처리하고, 서비스하는 것이 적절한 투자 수준에서 가능해지고 있다.

Google과 같은 선도적 인터넷 기업이 공개한 대용량 데이터 처리 기술이 오픈 소스 진영에서 재창출 되고 이것을 개발 환경에서 사용할 수 있게 되었다.

이와 같은 모든 환경적 요소에 의해 많은 데이터를 효율적으로 저장하고 처리할 수 있는 능력이 곧 기업의 경쟁력으로 직결되고 있다. 동시에 여러 소프트웨어 단체나 기업에서 이러한 데이터 저장, 처리 기능을 플랫폼화하여 누구나 쉽게 쓸 수 있도록 해서, 전문 인력 확보의 어려움과 높은 비용 때문에 큰 기업만이 할 수 있었던 빅데이터 기술을 작은 단체나 기업에서도 활용할 수 있게 된 것이다.

빅데이터를 다루는 플랫폼 기술

여러 플랫폼을 저장 시스템, 처리 방식, 분석 방식이라는 세 가지 측면으로 나누어 관련된 제품이나 기술에 대해 설명하겠다. 일부는 이러한 분류 기준에 적합하지 않지만, 이러한 방식이 직관적으로 이해하기 쉬운 방식이라 보고 있다.

저장 시스템

병렬 DBMS와 NoSQL은 모두 대량의 데이터를 저장하기 위해 수평 확장 접근 방식을 취하고 있다는 점에서는 동일하다.

이 이외에도 SAN(Storage Area Network), NAS(Network Attached Storage)와 같이 기존 저장 기술도 있고, Amazon S3나 OpenStack Swift와 같은 클라우드 파일 저장 시스템, GFS(Google File System), HDFS(Hadoop Distributed File System)와 같은 분산 파일 시스템 등이 모두 대량의 데이터를 저장하기 위한 기술이다.

병렬 DBMS

오픈 소스 데이터베이스인 PostgreSQL 개발을 주도한 Michael Stonebraker는, 기존의 RDBMS 기술은 하나의 시스템이 모든 영역에 맞춰 사용될 수 있도록 만들어져 왔으나 OLAP(Online Analytical Processing), 텍스트 처리, streaming 처리, 고차원 데이터 처리 등에 있어서는 특화된 아키텍처를 가진 시스템이 많이 우월하다는 것을 H-Store, C-Store와 같은 프로토타입 시스템을 만들어서 실증적으로 보였다.

참고

H-Store는 메모리 기반의 고성능 OLTP에 적합하도록 고안되었고 VoltDB라는 이름으로 상용화되었다.

C-Store는 OLAP 응용에 적합하도록 고안되었으며, Vertica란 상용제품으로 나왔고 2011년 HP에 의해서 인수되었다.

그는 또한 기존 OLTP(Online Transactional Processing) 처리 영역에 있어서도, RDBMS가 처음으로 디자인되고 구현될 당시와는 많은 환경 변화가 있으며 이를 반영해야만 한다고 했다. 예를 들어서 70년대의 하드 디스크 드라이브는 현재는 메모리와 동일한 위치에 있으며, 디스크 로그 및 테이프 백업에 의한 재난 복구 방식은 "k-safe environment", 즉 복제 기반의 고가용 구조로 변화해야 하고, 프로세서의 기술 변화에 의해서 전통적인 lock 방식의 concurrency 기법을 다시 고려해야 한다고 했다.

이 글에서는 대표적인 병렬 DBMS 시스템인 VoltDB, SAP HANA, Vertica, Greenplum, IBM Netezza data warehouse에 대해 간략하게 소개하겠다. 이 시스템 외에도 전통적인 강자라고 할 수 있는 Teradata, Sybase, Essbase 와 같은 여러 제품이 빅데이터 처리를 위한 여러 가지 솔루션을 제공하고 있다.

병렬 DBMS는 전통적인 RDBMS에서 발전한 형태이며, MPP 구조를 취하고 있는 경우가 많다. 또한 많은 경우 병렬 DBMS를 개발하는 회사나 단체는 IT 대기업에 인수되어 장치(appliance) 형태로 발전하고 있다. 다음 표는 대표적인 병렬 DBMS를 인수한 회사와 인수 연도를 정리한 것이다.

표 1 병렬 RDBM와 인수 회사

인수한 회사	데이터베이스	인수 연도
SAP	Sybase	2010
HP	Vertica	2011
IBM	Netezza	2010
Oracle	Essbase (Hyperian Solutions)	2007
Teradata	Aster Data	2011
EMC	Greenplum	2010

VoltDB

VoltDB는 고성능의 OLTP 환경에 적합한 형태로 구성된 시스템이다.

메모리 기반으로 데이터를 처리하며, SQL이 아니라 stored procedure 기반으로 데이터 분할에 대해 순차적인 처리를 하면서 통신과 lock 오버헤드를 줄이고 테이블 데이터에 대한 수평적 분할을 통해 고속의 OLTP 시스템을 구성할 수 있한다. 최근에는 snap-shot과 command logging 방식으로 디스크 상의 durability 지원, map-reduce 스타일의 읽기 연산과 materialized view 등을 지원해서 analytic 기능 (집계 연산)을 강화했다.

그림 3 VoltDB 아키텍처(원본 출처: VoltDB Techincal Overview )

위의 그림에서 보여 주듯이, VoltDB에서는 어느 한 파티션에서만 동작하면 되는 수행 작업은 해당 파티션에서 순차적으로 수행되고, 여러 파티션에서 처리되어야 하는 수행 작업은 coordinator에 의해서 처리된다. 따라서 여러 파티션에 대해서 처리되야 하는 연산이 많을 때 저장해야 할 row의 size가 큰 경우에는 성능이 좋지 않을 수 있다.

SAP HANA

SAP HANA는 SAP에서 만든 메모리 기반 로우/컬럼 저장소다. OLAP와 같은 분석 작업에 최적화된 형태로 시스템을 구성할 수 있도록 지원하는 것이 특징이다.

시스템 메모리 안에 모든 데이터가 들어와 있는 경우, CPU의 utilization을 최대화하는 것이 관건이 되며 이때 메모리와 CPU 캐시 간의 병목현상을 줄이는 것이 핵심이 된다. Cache miss를 최소화하기 위해서는 주어진 시간에 처리할 데이터가 연속적으로 있는 것이 유리하며, 많은 OLAP 분석의 경우 컬럼 기반(Column-Oriented) 형태의 테이블을 구성하는 것이 유리할 수 있다.

컬럼 기반의 테이블 구성의 장점은 여러 가지가 있는데, 대표적인 예로는 높은 데이터 압축률과 처리 속도를 들 수 있다. 같은 데이터 도메인의 경우 여러 데이터 도메인이 합쳐진 경우보다 데이터 압축에 유리하다. 또한 RLE(Run length encoding)나 dictionary encoding과 같이 경량의 압축 방식으로 CPU 연산을 줄이거나, 압축된 데이터를 복원 과정 없이 직접 원하는 연산을 수행할 수 있기도 하다. 다음 그림은 로우 기반(Row-oriented)과 컬럼 방식(Column-Oriented)을 간단하게 비교한 것이다.

그림 4 로우 기반 방식과 컬럼 기반 방식의 비교(원본 출처)

Vertica

Vertica는 데이터를 하드 디스크에 컬럼 방식으로 저장하는 OLAP에 특화된 데이터베이스다. Shared-nothing 기반의 MPP(Massive Parallel Processing) 구조이며 대량의 데이터를 빠르게 적재할 수 있도록 쓰기에 최적화된 저장소와 압축된 형태로 구성된 읽기 저장소, 양자간의 데이터 흐름을 관장하는 tuple mover 등으로 구성되어 있다. 다음 그림은 Vetica의 구조를 대략적으로 보여 준다.

그림 5 Vertica 구조(원본 출처 )

Greenplum

Greenplum은 shared-nothing MPP 구조의 데이터베이스이며 PostgreSQL 기반으로 만들어졌다. 저장되는 데이터는 해당 데이터에 적용되는 연산에 따라서 로우 기반 또는 컬럼 기반 방식을 선택할 수 있다. 데이터는 세그먼트 단위로 서버에 저장되며, log shipping 방식의 세그먼트 단위 복제로 가용성을 확보한다. PostgreSQL 기반에서 발전시킨 쿼리 엔진은 SQL 기본 연산(hash-join, hash-aggregation)이나 임의의 Map-Reduce 프로그램을 수행할 수 있도록 구성되어 있어 병렬 쿼리 처리나 Map-Reduce 형태의 프로그램을 효율적으로 처리할 수 있다. 각 처리 노드는 소프트웨어 기반의 데이터 스위치 컴포넌트로 연결되어 있다.

그림 6 Greenplum 아키텍처(원본 출처)

IBM Netezza data warehouse

IBM Netezza data warehouse는 AMPP(Asymmetric Massively Parallel Processing)라고 부르는 SMP(Symmetric Multiprocessing)와 MPP로 구성된 two-tier 형태의 아키텍처를 가지고 있다.

SMP 구조를 가지는 호스트는 쿼리 실행 계획 및 결과 집계 연산을 담당한다. MPP 구조를 가지는 S-blade 노드들은 쿼리 실행을 담당한다.

S-blade 노드는 디스크와 FPGA(Field Programmable Gate Array)라는 특수한 데이터 처리 프로세서에 의해 연결되어 있고, S-blade 노드와 호스트는 IP 주소를 사용하는 네트워크로 연결되어 있다.

다른 시스템에서 보기 힘든 FPGA의 특징에는 데이터 압축, 레코드 또는 컬럼 필터링이 있다. 트랜잭션 처리시에는 visibility check 등과 같은 filtering이나 transformation 기능을 디스크에서 메모리로 데이터를 가져오는 과정 중에 처리할 수 있도록 하여 실시간 처리를 할 수 있다. 대용량 데이터를 처리할 때, 데이터 연산을 가급적 데이터를 가지고 있는 곳에서 하여 불필요한 데이터 전송을 최대한 줄여야 한다라는 원칙(processing close to the data source)에 충실한 것이라고 할 수 있다.

그림 7 IBM Netezza data 아키텍처(원본 출처: The IBM Netezza data warehouse appliance architecture )

NoSQL

RDBMS에서 ACID(Atomicity, Consistency, Isolation, Durability)를 지원하면서 수평으로 확장하는 것은 거의 불가능에 가깝다. 여러 장비에 데이터를 나누어 저장해야 하고, 나누어진 데이터에 대한 ACID를 만족하려면 복잡한 locking 방식과 복잡한 복제 방식을 사용할 수 밖에 없게 되고, 이는 결국 성능 저하로 이어지기 때문이다.

이러한 이유로 데이터 모델을 단순화해서 분산의 기본이 되는 shard를 쉽게 정의하고, 분산 복제 환경에서 consistency의 요건을 완화하거나(Eventual Consistency), Isolation 요건을 제약하는 형태의 새로운 저장시스템이 나오게 되었는데, 이를 통칭해서 NoSQL이라 부르고 있다.

NoSQL에 대한 정보는 많은 곳에서 얻을 수 있기 때문에 이 글에서 NoSQL 제품군은 따로 설명하지 않겠다.

처리 방식

병렬 처리의 핵심은 분할 점령(Divide and Conquer)이다. 즉 데이터를 독립된 형태로 분할하고 이를 병렬적으로 처리하는 것이다. 각각의 연산을 분산하여 처리할 수 있는 행렬 곱을 상상해 보면 된다.

빅데이터의 데이터 처리란 이렇게 문제를 여러 개의 작은 연산으로 나누고 이를 취합하여 하나의 결과로 만드는 것을 말한다. 물론 연산 의존성이 있는 경우에는 병렬 연산의 이점을 살릴 수 없을 것이다. 이러한 점을 고려한 데이터 저장과 데이터 처리가 필요하다.

Map-Reduce

대용량의 데이터를 처리하는 기술 중 가장 널리 알려져 있는 것은 Apache Hadoop과 같은 Map-Reduce 방식의 분산 데이터 처리 프레임워크일 것이다.

Map-Reduce 방식의 데이터 처리는 다음과 같은 특징이 있다.

• 특별한 저장소가 아닌 일반적인 내장 하드 디스크 드라이브를 사용하는 일반 컴퓨터로 연산을 수행한다. 각 컴퓨터는 서로 매우 약한 상관 관계를 가지고 있기 때문에, 수백~수천 대까지 확장할 수 있다
• 많은 수의 컴퓨터가 처리에 참가하므로, 하드웨어 장애 등의 시스템 장애가 예외적인 상황이라기 보다는 일반적인 상황이라고 가정한다
• Map과 Reduce라는 간단하고 추상화된 기본 연산으로 복잡한 여러 문제를 해결할 수 있도록 한다. 병렬 프로그램에 익숙하지 않은 프로그래머라도 쉽게 데이터에 대한 병렬 처리를 할 수 있도록 하고 있다
• 많은 수의 컴퓨터에 의한 고처리량(throughput)을 지원한다.

다음 그림은 Map-Reduce 방식의 실행 흐름을 나타낸 것이다. HDFS와 같은 저장소에 저장된 데이터는 가용한 worker에 나누어져 key, value 형태로 표현되며(Map), 중간 결과는 로컬 디스크에 저장된다. 이 데이터가 Reduce를 하는 worker에 의해서 취합되어서 결과 파일이 만들어 진다.

그림 8 Map-Reduce 실행 과정(원본 출처: MapReduce: Simplified Data Processing on Large Clusters CACM January 2008/Vol. 51, No. 1)

마스터 노드는 worker를 데이터가 저장되어 있는 위치(네트워크 스위치 기준)에 위치시켜서 원본 데이터가 위치한 곳과 데이터를 처리하고 있는 노드 사이의 간격을 줄여서 locality를 최대한 살릴 수 있게 한다. 각 worker는 streaming 인터페이스(standard in/out) 등을 통해 여러 언어로 구현할 수 있다.

Dryad

Dryad는 프로그램과 프로그램 사이의 데이터 채널을 그래프 형태로 구성해서 병렬 데이터 처리를 할 수 있도록 하는 프레임워크이다.

Map-Reduce 프레임워크를 사용하는 개발자가 할 일은 Map 기능과 Reduce 기능을 작성하는 것이었는데, Dryad를 사용할 경우에 개발자가 할 일은 해당 데이터를 처리하는 그래프를 만들어 내는 것이 된다.

다음 그림은 Dryad에서 데이터를 처리하는 과정을 UNIX의 pipe에 빗대서 설명한 것이다. 이렇게 Dyrad에서는 DAG(Direct Acyclic Graph) 형태의 데이터 흐름을 처리해줄 수 있게 해주고 있다.

그림 9 Dryad 데이터 처리 과정(원본 출처: Cluster Computing with Dryad )

Apache Pig

Map-Reduce나 Dryad와 같은 병렬 데이터 연산 프레임워크는 빅데이터를 처리하기 위한 기능을 충분히 제공하지만, 경험이 많지 않은 개발자나 데이터 분석가, 데이터 마이너가 무리 없이 사용하기에는 어느 정도 진입 장벽이 있는 것이 사실이다. 그렇기 때문에 좀 더 높은 수준의 추상화로 데이터를 더 쉽게 처리할 수 있는 방법이 필요해지게 되었다. 다음에 설명할 Apache Pig와 Apache Hive가 이런 필요에 따라 나온 프레임워크이다.

Apache Pig는 고수준의 데이터 처리 구조를 제공하며, 이를 조합해서 대량의 데이터 처리를 가능하게 한다. Apache Pig는 Pig Latin이라는 언어를 지원하는데, Pig Latin은 다음과 같은 특징이 있다.

• int, long, double과 같은 기본 타입 외에 relation, bag, tuple 과 같은 고수준의 구조를 제공한다
• FILTER, FOREACH, GROUP, JOIN, LOAD, STORE 등의 관계(relation, table) 연산을 지원한다
• 사용자 지정 함수를 정의할 수 있다.

Pig Latin으로 명세한 데이터 처리 프로그램은 논리적인 실행 계획으로 변환되고, 이것이 다시 Map-Reduce 실행 계획으로 변환되어서 실행된다. 다음 그림은 Apache Pig의 동작 과정을 나타내는 그림이다.

그림 10 Pig Latin이 Map-Reduce로 변환되는 과정(원본 출처: Building a HighLevel Dataflow System on top of MapReduce: The Pig Experience, VLDB '09, August 2428, 2009, Lyon, France)

Apache Hive

Apache Pig의 경우는 C나 Java와 같이 절차적 프로그램 언어 형태로 대량의 데이터 처리 프로그램을 작성할 수 있도록 하는 접근 방식이다. 이와 비슷한 접근 방식으로 Google의 Sawzall이 있다. 프로그래밍 언어와 같이 절차적으로 데이터 처리를 명세하지 않고, SQL처럼 선언적 데이터 처리를 할 수 있도록 하는 기술도 있다. 대표적인 것으로 Apache Hive, Google Tenzing, Microsoft의 SCOPE 등이 있다.

Apache Hive는 HDFS나 HBase와 같은 대량의 데이터 원본을 HiveQL이라고 부르는 쿼리 언어로 분석할 수 있는 기술이다. 아키텍처상으로는 Map-Reduce 기반의 실행 부분과 데이터 저장소에 대한 메타데이터 정보와 사용자나 응용프로그램으로부터 쿼리를 받아 실행하는 실행 부분으로 나뉘어져 있다. 사용자에 의한 확장을 지원하기 위해서 scalar 값, aggregation, table 수준에서 사용자 정의 함수를 지정할 수 있도록 하고 있다.

그림 11 HIVE 아키텍처(원본 출처: Hive A Warehousing Solution Over a MapReduce Framework, VLDB '09, August 2428, 2009, Lyon, France)

분석 방식

지금까지 빅데이터를 저장하는 시스템과 대량의 데이터 처리 방식 및 처리를 나타내는 절차적/선언적 기술에 대해 살펴보았다. 마지막으로 빅데이터를 분석하는 기술에 대해 알아보려 한다.

데이터에서 의미를 찾는 과정을 KDD(Knowledge Discovery in Databases)라고 한다. 데이터를 저장하고, 관심 있는 데이터의 일부 또는 전부를 처리/분석해서 추이나 의미 있는 값을 추출하거나 지금까지 미처 알지 못했던 사실을 발견해서 이를 지식으로 만드는 것이다.

이를 위하여 인공지능, 기계 학습, 통계, 데이터 베이스 등 여러 분야의 기술을 종합적으로 적용하고 있다.

GNU R

GNU R은 통계 분석과 graphics(visualization) 분야에 특화된 프로그램 언어와 패키지로 구성된 소프트웨어 환경이다. 언어적으로 통계 계산에 최적화될 수 있도록 벡터, 행렬과 같은 자료를 잘 처리할 수 있게 한다. CRAN(Comprehensive R Archive Network)이라는 R 패키지 사이트(http://cran.r-project.org/mirrors.html)가 있어서 원하는 통계 처리 라이브러리를 쉽게 얻을 수 있다. 통계 분야의 오픈 소스라고 할 수 있을 것이다.

R은 하나의 컴퓨터에 처리해야 할 데이터를 메모리 상에 모두 올려서 하나의 CPU만으로 분석한다. 처리해야 할 데이터가 많아짐에 따라 메모리/CPU 상의 제약을 풀어 주는 패키지들이 있다. 대표적인 것을 소개하면 다음과 같다.

• doSMP package: 멀티코어를 사용한다.
• Bigmemory package: shared 메모리에 데이터를 저장한다. 메모리에는 값(Value)에 대한 레퍼런스만 저장하고 디스크에 값을 저장한다.
• snow package: 컴퓨터 클러스터 환경에서 R 프로그램을 수행할 수 있다.

다음 그림은 snow package가 클러스터 환경에서 처리하는 방식을 보여 준다. 전형적인 분할 점령 방식이다.

그림 12 GNU R, Snow Package 실행 환경(원본 출처: Tutorial: Parallel computing using R package snowfall )

Map-Reduce 연산이 보편화됨에 따라, MR 연산과 R이 통합되는 형태로 RHIPE, RHadoop package, Ricardo와 같은 기술이 나오고 있다. 또한 Apache Hive와 같은 고수준의 데이터 처리 기술과 결합한 rhive package도 있다.

Apache mahout

Apache mahout은 데이터 분석 알고리즘을 확장성 있도록 구현한 것이다. Apache Hadoop뿐만이 아니라 여러 환경에서 동작할 수 있다. 벡터 행렬과 같은 수학 라이브러리와 Java Collection을 저장 측면에서 효율화한 패키지, 그리고 DBMS나 다른 NoSQL 데이터베이스를 데이터 소스로 사용할 수 있는 기능도 제공하고 있다.

이 밖에도 기존 MPP 구조의 빅데이터 저장소 제품에서 제공하는 자체 처리 기술에 R을 통합해서 지원하는 경향도 있다. 예를 들어서 Oracle big data appliance에서는 R과 통합해서 Oracle database에 저장된 데이터를 대상으로 R 프로그램을 수행할 수 있도록 해주기도 한다. 기존의 대량 데이터 처리 프레임워크나 저장시스템 상의 연산에서 GNU R과 같은 데이터 분석 기술이 융합되는 방향으로 진행되고 있는 것이다.

마치며

지금까지 빅데이터를 처리하는 플랫폼 기술을 저장 시스템, 대량 데이터 처리 방식, 분석 방식으로 나누어 대략적으로 살펴 보았다.

요약해 보면, 기존 RDBMS는 MPP 구조의 어플라이언스 형태로 진화하고 있으며, NoSQL로 대변되는 대용량 데이터 저장/처리 시스템이 발전하고 있는 중이다. 분산 데이터 처리를 위한 Map-Reduce 기술을 기반으로 Apache Hive와 같은 SQL 형태의 선언적 데이터 처리 방식을 지원해 가고 있으며, 데이터 분석 도구 및 알고리즘이 이러한 분산 데이터 처리 방식과 융합하고 있다.

마지막으로, 빅데이터는 이를 처리하는 기술과 빅데이터를 사용하는 사람/조직의 역량이 결합되었을 때 비로소 힘의 원천으로 작용한다라는 것을 꼭 전달하고 싶다.