빅데이터는 전통 데이터베이스의 연산 수용능력을 초과한 "너무 크고, 빠르게 변하거나 데이터베이스에 구조화하기 힘든" 데이터를 말한다. 이런 데이터에서 가치를 얻으려면 대안을 찾는 수 밖에.
2012년 핫키워드 빅데이터는 거대한 데이터 3Vsvolume, velocity and variability를 싼 값에 다룰 수 있는 형태로 실용화되고 있다. 이런 빅데이터 내에 의미있는 패턴과 정보가 묻혀 있는데, 추출하는 일은 결코 쉽지 않아 예전엔 그냥 그대로 묻혀 있었다. 구글이나 월마트같은 소수의 선두기업만이 막대한 비용을 들여 빅데이터 처리 능력을 갖추고 있었지. 그러나 오늘날의 하드웨어, 클라우드, 그리고 오픈소스는 이제 싼 값에 클라우드를 렌트하여 사업하는 벤처기업마저도 빅데이터를 처리할 수 있게 도와준다.
빅데이터의 가치는 분석 용도와 신규 제품 개발에 활용되는 두 개의 분야로 나뉘는데, 빅데이터 분석은 그간 막대한 비용 뒷켠에 꽁꽁 숨어있던 인사이트를 찾는데 사용된다. 예를 들면, 쇼핑몰 고객의 거래내역, 사회적 지역적 데이터를 분석함으로서 고객들의 영향력을 분석한다. 또, 빠른 시간내 모든 데이터를 연산하는게 가능하여 샘플링하는 번거로움이 없고 사전 정의된 질의에 대한 정기적인 리포트를 뽑아내는 기존의 다소 정적인 방식 대신 새로운 데이터 분석과 교정작업을 필요할때 즉각 처리할 수 있다역자주: SQL 리포트 서비스나 비지니스 인텔리전스 Predefined or ad-hoc reports 참고.
지난 십여년 간 성공한 신생 웹 기업의 신규 사업과 서비스가 바로 이런 빅데이터를 잘 활용한 사례인데, 예를 들면, 페이스북은 사용자 행태와 친구관계를 분석함으로써 고급스럽게 개인화된 UX와 새로운 형태의 광고 사업을 만들어낸 것이다. 빅데이터 대부분의 아이디어와 솔루션이 구글, 야후!, 아마존 그리고 페이스북 등 기업에서 나온 것은 결코 우연히 아닌 것이다.
기업에 빅데이터 출현은 민첩함을 필연적 과제로 안겨다 준다. 빅데이터에서 성공적으로 가치를 얻으려면 연구와 실험을 필요로한다. 신규 사업을 개발하든 시장에서 경쟁 우위를 점할 방법을 찾든 호기심과 기업적 전망이 필요한 것이다.
What does big data look like?
"빅데이터"는 포괄적인 용어로 꽤 모호하다. "클라우드"가 다양한 기술을 커버하는것처럼 말이지. 빅데이터 시스템에 인풋이 되는 데이터는 웹로그, 위성 이미지, 트래픽 로그, 소셜 네트워크, 인터넷뱅킹 거래내역, 웹 컨텐츠, 금융 관련 데이터 등 헉헉! 보시는바와 같이 다양하거든?
의미가 좀 더 명확하게 표현하기 위해, 3Vs (volume, velocity and variety) 라는 것이 있다. 이는 일반적으로 빅데이터의 각기 다른 면을 표현하고자 사용되는데, 데이터의 본질과 그에 맞는 플랫폼을 확인하고 이해하는데 도움주는 잣대로 쓰면 된다.
Volume
거대한 정보를 연산처리할 수 있는 능력이 빅데이터 분석의 주된 매력이다. 사실 좋은 모델보다는 그냥 데이터셋이 많은게 좋거든. 단지 팩터가 늘어난다고 보다 정확한 수요예측이 가능해지진 않고, 거대한 데이터셋에 간단한 수학이 오히려 효과적일때가 있다.
이런 빅 volume은 기존의 IT 구조에 즉각 도전장을 던지지. 확장가능한 스토리지와 분산 쿼리 접근을 요구하니까. 많은 회사들은 이미 많은 데이터를 보유하고 있겠지만, 연산처리할 엄두를 못 내고 있는게 현실일게다.
기존의 관계형 데이터베이스에 안맞는 거대한 볼륨이 있다면, 데이터웨어하우스나 Greenplum 같은 데이터베이스 또는 Apache Hadoop 기반 솔루션들과 같은 분산처리시스템을 골라야할게다. 이 선택에는 3Vs 중에서 "variety"를 갖다 대면 된다. 일반적으로 데이터웨어하우징은 사전 정의된 스키마와 일정하고 느리게 변화하는 데이터셋에 적합한 반면, Apache Hadoop은 요런 데이터 구조에 문제가 없다.
Hadoop은 다수의 서버를 묶어 분산처리하는 플랫폼인데, 분산처리하는 "map" 단계와 결과를 취합하는 "reduce" 단계로 이루어진 구글의 MapReduce 모델을 본떠 만든 프로젝트로써 야후!의 더그커팅에 의해서 처음 개발되고 배포되었다.
데이터 저장은 자체 분산 파일시스템인 HDFS를 활용하는데 Hadoop의 일반적인 사용 패턴은 다음과 같다:
- HDFS로 데이터를 로딩
- MapReduce로 연산처리
- HDFS에 결과 저장
이 과정은 배치 연산이기때문에 분석이나 비대화식 컴퓨팅에 적합하다. 이 때문에 Hadoop이 데이터베이스 또는 데이터웨어하우스 솔루션은 아니지만 분석 보조자의 역할을 수행할 수 있다는 말씀.
Hadoop을 이러한 패턴으로 사용하는 가장 잘 알려진 사용자로는 페이스북이 있는데, MySQL 데이터베이스에 실데이터를 저장하고 Hadoop에 백업해서 친구 추천같은 작업을 MapReduce로 처리하고 다시 결과를 MySQL로 업데이트한다고 하지.
Velocity
데이터의 velocity의데이터를 처리하는 속도 중요성은 volume과 비슷한 패턴을 갖고 있다. 금융쪽과 같이 일부 특수 산업 분야에만 제한되어있던 문제들이 이제는 훨씬 광범위한 분야로 나타나고 있다. 요거 이제 우리 모두가 겪을 차례다.
왜냐? 인터넷과 모바일의 시대는 곧 우리 모두 서비스를 이용하면서 서비스 제공자에게 데이터를 꾸준히 만들어냄을 의미하니까. 쇼핑몰 사업자들은 단순 판매만이 아니라 고객의 클릭 로그나 행태를 모두 수집하면서 신속하게 그러한 정보를 활용하여 추가 구매를 추천하는 등의 방식으로 경쟁력을 얻을 수 있다. 스마트폰의 시대는 지형정보 이미지나 음성같은 데이터들로 유입량이 더 많아졌지.
단순히 유입되는 데이터의 속도만이 문제는 아니다. 배치 작업으로 스토리지에 밀어넣으면 되니까. 중요한건 들어온 데이터를 빠른 속도로 처리하여 결과를 얻는데 달려있다. IBM에 광고를 예로, 5분 전의 트래픽 정보 처리 결과 가지고는 도로를 못건넌다는. 즉, Hadoop 배치 job 완료될 때까지 못기다리겠다는 경우가 있다는것.
이렇게 빠른 속도로 유입되는 데이터를 처리하는 것을 공돌이 용어로는 "스트리밍 데이터" 또는 "컴플렉스 이벤트 프로세싱"이라고 한다. 먼저 일반적으로 사용된건 "스트리밍 프로세싱"이고, 뒤에 나온 용어는 제품용에다 갖다 붙이면서 탄생한 용어다.
스트리밍 프로세싱을 고려하는 이유는 크게 두 가지로 생각할 수 있는데, 첫번째로는 빠르게 들어오는 인풋데이터 전부를 스토리지에 때려넣기 버겁고 스토리지를 어떤 분석 가능한 형상으로 계속 유지하려는 경우다역자주: 극단적인 예로 초대형 입자가속기 얘기가 잠깐 나오는데 유용한 정보 안지웠길 희망한다네. 스트리밍을 고려하는 두 번째 이유는 어플리케이션이 즉각 반응해야하는 경우다. 모바일 어플리케이션과 온라인 게임의 출현 덕분에이 점점 더 일반적인 상황이지.
스트리밍 데이터를 처리하기위한 제품은 IBM의 InfoSphere Streams, 그리고 아직은 덜 익은(?) 트위터의 Storm과 야후!의 S4가 있다역자주: Apache Hama Realtime Processing도 참고하시라.
앞서 언급했듯, 비단 인풋 데이터에 대한 얘기만은 아니다. 시스템의 아웃풋 결과 처리 속도 또한 마찬가지라는 말씀. 예를 들면, 결과를 곧바로 페이스북의 추천 서비스에 반영하거나 의사결정 대쉬보드에 올려줘야 경쟁력을 갖춘다는 이야기.
특히 key-value 저장소나 column-oriented 데이터베이스같은 NoSQL 기반에 미리 요약된 정보를 빠르게 조회하도록 만든 웹서비스가 이러한 빠른 스트리밍 프로세싱이 필요하다!
Variety
데이터가 연산 가공하기 편하게 잘 준비된 형태를 갖추는 경우는 매우 드물다. 빅데이터 시스템은 관계형 구조에 안맞는 다양한 데이터를 다루는 것이 일반 주제다. 소셜 네트워크, 이미지, 센서의 raw 데이터에서 나온 텍스트같은 것들 말이지. 이것들은 개발자 어플리케이션에 쏙 들어갈 준비가 안 되어있다.
웹에서도, 컴퓨터간의 통신이 이뤄져야하는 경우 데이터는 매우 지저분하다. 다른 브라우저가 전송한 각 데이터, 정보를 제대로 입력안하는 유저들, 각기 다른 버전의 소프트웨어로 접근하지. 게다가 이런 과정에 사람 손을 타는 작업이 있으면, 오류와 모순 투성일게다.
빅데이터 프로세싱의 일반적인 사용은 비정형 데이터를 가지고 사람 또는 어플리케이션에 정형화된 인풋용으로 요구된 의미를 찾는것이다. 개체명 식별을 예로텍스트 마이닝에 Name/Entity resolution, "런던"이 영국의 "런던"을 가리키는지 텍사스의 "런던"을 가리키는지 파악할 수 있다.
원본 데이터에서 필요한 데이터로 전환하는 과정에 정보의 손실이 있을수 있다. 다 끝나고 작업자가 원본을 지워버릴수 있겠지. 빅데이터의 핵심이니까 지금부터 밑줄 쫙~. "보관할 수 있을때, 보관해라". 지워버린 데이터에 유용한 정보가 또 숨겨져 있을 수 있다. 지워버리면 되돌릴 수가 없으니.
관계형 데이터베이스가 인기있고 친숙하더라도 언제나 사용해야하는건 아니다. 특정 데이터 형식은 그에 걸맞는 데이터베이스에 잘 맞다. 예를 들어, XML로 인코딩된 문서는 MarkLogic같은 XML 특화된 저장소에 저장하는게 좋다. 소셜 네트워크 그래프는 Neo4j같은 그래프 데이터베이스에 저장하는것이 더 간단하고 효과적이다.
근본적으로 데이터 형식에 문제가 없더라도, 관계형 데이터베이스의 단점은 정적인 스키마다. 더 많은 시그널을 탐지하고 발견하면서 계산 결과는 계속 진화하니까. NoSQL 이놈들은 데이터를 구성하기에 충분한 구조를 제공하지만, 저장하기 전에 고정된 스키마를 필요하지 않거든.
--
빅데이터 = 말 그대로 '크고 많은 양'의 데이터들. 스마트폰, 스마트패드 등 단말기가 많아지고 소셜네트워크서비스(SNS) 등 정보채널이 확대되면서 이용자들이 생산, 유통하는 정보 양이 기하급수적으로 증가했다. 형태가 각기 다른 정보들을 수집하고 분석해 이용하는 방법이 중요하다.
No comments:
Post a Comment