Page History

• Impala는 다음과 같이 Query 요청을 처리하는 노드를 별도로 구성할 수 있고 이를 Impala Coordinator라고 칭하며 모든 Impala Worker(Impala Deamon)은 Impala Coordinator가 될 수 있으며, 별도로 Impala Coordinator를 둘 수 있음
• Impala Coordinator의 주요 역할은 메타데이터를 캐슁하고, 쿼리 플랜을 작성하고, 쿼리를 실행을 관리하는 것임

Image Modified

• Impala Daemon은 자체적으로 메타데이터를 캐쉬를 가지고 있고, 메타데이터 캐쉬를 관리하는 대상 서비스는 Impala Catalog이며, 이 두 캐쉬는 기본적으로 동기화가 되어야 함
• 동기화가 되어 있지 않다면 테이블이나 컬럼 등의 변경 사항을 탐지하지 못함
• Impala StateStore는 메타데이터 동기화를 요청하는 notification을 담당하여 메타데이터가 변경되었을 때 Impala Deamon에 변경을 요청하는 메시지를 송신함

Image Modified

• 테이블 생성 등과 같이 메타데이터 변경이 발생하면
  • User가 Create SQL을 실행 → 특정 Impala Daemon 또는 Impala Coordinator가 Create SQL을 실행 → 자기 자신의 메타데이터 업데이트 → Impala Catalog 업데이트 → Impala StateStore 통보 → 나머지 다른 Impala Daemon 또는 Coordinator의 메타데이터 업데이트

• Impala Coordinator가 HAProxy 또는 L4 Load Balancer로 묶여 있으면 메타데이터 변경시 동기화 이슈가 발생
  • 2번 과정에서 테이블이 생성되면 메타데이터가 캐슁
  • 그러나 5번 과정에서 해당 Impala Catalog는 아직 메타데이터가 동기화되어 있지 않아서 NOT FOUND ERROR 발생
• Impala Coordinator를 L4에 붙여서 사용하는 경우는 이중화 및 메타데이터 캐슁에 필요로 하는 작업 최소화 및 메모리 소비를 최대한 줄이기 위함
  • Impala Daemon은 실제로 메타데이터를 가지고 있지 않도록 하고 Impala Coordinator만 가지고 있도록 하여 메모리 소비 최소화
  • 동기화 대상 노드수가 줄어들어서 시스템 오버헤드 줄이도록 함

• 이 문제를 해결하려면
  • SYNC_DDL 옵션을 통해서 테이블을 생성하여 모든 노드에 동기화가 강제로 되도록 설정 (몇초의 시간이 필요함)
  • Impala Shell 등으로 테이블을 생성하고 이때 SET SYNC_DDL 옵션을 설정한 후에 메타데이터 변경 쿼리를 실행해야 함
• SELECT 위주의 시스템 인 경우 Impala Coordinator에 여러 개를 두어도 상관없이 잘 동작하나, DDL이 자주 발생하면 동기화에 대해서 잠시 여유가 있어야 함
  • 타 사이트에서도 이를 대비하기 위해서 잠시 대기를 하거나
  • ETL 처리 처럼 미리 테이블을 만들고 동기화가 없도록 하거나 하는 형태로 구현