[Hadoop] Hadoop & HDFS

하둡이란?

하둡은 대용량 데이터를 분산 처리 할 수 있는 자바 기반의 오픈 소스 프레임워크이다. 하둡은 구글이 논문으로 발표한 GFS(Google File System)과 맵리듀스(MapReduce)를 2005년 더그커팅이 구현한 결과물이다. 하둡은 분산시스템인 HDFS(Hadoop Distributed File System)에 데이터를 저장하고, 맵리듀스를 이용해 데이터를 처리한다.

하둡은 여러 대의 서버에 데이터를 저장하고, 저장된 각 서버에서 동시에 데이터를 처리하는 방식이다. 하둡은 기존의 RDBMS(Oracle, MS-SQL, MySQL 등)을 대치하는 것이 아니다. 즉 트랙잭션이나 무결성을 보장해야하는 데이터 처리에는 적합하지 않다. 하둡은 배치성으로 데이터를 저장하고 처리하는데 적합한 시스템이다.

쇼핑몰에서 회원가입이나, 결제진행등은 모두 트랜잭션이나 무결성을 보장해야 한다. 이런 것들을 하둡으로 처리하는 것이 아니라, 회원이 관심있게 보는 물품들이나, 이동경로, 머무르는 시간 등 배치성으로 저장되는 데이터에 적합하다. 이런 것들을 매번 비용이 비싼 RDBMS에 저장하면 낭비요소이다. 그러므로 하둡은 RDBMS와 경쟁하는 것이 아닌 RDBMS와 협력하는 것이라 볼 수 있다.

HDFS

HDFS는 Hadoop Distributed File System의 약자이다.
수십 테라바이트 또는 페타바이트 이상의 대용량 파일을 분산된 서버에 저장하고, 그 저장된 데이터를 빠르게 처리할 수 있게 하는 파일시스템이다. 또한 저사양의 서버를 이용해서 스토리지를 구성할 수 있어 기존의 대용량파일시스템(NAS, DAS, SAN 등)에 비해 장점을 가진다. HDFS는 블록 구조의 파일 시스템이다. 파일을 특정 크기의 블록으로 나누어 분산된 서버에 저장된다. 블록크기는 64MB에서 하둡2.0부터는 128M로 증가되었다.

HDFS 특징

1. 대용량 데이터를 범용 서버만으로 처리 가능

• 데이터 파일 크기나 개별 장비의 파일 시스템 크기에 제한이 없음

2. 용량 확장성

• 데이터가 증가하면 노드를 추가로 처리가능

3. 높은 처리량 실현

• 데이터의 부분 수정 불가, 랜덤 접근 불가, 큰 블록 처리 -> 고속 처리로 이어짐

4. 슬레이브 노드의 일부가 고장 나도 데이터 손실을 방지 가능

• 복수개의 노드에 데이터 복제 유지

HDFS 설계 목표

1. 장애 복구

HDFS는 장애에 있어 상당히 유연한 대처가 이루어져야 하므로 장애 복구를 할 수 있도록 설계가 되어져야 한다.

• 디스크 오류로 인한 데이터 저장 실패 및 유실과 같은 장애를 빠른 시간에 감지 및 대처
• 데이터를 저장하면 복제 데이터도 함께 저장해서 데이터 유실 방지
• 분산 간 서버 간 주기적인 상태 체크(Heart Beat)

2. 스트리밍 방식의 데이터 접근

HDFS에 파일 저자 및 조회를 위해서는 스트리밍 방식으로 데이터에 접근하는 방식을 취해야 하기 때문에 HDFS는 스트리밍 방식의 데이터 접근을 목표로 설계 되어져 있고 뿐만 아니라 배치 작업과 높은 데이터 처리량을 위해서도 스트리밍 방식을 사용한다.

3. 대용량 데이터 저장

하둡의 본질적인 목적인 대용량 데이터를 처리하기 위해 우선 대용량 데이터를 저장하는 기능이 있어야 하기 때문에 높은 데이터 전송 대역폭, 하나의 클러스터에서 수백 대의 노드를 지원한다. 그리고 하나의 인스턴스에서 수백만 개 이상의 파일을 지원한다.

4. 데이터 무결성

