IT/모바일
제공 : 한빛 네트워크
저자 : Edd Dumbill
역자 : 한순보
원문 : What is big data?
빅 데이터는 전통적인 데이터베이스 시스템 처리 용량을 넘어서는 데이터다. 빅 데이터는 아주 크고, 매우 빨리 변하며, 기존 데이터베이스 아키텍처의 구조에 맞지 않는다. 이 데이터에서 가치를 얻으려면, 그것을 처리할 다른 방법을 택해야 한다.
2012년 인기 있는 IT 유행어(buzzword)인 빅 데이터는 가능한 것(viable)이 되었는데, 이는 비용 대비 효율 높은 접근 방법이 나타나 대량 데이터의 부피, 속도, 그리고 가변성을 잘 다루었기 때문이다. 빅 데이터 안에는 이전에는 데이터에서의 추출에 필요한 작업량 때문에 숨어 있던 가치 있는 패턴 및 정보가 존재한다. 월마트나 구글 같은 선도기업에는 얼마 전부터 이러한 능력이 있었지만, 엄청난 비용이 들었다. 오늘날의 일반적인 하드웨어, 클라우드 아키텍처와 오픈 소스 소프트웨어는 리소스가 다소 부족한 회사도 빅 데이터 처리를 고려할 수 있게 했다. 빅 데이터 처리는 클라우드에서 값싸게 서버 시간을 빌릴 수 있는 차고(garage)에서 시작하는 작은 스타트업 회사에서도 충분히 가능한 일이다.
한 기관에 빅 데이터의 가치는 분석적 사용과 신제품 조력(enabling)의 두 범주로 나뉜다. 빅 데이터 분석은 쇼핑객의 거래 내용과 사회적, 지리적 데이터를 분석하여 드러나는 고객 간 또래 영향력(peer influence)과 같이, 처리에 비용이 너무 많이 드는 데이터 때문에 이전에는 숨어있던 통찰력을 제공한다. 합리적 시간 내에 모든 데이터 항목을 처리하는 것은 표본 추출이(sampling)라는 골칫거리의 필요성을 제거하고, 미리 정해진 보고서(report)를 게재하는 다소 정적인 특징과 달리 데이터를 조사하는 접근방법을 돕는다.
지난 10년간 성공한 웹 스타트업은 빅 데이터를 새로운 제품과 서비스를 가능하게 한 도구로써 이용한 주요한 예다. 예를 들면, 페이스북은 사용자와 친구의 행동에서 많은 신호를 결합해 상당히 개인화된 사용자 경험을 정성껏 제공하고, 사업 광고의 새로운 방법을 만들 수 있었다. 빅 데이터를 뒷받침하는 아이디어와 도구의 핵심이 구글, 야후, 아마존과 페이스북서 나온 것은 우연이 아니다.
산업에서 빅 데이터가 떠오르는 것은 필연적 상대(counterpart)를 가져온다. 민첩함(agility). 빅 데이터의 가치의 성공적 이용은 실험과 탐구가 필요하다. 새로운 제품을 만들든지 경쟁력 있는 장점을 얻는 방법을 찾든지 이 작업은 호기심과 기업가 세계관을 요구한다.
문제를 명확히 하기 위해, 부피(volume), 속도(velocity), 가변성(variability), V로 시작하는 세 가지가 빅 데이터의 각각 다른 면을 특징짓는데 흔히 사용된다. 이것은 데이터의 특성과 데이터 이용을 가능하게 하는 소프트웨어 플랫폼을 살펴보고 이해하는 것을 도와주는 렌즈이다. 십중팔구 당신은 어느 정도는 이것들과 씨름하게 될 것이다.
부피(Volume)
많은 양의 정보를 처리하는 능력에서 얻는 이익이 빅 데이터 분석의 주요 매력이다. 더 많은 데이터를 갖는 것이 더 나은 모델을 갖는 것보다 낫다. 많은 양의 데이터에 간단한 산수를 적용하는 것이 생각보다 훨씬 효과적일 수 있다. 6가지 요소를 고려하는 것보다 300가지를 고려해 예측한다면 수요를 더 잘 예측할 수 있을까?
부피는 전통적 IT 구조에 가장 직접적 도전이다. 부피는 확장 가능한 저장 공간과 질의에 대한 분산 접근 방식을 요구한다. 많은 회사가 이미 대량의 로그 형태로 보관 데이터를 가지고 있지만, 그것을 처리할 능력은 없다.
데이터 부피가 전통적 관계형 데이터베이스 인프라가 다룰 수 있는 것보다 크다면, 처리 옵션은 크게 Greenplum 같은 데이터웨어하우스(data warehouse) 혹은 데이터베이스의 대량 병렬 처리 아키텍처와 아파치 하둡 기반의 솔루션으로 나뉜다. 보통 다른 V요소 중 하나인 가변(variety)이 작동하는 정도에 의해 선택이 정해진다. 일반적으로, 데이터웨어하우스 접근 방식은 미리 정해진 스키마를 포함하고, 규칙적이고 느리게 변하는 데이터 세트에 적합하다. 반면 아파치 하둡은 처리하는 데이터 구조에 조건이 없다.
하둡의 핵심은 다수 서버에 걸친 분산 컴퓨팅 문제를 위한 플랫폼이라는 점이다. 하둡은 야후가 처음 개발 배포했는데, 이는 검색 인덱스를 컴파일하는 데 구글이 개척한 MapReduce 접근 방식을 구현한다. 하둡의 MapReduce는 여러 서버 간 데이터 세트를 분산하는 것과 데이터에 작업하는 것을 포함한다("map" 단계). 그리고 부분 결과를 다시 결합한다("reduce" 단계).
데이터를 저장하기 위해 하둡은 고유의 분산 파일시스템인 HDFS를 이용하는데, 이것은 다수의 컴퓨팅 노드에서 데이터를 이용할 수 있게 한다. 일반적인 하둡 이용 패턴은 세 단계를 포함한다.
가장 잘 알려진 하둡 사용자인 페이스북의 모델은 이 패턴을 따른다. MySQL 데이터베이스가 핵심 데이터를 저장한다. 그리고는 친구의 관심에 근거한 사용자 추천을 하는 계산이 이뤄지는 하둡에 반영된다. 페이스북은 결과를 MySQL로 전달하여 페이지에서 사용자에게 이를 제공한다.
속도(Velocity)
어떤 조직에 들어가는 데이터 증가 비율인 속도의 중요성은 부피의 중요성과 비슷한 패턴을 따랐다. 과거 산업 일부에 제한된 문제가 이제는 훨씬 광범위한 환경에서 드러나고 있다. 금융 트레이더와 같은 전문화된 회사는 빠르게 변하는 데이터를 다루는 시스템이 오랫동안 그들의 장점이 되게 했다. 이제 우리의 차례다.
왜 그럴까? 인터넷과 모바일 시대는 우리가 제품과 서비스를 전달하고 소비하는 방식이 점점 측정되고, 원 제공자에게로 데이터 흐름을 만들어 준다는 것을 의미한다. 온라인 소매업자는 단지 최종 판매만이 아닌 고객의 모든 클릭과 인터랙션에 대한 대량의 기록을 연결할 수 있다. 예를 들면, 부가적 구매를 추천하고 이 정보를 재빨리 이용할 수 있는 자가 경쟁 우위를 얻는다. 고객이 지리정보가 있는 이미지나 오디오 데이터의 스트리밍 소스를 가지고 있기 때문에, 스마트폰 시대에는 다시 데이터 유입률이 증가한다.
문제는 단지 유입되는 데이터 속도만이 아니다. 예를 들면, 나중의 배치 처리를 위해 큰 규모의 저장 공간에 빠르게 변하는 데이터를 스트리밍 하는 것이 가능하다. 입력에서 데이터를 가져와 결정하는 피드백 순환(loop) 속도가 중요하다. 한 IBM 광고에서 교통 지역의 5분 전 스냅샷(snapshot)을 갖고 길을 건너지 않는다는 이것의 요점을 지적했다. 당신이 리포트 실행 혹은 하둡 작업 종료를 단지 기다릴 수 없을 때가 있다.
빠르게 변하는 데이터에 대한 업계의 용어는 "스트리밍 데이터" 혹은 "복잡 이벤트 처리" 중 하나로 볼 수 있다. 복잡 이벤트 처리는 스트리밍 데이터가 더 광범위한 관련성이 생기기 전 제품 범주에서 자리 잡은 용어이며, 스트리밍의 인기에 따라 이 용어가 줄어들 것 같다.
스트리밍 처리를 자세히 살펴볼 두 가지 주요한 이유가 있다. 첫째는 입력 데이터가 너무 빨라서 전체를 저장할 수 없을 때다. 저장 요구사항을 현실적으로 유지하려면 데이터 스트림이 들어올 때 어느 정도 분석이 일어나야 한다. 최고 규모인 CERN의 대형 하드론 충돌 가속기(Large Hardron Collider)는 너무 많은 데이터를 생성해, 과학자가 유용한 데이터를 버리지 않는다는 신념을 갖고 엄청난 대다수 데이터를 버려야만 한다. 스트리밍을 고려할 두 번째 이유는 애플리케이션이 데이터에 즉각적 반응을 요구하는 곳에서다. 모바일 애플리케이션과 온라인 게임 덕분에 이것은 점점 더 일반적 상황이 된다.
스트리밍 데이터를 다루는 생산 범주는 IBM의 InfoSphere 스트림과 같이 확고한 등록 상품과 트위터의 Storm과 야후의 S4와 같이 웹 업계에서 비롯된 덜 세련되고 여전히 신생인 오픈 소스 프레임워크다.
위에서 언급했듯 단지 입력 데이터에 대한 것은 아니다. 시스템 출력 속도 또한 문제 될 수 있다. 피드백 순환이 더 빠듯해질수록 경쟁우위가 더 커진다. 그 결과가 페이스북 추천과 같이 제품으로 이어지거나, 의사 결정하는 데 사용하는 계기판으로 들어갈 수도 있다.
특히 웹에서 이러한 속도에 대한 필요성은 이미 계산된 정보의 빠른 추출에 최적화된 키-값 저장과 컬럼이 있는 데이터베이스 개발을 주도했다. 이 데이터베이스는 NoSQL이라는 큰 범주 일부를 형성해 관계형 모델이 꼭 맞지는 않는 곳에 사용한다.
가변성(Variety)
데이터는 좀처럼 완벽히 정렬되고 처리를 위해 준비돼 나타나지 않는다. 빅 데이터 시스템의 흔한 주제는 소스 데이터가 다양하고, 관계형 구조에 깔끔히 맞아 들어가지 않는다는 것이다. 이것은 소셜 네트워크의 텍스트, 이미지 데이터, 센서 소스의 직접적 원자료일 수 있다. 이러한 것 중 어떤 것도 애플리케이션에 통합될 준비가 돼 오진 않는다.
어느 정도 보장된 컴퓨터 간 통신인 웹에서도 데이터의 실체는 엉망이다. 다른 브라우저가 서로 다른 데이터를 보내고, 사용자는 정보를 주지 않으며 서로 다른 소프트웨어 버전이나 업체(vendor)를 사용할지도 모른다. 그리고 처리 과정 일부가 사람을 포함한다면, 분명 에러와 불일치가 있을 것이다.
빅 데이터 처리의 일반적 사용은 사람 혹은 애플리케이션의 구조화된 입력으로 사용하기 위해 구조화되지 않은 데이터를 받아서 정렬된 의미를 추출하는 것이다. 한 예는 어떤 이름이 정확히 무엇을 참조하는지 결정하는 과정인 개체 분석(entity resolution)이다. 이 도시가 영국 런던인가, 텍사스 런던인가? 비즈니스 로직이 이런 문제에 도달했을 때, 단순히 추측하고 싶진 않을 것이다.
소스 데이터에서 처리된 애플리케이션 데이터로 이동 과정은 정보 손실을 포함한다. 당신이 깔끔하게 정리할 때, 결국 어떤 것을 버릴 수밖에 없다. 이것은 빅 데이터 원칙을 강조한다. 가능하면, 모든 것을 유지하라. 버리는 약간의 정보에 유용한 신호가 있을 수 있다. 소스 데이터를 잃는다면, 돌아갈 길은 없다.
대중성과 잘 이해된 특징에도, 데이터가 깔끔히 정리됐을 때라도 그 종점이 반드시 관계형 데이터야 하는 것은 아니다. 어떤 데이터 타입은 어떤 계열의 데이터베이스에 더 잘 맞는다. 예를 들면, XML로 인코딩된 문서는 MarkLogic처럼 XML 전용 저장소에 저장할 때 가장 융통성 있게 사용할 수 있다. 소셜 네트워크 관계는 본래 그래프며, Neo4J 같은 그래프 데이터베이스가 그래프에 더 단순하고 효과적으로 작업한다
극단적 데이터 타입 부조화(mismatch)가 아닌 곳에서도 관계형 데이터베이스의 단점은 스키마의 정적 특성이다. 시험적 환경인 애자일에서도 계산 결과는 더 많은 신호 탐지와 추출과 함께 변화한다. 부분적으로 구조화된 NoSQL 데이터베이스는 유연성 면에서 이 요구를 만족한다. NoSQL은 데이터 구성에 충분한 구조를 제공하지만, 저장 이전 데이터의 정확한 스키마를 요구하지 않는다.
클라우드 혹은 기업 내에서?(Cloud or in-house?)
이제 빅 데이터 솔루션 대다수는 세 가지 형태로 제공되는데, 이것들은 오직 소프트웨어만, 응용 혹은 클라우드 기반이다. 어떤 길을 택할지 결정은 데이터 지역성(locality), 프라이버시와 규제(regulation), 인력, 그리고 프로젝트 요구사항 등 다른 것에 의존한다. 많은 기관이 기업 내 구현을 보충하기 위해, 필요할 때(on-demand) 클라우드 자원을 사용하는 등 하이브리드 솔루션을 선택한다.
빅 데이터는 크다(Big data is big)
너무 커서 전통적으로 처리할 수 없는 데이터가 다른 곳으로 이동하기에도 너무 크다는 것은 근본적인 사실이다. IT는 우선순위의 뒤바뀜(inversion)을 겪고 있다. 이동할 필요가 있는 것은 데이터가 아니라 프로그램이다. 미국 인구 조사국 데이터를 분석하고 싶다면, 코드를 그러한 데이터를 가까이에 관리하는 아마존의 웹 서비스 플랫폼에서 실행하는 편이 훨씬 쉽고, 데이터를 전송하는 시간과 돈이 들지 않을 것이다.
데이터가 이동하기에 아주 크지 않더라도 특히 신속히 업데이트되는 데이터를 가지면 집약성(locality)이 여전히 이슈가 될 수 있다. 금융 트레이딩 시스템은 소스 데이터에 가장 빠른 연결을 위해 데이터 센터에 들어가는데, 1밀리 초의 처리 시차를 경쟁우위와 동일시하기 때문이다.
빅 데이터는 엉망이다(Big data is messy)
인프라구조에 대한 것만은 아니다. Pete Warden이 그의 빅 데이터 용어집에서 "아마도, 엉망인 소스 데이터를 유용한 것으로 바꾸는데 드는 시간이 데이터 분석 처리를 하는 나머지 시간을 합한 것보다 많이 든다."라고 했듯이, 빅 데이터 전문가는 데이터를 다루는데 80%의 노력이 데이터를 먼저 깔끔하게 하는 것이라고 계속 보고한다. 데이터 수집과 정리의 고비용에 때문에, 스스로 얻기 위해 실제 필요한 것을 고려할 가치가 있다. 데이터 시장은 일반 데이터를 얻는 수단이며, 종종 역으로 개선한 것으로 이바지할 수 있다. 물론 품질은 가변적이지만, 점점 더 데이터 시장이 경쟁해야 할 벤치마크가 될 것이다.
문화(Culture)
빅 데이터 현상은 수학, 프로그래밍, 그리고 과학적 직관을 결합한 지식 분야인 데이터 과학 출현에 밀접히 얽혀있다. 빅 데이터로 이익을 얻는 것은 기술이 있는 팀에 투자하고, 이익을 위해 데이터를 이해하며 사용하기 위해 조직적으로 팀을 곁에 기꺼이 두는 것을 의미한다.
D.J. Patil은 "데이터 과학팀 구성(Building Data Science Teams)" 보고서에서 데이터 과학자를 다음 자질을 가진 것으로 특징지었다.
이야기하기와 영리함은 분석하는 노력의 이득이 기관에 흡수될지 궁극적으로 좌우하는 관문 요소(gateway factor)다. 데이터 시각화 기술과 실제가 점점 의미 있는 방식으로 분석적 통찰력을 조정하기 위해 인간과 컴퓨터의 틈을 메우는 데 중요해진다.
당신이 가고자 하는 곳을 알아라
마지막으로, 빅 데이터는 만병통치약이 아니다. 당신은 데이터에서 패턴과 단서를 찾을 수 있지만, 그다음에 무엇인가? 북아메리카 지역 IBM의 선행 분석의 리더인 Christer Johnson이 빅 데이터로 시작하는 기업에 충고한다. 우선 무슨 문제를 풀려는지 정하라.
어떻게 광고 전략을 바꿔 고객당 비용을 증가시킬 수 있는가와 같이 실제 비즈니스 문제를 택한다면, 그것이 구현으로 이끌 것이다. 빅 데이터 작업은 기업가 정신에서 이익을 얻지만, 구체적 목표에서도 강력한 이익을 얻는다.
저자 : Edd Dumbill
역자 : 한순보
원문 : What is big data?
빅 데이터는 전통적인 데이터베이스 시스템 처리 용량을 넘어서는 데이터다. 빅 데이터는 아주 크고, 매우 빨리 변하며, 기존 데이터베이스 아키텍처의 구조에 맞지 않는다. 이 데이터에서 가치를 얻으려면, 그것을 처리할 다른 방법을 택해야 한다.
2012년 인기 있는 IT 유행어(buzzword)인 빅 데이터는 가능한 것(viable)이 되었는데, 이는 비용 대비 효율 높은 접근 방법이 나타나 대량 데이터의 부피, 속도, 그리고 가변성을 잘 다루었기 때문이다. 빅 데이터 안에는 이전에는 데이터에서의 추출에 필요한 작업량 때문에 숨어 있던 가치 있는 패턴 및 정보가 존재한다. 월마트나 구글 같은 선도기업에는 얼마 전부터 이러한 능력이 있었지만, 엄청난 비용이 들었다. 오늘날의 일반적인 하드웨어, 클라우드 아키텍처와 오픈 소스 소프트웨어는 리소스가 다소 부족한 회사도 빅 데이터 처리를 고려할 수 있게 했다. 빅 데이터 처리는 클라우드에서 값싸게 서버 시간을 빌릴 수 있는 차고(garage)에서 시작하는 작은 스타트업 회사에서도 충분히 가능한 일이다.
한 기관에 빅 데이터의 가치는 분석적 사용과 신제품 조력(enabling)의 두 범주로 나뉜다. 빅 데이터 분석은 쇼핑객의 거래 내용과 사회적, 지리적 데이터를 분석하여 드러나는 고객 간 또래 영향력(peer influence)과 같이, 처리에 비용이 너무 많이 드는 데이터 때문에 이전에는 숨어있던 통찰력을 제공한다. 합리적 시간 내에 모든 데이터 항목을 처리하는 것은 표본 추출이(sampling)라는 골칫거리의 필요성을 제거하고, 미리 정해진 보고서(report)를 게재하는 다소 정적인 특징과 달리 데이터를 조사하는 접근방법을 돕는다.
지난 10년간 성공한 웹 스타트업은 빅 데이터를 새로운 제품과 서비스를 가능하게 한 도구로써 이용한 주요한 예다. 예를 들면, 페이스북은 사용자와 친구의 행동에서 많은 신호를 결합해 상당히 개인화된 사용자 경험을 정성껏 제공하고, 사업 광고의 새로운 방법을 만들 수 있었다. 빅 데이터를 뒷받침하는 아이디어와 도구의 핵심이 구글, 야후, 아마존과 페이스북서 나온 것은 우연이 아니다.
산업에서 빅 데이터가 떠오르는 것은 필연적 상대(counterpart)를 가져온다. 민첩함(agility). 빅 데이터의 가치의 성공적 이용은 실험과 탐구가 필요하다. 새로운 제품을 만들든지 경쟁력 있는 장점을 얻는 방법을 찾든지 이 작업은 호기심과 기업가 세계관을 요구한다.
빅 데이터는 어떻게 생겼는가?
"클라우드"가 다양한 기술을 포함한 용어인 것처럼, 포괄적 용어 "빅 데이터"는 아주 모호할 수 있다. 빅 데이터 시스템의 입력 데이터는 소셜 네트워크, 웹 서버 로그, 차량 흐름 센서, 인공위성 이미지, 방송 음성 스트림, 은행 거래 내역, 락 음악 MP3, 웹 페이지 콘텐츠, 정부 스캔 문서, GPS 경로 기록, 자동차 원격 측정치, 금융 시장 데이터로부터 쏟아질 수 있고, 이 목록은 끝이 없다. 이들이 정말 모두 같은가?문제를 명확히 하기 위해, 부피(volume), 속도(velocity), 가변성(variability), V로 시작하는 세 가지가 빅 데이터의 각각 다른 면을 특징짓는데 흔히 사용된다. 이것은 데이터의 특성과 데이터 이용을 가능하게 하는 소프트웨어 플랫폼을 살펴보고 이해하는 것을 도와주는 렌즈이다. 십중팔구 당신은 어느 정도는 이것들과 씨름하게 될 것이다.
부피(Volume)
많은 양의 정보를 처리하는 능력에서 얻는 이익이 빅 데이터 분석의 주요 매력이다. 더 많은 데이터를 갖는 것이 더 나은 모델을 갖는 것보다 낫다. 많은 양의 데이터에 간단한 산수를 적용하는 것이 생각보다 훨씬 효과적일 수 있다. 6가지 요소를 고려하는 것보다 300가지를 고려해 예측한다면 수요를 더 잘 예측할 수 있을까?
부피는 전통적 IT 구조에 가장 직접적 도전이다. 부피는 확장 가능한 저장 공간과 질의에 대한 분산 접근 방식을 요구한다. 많은 회사가 이미 대량의 로그 형태로 보관 데이터를 가지고 있지만, 그것을 처리할 능력은 없다.
데이터 부피가 전통적 관계형 데이터베이스 인프라가 다룰 수 있는 것보다 크다면, 처리 옵션은 크게 Greenplum 같은 데이터웨어하우스(data warehouse) 혹은 데이터베이스의 대량 병렬 처리 아키텍처와 아파치 하둡 기반의 솔루션으로 나뉜다. 보통 다른 V요소 중 하나인 가변(variety)이 작동하는 정도에 의해 선택이 정해진다. 일반적으로, 데이터웨어하우스 접근 방식은 미리 정해진 스키마를 포함하고, 규칙적이고 느리게 변하는 데이터 세트에 적합하다. 반면 아파치 하둡은 처리하는 데이터 구조에 조건이 없다.
하둡의 핵심은 다수 서버에 걸친 분산 컴퓨팅 문제를 위한 플랫폼이라는 점이다. 하둡은 야후가 처음 개발 배포했는데, 이는 검색 인덱스를 컴파일하는 데 구글이 개척한 MapReduce 접근 방식을 구현한다. 하둡의 MapReduce는 여러 서버 간 데이터 세트를 분산하는 것과 데이터에 작업하는 것을 포함한다("map" 단계). 그리고 부분 결과를 다시 결합한다("reduce" 단계).
데이터를 저장하기 위해 하둡은 고유의 분산 파일시스템인 HDFS를 이용하는데, 이것은 다수의 컴퓨팅 노드에서 데이터를 이용할 수 있게 한다. 일반적인 하둡 이용 패턴은 세 단계를 포함한다.
- HDFS에 데이터를 로드
- MapReduce 작업, 그리고
- HDFS에서 결과 추출
가장 잘 알려진 하둡 사용자인 페이스북의 모델은 이 패턴을 따른다. MySQL 데이터베이스가 핵심 데이터를 저장한다. 그리고는 친구의 관심에 근거한 사용자 추천을 하는 계산이 이뤄지는 하둡에 반영된다. 페이스북은 결과를 MySQL로 전달하여 페이지에서 사용자에게 이를 제공한다.
속도(Velocity)
어떤 조직에 들어가는 데이터 증가 비율인 속도의 중요성은 부피의 중요성과 비슷한 패턴을 따랐다. 과거 산업 일부에 제한된 문제가 이제는 훨씬 광범위한 환경에서 드러나고 있다. 금융 트레이더와 같은 전문화된 회사는 빠르게 변하는 데이터를 다루는 시스템이 오랫동안 그들의 장점이 되게 했다. 이제 우리의 차례다.
왜 그럴까? 인터넷과 모바일 시대는 우리가 제품과 서비스를 전달하고 소비하는 방식이 점점 측정되고, 원 제공자에게로 데이터 흐름을 만들어 준다는 것을 의미한다. 온라인 소매업자는 단지 최종 판매만이 아닌 고객의 모든 클릭과 인터랙션에 대한 대량의 기록을 연결할 수 있다. 예를 들면, 부가적 구매를 추천하고 이 정보를 재빨리 이용할 수 있는 자가 경쟁 우위를 얻는다. 고객이 지리정보가 있는 이미지나 오디오 데이터의 스트리밍 소스를 가지고 있기 때문에, 스마트폰 시대에는 다시 데이터 유입률이 증가한다.
문제는 단지 유입되는 데이터 속도만이 아니다. 예를 들면, 나중의 배치 처리를 위해 큰 규모의 저장 공간에 빠르게 변하는 데이터를 스트리밍 하는 것이 가능하다. 입력에서 데이터를 가져와 결정하는 피드백 순환(loop) 속도가 중요하다. 한 IBM 광고에서 교통 지역의 5분 전 스냅샷(snapshot)을 갖고 길을 건너지 않는다는 이것의 요점을 지적했다. 당신이 리포트 실행 혹은 하둡 작업 종료를 단지 기다릴 수 없을 때가 있다.
빠르게 변하는 데이터에 대한 업계의 용어는 "스트리밍 데이터" 혹은 "복잡 이벤트 처리" 중 하나로 볼 수 있다. 복잡 이벤트 처리는 스트리밍 데이터가 더 광범위한 관련성이 생기기 전 제품 범주에서 자리 잡은 용어이며, 스트리밍의 인기에 따라 이 용어가 줄어들 것 같다.
스트리밍 처리를 자세히 살펴볼 두 가지 주요한 이유가 있다. 첫째는 입력 데이터가 너무 빨라서 전체를 저장할 수 없을 때다. 저장 요구사항을 현실적으로 유지하려면 데이터 스트림이 들어올 때 어느 정도 분석이 일어나야 한다. 최고 규모인 CERN의 대형 하드론 충돌 가속기(Large Hardron Collider)는 너무 많은 데이터를 생성해, 과학자가 유용한 데이터를 버리지 않는다는 신념을 갖고 엄청난 대다수 데이터를 버려야만 한다. 스트리밍을 고려할 두 번째 이유는 애플리케이션이 데이터에 즉각적 반응을 요구하는 곳에서다. 모바일 애플리케이션과 온라인 게임 덕분에 이것은 점점 더 일반적 상황이 된다.
스트리밍 데이터를 다루는 생산 범주는 IBM의 InfoSphere 스트림과 같이 확고한 등록 상품과 트위터의 Storm과 야후의 S4와 같이 웹 업계에서 비롯된 덜 세련되고 여전히 신생인 오픈 소스 프레임워크다.
위에서 언급했듯 단지 입력 데이터에 대한 것은 아니다. 시스템 출력 속도 또한 문제 될 수 있다. 피드백 순환이 더 빠듯해질수록 경쟁우위가 더 커진다. 그 결과가 페이스북 추천과 같이 제품으로 이어지거나, 의사 결정하는 데 사용하는 계기판으로 들어갈 수도 있다.
특히 웹에서 이러한 속도에 대한 필요성은 이미 계산된 정보의 빠른 추출에 최적화된 키-값 저장과 컬럼이 있는 데이터베이스 개발을 주도했다. 이 데이터베이스는 NoSQL이라는 큰 범주 일부를 형성해 관계형 모델이 꼭 맞지는 않는 곳에 사용한다.
가변성(Variety)
데이터는 좀처럼 완벽히 정렬되고 처리를 위해 준비돼 나타나지 않는다. 빅 데이터 시스템의 흔한 주제는 소스 데이터가 다양하고, 관계형 구조에 깔끔히 맞아 들어가지 않는다는 것이다. 이것은 소셜 네트워크의 텍스트, 이미지 데이터, 센서 소스의 직접적 원자료일 수 있다. 이러한 것 중 어떤 것도 애플리케이션에 통합될 준비가 돼 오진 않는다.
어느 정도 보장된 컴퓨터 간 통신인 웹에서도 데이터의 실체는 엉망이다. 다른 브라우저가 서로 다른 데이터를 보내고, 사용자는 정보를 주지 않으며 서로 다른 소프트웨어 버전이나 업체(vendor)를 사용할지도 모른다. 그리고 처리 과정 일부가 사람을 포함한다면, 분명 에러와 불일치가 있을 것이다.
빅 데이터 처리의 일반적 사용은 사람 혹은 애플리케이션의 구조화된 입력으로 사용하기 위해 구조화되지 않은 데이터를 받아서 정렬된 의미를 추출하는 것이다. 한 예는 어떤 이름이 정확히 무엇을 참조하는지 결정하는 과정인 개체 분석(entity resolution)이다. 이 도시가 영국 런던인가, 텍사스 런던인가? 비즈니스 로직이 이런 문제에 도달했을 때, 단순히 추측하고 싶진 않을 것이다.
소스 데이터에서 처리된 애플리케이션 데이터로 이동 과정은 정보 손실을 포함한다. 당신이 깔끔하게 정리할 때, 결국 어떤 것을 버릴 수밖에 없다. 이것은 빅 데이터 원칙을 강조한다. 가능하면, 모든 것을 유지하라. 버리는 약간의 정보에 유용한 신호가 있을 수 있다. 소스 데이터를 잃는다면, 돌아갈 길은 없다.
대중성과 잘 이해된 특징에도, 데이터가 깔끔히 정리됐을 때라도 그 종점이 반드시 관계형 데이터야 하는 것은 아니다. 어떤 데이터 타입은 어떤 계열의 데이터베이스에 더 잘 맞는다. 예를 들면, XML로 인코딩된 문서는 MarkLogic처럼 XML 전용 저장소에 저장할 때 가장 융통성 있게 사용할 수 있다. 소셜 네트워크 관계는 본래 그래프며, Neo4J 같은 그래프 데이터베이스가 그래프에 더 단순하고 효과적으로 작업한다
극단적 데이터 타입 부조화(mismatch)가 아닌 곳에서도 관계형 데이터베이스의 단점은 스키마의 정적 특성이다. 시험적 환경인 애자일에서도 계산 결과는 더 많은 신호 탐지와 추출과 함께 변화한다. 부분적으로 구조화된 NoSQL 데이터베이스는 유연성 면에서 이 요구를 만족한다. NoSQL은 데이터 구성에 충분한 구조를 제공하지만, 저장 이전 데이터의 정확한 스키마를 요구하지 않는다.
실제
우리는 빅 데이터의 특성을 살펴봤고, 높은 차원에서 빅 데이터의 세계를 조사했다. 대개 구현 단계에 들어서면, 위의 툴 선택을 넘어서는 고려할 차원이 있다.클라우드 혹은 기업 내에서?(Cloud or in-house?)
이제 빅 데이터 솔루션 대다수는 세 가지 형태로 제공되는데, 이것들은 오직 소프트웨어만, 응용 혹은 클라우드 기반이다. 어떤 길을 택할지 결정은 데이터 지역성(locality), 프라이버시와 규제(regulation), 인력, 그리고 프로젝트 요구사항 등 다른 것에 의존한다. 많은 기관이 기업 내 구현을 보충하기 위해, 필요할 때(on-demand) 클라우드 자원을 사용하는 등 하이브리드 솔루션을 선택한다.
빅 데이터는 크다(Big data is big)
너무 커서 전통적으로 처리할 수 없는 데이터가 다른 곳으로 이동하기에도 너무 크다는 것은 근본적인 사실이다. IT는 우선순위의 뒤바뀜(inversion)을 겪고 있다. 이동할 필요가 있는 것은 데이터가 아니라 프로그램이다. 미국 인구 조사국 데이터를 분석하고 싶다면, 코드를 그러한 데이터를 가까이에 관리하는 아마존의 웹 서비스 플랫폼에서 실행하는 편이 훨씬 쉽고, 데이터를 전송하는 시간과 돈이 들지 않을 것이다.
데이터가 이동하기에 아주 크지 않더라도 특히 신속히 업데이트되는 데이터를 가지면 집약성(locality)이 여전히 이슈가 될 수 있다. 금융 트레이딩 시스템은 소스 데이터에 가장 빠른 연결을 위해 데이터 센터에 들어가는데, 1밀리 초의 처리 시차를 경쟁우위와 동일시하기 때문이다.
빅 데이터는 엉망이다(Big data is messy)
인프라구조에 대한 것만은 아니다. Pete Warden이 그의 빅 데이터 용어집에서 "아마도, 엉망인 소스 데이터를 유용한 것으로 바꾸는데 드는 시간이 데이터 분석 처리를 하는 나머지 시간을 합한 것보다 많이 든다."라고 했듯이, 빅 데이터 전문가는 데이터를 다루는데 80%의 노력이 데이터를 먼저 깔끔하게 하는 것이라고 계속 보고한다. 데이터 수집과 정리의 고비용에 때문에, 스스로 얻기 위해 실제 필요한 것을 고려할 가치가 있다. 데이터 시장은 일반 데이터를 얻는 수단이며, 종종 역으로 개선한 것으로 이바지할 수 있다. 물론 품질은 가변적이지만, 점점 더 데이터 시장이 경쟁해야 할 벤치마크가 될 것이다.
문화(Culture)
빅 데이터 현상은 수학, 프로그래밍, 그리고 과학적 직관을 결합한 지식 분야인 데이터 과학 출현에 밀접히 얽혀있다. 빅 데이터로 이익을 얻는 것은 기술이 있는 팀에 투자하고, 이익을 위해 데이터를 이해하며 사용하기 위해 조직적으로 팀을 곁에 기꺼이 두는 것을 의미한다.
D.J. Patil은 "데이터 과학팀 구성(Building Data Science Teams)" 보고서에서 데이터 과학자를 다음 자질을 가진 것으로 특징지었다.
- 테크니컬 전문가: 일반적으로 최고의 데이터 과학자는 어떤 과학 분야에 깊은 전문 지식을 가진다.
- 호기심: 내부에 숨겨진 것을 알려는, 문제를 발견하고, 테스트할 수 있는 매우 명확한 가설 집합으로 만드는 갈망
- 이야기하기(storytelling): 이야기하기 위해 데이터를 사용하고 효과적으로 전달할 능력
- 영리함: 창의적 방식으로 문제를 다르게 보는 능력
이야기하기와 영리함은 분석하는 노력의 이득이 기관에 흡수될지 궁극적으로 좌우하는 관문 요소(gateway factor)다. 데이터 시각화 기술과 실제가 점점 의미 있는 방식으로 분석적 통찰력을 조정하기 위해 인간과 컴퓨터의 틈을 메우는 데 중요해진다.
당신이 가고자 하는 곳을 알아라
마지막으로, 빅 데이터는 만병통치약이 아니다. 당신은 데이터에서 패턴과 단서를 찾을 수 있지만, 그다음에 무엇인가? 북아메리카 지역 IBM의 선행 분석의 리더인 Christer Johnson이 빅 데이터로 시작하는 기업에 충고한다. 우선 무슨 문제를 풀려는지 정하라.
어떻게 광고 전략을 바꿔 고객당 비용을 증가시킬 수 있는가와 같이 실제 비즈니스 문제를 택한다면, 그것이 구현으로 이끌 것이다. 빅 데이터 작업은 기업가 정신에서 이익을 얻지만, 구체적 목표에서도 강력한 이익을 얻는다.
TAG :
최신 콘텐츠