hadoop을 사용하면서 다양한 문제에 부딛히게 되었지만, 그 중에서도 가장 빈번히 당혹스럽게 하는
것은, collect과정에서의 에러들.
같이 일하는 shurain군은, 그런 에러들을 보면서 한마디 하곤한다.
"대체, 이럴때 제가 할 수 있는 일이 뭐가 있죠?"
코드 상의 버그도 아니고, 설정상의 오류도 아니고, 그저, 파일에 써보렴! 이라고 했는데
다양한 에러들을 뱉어내며 죽어버리는 task들을 볼땐, 나도 저 말이 떠오르곤 한다....
map 과정에서의 collect와 reduce 과정에서의 collect는 약간 다른 동작을 가지고 있지만,
공통적으로 들어가는 것은,
1. memory byte buffer로 collect된 객체들을 쓴다.
2. 납득할 수 없는 아주 저렴한? 알고리즘으로 계산된 buffer overflow계산을 통해,
buffer가 꽉 차면 flush 한다...
stream이라면, 누가 하더라도 당연히 갖고 있는 두 가지 과정인데..
희한하게도 hadoop은 저 과정들을 제대로 수행하지 못하는 경우가 태반이다.
좀 더 세세히 살펴보아야 하겠지만,-전혀 그러고 싶은 욕구는 생기지 않는다- 예상되는 바로는
1.저렴한, 아주 저렴한...누구도 납득할 수 없는 buffer overflow계산 알고리즘..의 문제.
황당하게도, stream인 주제에, out of memory를 내며 뻗는 경우도 있으니..할말 다했지..
2.flush를 하는 과정에서 buffer를 나눠 쓰는 알고리즘의 문제.(이건 안열어봤다.)
3.collect과정에서 즉, mapreduce package쪽 buffer를 1차로 거치고, dfs쪽에서 다시 stream을
사용하면서 buffer를 거치는데, 역시나 1과 연관된 이유로 인한 이중으로 사용되는 buffer를
제대로 처리하지 못하는 문제...
등이 머리속에 떠오른다.
뭐, 코드야 어찌되었던, hadoop을 고쳐주고 싶은 마음은 이제 생기지 않기 때문에,
대충의 해결책을 찾았는데...
collect를 호출하지 않고, output format으로부터 직접 writer를 가져와 write를 통해 쓰거나,
이것도 미심쩍은 경우에는, 직접 output format을 작성하는 것이다.
아마도, hadoop내의 mapreduce 쪽 코드보다는 dfs쪽이 좀더 안정화되어 있는듯,
collect를 통하지 않은 write만으로도 대부분의 에러상황을 피해갈 수 있다.
덧붙이기 : 여기 써놔봐야..읽을 수 있겠냐마는, 아무리 오픈소스라지만, 제발 니 머리속에서만
검증된 코드들을 작성해서 commit 하지 말란말이다...
-------------------------------------------------------------------------------------- 여기저기 확인해본 결과, hadoop 의 buffer 사용 쪽의 code들이 전체적으로 불만족 스러운듯. buffer size에 대한 soft limit을 적용한 결과.. 필수적으로 필요한 memory를 확보하지 못한채 flush 를 시작한다던가, 아예 flush도 못하고 그냥 죽어버린다던가..... 이에 대해...답변은...쩝. 좋은 컴퓨터에 메모리 많이 잡고...돌려라..정도라니 =_=; stream에서 out of memory 뜨는 걸 확인하는 순간...심각하게 고민을 해봤어야했다고. 이제와서 조금 후회중.
태그 : 
