최초 작성일 : 2013/05/20 13:15 


일단 설치와 설정을 끝마쳤다고 생각하고 샘플 job을 수행해보기로 했다.
하지만 아래의 명령을 실행시켜도 map:0% reduce:0%에서 더이상 진행이 없었다.

예제 실행 코드

./hadoop jar ../hadoop-examples-1.0.4.jar wordcount input output

input : 원본 문서가 있는 곳
output : 결과 문서가 저장될 곳

아직도 분산이라는 환경에 익숙하지 않은 탓에 계속 네임노드쪽 로그만 뒤적거리면서 원인을 찾으려고 했다.
하지만 네임노드쪽 로그에는 딱히 이렇다할 에러도 기록된 것이 없어 원인을 찾은데 시간만 잡아먹고 있었다.

그러다가 데이터노드 쪽으로 관심을 돌려 데이터노드의 로그를 살피기 시작했고 여기서 문제의 실마리가
잡히기 시작했다.

우선 데이터노드에서 jps 명령을 통해 TaskTracker가 로드되지 않았다는 사실을 확인했다.
그리고 바로 hadoop-mazdah-tasktracker-macmini-server.com.log 파일에서 다음과 같은 로그를
발견했다

이 로그의 ERROR 항목 바로 직전에 나오는 WARN 내용으로부터 디렉토리 설정에 뭔가 문제가 있다는 것을
짐작하고 처음 글에서 잠시 언급한 것 처럼 이 디렉토리도 모든 노드들 간에 경로를 일치시키기로 했다.


처음 디렉토리 설정이 맞지 않았을 때의 오류 로그

************************************************************/
2013-05-20 11:27:20,495 INFO org.apache.hadoop.mapred.TaskTracker: STARTUP_MSG:
/************************************************************
STARTUP_MSG: Starting TaskTracker
STARTUP_MSG:   host = macmini-server.com/134.102.35.58
STARTUP_MSG:   args = []
STARTUP_MSG:   version = 1.0.4
STARTUP_MSG:   build = https://svn.apache.org/repos/asf/hadoop/common/branches/branch-1.0 -r 1393290; compiled by 'hortonfo' on Wed Oct  3 05:13:58 UTC 2012
************************************************************/
2013-05-20 11:27:20,657 INFO org.apache.hadoop.metrics2.impl.MetricsConfig: loaded properties from hadoop-metrics2.properties
2013-05-20 11:27:20,710 INFO org.apache.hadoop.metrics2.impl.MetricsSourceAdapter: MBean for source MetricsSystem,sub=Stats registered.
2013-05-20 11:27:20,711 INFO org.apache.hadoop.metrics2.impl.MetricsSystemImpl: Scheduled snapshot period at 10 second(s).
2013-05-20 11:27:20,711 INFO org.apache.hadoop.metrics2.impl.MetricsSystemImpl: TaskTracker metrics system started
2013-05-20 11:27:20,979 INFO org.apache.hadoop.metrics2.impl.MetricsSourceAdapter: MBean for source ugi registered.
2013-05-20 11:27:25,144 INFO org.mortbay.log: Logging to org.slf4j.impl.Log4jLoggerAdapter(org.mortbay.log) via org.mortbay.log.Slf4jLog
2013-05-20 11:27:25,190 INFO org.apache.hadoop.http.HttpServer: Added global filtersafety (class=org.apache.hadoop.http.HttpServer$QuotingInputFilter)
2013-05-20 11:27:25,220 WARN org.apache.hadoop.mapred.TaskTracker: TaskTracker local dir /Volumes/Data2/hadoop-data/mapred/local error can not create directory: /Volumes/Data2/hadoop-data/mapred/local, removing from local dirs
2013-05-20 11:27:25,221 ERROR org.apache.hadoop.mapred.TaskTracker: Can not start task tracker because java.util.ConcurrentModificationException
at java.util.AbstractList$Itr.checkForComodification(AbstractList.java:372)
at java.util.AbstractList$Itr.next(AbstractList.java:343)
at org.apache.hadoop.mapred.TaskTracker$LocalStorage.checkDirs(TaskTracker.java:211)
at org.apache.hadoop.mapred.TaskTracker.<init>(TaskTracker.java:1449)
at org.apache.hadoop.mapred.TaskTracker.main(TaskTracker.java:3742)

2013-05-20 11:27:25,222 INFO org.apache.hadoop.mapred.TaskTracker: SHUTDOWN_MSG:


각각의 설정 파일에서 다음과 같이 value를 통일시켰다.
몰론 네임노드와 데이터노드의 실제 물리적 공간도 /hadoop-data로 맞추었다.

core-site.xml

<property>
        <name>hadoop.tmp.dir</name>
        <value>/hadoop-data/tmp</value>
    </property>
   
hdfs-site.xml

<property>
     <name>dfs.name.dir</name>
        <value>/hadoop-data</value>
    </property>

    <property>
        <name>dfs.data.dir</name>
        <value>/hadoop-data</value>
    </property>
   
mapred-site.xml

<property>
         <name>mapred.system.dir</name>
         <value>/hadoop-data/mapred/system</value>
    </property>
    <property>
     <name>mapred.local.dir</name>
        <value>/hadoop-data/mapred/local</value>
    </property>
   

그리고 각 노드간 변경된 설정들을 sync 시킨 후 다시 start-all.sh를 실행시켰다.
그러나 여전히 문제가 발생을 하였다. 이번엔 jps 명령어를 통해 확인하니 데이터노드쪽에서 DataNode 프로세스가
로드되지 않았고 hadoop-mazdah-datanode-macmini-server.com.log 파일을 확인하니 다음고 같은 로그가
찍혔다.

