초보자라면 HDFS 헷갈리는 기본 개념 정리 (1) - Impala가 Hive보다 빠른 이유
-상황 설명 : 본인은 hive table에 쿼리할 때 보통 hive sql 보단 impala query가 빨라서 impala를 쓴다.
무조건 Impala가 빠른건 아니겠지만 보통.. 보통 그랬다.
hive에만 존재하는 쿼리도 있고 impala에만 존재하는 쿼리도 있어서 그럴 때만 상황에 맞게 사용하고 있다.
- 결론부터 말하자면 impala가 메타데이터를 캐시해두며 Map Reduce 프레임워크를 사용하지 않기 때문에 impala가 더 빠른 결과를 내온다고 알고있다.
-이제 살펴볼 건 hive query는 왜 느리고, map reduce 자체가 분산 저장된 빅데이터를 빠르게 처리하기 위한 프레임워크인데 왜 이를 쓰지 않으면 빨라지는지 알아보고자 한다.
MapReduce
맵리듀스프레임워크는 하둡을 배웠다면 필수적으로 들었을 텐데, 간략히 말하자면 각 data node에서 computation을 실행하고(map) 해당 결과값들을 모아서(reduce) 최종 결과값을 내는 과정이라고 생각하면 된다.
자바 기반으로, map/reduece 함수를 상속받아서 사용자가 프로그래밍하고 해당 파일들을 .jar로 묶어서 실행시키는 방식인데, 이를 매번 프로그래밍 하기엔 힘드니 HiveQL을 이런 MapReduce 프레임워크를 손쉽게 이용하게 해준다. HiveQL은 사용자에게 친숙한 SQL문으로 MapReduce 작업을 일으킨다.
Hive
HADOOP 쪽에 JOB Tracker가 Map/Reudce task를 실행시키는걸 볼 수 있다. 과정은 아래와 같다.
1. 쿼리가 들어오면 해당 sql문을 map-reduce로 컴파일한다.
2. 데이터가 어디에 있는지 메타스토어에서 정보를 뽑아온다.
3. 해당 정보를 기반으로 Job Tracker가 Task Tracker에게 data가 있는 node에서 작업을 수행하게하고(map) 해당 값들을 모아서 결과를 내라고 전한다(reduce).
3-1. Map Task는 전체 node 수보다 훨씬 많이 생성된다. 하나의 data chuck 당 하나의 Map이 보편적이다.
3-2. 자원 분배는 YARN 에서 담당한다.
4. Map Task는 HDFS로 부터 데이터를 읽고 결과값을 Local Disk에 Write 한다. 그러면 Reduce Task가 Map Output을 읽고결과값을 HDFS에 Write 한다.
Impala
하지만 Impala는 이러한 Map Reduce 프레임워크를 사용하지 않고 자체 분산 쿼리 엔진을 사용한다. 이 때 query의 대상이 되는 데이터를 메모리에 저장한다. Disk에 저장해서 사용하는 Map Reduce와는 여기서도 속도 차이가 발생한다.
Impala의 쿼리 수행 프로세스를 살펴보자.
1. 쿼리가 들어오면 코디네이터 노드가 쿼리 계획을 짠다.
2. 짜여진 계획을 관련있는 데이터가 있는 각각의 impalad에 넘기고 이를 처리한다. 이때 쿼리는 노드에서 병렬로 수행한다.
3. 해당 노드의 데이터만으로 쿼리를 완료할 수 없다면 다른 노드와 데이터를 교환하기도 한다.
4. 코디네이터가 데이터를 모으고 결과를 낸다.
impalad 라고 부르는 Impala Daemon은 각각의 Data Node에 하나씩 떠있다. 이들이 데이터를 읽어서 메모리에 올리고, 쿼리를 수행한다. impalad는 데이터를 바로 읽어올 수 있도록 meta 정보를 가지고 있고, 자체 쿼리 엔진으로 쿼리를 처리한다. 다른 impalad와 함께 병렬로 처리하기 때문에 더욱 빠른 속도를 낼 수 있다.
Impala가 Hive 보다 빠른 이유
위의 내용 중 차이점을 발견해보자면
1. Hive는 매번 Name Node를 통해서 Data 가 어느 노드에 있는지 받아오고나서 수행하지만 Impala는 자체적으로 저장해두고 있기 때문에 코디네이터가 바로 계획을 짤 수 있다.
참고1) metadata 의 변경이 일어나면 Impala가 모를 수도 있다. 그래서 invalidate metadata 쿼리가 impala에만 존재하는 것이다
참고2) compute stats 문으로 table의 통계정보도 미리 metastore 데이터베이스에 저장해두어 쿼리를 최적화시키는데 도움을 줄 수 있다.
- 개인적인 경험으론 메모리가 터져버린 쿼리의 튜닝이 힘들 때 compute stats로 해결된 경우가 많았다.
2. Hive는 데이터를 디스크에 두고 수행하고 Impala는 메모리에 올려둔다.
참고) hive는 yarn이 자원을 관리해주지만 impala는 yarn 없이 자체적으로 수행하며 memory limit에 걸리 시 hive처럼 queue에 들어가는게 아니라 터져버린다.
3. Hive와 Impala 모두 병렬처리를 하지만 Hive는 수많은 Map Task가 생성(data chuck 갯수만큼)되고 이 과정이 끝나야 Reduce가 완료될 수 있다. 그리고 이 과정에서 자잘한 결과값을 주고받고 sorting 하기때문에 Network IO / Disk IO가 더 많이 발생한다. 이로 인해 병목현상 또한 피할 수 없다. 하지만 Impala는 각각의 노드에서 병렬처리하며 쿼리를 수행한다. 노드 수만큼 분산되어 처리하기 때문에 Hive보다 기본적으로 덜 쪼개져서 수행된다. 이 과정이 대화형 SQL 쿼리에 알맞게 최적화되어있는데 특히 Network IO를 많이 피할 수 있다.
결론
물론 항상 Impala가 더 좋다는건 아니다. 대화형 쿼리에 알맞게 설계되어 있기 때문에 빠른 결과를 보긴 하지만 Hive의 아키텍쳐에 더 적절한 일은 Hive가 더 빠르기도 하다. 예를 들면, counting, summing, ETL 등은 mapper로 일이 적절하게 나누어지기 때문에 더 빠를 수도 있다. 하지만 Impala가 여러 방법(캐싱, 메모리, Network IO줄이기)으로 속도 개선을 이루어냈기 때문에 대부분 Impala를 사용하게 되곤 한다. 적절한 상황에 맞추어 사용하는 개발자가 되어보도록 하자.
참고
https://cwiki.apache.org/confluence/display/Hive/Design