gimmesilver's blog

Agbird.egloos.com

포토로그



하둡의 내부 I/O 동작 분석 글 데이터분석

http://cto.vmware.com/analyzing-hadoops-internals-with-analytics/

VMWare 라는 회사의 누군가가 하둡의 I/O 동작 방식에 대해 분석한 글
한 줄로 요약하자면 하둡의 MapReduce 에서는 중간에 I/O가 참 많이 발생한다... 정도가 되겠다.

글의 마지막에 보면 몇 가지 질문을 던지고 있다.

 우선 하둡은 map task 실행 시 가급적 해당 task가 처리할 데이터가 있는 노드에서 실행되도록 job tracker가 task를 할당하고 있는데 글쓴이가 실제 실험을 해보니 원격 노드에서 실행을 하더라도 그에 따른 부하가 전체 I/O에서 그리 크지 않은 것 같다고 했다.
 이건 테스트를 위해 사용한 예제가 데이터 정렬이었기 때문에 그렇다. 데이터 정렬은 그 특성상 Map 에서 처리하는 데이터와 Reducer로 넘어가는 데이터 양이 동일한데, 원래 MapReduce 모델은 maper에서 로컬 데이터를 처리해서 reducer로 넘어갈 때 데이터 양을 줄일 수 있는 로직이 큰 성능 효과를 발휘하는 모델이다.
 이게 만약 정렬이 아니라 combiner가 적용된 word counter 같은 예제였다면 결과는 크게 다를 것이다.

 또 map task는 결과를 로컬 디스크에 저장하고 reducer가 web proxy를 이용해서 각 map task의 결과물을 가져가는 방식인데, 글쓴이는 map 결과를 HDFS에 저장하는 것이 좀 더 단순해서 reducer 최적화에 유리하지 않을까라는 질문을 하고 있다.
 이에 대한 내 생각은 다음과 같다.

 첫 째, HDFS에 저장하게 되면 복사본을 추가로 저장하는 부담이 생긴다. HDFS는 기본 설정이 3개의 복사본을 저장하게 되어 있기 때문에 각 map task 결과물을 HDFS에 저장하려면 2번의 추가적인 I/O가 발생한다. 게다가 이 추가적인 쓰기 작업은 모두 원격 I/O이다.

 둘 째, HDFS에 저장하게 되면 map task는 다른 노드의 장애에 영향을 받게 된다. map task 결과를 로컬에 저장하게 되면 해당 노드의 장애에만 영향을 받게 되지만 HDFS에 저장하면 data node 의 장애도 수행 시간이나 결과에 영향을 줄 수 있다. 게다가 map task가 수행되는 노드에 장애가 나거나 반대로 저장하는 data node에 장애가 나거나 혹은 둘 다 문제가 생겼을 때 등 장애 처리를 위해 고려해야 할 경우의 수가 더 많아져서 장애 처리 로직이 복잡해 진다. (그렇지 않아도 map 결과를 저장하는 로직은 하둡 전체 소스를 통털어 가장 복잡한 로직이다.)

 그 외에 네트워크 대역폭이 10GB 정도로 크면 지역성이 크게 의미없지 않을까? 라는 질문도 있다. 즉, 이 정도 대역폭이면 디스크I/O나 네트워크 I/O나 성능이 비슷하지 않겠냐는 뜻 같다. 하지만 분산 시스템에서 네트워크는 일종의 공공재이기 때문에 다른 작업에 대한 영향력을 생각해야 한다. 따라서 단일 작업에서의 성능은 차이가 없더라도 여러 job을 한꺼번에 돌리는 상황에서는 locality가 여전히 중요한 최적화 요소일 것이다.

 암튼 뭐 내 생각은 이렇고 다음 번에 자신의 질문에 대한 내용으로 글을 쓰겠다고 하니 어떤 내용일지 한번 봐야 겠다.

덧글

댓글 입력 영역