************************************************************/
2013-05-20 12:28:44,171 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: STARTUP_MSG:
/************************************************************
STARTUP_MSG: Starting DataNode
STARTUP_MSG:   host = macmini-server.com/134.102.35.58
STARTUP_MSG:   args = []
STARTUP_MSG:   version = 1.0.4
STARTUP_MSG:   build = https://svn.apache.org/repos/asf/hadoop/common/branches/branch-1.0 -r 1393290; compiled by 'hortonfo' on Wed Oct  3 05:13:58 UTC 2012
************************************************************/
2013-05-20 12:28:44,307 INFO org.apache.hadoop.metrics2.impl.MetricsConfig: loaded properties from hadoop-metrics2.properties
2013-05-20 12:28:44,317 INFO org.apache.hadoop.metrics2.impl.MetricsSourceAdapter: MBean for source MetricsSystem,sub=Stats registered.
2013-05-20 12:28:44,317 INFO org.apache.hadoop.metrics2.impl.MetricsSystemImpl: Scheduled snapshot period at 10 second(s).
2013-05-20 12:28:44,317 INFO org.apache.hadoop.metrics2.impl.MetricsSystemImpl: DataNode metrics system started
2013-05-20 12:28:44,403 INFO org.apache.hadoop.metrics2.impl.MetricsSourceAdapter: MBean for source ugi registered.
2013-05-20 12:28:52,800 ERROR org.apache.hadoop.hdfs.server.datanode.DataNode: java.io.IOException: Incompatible namespaceIDs in /hadoop-data: namenode namespaceID = 1440344326; datanode namespaceID = 1690373933
at org.apache.hadoop.hdfs.server.datanode.DataStorage.doTransition(DataStorage.java:232)
at org.apache.hadoop.hdfs.server.datanode.DataStorage.recoverTransitionRead(DataStorage.java:147)
at org.apache.hadoop.hdfs.server.datanode.DataNode.startDataNode(DataNode.java:385)
at org.apache.hadoop.hdfs.server.datanode.DataNode.<init>(DataNode.java:299)
at org.apache.hadoop.hdfs.server.datanode.DataNode.makeInstance(DataNode.java:1582)
at org.apache.hadoop.hdfs.server.datanode.DataNode.instantiateDataNode(DataNode.java:1521)
at org.apache.hadoop.hdfs.server.datanode.DataNode.createDataNode(DataNode.java:1539)
at org.apache.hadoop.hdfs.server.datanode.DataNode.secureMain(DataNode.java:1665)
at org.apache.hadoop.hdfs.server.datanode.DataNode.main(DataNode.java:1682)

2013-05-20 12:28:52,802 INFO org.apache.hadoop.hdfs.server.datanode.DataNode: SHUTDOWN_MSG:


이 내용은 구글링을 통해 쉽게 해결하였다.
위에서 디렉토리 경로를 바꾸면서 기존 생성했던 디렉토리를 새 위치로 그냥 카피를 했던 것이다.
즉 /hadoop-data라는 디렉토리 안에 기존에 생성된 설정들이 그대 담겨있었다. 이로 인해 문제가 발생을 한 것이었고
/hadoop-data를 싹 비우고 새로 실행하니 드디어 wordcount 예제가 실행이 되었다.

역시 아직은 분산이라는 환경에 익숙하지 않은 탓에 사소하면서도 쉽게 해결하지 못하는
문제들이 많이 발생을 한다. 이 부분은 이론적인 학습을 통해 보충을 하는 수 밖에 없을 것 같다.

그리고 이번 글에 같이 적으려던 놀고먹게된 맥미니에 대한 이야기는 별도로
작성하려 한다.

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요

최초 작성일 : 2013/05/16 13:37


미리 말씀드리지만 이 글은 설치 안내가 아니라 설치 중에 실수할 수 있을만한 부분에 대해

적은 글입니다. 설치 전반에 대해 참고한 글은 본문 중에 링크를 하였으니 참고하세요...^^


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


원래는 교재와 함께 천천히 실습을 진행할 계획이었는데…

지난 한 달 간 되지도 않는 영어실력으로 문서 번역한다고 삽질을 해놨더니 조급증이 생겨서

우선 하둡부터 설치를 하고 봤다.


애초 예정대로 대상 머신들은 모두 애플의 맥 기종으로 맥북 프로1대 맥미니 서버 1대 맥미니 1대이며

이 중 맥북프로와 맥미니 서버는 같은 네트워크 대역에 있으나 맥미니 1대는 다른 네트워크 대역에 있다.

다음 글에 언급하겠지만 역시나…맥미니는 클러스터로 묶일 수가 없다…ㅠ.ㅠ

(이거 해볼라구 따로 구입한 놈인데…제 역할을 못하게 됐다…ㅠ.ㅠ)


우선 설치는 무진장 쉽다.

개나 소나 할 수 있다.

개나 소가 컴퓨터를 이용할 수 있다는 가정하에…-.-


암튼 다운로드 받고 압축 풀고 java home 잡아주고 설정 xml파일 3개정도 만져주면 끝이다.

우선 도움을 받은 사이트를 링크한다.

많지도 않다.

요기만 잘 보고 진행하면 만사 땡이다.


http://blrunner.com/29

http://develop.sunshiny.co.kr/868

http://develop.sunshiny.co.kr/893


하지만…

중요한 함정이 도사리고 있었다.

앞서 구글의 논문을 번역하는 가운데 구글 애들이 매우 자주 강조한 내용이 있었다.

'MapReduce 라이브러리는 병렬이나 분산 시스템에 대한 경험이 없는 개발자들도

쉽게 접근할 수 있다'는 것이다.


그러나 이 쉽게 접근할 수 있다는 의미는 좀 더 구체적으로 말하면

'(얼마간의 혹은 꽤 오랜 시간 삽질을 거치게 되면) 쉽게 접근할 수 있다'라는 것이다.


대체로 분산 시스템이라는 것이 물리적으로 다른 공간에 위치한 머신들 사이에 동일한 프로세스를

마치 동일하 머신상에서 수행하는 것 처럼 처리할 수 있다는 의미일 것이다.

하지만 이러한 분산 시스템을 위해 먼저 알아 두어야 할 것이 바로 '물리적으로 분리된 공간'이라는 점이다.

