Impala(임팔라) 란?
아파치 하둡을 실행하는 컴퓨터 클러스터에 저장된 데이터를 위한 오픈 소스 대규모 병렬 처리 SQL 쿼리 엔진이다.
Apache Hadoop 파일 형식으로 저장된 데이터에 대해 low-latency 고성능 SQL 쿼리를 제공한다. 쿼리에 대한 빠른 응답으로 대화형 SQL 이라고도 한다.
Impala는 Hive 메타 스토어(HMS)와 통합되어 두 구성 요소 간에 데이터베이스와 테이블을 공유한다. Hive와 높은 수준의 통합 및 HiveQL 구문과의 호환성을 통해 Impala 또는 Hive를 사용하여 테이블을 만들고 쿼리를 실행하고 데이터를 로드하는 등의 작업을 수행할 수 있다.
- Map-reduce 대신 별도의 실행 엔진을 사용한다.
- 다양한 파일 저장소(HDFS, Kudu, S3 등)의 데이터를 SQL 쿼리로 실시간으로 분석 가능하다.
Hive vs. Impala
실시간성 : Hive는 MapReduce 엔진을 사용하는 반면에 Impala는 응답 시간을 최소한으로 줄이기 위해 자체 분산 질의엔진을 사용한다. 이 분산 질의 엔진은 클러스터 내 모든 데이터 노드에 설치되어 있다.
따라서 Impala는 Hive보다 응답 시간이 훨씬 빠르다.
Impala의 성능이 좋은 3가지 이유 (f.Cloudera)
- Impala는 Hive보다 CPU부하를 줄었고, 줄인 만큼 I/O 대역폭을 사용할 수 있다. 그래서 순수 I/O bound 질의일 경우 Impala는 Hive보다 3~4배 좋은 성능을 가진다.
- 질의가 복잡해지면 Hive는 여러 단계의 MapReduce 작업 또는 Reduce-side Join 작업이 필요하다. 이처럼 MapReduce 프레임워크로 처리하기에 비효율적인 질의의 경우 Impala가 7~45배 더 좋은 성능을 보인다.
- 분석할 데이터블록이 파일 캐시되어 있는 경우라면 매우 빠른 성능을 보인다. 이 경우 Hive보다 20~90배 빠른 성능을 보인다.
Impala Architecture
latency를 줄이기 위해 Impala는 MapReduce를 우회하여 상용 병렬 RDBMS에서 볼 수 있는 것과 유사한 전문화된 분산 쿼리 엔진을 통해 데이터에 직접 액세스한다.
결과는 쿼리 및 구성 유형에 따라 Hive보다 훨씬 빠른 성능을 보인다.
SQL 요청이 들어오면 Node 중 하나가 SQL을 받고 수행을 한다. 수행을 할 때 Oracle등 DB들이 실행계획을 세우는 옵티마이저나 플래너가 있는 것 처럼 Impala도 동일하게 SQL을 처리하기 위한 플래너가 있다.
처리의 병목이 어디인지 궁금할 때 임팔라 쿼리 플랜으로 summary 정보를 확인할 수 있다. hdfs scan은 얼마나 걸리는지, aggregation은 얼마나 걸리는지 등 step 별로 정보가 나온다. 이 정보를 확인하여 문제를 파악하고 해결하는데 도움을 받을 수 있다.
100대에 임팔라를 설치하고 SQL을 날리면 100대가 동작하게 되는데 어떻게 동작하고 성능에 어떤 영향이 있는지, 어떻게 동작하는지를 쿼리 플랜 안에서 확인할 수 있다. 가장 느리게 도는 곳은 어디고 빠른 곳은 어딘지 확인이 가능하며 두 영역의 차이도 확인할 수 있다.
쿼리 플랜이 세워지면 코디네이터가 마스터가 되어서 SQL을 처리한다.
코디네이터가 SQL을 받으면 Executor들이 작업을 처리하도록 한다. Impala Daemon(Impalad)은 하나지만 내부적으로 마스터 역할을 하는 Coordinator와 실제 업무를 수행하는 Executor의 역할을 모두 수행할 수 있다. 하지만 Impala의 규모가 커지면서 dedicated 모드로 변경이 필요하다.
각각의 데몬들이 통신을 해서 결과를 합산하고 최종 결과를 코디네이터가 받아서 클라이언트 툴에 전달한다.
100개의 Coordinator보다 5개의 Coordinator가 속도가 더 좋은 경우가 있다. 코디네이터가 많으면 통신 cost가 높기 때문이다.
따라서 코디네이터를 무한정 늘리는게 좋지만은 않다. 임팔라의 수가 많아지면 코디네이터를 줄이는 것을 추천한다.(Dedicated Role)
* Impala daemon : Query Planner, Query Coordinator, Query Exec Engine
- 데이터 노드(HDFS DN)의 로컬 처리 덕분에 네트워크 병목 현상이 방지된다.
- 개방형 통합 메타데이터 저장소를 활용할 수 있다 (HMS)
- 비용이 많이드는 데이터 형식 변환이 필요하지 않으므로 오버헤드가 발생하지 않는다.
- 모든 데이터는 ETL에 대한 지연 없이 즉시 쿼리할 수 있다.
- 모든 하드웨어는 MR(MapReduce)뿐만 아니라 Impala쿼리에도 활용된다.
- 단일 머신 풀만 있으면 확장이 가능하다.
Components of the Impala Server
The Impala Daemon(Impalad)
Impala daemon은 Core Impala component로 물리적으로 Impalad 프로세스로 표시된다.
[ Impala Daemon이 수행하는 주요 기능 ]
- 데이터 파일을 읽고 쓴다.
- impala-shell 명령, Hue, JDBC 또는 ODBC에서 전송된 쿼리를 받는다.
- 쿼리를 병렬화하고 클러스터 전체에 작업을 분산한다.
- 중간 쿼리 결과를 중앙 coordinator로 다시 전송한다.
[ Impala Daemon deploy는 아래 방법 중 하나로 진행 가능 ]
- HDFS와 Impala는 같은 위치에 있으며 Impala 데몬은 DataNode와 동일한 호스트에서 실행된다. (우리프로젝트)
- Impala는 컴퓨팅 클러스터에 별도로 배포되며 HDFS, S3, ADLS 등에서 원격으로 읽는다.
Impala daemons는 StateStore와 지속적으로 통신하여 어떤 daemon이 healthy하고(정상이고) 새 작업을 받아들일 수 있는지 확인한다.
또한 클러스터의 Impala daemon이 모든 유형의 객체를 creates, alters, drops 할 때마다 또는 'INSERT' 또는 'LOAD DATA' 문이 Impala를 통해 처리될 때 catalogd daemon(Impala 1.2에 도입)으로부터 broadcast 메시지를 수신한다.
이 백그라운드 통신은 Impala 1.2 이전의 Impala 데몬에서 메타데이터를 조정하는데 필요했던 'REFRESH' 또는 'INVALIDATE METADATA' 문의 필요성을 최소화한다.
CDH 5.12 / Impala 2.9 이상에서는 query coordinators의 역할을 하는 호스트를 제어하여 대규모 클러스터에서 동시 작업량이 많은 워크로드에 대한 확장성을 개선할 수 있다.(Dedicated Role)
* Query Planner
통계값을 가능한 최신으로 up to date 하는 것이 좋다. 예를 들어, 분석가들이 사용하는 쿼리는 outer join이 많이 들어있다. optimizer가 판단하기에 통계값이 없으면 이상한 실행 계획이 나올 수 있다. optimizer는 판단하기에 left side와 right side에 있는 레코드 카운트를 확인한다. 하지만 통계값이 부정확하면 실행계획이 잘못짜여져서 시간이 굉장히 오래걸린다.
(oracle은 sql 이 들어오면 내부적으로 rewriting을 한다. 대부분의 db가 하는 행위이며 임팔라도 동일하게 행동한다. 이때, right, left를 확인해서 오른쪽이 더 크면 outer join을 변경해서 돌린다. (실행계획 변경))
* Profiles / Explain Plans로 알고자 하는 것
Impala를 사용하는 end user는 자신이 날린 Impala query가 어떻게 실행될 것인지에 대한 내용을 확인할 수 있다.
알고자 하는 것은 아래와 같다.
- 이 쿼리의 Bottleneck은 무엇인지?
- A쿼리는 빠르지만 B쿼리는 느린 이유가 무엇인지?
- 쿼리의 성능 향상을 위해 어떻게 튜닝을 하면 좋은지?
* 쿼리플래닝의 Goals?
- 실행 비용 절감
- Partition, Runtime filter, Predicate(술어) pushdown 설정으로 불필요한 작업 감소
- DN block metadata 사용으로 scan locality(검색 인접성/지역성) 최대화
- 데이터 이동 최소화 (연결순서 최적화, 더 나은 Join 전략 선택)
- 병렬 작업 수행 (여러 노드에서 실행하여 실행시간 단축)
Predicate pushdown이란?
데이터를 읽어온 후 메모리에서 필터링하지 않고 파일을 읽을 때 꼭 필요한 데이터만 효율적으로 읽는다.
parquet와 orc 포맷의 파일은 컬럼별로 다양한 stats 데이터를 보관하고 있기 때문에 (min, max) 이 정보로 필요한 데이터만 읽는 것이 가능하다.
* Query profile - Execution Results
- 사용되는 리소스 양
- 각 piece에서 소요되는 시간
- Bottleneck(병목현상)/비정상적인 동작이 있는가?
The Impala Statestore
임팔라 데몬에 대한 멤버십 관리, 임팔라에서 자원을 관리할 때 메인으로 컨트롤 하는 자원은 메모리이다. 메모리 기반의 빠른 엔진을 제공하기 때문이다. statestore가 이를 관리한다. 임팔라에 쿼리를 날리면 그 쿼리를 수행해도 되는지 자원을 가지고 판단하는 역할을 한다.
StateStore로 알려진 Impala 구성요소는 클러스터에 있는 모든 Impala daemons의 상태를 확인하고(checks on the health of all Impala daemons in a cluster) 그 결과를 각 daemon에 지속적으로 전달한다.
이는 statestored라는 데몬 프로세스로 물리적으로 표시된다.
클러스터의 한 호스트에서만 이러한 프로세스가 필요하다. Impala 데몬이 하드웨어 오류, 네트워크 오류, 소프트웨어 문제 또는 기타 이유로 인해 오프라인 상태가 되면 StateStore는 다른 모든 Impala daemon에 알려 이후 쿼리를 수행할 때 연결 불가한 Impala daemon에 대한 요청을 피할 수 있도록 한다.
StateStore의 목적은 일이 잘못되었을 때 도움을 주고 coordinators에게 metadata를 broadcast하는 것이기 때문에 Impala 클러스터의 정상적인 작동에 항상 중요한 것은 아니다.
StateStore가 실행 중이 아니거나 연결할 수 없는 경우에도 Impala daemon은 계속 실행되고 Impala에 알려진 데이터로 작업할 때 평소와 같이 서로 간에 작업을 배포한다.
다른 Impala daemon이 실패하면 클러스터의 견고성이 떨어지고(less robust), StateStore가 오프라인인 동안 메타데이터가 변경됨에 따라 일관성이 떨어진다. StateStore가 다시 온라인 상태가 되면 Impala 데몬과의 통신을 다시 설정하고 모니터링 및 브로드캐스트 기능을 재개한다.
StateStore가 다운된 상태에서 DDL문을 실행하면 DDL로 생성된 객체에 액세스하는 쿼리는 실패한다.
로드 밸런싱 및 고가용성에 대한 대부분의 고려사항은 impalad daemon에서 고려된다. statestored와 catalogd daemons에는 고가용성(high availability)에 대한 특별한 요구사항이 없는데 그 이유는 이들에게 문제가 있어도 데이터 손실이 발생하지 않기 때문이다.
특정 호스트의 중단으로 인해 이러한 데몬을 사용할 수 없게 되면 Impala 서비스를 중지하고, Impala StateStore 및 Impala 카탈로그 서버 역할을 삭제하고, 다른 호스트에서 역할을 추가하고, Impala 서비스를 다시 시작할 수 있다.
The Impala Catalog Service
카탈로그는 테이블에 대한 메타데이터를 가지고 있다. 초대형 프로젝트는 카탈로그 메타데이터만 몇십기가에 달한다.
만약 100대에 임팔라 데몬을 설치하고 코디네이터를 100대를 다 쓴다고 하면 경우에 따라서는 카탈로그가 가진 몇십기가 데이터가 100대에 복제가 된다. (잘못 사용하는 경우) 따라서 특정 몇 대에만 Coordinator 역할을 부여하는 Dedicated Role 방식을 사용해야 한다.
Catalog Service로 알려진 Impala 구성요소는 Impala SQL문에서 클러스터의 모든 Impala 데몬으로 메타데이터 변경 사항을 전달한다. 이는 catalogd라는 데몬 프로세스로 물리적으로 표시된다. 클러스터의 한 호스트에서만 이러한 프로세스가 필요하다. 요청이 StateStore daemon을 통해 전달되기 때문에 동일한 호스트에서 statestored 및 catalogd 서비스를 실행하는 것이 좋다.
catalog service는 메타데이터 변경이 Impala를 통해 실행된 명령문에 의해 실행될 때 'REFRESH' 및 'INVALIDATE METADATA' 명령문을 실행할 필요가 없도록 한다.
Hive를 통해 테이블을 생성하고 데이터를 로드하는 등의 작업을 수행할 때 Impala 노드에서 쿼리를 실행하기 전에 REFRESH 또는 INVALIDATE METADATA를 실행해야 한다.
-> Impala를 통해 테이블 변경 또는 데이터 변경 작업을 수행할 때는 REFRESH, INVALIDATE METADATA 문이 필요하지 않다.
Hive를 통해 작업이 수행되거나 HDFS에서 직접 파일을 조작하여 수행되는 경우 이러한 명령문이 필요하다. 이러한 경우 명령문은 모든 데몬이 아닌 하나의 Impala daemon에서만 실행되면 된다.
__load_catalog_in_background 옵션을 사용하여 테이블의 메타데이터가 로드되는 시기를 제어할 수 있다.
false로 설정하면 테이블의 메타데이터가 처음 참조될 때 로드된다. 이는 특정 쿼리의 첫 번째 실행이 후속 실행보다 느릴 수 있음을 의미한다. Impala 2.2부터 해당 옵션의 기본값은 false이다.
true로 설정하면 쿼리에 해당 메타데이터가 필요하지 않은 경우에도 테이블에 대한 메타데이터를 로드하려고 시도한다. 따라서 메타데이터는 필요한 첫번째 쿼리가 실행될 때 이미 로드될 수 있다. 그러나 다음과 같은 이유로 옵션을 true로 설정하지 않는 것이 좋다.
- 백그라운드 로드는 쿼리별 메타데이터 로드를 방해할 수 있다. 기간은 메타데이터의 양에 따라 다르며 장기 실행 쿼리로 이어질 수 있다.
- Impala는 사용되지 않을 가능성이 있는 테이블에 대한 메타데이터를 로드하여 잠재적으로 카탈로그 크기를 증가시키고 결과적으로 카탈로그 서비스와 impala daemon 모두에 대한 메모리 사용량을 증가시킬 수 있다.
References
https://kerpect.tistory.com/77
https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/impala_components.html
'데이터 엔지니어링' 카테고리의 다른 글
| Hadoop이란? (2) NameNode, Yarn (0) | 2022.08.03 |
|---|---|
| Hadoop이란? (1) (0) | 2022.08.02 |
| DataLake vs DataWarehouse vs DataMart (0) | 2022.07.30 |
| [번역] Kafka Throughput&Latency Best Practices 공식문서 (0) | 2022.07.29 |
| Kafka란? (1) | 아키텍처, 핵심 개념 (0) | 2022.03.04 |
댓글