jaso extends j2ee

Bigtable은 구조화된 대용량 데이터(수백TB이상)를 분산환경에 저장하는 데이터베이스 솔루션이다. Bigtable은 rowkey로 정렬되어 있으며 하나의 큰 테이블은 여러개의 Tablet으로 분리된다.
Map&Reduce는 분산 병렬 프로그램 모델로 n개의 Map task가 분산된 노드에서 병렬로 수행되고 map에서의 결과가 m개의 Reduce task로 수집되고 Reduce에서는 레코드의 key를 이용하여 정렬한 다음 처리한다.
이 두개를 조합할 경우 대량의 데이터를 빠르게 분석해서 구조화된 저장소에 저장하고 저장된 데이터를 실시간으로 검색할 수 있는 시스템을 쉽게 구성할 수 있다.
최근 이 두개의 조합으로 테스트해보면서 이상한 점을 발견했는데 단순히 두개의 조합으로 프로그램을 할 경우 다음과 같은 문제점이 발생한다.

Map에서 reduce로 전달되는 데이터는 key값의 has를 이용하여 랜덤하게 Reduce로 전달된다. 이렇게 전달된 값은 Reduce에서 소팅된 후 순서대로 처리된다.
위의 그림에서 보는 것 처럼 테이블을 생성하면 하나의 Tablet이 rowkey영역 중 MIN - MAX를 담당하게 된다.  Reduce에서 순차적으로 insert 처리되면서 Tablet의 크기가 증가하면 두개의 split되는데 이때에는 MIN - 중간 key, 중간 key - MAX로 분리된다.
Reduce에서 처리하는 데이터가 정렬된 순서대로 처리되기 때문에 테이블이 분리된 다음에도 여전히 insert는 MAX를 담당하는 Tablet로 집중하게 된다.
Reduce Task의 갯수가 적은 경우 문제가 없지만 Reduce Task의 갯수가 수십/수백이 되는 경우 작업 성능이 심각한 영향을 줄 수 있으며 Tablet을 분리하여 분산 시키는 효과가 전혀 없는 구조가 되어버린다.
전혀 예상하지 못했던 결과의 성능이 나와 버렸다. ㅋㅋㅋ
해결방법은 Map -> Reduce로 잔달되는 key를 Table에 저장되는 key 그대로를 사용하지 않고 hash 값을 만들어 Reduce로 전달하고 실제 key 값은 map의 value에 추가하여 reduce로 보낸다. Reduce에서는 hash로 전달된 key를 이용하여 정렬하기 때문에 실제 key의 순서와는 무관하다. Table에 저장하는 key는 value에서 key를 추출하여 저장하는 방법을 사용한다.

크리에이티브 커먼즈 라이센스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-변경금지 2.0 대한민국 라이센스에 따라 이용하실 수 있습니다.

Posted by 김형준