Hive Architecture

Hive Architecture

Hive의 주요 Component들은 다음과 같다.

• UI - 사용자를 위한 유저인터페이스는 시스템에 쿼리와 작업을 제출 할 수 있다.
• Driver - 쿼리를 받는 컴포넌트이다. Driver는 세션 핸들의 개념을 실행하고 JDBC/ODBC 인터페이스 기반의 API 를 실행하고 가져오는 것을 제공한다.
• Compiler - 쿼리를 분석하는 컴포넌트로 각기 다른 쿼리 블록과 쿼리 표현에서 의미 분석을 하고 테이블의 지원과 함께 실행 계획과 메타스토어에서 찾은 파티션 메타데이터를 생성한다.
• Metastore - 다양한 테이블의 모든 구조 정보와 칼럼과 칼럼 타입 정보를 포함한 웨어하우스내 파티션을 저장하는 컴포넌트로, serializers 와 deserializers 는 데이터를 읽고 쓰거나 데이터가 저장되는 HDFS 파일이 필요하다.
• Execution Engine - Compiler에 의해 생성된 실행계획을 실행하는 컴포넌트이다. 계획은 DAG 단계로 되어있다. execution engine은 계획의 다른 단계들과 적절한 시스템 Component위에 단계들을 실행하는 것 사이의 의존성을 관리한다.

 

Hive의 주요 Component와 Hadoop과 상호작용하는 것을 보여주는 다이어그램이다.

시스템을 통해 보통 쿼리가 어떻게 흘러가는지 보여준다.

Step 1

UI는 Driver에게서 execution interface를 호출한다.

Step 2

Driver는 쿼리를 위한 세션 핸들을 생성하고 실행계획을 실행하기 위해 쿼리를 Compiler에게 전송한다.

Step 3 4

Compiler는 필요한 메타데이터를 메타스토어에서 가져온다.****

Step 5

메타데이터는 쿼리 트리내의 표현 타입체크하는데 사용되고 뿐만아니라 파티션을 쿼리를 기반으로 정리한다. Compiler에 의해 계획이 생성된다.

Step 6 6.1 6.2 6.3

Compiler에 의해 생성된 계획인 DAG의 각 단계는 Map/Reduce job, 메타데이터 작업 또는 HDFS위에서의 작업이다.

Map/Reduce 단계에서, 계획은 map operation 트리와 reduce operation 트리를 포함한다. Execution Engine은 이러한 단계에 적절한 Component를 제출한다

Map 연산자 트리 : mapper위에서 실행되는 operation 트리

Reduce 연산자 트리 : reducer가 필요한 operation

Step 7 8 9

각 작업(mapper/reducer)에서 deserializer와 관련된 테이블 또는 중간 산출물로 HDFS 파일에서 행을 읽거나 관련된 연산자 트리를 통과하는데에 사용된다.

산출물이 생성됐을 때, serializer 를 통해 임시 HDFS 파일로 쓰여진다. (mapper에서 리듀스가 필요없는 작업인 경우 일어난다.)

임시 파일들을 사용해 계획의 후속 map/reduce단계에 데이터를 제공한다.

DML 작업은 마지막 임시 파일을 테이블의 위치로 옮긴다.

스키마를 사용해 불량 데이터를 읽지 않도록 확실시 한다. (HDFS에서 파일 이름 재지정하는 작업)

쿼리의 경우, Driver에서 가져오는 호출의 일부분으로서 임시 파일의 내용들은 execution engine으로 HDFS에서 바로 읽는다.

Hive Data Model

Hive에서 구성되는 데이터

• Table
  • Hive 테이블은 관계형 데이터베이스에서의 테이블과 비슷하다.
  • 테이블은 filtered, projected, joined, unioned 가 가능하다.
  • 테이블의 모든 데이터는 HDFS 디렉토리에 저장된다.
  • Hive는 테이블 생성 DDL에 적절한 위치를 제공함으로써 HDFS에 기존에 있는 파일 또는 디렉터리에 테이블을 생성할 수 있는 외부테이블 개념을 지원한다.
  • 테이블에서 행은 관계형 데이터베이스와 유사한 열 입력으로 구성된다.
• Partition
  • 각 테이블은 하나 또는 그 이상의 데이터 저장 방법을 결정하는 파티션 키를 가질 수 있다.
    • 예를 들어, 테이블 T와 데이터 파티션 칼럼 ds는 특정 날짜에 HDFS 디렉터리에 저장된 파일과 데이터를 가진다. <table location>/ds=<date>
  • 파티션은 시스템이 쿼리 작성을 기반으로 검사될 데이터를 정리하는 것을 허용한다.
    • 예를 들면, T.ds = '2008-09-01' 서술을 만족하는 T의 행에 관심 있는 쿼리는 <table location>/ds=2008-09-01/ HDFS내의 디렉터리 안에 파일을 바라보면 된다.
