인프런 커뮤니티 질문&답변

odark 님에게

네 좋은 질문 감사합니다. 

우선 하둡 팀장과 개발자들과 모여 replication factor 곧 중복인자를 3으로 가정하였다는 점을 시작하겠습니다. 그리고는 개발자들은 현재 데이터 분석해야 할 파일을 선택한 뒤 쪼깨는 부분은 hdfs-site.xml 파일 내에서 조정합니다. 다음처럼요.

<property> 
<name > dfs.block.size<name>
<value> 128,000,000 <value>
</property>

그 파일은 hdfs-site,xml 파일 기준으로 파일들을 128MB로 쪼개도록 자동처리합니다. 만약 팀원들이 선택한 데이터셋의 총 용량이 384MB 사이즈로 되었있다면 우리는 384MB를 128MB으로 나누어야 합니다. 그래서 전체 example.txt 파일을 세 부분으로 쪼개니 A, B, C가 나온 겁니다. 아마 여기까지는 이제 이해하셨을 겁니다.  여기서 Replication Factor 곧 중복인자와는 상관이 없는 것이죠.. 아마 이 부분이 헷갈린 듯 합니다. 중복인자가 아닌 하둡 dfs 파일의 블럭 사이즈를 128MB로 선택한 것에 연관이 있죠.

문제는 A(1-128MB) ,B (129 - 256MB), C (257-384MB)로 나누어 있는 파일을 저장하여 하는데 하둡은 이들(A, B, C)을 다시는 잃어버리지 않고자 스토리지가 준비된 데이터노드들로 분산처리하여야 합니다. 

그렇다면 이 ABC 파일을 잊어버리지 않기 위해 하둡이 탄생하기 전 기업들은 데이터 손상을 어떻게 처리 해야 할까요? 답은 단순했습니다. 그저 과거 기업들은 백업 스토리지 서버를 하나 더 만들어 백업했습니다. 이는 데이터베이스를 중복처리, 곧 데이터셋 혹은 데이터 전체를 통체로 복사하여 중복 서버로 이동시켜 백업했습니다. 만약 백업할 용량이 1TB 라면 단순히 1TB 서버를 2배로 복제하였기에 200%의 용량이 된 것입니다. 여기까지는 이해하였을 겁니다. 

그리하여 384MB 라는 용량을 백업하고자 데이터베이스 서버하나 만들어 384MB 복사하여 다른 서버에 저장한 것이죠.. (하둡이 아닌 레거시 시스템 기준으로 볼 때)

           384MB            ----->  384MB (운용 서버), 384MB (백업 서버)     (200% storage overhead)

그런데 하둡은 이러한 처리를 좀더 세분화시키고 제타바이트라는 용량까지 백업하고 손상시키지 않고 복구를 실시간으로 해야 하는 사명에 의거하여 좀 더 다르게 시작합니다.   그렇다면 아래처럼 나누어 분산처리해야 하는 의무를 하둡이 지닙니다.  물론 여기서는 셋으로 나누던 둘로 나누던 큰 의미는 없습니다. 다만 블럭으로 팀원들의 상의에 의거하여 몇 개로 쪼개는가는 그들의 몫이죠. 네 개로 나누어도 무방합니다. 백 개로 쪼갠다면 백 개의 데이터 노드들이 생기는 것이죠.

   384MB               ----------          1 - 128MB (백업서버 A)

                               |________          129 - 256 MB  (백업서버 B)

                               |________           256 - 384 MB (백업 서버 C)

그런데 위의 서버 세 가지가 나눈 것으로 하둡은 끝나지 않습니다. 이 세가지 A B C 블럭들을 하둡이 다시 셋으로 쪼개죠(Replication Factor 3을 기준으로요. 만약 4 나 5 이상으로 한 다면 그에 준하게 블럭들을 나누어 저장하겠죠.?)... 아마 odark님께서 여기부터 혼돈(?) 한 듯 합니다. A B C 블럭과 A1 A2 A3 .....들을 또 나누냐는 의문은 당연하죠.. 만약 팀원들이 파일을 두 개로 블럭 쪼개면 당연히 A B 블럭으로 되고 이들을 각각 3 개씩 분산하여 데이터 노드들에 분산 저장하겠죠.

왜 중복인자를 사용하냐고요?

