[Data Engineering] 빅데이터를 지탱하는 기술_빅데이터의 축적
빅데이터의 축적
데이터를 수집하고 분산 스토리지에 저장하기까지의 프로세스를 살펴보자
객체 스토리지와 데이터 수집
- 빅데이터는 대부분의 경우 확장성이 높은 '분산 스토리지'에 저장된다.
- 객체 스토리지는 다수의 컴퓨터를 사용하여 파일을 여러 디스크에 복사함으로써 데이터의 중복화 및 부하 분산을 실현한다. (복사하여 데이터 손실 X)
- Hadoop이라면 'HDFS', 클라우드 서비스라면 'Amazon S3' 등이 유명하다.
- 대량의 데이터에서 효율적이다.
데이터 수집
- 수집되는 데이터가 대량의 작은 파일이라면 -> 적당히 모아서 하나의 큰 파일로 만든다.
- 수집되는 데이터가 지나치게 크다면 -> 적당히 나눠서 처리한다.
-> 빅데이터는 단지 수집만 해서는 안 되고 나중에 처리하기 쉽도록 준비해둬야 한다.
벌크 형의 데이터 전송
- 과거의 축적된 대량의 데이터가 이미 있는 경우, 기존의 데이터베이스에서 데이터를 추출하고 싶을 경우 벌크 형의 데이터 전송을 한다.
- 처음부터 데이터가 저장되어 있는 것이 아니라면 데이터 전송을 위한 'ETL 서버'를 설치한다.
벌크 형 데이터 전송의 파일 사이즈
- ETL 프로세스는 정기적인 실행을 하므로 전송 파일과 횟수를 적절하게 파악하는 것이 중요하다.
- '워크플로 관리 도구'를 활용하여 태스크 실행을 쉽게 관리할 수 있다.
벌크 형 데이터 전송의 워크플로
- 데이터 전송의 신뢰성이 중요한 경우 재실행할 수 있는 벌크 형 도구를 사용한다.
+ 스트리밍 형의 데이터 전송은 재실행하기 어렵기 때문이다.
스트리밍 형의 데이터 전송
- 계속해서 전송되어 오는 작은 데이터를 취급하기 위한 데이터 전송이다.
- 다수의 클라이언트에서 계속해서 작은 데이터가 전송되는 것으로 '메시지 배송'이라고 한다.
- 메시지 저장 방법
- NoSQL 데이터 베이스 이용
- 분산 스토리지에 직접 쓰는 것이 아니라 메시지 큐, 메시지 브로커 등의 중계 시스템에 전송
스트리밍 형 데이터 전송 예시
- 데이터를 어디서 수집하느냐에 따라 전혀 다르다.
- 웹 브라우저에서의 메시지 배송 : 웹 서버 안에서 메시지를 만들어 배송
- 모바일 앱으로부터 메시지 배송 : 웹 브라우저와 방식이 동일, MBaas와 SDK 이용
- 디바이스로부터의 메시지 배송 : ex) MQTT
MQTT
- TCP/IP를 사용하여 데이터를 전송하는 프로토콜
- 일반적으로 'Pub/Sub 형 메시지 배송' 구조를 가진다.
클라이언트의 수가 많아지면 스트리밍 형의 메시지 배송의 성능, 신뢰성 둘 다 만족하기 어려워진다.
메시지 브로커
- 대량의 메시지를 안정적으로 받기 위해 성능이 높고 필요에 따라 성능을 올릴 수 있는 스토리지가 필요해 메시지 브로커를 사용한다.
- 메시지 브로커는 메시지 배송 시스템에서 데이터를 일시적으로 축적한다.
- 분산형 메시지 브로커 종류
- Apache Kafka
- Amazon Kinesis
푸쉬 형과 풀 형
- 푸쉬(push) : 송신 측의 제어로 데이터를 보내는 방식
- 풀(pull) : 수신 측의 주도로 데이터를 가져오는 방식
- 메시지 브로커에 데이터를 푸쉬 하는 것을 생산자, 풀하는 것을 소비자라고 한다.
- 메시지 브로커 원리
- -메시지 브로커는 높은 빈도로 데이터를 쓰는 것에 최적화되어 있어 푸쉬 형의 메시지 배송은 메시지 브로커에 집중시키고 일정한 빈도로 꺼낸 데이터를 분산 스토리지에 기록하여 성능 문제를 피한다.
스트림 처리(streaming processing)
- 짧은 간격으로 차례대로 데이터를 꺼내서 처리하는 것이다.
메시지 라우팅(message routing)
- 메시지 브로커에 써넣은 데이터는 복수의 다른 소비자에서 읽어 들일 수 있어 (pull) 이를 통해 메시지가 복사되어 데이터를 여러 경로로 분기시키는 것이다.
메시지 배송 방법
- 성능 문제 외에도 '신뢰성' 문제가 있다. 신뢰성이 낮은 네트워크에서는 반드시 메시지의 중복과 누락이 발생한다.
- 메시지 배송 처리 시스템 종류
- at most once
- exactly once
- at least once
at most once
- 메시지는 한 번만 전송된다. 그러나 도중에 전송에 실패해서 사라질 가능성이 있다.
- 대개는 데이터 결손을 피하고자 재전송이 이루어진다.
exactly once
- 메시지 손실이나 중복 없이 한 번만 전달한다.
- 양쪽의 통신 내용을 보장하기 위해 그 사이에 중계하는 코디네이터를 이용한다.
- 코디네이터에게 정보를 전달하고 지시를 따른다.
- 코디네이터 문제점
- 분산 시스템에 코디네이터가 항상 존재하지 않는다. (합의로 해결)
- 코디네이터의 판단만 기다리면 시간 소요가 발생한다.
at least once
- 메시지는 확실히 전달되지만 같은 것이 여러 번 전달될 가능성이 있다.
- 재전송되어도 없앨 수 있는 구조 '중복 제거'로 중복이 없는 것처럼 보이게 할 수 있다.
대부분의 메시지 배송 시스템은 'at least once'를 보장하지만, 중복 제거는 이용자에게 맡긴다.
중복 제거 방법
- 오프셋을 이용한 중복 제거 (벌크 형에서 사용)
- 고유 ID(ex UUID)에 의한 중복 제거 (스트리밍 형에서 사용)
- 종단 간의 신뢰성 (중간 경로 'at least once'로 통일)
- 스트리밍 형의 메시지 배송에서는 중간에 명시적으로 중복 제거 방식을 도입하지 않으면 항상 중복의 가능성이 있다.
스트리밍 형의 메시지 배송에는 '메시지가 도착할 때까지의 시간 지연'이 문제다. 늦게 도달하는 데이터는 집계 속도에 영향을 미친다.
프로세스 시간
- 서버가 처리하는 시간
이벤트 시간
- 클라이언트 상에서 메시지가 생성된 시간
- 데이터 분석의 대상이 되는 것은 이벤트 시간이다.
프로세스 시간에 의한 분할과 문제점
- 분산 스토리지에 데이터를 넣는 단계에서는 이벤트 시간이 아니라 프로세스 시간을 사용한다.
- 이벤트 시간을 집계하기 위해 데이터를 찾으려면 시간과 자원을 낭비하게 된다.
- 다수의 파일을 모두 검색하는 쿼리를 '풀 스캔(full scan)'이라고 부른다.
시계열 인덱스
- Cassandra와 같은 '시계열 인덱스'에 대응하는 분산 데이터베이스를 이용한다.
- 장기간에 걸친 대량의 데이터라면 분산 데이터가 효율적이지 않아 집계 효율이 높은 열 지향 스토리지를 지속적으로 만들어야 한다.
조건절 푸쉬다운
- 열 지향 스토리지는 처음에 데이터를 정렬할 수 있어 조건절 푸시 다운으로 풀 스캔을 피한다.
- 필요 최소한의 데이터만 읽도록 하는 최적화를 '조건절 푸시 다운'이라고 한다.
이벤트 시간에 의한 분할
- 테이블 파티셔닝으로 시간을 이용하여 분할한 '시계열 테이블'을 이용한다.
- 이벤트 발생 시간을 파티션의 이름에 포함한다.
데이터 마트를 이벤트 시간으로 정렬하기
- 데이터 마트만이 이벤트 시간에 의한 정렬을 한다.
- 파일이 조각나지 않고 항상 최적을 유지할 수 있다.
메시지 배송 방식을 사용하지 않고 NoSQL 데이터베이스에 의한 데이터 활용
- 데이터를 기록하고 곧바로 활용하고자 하는 경우 실시간 집계와 검색에 적합한 데이터 장소가 필요한데, 특정 용도에 최적화된 데이터 저장소를 'NoSQL 데이터베이스'라고 사용한다.
- 대량의 데이터를 집계할 수는 없어 데이터 분석을 위해서는 외부로 데이터를 추출해야 한다.
- NoSQL 데이터베이스 예
- 분산 KVS (DynamoDB)
- 와이드 칼럼 스토어 (Apache Cassandra, Apache HBase)
- 도큐먼트 스토어 (MongoDB)
- 검색 엔진 (Elasticsearch, 역 색인을 사용하는 것이 특징)
NoSQL 특성
- ACID 특성 : 트랜잭션 처리에 요구되는 4가지 성질
- 원시성(Atomicity)
- 일관성(Consistency)
- 독립성(Isolation)
- 내구성(Durability)
- CAP 정리 : AICD 특성을 만족하면서 분산 시스템을 구축하는 것은 어렵기 때문에 한계에 대해서 제창된 것
- 일관성(Consistency)
- 가용성(Availiability)
- 분단내성(Partition-tolerance)