소소한 일상에서 책읽기 중

빅데이터 개요 본문

빅데이터

빅데이터 개요

다솜여우 2012. 1. 4. 16:13

빅데이터 개요
2011년 하반기부터 빅데이터라는 용어가 해외 블로그 또는 저널로부터 나오기 시작했습니다. 국내에서도 이 시기에 언론에서 빅데이터에 대해 관심을 가지면서 관련 기사들이 나왔습니다.

필자는 몇년 동안 하둡(Hadoop), NoSQL 등과 같은 분야를 연구하고 있었지만 이런 기술셋들에 대해 정확하게 분류할 수가 없었습니다. 2006년 처음 시작할 때에는 분산컴퓨팅, 그리드 컴퓨팅이라는 용어로 시작했는데 뭔가는 맞지 않는 부분도 있었습니다.

Hadoop의 경우 분산 파일 시스템 분야와 분산 처리 분야에 속해 있고 NoSQL은 분산 데이터베이스에 속해 있었다고 할 수 있죠. 2008년부터 클라우드 컴퓨팅(Cloud Computing)이라는 새로운 용어가 나오면서 가상화 기술(서버 가상화, 스토리지 가상화 등) 들을 비롯한 여러 기술 분야가 클라우드 컴퓨팅을 구현하기 위한 기술 분야로 묶이게 되었습니다. 이때 Hadoop, NoSQL 등도 클라우드 컴퓨팅이라는 용어로 묶이는 분위기였습니다.

클라우드 컴퓨팅을 구현하기 위해서는 서버 가상화뿐만 아니라 가상 머신(VM) 이미지나 VM에 마운트 시킬 수 있는 디스크 또는 스토리지 등의 기술이 필요했으며 사용자의 파일 등을 서비스할 수 있는 오브젝트 스토리지 기술도 필요하게 되었습니다. 또한 이렇게 저장된 데이터를 분석하는 기술도 필요하고요. 데이터베이스도 기존의 하나의 서비스만을 위한 데이터베이스가 아닌 하나의 큰 인스턴스로 여러 업무 여러 사용자에게 서비스하는 클라우드 개념을 지원하는 데이터베이스 기술도 필요하게 되었습니다.

이런 이유 때문에 Hadoop, NoSQL 등이 클라우드 컴퓨팅의 한 기술 분야로 정리되지 않았나 생각합니다.

그래도 이 기술 자체만으로는 클라우드의 개념과는 약간은 거리가 있는 듯한데 2010년 말~2011년에 이르러 이런 기술을 정의 내릴 수 있는 용어가 나왔는데 바로 빅데이터입니다. 기술적인 측면이 아닌 데이터 적인 측면에서도 정의를 하겠지만 빅데이터라는 용어를 등장시킨 결정적인 기술이 Hadoop, NoSQL이 아닐까 생각합니다.

빅데이터 정의
그럼 빅데이터에 대한 정의를 간단하게 내려 보겠습니다. 이것도 클라우드 컴퓨팅이라는 정의와 함께 많이 오해하고 있는 용어 중의 하나인 것 같습니다. 지금까지 제가 살펴본 여러 컬럼이나 문서를 통해 보면 다음과 같이 정의할 수 있을 것입니다.

“빅데이터란 시스템, 서비스, 조직(회사) 등에서 주어진 비용, 시간내에 처리 가능한 데이터 범위를 넘어서는 데이터이다.”

정의는 제 주관적인 정의입니다.

위 정의에서 좀 더 자세하게 짚고 넘어 가야 할 부분이 있습니다. 먼저 “처리” 라는 용어입니다. 이 부분이 국내 많은 개발자나 언론, 회사 IT 담당 부서에서 혼동하고 있는 부분이 아닐까 합니다.

“처리”는 단순히 배치 분석 작업을 의미하는 것이 아닙니다. 즉 기존의 비즈니스인텔리전스(BI)와 데이터웨어하우스(DW) 등에서의 데이터 웨어 하우스만을 의미하는 것이 아니라는 것입니다. 실시간으로 처리되는 데이터도 같이 포함하고 있는 개념입니다.