이 것은 시스템의 환경을 설정할 때 뜻하지 않은 실수를 하게 만든다.

바로 호스트명 또는 서버 주소를 설정하는 부분에서 발생을 하게 되는 것이다.


오늘의 실수를 통해 이야기 해보자.


우선 Hadoop은 Standalone모드와 Pseudo-distributed모드 그리고 Fully-distributed모드로

실행할 수 있다. 각각의 모드는 특별이 데몬을 띄울 때 옵션이 있거나 한 것이 아니라 위 링크에

설명되어있는 설정파일을 어떻게 설정을 하느냐에 따라 달라진다.


Standalone : 모든 설정파일을 초기 상태로 비워둔채로 하둡을 실행한다. map/reduce 프로그램을

                       신속하게 개발/디버깅하기 위해 사용된다.

Pseudo-distributed : 모든 설정 파일에 각 노드의 주소를 모두 localhost로 입력한다. 단일한

                       머신 내에서 가상으로 분산 환경을 만들 때 사용된다.

Fully-distributed : 모든 설정 파일에서 각 노드의 주소는 실제 부여된 IP나 도메인 또는 hosts 파일에

                       등록된 이름을 사용해야 하며 각각의 머신들은 실제로 분산되어있어야 한다.


내가 처음 참조한 설치 방법에 대한 블로그는 http://blrunner.com/29였다.

그런데 이 블로거는 Pseudo-distributed로 실행할 것을 전제로 하여 설명을 하고 있다.

그런데 나는 Fully-distributed를 목표로 진행을 하고 있었다. (그래서 피같은 돈 들여 맥미니까지 추가

구매를 하였다. 근데 그놈은 현재 놀고있다…ㅠ.ㅠ)


아무 생각 없이 따라하다보니 하둡 설정이 모두 Pseudo-distributed에 맞춰진 것이다.

여기서 첫 번째 실수가 있었다.


다음으로는 원래 분산 시스템이란 것이 그런가 모르겠는데

각 머신들간의 동기화를 위해서인지 하둡 자체가 동일한 경로에 설치가 되어야한다는 것을

나중에 알았다.(혹은 위치가 달라도 설정만 별도로 해주면 되는지도 모르겠다. 아직 모르는게

더 많아서…^^;;;)


즉 A 머신의 하둡 설치 경로가 /home/mazdah/hadoop-1.0.4였다면

B 머신의 하둡 설치 경로도 /home/mazdah/hadoop-1.0.4여야 한다는 것이다.


꼭 이렇게 하지 않아도 될지 모르지만 개인적인 생각에 시스템을 아예 처음 설치하는 것이라면

디스크 볼륨 등을 통일해서 이렇게 같은 경로에 설치하는 것이 관리적인 차원에서 좋을 것 같다.


이미 다른 시스템들이  잔뜩 설치된 곳에서는 디스크 볼륨명을 함부로 바꾸기도 쉽지 않고

여러모로 헷갈릴 듯싶다.


아래는 머신간에 하둡 설치 위치가 달랐을 때와 설치 위치가 같았을 때 start-all.sh를 실행한

콘솔 메시지 내용이다.


xxx와 yyy 머신은 데이터 노드이고 localhost는 네임노드이다.

현재 /Volumes/Data2/hadoop-1.0.4로 표시되는 것은 처음 설치한 네임노드에서의 하둡 설치

위치(HADOOP_HOME)이다.


이 중 xxx 시스템의 설치 위치를 네임노드와 일치시켰더니 이후 실행 시 xxx 머신에서는

No such file or directory 메시지가 나오지 않게 되었다.


하지만 yyy노드이 경우 이미 다른 웹 시스템 및 SVN과 CI용으로 젠킨스 등이 설치된 상태라 함부로

디스크 볼륨명을 수정하기가 어려웠다. 그래서 3대의 시스템 모두 설치 위치를 /hadoop-1.0.4로

옮겨버렸다. 참으로 심플한 결정이었다…-.-


네임노드와 데이터 노드의 하둡 설치 위치가 달랐을 때


Mazdah-ui-MacBook-Pro:bin mazdah$ ./start-all.sh

starting namenode, logging to /Volumes/Data2/hadoop-1.0.4/libexec/../logs/hadoop-mazdah-namenode-Mazdah-ui-MacBook-Pro.local.out

xxx.xxxxx.xxx: bash: /Volumes/Data2/hadoop/bin/hadoop-daemon.sh: No such file or directory

yyy.yyyy.yyy: bash: line 0: cd: /Volumes/Data2/hadoop-1.0.4/libexec/..: No such file or directory

yyy.yyyy.yyy: bash: /Volumes/Data2/hadoop/bin/hadoop-daemon.sh: No such file or directory

localhost: starting secondarynamenode, logging to /Volumes/Data2/hadoop-1.0.4/libexec/../logs/hadoop-mazdah-secondarynamenode-Mazdah-ui-MacBook-Pro.local.out

starting jobtracker, logging to /Volumes/Data2/hadoop-1.0.4/libexec/../logs/hadoop-mazdah-jobtracker-Mazdah-ui-MacBook-Pro.local.out

xxx.xxxxx.xxx: bash: /Volumes/Data2/hadoop/bin/hadoop-daemon.sh: No such file or directory

yyy.yyyy.yyy: bash: line 0: cd: /Volumes/Data2/hadoop-1.0.4/libexec/..: No such file or directory

yyy.yyyy.yyy: bash: /Volumes/Data2/hadoop/bin/hadoop-daemon.sh: No such file or directory


Mazdah-ui-MacBook-Pro:bin mazdah$ ./stop-all.sh

stopping jobtracker

yyy.yyyy.yyy: bash: line 0: cd: /Volumes/Data2/hadoop-1.0.4/libexec/..: No such file or directory

yyy.yyyy.yyy: bash: /Volumes/Data2/hadoop/bin/hadoop-daemon.sh: No such file or directory

xxx.xxxx.xxx: bash: /Volumes/Data2/hadoop/bin/hadoop-daemon.sh: No such file or directory