• Buckets
  • 각 파티션내 데이터는 테이블내 칼럼의 해시에 기반한 Buckets에 차례로 분할된다.
  • 각 bucket은 파일로 파티션 디렉터리에 저장된다.
  • Bucketing 시스템이 데이터의 샘플에 의존하는 쿼리를 효율적으로 평가하는 것을 허용한다. (이러한 쿼리들은 테이블의 SAMPLE 조항을 사용한다.)

Metastore

Motivation

메타스토어는 두개의 중요한 것을 제공하나 데이터 웨어하우스의 특징으로 종종 간과된다: 데이터 추상화와 데이터 발견. Hive에서 데이터 추상화 제외하고 제공한다, 사용자는 쿼리와 함께 데이터 formats, extractors, loaders 에 대한 정보를 제공해야한다. Hive에서는, 이런 정보들은 테이블 생성하는 동안 주어지고 재참조 될때마다 재사용한다. 이러한 점은 전통적인 웨어하우징 시스템과 유사하다. 두번째 기능, 데이터 발견은 사용자들이 웨어하우스에서 적절하고 구체적인 데이터를 발견하고 탐색할 수 있다. 다른 툴은 노출할 메타데이터를 사용해서 지어질 수 있고 데이터에 대한 정보를 향상시킬 수 있으며 이것은 유용하다. 하이브는 데이터 및 메타데이터가 동기화되도록 하이브 쿼리 처리 시스템과 긴밀하게 통합된 메타데이터 저장소를 제공함으로써 이러한 두 가지 기능을 모두 달성한다.

Metadata Objects

• Database
  • 테이블을 위한 네임스페이스
  • 후에 관리 부분(administrative unit)으로 사용할 수 있을 것이다.
  • 데이터베이스 ‘기본값’은 사용자가 데이터베이스이름을 지정하지 않은 테이블에 사용된다.
• Table
  • 테이블을 위한 메타데이터는 칼럼, 소유자, 저장소, SerDe 정보의 리스트를 포함한다.
  • 또한 어느 사용자가 제공한 key와 value 데이터를 포함한다.
  • 저장소 정보는 underlying data 위치, 파일의 출력, 출력 포맷, 버켓 정보를 포함한다.
  • SerDe 메타데이터는 serializer and deserializer의 실행 클래스 위치를 포함하고 실행에 의해 어떠한 지원정보를 요구한다.
  • 이 정보의 모든 것은 테이블을 생성하는 동안 제공된다.
• Partition
  • 각 파티션은 칼럼과 SerDe 그리고 저장소 정보를 소유할 수 있다.
  • 이전 파티션에 영향을 주지않고 스키마를 변경할 수 있다.

Metastore Architecture

메타스토어는 데이터베이스 또는 파일 백업 저장소가 있는 개체 저장소이다.

데이터베이스 백업 저장소는 DataNucleus라는 ORM(개체 관계 매핑) 솔루션을 사용하여 구현된다.

The prime motivation for storing this in a relational database is queriability of metadata.

HDFS 사용하는 것 대신 메타데이터를 위한 개별 데이터 저장소를 사용하는 것의 몇몇 단점들은 동기화와 확장성 문제가 있다.

게다가 임의의 파일 업데이트 부족으로 인해 HDFS의 위에서 개체 저장소를 구현하는 명확한 방법은 없다.

This, coupled with the advantages of queriability of a relational store, made our approach a sensible one.

메타스토어는 두가지 방법을 사용해 구성될 수 있다: remote와 embedded. remote 모드에서, 메타스토어는 Thrift 서비스이다. 이 모드는 non-Java clients에게 유용하다. embedded 모드에서, JDBC를 사용해 Hive client는 메타스토어 기반에 바로 연결할 수 있다. 이 모드는 유지보수와 모니터링이 필요한 다른 시스템을 피하기 때문에 유용하다. 이런 모드들 둘 다 공존할 수 있다. (Update: 로컬 메타스토어는 제3의 가능성이다. Local metastore is a third possibility.? )

Metastore Interface

메타스토어는 하이브 메타데이터를 조작하거나 질의할 수 있는 Thrift 인터페이스 를제공한다. Thrift 는 많은 유명한 언어로 묶는 것 제공한다. Third party tools는 Hive 메타데이터를 다른 비즈니스 메타데이터 저장소에 통합하기 위해 Thrift 인터페이스를 사용 할 수 있다.

Hive Query Language