예를 들어 국내에서만 서비스되는 쇼핑몰이 있습니다. 이 쇼핑몰은 하루에 수백만명의 제품 검색, 구매 요청을 처리 가능합니다. 이 서비스를 아시아권으로 확대 서비스 했을 때에도 사용자의 요청을 처리할 수 있을까요?

서비스 개발에 조금이라도 아는 사람이라면 안된다는 것을 알 것입니다. 사용자가 늘어나면 사용자의 실시간 검색 요청, 구매 요청 등에 대응하기 위해 여러 부분이 바뀌어야 합니다. 웹 서버의 용량, 네트워크 증설, 세션 처리 용량 등이 필요합니다. 이런 증설에서 가장 중요한 부분이 데이터에 대한 부분일 것입니다. 검색도 데이터에 대한 내용이고 구매한 이력을 저장하는 것도 데이터에 대한 내용입니다. 상품을 추천하는 것도 구매한 정보를 이용하여 분석하여 다시 피드백을 주는 데이터에 대한 내용입니다.

빅데이터에서의 “데이터 처리”의 개념은 이렇게 단순 분석이 아닌 사용자의 모든 데이터 요청 유형을 의미하는 것입니다.

그러면 일반적인 데이터와 빅데이터를 나누는 기준은 무엇일까요? 이 부분에 대한 답이 앞에서 정의한 빅데이터 정의 부분에서 “비용/시간”이라고 볼 수 있습니다. 그리고 “비용/시간”은 어떤 기술을 사용할 것인가를 결정하는 요소입니다.

데이터를 처리하는데 있어 기업이 투자 가능한 비용의 범위 내에 있으면 빅데이터라고 하지 않습니다. 예를 들어 하루에 수억건 발생하는 이동통신회사의 콜 데이터를 저장하기 위해 이동통신회사는 수십억 ~ 수백억의 비용을 지불해서 고가의 하드웨어, 고가의 데이터베이스 솔루션에 투자하는 것이 가능하다고 하면 그것은 빅데이터라고 보기 어렵습니다.

현재에도 많은 통신회사가 이런 방식으로 과금 시스템을 구축했습니다. 통신회사가 이렇게 비용을 지불할 수 있는 것은 다루는 데이터가 과금에 사용되는 가장 중요한 데이터이기 때문이겠죠. 이런 중요한 데이터를 저장, 처리하는데 기업들은 기꺼이 비용을 지불할 것입니다.

그러면 동일한 데이터이지만 이렇게 저장된 데이터를 이용하여 과금보다는 조금 덜 중요한 기지국의 증설, 통화 품질 등을 분석하는 자료 중의 하나로 활용하는 경우라면 어떨까요? 그리고 기지국의 증설, 통화 품질 분석 등을 위해서 사용자 콜 정보 이외의 다른 여러가지 부가 정보도 같이 활용한다면 앞에서와 같이 사용자 콜 데이터를 저장, 분석하는데 수십 ~ 수백억의 비용을 지불하면서 시스템을 구축할 수 있을까요?

즉 같은 데이터라도 기업에게 어느 정도로 중요하고 그 중요성 만큼의 비용을 지불할 수 있는 수준을 넘어서는 데이터를 다루는 기술을 빅데이터라고 할 수 있습니다. 과거에도 사용자 콜 데이터를 저장하고 과금 처리를 하고 있었는데 이를 빅데이터라고는 하지 않습니다. 따라서 빅데이터를 다루는 기술은 기본적으로 기존의 데이터 방식에 비해 구축과 운영 비용이 매우 저렴한 기술이라야 합니다.

빅데이터의 특징을 이야기 할때 다음 세가지 특징을 많이 이야기 합니다.

- volume: 데이터의 크기인데 물리적인 크기 보다는 앞에서 설명드린 크기에 대한 내용입니다. 웹 로그 데이터나 다음커뮤니케이션의 한메일, 구글 지메일(gmail) 등의 메일 MIME 데이터는 수 PB 이상이 되지만 트위터 네트워크 데이터는 수십 GB 미만입니다. 앞의 데이터는 안정적인 저장이 가장 큰 해결 과제인 반면 네트워크 데이터는 분석과 처리가 가장 큰 이슈입니다. 따라서 단순히 물리적인 크기가 아닌 데이터의 어떤 ‘속성’이 더 중요하고 그것을 처리하는데 어려움이 있느냐 없느냐 입니다.