HDFS는 한번 저장한 데이터를 수정할 수 없고 읽기만 가능하기 때문에 파일 이동, 삭제, 복사할 수 있는 인터페이스만 제공, 그렇기 때문에 데이터에 대한 무결성을 가진다.

네임노드와 데이터노드

HDFS는 네임노드(마스터)와 데이터노드(슬레이브)로 구현되어 있다.
네임노드(NameNode)는 다음과 같은 핵심기능을 수행한다.

메타데이터관리 : 파일 시스템을 유지하기 위한 메타데이터를 관리

데이터노드 모니터링 : 데이터노드는 네임노드에게 3초마다 하트비트를 전송한다. 네임노드는 이를 이용하여 데이터노드의 실행상태와 용량을 체크한다. 하트비트를 전송하지 않는 데이터노드는 장애서버로 판단한다.

블록관리 : 장애가 발생한 데이터노드의 블록을 새로운 데이터노드에 복제한다. 용량이 부족하다면 여유가 있는 데이터노드에 블록을 옮긴다.

클라이언트 요청접수 : 클라이언트가 HDFS에 접근하려면 반드시 네임노드에 먼저 접속해야 한다. HDFS에 파일을 저장할 경우 기존 파일의 저장여부와 권한 확인 절차를 거쳐 저장을 승인한다.

데이터노드는 클라이언트가 HDFS에 저장하는 파일을 로컬 디스크에 유지한다. 이 때 파일은 두 가지로 저장되는데 하나는 실제 저장되는 로우데이터이고 다른 하나는 체크섬이나 파일생성일자 같은 메타데이터가 저장된 파일이다.

HDFS에 파일저장

1. 클라이언트에서 먼저 네임노드와 통신과정을 통해 스트림(DFSOutputStream)을 생성한다.
2. 생성된 스트림을 통해 클라이언트에서 파일을 각 데이터노드에 전송한다. 이 때 저장할 파일을 패킷단위로 나누어서 전송한다.
3. 파일전송이 완료되면 클라이언트에서는 네임노드에서 얻은 스트림을 close하면 남은 모든 패킷이 Flush 된다.
4. 클라이언트에서 네임노드의 complete 메소드를 호출해서 정상적으로 저장되었다면 True가 반환된다. 그러면 파일저장이 완료된 것

HDFS에 파일읽기

1. 클라이언트에서 네임노드의 입력스트림객체(DFSInputStream)를 통해 스트림객체를 생성한다.
2. 생성된 스트림객체를 이용하여 기본 블록의 10배수만큼 조회한다.
3. 클라이언트 스트림객체에서 블록리더기 생성하는데 블록이 저장된 데이터노드가 같은 서버에 있다면 로컬블록리더기(BlockReaderLocal)를 생성하고, 원격에 있다면 원격블록리더기(RemoteBlockReader)를 생성한다.
4. DFSInputStream은 파일 모두 읽을 때까지 블록을 조회한다. 모두 읽었다면 close를 통해 닫아주어야 한다.

보조네임노드(Secondary Name Node)

네임노드가 메타데이터를 메모리에 담고 처리하는데 만약 서버가 리부팅되면 사라질 수 있다. HDFS는 이러한 점 때문에 editslog와 fsimage라는 두 개의 파일을 생성한다. editslog는 HDFS의 모든 변경 이력을 저장하고, fsimage는 메모리에 저장된 메타데이터의 파일 시스템 이미지를 저장한 파일이다. 그런데 만약 editslog가 커지면 fsimage를 만드는데 시간이 많이 소요되게 된다.
이러한 문제를 해결하기 위해서 보조네임노드(Secondary Name Node)가 있다. 보조네임노드는 fsimage를 갱신해준다. 이러한 작업을 체크포인트라고 한다. 그래서 보조네임노드를 체크포인팅 서버 라고도 한다. 보조네임노드는 네임노드의 백업이 아니고 단순히 fsimage를 줄여주는 역할만 한다. fsimage가 너무 커서 네임노드가 메모리에 로딩되지 못 하는 경우를 예방하기 위해 사용되는 것이다.

원문 : https://yookeun.github.io/java/2015/05/24/hadoop-hdfs/

https://nathanh.tistory.com/91
https://tourspace.tistory.com/223
https://kadensungbincho.tistory.com/30