의 아파치 임팔라 하이브와 건축과의 유사점과 차이점 사이의 관계

A, 임팔라 와 하이브 관계

임팔라는 메타 스토어는 그들의 하이브에 임 팔 라 메타 데이터가 저장 의미 대용량 데이터 쿼리 엔진 하이브, 메타 데이터베이스 메타 데이터의 하이브 직접 사용의 분석을 기반으로하고, 임팔라 호환 하이브 SQL 구문의 대부분. 당신이 임팔라를 설치해야합니다 그래서, 그것은 성공적인 설치를 보장하기 위해 하이브, 하이브 설치 및 메타 스토어 서비스의 하이브 시작해야해야합니다.

등 하이브 메타 상기 메타 정보 데이터베이스, 테이블, 하이브로 만들었다. 메타 데이터는 이러한 더비, 같은 MySQL은 같은 관계형 데이터베이스에 저장됩니다.

메타 스토어 서비스 클라이언트 연결, 메타 스토어는 메타 데이터에 액세스에 연결 MySQL 데이터베이스로 이동합니다. 메타 스토어 서비스를 사용하면 여러 개의 동시 클라이언트 연결을 가질 수 있으며, 이러한 클라이언트는 MySQL 데이터베이스 사용자 이름과 암호를 알 필요가 없습니다 만 메타 스토어에게 서비스를 연결해야합니다.

nohup hive --service metastore >> ~/metastore.log 2>&1 &

긴 일괄 질의 및 분석에 적합한 하이브, 그리고 임팔라는 실시간 대화 형 SQL 쿼리에 적합합니다. 하이브 제 하이브 처리 데이터 세트의 결과를 사용하는 임 신속한 데이터 분석 한 후, 상기 데이터 변환 처리를 사용할 수있다.

두, 임팔라 와 하이브 유사점과 차이점

하이브 임팔라 및 데이터 쿼리 도구 초점에 적응하기 위해 변화 하둡 기반으로 구축되지만 클라이언트가 하이브는 많은 공통점을 가지고 임팔라보기를 사용하여 데이터 테이블 메타 데이터, ODBC / JDBC 드라이버, SQL 구문, 유연한 파일 형식, 스토리지 리소스 풀.

그러나 하이브 최적화가 가장 큰 차이 임팔라는 : 사용하지 않는 맵리 듀스 병렬 컴퓨팅을 맵리 듀스 프레임 워크를 계산하는 아주 좋은 병렬이지만, 오히려 대화 형 SQL 실행을위한보다 더 배치 지향 모델이지만,. 맵리 듀스에 비해 임팔라는 전체 쿼리에 넣어 실행 계획 트리 배포 계획의 이행 후, 오히려 맵리 듀스 일련의 작업보다, 임팔라를 사용하여 풀 데이터 수집 방법은 결과를 얻을, 상기 조성물 실행 트리 스트리밍을 전달하여 데이터 수집의 결과 디스크의 헤드로부터 디스크에 기록 된 중간 결과를 감소시키는 단계, 그리고 데이터를 판독. 임팔라 방법은 당신이 오버 헤드 모든 쿼리 실행을 시작하는 데 필요한 서비스를 사용 방지하기 위해 맵리 듀스 시작 시간이 아니라고 하이브를 비교했다.

1, 임팔라 사용되는 최적화 기술

실행의 효율성을 속도를 인라인 방법을 사용하는 동안 특정 쿼리에 대한 특정 코드를 생성하기 위해 LLVM을 사용하여 생성 된 코드를 실행, 함수 호출의 오버 헤드를 줄일 수 있습니다. (C ++ 특성)

사용 가능한 하드웨어 명령 (SSE4.2)의 전체 사용.

더 나은 IO 스케줄링, 데이터 블록 임팔라 임팔라 직접 데이터 블록 읽기와 계산 체크섬 네이티브 코드를 지원하는 반면, 멀티 디스크의 장점을 악용 할 수 잘 알고 디스크 위치.

최상의 성능은 적절한 데이터 저장 포맷 (임팔라 여러 저장 포맷을 지원)을 선택함으로써 얻어 질 수있다.

최대 메모리 사용, 중간 결과는 네트워크를 통해 스트리밍 할 디스크, 적시 납품 방법을 쓰지 않는다.

