Hadoop HDFS

Basic Concepts of HDFS

de facto standard : 사실상 표준

Big Data STORE : hdfs

processing : map reduce

 

요약

큰 데이터 저장, 높은 대역대로 애플리케이션에 데이터 스트림 전달, 저장소와 계산능력 여러 서버에 분산.

 

hadoop project

맵리듀스 사용 분산파일 시스템 제공,  

- 빅데이터가 있고 계산능력을 빅데이터에 보냄. Parallel

adding commodity server -> computation sacle

 

Hadoop Ecosystem

Mapreduce, yarn, HDFS

 

why distributed file system?

단일 머신의 한계.

네트워크 통신 기반 -> 훨씬 복잡함. 큰 문제는 노드가 죽을 수도 있음, 이때 데이터 손실이 없게하기.

HDFS만 붙일 수 이쓴게 아니고 다른 파일 시스템도 붙일 수 있음.

 

Design of HDFS

매우큰 파일 저장

 - streaming data access 

  :1번 쓰고 여러번 읽기 패턴(업데이트 없음)

  : 전체 데이터를 읽는게 더 중요. 첫 레코드 읽는거보다

 - comoddity hardware

  : 비싼 하드웨어 필요없음. 일반 하드웨어 사용

  : 노드 죽을 확률이 큼 . HDFS로 커버.

 

잘 동작 안하는 상황

 - low latency 는 잘 못함.  high throughput 위주

 - lots of small files : namenode(master)가 메모리에 메타데이터 저장하기 때문. 

 - 하나의 파일을 동시에 여러 writer, wirte 는 append only.

 

HDFS Architecture

앱 데이터와 메타 데이터를 분리저장

하나의 파일을 복제해서 여러 블록에 나눠서 저장.

네임 노드에 메타데이터 관리

 

 - HDFSBlocks

  :읽기 쓰기의 단위, 64MB라는 큰 단위. 

  :seek time 줄이기

  : 블록은 복제되어있다. 보통 3개.(장애 회복, 성능 더 좋아짐 coloaction) 근데 용량이 많이듬

 

 - NameNode

  : block location 은 지속적으로 저장안함 -> 시스템 시작하면 데이터노드를 재구성하기 때문

  : RAM에 모두 저장함

 

 - DataNodes

  : 데이터, 블록의 메타데이터(체크섬, generation stamp)를 저장.

  : 시작시 namenode 랑 handshaking 후 register, block정보 보냄.

  : block report. 등록 후 즉시, 매 1 시간마다. 자신의 위치 등

 

 - 전체 시스템 관리

  : heartbests. 3초마다 데이터노드가 보냄. 생존신고. 계속 안오면 새로운 복제 생성. 저장용량, 저장소 사용 부분 등.

  : piggybacking. heartbeat에 답신에 추가 지령 담아서 보내기.

 

*마스터(namenode)가 죽었을 때 대처법? : 죽어도 일정 시간 안에만 다 완료하면 되기 때문에 크게 타격이 없음. 빠른 반응을 위한 것이 아니기 때문.

 

 - Client

  : HDFS 사용자 접근. 

  : 파일 읽기. 읽으려는 파일을 포함하는 데이터 노드들의 리스트를 받음. 직접 데이터 노드 선택해서 접근. 

  : 파일 쓰기. 네임노드에게 각 블록에 대해 3개의 데이터블록 리스트를 받아옴. node to node 파이프라인. 블록단위로 계속 리스트를 받아와서 읽고씀.

 

Reading data from HDFS

네임노드에게 최고의 데이터 노드를 가이드받아 클라이언트가 직접 접근해서 데이터를 회수함.

HDFS가 여러 클라이언트의 요청을 처리하기 좋음.

 

Writing data from HDFS

네임노드에게 물어봄. 첫번째 블록 어디다 쓸까? -> 네임노드가 데이터노드 리스트를 알려줌->리스트의 노드들에 데이터를 복제해서 씀. (파이프라인). -> 다 썼다고 알림 -> 네임노드한테 다음 블록 어디에 쓸지 물어봄 -> 반복

 

---

HDFS Part2

 

FILE I/O, Replica Management

-클라이언트가 읽을 때 제대로 된 블록인지 체크. 각 블록의 체크섬 이용. 오염된 노드면 네임노드한테 알려줌. 그리고 네임노드한테 다른 블록 주세요 함.

-클라가 가장 가까운 파일 읽음. 네임노드는 클라가 읽으려하면 블록 리스트를 줌. 

