[빅데이터를 지탱하는 기술] 4장 빅데이터의 축적
Chapter 4
빅데이터의 축적
📑 목차
1. 객체 스토리지와 데이터 수집
2. 벌크 형 vs 스트리밍 형 데이터 전송
3. 메시지 브로커와 메시지 라우팅
4. 메시지 배송의 신뢰성과 중복 제거
5. 시계열 데이터의 최적화
6. NoSQL 데이터베이스의 종류와 활용
7. 핵심 요약 정리
01
객체 스토리지와 데이터 수집
빅데이터는 대부분 객체 스토리지(Hadoop→HDFS, AWS→S3)에 저장됩니다. 데이터는 여러 디스크에 복제되어 하드웨어 고장에도 손실이 없고, 데이터양이 늘어도 성능이 떨어지지 않도록 설계되어 있습니다.
💡 비유로 이해하기
객체 스토리지는 대형 물류 창고입니다. 대량 화물엔 탁월하지만, 편지 한 장 보관하려고 창고 문을 여닫는 건 비효율적(네트워크 오버헤드)이죠.
⚠️ 파일 크기의 황금 구간: 1MB ~ 1GB
너무 작으면 → 대량의 작은 파일이 쌓여 성능 저하 / 너무 크면 → 전송 시간·오류 증가 (1TB = 100Mbps로 24시간!)
해결 → 작은 데이터는 모아서 하나로, 큰 데이터는 적당히 나눠서 저장
02
벌크 형 vs 스트리밍 형 데이터 전송
📦 벌크(Bulk) 형
✅ DB·파일 서버에서 정기적으로 추출
✅ 문제 시 재실행 가능 (최대 장점)
✅ 워크플로 관리 도구와 궁합 최고
✅ 과금·마스터 데이터 등 신뢰성 중시
🌊 스트리밍(Streaming) 형
✅ 다수 클라이언트에서 실시간 전송
✅ 웹·모바일·IoT 수집에 필수
⚠️ 재실행 어려움, 중복 가능성
⚠️ 메시지 브로커 등 중계 시스템 필요
💡 비유로 이해하기
벌크 형은 빨래를 모아서 세탁기 한 번에 돌리는 것, 스트리밍 형은 옷이 더러워질 때마다 바로 손빨래하는 것입니다.
스트리밍 데이터의 3가지 출처
🌐
웹 브라우저
Fluentd · Logstash
웹 이벤트 추적 (JS 태그)
📱
모바일 앱
MBaaS · SDK
오프라인→온라인 시 전송
🔌
IoT 디바이스
MQTT 프로토콜
Pub/Sub · 토픽 기반
03
메시지 브로커와 메시지 라우팅
외부 메시지 양은 제어 불가능합니다. 급증하면 쓰기 한계→재전송→부하 증가의 악순환. 이를 막기 위한 완충 장치가 메시지 브로커(Apache Kafka, Amazon Kinesis)입니다.
💡 비유로 이해하기
메시지 브로커는 편의점 택배 접수대입니다. 고객(생산자)이 폭주해도 접수대가 완충하고, 택배 기사(소비자)는 자기 페이스로 가져갑니다.
↘ 📥 소비자 B — 메시지 라우팅으로 동일 데이터를 여러 경로로 분기 가능!
04
메시지 배송의 신뢰성과 중복 제거
⚡
At Most Once
최대 1번 전송
누락 가능, 중복 없음
✅
Exactly Once
정확히 1번
코디네이터 필수, 현실적으로 어려움
🔄
At Least Once ⭐
최소 1번 전달
확실히 도착, 중복 가능
📌 Kafka, Flume, Logstash, Fluentd 모두 At Least Once
하지만 중복 제거는 사용자 책임입니다. TCP처럼 자동으로 제거해주지 않습니다.
벌크 형
📂 오프셋 기반 중복 제거
파일명+시작 위치를 부착. 같은 위치를 덮어쓸 뿐. 고정 데이터양에 적합
스트리밍 형
🔑 UUID 기반 중복 제거
모든 메시지에 고유 ID 부여. 최근 ID만 기억하고 동일 ID는 파기. NoSQL(Cassandra) 덮어쓰기 또는 SQL DISTINCT로 처리
🟢 대부분의 빅데이터
작은 중복은 무시. 멱등한 조작 설계로 "중복이 있어도 문제없는" 시스템 구축
🔴 신뢰성 필수 데이터
과금·병원 등은 스트리밍 피하고, 트랜잭션 DB + 벌크 형 전송으로 완벽 보장
05
시계열 데이터의 최적화
스트리밍에서는 메시지가 늦게 도착하는 문제가 핵심입니다. 클라이언트에서 생성된 시간(이벤트 시간)과 서버 처리 시간(프로세스 시간)은 다를 수 있습니다.
💡 비유로 이해하기
이벤트 시간은 편지가 쓰여진 날짜, 프로세스 시간은 편지가 우체국에 도착한 날짜입니다. "1월 1일에 쓴 편지"를 찾으려면 이후 도착한 모든 편지를 뒤져야 하는 풀 스캔 문제가 생깁니다.
3가지 최적화 전략
전략 1
시계열 인덱스
Cassandra 등에서 이벤트 시간 인덱스. 짧은 범위 집계에 빠름. 장기 분석엔 비효율
전략 2
조건절 푸시다운
열 지향 스토리지 변환 시 이벤트 시간으로 정렬. 컬럼 통계로 필요한 파일만 읽기
전략 3 (권장)
데이터 마트에서만 정렬
수집 시에는 프로세스 시간으로 저장. 마트 구축 시 이벤트 시간 정렬. 파일 조각화 방지!
📌 가장 좋은 방법
데이터 수집 단계에서는 이벤트 시간을 따지지 않고 프로세스 시간으로만 저장합니다. 그리고 데이터 마트를 만드는 단계에서 이벤트 시간 정렬을 하면, 파일이 조각나지 않고 항상 최적의 데이터 마트를 유지할 수 있습니다.
06
NoSQL 데이터베이스의 종류와 활용
객체 스토리지는 파일 교체가 어렵고, 열 지향 스토리지 작성에 시간이 걸립니다. 데이터를 기록하고 곧바로 활용하려면, 특정 용도에 최적화된 NoSQL 데이터베이스가 필요합니다.
🔑
분산 KVS
Key-Value 쌍으로 저장. 초당 수만 번 읽기/쓰기
예: Amazon DynamoDB — P2P 분산, 요청 수에 따라 자동 확장. DynamoDB Streams로 실시간 이벤트 전송
📊
와이드 컬럼 스토어
2개 이상의 키에 데이터 저장. 수억 컬럼 가능
예: Apache Cassandra — CQL로 SQL 감각 조작. 복합 키로 사용자별 타임라인 구축
📄
도큐먼트 스토어
JSON처럼 중첩된 스키마리스 데이터를 그대로 저장
예: MongoDB — 간편하고 유연. 외부 참조 데이터·로그 저장에 적합
🔍
검색 엔진
역 색인으로 키워드 검색 고속화. 실시간 집계에 강점
예: Elasticsearch (ELK 스택), Splunk — 이상 감지·보안·로그 분석에 최적
⚠️ NoSQL의 공통 한계
NoSQL DB는 읽기/쓰기는 빠르지만, 대량 데이터 집계 기능이 없는 경우가 많습니다. 데이터 분석을 위해서는 Hive·Presto·Spark 등 쿼리 엔진과 연결하여 데이터를 추출해야 합니다.
SUMMARY
핵심 요약 정리 ✨
빅데이터는 객체 스토리지에 저장. 파일 크기는 1MB~1GB가 최적입니다.
벌크 형은 재실행 가능하고 안정적, 스트리밍 형은 실시간이지만 중복 가능성이 있습니다.
메시지 브로커로 Push→Pull 변환하고, 메시지 라우팅으로 여러 경로에 분기합니다.
At Least Once가 표준이며, 중복은 UUID/SQL DISTINCT로 말단에서 제거합니다.
시계열 최적화는 수집 시 프로세스 시간으로 저장, 데이터 마트에서만 이벤트 시간 정렬이 최선입니다.
NoSQL DB(KVS·와이드컬럼·도큐먼트·검색엔진)는 빠르지만 집계엔 쿼리 엔진 연결이 필수입니다.