데이터를 수집할 때 빅데이터에서는 2가지 형태로 데이터를 수집한다.

벌크형태와 스트리밍형태로 이 두가지인데 이 두가지 형태에 대한 수집 방법에 대해 공부한 것을 작성한다.

지금까지 계속 말해왔었지만, 대부분의 빅데이터는 분산 스토리지에 데이터를 저장한다.

확장성이 높고 안정성이 높기 때문인데, 대표적으로 우리가 가장 잘 아는 AWS S3 등이 있다.

AWS S3객체 스토리지(Object Storage),

Apache HadoopHDFS(Hadoop Distributed File System)는 File Storage(file based storage)이다.

Apache HadoopHDFS외에 HDDS(Hadoop Distributed Data Store)을 Ozone 프로젝트을 통해 지원한다.

이 Ozone 프로젝트는 S3와 같은 Object Storage를 지원한다(Object Storage를 비롯한 몇 개의 Data Storage Type은 별도의 공부를 해서 포스트로 작성하겠다).

어쨌든 빅데이터에서 데이터들을 수집하여 이들을 집계 효율이 좋은 분산 스토리지를 만드는 것을 데이터 수집이라고 한다.

여기에는 데이터 수집부터 시작해서 데이터의 구조화, 분산 스토리지에 장기적인 저장 등을 포함한다.

즉, 우리가 일반적으로 생각하는 데이터를 모으는 것부터 시작해서 구조를 만들고 저장하는 일련의 형태를 데이터 수집이라고 한다.

이런 데이터 수집 형태로 2가지가 있는데, 벌크형(Bulk)과 스트리밍형(Streaming)다.

먼저 벌크형은 우리가 전통적인 DW에서 사용하던 형태로 이미 DB, 파일 서버 등에서 각각의 방식으로 데이터를 추출한다.

또한 전통적인 DW뿐만 아니라 빅데이터에서도 과거에서부터 축적된 대량의 데이터가 있거나 기존의 DB에서 데이터를 추출할 때 이 방식을 사용한다.

주로 규모가 큰 데이터를 다루고 높은 신뢰성이 요구될 때 사용되며, ETL 서버를 사용한다.

이 ETL 서버를 이용해서 DB, 파일 서버 등 다양한 데이터 소스들로부터 데이터를 가지고 와서 ETL(Extract Transform Load) 과정을 거쳐 분산 스토리지에 저장하고,

cronjob처럼 일정 간격마다 실행하여 데이터를 분산 스토리지에 저장한다.

이렇게 일정 간격마다 ETL을 실행하여 분산 스토리지에 저장하는 것은 한 번에 너무 많은 데이터가 저장되지 않게 하여 이로 인해 발생할 문제들을 방지하는데 목적이 있다.

한 번에 너무 많은 데이터를 ETL을 통해 분산 스토리지에 저장하려고 하면, 시간이 너무 오래 걸린다던가 용량이 너무 커져서 오류가 발생하는 등의 일이 발생한다.

특히 이런 벌크형으로 데이터 수집을 하는 경우는 신뢰성이 중요한 경우에도 사용한다. 데이터를 그대로 데이터 소스가 가지고 있어서 유실되지 않기 때문이다.

벌크형으로 데이터 수집을 할 경우 보통 워크플로우를 통하여 작업을 하고 에러가 발생하는 등의 특이사항이 발생하면 알람을 통해 이를 인지하고 대처한다.

다음은 스트리밍형의 데이터 수집을 살펴본다.

스트리밍은 우리가 이미 알고 있는 그것이다.

실시간성으로 계속 데이터가 끊임없이 마치 흐르는 물처럼 데이터가 흘러들어오는 것을 수집하는 것이다.

이런경우는 보통 IoT를 떠올릴 수 있다. IoT처럼 다수의 클라이언트가 계속해서 작은 데이터를 계속 전송하는데 이런 전송방식을 메시지 배송(Message Delivery)라고 한다.

Message Delivery는 보통 네트워크를 통해 수집되기 때문에 데이터의 양에 비해서 통신을 위한 오버헤드가 크기 때문에 이를 처리하는 서버는 고성능이 요구된다.

이런 Message Delivery형태를 저장하기 위해서 보통 2가지의 방법이 고려된다.

  1. NoSQL 과 같은 DB에 저장
  2. Message Broker 사용

첫번째보다는 두번째를 주로 많이 사용할 것이다.

Message Broker로 사용되는 것 중 가장 유명한 것이 Apache Kafka다.

이런 Message Broker를 사용함으로써,

첫번째 NoSQL과 같은 경우에서 발생할 수 있는 다수의 작은 데이터가 계속 저장이 될 때 발생할 수 있는 쓰기 성능의 한계 등을 방지하기 위해

Message Broker를 중간에 두어서 일종의 완충제 역할을 하게 한다.

이런 Message Broker들은 message를 내부에서 일정 기간 저장하여 보관하고 있다거나 내부적으로 offset을 관리하여 가져간 message(data)들을 마킹하는 등의 편의성을 제공해주기도 하며,

신뢰성 있는 처리를 위해 우리가 알고 있는

  1. at most once
  2. exactly once
  3. at least once

와 같은 일종의 guarantee를 해준다.

이런 Message Broker의 역할은 별도의 포스트로 작성하겠다.

스트리밍 형태의 데이터 수집에서는 일반적으로 명시적으로 데이터 중복을 제거하는 방식을 도입하지 않는다면 어느정도의 데이터 중복이 일어난다고 생각한다.

아주 작은 중복은 무시하기도 하며 이로 인해 큰 문제는 발생하지 않는다.

100%의 신뢰성을 위한다면 아무래도 스트리밍 형태의 데이터 수집은 어렵지 않나라는 생각을 한다.

간단한 비교

  Bulk Streaming
사용처 대용량 데이터의 분산 스토리지로의 저장 실시간성 데이터의 분산 스토리지로의 저장
요구사항 다양한 데이터 소스로부터 분산 스토리지로 저장을 해줄 ETL 서버, 워크플로우 고성능 서버, Message Broker
장점 높은 신뢰성 실시간 데이터의 처리

포스트에 대한 피드백이 있으시다면 여기로 메일 부탁드립니다. 읽어주셔서 감사합니다.