출처: http://www.jaso.co.kr/130
hadoop 파일 write 시간 측정 결과
- 파일 사이즈 : 48MB
- replication : 1
- write 시간 : 3.1초
- replication : 5
- wrtie시간 : 3.06초
scp를 이용한 다른 머신으로 복사 : 1.3초
hadoop 파일 write 시간 측정 결과
- 파일 사이즈 : 48MB
- replication : 1
- write 시간 : 3.1초
- replication : 5
- wrtie시간 : 3.06초
scp를 이용한 다른 머신으로 복사 : 1.3초
replication 수에 따른 성능 차이는 없는 것으로 생각됨
이유는 pipe 형태로 DataNode1 -> DataNode2 -> DataNode3 로 전송되기 때문에 이것에 대한 속도 오버헤드는 없음.
scp와의 성능 차이는 Hadoop의 경우 OutputStream으로 write()를 호출하게 되면 바로 DataNode로 전송하는 것이 아니라 client의 로컬 디스크에 저장한 후 block size(64MB)가 차거나 OutputStream이 close() 될 때 로컬 파일을 처음부터 다시 읽어 DataNode로 전송하기 때문. 여기에 1 write, 1 read 만큼의 오버헤드가 있음
왜 이렇게 구현했는지는 메일링 리스트에 올려서 물어봐야 할 것 같다.
이유는 pipe 형태로 DataNode1 -> DataNode2 -> DataNode3 로 전송되기 때문에 이것에 대한 속도 오버헤드는 없음.
scp와의 성능 차이는 Hadoop의 경우 OutputStream으로 write()를 호출하게 되면 바로 DataNode로 전송하는 것이 아니라 client의 로컬 디스크에 저장한 후 block size(64MB)가 차거나 OutputStream이 close() 될 때 로컬 파일을 처음부터 다시 읽어 DataNode로 전송하기 때문. 여기에 1 write, 1 read 만큼의 오버헤드가 있음
왜 이렇게 구현했는지는 메일링 리스트에 올려서 물어봐야 할 것 같다.
이 문제에 대한 해답
http://issues.apache.org/jira/browse/HADOOP-445
로컬의 파일을 읽어 아무런 작업을 하지 않고 hadoop으로 upload하는 경우라면 이렇게 처리하는 것이 불필요한 처리를 더 하는 것 처럼 보이지만 일반적인 애플리케이션의 경우에서는 연산을 처리하고 연산된 결과를 파일로 저장하고 이런 내용을 계속 반복한 후 close() 하게 된다.
이때 연산을 처리하는데 시간이 오래 걸릴 경우 write()또는 flush()할때 서버로 바로 전송하는 경우라면 소켓을 오랜 시간동안 열고 있어야 하거나 매번 보낼때 마다 소켓을 다시 열어야 하는 오버헤드가 있다.
http://issues.apache.org/jira/browse/HADOOP-445
로컬의 파일을 읽어 아무런 작업을 하지 않고 hadoop으로 upload하는 경우라면 이렇게 처리하는 것이 불필요한 처리를 더 하는 것 처럼 보이지만 일반적인 애플리케이션의 경우에서는 연산을 처리하고 연산된 결과를 파일로 저장하고 이런 내용을 계속 반복한 후 close() 하게 된다.
이때 연산을 처리하는데 시간이 오래 걸릴 경우 write()또는 flush()할때 서버로 바로 전송하는 경우라면 소켓을 오랜 시간동안 열고 있어야 하거나 매번 보낼때 마다 소켓을 다시 열어야 하는 오버헤드가 있다.