N년차 개발자

[Spring] 정적 컨텐츠 vs MVC 패턴 vs API

peachh — Wed, 10 Sep 2025 01:58:19 +0900

정적 컨텐츠, MVC 패턴, API는 스프링 웹 개발에 주로 사용되는 3가지 방식이다.

정적 컨텐츠

약속된 경로(ex. /resources/static)에 저장된 html 파일을 그대로 내려준다.
요청과 관련된 컨트롤러가 있는지 먼저 확인하고 없다면 정적 컨텐츠를 찾는다.

MVC 패턴

관심사에 따라 Model-View-Controller 로 구분된 패턴이며, 템플릿 엔진을 사용해서 html 파일을 적절히 가공해서 내려준다.
Controller는 템플릿과 모델을 ViewResolver에게 넘긴다.
ViewResolver가 템플릿을 찾아서 템플릿 엔진에 넘기면 템플릿 엔진이 렌더링해서 완성된 HTML을 내려준다.

API

html이 아니라 데이터 그 자체를 내려준다.
컨트롤러의 메소드에 @ResponseBody 를 사용하면 ViewResolver를 사용하는 대신에 HttpMessageConverter를 사용한다.
클라이언트의 Accept 헤더와 데이터 타입에 대한 정보를 조합하여 StringConverter, JsonConverter 등 적절한 컨버터를 사용한다.

Reference

스프링 입문 - 코드로 배우는 스프링 부트, 웹 MVC, DB 접근 기술

[하둡 완벽 가이드] Chapter 03. 하둡 분산 파일시스템(4)

peachh — Sat, 10 Sep 2022 18:30:09 +0900

데이터 읽기

클라이언트는 DistributedFileSystem 인스턴스인 FileSystem 객체의 open() 메소드를 호출하여 파일을 연다.
DistributedFileSystem은 파일 블록의 위치를 파악하기 위해 RPC(Remote Procedure Call)을 사용하여 네임 노드를 호출한다.
네임 노드는 각 블록마다 복제본을 가진 데이터 노드의 주소를 반환한다. 이때 클러스터의 네트워크 위상에 따라 클라이언트와 가까운 순으로 데이터 노드가 정렬된다.
DistributedFileSystemd은 파일 탐색을 위한 입력 스트림인 FSDataInputStream을 클라이언트에 반환한다. FSDataInputStream은 네임 노드와 데이터 노드의 통신을 처리하는 DFSInputStream으로 Wrapping 된다.
클라이언트는 스트림을 읽기 위해 read() 메소드를 호출한다.
FSDataInputStream은 각 블록의 복제본을 가진 클라이언트와 가장 가까운 데이터 노드에 연결하여 파일의 데이터를 전송한다.
클라이언트 관점에서는 이 과정이 투명하여 단순히 연속된 스트림을 읽는 것처럼 느껴진다.
모든 데이터를 읽으면 클라이언트는 FSDataInputStream의 close() 메소드를 호출한다.

클라이언트는 다음 블록의 데이터 노드 위치를 얻기 위해 블록을 순서대로 하나씩 읽고, DFSInputStream은 하나의 블록을 읽을 때마다 데이터 노드와 새로운 연결을 맺는다. 데이터를 읽다가 데이터 노드에 장애가 발생하거나 블록이 손상된 경우에는 다른 데이터 노드에 연결을 시도하여 데이터를 읽는다.

데이터 쓰기