stopping namenode

yyy.yyyy.yyy: bash: line 0: cd: /Volumes/Data2/hadoop-1.0.4/libexec/..: No such file or directory

yyy.yyyy.yyy: bash: /Volumes/Data2/hadoop/bin/hadoop-daemon.sh: No such file or directory

xxx.xxxx.xxx bash: /Volumes/Data2/hadoop/bin/hadoop-daemon.sh: No such file or directory

localhost: stopping secondarynamenode


네임노드와 데이터 노드의 하둡 설치 위치가 같아진 후


Mazdah-ui-MacBook-Pro:bin mazdah$ ./start-all.sh

starting namenode, logging to /Volumes/Data2/hadoop-1.0.4/libexec/../logs/hadoop-mazdah-namenode-Mazdah-ui-MacBook-Pro.local.out

xxx.xxxx.xxx: starting datanode, logging to /Volumes/Data2/hadoop-1.0.4/libexec/../logs/hadoop-mazdah-datanode-localhost.out

yyy.yyyy.yyy: bash: line 0: cd: /Volumes/Data2/hadoop-1.0.4/libexec/..: No such file or directory

yyy.yyyy.yyy: bash: /Volumes/Data2/hadoop/bin/hadoop-daemon.sh: No such file or directory

localhost: starting secondarynamenode, logging to /Volumes/Data2/hadoop-1.0.4/libexec/../logs/hadoop-mazdah-secondarynamenode-Mazdah-ui-MacBook-Pro.local.out

starting jobtracker, logging to /Volumes/Data2/hadoop-1.0.4/libexec/../logs/hadoop-mazdah-jobtracker-Mazdah-ui-MacBook-Pro.local.out

xxx.xxxx.xxx: starting tasktracker, logging to /Volumes/Data2/hadoop-1.0.4/libexec/../logs/hadoop-mazdah-tasktracker-localhost.out

yyy.yyyy.yyy: bash: line 0: cd: /Volumes/Data2/hadoop-1.0.4/libexec/..: No such file or directory

yyy.yyyy.yyy: bash: /Volumes/Data2/hadoop/bin/hadoop-daemon.sh: No such file or directory


첫 날부터 너무 긴 내용을 적으면 이후 진행에 애로 사항이 꽃피는데…

암튼 처음 설치다보니 삽질이 적지 않았다. 하지만 반나절 정도 삽질하고 네임노드와 데이터 노드가 정상적으로

연결된 것을 볼 수 있었으니 그리 나쁘진 않은 성적인 것 같다.

구글 아자씨들 말대로 쉽긴 쉬운가보다.

(컴퓨터를 할 줄 아는) 개나 소나 할 수 있으니…^^;;;


암튼 오늘인 여기까지

다음에는 아직 못돌려본 샘플 프로그램을 좀 돌려보고 부가적으로다가

혼자 놀게된 맥미니가 왜 혼자 놀게 되었는지(당근 네트워크 대역이 다르니…-.-)

또 거금을 들여 구입한 맥미니를 그냥 놀게 둘 수는 없으니 어떻게 활용할지에 대해 다뤄보자.

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요

최초 작성일 : 2013/05/15 13:28 


앞서 용어 정리도 해보았고

또 없는 실력에 구글의 MapReduce에 대한 논문도 한 편 번역을 해 보았다.
이제 실습을 진행할 단계인데...여전히 지식은 부족하다.
해서 교재가 한 권 필요한데...우선 현재 보유하고 있는 Hadoop 관련 서적이 한 권
있어서 이 책을 기반으로 실습을 진행하려고 한다.

교재

제목 : Hadoop 완벽 가이드
저자 : 톰 화이트
역자 : 심탁길, 김우현
출판사:O'REILLY, YAHOO RESS, 한빛미디어
초판 발행일 : 2010년 5월 30일

일단 발행일이 2010년이라 좀 오래된 감은 있지만 기본 적인 내용에 대한 변화는
없으리라 믿고 일단 진행한다. 우선 이 책을 진행 하다가 현재의 버전과 차이가
많이 난다면 그 때 새 교재를 고려해 볼 것이다.

하드웨어

다음은 하드웨어적인 준비인데 현재 내가 개인적으로 전용할 수 있는 시스템은
애플의 MAC 3대이다. 맥북프로 1대 맥미니 서버 1대 맥미니 1대
MAC으로 시스템을 구성한 이유는 일단 현재는 내가 아이폰 개발을 주력으로
하고 있기 때문이다...^^;;; 또 한편으로는 MAC OS가 윈도우즈 시스템보다는
유닉스 계열에 가까운 특성도 있어서 진행이 수월할 것 같아서이다.

어쨌든 이 중 맥북프로와 맥미니 서버는 회사에 있고 맥미니는 집에 있는데
일단 방화벽으로 인해 회사 시스템에서는 집 시스템이 연결이 되지만 집 시스템에서는
회사 시스템이 연결이 되지 않는다. 이 부분이 어떻게 해결될 수 있을지가 고민이다.

만약 전혀 쌍방향 통신의 가능성이 없다면 우선은 회사에 있는 2대로 진행을 해야겠다.

다음 가상(학습용 샘플) 서비스를 위해 필요한 데이터를 저장할 스토리지로는
그냥 2Tb 하드 2개를 USB 3.0 외장 케이스에 담아 집 시스템에 연결을 해두었다.
이 것도 역시 방화벽 문제 해결 여하에 따라 변동이 생길 것 같다.

간략한 시스템 사양은 다음과 같다.

맥북프로(Early 2011) : i7 쿼드코어 / 16Gb 램 / 256Gb SSD / 500Gb HDD
맥미니 서버 : i7 쿼드코어/ 4Gb 램 / 500Gb * 2 HDD
---------------------------------------------------------------------------------------------
맥미니 : i5 듀얼코어(4thread) / 16Gb 램 / 500Gb HDD / 2Tb * 2 USB 3.0 외장하드

서비스

