이 과목 예상 출제 범위 — 💯 DW 스키마·EAI vs ESB·하둡 에코시스템·맵리듀스 순서 / ⭐ ETL/ODS·CDC·GFS/HDFS·NoSQL·SQL on Hadoop / 🔥 DB클러스터·가상화·메모리 기법 📖 이 과목도 계산 문제가 거의 없어요. 기술 이름과 역할을 정확히 매칭하는 문제 위주입니다.
0) 원본 교재 없이도 이해되는 기초 개념 📖 (입문자용)
왜 “데이터 처리 기술”을 배우나요? ❗ 1과목에서 “빅데이터가 무엇인지”를 배웠다면, 2과목은 그 빅데이터를 실제로 어떻게 수집·이동·저장·처리하는가를 배웁니다. 흐름은 이렇습니다: 원천 시스템(앱·로그·센서 등) → 수집(ETL/EAI/Flume·Sqoop 등) → 저장(HDFS·NoSQL·DB클러스터) → 처리(맵리듀스·스파크) → 분석(SQL on Hadoop). 이 흐름을 먼저 머리에 그려놓고 각 기술을 어느 단계에 넣을지 생각하면 암기가 훨씬 쉽습니다.
ETL이란 무엇인가? ❗ 원천 시스템의 데이터를 분석용 저장소(DW 등)로 옮기는 과정입니다. 마치 이사할 때 “짐(Extraction) → 짜서 정리(Transformation) → 새 집에 넣기(Load)“하는 것이라고 생각하면 쉽습니다.
하둡(Hadoop)이란 무엇인가? ❗ 대용량 데이터를 여러 대의 서버에 나눠서 저장·처리하는 오픈소스 프레임워크입니다. “저장은 HDFS, 처리는 맵리듀스”가 핵심 축이고, 나머지 기술(피그·하이브·하베이스 등)은 이 둘을 보조하는 도구들입니다.
🎯 학습 우선순위 계획 (기출 분석 기반)
최우선 암기(반복 출제 확인됨, 함정형 문제 다수) ❗❗❗
- CDC: Status on Rows “보완 불가”·Log Scanner “관리 복잡도 증가” 함정
- EAI vs ESB 4관점 구분, EAI 활용효과에 “CDC 구현” 없음
- 하둡 에코시스템: Pig가 MapReduce를 대체 못한다는 서술(오답), Sqoop이 NoSQL을 지원한다는 서술(오답), Import/Export 방향 반대 서술(오답)
- 컨테이너 가상화의 지원 계층 = 가상 운영환경(하이퍼바이저 아님) — 실제 기출 선지로 반복 확인
- DW 4특징(주영통시), 스타 vs 스노우플레이크
- 맵리듀스 워드카운트 실행 순서 7단계
보완 완료(이전에 설명 부족했던 부분, 이번에 상세화함) ⭐
-
- 데이터 수집·하둡 에코시스템: 기술별 개발주체·상세 설명 추가
-
- NoSQL: 개념·BASE 특성·데이터 모델 4종(Key-Value/Document/Column/Graph) 추가
- (최신 업데이트) CDC Status on Rows · EAI-ESB 결합도/대상 · 통합기법 3종(배치/비동기/동기) · 러스터(Lustre) · GFS/HDFS 구성요소(보조네임노드 SPOF) · DB클러스터 예시(IBM DB2 ICE)·고려사항 · NoSQL 추가사례(MS SSDS) · Sawzall · 클라우드 서비스 예시 · 하이퍼바이저 Type1/2 · I/O 가상화 · DW 정의문 · EAI·ESB/ETL/CDC 3자 비교표 · 무공유/공유디스크 SAN·수정권한 명확화 · MySQL 특징 · CPU가상화(하드웨어지원완전가상화/Monolithic·Microkernel/호스트기반) 신규 반영
상대적으로 가볍게 봐도 되는 부분 (출제 확인도 낮음, 세부 암기 불필요)
- 가상화 플랫폼별 분류(x86/유닉스/메인프레임 계열), 하이퍼바이저 위치별 세부 분류
- VMkernel·Shadow Page Table 등 메모리 가상화 내부 동작 원리(명칭만 알면 충분)
1) ETL ⭐ · ODS 6단계 ⭐
ETL(Extraction·Transformation·Load): 원천→ 추출, 변형, 적재 / ODS/DW/DM 이동·변환. 배치(Batch) 중심 ❗(↔ EAI=실시간). 변형=클렌징·표준화·통합·비즈니스 룰 적용
ODS(Operational Data Store): 실시간·원자성을 지닌 낮은 수준 데이터 처리 ❗, 이후 DW로 이관
| 단계 | 키워드 |
|---|---|
| ①인터페이스 | 이기종 원천 획득(OLEDB·ODBC·FTP) |
| ②스테이징 ❗ | 정규화 배제, 타임스탬프·체크섬 통제정보, 정기+실시간 ETL 혼용 |
| ③프로파일링 | 데이터 특성·품질 측정 |
| ④클렌징 | 오류 데이터 보정 |
| ⑤인티그레이션 | 충돌 해소·통합 |
| ⑥익스포트 | 보안 규칙 적용 후 DW·DM 전송 |
🥔 ODS 순서 외우는법! 인스프클인익 (인터페이스→스테이징→프로파일링→클렌징→인티그레이션→익스포트) 📝 참고(교재별 차이) ❗: 일부 교재는 6단계의 마지막을 Denormalizing(비정규화 — 조회 성능 향상을 위해 테이블을 의도적으로 통합·단순화)으로 명명. 암기법 IS PC ID(Interface·Staging·Profiling·Cleansing·Integration·Denormalizing)
2) DW · 스키마 💯
데이터 웨어하우스(DW)란? ❗ ODS를 통해 정제된 데이터가 축적되어 적재되는 주제 지향적 통합 저장소
🥔 DW 4특징 외우는법! 주영통시 — 주제 중심성(사용자가 이해하기 쉬워야 함) · 영속성(비휘발, 읽기전용·삭제되지 않음) · 통합성 · 시계열성(시간 순에 의한 이력데이터 보유)
| 구분 | 스타 스키마 | 스노우 플레이크 |
|---|---|---|
| 특징 ❗ | 사실(Fact)=제3정규형, 차원(Dimension)=제2정규형 | 차원 테이블을 제3정규형으로 정규화 |
| 장점 | 단순·이해 쉬움·쿼리 용이·조인 적음 | 중복 제거 → 적재 시간 단축 |
| 단점 | 데이터 중복 → 적재 오래 걸림 | 복잡성↑·조인↑·쿼리 난이도↑ |
ODS vs DW ❗ : ODS=실시간·원자성·지속 갱신·운영 지원 ↔ DW=요약·이력·비휘발·중장기 의사결정 지원
| 구분 | ODS | DW |
|---|---|---|
| 데이터의 내용 | 최신 데이터 | 오래됨, 가공된 데이터 |
| 데이터의 양 | 소규모 | 대규모 |
| 데이터의 갱신 | 실시간/근접 실시간으로 지속적 갱신 | 축적 보관 |
| 기술적 요소 | 모든 기능 사용 | 적재, 접근 중심 |
3) CDC ⭐
CDC(Change Data Capture): DB 변경(삽입·갱신·삭제) 식별·후속 처리 자동화 / 방식 ❗: 푸시(원천이 통보) · 풀(대상이 주기적 확인)
| 기법 | 키워드 |
|---|---|
| Time Stamp on Rows | 타임스탬프 칼럼으로 변경 식별 |
| Version Numbers on Rows ❗ | 버전 번호↑, 최신 버전 참조 테이블 함께 운영 |
| Status on Rows ❗ | 변경여부를 나타내는 상태값(True/False 등)으로 변경 데이터 판단, 위 기법들의 보완 용도로 활용 가능 |
| Time/Version/Status on Rows ❗ | 타임스탬프, 버전넘버, 상태값 모두 활용 |
| Triggers on Tables | 트리거 이벤트 처리, 복잡도↑·성능 저하 |
| Event Programming ❗ | 앱에 코드 구현, 부담↑ but 다양한 조건 CDC 가능 |
| Log Scanner on Database ❗ | 트랜잭션 로그 스캔: DB·앱 영향 최소화 / 지연 최소화 / 무결성 영향 최소화 / 스키마 변경 불필요 |
🚫 기출 함정: ① “Status on Rows는 보완 용도로 활용될 수 없다” → 오답 ② Log Scanner 특징에 “관리 복잡도 증가” → 포함 안 됨
4) EAI / ESB 💯
EAI·ESB vs ETL vs CDC 핵심 구분 ❗❗❗ (신규)
| 기술 | 핵심 방식 | 이동 대상·시점 |
|---|---|---|
| EAI·ESB | 운영 시스템 간 연계 | 실시간·근실시간 |
| ETL | 분석 시스템(DW)으로 이동 | 배치(Batch) 중심 |
| CDC | 변경된 데이터만 캐치·전달 | 실시간·근실시간 |
EAI(Enterprise Application Integration): 이질적 시스템 연계·통합 프레임워크. 기존 PTP(Point-to-Point, 1:1) → Hub and Spoke(중앙집중) ❗ / EAI=실시간 ↔ ETL=배치 ❗
구성요소: 어댑터·버스·브로커·트랜스포머 / 유형: Mediation(Pub/Sub) · Federation(Req/Reply) / 활용 효과: 비용 절감·시스템 발전 기반·협력 프로세스 연계·데이터 동기화·표준화 기반
| 구분 | EAI | ESB(Enterprise Service Bus) |
|---|---|---|
| 기능 ❗ | Hub 미들웨어, 비즈니스 로직 중심 App 통합 | Bus 미들웨어, 서비스 중심 유기적 연계 |
| 통합 관점 | Application | Process(서비스) |
| 결합도 | 강결합 | 약결합 |
| 대상 | 기업 내부 시스템 | 기업 내/외부 시스템 |
| 로직 연동 | 개별 Application에서 수행 | ESB에서 수행 |
| 아키텍처 | 중앙집중식 | 느슨하고 유연한(Loosely-coupled) |
🚫 기출 함정: EAI 활용 효과에 “CDC 메커니즘 구현” → 포함 안 됨
4-1. 데이터 연계 및 통합 기법(처리 시점 기준) ❗ (신규)
| 통합 방식 | 특징 |
|---|---|
| 배치 통합 | 일정 주기로 데이터를 일괄 처리. 대용량 데이터 처리에 적합하며 실시간성이 불필요한 DW·DM 구축에 주로 사용 |
| 비동기식 실시간 통합 | 이벤트 발생 시 데이터를 즉시 전달하나 송·수신 시스템이 서로 응답을 기다리지 않음(낮은 결합도) |
| 동기식 실시간 통합 | 요청 시스템이 응답 시스템의 처리 완료를 기다림. 즉각적인 응답이 필요한 온라인 트랜잭션 처리에 적합 |
5) 데이터 수집 ⭐ · 하둡 에코시스템 💯
5-1. 비정형 데이터 수집 기술 (로그 수집 시스템) ❗
| 기술 | 개발 주체 | 상세 설명 |
|---|---|---|
| Flume-NG ❗ | 클라우데라(Cloudera) 개발, 아파치 오픈소스 | 소스 서버에 에이전트(Agent) 설치 → 에이전트가 수집한 데이터를 콜렉터(Collector)에 전달 → 콜렉터가 HDFS 등에 저장. 마스터 서버가 있어 어디서 수집·어떻게 전송·어디에 저장할지 동적으로 변경 가능(척와보다 유연) |
| Scribe ❗ | 페이스북 개발, **C++**로 제작 | 각 서버의 로그를 메시지 큐에 모아 중앙집중 서버로 전달. 속도가 빠르고 대용량 처리에 안정적(단, 현재는 페이스북이 후속 도구로 대체해 유지보수 중단된 레거시) |
| Chukwa ❗ | 야후 개발, 하둡 서브프로젝트 | 에이전트-콜렉터 구조(Flume과 유사)로 분산된 서버의 로그를 수집해 HDFS에 안정적으로 저장. 수집한 데이터를 MapReduce로 바로 분석할 수 있게 하는 것이 특징 |
| Kafka | 링크드인 개발, 아파치 톱레벨 프로젝트 | 분산 메시징 시스템으로 대용량 실시간 스트림 데이터 처리. 디스크에 저장해 데이터 유실 방지, 파티셔닝으로 다수 서버 분산 처리·로드밸런싱·내고장성 보장 |
비정형 데이터 수집 시스템 특징 4가지 ❗: ①초고속 수집 성능과 확장성 ②데이터 전송 보장 메커니즘(유실 방지) ③다양한 수집·저장 플러그인 ④인터페이스 상속을 통한 애플리케이션 기능 확장
5-2. 정형 데이터 수집(연동) 기술 ❗
| 기술 | 상세 설명 |
|---|---|
| Sqoop(스쿱) ❗ | 하둡과 관계형 데이터베이스(RDBMS) 간 정형 데이터를 연동하는 오픈소스 솔루션. Import(RDB → 하둡/HDFS 적재)와 Export(하둡 → RDB 적재) 모두 지원 ❗. 오라클·MySQL 등 대부분의 관계형 DB는 지원하지만, NoSQL은 거의 지원하지 않음 ❗(기출 함정: “대부분 NoSQL을 지원한다” → 오답) |
| Hiho(히호) ❗ | 스쿱과 유사하게 하둡-관계형DB 간 데이터 연동을 지원하는 오픈소스 도구(국내 개발) |
🚫 기출 함정 총정리: ①Sqoop이 NoSQL을 지원한다는 서술 → 오답(정형 RDBMS 대상) ②Import/Export 방향을 반대로 서술(예: “Import로 RDBMS에 적재, Export로 HDFS에 적재”) → 오답(정답은 반대: Import=RDB→하둡, Export=하둡→RDB)
하둡 특징 5가지 ❗: ①비공유(Shared Nothing) 구조(각 노드가 디스크·메모리를 공유하지 않고 독립 운영) ②선형적 성능·용량 확장(노드 추가만으로 확장) ③고장 감내성(데이터 3중 복제·작업 실패 시 자동 재실행) ④핵심 비즈니스 로직 집중(장애 처리를 시스템이 대신함) ⑤풍부한 에코시스템
5-3. 하둡 에코시스템 전체 매칭표 ❗❗❗
| 기능 | 기술 | 핵심 설명 |
|---|---|---|
| 비정형 데이터 수집 | 척와·플럼·스크라이브 | 로그 등 비정형 데이터를 에이전트·콜렉터 구조로 수집해 HDFS에 저장 |
| 정형 데이터 수집(연동) | 스쿱·히호 | 하둡↔RDBMS 데이터 연동(Import/Export) |
| 분산 데이터 저장 | HDFS | 대용량 파일을 블록 단위로 분산·복제 저장 |
| 분산 데이터베이스 | HBase | HDFS 기반 칼럼 지향 NoSQL, 실시간 읽기/쓰기 |
| 분산 데이터 처리 | 맵리듀스(MapReduce) | 분할정복 방식의 대용량 데이터 병렬 처리 |
| 리소스(자원) 관리 | 얀(YARN) ❗ | 맵리듀스의 자원관리 기능을 분리해 확장성 문제 해결, 다양한 분산 애플리케이션의 자원을 통합 관리하는 프레임워크 |
| 인메모리 처리 | 아파치 스파크(Spark) ❗ | 데이터를 메모리에 올려두고 처리해 맵리듀스보다 훨씬 빠름(반복 연산·실시간 처리에 유리) |
| 데이터 가공 | 피그(Pig) ❗ | Pig Latin 언어로 복잡한 MapReduce 프로그래밍을 대체(100줄→10~20줄로 단축) ❗(기출 함정: “대체하지 못한다” → 오답) |
| 데이터 가공(DW) | 하이브(Hive) ❗ | 하둡 기반 데이터 웨어하우스, HiveQL로 SQL과 유사하게 질의. 내부적으로 맵리듀스로 변환되어 실행되므로 배치 처리(실시간 조회에는 부적합) |
| 데이터 마이닝 | 머하웃(Mahout) ❗ | 하둡 기반 데이터마이닝 알고리즘(분류·군집·추천 등)을 구현한 오픈소스 라이브러리 |
| 실시간 SQL 질의 | 임팔라·타조 | 맵리듀스를 거치지 않고 대화형으로 SQL 질의(임팔라=SQL on Hadoop의 원조) |
| 워크플로우 관리 | 우지(Oozie) ❗(+아즈카반) | 여러 개의 하둡 작업(Job)을 순서대로 관리하는 워크플로우 및 코디네이터 시스템 |
| 분산 코디네이션 | 주키퍼(Zookeeper) ❗ | 분산 시스템 간 설정 정보 관리·동기화, 여러 서버의 상태를 조율해 일관성 유지(HBase의 고가용성도 주키퍼가 지원) |
🚫 기출 함정: “분산 데이터 저장 기술이 아닌 것은?” 유형에서 **아파치 스팅거(Stinger)**를 저장 기술로 헷갈리기 쉬운데, 스팅거는 저장 기술이 아니라 SQL on Hadoop 기술(하이브 성능 개선판)
6) GFS · HDFS ⭐
GFS 설계 가정 ❗: ①서버 고장 빈번 ②대용량 파일 ③추가 쓰기 중심(한 번 쓰면 잘 안 바뀜) ④높은 처리율 > 낮은 지연 (구조: 마스터1 + 청크서버 다수, 64MB·3중 복제)
GFS 구성요소 ❗ (신규): 클라이언트(파일 읽기·추가 요청 수행) · 마스터(단일 구조, 메타데이터·네임스페이스·청크 위치 관리) · 청크서버(청크 저장, Heartbeat 메시지로 상태를 마스터에 주기적 전달)
HDFS 특징 ❗: 네임노드 1 + 데이터노드 다수 / 블록 단위 분산·복제(파일 단위 X) / 한 번 쓰면 변경 X 가정 / 순차 스트리밍·배치 적합 / 높은 처리량 / RPC 통신
HDFS 구성요소 ❗ (신규): 네임노드(마스터, 메타데이터 관리) · 데이터노드(슬레이브, 실제 데이터 저장·3중 복제 수행) · 보조네임노드(메타데이터 체크포인트 생성용, 네임노드의 백업노드가 아님 🚫기출함정) — 마스터/슬레이브 구조라 마스터 장애 시 단일 장애 지점(SPOF) 발생 가능
📗 파일 읽기: 네임노드에 블록 위치 요청 → 데이터노드 목록 수신 → 데이터노드에서 직접 읽기(데이터는 네임노드 경유 X) 📗 파일 쓰기: 네임노드에 생성 요청 → 데이터노드 목록 할당 → 첫 노드 전송 → 파이프라인 복제(1→2→3) → 완료 보고
6-1. 러스터(Lustre) ❗ (신규)
고성능 컴퓨팅(HPC) 환경을 위한 병렬 분산 파일 시스템. **메타데이터 서버(MDS)**와 **객체 저장 서버(OSS)**로 역할이 분리된 구조. 클라이언트에서 메타데이터 변경에 대한 갱신 레코드 생성
7) DB 클러스터 · NoSQL ⭐
| 구분 | 무공유(Shared Nothing) | 공유 디스크(Shared Disk) |
|---|---|---|
| 특징 | 노드별 데이터 소유권 분리 | 모든 노드가 데이터 논리적 공유 |
| 장점 | 노드 확장 제한 없음 | 높은 폴트톨러런스 |
| 단점 | 폴트톨러런스 별도 구성 필요 | 클러스터 커지면 디스크 병목 |
| 대표 ❗ | MySQL Cluster | Oracle RAC(Real Application Cluster) |
MySQL 클러스터 3노드 ❗: 관리 노드(관리·설정) · 데이터 노드(저장) · SQL 노드(접근 창구) — 무공유, 데이터=디스크·인덱스=메모리
주요 DB 클러스터링 예시 ❗ (신규): Oracle RAC(공유디스크, 가용성·확장성 확보) / IBM DB2 ICE(무공유, CPU·메모리·디스크를 파티션별로 독립 운영) / MySQL(무공유) — Oracle RAC를 제외한 대부분 클러스터가 무공유 방식
클러스터 설정 시 고려사항 (신규): 네트워크 성능·지연 / 데이터 일관성 / 관리·모니터링 복잡성 / 구축·운영 비용
MySQL 특징 ❗ (신규): 오픈소스 RDBMS, 다양한 스토리지 엔진(InnoDB 등) 지원, 무공유(Shared-Nothing) 클러스터 구조로 확장 가능
7-1. NoSQL의 개념 및 특징 ❗❗❗
NoSQL(Not Only SQL) ❗ : 기존 관계형 모델(RDBMS)을 따르지 않는 비관계형 데이터베이스 관리시스템. 여러 대의 DB 서버를 묶어(클러스터링) 하나의 DB처럼 구성해 대용량 비정형·반정형 데이터를 유연하게 저장·처리
핵심 특징 ❗
- 스키마가 없거나 유연함(Schema-less): 미리 정의된 테이블 구조 없이도 데이터 저장 가능
- 수평적 확장(Scale-out)이 용이: 서버를 추가해 용량·성능을 늘림(기존 RDB의 수직적 확장과 대조)
- BASE 특성 지향 ❗: RDB의 ACID 대신 Basically Available, Soft state, Eventually consistent(결국엔 일관성 확보)를 충족시켜 성능·확장성 확보
- 대용량 빅데이터의 비정형·반정형 데이터 처리에 적합, 읽기/쓰기 성능이 높음
- 조인(Join) 연산이 없거나 제한적(데이터 중복을 허용해 조인 필요성을 줄임)
데이터 모델 4가지 ❗❗
| 모델 | 특징 | 대표 예시 |
|---|---|---|
| Key-Value ❗ | 가장 단순한 구조. 키와 값을 1:1로 저장, 값의 내부 구조는 신경 쓰지 않음. 조회 속도 매우 빠름 | Redis, Amazon DynamoDB, Riak |
| Document(문서) ❗ | JSON·XML·BSON 등 문서 단위로 저장. 문서마다 구조가 다를 수 있음(유연한 스키마) | MongoDB, CouchDB, 아마존 SimpleDB |
| Column(칼럼, 칼럼패밀리) ❗ | 행이 아닌 칼럼 단위로 묶어 저장, 같은 칼럼끼리 모아 대규모 읽기/집계에 유리 | Google Bigtable, HBase, Cassandra |
| Graph(그래프) ❗ | 노드(개체)와 엣지(관계)로 데이터를 저장, 개체 간 관계·연결성 탐색에 특화 | Neo4j |
🚫 기출 함정: “NoSQL은 SQL(구조적 질의 언어)을 전혀 사용하지 않는다” → 오답! Not Only SQL이라는 이름이 말해주듯, 일부 NoSQL은 SQL계열 쿼리 언어를 지원함(예: Cassandra의 CQL, HBase와 연동되는 SQL on Hadoop인 임팔라·하이브의 HiveQL). 관계형 DB의 조인 중심 구조적 질의를 그대로 지원하지 않는다는 점이 핵심이지, SQL 계열 언어 자체를 배제하는 것은 아님
7-2. 주요 NoSQL 사례 (출제 빈도 높은 3가지) ❗
| NoSQL | 키워드 |
|---|---|
| 구글 빅테이블 ❗ | GFS 기반 공유 디스크 방식, (row key·column key·timestamp) 다차원 맵. Column 모델의 원조. 페일오버(장애 발생 시 다른 노드로 작업 재할당) 지원, AppEngine을 통해 API 추상화 제공 |
| HBase ❗ | HDFS 기반 칼럼 기반(빅테이블 모델). 관계형 X · SQL 미지원, 로우키 인덱싱만, 단일 행 트랜잭션, Zookeeper 고가용성, 선형 확장 |
| 아마존 SimpleDB ❗ | 스키마 없음 · 도메인=테이블 / 아이템=행 / Attribute=칼럼 / Value=값. Document 모델에 가까운 구조 |
| 마이크로소프트 SSDS (신규) | 컨테이너와 엔티티로 구성(Azure 계열 NoSQL 스토리지) |
8) 맵리듀스 · 하이브 · SQL on Hadoop 💯
맵리듀스: 구글의 분할정복 분산 병렬 프레임워크. 맵 태스크 1개 = 블록 1개 연산 ❗. 하둡 맵리듀스=Java 구현(잡트래커+태스크트래커)
📗 워드카운트 실행 순서 ❗ : 스플릿 → 맵 → 컴바인 → 파티션 → 셔플 → 소트 → 리듀스 (컴바인=로컬 사전 집계로 네트워크 부하↓, 선택적)
병렬 쿼리 시스템 ❗ (신규): 구글 Sawzall(맵리듀스를 추상화한 병렬 프로그래밍 언어) · 아파치 Pig(Pig Latin) · 아파치 Hive(HiveQL)
하이브(Hive) ❗: 하둡 기반 DW, 테이블 단위 저장 + HiveQL(SQL 유사), 페이스북 개발, 맵리듀스 변환 실행 → 배치 기반
SQL on Hadoop: 하둡 데이터를 대화형 SQL 질의로 처리(실시간 제약 극복). 원조 = 임팔라 ❗
| 기술 | 키워드 |
|---|---|
| 임팔라(Impala) ❗ | 클라우데라 주도·먼저 공개, C++ · 맵리듀스 미사용(MPP), 하둡·HBase에 SQL 질의 |
| 스팅거 / 드릴 | 호튼웍스·하이브 코드 최대 활용 / MapR·구글 드레멜 오픈소스 구현 |
| 타조 / 프레스토 / 호크 / 샤크 | 국내(고려대·그루터) / 페이스북 / EMC / 인메모리 DW·하이브 호환 |
🚫 기출 함정: “SQL on Hadoop의 원조 = 빅테이블” → 오답 (빅테이블은 NoSQL, 원조는 임팔라)
9) 클라우드 · 가상화 🔥
클라우드 컴퓨팅 3유형 ❗ (예시 보강)
| 모델 | 제공 범위 | 사용자 역할 | 예시 |
|---|---|---|---|
| IaaS | 가상화된 서버·네트워크·스토리지 등 인프라 | OS 설치부터 애플리케이션 실행까지 직접 관리 | Amazon EC2, Microsoft Azure VM |
| PaaS | 개발에 필요한 플랫폼(OS·DB 등) | 애플리케이션 코드만 작성 | Google App Engine, Azure App Service |
| SaaS | 완성된 소프트웨어를 웹 기반 제공 | 소프트웨어만 사용 | Microsoft 365, Dropbox |
서버 가상화 ❗(기출 그대로): 물리적 서버와 운영체제 사이에 적절한 계층을 추가해 사용자에게 물리적 자원은 숨기고 논리적 자원만 보여주는 기술. 최근 CPU 제조사도 하드웨어 가상화를 지원해 가상화 기술을 정확히 분류하기 어려움
서버 가상화 효과 8가지 ❗: VM 간 데이터 보호 / 장애로부터 보호 / 공유 자원 강제 사용 거부 / 서버 통합 / 자원 할당 유연성↑ / 테스팅 / 서버 사이징 / 시스템 관리
하이퍼바이저 ❗: 호스트에서 다수 OS를 동시 실행하기 위한 논리적 플랫폼(VMM)
하이퍼바이저 목적 ❗ (신규): 자원 통합 및 효율화 · 하드웨어 에뮬레이션 · 격리 및 보안 · 유연성 확보
| 유형 | 특징 | 예시 |
|---|---|---|
| Type 1(하이퍼바이저 가상화) ❗ | OS 없이 물리 서버에 직접 설치, 성능 우수·보안성 높음(서버/클라우드용) | VMware ESXi, KVM, Hyper-V, Xen |
| Type 2(호스트 가상화) ❗ | Host OS 위에 설치되는 애플리케이션 형태(개인용/테스트용) | Oracle VirtualBox, VMware Workstation |
| CPU 가상화 | 핵심 포인트 |
|---|---|
| 완전가상화(Full Virtualization) ❗ | 어떤 OS든 수정 없이 설치 가능(가장 자주 나오는 포인트), 하이퍼바이저가 하드웨어 명령을 트랩·에뮬레이션 |
| 하드웨어 지원 완전가상화 ❗ (신규) | CPU 자체(Intel VT-x, AMD-V)가 가상화를 지원 → 완전가상화 대비 성능 향상 |
| 반가상화(Para-Virtualization) ❗ | 게스트 OS를 수정해야 함(하이퍼콜 사용), 완전가상화보다 성능은 좋으나 이식성 낮음 |
| Monolithic vs Microkernel ❗ (신규) | Monolithic: 디바이스 드라이버를 하이퍼바이저 내부에 포함(빠르지만 구조가 크고 취약) / Microkernel: 하이퍼바이저를 최소화, 드라이버는 별도 파티션에 위치(안정적, 예: Hyper-V) |
| 호스트 기반 가상화 ❗ (신규) | 호스트 OS 위에 가상화 소프트웨어를 설치하는 방식, 설치는 쉽지만 오버헤드가 큼 |
| 컨테이너 기반 ❗❗❗ | 지원 계층 = 가상 운영환경(하이퍼바이저 아님) — 실제 기출 함정 선지로 반복 출제. OS를 가상화하지 않고 애플리케이션·실행환경만 격리(완전한 OS 분리가 아닌 프로세스 단위 격리), 가볍고 빠름, 마이크로서비스 구조에 적합. 예: Docker |
🥔 참고 (신규): 모놀리식은 모든 기능을 하나로 통합한 구조, 마이크로서비스는 기능을 서비스 단위로 분리한 구조(컨테이너 기반 가상화와 궁합이 좋음) 🚫 기출 함정(실제 선지): “컨테이너 기반 가상화 방식에서 가상화를 지원하는 계층을 하이퍼바이저라고 한다” → 오답. 정답은 가상 운영환경
메모리 가상화(VMware) 기법 3가지 ❗
| 기법 | 핵심 키워드 |
|---|---|
| Memory Ballooning ❗ | 메모리를 빈 값으로 채워 게스트 OS 자체 스와핑 유도 |
| Transparent Page Sharing ❗ | 동일 페이지는 물리 메모리에 1개만 두고 공유 |
| Memory Overcommitment ❗ | 물리보다 많이 할당 가능하나 성능 저하로 비권장 |
9-1. I/O 가상화 ❗ (신규)
| 기술 | 설명 |
|---|---|
| 가상 이더넷(vNIC) | VM에 제공되는 가상 네트워크 인터페이스 |
| 공유 이더넷 어댑터(SEA) | 여러 VM의 네트워크 트래픽을 하나의 물리 NIC로 공유 |
| 가상 디스크 어댑터 | VM에 스토리지 I/O를 제공하는 가상 인터페이스 |
🥔 복습 체크리스트
- 1) ETL 3기능·배치 중심 · ODS 6단계(인스프클인익) ⭐ ❗
- 2) DW 주영통시 · 스타 vs 스노우플레이크 · ODS vs DW(내용·양·갱신·기술요소) 💯
- 3) CDC 기법 6 · 푸시/풀 · 함정 2개 ⭐ ❗
- 4) EAI(PTP→Hub&Spoke·실시간) vs ESB 4관점 💯 ❗
- 5) 비정형 수집 4종(개발주체·특징) · 정형 연동 2종(Import/Export 방향) · 에코시스템 매칭+상세설명 💯 ❗
- 6) GFS 가정 4 · HDFS 특징 · 읽기/쓰기 순서 ⭐ ❗
- 7) 무공유 vs 공유(Oracle RAC) · MySQL 3노드 · NoSQL 개념+특징(BASE·스키마리스) · 데이터모델 4종(K-V/Document/Column/Graph) · 빅테이블/HBase/SimpleDB ⭐ ❗
- 8) 맵 태스크1=블록1 · 워드카운트 7단계 · 하이브 · 임팔라 💯 ❗
- 9) IaaS/PaaS/SaaS(예시 포함) · 하이퍼바이저 Type1/Type2 · 완전가상화 vs 반가상화 · 컨테이너=가상 운영환경(하이퍼바이저 아님, Docker) · 메모리 가상화 3기법 · I/O 가상화(vNIC/SEA/가상디스크) 🔥 ❗ (신규 포함)