2, 구현 계획

하이브 : 맵리 듀스 프레임 워크의 구현에 따라, 구현 계획은 -지도에서> shuffle-> reduce-> -지도에서>으로 나누어 져모델. 쿼리는 맵리 듀스의 여러 라운드로 컴파일되면, 중간 결과를 작성하는 더있을 것입니다. 자체 MapReduce를 수행 한 프레임의 특성 때문에, 과도한 중간 과정은 쿼리의 전체 실행 시간을 증가시킨다.

임팔라 : 전체 실행 계획 트리의 성능 구현의 계획은 쿼리를 실행하기 위해 다양한 Impalad 실행 계획에 배포 할 더 자연스러운 될 수 있지만,이 -지도에서> 모델을 감소 파이프 라인 형태로 결합으로 임팔라을 보장하기 위해, 하이브 싫어 동시성과 피할 불필요한 중간 정렬 셔플보다.

(3) 데이터 흐름

하이브 : 푸시 방식으로, 사전에 후속 노드로 계산 데이터의 완료 후에 밀어 각 연산 노드를 사용.

임 : 사용 풀 모드가 전방 GETNEXT 액티브 노드에 상기 데이터 노드에 후속하여, 이러한 방식으로 데이터를 클라이언트에 스트리밍 돌아올 수 있고, 긴 처리 할 데이터가있는 한, 대기하지 않고, 즉시 표시 할 모든 처리는 대화 형 SQL 쿼리에 맞춰 더 완료됩니다.

4, 메모리 사용

하이브는 : 메모리가 모든 데이터를 맞지 않으면 실행 중에, 외부 메모리는 전체 쿼리가 순차적으로 수행 할 수 있도록하는 데 사용됩니다. 각 라운드의 MapReduce의 단부가 상기 중간 결과도 HDFS 작성된, MapReduce의 실행은 아키텍처의 특성에, 셔플 프로세스가 로컬 디스크 기록 동작이있을 것 때문에도.

임팔라 : 얼굴에 데이터 메모리, 버전 1.0.1 오류가, 외부 메모리를 사용하지 않고, 미래 버전은 개선되어야 직접 반환 맞지 않습니다. 이 과정은 현재 가장 하이브와 함께 사용되는 쿼리 임팔라 특정 제한이 적용되었다 사용하고 있습니다.

5, 스케줄링

하이브 : 작업 일정은 하둡의 스케줄링 정책에 따라 달라집니다.

임팔라 : 자신에 의해 수행 일정, 하나의 스케줄러 간단한 스케줄이있다, 그것은 지역, 프로세스 데이터가 물리적 머신에 가까운 데이터 자체로 데이터를 스캔 충족하기 위해 노력할 것입니다. 스케줄러는 전혀 고려 부하, 네트워크 상태 IO 일정이 없습니다에 SimpleScheduler :: GetBackend에서 볼 수있는, 여전히 상대적으로 간단하다. 그러나 임팔라가 구현 프로세스의 성능 통계 분석을 가지고, 우리는 나중에 일정이 통계를 사용합니다.

6, 내결함성

하이브 : 하둡 내결함성에 의존한다.

임팔라 : 오류가 실행 중에 발생하는 경우 질의 과정에서 어떤 오류 로직, 오류가 임팔라의 디자인 관련되는 (직접 반환되지 않습니다, 실시간 질의에 위치, 쿼리는 임팔라에 실패한 후 단 한 번 확인하고 있기 때문에 비용이 매우 낮은되면)를 확인하십시오.

7 적용

하이브 : 복잡한 배치 쿼리 작업, 데이터 변환 작업.

임 : 실시간 데이터 분석 문제는 UDF를 지원하지 않기 때문에, 도메인 하이브 실시간 분석 하이브 데이터 세트의 결과와 함께, 특정한 제한이 처리 할 수있다.

세, 임팔라 아키텍처

임팔라 을 중심으로 Impalad , 배송 상태 , Catalogd 및 CLI 구성 .

1 Impalad