예를 들어 하둡이 등장하기 전, 기존의 기업들은 백업 서버를 두어 블럭을 잘 개 쪼개기 보다는 통으로 전체를 백업 서버에 넣었다고 생각하면 되지만, 만약 백업 서버가 이유없이 사라진다면? 혹은 백업하던 중간에 서버가 파손되거나 데이터가 손상된다면요?

하둡은 이러한 손상처리를 클러스트 서버로 복제 관리 매커니즘을 관리합니다. 그리하여 마스터인 네임노드 서버가 수 많은 데이터노드들을 잘 개 쪼개어 배포하기 시작하여 백업을 하게 만들죠...어떻게요? 아래 그림처럼요. 

실 데이터                                              블럭들(A,B,C)                          블럭 각각의 청크들(A,B,C들의 복제품노드들)

==========                        ====================              =====================

   384MB       ----------    1 - 128MB (백업서버 A)     
                                                                     |___________   백업서버 A' (1-128MB)

                                                                      |___________   백업서버 A'' (1-128MB)

                                                                      |____________백업서버 A''' (1-128MB)   

                    |________          129 - 256 MB  (백업서버 B)

                                                                       |___________   백업서버 B' (1-128MB)

                                                                        |___________   백업서버 B'' (1-128MB)

                                                                         |____________백업서버 B''' (1-128MB)   

                               |________           256 - 384 MB (백업 서버 C)

                                                                           |___________   백업서버 C' (1-128MB)

                                                                           |___________   백업서버 C'' (1-128MB)

                                                                           |____________백업서버 C''' (1-128MB)   

                             ...........                                               ....................... 

곧 A B C 블럭(아직 중복처리 인자가 적용되지 않습니다.) 을 중복처리인자 3으로 기준으로 하여 A 3 개, B 3개, C 3개로 나누어 데이터 노드들은 총 9개가 되는 겁니다. 이들이 하둡 클러스트에 하둡이 분산 처리 하여 자동으로 저장하게 되죠. 그리하여 자동적으로 데이터노드들에 분산되어 9개의 블럭들이 생기는 겁니다. 3개의 A, 또 다른 3개의 B, 또 다른 3개의 C들이 분산되어 퍼져있게 되죠.
하둡이 이 일을 하게 되면서 스토리지 오버헤드는 그저 100%로 남습니다.  Replicaton Factor 기준 3으로 하였기에 300%가 이닙니다. 왜냐하면 하둡의 기본 방향이 3배로 분산 처리하는 기본 구조이기 때문에 100% 스토리지로 남는 것이죠..

그런데 하둡은 여기서 그치지 않고 Replicas를 두 배로 저장하는 기존 레거시 정책처럼A1, A2 A3 ........ C3까지 그대로 복제합니다. 그렇게 복제를 x2로 한다면 당연히 스토리지 오버해드는 100%에서 200%로 상향되게 되죠..

이해하셨나요? 그리고 나서 아래 저의 강의 노트 중 하나인 Erasure coding 기술과 레프리케이션 데이터 블럭들의 차이점이 보이실 겁니다. 또한 하둡 1 과 2 버전의 레프리케이션 데이터 블럭 기술이 어떻게 노드들로 쪼개져 청크들에 들어가는 지 이해하실 겁니다. 

디스트 노드들이 하둡 3 버전은 블럭들이 3개에서 6개로 쪼개져 분산처리된다는 것이 보이시나요? 그렇다면 

하둡 1과 2에서 스토리지 복제 메커니즘이 200%이지만 하둡 3은 노드 두 개를 하나로 만든다는 점에서 200%로 상향되기보다 오히려 50%로 줄어든 셈이죠.. 왜냐고요? 노드 1(Node #1)이 세 개의 블럭 (A2, B1, C2)으로 가지고 있다면

Erasure Coding 기술에서는 A2, B1, C2, C1, B2, C1)이라는 여섯 개의 블럭들로 붙어 있으니 50%로로 반이 줄게 되지 않을까요? 서버 증대 수가 반으로 쪼개지니 이들을 복제 한다면 100%에서 50%로 줄어드는 셈이죠.

질문에 답이 되었는지 속이 시원하신지 궁금하네요.... 
답변주시면 고맙구요..

토론토에서 빌리 올림