Hadoop을 실제 업무에 사용하기 위한 조건
- Posted at 2007/03/26 12:39
- Filed under project/lucene_hadoop
Hadoop을 실제 업무에 사용하기 위해서는 많은 어려움을 극복해야 할 것 같다.
가정 먼저 극복해야 할 문제가 속도에 대한 문제인 것 같다.
Hadoop의 Map&Reduce도 분산컴퓨팅을 위한 한 분류라고 보았을 때 클러스터의 Node 수와 수행속도 사이에는 다음과 같은 그래프가 그려져야 한다.
2번 라인이 분산컴퓨팅을 구축하는 조직에서 원하는 전형적인 그래프 모습일 것이다.
1번 라인은 실제 클러스터에서 발생할 수 있는 그래프이다. 노드수가 일정 수준이상 증가하게 되면 관리 정보가 많아지고 이들 정보를 관리하기 위해 더 많은 오버헤드가 발생하기 때문이다.
3번 그래프는 분산컴퓨팅 자체의 오버헤드 등의 문제로 인해 선형적으로 증가는 하지만 효율이 낮은 경우이다.
hadoop의 경우 3번에 걸릴 가능성이 높다는 것이다. Mapr&Reduce 자체가 Map -> Output -> Reduce -> Output 와 같이 중간 작업 파일을 만들고, 자바로 만들어졌기 때문에 I/O에 처리에 대한 오버헤드와 String 연산에 대한 오버헤드가 크기 때문이다. 물론 이런 것들은 Hadoop의 자체의 문제라기 보다는 외부적인 환경에 의해 좌우될 수도 있다. I/O 문제는 JDK6.0의 NIO 기능을 이용하면 해결될 수도 있다. String 연산에 대한 문제는 C언어 처럼 byte 단위로 처리하게 구현하면 된다.
하지만 아직까지 hadoop내의 기본 구현(TextInputFormat)에서는 이런 부분에 대한 세밀한 튜닝은 되지 않은 상태이다.
가정 먼저 극복해야 할 문제가 속도에 대한 문제인 것 같다.
Hadoop의 Map&Reduce도 분산컴퓨팅을 위한 한 분류라고 보았을 때 클러스터의 Node 수와 수행속도 사이에는 다음과 같은 그래프가 그려져야 한다.

2번 라인이 분산컴퓨팅을 구축하는 조직에서 원하는 전형적인 그래프 모습일 것이다.
1번 라인은 실제 클러스터에서 발생할 수 있는 그래프이다. 노드수가 일정 수준이상 증가하게 되면 관리 정보가 많아지고 이들 정보를 관리하기 위해 더 많은 오버헤드가 발생하기 때문이다.
3번 그래프는 분산컴퓨팅 자체의 오버헤드 등의 문제로 인해 선형적으로 증가는 하지만 효율이 낮은 경우이다.
hadoop의 경우 3번에 걸릴 가능성이 높다는 것이다. Mapr&Reduce 자체가 Map -> Output -> Reduce -> Output 와 같이 중간 작업 파일을 만들고, 자바로 만들어졌기 때문에 I/O에 처리에 대한 오버헤드와 String 연산에 대한 오버헤드가 크기 때문이다. 물론 이런 것들은 Hadoop의 자체의 문제라기 보다는 외부적인 환경에 의해 좌우될 수도 있다. I/O 문제는 JDK6.0의 NIO 기능을 이용하면 해결될 수도 있다. String 연산에 대한 문제는 C언어 처럼 byte 단위로 처리하게 구현하면 된다.
하지만 아직까지 hadoop내의 기본 구현(TextInputFormat)에서는 이런 부분에 대한 세밀한 튜닝은 되지 않은 상태이다.
Posted by 김형준
- Response
- No Trackback , No Comment
Trackback URL : 이 글에는 트랙백을 보낼 수 없습니다






