물론 아직 형태소 분석기는 작동시켜서 한건 아니였지만, 참으로 재미난 경험이였다.

문서를 (term, docids)로 만들기위해서, 문서 파싱하고 텀단위 추출하기 위한 map,reduce작업, 그리고 그것들을 역파일 구조로 만들기 위한 combine과 reduce 작업을 했다. 여기서 가장 고민을 많이 했던점은 Docid를 제너레이션 하기가 쉽지 않았다는 것이다.(이것은 피보나치 수열을 mapreduce모델로 제너레이션 하기 힘든것과 비슷한 문제다. )
솔직히 Class 객체하나에 static 멤버변수를 모든 노드에서 공유할것이라는 예상은 보기좋게 빗나갔다. 그래서 Docid를 제너레이션 하기 힘들었다. (하긴 이정도 까지 할라면 mutex lock같은게 필요해서 병목이 발생할수도 있으니…)

빨리 테스트 하기 위해서 url을 키로 잡고 1G정도의 블로그 데이터로 처리해보고 결과보고 했다. 역시나 text 문자열 매칭은 속도가 많이 잡히는 것이니, Docid를 사용하면 더 속도가 날것이란 생각이 든다.

hadoop을 테스트 해보면서 가장 많이 드는 생각은, 너무 문서가 미비하다는것(심지어 javadoc도..), 소스보고 예상해서 테스트를 직접 해봐야 한다는것이다. 그나마 정말 다행인것은 예상을 빗나가든 정확히 들어맞던지간에 처리되는 결과를 보자면 마구마구 적용할수 있는 분야의 다양함이 눈에 보인다는것이다.

hadoop에서 쓰이는 mapreduce의 모든 관련 함수는 이제 다 알것같은데, 도저히 Job 스케줄링은  조금 개념잡기가 힘들다. 이것보다 더 힘든부분은 노드간 통신하는 부분이겠지..

통신하는 부분도 네트워크에 대한 부하를 조금이라도 줄여보기 위한 부분이 많이 눈에 띄인다. tcp의 conjestion control개념등등….

hadoop에 contribute할 부분이 속속들이 눈에 띄지만 좀 메일링 리스트를 보면서 감을 더 잡아보기로 하자!

이제 hadoop을 테스트 하고,분석할수 있는 시간은 많이 잡아야 1주일….. 그 기간에 빨리 정리를 할수 있었음 좋겠다.

ps. 대용량을 분산처리함으로 인해서 색인 주기를 획기적으로 줄일수 있을거 같다는 생각이 든다.

Hadoop으로 Distribute indexing을 시뮬레이션 해보고나서…. by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.