hdfs
- 두세배 빠른 속도로 읽을 수 있다.
- 디스크 - 파일 시스템
- hdfs만의 특징이라기 보다는 분산파일 시스템의 특징 : 언제 데이터가 생성됐고 변경됐고 저장했는지를 edit logs를 가짐
- 변경 - 삭제를 포함 / 파일에 어떤 작업이 일어낫는지를 모두 저장하는 것이다.
- 참고로 hdfs는 append가 불가능하다
- 근데 이 부분은 잘 모르겠다…직접 해봐야 알 수 있을것 같다.
- 한번 저장한 데이터를 수정할수 없고 읽기만 가능하다.
- 파일이동 삭제 복사만 됨(데이터 무결성)
- nfs
- secondary name node VS hot standby name node(HA → 고가용성)
HA에서 주키퍼가 네임노드를 관리하는 방식은? secondary namenode랑 차이는?
put / copy from local 의 차이는? 로컬에 있지 않아도 파일을 올릴수 있는게 put
- 아예 서로 다른 시스템내에서도 파일을 옮기는 것이 가능하다.
- client가 hdfs에 접속 안되어 있을때, 다른 곳에서 데이터를 가지고와서 옮겨야 할때
- copy from local로 하려면 일단 로컬로 파일을 가져오고 그 내부로 들어가서 파일을 옮겨야 하므로
Difference between hadoop fs -put and hadoop fs -copyFromLocal
책 3.1(81p) 참고
- HDFS가 다른 분산 파일시스템과 다른 것은 생각보다 큰 파일 크기로 저장하는 것.
- 읽을때 오버헤드를 감안하고서라도 이후 꾸준한 속도를 지원
- 스트리밍 방식의 데이터 접근을 허용
https://serverfault.com/questions/40370/what-is-meant-by-streaming-data-access-in-hdfs
- object storage 기반
https://tech.kakao.com/2017/01/12/kage/
위 그림은 fsimage와 edit log가 어떻게 관리되는지 보여주는 구조도인데요.
여기서 fsimage와 edit log를 보관하는 노드를 journalnode라고 불러요. 강의에서 나왔던 edit log를 보관하는 Shared Volume이 바로 저널노드입니다. journalnode는 정족수를 맞춰야 하기 때문에 보통 홀수로 구성합니다.
만약, ACT 네임노드에서 장애가 발생하면, fsimage를 STB 네임노드의 memory에 load하고, edit log는 최신까지 있을테니, edit log 내에서 특정 시점 이후에 발생한 변경 내역을 메모리에 반영해서, 메타를 최신으로 복원할 수 있어요.
edit log가 변경되는 경우는 대부분 client가 hdfs에 파일 쓰기를 작업할 때예요. 네임노드는 fs metadata를 in-memory에서 관리하고 있구요. 파일 쓰기가 이뤄지면, edit log를 먼저 변경한 후에, memory에 떠 있는 metadata를 변경하는 순서라고 합니다. 반면에 읽기 요청이 왔을 때는 edit log를 읽는 것은 아니고, memory에 올려져있는 metadata만을 이용해서 읽어간다고 하네요.
개인적으론, 실제 Hadoop 관리자 입장에선 HDFS NN Failover 과정에 대해서 잘 알아야 할 거 같은데, 요건 저희 책으로 스터디할 때 좀 더 파볼게요
추가로 블록 크기가 128MB라고 해서, 작은 파일을 저장하는 데에도 128MB를 사용하는 건 아니라고 해요. 최대 블록 사이즈가 128MB일 뿐이고, 128MB를 넘어가는 큰 데이터는 블록 크기(128MB)를 기준으로 쪼갤 때 사용한다고 합니다. 당연히 이런 식으로 동작하는게 합리적이라고 생각은 들었지만, ‘하둡이라면 hoxy…?’하는 생각에 여쭤봤었네요 ㅋㅋ