- velocity: 데이터를 처리하는 속도입니다. 정의 부분에서도 설명했듯이 배치 분석만을 의미하는 것이 아닙니다. 필요에 따라서 수 많은 사용자 요청을 실시간으로 처리한 후 처리 결과를 반환해주는 기능도 필요합니다. -

- various: 전통적인 기업의 데이터 분석은 기업 내부에서 발생하는 운영데이터인 전사적자원관리(ERP), 공급망관리(SCM), 생산관리시스템(MES), 고객관계관리(CRM) 등의 시스템에 저장되어 있는 데이터베이스 데이터였습니다. 이런 데이터는 잘 정제되어 있고 의미도 명확합니다. 최근에는 이런 데이터뿐만 아니라 기업 외부에서 발생하는 SNS, 블로그, 뉴스, 게시판 등의 데이터나 사용자가 업로드 한 파일, 콜 센터의 고객 상담 내용 등 비정형 데이터도 처리할 수 있는 능력이 있어야 합니다.

그러면 이런 빅데이터는 어떤 회사가 주도하고 있을까요? 지금까지의 소프트웨어는 오라클(Oracle), IBM, HP, 마이크로소프트(MS) 등과 같은 미국의 소프트웨어 회사 중심이었다면 클라우드 컴퓨팅 이후부터의 기술은 인터넷 서비스 업체인 구글(Google), 야후(Yahoo), 페이스북(Facebook), 아마존(Amazon) 등이 주도적으로 이끌고 있습니다.

전통적인 소프트웨어 회사는 그 기술 자체가 회사의 경쟁력이고 판매되는 상품이었기 때문에 소스가 공개되지 않았습니다. 하지만 인터넷 서비스 업체는 기술 자체로 비즈니스를 하는 것이 아니라 그 기술을 이용한 서비스로 비즈니스를 하기 때문에 기술 공개에 있어 자유롭다고 할 수 있습니다.

그리고 이런 회사들이 진정한 빅데이터를 다루고 운영하는 경험이 있는 회사라고 할 수 있습니다. 따라서 빅데이터는 전통적인 소프트웨어 벤더에 의해 만들어진 시장이 아니라 글로벌 인터넷 서비스 업체들에 의해 만들어진 시장과 기술입니다.

관련 기술
그러면 빅데이터를 다루는 기술들은 어떤 것들이 있을까요? 빅데이터라는 용어를 이끌어 낸 것도 Hadoop과 NoSQL의 성공에 있다고 볼 수 있기 때문에 가장 중요한 기술은 Hadoop 이라고 할 수 있습니다. Hadoop 자체는 파일 시스템과 분산 처리 플랫폼이지만 Hadoop을 중심으로 다양한 에코 시스템이 구축되면서 이제 Hadoop은 빅데이터에 있어 산업계 표준이라고 할 수 있습니다.

다음은 빅데이터를 다루는데 필요한 기술입니다.

- 원본 데이터 저장: 대용량 분산 파일 시스템(Hadoop File System 등)
- 구조적 데이터 저장: 대용량 분산 데이터 저장소(NoSQL-HBase, Cassandra, MongoDB 등)
- 배치 분산 병렬 처리: MapReduce(Hadoop), 그래프 분석(Pregel, GlodenORB 등)
- 데이터 스트리밍 프로세싱: S4, Storm
- 데이터 마이닝: Mahout
- 다양한 데이터 분석 알고리즘
- 기타: 분산 관리(ZooKeeper), 분산 큐(kafka), 분산 캐쉬(Memcached, Redis),
- 기존 전통적인 솔루션: BI/DW, RDBMS 등
- 데이터 분석 기술

