빅데이터 플랫폼과 분석 아키텍처 | SW 전공

1. 빅데이터의 의미

빅데이터는 단순히 데이터 용량이 큰 상태만을 뜻하지 않는다. 기존 방식만으로 수집·저장·처리·분석하기 어려운 규모·속도·다양성을 가진 데이터와 이를 활용하는 기술·운영체계를 함께 가리킨다.

대표 특성:

특성	의미	예시
Volume	데이터 규모	거래·센서·로그 수십억 건
Velocity	생성·처리 속도	실시간 이상탐지
Variety	형식의 다양성	테이블·JSON·문서·이미지
Veracity	신뢰성과 품질	오류·중복·편향
Value	업무 가치	비용절감·예측·자동화

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

다양한 원천
DB·로그·파일·센서·API
         ↓
수집·저장·처리·분석·활용
         ↓
    업무 가치 창출

V의 개수는 자료마다 다르게 제시될 수 있으므로, 핵심 의미를 이해하는 것이 중요하다.

2. 데이터 플랫폼의 전체 구조

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

[원천 시스템]
업무 DB · 파일 · 로그 · API · IoT
         │
         ▼
[수집 계층]
Batch · CDC · Message Broker · Stream
         │
         ▼
[저장 계층]
Object Storage · HDFS · DW · Data Lake
         │
         ▼
[처리 계층]
ETL/ELT · Spark · SQL Engine · Stream Processing
         │
         ▼
[제공 계층]
BI · 통계 · ML · API · 데이터 제품
         │
         ▼
[공통 관리]
메타데이터 · 품질 · 계보 · 권한 · 모니터링 · 비용

플랫폼은 특정 제품 하나가 아니라 여러 계층과 관리 기능의 결합이다.

3. 수집 방식

배치 수집

일정 시간 동안 데이터를 모아 주기적으로 처리한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

업무 DB → 매일 01:00 추출 → 분석 저장소

장점은 단순성과 대량 처리 효율이며, 단점은 데이터 최신성이 낮을 수 있다는 점이다.

CDC

데이터베이스의 변경 로그 등을 이용해 삽입·수정·삭제 변화만 전달한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

DB 변경로그
   ├─ INSERT
   ├─ UPDATE
   └─ DELETE
         ↓
   변경 이벤트 스트림

원본 테이블을 매번 전체 스캔하지 않고 변경을 전달할 수 있지만 스키마 변경, 순서, 재처리를 관리해야 한다.

메시지·스트림 수집

이벤트가 발생할 때 지속적으로 전달한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

Producer → Broker → Consumer A
                   └→ Consumer B

실시간 처리에 유리하지만 중복·순서·지연·재처리·백프레셔를 고려해야 한다.

4. Hadoop과 HDFS

Hadoop은 대용량 데이터를 여러 서버에 분산 저장·처리하기 위한 오픈소스 생태계의 이름이다. 특정 영문 문장의 약어가 아니다.

대표 구성 개념:

HDFS: 분산 파일시스템
MapReduce: 병렬 배치 처리 모델
YARN: 자원·작업 관리
관련 저장·수집·질의 도구 생태계

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

큰 파일
  ↓ 블록 분할
Block A → DataNode 1, 3
Block B → DataNode 2, 3
Block C → DataNode 1, 2
         ↑
   메타데이터 관리

HDFS는 대용량 순차 읽기·쓰기에 적합하도록 설계되었으며, 작은 파일이 지나치게 많거나 빈번한 임의 수정에는 비효율적일 수 있다.

5. MapReduce

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

입력 분할
   ↓
Map: 각 조각 병렬 변환
   ↓
Shuffle·Sort: 같은 키끼리 모음
   ↓
Reduce: 키별 집계
   ↓
결과 저장

단어 수 예:

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

입력: "api log api"
Map: (api,1), (log,1), (api,1)
Shuffle: api→[1,1], log→[1]
Reduce: api=2, log=1