Impalad : Impalad 프로세스에 의해 표현 된 동일한 노드에와 데이터 노드 실행, 그것은 클라이언트 쿼리 (수신 Impalad 쿼리 요청 수신 코디네이터 , 코디네이터를 JNI를 통해 호출 자바 SQL 프런트 엔드 설명 , 쿼리를 쿼리 계획 트리를 생성 한 다음 스케줄러를 통해를 다른 Impalad에서의 대응하는 데이터 분산 실행 계획 실행 ), 판독 및 기록 데이터를 병렬로 실행 된 쿼리 및 결과 코디네이터에 의해 클라이언트에 반환 코디네이터 스트림 네트워크 백을 통해 전송된다. 한편, 주 저장소와 연결 Impalad 건강하고 새로운 작업을 수용 할 수있는 결정하는 데 사용 유지도 Impalad.

beeswax_server (연결 클라이언트), hs2_server (차용 하이브 메타 데이터), be_server (Impalad 내부)와 ImpalaServer 서비스 : Impalad의 3 ThriftServer를 시작합니다.

2, 임팔라 국가 스토어

주 저장 임팔라는 : statestored 프로세스에 의해 표현 건강 상태 및 위치 추적 정보 Impalad 클러스터, 그것은 핸들 구독에 등록하고 여러 스레드를 생성하여 Impalad Impalad와 하트 비트 연결을 유지하기 위해, 각 Impalad는 국가 스토어에서 캐시됩니다 국가 스토어 오프라인 때 Impalad이 주 스토어 캐시가 계속 될 수 있기 때문에 정보는 (Impalad는 국가 스토어를 발견 오프라인 상태 스토어 클러스터를 다시 결합 할 때, 복구 모드로 들어갑니다 반복적으로 등록, 자동으로 정상 업데이트 캐시 된 데이터로 돌아갑니다) 일부 Impalad가 실패하기 때문에 작동하지만, 캐시 된 데이터는 쿼리가 실패의 결과로, Impalad 실패에 할당 된 실행 계획의 결과로, 업데이트 할 수 없습니다.

3 CLI

CLI : 임팔라는 색조, JDBC, ODBC 사용 인터페이스를 제공하는 동안 사용되는 사용자 쿼리 명령 줄 도구에서 사용할 수, (임팔라 쉘은 파이썬을 사용하여 달성).

4, Catalogd (디렉토리)

Catalogd : 액세스 게이트웨이 메타 데이터를 다른 메타 스토어 외부 하이브 카탈로그로부터 취득한 메타 데이터 정보, 그들의 구조 임에 탈있다. 때 catalogd에 의해 그것의 실행, statestored 방송하여 업데이트를 대신 impalad DDL 명령 실행.

네, 임팔라 질의 처리

　자바 C ++ 프론트 엔드와 백엔드 처리에 Impalad 쿼리 코디네이터로 사용자의 쿼리 SQL 실행 계획 트리를 분석하기 위해 연결되어 Impalad 클라이언트를 받아, 코디네이터는 JNI를 통해 자바 프론트 엔드를 호출합니다.

는 C ++ 드리프트 후단 (코디네이터) (행 데이터 포맷 복귀의 선단부에서 생성 된 자바 실행 계획 트리 복수 단계로 실행 플랜은, 각 스테이지는 PlanFragment라고 각각 PlanFragment 수 Impalad 복수 의해 실행될 때 병렬 실행 인스턴스 ( 일부 PlanFragment 만 Impalad 의해 실행 예컨대, 이러한 중합 조작) , 실행 계획 트리 전체 실행 계획 ).

실행 계획, 데이터 기억 정보에 따라 코디네이터 ( 임 libhdfs 의해 HDFS와 의해 hdfsGetHosts 상호 작용 하는 노드의 위치 정보를 획득하는 데이터 블록을 파일에있어서 ) 스케줄러 (이제 간단한 스케줄러는 라운드 로빈 알고리즘을 사용)하여, :: 코디네이터 Exec은 (쿼리 실행 LLVM 코드 생성 컴파일을 사용하여) 적절한 백엔드 액추에이터 Impalad 실행에 할당 된 실행 플랜 트리를 생성 GETNEXT () 메소드를 호출하여 결과를 얻을 수있다.

삽입 문 경우, 결과는 모든 입력 데이터가 고갈 될 때 HDFS 다시 쓰기 libhdfs에 의해 계산됩니다 쿼리 서비스의 취소 후 종료의 구현입니다.