이런 기술이 필요에 따라 적절하게 도입되어야 빅데이터를 처리할 수 있는 시스템을 구축할 수 있습니다. 언급한 기술 하나하나 쉽지 않은 기술이며 아직 성숙되지 않은 기술도 많습니다. 다행인 것은 대부분 오픈소스로 코드가 공개되어 있고 기술이 많이 공개되어 있다는 것입니다.

여러 기술이 있지만 이 중 가장 중요한 기술은 마지막에 있는 어떤 데이터를 분석할 것인가를 정의하고 데이터간의 관계를 찾아서 의미 없는 데이터로부터 의미를 찾아내는 기술이 가장 중요한 기술입니다.  이 기술은 솔루션이 아닌 사람의 기술입니다. 기업이 빅데이터 처리를 도입하는데 있어 닭이 먼저냐, 달걀이 먼저냐라는 논의가 여기서 나오지 않나 생각합니다.

시스템을 구축하는 기업 입장에서는 “무엇”과 “효과”를 알아야만 시스템 도입을 진행할 수 있지만 국내에는 아직까지 데이터 분석을 잘 할 수 있는 전문가는 많지 않습니다. 따라서 기업에게 “무엇”과 “효과”를 명확하게 제시할 수 있는 경우가 많지 않습니다. 그러면 사람을 키워야 하는데 데이터를 다루는 사람을 키우기 위해서는 데이터를 자주 보게해야 하고 데이터를 만지는 것이 쉬워야 합니다. 그러기 위해서는 빅데이터를 처리하는 시스템을 구축해야 하기 하는데 투자를 위해 다시 “무엇”과 “효과”로 돌아오게 되는 겁니다.

시스템 구축 방안
빅데이터 시스템 구축에 있어 어려움은 시스템 구조가 너무 복잡하다는 것입니다. 앞에 소개한 기술에서 보듯이 하나의 솔루션으로 구축되는 것이 아니라 여러 개의 솔루션이 조합되어야 하고 요구사항에 따라 솔루션 선택도 달라지게 됩니다. 일반적으로 운영조직은 복잡한 시스템 구성을 좋아하지 않습니다. 이유는 당연히 운영의 어려움(비용증가)와 장애 때문일 것입니다.

전통적인 시스템은 주로 웹서버(Apache), 애플리케이션서버(Tomcat, JBoss, Weblogic), 데이터베이스(Oracle, MSSQL, MySQL) 등의 구조로 시스템이 구축되어 운영이나 장애 발생에 쉽게 대응할 수 있었습니다. 하지만 빅데이터를 다루기 위해서는 이런 단순한 구조로 시스템을 구축할 수 있다는 생각을 버려야 합니다. 앞에서 설명했듯이 “무엇”과 “효과”에 대해서는 잘 모르겠고 전문가(시스템, 데이터 분석 모두)도 부족한 상황입니다.

구축 하고자 하는 시스템의 복잡도는 과거의 시스템에 비해 비교도 안될 정도 복잡합니다. 기술도 어렵고 전문 기술 지원 회사도 부족합니다. 글로벌 솔루션 회사들의 솔루션은 대부분 고가의 솔루션으로 빅데이터라는 정의에 부합되지 않습니다. 그러면 어떻게 시스템을 구축하고 전문가를 키워나갈 수 있을까요?

다음은 필자가 생각하는 빅데이터 시스템을 구축할 수 있는 최적의 방안입니다.

국내 새롭게 구축되는 대부분의 시스템은 멋진 청사진과 ROI를 내세우며 단기간의 성과에 치중한다. 앞에서 거듭 이야기한 것처럼 빅데이터는 소프트웨어의 종합 선물 세트이며 예술의 경지에 가깝다고 할 수 있다. 멋진 청사진보다는 내실을 다지는 쪽으로 방향을 잡아야 한다.

먼저 현재 나온 솔루션 중에서 가장 안정적이면서 레퍼런스도 풍부하고 엔지니어링 소싱도 다소 쉽다고 할 수 있는 Hadoop File System과 MapReduce를 도입하여 기업에서 필요할 것 같은 데이터를 저장한다.

