4장 빅데이터의 축적

데이터를 수집하고 분산 스토리지에 저장하기까지의 프로세스를 살펴본다.

4-1 벌크 형과 스트리밍 형의 데이터 수집

객체 스토리지와 데이터 수집

• 대부분의 경우 빅데이터는 확장성이 높은 분산 스토리지(distributed storage)에 저장된다.

• 분산형의 DB가 이용되는 경우도 있지만, 기본은 객체 스토리지(object storage)이다.
  ex) 하둡 -> HDFS, 아마존 -> Amazon S3

객체 스토리지에 파일 읽고 쓰기는 네트워크를 거쳐서 실행한다. (다수의 물리적인 장비가 있고... HW 고장이 나도 데이터 손실이 없으며... 소량의 데이터는 네트워크 오버헤드...)

데이터 수집 : 수집한 데이터를 가공하여 집계 효율이 좋은 분산 스토리지를 만드는 일련의 프로세스를 말한다. 여기에는 데이터 수집부터 구조화 데이터의 작성, 분산 스토리지에 대한 장기적인 저장 등이 포함된다.

• 빅데이터에서는 시계열 데이터를 자주 다룬다. 이를 수시로 객체 스토리지에 기록하면 대량의 작은 파일이 생성돼서 시간이 지남에 따라 성능을 저하시키는 요인이 된다. => 이들을 큰 파일로 만들어서 효율을 높이자.

• 또, 지나치게 큰 파일은 적당히 나눠져서 문제 발생을 예방하자.

벌크 형의 데이터 전송

전통적인 DWH에서 사용된 것은 주로 벌크 형 방식으로 DB나 파일 서버 또는 웹 서비스 등에서 각각의 방식(SQL, API 등)으로 정리해 데이터를 추출한다.

빅데이터를 다루는 경우에도 과거에 축적된 대량의 데이터가 이미 있는 경우나 기존의 데이터베이스에서 데이터를 추출하고 싶을 경우에 벌크 형의 데이터를 전송한다.

원래 데이터가 처음부터 분산 스토리지에 저장되어 있지 않다면, 데이터 전송을 위한 ETL 서버가 필요하다.

워크플로 관리 도구를 통해 주기적으로 ETL 프로세스가 실행되도록 해서 너무 많은 데이터가 한 번에 전송되는 것을 예방하자.

벌크 형의 장점으로는 문제 발생시 여러 번 재실행할 수가 있다는 것이다.

벌크 형의 데이터 전송은 워크플로 관리 도구와의 궁합이 뛰어나다.

스트리밍 형의 데이터 전송

대다수 데이터는 통신 장비 및 SW 의해 생성되고, 네트워크를 바로 거쳐서 전송된다. 이러한 데이터를 벌크 형 도구로 모으는 것은 불가능하므로, 스트리밍 형의 데이터 전송이 필요하다.

보내온 메시지를 정장하는 데에는 몇 가지 방법이 있다.

1. 작은 데이터를 쓰기에 적합한 NoSQL DB 사용
2. 분산 스토리지에 쓰는 것이 아닌 메시지 큐(message queue), 메시지 브로커(message broker) 등의 중계 시스템에 전송

웹 브라우저에서의 메시지 배송

Fluentd, Logstash : 서버 상주형 로그 수집 SW, 웹 서버 안에서 메시지를 만들어 배송할 때, 전송 효율을 높이기 위해 서버상에서 일단 데이터를 축적해 놓고 나중에 모아서 보내는 경우 사용된다.

웹 이벤트 추적(web event tracking) : JS를 사용하여 웹 브라우저에서 직접 메시지를 보내는 경우를 말한다.

모바일 앱으로부터의 메시지 배송

모바일 앱에서는 서버를 직접 마련하는 것이 아니라 MBaaS(Mobile Backend as a Service)라는 백엔드의 각종 서비스를 이용할 수 있다. 이 경우 백엔드 데이터 저장소에 저장한 데이터를 벌크형 도구를 사용해서 꺼낸다.

또는, 모바일 앱에 특화된 엑세스 해석 서비스를 통해 이벤트 데이터를 수집한다. 이 때는 SDK를 사용하여 메시지를 보낸다.

디바이스로부터의 메시지 배송

IoT 등의 디바이스로부터 메시지 전달은 (책이 쓰여진 시점에는) 규격이 확립되지 않았다. 하지만 하나의 예시로 MQTT(MQ Telemetry Transport)는 TCP/IP를 사용하여 데이터를 전송하는 프로토콜의 하나이다.

일반적으로 Pub/Sub(publish & subscription)이 쓰이며 이는 채팅 시스템이나 메시징 앱 또는 푸시 알림 등의 시스템에서 자주 사용되는 기술이다. 자세한 설명은 (p.141) 참고

4-2 [성능x신뢰성] 메시지 배송의 트레이드 오프

스트리밍 형의 메시지 배송의 '성능'과 '신뢰성'을 둘 다 만족하기는 어렵다.

메시지 브로커

메시지 브로커 : 메시지 배송 시스템에 과부화(디스크 용량 초과 등)를 막기 위해 데이터를 일시적으로 축적하는 중산층 스토리지.

