4-1. 벌크 형과 스트리밍 형의 데이터 수집
객체 스토리지와 데이터 수집
▪ 빅데이터는 확장성이 높은 '분산 스토리지(distributed storage)'에 저장
▪ 기본이 되는 것은 대량으로 파일을 저장하기 위한 '객체 스토리지(object storage)' ex) 'HDFS', 'Amazon S3'
▪ 객체 스토리지에서의 파일 읽고 쓰기는 네트워크를 거침
▪ 데이터는 여러 디스크에 복사되어 일부가 고장이 나도 데이터 손실이 발생하지 않음
▪ 데이터의 읽고 쓰기를 다수의 하드웨어가 분산하여 데이터양이 늘어나도 성능이 떨어지지 않음
▪ 객체 스토리지는 데이터양이 많을 때 우수한 반면에 소량의 데이터에서는 데이터양에 비해 통신 오버헤드가 커서 비효율적임
데이터 수집
▪ 작은 데이터는 적당히 모아서 하나의 큰 파일로 기록, 거대한 데이터는 적당한 크기의 파일로 나눠 기록
▪ 객체 스토리지에서 효율적인 파일 크기는 1메가바이트에서 1기가바이트
▪ 수집한 데이터를 가공하여 집계 효율이 좋은 분산 스토리지를 만드는 프로세스를 '데이터 수집(data ingestion)'이라고 함
벌크 형의 데이터 전송
▪ 전통적인 데이터 웨어하우스에서 사용된 것은 '벌크 형' 방식
▪ 축적된 대량의 데이터가 이미 있거나 기존의 데이터베이스에서 데이터를 추출하는 경우에 벌크 형의 데이터 전송 사용
▪ 데이터가 분산 스토리지에 저장되어 있는 것이 아니라면 데이터 전송을 위한 'ETL 서버(ETL server)' 설치
파일 사이즈의 적정화는 비교적 간단하다
▪ ETL 프로세스는 하루 또는 1시간 마다 간격으로 정기적인 실행되어 그 동안 축적된 데이터는 하나로 모임
▪ 하지만 너무 많은 양의 데이터를 한꺼번에 전송할 경우 디스크가 넘쳐 오류
▪ 많은 양의 데이터는 작은 태스크로 분해하여 한번의 태스크가 커지지 않도록 함
데이터 전송의 워크플로
▪ 데이터 전송의 신뢰성이 중요한 경우는 벌크 형 도구 사용
▪ 벌크형은 문제가 발생했을 때 여러 번 데이터 전송을 재실행이 가능, 스트리밍 형은 재실행이 어려움
▪ 벌크형 데이터 전송에서는 워크플로 관리 도구를 조합하여 정기적인 스케줄 실행 및 오류 통지
스트리밍 형의 데이터 전송
▪ 메시지 배송(message delivery): 다수의 클라이언트에서 계속해서 전송되는 작은 데이터
▪ 메시지 배송 시스템은 전송되는 데이터양에 비해 통신을 위한 오버헤드가 크기 때문에, 높은 성능의 서버가 필요
▪ 보내온 메시지를 저장하는 방법
- 작은 데이터 쓰기에 적합한 NoSQL 데이터베이스 사용, Hive와 같은 쿼리 엔진으로 연결해 데이터 읽기 가능
- '메시지 큐(message queue)'나 '메시지 브로커(meassage broker)' 등의 중계 시스템 사용, 기록된 데이터는 일정 간격으로 모아서 분산 스토리지에 저장
웹 브라우저에서의 메시지 배송
▪ 자체 개발한 웹 애플리케이션 등에서는 웹 서버 안에서 메시지를 만들어 배송, 서버상에서 데이터를 모아서 보냄
▪ 이에는 'Fluentd', 'Logstash'와 같은 서버 상주형 로그 수집 소프트웨어가 자주 사용
▪ 자바스크립트를 사용하여 직접 웹 브라우저에 직접 메시지를 보내는 방법도 있음 이는 '웹 이벤트 추적(web event tracking)' 이라고 함
모바일 앱으로부터의 메시지 배송
▪ 모바일 앱은 HTTP 프로토콜을 사용하는 클라이언트로 메시지 배송 방식이 웹 브라우저와 동일
▪ 서버를 직접 마련하지 않고 MBaaS(Mobile Backend as a Service)라는 백 엔드의 각종 서버를 이용
▪ 백 엔드 데이터 저장소에 저장한 데이터를 벌크 형 도구를 사용해서 꺼냄
▪ 또는 모바일 앱에 특화된 엑세스 해석 서비스를 통해 이벤트 데이터를 수집, 이 경우 모바일 용의 편리한 개발 키트(SDK)를 사용하여 메시지 보냄
▪ 오프라인 상태에서 발생한 이벤트는 SDK 내부에 축적되고, 온라인 상태가 되었을 때 모아서 보냄
▪ 모바일 회선은 불안정하여 메시지 재전송이 여러 번 발생, 따라서 데이터가 중복되지 않게 특정한 중복 제거의 구조가 필요
디바이스로부터의 메시지 배송
▪ MQTT(MQ Telemetry Transport): TCP/IP를 사용하여 데이터를 전송하는 프로토콜, 'Pub/Sub 형 메시지 배송(Pub/Sub message delivey)'이라는 구조를 가짐, 'Pub'은 '전달(Publish)'이고 'Sub'은 '구독(Subsciption)'
▪ MQTT는 관리자에 의해 '토픽(topic)'이 만들어짐, 송수신을 하기 위한 일종의 대화방, 토픽을 구독하면 메시지가 도착하고 토픽을 전달하면 구독 중인 모든 클라이언트에 보내짐
▪ 다음의 메시지 교환을 관리하는 서버를 'MQTT 브로커(MQTT broker)', 메시지를 수신하는 시스템을 'MQTT 구독자(MQTT subsciber)' 라고 함
▪ 네트워크에서 분리된 경우에도 재전송하는 구조가 프로토콜 수준에서 고려
메시지 배송의 공통화
▪ 메시지 배송의 방식은 데이터를 수집하는 곳에 따라 다름, 환경에 따라 다른 부분과 공통되는 부분을 분리하여 생각
▪ 메시지가 처음 생성되는 기기를 '클라이언트(client)', 메시지를 먼저 받는 서버를 '프런트 엔드(front end)'라고 함
▪ 프론트 엔드의 역할은 클라이언트와의 통신 프로토콜을 제대로 구현하는 것
▪ 프론트 엔드가 받은 메시지는 메시지 브로커로 전송, 분산 스토리지에 데이터를 저장하는 것은 메시지 브로커로부터 그 이후의 역할
[참고]
'Data Engineering > 책 리뷰' 카테고리의 다른 글
| [빅데이터를 지탱하는 기술] 4. 빅데이터의 축적 (3) (0) | 2023.09.20 |
|---|---|
| [빅데이터를 지탱하는 기술] 4. 빅데이터의 축적 (2) (0) | 2023.09.12 |
| [빅데이터를 지탱하는 기술] 3. 빅데이터의 분산 처리 (3) (0) | 2023.09.07 |
| [빅데이터를 지탱하는 기술] 3. 빅데이터의 분산 처리 (2) (0) | 2023.09.06 |
| [빅데이터를 지탱하는 기술] 3. 빅데이터의 분산 처리 (1) (0) | 2023.09.05 |