HiveQL은 Hive의 SQL 유사 쿼리 언어이다. 테이블 생성, 테이블에 데이터 로딩, 그리고 테이블에 쿼리 입력 등 대부분 SQL 구문과 유사하다. HiveQL 또한 사용자들이 그들의 커스텀 map-reduce 스크립트를 내장하는 것을 허용한다. 이러한 스크립트들은 단순한 행 기반 스트리밍 인터페이스를 사용해 어떠한 언어로 쓰여질 수 있다 - 표준 입력값에서 행을 읽거나 표준 출력값에서 행을 쓰거나. 이러한 유연성은 converting rows from and to strings에서 성능저하를 초래한다. 그러나, 우리는 사용자들이 그들이 원하는 언어를 선택하여 스크립트를 구현하는 것을 감안하여 신경쓰지 않는 것을 본 적이 있다. HiveQL의 다른 특별한 특징은 다중 테이블 삽입이다. 이 구성에서는, 사용자들이 단일 HiveQL 쿼리 사용하여 같은 입력 데이터대해 다중 쿼리를 수행 할 수 있다. Hive는 입력 데이터의 스캔을 공유하기 위해 쿼리들과 따라서 증가하는 질문의 처리량의 몇 배나 되는 크기를 최적화한다. 공간의 부족으로 더 자세한 내용은 생략한다. HiveQL의 자세한 내용은> language manual.

Compiler

• Parser – 쿼리 문장을 트리 표현으로 변환한다.
• Semantic Analyser
  • parse 트리를 내부 쿼리 표현으로 변형한다. 이것은 블록기반이며 operation 트리는 아니다.
  • 이 단계의 부분으로, 칼럼 이름들은 검증되고 * 과 같이 확장된다.
  • Type-checking 과 암묵적 형식 변환 은 이 단계에서 수행된다.
  • 고려중인 테이블이 일반적인 시나리오인 partitioned table라면, 나중에 필요하지않은 파티션이 제거 할 수 있도록 해당 테이블의 모든 식이 수집된다.
  • 만약 쿼리가 샘플링을 지정한다면, 또한 후에 사용하기 위해 수집될 수 있다.
• Logical Plan Generator
  • 내부 쿼리 표현을 operator의 트리의 구조인 논리적인 계획으로 변환한다.
  • 몇몇 operators는 ‘filter', 'join’ 과 같은 관계형 대수 operators 이다.
  • 하지만 몇몇 operators는 Hive 구체적이고 후에 이 계획에서 일련의 map-reduce jobs 으로 변환되는데 사용된다.
  • operator 하나는 map-reduce boundary에서 일어나는 reduceSink operator 이다.
  • 또한 이 단계는 성능 향상시키는 계획을 변경하는 최적화를 포함한다.
    • 이러한 변환의 일부는 같다 : 일련의 조인들을 싱글 다중방향 조인으로 변환, 그룹별 map-side 부분 집계 수행, 단일 reducer가 그룹화 키에 대해 왜곡된 데이터가 있는 경우 병목현상이 일어났을 때, 시나리오를 피하기위해서 2 단계에서 group-by를 수행한다.
  • 각 operator는 serializable object인 descriptor로 구성되어있다.
• Query Plan Generator
  • 논리적인 계획을 일련의 map-reduce 작업으로 변환한다.
  • operator tree는 반복적으로 통과된다. HDFS의 map-reduce framework에서 후에 제출 할수있는 일련의 map-reduce serializable 작업으로 분해된다.
  • reduceSink operator는 reduction keys를 포함한 descriptor인 map-reduce boundary이다.
  • reduceSink descriptor 안에 reduction keys들은 map-reduce에서 reduction keys로서 사용된다.
  • 쿼리가 지정한 경우 계획은 필요한 샘플/파티션 포함한다.
  • 계획은 serialized 와 파일에 기록된다.

Optimizer

optimizer로 인해서 계획 변경이 수행된다. optimizer 는 진화하는 component이다. 2011년에, optimizer는 규칙기반이며 칼럼 자르거나 predicate pushdown 을 수행했었다. 그러나, infrastructure이 이루어 졌고, map-side join과 같은 다른 optimizations 를 포함하는 진행 중인 일이 있었다. optimizer를 비용 기반으로 향상 시킬 수 있었다. (see Cost-based optimization in Hive and HIVE-5775). 또한 출력 테이블의 정돈된 특성은 보존될 수 있거나 더 좋은 방법 생성하는 데 사용할 수 있다. 데이터 분포 추측을 위해 데이터의 작은 샘플에 대해 쿼리를 수행할 수 있으며, 더 나은 방법을 생성할 수 있다. correlation optimizer는 Hive 0.12.에 추가되었다. 계획은 포괄적인 operator tree이고 조작이 용이하다.

---

operation은 연산자? 작업? 해석

operator

query predicates ? 쿼리 작성?

---

참고사항

DAG

serializers

deserializers

https://cwiki.apache.org/confluence/display/Hive/Design

Design - Apache Hive - Apache Software Foundation