저장된 데이터를 hive 등과 같은 쉬운 인터페이스를 이용하여 처리할 수 있는 체계 정도만 구축한다.

여기까지 구축 되면 이제는 엔지니어링 분야가 아닌 데이터를 다루는 분야의 사람이 개입되어 데이터를 여기 저기 뜯어 보고, 해체하고 조합하는 과정을 거치면서 “무엇”에 대한 정의를 할 수 있는 역량을 키운다.

이 단계가 지나면 엔지니어링 분야에서는 분산 시스템에 대한 적용 및 운영 능력이 쌓이게 되고 데이터 분석 분야에서는 데이터가 어떤 모양을 가지고 있고 우리 기업이 필요로 한 데이터가 어떤 데이터인지를 조금씩 알 수 있게 된다.

즉 학습이 되고 학습된 결과가 효과를 거두는 시기가 온다. 이렇게 되면 데이터 분석 분야에서는 구체적인 요구사항을 엔지니어링 쪽으로 알려줄 수 있고 엔지니어링에서는 앞에서 설명한 다양한 기술을 조합하여 이 요구사항에 부합되는 시스템을 구축하여 운영할 수 있게 된다.

이런 사이클은 한번에 끝나는 것이 아니라 지속적으로 기업의 활동과 함께 진화해 나가게 된다.

방안의 핵심은 쉬운것부터, 욕심을 버리고, 지속적으로 할 수 있는 체계를 갖추는 것입니다. 이렇게 하기 위해서는 기업 내부에서 투자를 결정하는 의사결정권자의 전폭적인 지지와 관심이 있어야만 가능합니다.

기존의 방식처럼 특정 사업부에 맞기고 그 사업부의 임원의 성과로만 치부해버리면 단기간의 화려한 성과에 매달리게 되고 주변의 도움도 받지 못하게 됩니다. 가능하면 최고의사결정자(CEO) 또는 최고기술임원(CTO) 직속으로 조직을 두고 여러 사업부에 영향력을 행사할 수 있는 임원급에게 업무를 할당하는 것이 성공의 첫 단추입니다.

전사적인 부서로 두어야 하는 필요성 중의 하나는 여러 부서로부터의 데이터를 수집해야 하고 처리된 결과를 다시 필요로 하는 부서로 제공해야 하기 때문이기도 합니다.

그 다음은 내부에 엔지니어링 조직을 갖추는 것입니다. 많은 기업이 IT 관련 부분은 아웃 소싱으로 처리하고 있습니다. 빅데이터는 한번의 프로젝트로 완료되는 것이 아니라 지속적으로 운영, 개선해나가야 하는 것이 가장 중요하기 때문에 내부에 엔지니어링 조직을 갖추는 것이 가장 좋습니다.

물론 비용이 많이 든다고 생각할 수도 있지만 회사의 규모에 따라 다르겠지만 앞에서 언급한 기술을 유지하는 수준이라면 뛰어난 인력 3~5명 정도를 핵심으로 구성하고 필요에 따라 아웃소싱할 수 있습니다. 문제는 3~5명의 팀을 제대로 구성하기 위해서는 전통적으로 지급되었던 급여 수준보다는 높은 수준의 급여를 지불해야 할 것입니다. 그 수준에 맞는 인력을 채용해야 합니다.

자체 엔지니어링 팀 구성이 어려우면 아웃소싱이 대안이 될 수 있습니다. 아웃 소싱의 경우에도 앞에서 높은 기술력을 유지하고 있는 회사를 소싱해야 하며 엔지니어링 분야 뿐만 아니라 데이터 분석 분야도 같이 다룰 수 있는 회사를 소싱해야 합니다. 그리고 지속적인 관계를 유지할 수 있는 회사라야 할 것입니다.

데이터 특성을 고려한 시스템
빅데이터 시스템을 구축하는데 있어 한가지 더 중요하게 생각해야 될 점은 “데이터의 특징에 맞는 시스템을 구축해야 한다”라는 것입니다.

일반적으로 데이터의 특징은 다음과 같습니다.

