1. 왜 빅데이터가 등장했을까
빅데이터는 단순히 “데이터가 많다”는 뜻이 아니다. 웹, SNS, IoT, 로그 시스템의 성장으로 데이터 양이 너무 커지고 너무 빠르게 들어와서 기존 방식만으로 처리하기 어려워졌다는 점이다.
그래서 한 대의 강한 서버보다, 여러 서버를 묶어 병렬로 저장하고 처리하는 방식이 중요해졌다.
클러스터를 구성하는 개별 서버를 보통 node라고 부른다.
2. 빅데이터의 3V
빅데이터를 설명할 때 가장 자주 나오는 개념이 3V다.
| Volume | 데이터 규모가 매우 큼 | TB, PB 단위 로그/센서 데이터 |
| Velocity | 데이터가 매우 빠르게 생성됨 | 클릭 로그, 실시간 거래, IoT 이벤트 |
| Variety | 데이터 형태가 다양함 | 테이블, JSON, 텍스트, 이미지, 영상 |
3. 분산 저장 방식 한눈에 보기
빅데이터 환경에서는 한 가지 저장 방식으로 모든 문제를 해결하지 않는다. 데이터 형태와 처리 목적에 따라 분산 파일 시스템, 샤딩, Key-Value 저장소, 병렬/분산 DB 같은 방식을 나눠 쓴다. 관계형 저장소가 강한 일도 있고, NoSQL 계열이 더 잘 맞는 일도 있다.
| 분산 파일 시스템 | 큰 파일을 여러 노드에 분산 저장 | 확장성, 장애 내성 | 작은 레코드 대량 처리엔 비효율적일 수 있음 |
| 샤딩 | 데이터를 키 기준으로 여러 DB에 분할 | 구현이 비교적 단순 | 라우팅/복제 책임이 커짐 |
| Key-Value 저장소 | key로 빠르게 읽고 쓰는 단순 모델 | 고확장성, 고가용성 | join/복잡한 질의 제약 |
| 병렬/분산 DB | 여러 노드에서 DB 연산 병렬 처리 | SQL 지원 강함 | 초대규모 확장성엔 한계가 있을 수 있음 |
4. Distributed File System이란
분산 파일 시스템은 데이터를 여러 머신에 나눠 저장하지만, 사용자 입장에서는 하나의 파일시스템처럼 보이게 하는 구조다.
특징
- 여러 머신에 분산 저장
- 높은 확장성
- 값싼 서버 여러 대 사용 가능
- 일부 서버가 고장 나도 복제로 버틸 수 있음
대표 예시:
- GFS (Google File System)
- HDFS (Hadoop Distributed File System)
4-1. HDFS 이해하기
HDFS는 Hadoop의 대표적인 분산 파일 시스템이다. 핵심 아이디어는 큰 파일을 block 단위로 나눠 여러 DataNode에 저장하고, 메타데이터는 NameNode가 관리하는 구조다.
사용자는 하나의 파일시스템처럼 보지만, 실제론 파일이 여러 block으로 쪼개져 분산 저장된다.
- NameNode: 파일명, block 위치 같은 메타데이터 관리
- DataNode: 실제 block 저장
- Client: NameNode에 block 위치를 묻고, 실제 데이터는 DataNode와 직접 주고받음
HDFS는 write-once-read-many 모델에 잘 맞고, 큰 파일을 저장하고 순차적으로 읽는 작업에 강하다. 반면 작은 파일이 지나치게 많거나, 잦은 랜덤 업데이트가 필요한 워크로드엔 잘 맞지 않을 수 있다. 그래서 HDFS는 일반 관계형 DB를 대체한다기보다, 대규모 파일 저장소에 더 가깝게 보는 편이 자연스럽다.
5. 복제, 일관성, CAP
분산 시스템은 일부 노드가 죽어도 계속 동작해야 하니까 보통 데이터를 복제해둔다. 이때 중요한 개념이 Availability(가용성) 과 Consistency(일관성) 이다.
예를 들어 복제본이 3개일 때 read/write 시 다수 복제본을 확인하는 majority 방식은 일관성을 확보하는 대표적인 아이디어다.
여기서 유명한 게 CAP 정리다. 네트워크 파티션이 생긴 상황에서는, 분산 시스템이 Consistency와 Availability를 동시에 완벽히 만족시키기 어렵다!! 둘 중 하나를 선택해야한다.
- 전통적인 DB 시스템: 일관성을 더 중시
- 대규모 Web 서비스: 가용성을 더 중시하는 경우 많음
6. MapReduce와 WordCount
MapReduce는 대규모 병렬 계산을 단순하게 만들기 위한 프로그래밍 모델이다. 개발자는 기본적으로 map 함수와 reduce 함수만 작성하고, 분산 실행, 장애 처리, 스케줄링, 중간 데이터 정렬 같은 복잡한 일은 시스템이 맡는다.
가장 대표적인 예제가 WordCount다. 문서에서 단어를 뽑아 (word, 1) 형태로 내보내고, 같은 단어끼리 묶은 뒤, 마지막에 합을 계산한다. 이때 shuffle 단계는 같은 key를 자동으로 모아주는 시스템 단계다.
| map | 입력에서 단어를 꺼내 (word, 1) 생성 |
| shuffle | 같은 단어끼리 자동 그룹핑 |
| reduce | 각 단어별 값을 합쳐 최종 개수 계산 |
MapReduce의 장점은 초대규모 배치 처리와 장애 내성이다. 하지만 단순한 조회나 join, aggregation 같은 작업까지 전부 MapReduce 코드로 직접 짜면 너무 장황해진다. 그래서 이후에는 더 높은 수준의 대수 연산을 지원하는 엔진이 발전하게 된다.
자세한 코드를 보고싶다면 https://hadoop.apache.org/docs/stable/hadoop-mapreduce-client/hadoop-mapreduce-client-core/MapReduceTutorial.html
7. Spark와 고수준 분산 처리
MapReduce 다음 세대 시스템들은 map/reduce 두 단계만이 아니라, join, groupBy, filter, agg 같은 더 풍부한 연산을 기본 지원한다. 그 대표적인 예가 Spark다.
Spark의 핵심 개념 중 하나가 RDD(Resilient Distributed Dataset) 다.
RDD 특징
- 데이터가 여러 노드에 partition 되어 저장됨
- 연산을 적용하면 새로운 RDD 생성
- immutable에 가까운 변환 중심 모델
- 장애 발생 시 재계산 가능
또 Spark 계열 연산은 보통 lazy evaluation 방식으로 동작해서, collect() 같은 action이 호출되기 전까지는 실행 계획만 쌓아둘 수 있다.
MapReduce vs Database
MapReduce가 강한 쪽
- 매우 큰 규모 병렬 처리
- 비정형 데이터
- 복잡한 절차형 처리
- 대규모 로그 분석
SQL/DB가 강한 쪽
- select/project/join/aggregation
- 짧고 선언적인 질의
- 구조화 데이터 분석
| 처리 방식 | map / shuffle / reduce 중심 | 더 다양한 고수준 연산 지원 |
| 표현력 | 비교적 저수준 | RDD, DataFrame, Dataset 지원 |
| 실행 특징 | 배치 중심 | lazy execution 기반 최적화 가능 |
| 사용감 | 단순하지만 장황해질 수 있음 | 분석/ETL 파이프라인 작성이 더 자연스러움 |
8. 스트림 데이터와 윈도우
빅데이터가 꼭 저장된 데이터만 뜻하는 건 아니다. 현실에서는 데이터가 끊임없이 들어오는 스트림 형태인 경우가 많다. 주식 거래, 검색 로그, IoT 센서, 네트워크 이벤트, SNS 피드 같은 데이터가 여기에 해당한다.
이런 데이터는 쌓아두고 나중에 보는 것보다 즉시 계산하고 반응하는 것이 중요할 때가 많다.
문제는 스트림이 사실상 무한하다는 점이다.
그래서 스트림 처리 시스템은 보통 window 개념으로 무한 스트림을 유한 구간으로 잘라서 계산한다.
| Tumbling | 겹치지 않는 고정 구간 | 매 1시간 집계 |
| Hopping | 겹칠 수 있는 고정 구간 | 1시간 윈도우를 20분마다 계산 |
| Sliding | 현재 이벤트를 중심으로 이동하며 계산 | 최근 N분 이벤트 기준 계산 |
| Session | 활동 간격을 기준으로 묶음 | 사용자가 일정 시간 쉬면 새 세션 시작 |
스트림 처리에서는 continuous query, 늦게 들어오는 이벤트 문제, 그리고 특정 시점 이전 데이터가 다 도착했음을 알려주는 메타 정보 같은 개념도 중요하다. 결국 핵심은 무한한 흐름을 의미 있는 구간으로 잘라서 계산하는 것이다.
9. Kafka와 Publish-Subscribe
스트림 파이프라인에서 데이터를 한 시스템에서 다른 시스템으로 흘려보내려면 producer와 consumer를 느슨하게 연결하는 구조가 필요하다.
이때 자주 쓰는 게 Publish-Subscribe 모델이다. 생산자는 topic에 데이터를 publish하고, 소비자는 관심 있는 topic을 subscribe 해서 가져간다.
즉, Kafka는 단순 메시지 큐라기보다 현대 데이터 파이프라인의 허브 역할에 가깝다. topic, partition, replication 개념을 바탕으로 생산자와 소비자를 이어주고, 스트림 처리 엔진과 저장 시스템 사이를 연결하는 중심축처럼 자주 쓰인다.
10. 핵심 요약
- 빅데이터는 Volume, Velocity, Variety 때문에 기존 DBMS 방식만으로 처리하기 어려운 데이터 환경이다.
- 이를 해결하려고 클러스터 기반 분산 저장/처리가 등장했다.
- HDFS는 큰 파일을 block 단위로 나눠 분산 저장하는 대표적인 시스템이다.
- 샤딩은 데이터를 여러 DB로 나누는 방식이지만, 애플리케이션 책임이 커질 수 있다.
- Key-Value 저장소는 고확장성을 위해 많은 DB 기능을 단순화한 NoSQL 계열이다.
- 분산 시스템에서는 복제, 가용성, 일관성, CAP 문제가 매우 중요하다.
- MapReduce는 대규모 병렬 처리를 단순한 map/reduce 모델로 추상화했다.
- 이후에는 Spark, Tez 같은 더 고수준 대수 연산 기반 엔진이 발전했다.
- RDD, DataFrame, DataSet 은 Spark에서 분산 데이터를 다루는 핵심 개념이다.
- 스트림 데이터는 저장된 데이터와 달리 실시간으로 계속 들어오는 데이터다.
- 스트림 처리에서는 window, continuous query, pub-sub, Kafka 같은 개념이 중요하다.
11. 전체 흐름
- 데이터가 너무 많아지고 빨라짐, 한 대 서버와 기존 DBMS만으로는 부족
- 분산 저장(HDFS, NoSQL)이 등장
- 분산 처리(MapReduce) 등장
- 더 높은 수준의 실행 엔진(Spark)으로 발전
- 이제는 실시간 스트림 처리와 Kafka 같은 데이터 흐름 플랫폼까지 중요해졌다.
이미지 출처 모음
- HDFS 구조도: Apache Hadoop HDFS Architecture Guide
- WordCount / MapReduce 흐름: Apache Hadoop MapReduce Tutorial
- 스트림 윈도우 종류: Azure Stream Analytics / Apache Flink 문서