약 4일동안 Hadoop을 가지고 놀고 있다. 논다기 보다는, 약간의 삽질과 개념 이해를 위해 코딩 약간… 정도. (가장 힘들었던것은 역시나 한글 코드가 깨지는 것이였다. 물론 하루 반나절만에 해결을 했다. 이런 삽질은 역시나 빨리 해결하려고 하는게 정신 건강에 좋다. 이자리는 빌어 김형준님에게 감사드린다. JVM fork관련된 충고가 없었다면 이렇게 빠르게 해결하지 못했을 것이다.)

전에 Distribute Sort에 대해서 한번정도 생각해 본적이 있다.
그러니까, 엄청나게 많은 데이터를 한PC에 넣지 못할경우 이것을 분산시켜서 저장해 놓고 한 클라이언트 PC에서 소팅된 데이터를 받는 방법을 고민했었다.

그렇게 하기 위해서 각 노드마다 Sort를 하고 가장 큰값을 가져와서 그중에 큰것을 클라이언트에 보내고 그 다음 값을 또 비교해서 보내고 하는 과정을 반복하면 Top N개에 대한 Sorting된 데이터를 가져올수 있다.

위와 비슷한 개념을 Hadoop에서 쓰더라.

Key, Value 값의 Pair를 가지고 Reduce작업을 하는데, 일단 Reduce작업은 Key값을 기준으로 작업이 되어서 같은 Key를 빨리 찾는 방법이 Performance를 향상 시키는 키가 된다. 그래서 Hadoop 내부적으로 각 노드를 Sort해서 가지고 있는 것이다.
Sort된 데이터를 각 노드에 가지고 있다면, 한 Key에 대해서 Value값에 대한 처리를 할때 각 노드의 처음 Key값이 현재 처리중인 Key값보다 크다면 다음 값들을 일일이 확인해서 Key비교를 할 필요가 없는것이다. early termination이 되는 것이다.(hadoop은 디폴트 sort가 오름차순이다. )
각 노드의 처음값을 가져오는 작업을 반복적으로 함으로써 같은 Key 값에 대한 처리를 효율적으로 할수 있는 것이다.

그 외에도 Map, Reduce 함수 말고 combine이라는 개념도 있던데, 이것은 map하고 데이터를 쓰기 전에 그 노드에서 같은 Key값을 가지는것들을 combine하는 것이다. 이렇게 함으로써 Reduce함수가 하는 일이 줄어드는 것이다.

한 4일 가지고 이것저것 해본 소감은 현재로서 Hadoop의 소스코드에 대한 이해와 작동방식에 대한 이해가 없이 절대 Hadoop을 쓸수 없다는 생각을 했다. 실제 내림차순 Sorting만 한다고 해도 Hadoop 내부의 클래스를 오버라이딩 해서 재구현 한다음에 써야 하기 때문이다. (다시말하지만 Hadoop의 기본 Sorting은 오름차순이다. )
핸들링하고자 하는 데이터에 따라 수많은 수작업이 필요할거라는 형준님의 말씀이 일리 있음이 이제 이해가 간다.

예제코드 열심히 만들고, 데이터 준비하고 열심히 테스트하고 검색의 어느부분에 쓰이면 좋을지 고민해 봐야 겠다.

ps. 이제는 nutch 크롤러에 쓰인 hadoop도 이해를 할수 있을거 같다.

Hadoop을 보면서 by from __future__ import dream is licensed under a Creative Commons Attribution-NonCommercial 4.0 International License.