- Consistency 저장된 데이터는 모두에게 같은 데이터가 보여야 한다.
- Availability 언제든지 데이터를 저장/조회할 수 있어야 한다.
- Durability 저장된 데이터는 안정적으로 저장되어야 한다.

현재의 데이터 저장 솔루션(DBMS)은 이런 속성을 잘 만족시키고 있습니다. 그렇기 때문에 고가인 것입니다. 문제는 빅데이터 처리에 있어서도 반드시 이 속성을 만족해야 하는지 검토해 봐야 합니다.

페이스북 서비스를 보면 Consistency는 일부 포기하고 있습니다. 내가 쓴 글이 나에게는 보이는데 내 친구에게는 일정 시간 내에는 안보이는 경우도 있습니다. 이것은 서비스 측면에서 Consistency보다는 다른 속성을 더 중요하다고 판단했기 때문에 Consistency 속성을 일부 희생한 것입니다.

국내 서비스 기획자나 의사 결정권자는 절대 받아들이지 않을 속성일 것입니다. 하지만 이제 변해야 합니다. 페이스북이 Consistency 속성을 버린 이유는 그 속성을 유지하는 것보다는 그 속성을 일부 희생하더라도 10억명의 사용자 글을 받아주는 기본 기능이 더 중요했기 때문일 것입니다.

이렇듯 구축하고자 하는 시스템에서 중요하게 생각하는 속성이 무엇인지를 정의하고 그것에 따라 시스템을 구축해야 합니다. 모든 속성을 다 만족하고 몇억명의 사용자에게 서비스되고 안정적으로 운영되는 시스템을 구축하기를 원하는 의사결정권자의 바람은 바람일뿐입니다. 현재의 기술로는 불가능하다고 할 수 있습니다.

중요한 하나를 취하고 덜 중요한 하나를 버리는 의사결정이 필요한 시대입니다.

결론
마지막으로 빅데이터 시스템을 구축하는데 있어 중요한 몇가지를 정리 했습니다.

- 빅데이터는 단순히 많은 데이터를 분석하는것이 아니다.
- 분석뿐만 아니라 시스템, 서비스 자체가 이미 빅데이터에 대한 적응능력이 있어야 한다.
- 시스템, 서비스를 기획, 개발, 운영하는 조직도 빅데이터를 다루는 능력이 있어야 한다.
- 빅데이터는 하나의 솔루션으로 해결할 수 없으며 요구사항, 데이터의 성격 등에 따라 다양한 솔루션으로 조합되어야 한다.
- 오픈소스 중심의 소프트웨어 스택을 구축하고 운영하기 위해서는 내부 기술력을 갖추어야 한다. 외부시스템 구축 회사나 벤더에 의존해서는 안된다.
- 한번 구축하고 관리만 하면 되는 시스템이 아니라 지속적으로 진화시켜 나가야 하는 시스템이다.
- 단기간(6개월~1년 이내)에 전체 시스템을 구축하고자 하는 욕심을 버려야 한다.
- 처음의 실패를 두려워하지 말고 지속적으로 기술을 내재화하고 시스템을 진화시켜야 한다.
- 오픈 소스 검증에 시간을 낭비하기 보다는 작게라도 실행에 옮기는 것이 중요하다.

많은 연구기관에서 2012년에 떠오르는 기술 중의 하나로 빅데이터를 꼽고 있습니다. 기업의 경쟁력을 높이는 방법 중의 하나로 데이터 분석의 시대가 오고 있는 것은 사실이지만 쉽지 않은 기술임에는 틀림없습니다.

이런 분위기에 글로벌 소프트웨어 업체들이 편승해서 자사의 솔루션 판매에 열을 올리고 있습니다. 물론 이런 솔루션이 도움은 줄 수 있을 겁니다. 기업에서 고민하는 운영이나 기술 지원의 문제도 어느 정도는 해결해 줄 수 있을 겁니다. 하지만 데이터의 시대에서는 그 어떤 시스템보다도 데이터 그 자체에 대한 이해가 가장 중요하며 이것은 쉽게 얻을 수 있는 것은 아니라는 사실은 반드시 기억해 주시기 바랍니다

출처 : http://www.bloter.net/archives/90508