Big Data : Hadoop : lecture_2 : Hadoop_basics_2

Hadoop_basics_1에서는 Hadoop이 실제로 어떤 방식으로 연산하고 저장하며,

RDBMS와 비교했을 때, big data를 다룰 때 어떤 이점이 있는지 설명하였다.

또한 연산을 할 때, MapReduce를 기본으로 사용하고 있다라고 설명하였다.

 

이번 포스팅에서는 HDFS, 실제로 Hadoop이 분산저장을 할 때, 어떤 방식으로 저장하는지를 적을 것이다.

The Design and Concepts of HDFS

 

Design of HDFS

• Data가 매우 크다. PB까지 커버린 data를 분산저장하고자 한다.
• Streaming Data를 access하는 효과적인 방법은 : write-once 하고 반복적으로 read한다.
• comodity hardware를 사용함으로써 fail이 자주 일어나기 때문에 쉽게 사용 but fail을 잡아야한다.

Trade-off (hadoop의 원래 목적과 맞지 않는 단점들, 자주 나오기 때문에 알아둘 것.)

• low-latency data access : HDFS는 big data를 다루기 때문에 지연시간이 어쩔 수 없이 있기 마련. 따라서 HDFS는 latency-access를 줄이기위해 많은 노력을 한다.
• Lots of small files (one namenode) : big data를 다루는 Hadoop이라 하지만, 수백만개의 file은 할 수 있다. 그렇지만 10억개 정도면, 갯수로 봤을 때, 현재 하드웨어의 능력 밖이다.
• multiple writer, arbitary(임의의) file modification : Hadoop이 write-once를 지향한다. 하지만 다수의 writer들이 file 안에 arbitary offset (임의의 file 내용의 위치, file에서 임의의 곳을 수정할 수 있다는 의미)을 수정하는 것을 지원하지 않는다. 

 

Block

disk 에 읽고 쓰고 하는 최소의 data 양은 128MB 이다.

 

Why??? ->

• 네트워크 상에서는 어느 single disk보다 file이 더 크다.
• fault tolerance & availability를 하기 위해 진행하는 replication이 Block에 딱맞다. 이말은 Block 단위로 나뉘어져 있어야 fail이 일어나도 잘게 쪼개져 있는 상태에서 replication이 일어나기 때문에 금방 복구가 가능하다.
• client 가 namenode와 interact를 하는 것을 많이 줄일 수 있다. -> block 단위가 작으면, 그만큼 같은 데이터를 불러오더라도 여러번 interact를 해야함 -> latency를 증가하는 행위.

 

 

Block의 status를 확인

위는 Block 단위를 나눠놓은 것을 status로 확인 가능하다.

 

---

Namenode, Datanode

Namenode:

• filesystem의 namespace를 관리한다. namespace는 filesystem의 tree구조, 그리고 모든 file, directory의 metadata를 유지한다.
• namenode는 input한 file들이 어디 block에 있는지 block들을 가지고 있는 datanode를 알고 있다. input한 data들은 block 단위로 쪼개져서 여러 datanode로 들어가기 때문이다.
• namenode가 없으면 filesystem도 사용하지 못한다. -> filesystem의 tree구조, metadata를 모르기 때문에!!!
• 따라서 fail이 일어나면 안되기 때문에, 이를 보완하기 위해서 -> 1. filesystem metadata의 지속적인 state를 백업해둔다. 2. secondary namenode를 실행시킨다.
• secondary namenode는 log파일이 커지는 것을 방지하기 위해, namespace의 image를 주기적으로 계속 업데이트 한다. 따라서 secondary namenode는 separate physical machine, 즉 따로 machine을 운영한다는 말로, 이는 CPU를 많이 잡아먹기 때문에, namenode가 죽었을 때만 사용 가능한것이지, 실제로 돌아가고는 있다.

Datanode:

• Datanode는 filesystem의 work를 담당한다.
• block을 저장하기도하고, 지우기도 하고, 복구하기도 한다.
• 이를 namenode와 주기적으로 report 하며 block들의 list들이 어디에 저장되었는지 알려준다.

 

HDFS High-Availability

• Namenode는 single point of failure (SPOF)이다. -> (어떤 시스템 혹은, 기계장치에서 특정 부분이 고장이나 이상이 나면 전체 시스템이 정상적으로 동작하지 않는 것을 뜻한다)
• 이를 막기 위해 namenode 는 active, standby로 configuration을 hadoop 2.x-버젼부터 지원한다. 

 

---

Hadoop FileSystem

 

Command Line Interface

 

HDFS 에서 Local로 옮기는 작업은 필수이다. 

command 를 외워두면 좋다.!!!

 

hadoop-env.sh 

name이 fs에서 defaultFS로 정해둔 것을 쓰겠다는 것이고, value 값으로 hdfs://localhost:4010을 썼다는 것이다.

4010은 내 컴퓨터의 port 번호이다.

 

hadoop filesystem

위는 org.apache.hadoop.fs.FileSystem 에서 파생되서 응용가능한 filesystem들이다. 참고용?

 

위에는 나중에 filesystem에 어떻게 접근하고, 어떻게 읽고 쓰는지에 대한 것이다. 

나중에 참고하면 좋을 내용들!!!

 

여기서 중요한 내용은!! read는 seek가 가능하지만, write는 seek가 안된다. 왜냐면 Hadoop의 HBase는 relation을 생각해서 sort & merge를 하지않기 때문에 seek를 해서 sor & merge 후 update를 하지 않는다.

 

 

---

Data Flow

 

Anatomy of File Read

File read

이는 위에서 read에 대한 interface 적은 부분과 똑같다.

• 1. client가 DFS에게 open을 요청
• 2. Namenode는 block들의 location, datanode의 주소를 알려준다.
• 3. client는 datanode의 주소를 토대로 FSDataInputStream에 요청
• 4-5. FSDataInputStream 은 Datanode를 read
• 6. close

Network Topology and Hadoop

network toplogy는 Tree 구조를 가진다. 

hadoop은 총 4가지로 distance를 구별한다.

• 같은 node에 있는지
• 같은 rack에 있고 , 다른 node에 있는지
• 같은 data center에 있고 다른 rack에 있는지
• 다른 data center에 있는지

Anatomy of File write

write flow

• 3 : split 된 data 들을 packet에 넣어서, internal queue에 넣는다. 이 queue 를 data queue라 한다.
• 4 : Data Streamer 가 packet의 정보를 write 한다.
• 5 : datanode에 의해서 올바른 datanode가 맞는지 인식하는 것을 기다리는 packet의 queue를 ack queue라 한다. 이를 유지시키는 과정이다.
• 6 : 완료되었으면 close하고 7번으로 가서 Namenode에 complete 되었다고 알려준다. 
• Namenode는 새로운 정보를 update 한다.

 Hadoop은 Data Locality를 보장하려 한다.

 

Data locality란 속성, 특징이 비슷한 data를 근처에 두어 자주 접근하는 특징을 말한다.

 

1. 같은 node에 replica를 둔다. node가 꽉차면 2번으로 진행
2. 같은 rack안에 배치
3. rack도 꽉차면 다른 data center에 저장한다.