데이터 적재와 저장

데이터 적재 방식

방식	특징	기술
벌크(배치) 적재	일정 주기로 대량 전송, 처리량 우선	ETL, Sqoop, 파일 전송
실시간(스트리밍) 적재	발생 즉시 전송, 지연 시간 우선	Kafka, Flume, CEP

데이터 웨어하우스 (DW)

전사 의사결정을 위해 주제별로 통합·보관하는 저장소입니다. 4대 특성은 다음과 같습니다.

특성	뜻
주제 지향성	업무 프로세스가 아니라 분석 주제(고객·상품 등) 중심으로 구성
통합성	여러 원천의 코드·형식을 하나로 통일
시계열성	시점별 이력을 보관해 시간에 따른 변화를 볼 수 있음
비휘발성	한 번 적재되면 갱신·삭제되지 않고 조회만 됨

DW 모델링은 팩트와 차원 테이블로 하며, 차원을 정규화하지 않은 스타 스키마와 정규화한 스노우플레이크 스키마가 있습니다. 스타 스키마는 조인이 적어 조회가 빠르고, 스노우플레이크는 중복이 적은 대신 조인이 늘어납니다.

DW · DM · ODS · 데이터 레이크

구분	범위	데이터 상태	목적
ODS	운영계 통합	최신 상세 데이터, 갱신됨	운영 보고·실시간 조회, DW 적재 전 중간 단계
DW	전사	정제·통합된 이력 데이터	전사 의사결정
DM	부서·주제 단위	DW의 부분집합	특정 부서·업무 분석
데이터 레이크	전사	원본(raw) 그대로, 정형·비정형 모두	목적을 정하지 않은 탐색·머신러닝

함정 정리

• ODS는 갱신되고 DW는 갱신되지 않습니다(비휘발성). ODS를 "이력 보관용"으로 서술한 선택지는 오답입니다.
• DM은 DW의 부분집합입니다. 반대로 "DM을 모아 DW를 만든다"는 서술도 접근법에 따라 존재하지만, 시험은 DW → DM 방향을 정답으로 봅니다.
• DW는 저장할 때 스키마를 정하는 schema-on-write, 데이터 레이크는 읽을 때 스키마를 적용하는 schema-on-read 입니다.
• 관리 없이 방치된 데이터 레이크는 데이터 스왐프(swamp) 가 됩니다.

HDFS

구성	역할
네임노드(마스터)	파일 메타데이터·블록 위치 관리. FsImage + EditLog 보관
보조 네임노드	EditLog를 FsImage에 병합(체크포인트). 네임노드의 예비 서버가 아님
데이터노드(슬레이브)	실제 블록 저장, 네임노드에 하트비트·블록 리포트 전송

• 파일을 블록 단위로 쪼개 저장(하둡 2.0 기준 기본 128MB)
• 각 블록을 기본 3개로 복제해 장애에 대비
• 한 번 쓰고 여러 번 읽는(WORM) 모델, 임의 수정이 아니라 스트리밍 접근에 최적화

보조 네임노드를 "네임노드가 죽으면 대신하는 노드"로 설명한 선택지는 오답입니다. 그 역할은 하둡 2.0의 고가용성(HA) 구성에서 스탠바이 네임노드가 담당합니다.

HDFS는 작은 파일이 매우 많은 경우에 불리합니다(네임노드 메모리 부담). "소용량 파일 다수 처리에 적합"은 오답입니다.

분산 파일 시스템 비교

시스템	구조
GFS	마스터 + 청크 서버 + 클라이언트. 청크 단위(64MB) 저장
HDFS	네임노드 + 데이터노드. GFS를 오픈소스로 구현
러스터(Lustre)	클라이언트 파일 시스템 + 메타데이터 서버(MDS) + 객체 저장 서버(OSS)

NoSQL

관계형 DB의 스키마·조인 제약을 버리고 확장성과 가용성을 취한 저장 기술입니다.

특징	내용
Schema-less	사전 스키마 정의 없이 저장
수평 확장(Scale-out)	서버를 늘려 용량·성능 확장
BASE	Basically Available · Soft state · Eventually consistent

관계형 DB의 ACID(원자성·일관성·격리성·지속성)와 대비됩니다. NoSQL은 즉시 일관성을 포기하고 최종적 일관성을 택합니다.

유형	구조	예
Key-Value	키에 값 하나를 대응	Redis, DynamoDB, Riak
컬럼 패밀리(Column)	행 키 + 컬럼 패밀리, 컬럼 단위 저장	HBase, Cassandra
도큐먼트(Document)	JSON·BSON 문서 단위, 문서마다 구조가 달라도 됨	MongoDB, CouchDB
그래프(Graph)	노드와 관계(엣지)로 연결 구조 표현	Neo4j

관계 탐색(SNS 친구 관계, 추천 경로)이 필요한 문제는 그래프 DB, 구조가 자주 바뀌는 반정형 문서는 도큐먼트 DB가 답입니다.

CAP 정리

분산 시스템은 세 속성 중 두 개까지만 동시에 만족할 수 있습니다.

속성	뜻
Consistency(일관성)	모든 노드가 같은 시점에 같은 데이터를 보여줌
Availability(가용성)	일부 노드가 죽어도 요청에 응답
Partition tolerance(분단 허용성)	네트워크 분단이 생겨도 시스템이 동작

선택	성격	예
CA	분단을 허용하지 않음 — 단일 클러스터	관계형 DBMS
CP	분단 시 일관성을 지키고 응답을 포기	HBase, MongoDB, Redis
AP	분단 시 응답을 지키고 일관성을 나중에 맞춤	Cassandra, CouchDB, DynamoDB, Riak

"세 가지를 모두 만족한다"는 선택지는 항상 오답입니다. 그리고 Cassandra는 AP, HBase는 CP 라는 짝은 그대로 출제됩니다.

저장 시스템 구성 방식

방식	연결	특징
DAS	서버에 저장장치 직접 연결	구축이 싸고 단순, 서버 간 공유 불가
NAS	네트워크(LAN) 를 통해 파일 단위 접근	파일 공유 쉬움, 네트워크 부하에 성능 좌우
SAN	광채널(FC) 전용 네트워크, 블록 단위 접근	고성능·확장성, 비용이 큼

그 밖의 저장 기술

• 병렬 DBMS: 다수 프로세서로 질의를 분할 처리 (Teradata, Netezza, Greenplum)
• 클라우드 스토리지: 오브젝트 스토리지 기반의 사실상 무제한 확장
• 인메모리 저장: Redis, Memcached — 초저지연 조회용 캐시 계층

데이터 저장소 설계는 논리 설계(개념·주제 영역 정의) → 물리 설계(파티셔닝, 인덱스, 압축, 파일 포맷) 순으로 진행합니다. 파티셔닝과 인덱스는 물리 설계 단계의 관심사입니다.