5년 전만 해도 페타바이트급 히스토리 데이터를 상용 하드웨어를 사용해 분석하는 것은 상상에 가까운 일이었다. 오늘날 수천 개의 노드로 구축된 하둡 클러스터는 아주 흔하다. 하둡과 같은 오픈소스 기술은 페타바이트급 데이터를 상용과 가상화 하드웨어를 사용해 효율적으로 처리해 이런 기능을 모든 개발자들이 값싸게 이용할 수 있게 해준다. 그 결과 빅데이터라는 분야가 열리게 되었다.

빅데이터는 지속적인 데이터 유입으로 인해 거대해진다. 대용량 환경에서 데이터는 막대하게 유입되는 가운데서도 데이터 분석과 저장이 필요하다.
볼트DB(VoltDB)의 소프트웨어 아키텍트 존 허그는 단순히 데이터를 저장하고 차후에 분석하는 대신 아파치 카프카(Apache Kafka)와 같은 툴을 활용해 극도로 높은 유입률을 유지하면서도 데이터 통합 과정에서 분석을 수행할 수 있는 수준에 아마도 이르렀다고 생각했다.
- 폴 베네치아

비슷한 혁명이 이른바 패스트 데이터(fast data)와 함께 일어나고 있다. 빅데이터는 클릭-스트림 데이터, 금융 티커 데이터, 로그 데이터 집합, 센서 데이터 등 종종 엄청난 속도로 생성되는 데이터에 의해 만들어진다. 이런 이벤트들은 종종 초당 수천에서 수만 번씩 발생하곤 한다. 이런 유형의 데이터가 흔히들 '소방 호스(fire hose)'라고 불리는 것도 이해가 간다.

빅데이터의 소방호스에 대해 이야기할 때 그 데이터 볼륨은 데이터웨어하우스에서의 기가바이트, 테라바이트, 페타바이트 단위로 측정하지 않는다.

빅데이터에서는 데이터 볼륨을 시간 단위로 측정한다. 초당 몇 메가바이트, 시간당 몇 기가바이트, 혹은 하루당 몇 테라바이트 하는 식이다. 데이터 볼륨과 함께 속도도 이야기하는데, 이것이 바로 데이터웨어하우스와 빅데이터 간 핵심적인 차이다. 빅데이터는 그냥 큰 게 아니라 빠르기도 하다.

HDFS, 애널리틱 RDBMS, 혹은 플랫 파일에 이르기까지 빠르게 소방호스를 따라오는 새로운 데이터가 도착했을 때 즉각적으로 처리할 능력이 없어서 쌓아두게 된다면 빅데이터의 이점은 사라져 버린다.

소방호스는 능동 데이터, 즉각적인 상태, 혹은 현시적인 목표 없는 데이터를 대표한다. 반면 데이터웨어하우스는 히스토리 데이터를 훑어서 과거를 이해하고 미래를 예측하는 방법이다.

도착하는 데이터에 맞춰 행동하는 것은 상용 하드웨어상에서는 비용이 크고 거의 불가능에 가까울 정도로 비효율적이었다. 빅데이터의 가치처럼 패스트 데이터의 가치는 메시지 큐와 오픈소스 카프카(Kafka)와 스톰(Storm)과 같은 스트리밍 시스템의 리이미징된 이행과 오픈소스 NoSQL과 NewSQL 오퍼링과 데이터베이스의 리이미징된 이행을 통해 구현된다.

패스트 데이터에서 가치 잡기
들어오는 데이터에서 가치를 붙잡는 최선의 방법은 들어오는 즉시 반응하는 것이다. 자신이 배치로 들어오는 데이터를 처리한다면, 이미 시간이 뒤쳐진 것이고 가치도 상실한 셈이다.

초당 수천에서 수백만 이벤트 단위로 도달하는 데이터를 처리하기 위해서는 두 가지 기술이 필요하다. 우선 들어오는 속도로 이벤트를 전달할 수 있는 스트리밍 시스템과 들어오는 대로 각각의 아이템을 처리할 수 있는 데이터 스토어가 바로 그 두 가지다.

패스트 데이터의 딜리버리
인기 스트리밍 시스템인 아파치 스톰과 아파치 카프카 두 가지가 지난 몇 년 간 등장했다. 트위터의 엔지니어링 팀이 개발한 스톰은 초당 수백만 메시지에 달하는 데이터 스트리밍을 안정적으로 처리할 수 있다.
링크드인의 엔니지어링 팀이 개발한 카프카는 높은 처리율(high-throughput)의 분산형 메시지 큐(distributed Message Queue) 시스템이다. 두 스트리밍 시스템 모두 패스트 데이터 프로세싱의 필요성을 해결해준다. 하지만 카프카가 두드러진다.