디스크 중심의 여러 단계 배치 처리라 반복 분석의 지연이 커질 수 있다.

6. Spark

Spark는 분산 데이터 처리 엔진으로 DAG 기반 실행계획과 메모리 활용을 통해 배치·SQL·스트림·머신러닝 작업을 지원한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

Read
  ↓
Filter
  ↓
Join
  ↓
GroupBy
  ↓
Write

변환을 선언한 뒤 실제 결과가 필요한 시점에 실행하는 지연 평가를 사용할 수 있다. “Spark는 모든 데이터를 항상 메모리에만 저장한다”는 설명은 부정확하다. 데이터 규모와 작업에 따라 메모리·디스크를 함께 사용한다.

7. 배치 처리와 스트림 처리

기준	배치	스트림
입력	일정량 누적	계속 도착
결과	분·시간·일 단위	실시간·근실시간
주요 목표	처리량·재처리	낮은 지연·상태 관리
예	일일 정산	부정거래 경보

스트림 처리에서는 다음을 구분한다.

이벤트 시간: 사건이 실제 발생한 시간
처리 시간: 시스템이 사건을 처리한 시간
윈도: 일정 시간 범위의 이벤트 묶음
Watermark: 늦은 이벤트를 어디까지 기다릴지 판단하는 기준
상태: 이전 이벤트를 기억해 계산하는 정보

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

10:00 사건 → 네트워크 지연 → 10:03 처리
이벤트 시간 10:00
처리 시간 10:03

8. ETL과 ELT

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

ETL
추출 → 변환 → 적재

ELT
추출 → 적재 → 저장소 내부에서 변환

ETL: 저장 전에 정제·변환
ELT: 확장 가능한 저장소에 먼저 적재하고 필요에 따라 변환

선택 기준은 데이터 규모, 저장소 성능, 보안, 품질, 재처리, 비용이다.

9. 데이터웨어하우스와 데이터마트

데이터웨어하우스는 여러 원천의 데이터를 분석 목적으로 통합·정리해 장기간 축적하는 저장체계이다.

전통적으로 강조되는 성질:

주제지향성
통합성
시계열성
비휘발성

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

고객 DB ─┐
주문 DB ─┼─► 정제·통합 ─► Enterprise DW
상담 DB ─┘                    ├─ 영업 Data Mart
                             └─ 재무 Data Mart

데이터마트는 특정 부서·주제에 초점을 둔 비교적 작은 분석 저장소이다.

10. OLTP와 OLAP

기준	OLTP	OLAP
목적	일상 거래 처리	분석·의사결정
쿼리	짧은 조회·변경	대량 집계·다차원 분석
데이터	현재·상세	장기간·통합·요약
설계	정규화 중심	스타·스노플레이크 등 분석 중심
예	주문 등록	월별 지역 매출 분석

운영 DB에서 무거운 분석을 직접 수행하면 거래 처리 성능에 영향을 줄 수 있다.

11. Data Lake와 Lakehouse

Data Lake

원시·반정형·비정형 데이터를 확장 가능한 저장소에 보관한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

Raw Zone → Cleansed Zone → Curated Zone

장점은 유연성과 다양한 데이터 보관이다. 메타데이터·품질·소유권이 부족하면 찾기 어렵고 신뢰할 수 없는 “데이터 늪”이 될 수 있다.

Lakehouse

Data Lake의 저비용·유연한 저장과 Data Warehouse의 테이블 관리·트랜잭션·질의 기능을 결합하려는 구조이다.

이름보다 다음 기능을 확인한다.

스키마 관리
트랜잭션·동시성
버전·시점 조회
메타데이터
품질·권한
BI·ML의 공동 사용

12. 오케스트레이션

데이터 파이프라인 작업의 순서·의존성·재시도·스케줄을 관리한다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

원천 수집
   ↓ 성공
품질검사
   ↓ 성공
변환
   ↓ 성공
집계·제공
   ↓
완료 알림

