분산 파일 시스템 , 하둡

리액트 초기 세팅에 yarn이라는 것을 설치하길래 이것이 무엇인가 검색해보니 분산 파일 시스템과 관련이 있다고 나와

마침 나중에 공부하려고 했었는데 좋은 기회라고 생각이 들어 좀 이것저것 읽고 정리하려고 한다.

 

하둡이 탄생하게 된 배경

빅데이터 환경에서 만들어지는 데이터는 규모와 크기가 엄청 크기 때문에
기존의 파일 시스템 체계를 그대로 사용한다면 시간이 많이 들고, 처리 하는데 비용이 크게 든다.

그래서 2대 이상의 컴퓨터를 이용해 작업을 분배하고, 다시 조합하며, 일부 작업에 문제가 생긴다면

해당 부분만 재 처리 할 수 있는 분산 컴퓨팅 환경을 요구합니다.

 

하둡 이전에도 기존의 데이터 베이스에서 분산의 개념을 추가한 형태로 구현된 Appliances라는 도구들이 있었습니다.

하지만 분산 시스템 설계에 대해 이해도가 높지 않아 잦은 '노드 실패'가 발생했고 회복을 위해 여러 백업 장비들이

추가가 됐었습니다. 그래서 고비용의 하드웨어를 필요로 했습니다.

 

하둡의 탄생

더그 컷팅과 마이크 카페렐라라는 프로그래머가 텍스트 검색 엔진을 만들고

이에 대한 Parser와 Crawler로서 너치(Apache Nutch)라는 프로젝트를 진행했다.

이 너치에서 가져오는 방대한 데이터를 처리하기 위해 구글 파일 시스템(GFS)와 맵-리듀스(Map-Reduce)논문을 기초로

하둡 분산 파일 시스템(HDFD)를 너치에 이식했습니다.

 

하둡 분산 파일 시스템

대용량 파일을 저장하고 처리하기 위한 파일 시스템.

한 서버에서 동작하는 것이 아닌 여러 서버에 설치되어 서비스된다.

별도 스토리지는 필요하지 않고, 일반 리눅스에 탑재되어 있는 로컬 디스크를 이용해

확장이 가능한 유연한 구조를 가진다.

 

주요 목적

1. 잦은 노드 실패의 해결.

2. 워크로드 최적화

위 목적을 위해 아래와 같은 특징을 가지고 있다.

 

특징

1. 유저 스페이스 파일 시스템(FUSE)

파일 시스템 코드가 커널 스페이스 외부에서 실행. ext3와 같이 마운트할 필요는 없지만,

APP이 특정 유저스페이스 파일 시스템과 호환이 가능해야 한다.

관련 부분으로 HDFS 사용 시 모든 Replication이 HDFS APP레벨에서 처리되기 때문에 RAID 설정을 꺼야 한다.

2. 분산 파일 시스템

하나의 디스크를 사용하거나, 노드의 제약을 벗어나기 위해 클러스터의 각 노드는 완전한 파일시스템의 일부만 저장.

따라서 노드를 추가하기만 하면 전체 파일 시스템의 크기를 키울 수 있음

3. Fault-tolerance

일부가 고장나도 자동으로 고쳐져서 시스템 전체에 영향을 주지 않음을 의미한다.

4. 큰 파일 대상으로 IO 연산과 블록 사이즈 구현

5. append에 최적화

데이터 처리 워크로드 분석할 때 대부분 작업이 append로 이루어진다.

또한 랜덤 write는 존재하지 않음. 그리고 한 번 쓰이면 대부분 sequential 하게 데이터를 읽어서 사용한다.