카프카는 메시지 큐로 디자인해 기존 기술에서 나온 문제점을 해결했다. 카프카는 무한한 확장성, 분산 배치, 멀티테넌시(multitenancy), 강력한 지속성을 가진 우버(über)-큐의 일종으로 디자인됐다. 조직은 하나의 카프카 클러스터를 배치해 모든 메시지 큐 니즈를 충족할 수 있다. 여전히 카프카의 핵심은 메시지 딜리버리로, 어떠한 프로세싱이나 큐잉도 지원하지 않는다.

패스트 데이터 프로세싱
메시징은 솔루션의 한 부분에 불과하다. 전통적인 관계형 데이터베이스는 성능에 제한되기 마련이었다. 몇몇은 높은 비율로 데이터를 저장할 수 있지만 데이터가 소화되는 대로 이에 맞춰 인증, 강화, 행동하는 데는 기대에 미치지 못했다.

NoSQL 시스템이 클러스터링과 고성능을 해결했지만 동시에 전통적인 SQL 기반 시스템이 제공하던 힘과 안전성의 상당 부분을 포기해야 했다. 하지만 자신이 이벤트 단위로 복잡한 쿼리와 비즈니스 로직 작업을 처리한다면 인메모리 NewSQL 솔루션이 성능과 전통적인 복잡성 모두의 필요 기준을 충족시킬 수 있을 것이다.

카프카처럼 일부 NewSQL 시스템은 무공유 클러스터링을 중심으로 구축되어 있다. 로드는 성능을 위해 클러스터 노드들에 분산되어 있다. 데이터는 안정성과 가용성을 위해 클러스터 노드에 복제된다. 증가한 로드를 처리하기 위해 노드는 클러스터에 투명하게 추가할 수 있다.

노드는 제거될 수 있고 고장나더라도 나머지 클러스터는 계속해서 기능할 것이다. 데이터베이스와 메시지 큐 모두 단일 장애점(Single Point of Failure) 없이 디자인됐다. 이 기능들은 확장을 위해 설계된 시스템의 전형적인 특색이다.

이에 더해 카프카와 일부 NewSQL 시스템은 클러스터링과 다이나믹 토폴로지(dynamic topology)를 강력한 보장을 마다하지 않고도 확장에 활용할 능력이 있다. 카프카는 메시지-오더링 보장을 제공하는 반면 일부 인메모리 프로세싱 엔진은 직렬 가능(serializable)할 수 있는 지속성과 ACID 시멘틱을 제공한다.

두 시스템 모두 클러스터 인지 클라이언트를 활용해 더 많은 기능을 제공하거나 구성을 단순화한다. 마지막으로 둘 모두 RAID나 다른 로컬 스토리지 스키마보다는 각기 다른 장비 상의 디스크에 걸친 중복 내구성(redundant durability)을 달성한다.

빅데이터 패스트 처리를 위한 툴킷의 조건
빅데이터 소방호스 처리를 위한 시스템에서 원하는 것은 다음과 같다.

- 네이티브 무공유 클러스터링의 중복과 확장성 이점을 갖춘 시스템
- 노드당 높은 처리율을 달성하기 위한 인메모리 스토리지와 프로세싱에 기댄 시스템
- 섭취 시 프로세싱을 제공하는 시스템. 시스템이 조건부 로직을 수행할 수 있나? 시스템이 결정을 통지하기 위해 기가바이트 이상의 기존 상태 쿼리가 가능한가?
- 분리된 운영 시스템과 자체 작업에 대해 강력한 보증을 하는 시스템. 이를 통해 사용자들은 현재 문제나 데이터 분화(data divergence)을 처리하는 대신 더 단순한 코드를 작성하고 비즈니스 문제에 집중할 수 있다. 강력한 지속성을 제공하지만 이로 인해 성능이 크게 저하된 시스템에 주의하라.

이런 속성을 갖춘 시스템들이 NewSQL, NoSQL, 하둡 커뮤니티에서 등장하고 있지만, 각기 다른 시스템마다의 기본 조건에 따라 각기 다른 장단점이 있다. 실시간으로 패스트 데이터에 대응하고자 하는 조직에게 이런 툴은 고속 데이터를 이해하는데 연관된 복잡성 문제 상당수를 없애줄 수 있다.

카프카는 데이터를 수많은 제작자와 소비자 사이에 이동시키는 안전하고 고가용적인 방법과 관리자를 편안하기 해줄 오퍼링 성능과 튼튼함을 함께 제공한다. 인메모리 데이터베이스는 강력한 트랜젝셔널 로직(transactional logic), 계산(counting), 집합(aggregation)를 갖춘 온전한 관계형 엔진을 어떤 부하든 감당할 수 있는 충분한 확장성과 함께 제공할 수 있다. 관계형 데이터베이스 이상으로 이 시스템은 카프카의 메시징 인프라를 보완하기 위한 프로세싱 엔진 역할을 해야 한다.

자신의 조직이 필요한 게 무엇이든 이 툴들을 조합하면 종종 더 취약하고 이질적인 시스템을 대체함에 있어서도 작업을 더 빠르게 해주고 지금보다 더 많이 알게 해줄 것이다.