• 푸쉬 형과 풀 형

  송신 측의 제어로 데이터를 보내는 방식을 푸시(push)형이라고 하고,

  수신 측의 주도로 데이터를 가져온느 것을 풀(pull)형이라고 한다.

  메시지 브로커에 데이터를 넣는(push) 것을 생산자, 꺼내오는(pull) 소비자라고 한다.

메시지 브로커는 데이터의 쓰기 속도를 조정하기 위한 완충 부분이며, 푸쉬 형에서 풀형으로 메시지 배송의 타이밍을 변환한다.

• 메시지 라우팅

  스트림 처리(stream process) : 프런트엔드에서 메시지 브로커에 데이터르 푸쉬하도록 하고 그것을 '소비자'에서 모아서 가져온다. 이를 초 단위로 처리하는 등 짧은 간격으로 차례대로 데이터를 꺼내서 처리하는 것이 스트림 처리이다.

  메시지 라우팅(message routing) : 메시지 브로커에 써넣은 데이터는 복수의 다른 소비자에서 읽어 들일 수 있고, 이를 통해 메시지가 복사되어 데이터를 여러 경로로 분기시킬 수 있다.

메시지 배송을 확실하게 실시하는 것은 어렵다.

신뢰성(reliability) 또한 중요한 문제겠다.

네트워크에서 메시지의 중복이나 누락을 어떻게 처리할지는 시스템마다 다르고 다음 중 하나를 보장하도록 설계된다.

• at most once : 메시지는 한 번만 전송, 전송 실패나 누락 가능성 있음.
• exactly once : 손실이나 중복 없이 한 번만 전달.
• at least once : 메시지는 확실히 전달. 단, 중복의 가능성은 있음.

메시지 배송에 사용되는 오픈 소스 SW인 Apache Flume, Apache Kafka, Logstash, Fluentd는 at least once를 보장한다.

중복 제거는 높은 비용의 오퍼레이션

메시지의 중복을 제거하려면 같은 메시지를 받았는지를 시간 정보를 통해 판정해야 한다.

TCP의 경우 메시지의 시퀸스 번호를 붙이지만, 분산 시스템은 그렇지 않다.

모든 메시지에 일련 번호를 넣으려면 성능이 안 좋아질테고 이에 대한 대안이 몇 가지 있다.

• 오프셋을 이용한 중복 제거
  전송해야 할 데이터에 파일명 등의 이름을 부여해 그것을 작은 메시지에 실어서 배송하는 방법. 데이터양이 고정 되어있을 잘 작동해서 벌크형에서는 많이 채용하지만 스트리밍형에서는 그렇지 않다.

• 고유 ID에 의한 중복 제거
  모든 메시지에 UUID(Universally Unique IDentifier)등의 고유 ID 지정하는 방법이다. 스트리밍 형의 메시지 배송에서 자주 사용된다.

• 종단간(End to End)의 신뢰성
  신뢰성이 높은 메시지 배송을 실현하려면 중간 경롤를 모두 at least once로 통일한 후 클라이언트 상에서 모든 메시지에 고유 ID를 포함하도록 하고 경로의 말단에서 중복 제거를 실행해야 한다.

• 고유 ID를 사용한 중복 제거의 방법
  고유 ID를 사용한 중복 제거는 여러가지가 있는데 책에서는 대표적인 2가지를 설명한다.

  하나는 분산 스토리지로 NoSQL DB를 이용하는 것이다. ex) Cassnadra, Elasticsearch 등

  다른 하나는 SQL로 중복을 제거하는 것이다. 보내온 데이터를 일단 그대로 스토리지에 저장하고 나중에 읽어 들이는 단계에서 중복을 제거하는 것이다. (양이 많고 성능이 중요하기 떄문에 Hive 등 배치형 쿼리 엔진을 사용한다.)

데이터 수집의 파이프라인

이런 일련의 프로세스를 거친 다음, 마지막으로 데이터를 구조화해서 열 지향 스토리지로 변환함으로써, 마침내 장기간의 데이터 분석에 적합한 스토리지가 완성된다. 이를 데이터 수집의 파이프라인이라고 한다.

중복을 고려한 시스템 설계
일반적으로 스트리밍 형의 메시지 배송에서는 중간에 명시적으로 중복 제거 바시긍ㄹ 도입하지 않는 한 항상 중복의 가능성이 있다고 보는것이 좋다.

빅데이터를 다루는 시스템은 매우 높은 성능을 요구하기 때문에 아주 작은 중복은 무시하는 경향이 있다.

실제로 (모바일 회선 처럼 불안정한 통신 경로는 제외 하더라도) 데이터 센터와 같은 안정된 회선은 99% 이상의 신뢰성을 확보할 수 있다. 이런 경우에는 '중복이 있어도 문제가 되지 않는' 시스템을 설계할 것을 추천한다.

신뢰성이 중시되는 경우에는 스트리밍 형의 메시지 배송을 피하는 것이 가장 좋다.
ex) 과금 데이터, 병원, 공항 데이터 등
이 때는 트랜잭션 처리를 지원하는 DB 애플리케이션이 직접 기록, 벌크 형의 데이터를 전송함 으로써 중복과 결손 둘 다 피해야 한다.

4-3 시계열 데이터의 최적화

4-4 비구조화 데이터의 분산 스토리지

요약