현재 내가 가장 손쉽게 대량의 데이터를 얻을 수 있는 소스는 바로 트위터이다.
팔로워들의 tweet데이터를 API를 이용하여 수집을 할 예정이며 이 데이터들을 이용하여
단어 분석을 진행할 예정이다. 구체적으로 어떤 내용을 분석할 것인지에 대해서는
조금 더 학습을 진행한 후 정리하도록 하겠다.



아직은 쥐뿔도 모르지만 이렇게 준비를 하고보니 엄청 설레인다...^^;;;
열심히 준비해서 뭔가 한 번 해내야겠다~

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요

최초 작성일 : 2013/05/15 13:05 


드디어 마지막 결론입니다~~~!

그동안 발번역을 열심히 보아주신(분이 계시다면) 경의를 표합니다...^^;;;
이제 다음 주부터는 실무 연습으로 들어가야겠네요.
자세한 계획은 다음 글에...^^;;;

감사합니다.
=============================================

결론

MapReduce 프로그래밍 모델은 구글에서 여러가지 서로 다른 목적을 위해 성공적으로 사용되고 있다.
우리는 몇가지 이유로부터 이러한 성공의 결과를 찾고 있다.

첫 번째로 MapReduce의 프로그래밍 모델은 병렬화, 고장 방지, 지역 최적화, 로드 밸런싱 등의 세부적인
부분을 모두 라이브러리 내부에 감추고 있기 때문에 사용하기 쉽고 심지어 병렬이나 분산 시스템에 대한 경험이 없는
프로그래머도 사용 가능하다.

두 번째로 매우 다양한 문제들을 MapReduce 연산으로 쉽게 표현할 수 있다.
예를 들면 MapReduce는 구글의 검색 서비스, 정렬이나 데이터 마이닝, *machine learning(기계 학습),
그리고 많은 다른 시스템들을 위한 데이터를 생산해내고 있다.

세 번째로 우리는 수천대의 머신으로 구성된 대규모 클러스터를 대상으로 MapReduce 구현을 개발했다.
이러한 구현은 이러한 머신 리소스들을 보다 효과적으로 사용 가능하도록 해주며 그래서 구글에 닥친
컴퓨터와 관련된 다수의 커다란 문제점들을 다루는데 적합하다.

우리는 이 작업으로부터 몇가지를 배웠다.
첫 번째로 프로그래밍 모델을 제한하는 것이 연산을 병렬화 분산화 시키는데 쉽고
이러한 연산의 고장 관리를 하는데 쉽다는 것이다.

두 번째로 네트워크 대역폭은 부족한 자원이라는 것이다. 우리 시스템의 다수의 최적화는
데이터를 네트워크를 통해 전송하는 전송량의 감소에 초점이 맞춰져있다:로컬 최적화는 로컬 디스크로부터
데이터를 읽을 수 있도록 해주고 단일 복사본의 중간 형태의 데이터를 로컬 디스크에 기록함으로써
네트워크 대역폭을 절약하게 해준다.

세 번째로 남아도는 실행은 느린 머신들, 머신의 고장 관리, 데이터 손실 등에 의한 악영향을 감소시키는데
이용 가능하다.





machine learning
(1) 새로운 정보를 학습하고, 습득한 정보를 효율적으로 사용할 수 있는 능력과 결부시키는 지식 습득.
(2) 작업을 반복적으로 수행함으로써 결과를 얻어내는 기술의 개선 과정.
컴퓨터인터넷IT용어대사전

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요

최초 작성일 : 2013/05/09 12:26 


이제 마지막 여덟 번 째 섹션인 '결론'만 남았네요.
결론까지 다 번역하고 나면 드디어 기다리고 기다리는 실제 구축 연습니다.
빈약하지만 열심히 장비도 준비를 해놓았네요...^^;;;

오늘도 발번역 나갑니다.

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

Related Work 2

MapReduce 라이브러리의 일부인 정렬 장치는 *NOW-Sort 수행과 유사하다. 소스 머신들(map 작업자들)은
정렬을 위해 데이터를 분할하고 분할된 데이터를 R개의 reduce 작업자 중 하나에게 전달한다. 각각의 reduce
작업자들은 로컬상에서 그 데이터들을 정렬한다(가능하다면 메모리상에서 수행한다). 물론 NOW-Sort는
우리의 라이브러리에서는 광범위하게 적용 가능한 사용자 정의 Map, Reduce 함수는 가지고 있지 않다.

**River는 분산된 qeue들을 통해 데이터를 전송함으로써 프로세스들이 상호 통신하는 프로그래밍 모델을 제공한다.
River 시스템도 MapReduce처럼 이기종의 하드웨어로부터 생겨난 불균일성이나 시스템의 교란에도
훌륭한 평균 성능을 제공해준다. River는 균형잡힌 종료시간 유지를 위해 디스크와 네트워크 전송에 대한
주의 깊은 스케쥴링을 함으로써 이러한 성능을 이끌어내었다.

MapReduce는 다른 접근 방식을 취한다.
프로그래밍 모델을 제한함으로써 MapReduce 라이브러리는 문제들을 매끄럽게 수행되는 다수의 task들 사이에
분할해서 넣을 수 있다. 이러한 task들은 사용 가능한 작업자들 내에서 동적으로 스케쥴링 되고 따라서
빠른 작업자들은 더 많은 task들을 수행하게 된다.

또한 제한적인 프로그래밍 모델은 우리가 job 실행 종료 부근에서 발생하는 task들의 남아도는 실행을 스케쥴링
할 수 있도록 해줌으로써 불균일한 상황(작업자가 느려지거나 멈추는 것과 같이)이 발생하는 경우에도
훌륭하게 종료 시간을 단축시킬 수 있게 해준다.

