Cloudera CDH/CDP 및 Hadoop EcoSystem, Semantic IoT등의 개발/운영 기술을 정리합니다. gooper@gooper.com로 문의 주세요.
Apache Kudu에서 동일한 이름의 테이블을 반복적으로 DROP → CREATE → INSERT하는 로직을 2분 간격으로 10회 수행할 때 발생할 수 있는 주요 이슈는 다음과 같습니다:
1. 메타데이터 동기화 문제 (Impala-Kudu 간 불일치)
-
증상:
DROP TABLE후 즉시CREATE TABLE을 수행하면, Impala의 메타스토어가 Kudu의 변경 사항을 즉시 인식하지 못해INSERT시 "Table not found" 오류 발생. -
원인:
Impala는 메타데이터를 기본적으로 캐싱하며, Kudu 테이블 삭제/생성 시 자동으로 갱신되지 않음. -
해결 방안:
CREATE TABLE후 Impala에서INVALIDATE METADATA [테이블명]명령어로 메타데이터 강제 갱신.
2. 테이블릿(Tablet) 관리 오버헤드
-
증상:
테이블릿 생성/삭제 반복으로 Kudu 마스터 서버의 CPU/메모리 사용량 급증.
(특히, 파티셔닝이 잘못된 테이블의 경우 단일 테이블릿에 쓰기가 집중되어 핫스팟 발생) -
원인:
-
테이블릿은 물리적 저장 단위로, 생성 시 분산 및 복제 프로세스가 동반됨.
-
반복적인 생성/삭제로 인해 백그라운드 쓰레드(
maintenance_manager)가 과부하 상태에 빠짐.
-
-
해결 방안:
-
파티셔닝 전략 개선 (예:
HASH+RANGE혼용). -
Kudu 설정 조정 (
--maintenance_manager_num_threads증가).
-
3. WAL(Write Ahead Log) 누적 및 디스크 I/O 병목
-
증상:
삽입 작업 시 지연이 점차 증가하거나,INSERT실패 로그 발생. -
원인:
-
Kudu는 모든 쓰기 작업을 WAL에 기록 후 메모리(MemRowSet)에 저장.
-
반복적인 테이블 삭제/생성으로 WAL 파일이 즉시 정리되지 않아 디스크 공간 부족 발생 가능.
-
단일 디스크에 WAL이 저장되는 경우 I/O 경합 심화.
-
-
해결 방안:
-
WAL 전용 디스크 할당 (
--fs_wal_dir설정). -
주기적인 로그 정리 스크립트 추가.
-
4. 메모리 누수(Memory Leak) 및 GC 과부하
-
증상:
Kudu 서버의 Heap 메모리 사용량이 반복 작업 후 지속적으로 증가.
GC(Garbage Collection) 로그에서Full GC빈도 증가. -
원인:
-
테이블릿 메타데이터, 쓰기 버퍼 등이 완전히 해제되지 않고 누적됨.
-
Java 기반 Kudu 마스터 서버의 GC 정책 미최적화.
-
-
해결 방안:
-
JVM 힙 크기 조정 (
--memory_limit_hard_bytes). -
주기적인 Kudu 서버 재시작으로 메모리 초기화.
-
5. 동시성 충돌(Concurrency Issues)
-
증상:
동일 테이블에 대한DROP/CREATE작업 중 "Table already exists" 또는 "Tablet not found" 오류. -
원인:
-
Kudu의 DDL 작업은 완전한 원자성(atomicity)을 보장하지 않음.
-
작업 간 간격(2분)이 Kudu의 내부 상태 갱신 주기보다 짧은 경우.
-
-
해결 방안:
-
동시성 제어를 위한 락(lock) 메커니즘 도입 (예: ZooKeeper 분산 락).
-
작업 실패 시 재시도 로직 추가.
-
6. 디스크 공간 부족
-
증상:
No space left on device오류로 인해 테이블 생성 실패. -
원인:
-
DROP TABLE이 논리적 삭제만 수행하고 물리적 데이터 파일을 즉시 삭제하지 않음. -
Kudu의 백그라운드 컴팩션 작업이 느린 경우.
-
-
해결 방안:
-
kudu fs clean명령어로 잔여 데이터 수동 삭제. -
디스크 모니터링 도구를 활용한 사전 예방.
-
권장 최적화 전략
-
테이블 재사용:
가능하면TRUNCATE TABLE로 데이터만 삭제하고 테이블 구조를 재활용.
(단, Kudu는TRUNCATE를 직접 지원하지 않으므로INSERT OVERWRITE또는 파티션 드롭으로 대체) -
비동기 처리:
DDL 작업과 데이터 삽입을 분리하여 배치 처리. -
모니터링:
Kudu 웹 UI(http://kudu-master:8051)에서 Tablet Server 상태 및 메모리 사용량 실시간 확인. -
테스트 환경 검증:
실제 데이터 볼륨과 동일한 조건에서 성능 테스트 수행.
반복적인 DDL 작업은 Kudu 클러스터에 부하를 유발하므로, 가능한 한 테이블을 재생성하지 않는 아키텍처를 고려하는 것이 좋습니다.