[Hive] Compile 상세 과정 #1 - 쿼리 변화 과정과 형태

 Hive를 이용하면서 Client로부터 제출된 쿼리가 어떻게 MR Job으로까지 변환이 될까라는 궁금증이 항상 있었습니다. 그래서 내부적인 Compile 과정에 대해서 공부를 하게 되었고, 소스 코드를 직접 분석해 봤습니다. 이전에 작성한 [Hive] Hive 아키텍처와 HiveServer2 & Hive Metastore  글을 먼저 읽으면 본 게시글을 이해하는데 도움이 될 겁니다. 

 

 

Hive Architecture Review

 

 

- 주요 프로세스로 HiveServer2, Metastore 존재

- Driver가 중심에서 컴파일 과정, Task 전달 등 수행.

- Hive 쿼리의 변화 과정을 알기 위해선 위 그림의 Compiler 과정을 알아야함.

 

 

 

Hive 쿼리 처리 과정

 

- Hive 쿼리가 최종적으로 Map Reduce Job이 된다는 것은 잘 알고 있음.

- 하지만 대부분의 에러 발생은 중간 과정에서 발생.

- 위의 과정을 모른다면 에러의 원인을 파악하기 힘듦.

 

 Architecture 그림에서 Compiler와 Driver를 모듈로써 따로 분리를 시키면 위와 같습니다. 하지만 제가 실제로 알아본 Hive 쿼리의 Compile 과정은 조금 달랐습니다. 아래의 그림을 통해 설명하겠습니다.

 

 Hive Architecture에서 Compiler 모듈이 존재했던 것과 달리 실제 과정에서는 쿼리의 변화 과정에 필요한 각 모듈들이 모두 Driver에서 호출되어 사용되었습니다. 위 그림에서 확인할 수 있는 Hive 쿼리의 변화 과정은 다음과 같습니다.

 

Hive 쿼리  -  AST  -  QB  -  OP Tree  -  Task Tree

 

 

Hive 쿼리의 변환 형태

 

 Hive가 변환되면서 거치게 되는 각각의 형태에 대해서 알아보겠습니다.

 

AST 

 Abstract Syntax Tree, 일반적인 프로그래밍 Compile 과정에서 쓰이는 개념으로 추상화된 트리를 뜻합니다. 코드 또는 쿼리의 각 구문을 트리 형태로 분리시킨 형태입니다.

 

 

QB

 Query Block, 쿼리 구조에 대한 정보를 담습니다. 보통 Sub 쿼리가 존재하는 쿼리에서 여러 구조의 QB 정보가 생깁니다.

 Hive에서 사용하는 QB의 경우 두 가지 종류의 데이터가 담깁니다.

    1) MetaData

        -> 테이블에 대한 Metadata

    2) ParseInfo

        -> QB에 대한 parsing 정보

 

OP Tree

 Operator Tree, Logical Plan으로써 Operator가 Tree 구조로 생성됨.

Operator 예시 - TS : Table Scan Operator - GBY : Group By Operator - RS : Reduce Sink Operator - SEL : Select Operator - FS : File Sink Operator - FIL : Filter Operator

 Logical Plan은 Hive를 debug 모드로 실행했을 때 Log에서 확인할 수 있습니다.

 

Task Tree

 Task Tree, Logical Plan이 최종적으로 Execution engine에서 수행될 Physical Plan으로 변환된 상태.

Task 예시 - Fetch Task : [Stage-0 : FETCH] - Root Task : [Stage-1 : MAPRED]

 explain 문을 사용하여 쿼리의 plan을 확인할 때 Task Tree 구조를 볼 수 있습니다.