***BAD-FS는 MapReduce와 매우 다른 프로그래밍 모델을 가지고 있다. 그리고 MapReduce와는 달리
광범위한 영역의 네트워크망 사이에서 job들을 실행시킬 목적으로 만들어졌다. 그러나 2가지 근본적인 유사성이 있다.
(1) 양 시스템은 고장으로 발생하는 데이터 손실을 복구하기 위해 남아도는 실행을 이용한다.
(2) 양 시스템은 혼잡한 네트워크간의 데이터 전송량을 줄이기 위해 지역 기반의 스케쥴링을 이용한다.

****TACC는 고가용성의 네트워크 서비스를 단순하게 구축하기 위해 고안되었다.
MapReduce처럼 내고장성을 구현하기 위해 재실행 매커니즘을 이용한다.



*NOW-Sort
Andrea C. Arpaci-Dusseau, Remzi H. Arpaci-Dusseau, David E. Culler, Joseph M.
Hellerstein, and David A. Pat- terson.
High-performance sorting on networks of work- stations.
In Proceedings of the 1997 ACM SIGMOD In- ternational Conference on Management of Data,
Tucson, Arizona, May 1997.

**River
Remzi H. Arpaci-Dusseau, Eric Anderson, Noah Treuhaft, David E. Culler, Joseph M.
Hellerstein, David Patterson, and Kathy Yelick.
Cluster I/O with River: Making the fast case common.
In Proceedings of the Sixth Workshop on Input/Output
in Parallel and Distributed Systems (IOPADS ’99), pages 10–22,
Atlanta, Georgia, May 1999.

***BAD-FS
John Bent, Douglas Thain, Andrea C.Arpaci-Dusseau, Remzi H.
Arpaci-Dusseau, and Miron Livny.
Explicit control in a batch-aware distributed file system.
In Pro- ceedings of the 1st USENIX Symposium on Networked Systems Design
and Implementation NSDI, March 2004.

****TACC
Armando Fox, Steven D. Gribble, Yatin Chawathe, Eric A. Brewer, and Paul Gauthier.
Cluster-based scal- able network services.
In Proceedings of the 16th ACM Symposium on Operating System Principles,
pages 78– 91, Saint-Malo, France, 1997.

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요

최초 작성일 : 2013/05/03 13:04 


=============================================
문서의 막바지에 다다르니 전문 용어 및 원서와 논문들의 인용구가 많아
독해에 어려움이 많네요...ㅠ.ㅠ

이미 앞서 올린 글을 통해 발번역인 거 다 아셨으니 그냥 그러려니 하고 보세요...ㅠ.ㅠ
=============================================

Related Work

많은 시스템들이 제한된 프로그래밍 모델들을 제공하고 자동으로 연산의 병렬화를 하는데 그 제약을 사용한다.
예를 들면 associative 함수는 parallel prefix computations[6, 9, 13]을 이용하여 N개의 프로세서 상에서
log N의 시간 동안 N개의 요소를 가진 배열의 모든 접두어에 대해 연산이 수행된다.

MapReduce는 거대한 실세계에서의 연산에 대한 우리들의 경험을 기반으로 이러한 프로그래밍 모델들의 일부에 대한
간소화와 정제가 고려되어있다.

보다 주목할 만한 것은 우리는 수천개의 프로세서에 대한 고장 방지 구현을 제공한다는 것이다.
반면에 대부분의 병렬 프로세싱 시스템들은 단지 작은 규모의 구현만을 제공하거나 머신의 고장에 대한 관리를
프로그래머에게 맡기고 있다.

*Bulk Synchronous Programming과 일부 **MPI primitives는 높은 수준의 추상화를 제공하고
이를 통해 개발자들이 병렬 프로그램을 작성하기 쉽도록 해준다. 이러한 시스템들과 MapReduce 간의 명확한 차이는
MapReduce가 사용자의 프로그램을 자동으로 병렬화 할 수 있는 제한적 프로그래밍 모델을 활용하고 있다는 점과
고장 방지 기능의 투명성을 제공하고 있다는 점이다.


우리의 지역 최적화는 ***active disks와 같은 기술로부터 영감을 얻어 구현하고 있다.
active disk에서는 I/O 서브시스템들간에 데이터를 주고 받는 전송량이나 네트워크 전송량을 줄이기 위해
연산 수행에 필요한 요소들이 있는 로컬 디스크에서 연산이 수행되도록 한다.

우리는 디스크 관리 프로세서상에서 직접 수행하는 대신 소수의 디스크가 직접 연결된 일반적인 상용 프로세서상에서
프로세스를 수행하며 그밖의 일반적인 접근은 active disk와 유사하다.

우리의 백업 task 매커니즘은 ****Charlotte System에 채택되어있는 eager scheduling과 유사하다.
간단한 eager scheduling의 단점 중 하나는 주어진 task가 반복적인 오류를 발생시킬 경우 전체 연산의
완료가 실패한다는 것이다. 우리는 잘못된 레코드를 무시하고 넘어가는 우리의 매커니즘을 통해 이러한 문제를 가진
몇몇 인스턴스를 수정하였다.

MapReduce의 구현은 내부 클러스터 관리 시스템에 의존한다.
내부 클러스터 관리 시스템은 대규모 공유 머신들의 집합체 상에서 분산과 사용자 task 수행을
책임지고 있다. 이 문서의 논점에서 벗어나지만 클러스터 관리 시스템은 *****Condor와 같은 다른 시스템들과
그 기본 사상이 유사하다.



-> 아래 내용은 원문에 등록된 참고 문헌들입니다.

*Bulk Synchronous Programming
L.G.Valiant.Abridgingmodelforparallelcomputation.
Communications of the ACM, 33(8):103–111, 1997.

**MPI primitives
William Gropp, Ewing Lusk, and Anthony Skjellum.
Using MPI: Portable Parallel Programming with the Message-Passing Interface.
MIT Press, Cambridge, MA, 1999.

***techniques such as active disks
L. Huston, R. Sukthankar, R. Wickremesinghe, M. Satya- narayanan, G. R. Ganger,
E. Riedel, and A. Ailamaki.
Di- amond: A storage architecture for early discard in inter- active search.
In Proceedings of the 2004 USENIX File and Storage Technologies FAST Conference,
April 2004.

