storage overhead설명시에 이해가 안갑니다.

팀원들이 총 3개로 파일을 나누고 replication factor를 3으로 해서 총 9개 블럭이 되는데 설명화면 반으로 나눠서 왼쪽은 

replcation factor값이 3이여서 총 9개 블럭인데 갑자기 왜 9블럭x 1 replica 값을 계산 하며 여기서 replica 1이 왜 나오며,..replication factor와는 어떤 차이가 있습니까? 

오른쪽화면은 9블럭에서 값자기 또 replica2는 왜 나와서 18블럭이 되나요? replication factor값이 이미 3이 있는데...느닺없이

왼쪽은 1을 곱하고 오른쪽 화면은 2를 곱하는게 뭔지 도무지 이해가 안갑니다. 왜 갑자기 오른쪽에서 2배로 replica를 올리고 비용부담과 IO과부하는 당연하다고 표현하신건가요? replication값 3으로 복제는 이미 끝난거 아닌가요?

곧이어서 replication 곧 3배의 높은 비용이 되는 중복이라는 이런 문제점들의 솔루션을 하둡2.0은 아직 안고있었다. 라고 표현하시고 erasure coding이 나왔다고 하는데 왜 위의 먼저 언급한 설명들이 필요한건가요? 인과관계도 판단이 안되구요 ㅠ

아래 내용들은 강사님의 말을 그대로 적어봤습니다. 읽고 읽어봐도..진짜...초보로써 저 말들이 이해가 되어야 하는건가 싶습니다.

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

우선 block replica에 대한 문제점부터 살펴보자. 하둡의 팀원을 샘플텍스트를 3개로 나누기로 결정했따. (example.txt 384M) replication factor를 3으로 가정. A(128M)- A1,A2,A3 B(128M)- B1,B2,B3 C(128M)- C1,C2,C3 총 9개로 쪼개져 클러스터에 배포 전환된다. storage overhead 100%로 자리를 잡는다. 다만 encoding으로 replica를 중복처리하게 되어...각각 block들의 replica는 각각 2개 중복처리 저장이 되기도 합니다. 이제 하나의 replica 를 가진 결과값과 비교할때 현재 block size chuncks의 replica는 1개 기준으로 storage overhead는 200%의 결과값을 가져온다. replica를 2배로 복제하였기 때문에 overhead는 2배값인 200% 의 결과값으로 storage는 2배로 많아지는 비용부담과 IO과부하는 당연하다. 또한 3배의 기본 replication 곧 3배의 높은 비용이 되는 중복이라는 이런 문제점들의 솔루션을 하둡2.0은 아직 안고있었다. 그런 resource와 IO성능개선을 위하여 erasure coding기술을 도입하게된다. 하나의 raid는 운영체계적으로 혹은 논리적으로 하나의 하드디스크로 인식이 되지만 내용의 다양한 sector크기에서 수 메가바이트 데이타 공간까지 다양한 범위로 파티션하는 작업이기에 기존의 중복처리로 여러대 복수 노드들로 인지하는것보다는 시간과 리소스를 적게 잡아먹게된다. 기존하둡 팀원들의 상의 결과에 의하여 나타난 하둡2.0 에 중복데이터들은 총 9개의 블럭들로 디스크 스페이스는 9개의 블록에 해당되는 노드들로 구성되어 리소스를 많이 잡아먹게 된다. 그러나 하둡3.0의 erasure coding은 한 블럭안에 두개의 데이타블럭들을 오버헤드 하도록 돕는다. 이는 기존의 storage overhead를 반으로쪼개므로 디스크 노드갯수가 줄어드는 경험을 하게 된다. 결과적으로 50%의 storage overhead를 요구한다는점으로 기존의 50%의 storage overhead 요구한다는 블록수는 줄어들게 된다. 한개의 파일내에 블럭들을 더 많이 쪼개어도 기존에 중복저장방식에 50%서버 증대수를 대폭 줄어들게 되는것이다.

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%로 줄어드는 셈이죠.

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

토론토에서 빌리 올림

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