-그런데 어떻게 가까운 블록을 알 수 있음? -> 두 노드 사이의 시간당 데이터 전송(bandwidth)을 측정. 근데 이게 사실상 힘듬. -> 그래서 데이터 센터를 트리형태로 표현한 네트워크 토폴로지에서 가장 가까운 공통 조상으로 가는 길의 합.

 

*네트워크 토폴로지 : DataCenter -> Rack -> Node 등으로 이루어지는 데이터 서버의 구조

 

- BlockPlacement : 복제된 블록을 어디에 놓을 것인가? 

 : 노드의 주소를 주면 몇 번 RACK에 있는지 스크립트 정의

 : 어떤 노드라도 두 개 이상의 복제 블록을 가지고 있지 않다. 

 : 하나의 RACK에 두 개 까지의 복제 블록을 가진다. 세 번쨰는 반드시 다른 RACK에 (RACK이 고장났을 때 장애 복구를 위함& distance 줄이기 가능)

- Replica management : 네임노드가 3개 블록이 잘 유지되는지  관리. under or over

- Balancer : 언제나 블록이 균등하게 흩어진 것은 아님. 왜냐면 새로운 노드가 추가됐을 때 데이터 재분배가 이루어지지 않음. or 기존 노드가 없어지면 나머지 노드에 몰림. -> 그래서 정기적으로 관리자가 Balancer 작동.

- Block Scanner : 블록들이 오염되지 않았나 주기적으로 checksum 검사. 

- Graceful leaving of DataNode : decommissioning. 떠날 노드는 더이상 새로운 저장을 안하게 됨. ->

 : 떠날 노드에 있는 블록들을 다른 곳으로 옮김. -> 다 옮기면 decommissioned 상태가 됨 -> 그럼 안전하게 클러스터에서 제거가능.

 

---

UTILIZING HDFS

CommandLine Interface

- Basic Filesystem Operations : 파일 읽기, 디렉토리 생성, 파일 이동, 삭제 등

 : HDFS로 데이터 올리기 : %hadoop fs -copyFromLocal input/docs/quangle.txt \hdfs://localhost/user/tom/quangle.txt -> 로컬의 qungle.txt 를 HDFS에 올림. 

 : HDFS에서 로컬로 가져오기 : % hadoop fs -copyToLocal quangle.txt quangle.copy.txt

 : HDFS 파일 리스팅 : %hadoop fs -mkdir books -> %hadoop fs -ls

 

Hadoop Filesystem

 - HDFS도 hadoop filesystem을 구현한 결과물임. Hadoop Filesystem Abstract Class로 구현.

 - Interface : JAVA API

  : HTTP REST API (좀 느림)

  : C library (libhdfs)

  : NFS (클라이언트의 파일시ㅡ템에 mount해서 POSIX Library를 그대로 사용하게 해줌) 

  : FUSE (UNIX)

---

ADVANCED FEATURES OF HDFS

 

HDFS Federation 

 - 네임노드를 추가해 여러개 공존할 수 있게 하는 기능. 

 - 네임 스페이스를 여러개로 쪼개서 관리할 수 있음. 데이터 노드가 여러개의 네임노드에 다 등록됨. 각 네임노드들은 통신 안함. 

HDFS High Availability

 - 데이터 손실 방어. 

 - 네임노드 Single point of failure : 모든 하둡 시스템이 서비스 아웃 됨

 - 네임노드 복구 : 어드민이 예비 네임노드를 가동시키고 알림(Secondary Namenode)

  :새로운 노드를 사용하려면 -> 네임스페이스 이미지 불러오기 -> edit log 재생 -> block report를 받음

  : 근데 큰 시스템은 30분정도 걸림.

 - 그래서 Hadoop2에선 옆에 준비된 스페어 네임노드를 항상 둠. (Standby NameNode)

  : journal node로 standby NameNode와 스토리지 공유, 데이터노드들도 block report 등을 standby namenode에도 같이 보내줌.

 - 클라이언트도 이미 standby namenode를 알고있음.

 

Hadoop 3.0

 - Erasure Encoding 제공 : 복제를 세 개 해놓는게 아까워서 해결하려고 

  : Parity Block을 만듬. ( 두 블록을 XOR 연산을 한 블록) -> 한 블록이 문제가 생기면 Parity Block을 통해 한 블록을 복구할 수 있는거임. -> 저장 오버헤드가 200%에서 50%로 감소. -> 그치만 성능 측면에선 손해.

 - Standby Node를 한 개가 아닌 두 개 이상 만듬.