Erik Riedel, Christos Faloutsos, Garth A. Gibson, and David Nagle.
Active disks for large-scale data process- ing.
IEEE Computer, pages 68–74, June 2001.

****Charlotte System
Arash Baratloo, Mehmet Karaul, Zvi Kedem, and Peter Wyckoff.
Charlotte: Metacomputing on the web.
In Pro- ceedings of the 9th International Conference on Parallel and
Distributed Computing Systems, 1996.

*****Condor
Douglas Thain, Todd Tannenbaum, and Miron Livny.
Distributed computing in practice: The Condor experi- ence.
Concurrency and Computation: Practice and Ex- perience, 2004.

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요

최초 작성일 : 2013/04/23 12:47 


지금까지의 MapReduce 사용에 있어 가장 주목할만한 점 한가지는 구글의 웹 검색 서비스에 사용되는
데이터 구조를 생성하는 production indexing 시스템을 완전히 다시 작성했다는 것이다.
indexing 시스템은 우리의 crawling 시스템이 검색해오는 대량의 문서 셋을 입력값으로 받아
GFS 파일 셋으로 저장한다. 이러한 문서 셋의 원본 내용들은 20 테라바이트 이상의 데이터들이다.
indexing 수행은 5개에서 10개 정도의 MapReduce 업무가 순차적으로 진행되면서 이루어진다.
(이전 버전의 indexing 시스템에서 ad-hoc distributed passes를 사용하는 대신에)MapReduce를
이용하는 것은 몇가지 이익을 준다.

• MapReduce 라이브러리 내에 오류(실패) 관리, 분산과 병렬 처리에 대한 코드들이 감춰져있기 때문에
  indexing 코드는 보다 단순하고 작고 이해하기 쉬워진다. 예를 들면 한 단위의 연산을 수행하는
  C++ 코드는 MapReduce로 구현할 겨웅 약 3800라인에서 700라인 정도로 감소한다.
 
• MapReduce 라이브러리는 개념적으로 관련이 없는 연산을 데이터에 대한 추가적인 전달을 회피하기 위해
  뒤섞어 놓는 대신에 서로 분리되도록 유지하는데 충분한 성능을 발휘한다.
  이 것은 indexing 프로세스을 변경하기 쉽게 하였다.
  일례로 예전의 indexing 시스템이 수개월 동안 걸려 처리한 변경작업을 새로운 시스템을 구현하여
  몇일만에 처리하였다.
 
• 머신의 고장, 느려진 머신, 네트워크의 일시적인 중단 등이 작업자의 개입 없이
  MapReduce에서 자동으로 관리되기 때문에 indexing 프로세스는 보다 운영하기 쉬워졌다.
  게다가 indexing 클러스터에 머신을 추가함으로써 indexing 프로세스의 성능을 개선하기도 쉬워졌다.

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요

최초 작성일 : 2013/04/19 12:57 


Experience

MapReduce 라이브러리의 최초 버전은 2003년 2웖에 만들어졌다.
그리고 locality 최적화, 작업자 머신들 간에 task 수행에 있어서의 동적인 로드 밸런싱 등  
괄목할만한 개선이 2003년 8월에 이루어졌다.

그 때부터 우리는 우리가 작업하는 곳에서 발생하는 다양한 문제점을 해결하는데 MapReduce 라이브러리가
얼마나 광범위하게 적용 가능한지를 알고 환호했다.

MapReduce는 Google 내의 광범위한 도메인에 사용되어 다음과 같은 역할을 하였다.

* 대규모 머신에서 배우는 문제들
* 구글 뉴스와 Froogle의 생산물에 대한 클러스링 문제들
* 인기있는 쿼리들(Google Zeitgeist같은)의 보고서에서 만들어지는 데이터의 추출
* 새로운 실험을 위한 웹페이지나 생산물들의 속성 추출 (예를들어 지역화된 검색을 위한 대규모
실험용 웹페이지로부터 지리적인 위치를 추출하는 것).
* 대규모 그래프 연산





Figure 4는 우리의 주요한 소스 코드 관리 시스템에 2003년 초 0개로부터 2004년 9월 말의
900개의 분산된 인스턴스에 이르기까지 등록된 분산 MapReduce 프로그램이 등록된 수의 주목할만한
성장을 보여준다.

MapReduce는 간단한 프로그램을 짜고 그 것을 수천대의 머신들에서 효과적으로 실행시키는데
30분 정도의 시간이면 가능하도록 하여 개발과 프로토타이핑의 속도를 매우 높였다는데 있어
꽤 성공적이다.

더 나아가서 분산이나 병렬처리 시스템경험이 없는 개발자들로 하여금 많은 양의 리소스를 쉽게
이용 가능하게 해준다.

MapReduce 라이브러리는 각각의 job 끝에 job이 연산에 사용한 자원들에 대한 통계를 로그로 남긴다.
Table 1은 2004년 8월 Google에서 실행된 MapReduce job들의 서브셋에 대한 통계를 보여준다.

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요

최초 작성일 : 2013/04/17 13:17 






Effect of Backup Task

Figure 3 (b)에서 우리는 backup task들이 비활성화된 정렬 프로그램의 실행을 볼 수있다.
프로그램 실행의 흐름은 과도한 쓰기 작업이 있는 경우에 완료 시점까지 long tail 현상이
나타난다는 것을 제외하면 Figure 3 (a)와 유사하다.

960초 이후 5개의 reduce task들을 제외한 모든 수행이 완료되었다. 그러나 이 마지막의
straggler들은 이후 300초가 지날 때까지 끝나지 않았다. 모든 연산은 1283초가 걸렸으며
소요시간이 44% 증가하였다.

Machine Failure

Figure 3 (c)에서는 연산 중에 1746개의 작업자를 제외한 200개의 작업자를 의도적으로
몇분간 중지시킨 상태의 실행을 보여준다.

