파일 구조를 관리하는 하나의 Name Node(마스터)와 복수 개의 Data Nodes(슬레이브)
c:\Users\hywckw\desktop\a.txt 과 같은 파일 경로는 실제 정보가 아닌 파일의 이동 경로를 보여주는 메타 정보.
슬레이브는 a.txt의 내용을 보여준다.
Secondary NameNode는 주기적으로 Name Node의 내용을 백업(snapshot)한다.
MapReduce
전체 job을 관리해주는 하나의 job tracker(마스터)와 MapReduce Task를 실행 및 종료하는 복수 개의 task Tracker(슬레이브)가 존재한다.
물리적인 클리스터에 name Node/job tracker가 같이 있고, Data Node/Task Tracker가 함께 있다.
Development of Hadoop
Doug Cutting이 Nutch 크롤, 컴색 패키지에 구글 페이퍼를 기반으로 한 HDFS/MapReduce 프레임워크를 추가하면서 시작되었다.
구글 논문으로 부터 시작했다.
one is GFS(Google File System), another is MapReduce
야후 검색팀 조인, 20 노트 클러스터 셋업
hadoop이 Nutch에 떨어져나와 아파치 톱레벨 프로젝트로 이어짐
야후에서 1000 노드 하둡 클러스터를 프로덕션에 사용
2012년 이후 하둡 생태계가 활발히 커져가고 있다.
Hadoop 배포판
대표적으로 클라우데라, 홀튼 웍스, MapR을 만들었으며 오픈소스이고 개인이 사용 시 무료.
Haddop license
아파치 라이센스
free SW license
재배포 및 상업적 이용 가능
model
하둡 자체는 아파치 소프트 웨어 재단의 소유물
4가지 형태의 notribution이 가능
사용자의 경우, download -> install -> vun(bug, new feature) -> developement
contributer, 패치 생성, bug report, write document
commiter, contributer의 작업 반영 여부 결정
프로젝트 관리 커미티(PMC), new release, commiter(선정투표)
problem of Hapdoop
too many version, weak surport because of OPEN SOURCE
3rd party 배포판을 대체로 사용
셋업과 사용이 쉽지 않다
스킬 셋을 가진 사람이 별로 없음
소규모 작업의 경우 필요 없음.
HDFS
The Google Filesystem이란 논문을 바탕으로 작성된 파일 시스템
large file을 여러 블록으로 나눠 저장한다(기본 64mb)
하드웨어 고장에 견고하다.
한 블록을 3군데에 저장하며, 저장 시 같은 rack에 있는 서버들에 두 개를 저장하고 다른 하나는 다른 rack에 있는 서버에 저장한다.
Write Once Read Many
large data의 경우, 쓰기는 한 번만 일어나고, 읽기가 여러번 일어난다. (update는 하지 않는다.)
이런 특징을 바탕으로 한 데이터 블럭의 사이즈를 64MB로 설정하였다.
우리가 사용하는 window/linux의 경우 기본 사이즈가 4kb이다. 이는 64MB를 사용했을 경우 수정 시 1MB의 파일일지라도 64MB 전체를 수정해야 하는 낭비가 있기 때문이다.
하둡의 데이터는 update는 불가능하지만, append는 가능하다. 만일 update하려고 하면 파일 전체를 새로 써야 한다.
스트리밍 데이터 엑세스
배치 잡에 최적화되어 있다.
MapReduce나 HBase와 같은 기스템의 기본 구성 블록으로 사용한다.
계층 구조의 파일 시스템을 제공한다.
HDFS의 구조
Name node가 data node들을 관리하는 전체를 두고 HDFS cluster라고 한다.
Name Node
HDFS마다 단 하나만 존재한다.
마스터 로드로서 파일들의 메타 정보들을 관리하고, 실제 데이터는 다수의 DATA Node에 분산 저장한다.
파일은 블록단위(64MB)에 나누어 저장되고, 세 군데 Data Node에 중복 저장된다
블록 크기도 hdfs-site.xml의 dfs.block.size 파라미터로 저장할 수 있다.
rack awareness : 중복 저장 시 rack 위치를 유념하여(3 copy) 한 rack에 모든 복제 블록이 놓이지 않도록 한다.
data node들의 지속적인 통신(Heartbeat)
데이터를 중복해서 얼마나 저장할 건지.
얼마나 한번씩 통신할 건지.
A single point of failure
네임 노드가 메타 데이터를 담고 있기 때문에 failure 혹은 네트워크가 단절이 되면, 이 정보들을 엑세스할 수 없기 때문에 접근 방법이 사라지게 된다.
HDFS Heartbeat
일정 시간동안 통신이 되지 않으면 그 노트를 dead노드로 분류하고 다른 alive node에 복제하여 저장해 3copy를 유지한다.
노드가 하나 죽게 되면 그 노드에 있는 data들이 죽기 때문에 일시적으로 2-copy가 된다. 따라서 다른 active한 노드들에게 할당하여 3-copy로 만든다.
Data 읽기
client는 data를 읽고자 쓰고자하는 사용자, 파일을 읽고자하면 path정보를 알고 있으며 이 정보를 namenode와 통신하여 해당 파일의 데이터 노드의 위치 리스트를 모두 얻어 온다.
이 데이터를 수신하게 되면 datanode를 차례데로 읽을 수 있다.
Data 쓰기
클라이언트는 HDFS의 네임노드에게 PATH 정보(로컬 파일 시스템_를 바탕으로 파일 생성 요청을 전송.
네임노드는 replication factor(3)만큼 데이터 노드와 블럭 id를 클라이언트에게 전송하게 된다.
클라이언트는 첫번째 데이터 노드에 데이터를 쓰면서, 2번과 3번에 쓰라고 정보를 전달한다. (1번 노드 -> 2번 노드 -> 3번 노드)
첫번째 데이터 노드는 데이터를 복제 받으며 두번 째 데이터 노드로 복제를 시작한다.
마지막 노드에서 복제가 완료되면 데이터 블록의 생성이 완료된 것으로 간주. 해당 프로세스를 replication piplelining이라고 한다.
1. users -> sameerp -> data -> part-0 {1, 3}에 2-copy가 되었으며 해당 파일의 이름은 1과 3번이다. 2. users -> sameerp -> data -> part-2 {2, 4, 5}에 2-copy가 되었으며 해당 파일의 이름은 2, 4과 5번이다.
HDFS 액세스
HDFS 라이브러러리를 이용하거나 하둡 셀 커맨드를 이용하여 엑세스할 수 있다.
HDFS 자바 라이브러리
Hadoop 셀 커맨드
Hadoop DFS 어드민 (ex. format)
로컬에서 작업이 이루어지는 게 아니라 원격으로 remote Hadoop Cluster에서 작업이 이루어진다.
MapReduce
MapReduce: simplicfied data processing on large cluster란 논문을 바탕으로 작성된 분산 처리 시스템
Feature of MapReduce Framwork
code/program을 작성하는 것.
데이터가 있는 노드로 코드를 전송한다.
key-value 형태로 계산이 진행 뒤 valuable information
Shared Nothing architecture
서버들 사이에 공유하는 것이 하나도 없다.
physic한 resource를 공유하지 않는다.
다만 네트워크로 연결되어 통신하는 아키텍쳐이다
모든 프로세서는 map과 reduce.
map 프로세서들끼리, reduce 프로세서 끼리도 공유하는 것이 없음. map과 reduce 사이에는 map에서 전송되는 정보만 있을 뿐이다.
data locality를 최대한 화용
2-copy in one rack, 1-copy in another rack.
하나의 데이터에 문제가 생기면 네트워크 상 근접한 서버에 우선 연결함.
개괄적인 그림
1. client에서 job을 표현하는 프로그램을 표현. 2. 이후 job Tracker에게 요청을 하게 됨. 3. job tracker이 스케줄링하여 여유 있는 서버들에게 map을 우선 보낸 뒤, reduce를 보냄. 4. reduce 작업이 끝나면 html파일로 저장이 된다.
job Tracker
MapReduce 프레임워크의 마스터로 한 클러스터에 하나만 존재한다.
nameNode와 마찬가지 a single point a failure에 취약하다.
프레임 웍에 실행되는 모든 job들의 실행을 관리한다.
사용자로부터 하둡 잡 실행을 요청받은 뒤 task tracker들로 job을 실행할 수 있도록 한다. (by job 스케줄러)
테스크가 종료될 때까지 관리, 실패시 다른 task tracker에 그 테스크를 다시 실행
보통 job tracker는 HDFS의 마스터인 Name Node와 같은 서버에 위치한다.
task tracker 역시 HDFS의 DataNode들과 같이 공존한다.
하둡 쉘 커맨드와 웹 인터페이스를 통해 job/tasker의 상태를 확인할 수 있다.
task tracker는 주기적으로 job tracker에게 상태를 보고한다.
연락이 닿지 않는 노드는 다른 노드로 데이터를 이전한다.
실행 중인 테이크의 상태
mapper(실행중) 경우, 입력 레코드의 처리 퍼센트
reducer
셔플링 -> 33%
소팅 -> 66%
이후 -> reducer의 처리 퍼센트 * 0.36 + 66%
job & task
job은 MapReduce 프로그램. job tracker가 관리한다.
job은 하나 이상의 mapper와 하나 이상의 reducer로 구성되며, task라 불림
각각의 task는 task tracker에 의해 관리되며, 각 task는 별개의 JVM에서 실행.
실패한 TASK는 다른 노드에서 재시도
Speculative Execution : task tracker가 완전히 실패는 아니지만 너무 느리게 도는 경우(preformance가 낮은 경우), 그 일에 대해 보상하기 위해 다른 서버에 같은 일을 하게 함.
하나 이상의 job이 엮여 실제 원하는 일을 수행하는 경우가 대부분이며 이를 Hadoop job Chaining이라고 함. 이런 워크 플로우 관리가 중요하다
Scheduler
task를 스케줄링(어느 노드에 스케줄링할 것인지
MapReduce 프레임 워크는 FIFO(선입선출) 스케줄링을 지원한다.
job 제출 시 job의 우선순위를 지정할 수는 있지만 실행중인 job의 pre-emption은 불가능하다.
댓글