클라이언트는 DistributedFileSystem의 create() 메소드를 호출하여 파일을 생성한다.
DistributedFileSystem은 파일시스템의 네임스페이스에 새로운 파일을 생성하기 위해 RPC(Remote Procedure Call)을 사용하여 네임 노드를 호출한다. 이때 블록에 대한 정보는 보내지 않는다.
네임 노드는 파일이 생성될 수 있는지 검사하여 통과하면 새로운 파일의 레코드를 만들고, 그렇지 않으면 파일 생성이 실패하며 클라이언트의 IOException이 발생한다.
DistributedFileSystemd은 파일 쓰기를 위한 출력 스트림인 FSDataOutputStream을 클라이언트에 반환한다. FSDataOutputStream은 네임 노드와 데이터 노드의 통신을 처리하는 DFSOutputStream으로 Wrapping 된다.
클라이언트가 데이터를 쓸 때 DFSOutputStream은 데이터를 패킷으로 분리하고, 내부의 데이터 큐로 패킷을 보낸다.
DataStreamer는 데이터 큐의 패킷을 처리한다.
(1) 네임 노드에 복제본을 저장할 데이터 노드의 목록을 요청한다. (복제 계수만큼
(2) 목록의 데이터 노드는 파이프라인을 형성한다.
(3) DataStreamer는 파이프라인의 첫 번째 데이터 노드로 패킷을 전송하고, 각 노드는 패킷을 저장한 후 다음 노드로 보낸다.
DFSOutputStream의 ACK 큐는 데이터 노드의 승인 여부를 기다리며, 모든 노드로부터 ACK 응답을 받아야 큐에 있는 패킷이 제거된다.
데이터 쓰기 작업이 완료되면 close() 메소드를 호출한다.
(1) 파이프라인에 남아 있는 모든 패킷을 flush 하고 ACK를 기다린다.
(2) 모든 패킷이 완전히 전송되면 네임 노드에 "File is Complete" 신호를 보낸다.
(3) 네임 노드는 최소한의 블록 복제가 완료되면 최종적으로 성공 신호를 반환한다.

데이터 쓰기 작업은 dfs.namenode.replication.min에 설정된 개수만큼의 블록이 저장되면 성공한 것으로 간주된다. 기본값은 1이며, 나머지 복제 작업은 비동기적으로 수행된다. 하둡은 신뢰성, 쓰기 대역폭, 읽기 성능, 분산도 등의 균형을 전체적으로 고려하여 복제본을 저장할 데이터 노드를 선택한다.

데이터 쓰기 중 장애가 발생하는 경우

파이프라인이 닫히고 ACK 큐에 있는 모든 패킷이 데이터 큐 앞쪽에 다시 추가된다. → 패킷이 유실되지 않는다.
정상 데이터 노드는 네임 노드로부터 새로운 ID를 받아서 장애가 발생한 데이터 노드를 제외한 나머지 데이터 노드로 새로운 파이프라인을 구성한다.
데이터는 새로운 파이프라인으로 전송되며, 네임 노드는 불완전 복제임을 인지하고 있으므로 나중에 다른 노드에 복제본이 생성되도록 조치한다.
장애가 발생한 데이터 노드가 복구되면 불완전한 블록은 삭제된다.

[하둡 완벽 가이드] Chapter 03. 하둡 분산 파일시스템(3)

peachh — Fri, 9 Sep 2022 23:46:55 +0900

하둡 파일시스템

하둡은 파일시스템의 추상화 개념을 가지고 있고, HDFS는 그 구현체 중 하나이다. FTP, S3, Azure 등 여러 구현체가 존재한다. 위에서 살펴본 명령어는 모든 파일시스템에서 잘 동작한다. 하지만 대용량 데이터를 처리할 때는 HDFS와 같이 데이터 지역성 최적화가 가능한 분산 파일시스템을 선택하는 것이 좋다.

인터페이스

하둡은 파일시스템의 추상화 개념을 가지고 있고, 다음은 그 구현체의 목록이다. 맵리듀스 프로그램은 어떠한 파일시스템도 쉽게 실행할 수 있지만 대용량 데이터를 처리할 때는 HDFS처럼 데이터 지역성 최적화가 가능한 분산 파일시스템을 선택하는 것이 좋다. 파일시스템의 인스턴스에 접근할 때는 주로 URI 스킴을 사용한다.

파일시스템	URI 스킴	자바 구현체 (org.apache.hadoop.)	설명
Local	file	fs.LocalFileSystem	클라이언트 측 체크섬을 사용하는 로컬 디스크를 위한 파일시스템
HDFS	hdfs	hdfs.DistributedFileSystem	맵리듀스와 효율적으로 연동하기 위한 파일시스템
WebHDFS	webhdfs	hdfs.web.WebHdfsFileSystem	HTTP를 통해 HDFS에 접근할 수 있는 파일시스템
SecureWebHDFS	swebhdfs	hdfs.web.SWebHdfsFileSystem	WebHDFS의 HTTPS 버전
HAR	har	fs.HarFileSystem	아카이브 파일을 위한 파일시스템
View	viewfs	viewfs.ViewFileSystem	다른 하둡 파일시스템을 위한 클라리언트 측 마운트 테이블
FTP	ftp	fs.ftp.FTPFileSystem	FTP 서버를 지원하는 파일시스템
S3	s3a	fs.s3a.S3AFileSystem	아마존 S3를 지원하는 파일시스템
Azure	wasb	fs.azure.NativeAzureFileSystem	마이크로소프트의 Azure를 지원하는 파일시스템
Swift	swift	fs.swift.snative.SwiftNativeFileSystem	오픈스택 Swift르르 지원하는 파일시스템

자바 인터페이스

FileSystem 클래스는 데이터를 읽고 쓰는 것 외에도 디렉터리, 파일시스템 질의, 파일 목록 조회, 파일 패턴, PathFilter, 데이터 삭제를 위한 다양한 메소드를 지원한다. 각 메소드에 대한 자세한 내용은 하둡 문서에 설명되어 있다.

예제 코드 실행

# 다운로드한 예제 코드 폴더로 이동
$ cd ~/hadoop-book/ch03-hdfs

# 빌드 (maven은 미리 설치)
$ mvn install

# 하둡 디렉터리로 복사 (examples 디렉터리는 미리 생성)
$ cp target/ch03-hdfs-4.0.jar $HADOOP_HOME/examples

# 실행
$ hadoop jar $HADOOP_HOME/examples/ch03.jar URLCat hdfs://localhost/user/$USER/sample.txt

[하둡 완벽 가이드] Chapter 03. 하둡 분산 파일시스템(2)

peachh — Fri, 9 Sep 2022 23:23:20 +0900

명령행 인터페이스

도움말

$ hadoop fs -help

로컬에서 HDFS로 복사하기

$ hadoop fs -copyFromLocal ~/Desktop/quangle.txt hdfs://localhost/user/$USER/quangle.txt	# 전체 경로
$ hadoop fs -copyFromLocal ~/Desktop/quangle.txt /user/$USER/quangle.txt				# core-site.xml에 설정된 fs.defaultFS 값 사용
$ hadoop fs -copyFromLocal ~/Desktop/quangle.txt quangle.txt						# 홈 디렉터리 (/user/$USER)

HDFS에서 로컬로 복사하기

$ hadoop fs -copyToLocal quangle.txt ~/Desktop/quangle.copy.txt

두 파일이 동일한지 확인하기

$ md5 ~/Desktop/quangle.txt ~/Desktop/quangle.copy.txt

HDFS 파일 목록 확인하기

$ hadoop fs -ls

MacOS에서 Maven 설치하기

peachh — Fri, 9 Sep 2022 21:37:15 +0900

1. Maven 홈페이지에서 바이너리 파일 다운로드

2. 압축 해제

$ tar xvf apache-maven-3.8.6-bin.tar.gz

3. 환경 변수 설정

$ vi ~/.zshrc

# 다음 내용 추가 후 [ESC] 누르고 :wq로 저장
export M3_HOME=/Users/jimin/Downloads/apache-maven-3.8.6
export PATH=$PATH:$M3_HOME/bin

$ source ~/.zshrc

4. 설치 확인

$ mvn -version

하둡 실행하기 (의사 분산 모드)

peachh — Fri, 9 Sep 2022 13:46:45 +0900

환경 설정 파일 생성

하둡의 환경 설정 파일은 $HADOOP_HOME/etc/hadoop 경로에 있다.

core-site.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<property>
		<name>fs.defaultFS</name>
		<value>hdfs://localhost/</value>
	</property>
</configuration>

hdfs-site.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<property>
		<name>dfs.replication</name>
		<value>1</value>
	</property>
</configuration>

mapred-site.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<property>
		<name>mapreduce.framework.name</name>
		<value>yarn</value>
	</property>
</configuration>

yarn-site.xml

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
	<property>
		<name>yarn.resourcemanager.hostname</name>
		<value>localhost</value>
	</property>
	<property>
		<name>yarn.nodemanager.aux-services</name>
		<value>mapreduce_shuffle</value>
	</property>
</configuration>

SSH 설정

$ sudo apt-get install ssh

# MAC OS인 경우, [시스템 환경설정]-[공유]-[원격 로그인]을 활성화해야 함

$ ssh-keygen -t rsa -P '' -f ~/.ssh/id_rsa
$ cat ~/.ssh/id_rsa.pub >> ~/.ssh/authorized_keys
$ ssh localhost

HDFS 포맷

$ hdfs namenode -format

데몬의 시작 및 종료

$ start-dfs.sh                                  # HDFS 데몬 시작
$ start-yarn.sh                                 # YARN 데몬 시작
$ mr-jobhistory-daemon.sh start historyserver   # 맵리듀스 데몬 시작

실행중인 데몬을 확인하려면 다음 명령어를 사용하면 된다.

$ jps
2755 NameNode
3126 ResourceManager
3225 NodeManager
2858 DataNode
3309 Jps

다음 링크에서 웹 UI로도 확인할 수 있다.

네임 노드 웹 UI : http://localhost:50070/
리소스 매니저 웹 UI : http://localhost:8088/
히스토리 서버 웹 UI : http://localhost:19888/

$ stop-dfs.sh                                   # HDFS 데몬 종료
$ stop-yarn.sh                                  # YARN 데몬 종료
$ mr-jobhistory-daemon.sh stop historyserver    # 맵리듀스 데몬 종료

다음과 같이 한 번에 모든 데몬을 시작 및 종료할 수 있다.

$ start-all.sh    # 전체 데몬 시작
$ stop-all.sh     # 전체 데몬 종료

사용자 디렉터리 생성

$ hadoop fs -mkdir -p /user/$USER

[하둡 완벽 가이드] Chapter 03. 하둡 분산 파일시스템(1)

peachh — Wed, 7 Sep 2022 01:26:08 +0900

HDFS

HDFS는 Hadoop Distributed File System의범용 하드웨어로 구성된 클러스터에서 실행되고 스트리밍 방식의 데이터 접근 패턴으로 대용량 파일을 다룰 수 있도록 설계된 분산 파일시스템이다.

범용 하드웨어 : 노드 장애 발생 확률이 높은 범용 하드웨어에서 문제없이 실행되며 장애 발생을 사용자가 알 수 없도록 작업을 수행함
스트리밍 방식의 데이터 접근 : 데이터를 한 번 쓰고 여러 번 읽음, 첫 번째 레코드를 읽는 시간보다 전체 데이터셋을 읽는 시간이 더 중요함
대용량 파일 : 수백 MB, GB, TB를 넘어 PB 크기의 데이터를 저장
분산 파일시스템 : 네트워크로 연결된 여러 머신의 스토리지를 관리

블록

블록 크기는 한 번에 읽고 쓸 수 있는 데이터의 최대량이다. 보통 블록의 크기는 다음과 같다.

파일시스템 → n KB
디스크 → 512 bytes
HDFS → 128 MB 탐색 비용을 최소화하기 위해 블록의 크기가 큼

파일 크기가 블록 크기보다 작은 경우

단일 디스크를 위한 파일시스템 → 하나의 블록 전체를 점유
HDFS → 파일 크기 만큼만 점유

블록 추상화의 이점

파일 하나의 크기가 단일 디스크의 용량보다 커질 수 있다. 파일을 하나의 디스크에만 저장할 필요가 없기 때문이다.
스토리지의 서브시스템을 단순화할 수 있다. 블록이 고정 크기이므로 저장하기 위한 디스크 용량만 계산하면 되기 때문에 스토리지 관리가 단순해진다. 그리고 파일의 메타데이터와 데이터를 함께 저장하지 않아도 된다.

블록 수준에서 파일시스템의 유지 관리를 위한 도구

df : 디스크 여유 공간 확인
fsck : 파일시스템 일관성 확인 및 대화형 복구 수행

네임 노드와 데이터 노드

HDFS는 하나의 네임 노드와 여러 개의 데이터 노드로 구성되며 이는 Master-Worker 패턴으로 동작한다.

클라이언트 (Client)

사용자를 대신해 네임 노드와 데이터 노드 사이에서 통신하고 파일시스템에 접근함
POSIX와 유사한 파일시스템 인터페이스 제공함

네임 노드 (Name Node)

파일시스템의 메타데이터 유지 : Namespace Image와 Edit Log라는 두 종류의 파일로 로컬 디스크에 영속적으로 저장함
파일의 블록이 저장된 데이터 노드 파악 : 시스템 시작 시 데이터 노드로부터 정보를 받음 (영속적으로 저장 X)

데이터 노드 (Data Node)

실제 데이터를 저장 및 탐색
저장하고 있는 블록의 목록을 주기적으로 네임 노드에게 알림

보조 네임 노드 (Secondary Name Node)

네임 노드에 장애가 발생하면 파일시스템이 동작하지 않기 때문에 장애 대비용으로 존재함
Edit Log 가 너무 커지지 않도록 주기적으로 Namespace Image와 Edit Log를 병합하여 최신 버전의 Namespace Image를 생성함
장애 발생에 대비해 Namespace Image의 복제본을 보관함 (시간차 복제로 인한 손실은 불가피함)

블록 캐싱

자주 접근되는 블록은 Off-Heap 블록 캐시라는 데이터 노드의 메모리에 명시적으로 캐싱할 수 있다.

잡 스케줄러 : 블록이 캐싱된 데이터 노드에서 태스크를 실행할 수 있음
사용자나 애플리케이션 : 캐시 풀(Cache Pool)에 캐시 지시자(Cache Directive)를 추가하여 특정 파일을 캐싱할 수 있음

페더레이션

HDFS 페더레이션(Federation)을 활용하면 각 네임 노드가 파일시스템의 네임스페이스를 나누어 관리하는 방식으로 새로운 네임 노드를 추가할 수 있다. 즉, 페더레이션은 네임 노드의 확장성 문제를 해결하기 위한 방안이다.

페더레이션을 적용하면 각 네임 노드는 네임스페이스 볼륨(Namespace Volume)과 블록 풀(Block Pool)을 관리한다.

네임스페이스 볼륨(Namespace Volume) : 네임스페이스의 메타데이터를 구성함 (네임 노드마다 독립 O)
블록 풀(Block Pool) : 네임스페이스에 포함된 파일의 전체 블록을 보관함 (네임 노드마다 독립 X)

클라이언트는 페더레이션 클러스터에 접근하기 위해 파일 경로와 네임 노드를 매핑한 클라이언트 측 마운트 테이블을 이용한다. 이는 환경 설정에서 ViewFileSystem과 viewfs://URI를 사용해서 관리할 수 있다.

고가용성

데이터 손실을 방지하기 위해 네임 노드의 메타데이터를 다수의 파일시스템에 복제하는 방식과 보조 네임 노드를 사용하여 체크포인트를 생성하는 방식을 조합하여 사용할 수 있다. 하지만 여전히 네임 노드는 단일 고장 지점(Single Point Of Failure, SPOF)이다.

네임 노드에 장애가 발생하면 새로운 네임 노드를 구동하고 요청을 처리하기 위한 준비를 마칠 때까지 아무런 처리도 하지 못한다. 대형 클러스터에서는 30분 이상 소요되기도 한다.

이 문제를 해결하기 위해 HDFS 고가용성(High Availability, HA)은 Active-Standby 상태의 네임 노드 쌍으로 구현된다. Active 네임 노드에 장애가 발생하면 Standby 네임 노드가 그 역할을 이어받아 큰 중단 없이 요청을 처리할 수 있다. (1분 정도 소요)

고가용성을 지원하기 위해 HDFS의 구조가 약간 변경된다.

Edit Log를 공유하기 위해 고가용성 공유 스토리지를 사용함 (NFS or QJM)
데이터 노드는 블록 정보를 두 개의 네임 노드에게 보고함 (네임 노드의 메모리에 저장됨)
Standby 네임 노드는 Secondary 네임 노드의 역할을 포함함

장애 복구와 펜싱

장애 복구 컨트롤러는 Standby 네임 노드를 활성화시키는 전환 작업을 관리하며, 단 하나의 네임 노드만 Active 상태에 있는 것을 보장하기 위해 주키퍼로 구현된다.

우아한 장애 복구(Graceful Failover) : 정기적인 유지 관리를 위해 관리자가 수동으로 초기화함
우아하지 않은 장애 복구(Ungraceful Failover) : 장애가 발생한 네임 노드가 중단됐다는 것을 확신하기 어려움

고가용성을 위해 기존의 Active 네임 노드가 시스템을 손상시키지 않도록 하기 위해 펜싱(fencing) 메소드가 제공된다. 공유 스토리지 접근 제한, 원력으로 네트워크 포트 차단 등 다양한 펜싱 메커니즘이 있다.

하둡 설치하기

peachh — Fri, 26 Aug 2022 03:07:10 +0900

1. 하둡 위키 페이지에서 필요한 자바 버전 확인

설치하려는 하둡 버전에 따라 필요한 자바 버전을 확인한다.

$ java version

설치된 자바 버전을 확인한다.

2. 하둡 배포 페이지에서 배포판 바이너리 다운로드

원하는 버전의 binary 를 클릭하면 아래 화면으로 이동한다.

링크를 클릭해서 다운로드 한다.

3. 압축 풀기

$ tar xzf hadoop-3.3.4.tar.gz     # 다운로드한 파일

4. 환경 변수 설정

$ export HADOOP_HOME=/Users/jimin/Downloads/hadoop-3.3.4    # 하둡이 설치된 경로
$ export PATH=$PATH:$HADOOP_HOME/bin:$HADOOP_HOME/sbin

5. 하둡 버전 확인

$ hadoop version

6. 환경 설정

하둡은 세 가지 동작 모드가 있다.

독립 모드 (standalone) : 데몬이 실행되지 않고 모든 것이 단독 JVM 내에서 실행된다.
의사 분산 모드 (pseudo-distributed) : 모든 하둡 데몬을 로컬 머신에서 실행한다.
완전 분산 모드 (fully-distributed) : 하둡 데몬을 여러 대의 머신으로 구성된 클러스터에서 실행한다.

원하는 동작 모드에 따라 설정 파일을 수정해야 한다. 설정 파일은 /etc/hadoop 디렉터리에 있으며 기본적으로 독립 모드에 맞춰져 있다.

[하둡 완벽 가이드] Chapter 02. 맵리듀스

peachh — Thu, 25 Aug 2022 01:38:46 +0900

단일 머신에서 멀티 스레드를 활용한 병렬 처리

1. 작업을 동일한 크기로 나누기 어려움
처리해야 할 파일마다 크기가 다른 경우, 결국엔 가장 큰 파일을 처리하는 시간에 의해 전체 처리 시간이 결정된다.
최대한 동일한 크기로 나누고 싶다면 각 파일을 고정 길이의 청크 단위로 나누어 처리할 수는 있다.

2. 병렬 처리된 결과를 병합하는 데 더 많은 처리가 필요할 수 있음
파일을 병렬 처리하여 얻은 중간 결과를 모아서 추가적인 처리를 해야만 최종 결과를 얻을 수 있다.

3. 단일 머신의 처리 능력에 한계가 있음
만약 단일 머신에서 여러 개의 프로세서로 처리할 수 있는 최적의 수행 시간이 20분이라면 그 이상 빨라질 수는 없다.

→ 병렬 처리는 매우 복잡하므로 하둡과 같은 프레임워크를 활용하는 것이 좋다.

하둡을 활용한 병렬 처리

하둡이 제공하는 병렬 처리를 이용하기 위해 요구사항을 맵리듀스 작업으로 표현해야 한다. 맵리듀스는 맵 단계와 리듀스 단계로 구분되며, 프로그래머가 맵 함수와 리듀스 함수를 작성해야 한다. 각 단계의 입력과 출력은 key-value 쌍이며 타입은 상관없다.

[예제] 날씨 데이터를 가지고 연도별 최고 기온 구하기

원본 데이터가 맵 함수의 입력으로 주어진다.
하나의 레코드는 연도, 위도, 경도, 기온, 풍향 등을 포함한다.
맵 단계에서 주어진 입력에서 연도와 기온을 추출한다. + 잘못된 레코드 필터링
맵 단계의 결과로 <연도, 기온> 쌍들이 반환된다.
<2000, 24> <2001, 14> <2000, 32> <2000, 18> <2001, 22>
셔플 단계에서 같은 key를 가지는 데이터를 모으고 key를 기준으로 정렬한다. (key = 연도)
<2000, [24, 32, 18]> <2001, [14, 22]>
리듀스 단계에서 연도별 최고 기온을 구한다. ► 최종 결과
<2000, 32> <2001, 22>

맵리듀스

job은 클라이언트가 수행하는 작업의 기본 단위이며 입력 데이터, 맵리듀스 프로그램, 설정 정보로 구성된다. job은 map 태스크와 reduce 태스크로 나누어 실행되고, 각 태스크는 YARN을 통해 스케줄링된다.

하둡은 입력 데이터를 split이라는 고정 크기의 조각으로 분리한다. split의 크기가 작을수록 부하분산 효과가 좋지만 크기가 너무 작으면 관리를 위한 오버헤드 때문에 실행시간이 증가하게 된다. 보통 HDFS 블록의 기본 크기인 128 MB가 적당하다고 한다.

하둡은 split 마다 하나의 map 태스크를 생성하고 record 단위로 처리한다. 특정 노드의 태스크가 실패하면 다른 노드에 재할당하여 다시 실행한다.

하둡은 입력 데이터가 있는 노드에서 map 태스크를 실행할 때 가장 빠르다. 이를 데이터 지역성 최적화라고 한다. 이 방식은 네트워크 자원 사용을 최소화할 수 있다. 데이터의 복제본이 저장된 모든 노드에서 map 태스크를 실행할 수 없는 경우, 동일 랙이 다른 노드에서 map 태스크를 실행할 수도 있다. 이것도 불가능하다면 네트워크 전송을 통해 외부 랙에서 map 태스크를 실행해야 한다.

map 태스크의 결과는 HDFS가 아닌 로컬 디스크에 저장된다. map 단계의 결과는 reduce 단계에서 최종 결과를 생성하기 위한 중간 결과이므로 job이 완료된 후에는 버려지기 때문이다.

reduce 태스크는 모든 map 태스크의 결과를 입력으로 받는다. reduce 태스크의 결과는 로컬 노드의 HDFS에 저장되고, 외부 랙에 복제본을 저장한다. reducer가 여러 개이면 reducer만큼 파티션을 생성하고 mapper의 결과를 각 파티션에 분배한다. 주로 key를 해싱하여 분배한다. 모든 처리를 완전히 병렬로 처리하는 경우 reducer가 없을 수도 있다.

하둡 클러스터에서 job이 사용하는 네트워크 대역폭은 한계가 있기 때문에 mapper의 결과를 reducer로 전송하기 위한 네트워크 사용을 최소화 하기 위해 combiner 함수를 사용할 수 있다. reduce 함수를 combiner 함수로 재사용할 수 있다. combiner 함수는 적용하는 데에 제약이 있다. 예를 들어 max, min 과 같은 처리는 combiner 함수를 적용해도 최종 결과가 바뀌지 않지만 mean 의 경우엔 최종 결과가 달라지기 때문에 combiner 함수를 적용하기 어렵다.

자바의 맵리듀스

맵 단계 : Mapper 클래스의 추상 메소드 map()을 정의하여 구현한다.
리듀스 단계 : Reducer 클래스의 추상 메소드 reduce()를 정의하여 구현한다.
Job : Job 클래스로 맵리듀스를 수행할 Job을 정의한다.
- 하둡 클러스터에서 Job을 실행하기 위해서는 jar 파일을 생성하여 배포해야 한다.
- 지정한 출력 파일 경로가 미리 존재한다면 에러가 발생하고 Job이 실행되지 않는다. (데이터 유실 방지)
- 지정한 출력 타입은 매퍼 및 리듀서가 반환하는 것과 반드시 일치해야 한다. (컴파일 시점에 확인되지 않으므로 주의)

하둡 스트리밍

하둡과 사용자 프로그램 사이의 인터페이스이다. 유닉스 표준 스트림을 사용하기 때문에 표준 입출력이 가능한 다양한 언어를 사용해 맵리듀스 프로그램을 작성할 수 있도록 한다.

[하둡 완벽 가이드] Chapter 01. 하둡과의 만남

peachh — Wed, 24 Aug 2022 00:43:51 +0900

데이터 저장소와 분석

하드 디스크의 용량은 크게 증가했지만 데이터 IO 속도는 그렇지 못했다.
하지만 같은 양의 데이터를 100개로 나눠서 저장하고 공유하여 병렬로 작업한다면 IO 속도를 줄일 수 있다.
이때 고려해야 할 문제들이 있다.

1. 하드웨어 장애
하드웨어를 많이 사용할수록 장애 발생 확률도 높아진다.
데이터 손실을 방지하기 위해 복제본을 만들어 여러 곳에 보관할 수 있다.

2. 분산된 데이터 병합
데이터 분석을 위해 100개로 나눠서 저장한 데이터를 병합해야 한다.
맵리듀스는 데이터 IO를 key-value 쌍의 계산으로 변환한 추상화된 프로그래밍 모델을 제공한다.

하둡의 처리 패턴

하둡 에코시스템은 분산 컴퓨팅과 대규모 데이터 처리를 위한 기반 시설이다.
최초의 하둡은 일괄 처리를 위해 만들어졌으나 시간이 흐르며 다양한 처리 패턴이 생겨났다.

일괄 처리 - 맵리듀스는 한 번의 쿼리로 전체 데이터셋을 처리할 수 있는 일괄 질의 처리기이다.
반복 처리 - Spark는 메모리에 저장된 임시 데이터셋을 탐색하여 작업을 수행할 수 있으므로 매번 디스크 IO를 수행하지 않아도 된다.
스트림 처리 - 스트리밍 시스템(Storm, Spark Streaming, Samza 등)은 실시간으로 실행되고 경계가 없는 스트림 데이터를 분산 계산하여 그 결과를 하둡 저장소나 외부 시스템에 전송한다.
대화형 SQL - 장기 실행 전용 데몬 (Impala) 또는 컨테이너를 재사용하는 분산 쿼리 엔진(Tez based Hive)을 사용한다.
검색 - 검색 플랫폼인 Solr는 하둡 클러스터에서 실행되어 HDFS에 문서를 인덱싱하여 저장하고 검색 쿼리를 제공한다.

RDBMS vs 맵리듀스

	RDBMS	맵리듀스
데이터 크기	GB	PB
데이터 유형	정형	정형, 반정형, 비정형
접근 방식	대화형, 일괄 처리	일괄 처리
IO	여러 번 읽고 쓰기	한 번 쓰고 여러 번 읽기
트랜잭션	ACID	-
구조	쓰기 기준 스키마	읽기 기준 스키마
무결성	높음	낮음
확장성	비선형	선형