일인 미디어 스토리기업 경영포럼

[전문가 칼럼] 김윤호 전문위원의 금융칼럼-

빅 데이터 처리의 일반적 사용은 사람 혹은 애플리케이션의

구조화된 입력으로 사용하기 위해

가변성(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밀리 초의 처리

시차를 경쟁우위와 동일시하기 때문이다.