[튜닝] Hive 에서 Broadcast Join 을 이용한 join 성능 튜닝방법

개요

hive 에서 join 은 매우 느린 연산이다. 돌려본 사람은 알겠지만 join 이 들어간 경우 엄~~청 결과가 느려진다.

그래서 join 이 있는 쿼리를 튜닝해야할 일이 생길텐데 가장 손쉬운 방법은 broadcast join 을 사용하는것이다.

(다른말로는 mapside join 이라고도 한다)

 

사용가능한 패턴은 "큰테이블  join 작은테이블" 의 경우에만 가능하지만, 일반적으로 이런패턴의 쿼리가 많아서 알아두면 많이 도움이 된다. 참고로 broadcast join 으로 유도하면 hive 에서 reduce 단계를 제거해서 50% 정도까지 시간이 단축될 수 있다.

사용방법

우선 연관된 설정이 3개가 있는데 다음과 같이 활성화 해주면 좀더 많은 케이스에 적용을 할 수 있다.

기본값이 약 20메가 수준인데, 리얼월드에서는 이것보다는 좀더 큰 데이터를 다루기 때문에 좀더 올려주는게 좋다.

나 같은 경우는 250메가 정도로 올려줬고, 이걸 올릴때 컨테이너의 메모리 관련 설정도 같이 늘려주는게 좋다.

set hive.auto.convert.join=true;
set hive.auto.convert.join.noconditionaltask=true;
set hive.auto.convert.join.noconditionaltask.size=250000000;

위와 같이 설정하면 250메가 수준이하의 테이블은 메모리에 올려서 조인을 한다는것이다.

(두 테이블중 하나만 만족하면 로딩후 map 단계에서 조인이된다는 말)

 

실제로 튜닝전과 튜닝후의 플랜을 확인해보면, 튜닝전에 reduce 였던게 map 단계로 처리 된다고 되어있고, 12분이 넘어도 안나오는 결과가 튜닝이후에는 4분정도면 결과가 나오는 기적(?)을 경험하게 되었다.

주의사항

메모리에 로딩후 조인하는 구조라서 "hive.tez.container.size" 같은 관련 옵션도 같이 조정해서 작업해야 하는데, 결국은 이 값을 키우면 최대 사용가능한 yarn 의 컨테이너 갯수가 줄어들기 때문에 쿼리 패턴에 맞춰서 메모리를 작게 잡고 돌리는게 유리한지 판단을 하도록 하자.