x축 아래로 내려간 클러스터 스케쥴러는 즉시 머신들 상의 새 작업자로 재시작 되었다
(프로세스들이 죽었지만 머신들은 여전히 정상적으로 동작했다).

작업자가 죽는 것은 앞서 완료됐어야 할 몇몇 map 작업이 사라졌고(통신할 map 작업자가 죽었고)
그리고 이전 상태로 되돌려져야 하기 때문에 마이너스 입력 속도를 보여준다.

이러한 map 작업의 재실행은 비교적 신속하게 이루어진다.
전체 연산은 시작시의 부하를 포함해 933초만에 끝났다(일반적인 수행에 비해 단지 5%만 상승했다).

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요

최초 작성일 : 2013/04/11 12:22 


Sort

sort 프로그램은 10의 10승개의 100바이트 크기 레코드들을 정렬한다.(약 1테라바이트의 데이터이다.)
이 프로그램은 *TeraSort benchmark 이후에 모델링 되었다.

소팅 프로그램은 50 줄도 안되는 사용자 코드로 구성되어있다.
3줄의 Map 함수는 text문서의 라인으로부터 10바이트의 정렬 키를 추출하고
이 키와 원래 문서의 라인을 key/value 쌍으로 뽑아낸다.

우리는 라이브러리에 내장되어있는 Identity(항등)함수를 Reduce 연산자로 사용할 것이다.
이 함수는 중간형태의 key/value 쌍을 아무 변화 없이 출력 key/value 쌍으로 보낸다.
정렬된 최종 출력은 2방향으로 복제된 GFS 파일로 저장된다.
(프로그램의 출력 값으로 2테라바이트의 데이터가 작성된다.)

이전과 마찬가지로 입력 데이터는 64Mb 크기의 조각(M = 15000)으로 분할된다.
그리고 4000개(R = 4000)의 파일들에 정렬된 출력값들을 나누어 저장한다.
이 분할 함수는 데이터의 최초 바이트를 이용하여 분할된 R 중 하나에 출력값들을
나누어 넣게 된다.

이 벤치마크를 위한 분할 함수는 키 분산에 대한 지식 기반으로 만들어졌다.
우리가 MapReduce 수행의 전단계에 추가하려고 하는 일반적인 정렬 프로그램은
key들의 샘플을 모아서 마지막 정렬 단계를 위해 계산된 분할 포인트로 샘플 키들을
분산하는데 사용된다.





Figure 3의 (a)는 일반적인 정렬 프로그램의 실행을 보여준다.
좌측 상단이 그래프는 입력 값을 읽는 실행 속도를 보여준다.
실행 속도는 약 13 GB/s 정도에서 최고점에 이르렀다가 모든 map task가 종료 되기 전
200초 정도 지난 시점까지 상당히 빠르게 감소하다가 종료된다.

입력 값을 읽어들이는 실행 속도가 grep 함수 실행보다 짧다는 것에 주목하라.
이것은 정렬을 위한 map task들이 그들의 로컬 디스크에 중간 파일들을 저장하는데
절반 가량의 시간과 I/O 대역폭을 사용하기 때문이다.

grep을 위한 중간 형태의 출력 파일은 무시해되 될 정도의 크기이다.

좌측 중앙의 그래프는 데이터가 map task로부터 reduce task로 네트워크를 통해
전송되는 속도를 보여준다. 이 shuffling은 첫 번째 map task가 완료 되자마자 시작된다.
그래프에서 첫 번째로 높아진 부분은 약 1700여개의 reduce task들의 첫번째 배치 작업에 대한
값이다(전체 MapReduce는 약 1700여대의 머신들에 배치되어있고 각각의 머신은 한번에
최소한 1개의 reduce task를 실행한다).

연산이 진행되는 약 300초 동안 이 첫 번째 reduce task들의 배치 중 몇몇은 종료가 되고
남아있는 reduce task들을 위해 shuffling을 시작한다. 모든 shuffling은 약 600초 정도
연산을 수행한 후 완료된다.

좌측 하단의 그래프는 정렬된 데이터를 reduce task를 통해 최종 출력 파일에 저장하는 속도를 보여준다.
첫 shuffling이 끝나는 시점과 파일 기록 시점에는 지연이 발생하는데 이는 머신이 중간 데이터를
정렬하는데 부하가 걸리기 때문이다.

쓰기 작업은 잠시동안 약 2~4GB/s의 속도로 계속된다.
850초 무렵 정렬연산 내의 모든 쓰기 작업이 종료된다.

초기 기동시의 부하를 포함하여 전체 연산에는 891초가 소요되었다.
이 것은 현재까지 보고된 TeraSort 벤치마크의 가장 좋은 기록인 1057초와 근접한 값이다.

알아두어야 할 몇가지 사항은 우리의 로컬 최적화를 통해 대부분의 데이터가 비교적 제약이 있는
네트워크를 우회하여 로컬에서 읽혀지기 때문에 입력 속도는 shuffle 속도나 출력 속도보다 빠르다는
것이다. shuffle 속도는 출력 속도보다 빠른데 이는 출력 단계에서는 정렬된 데이터를 복사하여
2벌의 데이터를 기록하기 때문이다(우리는 신뢰성과 가용성을 높이기 위해 출력 데이터의 복제본을
만든다). 우리는 2개의 복제된 데이터를 기록하는데 이는 신뢰성과 가용성이 우리의 기반
파일시스템으로부터 제공받도록 만들어진 메커니즘 때문이다.

복제가 아닌 삭제 기능의 코드를 사용할 경우 데이터 기록을 위한 네트워크 대역폭에 대한 요구는
더욱 감소한다.
 


*TeraSort benchmark
Jim Gray. Sort benchmark home page.
http://research.microsoft.com/barc/SortBenchmark/.

블로그 이미지

마즈다

이제 반백이 되었지만 아직도 꿈을 좇고 있습니다. 그래서 그 꿈에 다가가기 위한 단편들을 하나 둘 씩 모아가고 있지요. 이 곳에 그 단편들이 모일 겁니다...^^

댓글을 달아 주세요