실패 시 무조건 처음부터 재실행하기보다 체크포인트, 멱등성, 부분 재처리를 설계한다.

13. 플랫폼 운영 지표

데이터 최신성
처리 지연
성공·실패 건수
입력·출력 건수 대사
데이터 품질 점수
스트림 적체
스토리지 증가율
쿼리 비용·시간
자원 사용량
계보·스키마 변경
사용자·데이터 제품 활용률

참고 기준

Apache Hadoop 공식 문서
Apache Spark 공식 문서

14. HDFS 용량과 블록 계산

복제계수 3인 HDFS에 원본 12TB를 저장하면 단순 데이터 블록 사용량은 약 36TB이다. 128MB 블록에서 300MB 파일은 마지막 블록이 꽉 차지 않더라도 3개 블록으로 나뉜다. 실제 운영에는 메타데이터·임시파일·여유공간도 필요하다.

작은 파일이 지나치게 많으면 NameNode 메타데이터와 작업 스케줄링 부담이 커진다. 단순히 블록 크기를 줄여 해결하기보다 파일 병합·컨테이너 포맷·적절한 파티셔닝을 검토한다.

15. Spark DAG·stage·shuffle

Spark의 transformation은 지연 평가되고 action이 결과를 요구할 때 실행계획이 동작한다. Narrow dependency는 부모 파티션 하나가 제한된 자식 파티션에 기여하지만, groupByKey, reduceByKey, 대규모 join 같은 wide dependency는 여러 파티션 간 shuffle을 만들 수 있다.

CODE코드 영역 안에서 좌우로 이동할 수 있습니다.

read → filter → map          (좁은 변환 체인)
                 ↓
             reduceByKey     (shuffle 경계)
                 ↓
               action

데이터 skew가 있으면 특정 key의 파티션만 오래 걸린다. 사전 집계, key salting, 파티션 전략, 작은 테이블 broadcast join 등을 검토한다.

16. Kafka·스트림 처리 상태

파티션 내부 순서는 보장되지만 서로 다른 파티션 사이의 전역 순서는 보장되지 않는다. 한 consumer group에서 한 파티션은 한 시점에 하나의 consumer가 처리하므로 consumer 수가 파티션 수보다 많아도 초과 consumer는 유휴일 수 있다.

Offset을 처리 전에 커밋하면 장애 시 손실 위험이, 처리 후 커밋하면 재처리·중복 위험이 있다. 정확히 한 번이라는 표현은 source, state, sink, 외부 부작용까지 하나의 일관된 프로토콜로 묶었는지 확인해야 한다.

17. 이벤트 시간·워터마크·윈도

Event time: 사건이 실제 발생한 시각
Processing time: 시스템이 처리한 시각
Watermark: 늦게 도착한 이벤트를 어느 시점까지 기다릴지 정하는 진행 기준

워터마크 10분은 모든 이벤트가 10분 안에 온다는 보장이 아니라, 그보다 늦은 데이터의 처리 정책을 정하는 기준이다. 늦은 데이터는 폐기·별도 저장·결과 갱신 등 정책이 필요하다.

18. 분석 저장계층과 데이터 계약

Lakehouse는 객체 저장소의 개방성과 분석 테이블의 트랜잭션·스키마 관리 기능을 결합하려는 구조다. 원천·정제·서빙 영역을 분리할 수 있지만 명칭 자체가 품질을 보장하지는 않는다.

데이터 계약에는 소유자, 스키마, 의미, 품질 SLO, 호환성, 변경 통지, 폐기 일정이 포함될 수 있다. 컬럼 삭제·타입 축소는 소비자 호환성을 깨뜨릴 가능성이 크다.

확인 문제

원본 12TB, 복제계수 3의 단순 HDFS 데이터 사용량은?
300MB 파일을 128MB 블록으로 나누면 블록 수는?
Kafka에서 순서가 보장되는 기본 범위는?
Spark에서 wide dependency가 만드는 대표 비용은?
사건 발생 시각과 시스템 처리 시각의 구분은?