현재 Hadoop 완벽 가이드 (데이터 엔지니어 기본 책)을 일고 있으며 조금씩 주요 내용을 간단하게 내가 이해한 방식으로 정리하고자 한다.
Chapter 2 - MAPREDUCE
- MAP : 입력에 있어 원하는 부분만 Mapping을 하는 것 만약 테이블이라면 원하는 field 를 select 하는 것도 포함될 수 있다.
내 생각에 주요 부분은
@Override
public void map(LongWritable key, Text Value, Context context) 마지막 부분에
context.write(new Text(year), new IntWritable(airTemperature));즉 return 을 Context 로 반환하는것 그리고 해당 Context는 year와 int Temperature를 담고 있다는게 나에게는 중요하게 다가왔다. 즉 Mapper 가 반환하는 것은 하나의 Row라고 할 수 있다. Spark를 공부하며 Shuffle 단계에서 이게 합쳐지는 것으로 보였는데 현재 2챕터에서는 단순히 보내지는 과정에서 맵리듀스 프레임워크에 의해 처리 된다라고만 설명한다.
-
Reduce : (1960 [20, -1, 2]) 같은 key value를 받으면 max 를 뽑거나 뭐 원하는 리스트 연산을 적용하게 되는 것이라고 생각이 든다.
-
Shuffle : ? 내용이 따로 Chapter2에서는 없고 잠시 복잡한 과정이라고 언급만 있다. 그러나 나는 항상 MAPREDUCE는 명칭이 잘못 되었다고 생각한다. 그냥 Shuffle이여야한다. 이게 제일 cost가 비싸며 네트워크사용과 원하는 전송이 빠딱빠딱 되야하는데 제일 복잡한 과정 아닐까? Spark에서도 마찬가지다.
-
Split : 잡의 인풋을 나눈 input split이다. Spark의 파티션의 여기서 유래 되었을 것이라고 판단된다.
-
Data Locality Optimization : 당연하지만 블록이 있는 노드에 잡 실행 컨테이너가 떠야 네트워크 사용없이 데이터를 최대한 빠르게 사용하는 Optimization
-
Combiner Function : [1,2,3,4][5,6] 두개의 list에서 max를 뽑자
l1 + l2 의 max도 가능하지만 만약 다른 노드에서 실행된다면 전체 데이터를 합치는 과정이 있다. 그러나 max(l1), max(l2) 의 max 를 찾는다면 가장 적은 데이터 프로세싱과 네트워크 비용을 감소시킬 수 있다. 하자만 mean과 같은 함수는 하면 당연히 안됨.
Chapter 3 - HDFS
- 블록 : 일반적인 디스크 블록의 크기는 512 바이트이며 HDFS 의 블록 사이즈는 128 MB 이며 129MB 짜리 데이터가 저장되면 128 블록 하나 1 짜리 하나가 사용된다. 128 + 128 로 256 을 차지하지는 않는다.
파일들에 대한 블록정봍나 이런거를 보려면
% hdfs gsck / -files -blocks hdfs 명령어를 사용하면 된다.
-
NameNode : 머리! Meta 정보를 기본적으로 namespace image 와 edit log로 관리하며 edit 될때마다 edit log가 추가되는 것이며 이는 메모리! 에서 관리된다.
-
DataNode : 저장소 + container 일하는곳 그리고 주기적으로 NameNode에 하트비트 (블록 정보 등) 를 보낸다.
-
기본 장애 복구 방법 :
1. 다수의 fs 에 영구적인 상태로 메타 정보를 저장 하는 것 주로 NFS를 사용하도록 권장한다.- Secondary NameNode를 운영하는 것 그러나 비싸다는 단점이 있다 왜냐하면 프라이머리하고 비슷한 스펙의 머신에서 실행되어야한다. 또또한 네임스페이스 이미지를 주기적으로 복제해야한다. (나중에 활성화 비활성화도 나온다)
-
Block caching : 블록이 저장되어 있는 데이터 노드에 주기적으로 읽어오는 데이터를 메모리 위에 올려놓는 것. 빠르자나
-
HDFS Federation : hdfs 하위 디렉토리 /user/namenode1 은 네임노드 1 이 메타를 가지고 있고, /user/namenode2 는 네임노드 2가 메타를 가지고 있도록 구성하는 것 근데 결국 가장 상위는 누가 가지고 있는거지?
-
SPOF : SINGLE POINT OF FAILURE ! 지금까지설명한 어떠한 방법으로든 프라이머리 대가리가 오류가 발생하면 데이터 손실을 방지할 수 없다 조금은 발생하게 되어 있다. 지금부터 설명하는 방법도 완전한 데이터 손실을 방지할 수는 없지만 그나마 적절한 벙법이다.
-
Secondary NameNode를 항상 활성화 상태로 두며 주기적으로 Namespace Image 와 Edit Log를 받아서 refresh (합치기)
-
Journal Node : 말그대로 일기 노드이다 메타정보를 저널 노드들에 (보통 3개이상 그리고 홀수로 구성한다) 계속해서 쓴다. 그리고 프라이머리가 무슨 이유에서 죽었을때 과반수로 저널 노드중 한대를 프라이머리로 올린다. 그래서 Secondary 한대만 사용하는 것보다 3대 이상의 머신을 사용해야하기 때문에 무조건 적으로 비싸다 그리고 실제 내가 emr가지고 구성하였을때 비용 폭탄을 맞았다.
-
장애복구와 팬싱 : 간단하게 프라이머리가 잠시 네트워크 단절로 오류가 떴는데 다른 프라이머리가 선출되어 2개의 프라이머리가 동시에 hdfs를 관리하는 것을 막는게 팬싱이다. Quoram Journal Node를 사용하면 지가 알아서 하나의 네임노드만 에딧로그를 사용하도록 설정이되어 무조건 이걸 권장하는 것이다.
Chapter 3 - HDFS (2)
-
데이터 읽기
client -> dfs -> namenode -> FSDataInputStream -> DataNode
결국 namenode에서 먼저 데이터 정보를 받은 후에 데이터 노드에서 블록들을 가지고 온다. -
데이터 쓰기
Client -> dfs -> namenode -> (FSDataOutputStream) DFSOutputStream -> NameNode ->DFS OutputStream -> DataNode -> DataNode -> ... -> DFSOutputStream ACK!
여기서 중요한 Replication 즉 데이터 단일 블록을 복제를 할 때 동일 데이터 노드에 하나를 먼저 쓰고 다른 가까운 데이터 노드에 복제본을 저장한다.
