Impala 에서 S3 LOCATION 테이블에 쓰기가 실패하며 코디네이터 로그에 다음 예외가 남는 경우가 있다. 여러 백엔드 호스트에서 동시에 같은 증상이 나오면 공통 설정 문제일 가능성이 높다.
DiskChecker$DiskErrorException: Could not find any valid local directory
for s3ablock-0001- with requested size 67108864
as the max capacity in any directory is 0
S3 권한이나 테이블 LOCATION, 네트워크 문제가 아니라 impalad 호스트의 로컬 디스크 문제다.
S3A 커넥터는 S3 로 쓸 때 데이터를 바로 올리지 않고 멀티파트 업로드 블록을 로컬 디스크에 먼저 버퍼링한다(fs.s3a.fast.upload.buffer=disk 가 기본). 그 버퍼 파일 이름이 s3ablock- 으로 시작한다. requested size 67108864 은 64MB 로 fs.s3a.multipart.size 값이고, max capacity in any directory is 0 은 버퍼 디렉터리에 쓸 공간이 없다는 뜻이다.
다만 이 메시지는 두 상황에서 모두 나온다. 하나는 후보 디렉터리의 가용 용량이 실제로 0 인 경우이고, 다른 하나는 순회할 후보 디렉터리 목록 자체가 비어 있어 LocalDirAllocator 의 초기값 0 이 그대로 출력되는 경우다. df 로 확인했을 때 여유 공간이 충분하다면 후자이며, 설정이 빈 값으로 들어갔거나 존재하지 않는 경로를 가리키고 있다는 신호다.
버퍼 디렉터리가 어디로 잡혀 있는지 본다. 미설정이면 ${hadoop.tmp.dir}/s3a 로 전개되어 보통 /tmp/hadoop-impala/s3a 가 된다. hadoop.tmp.dir 자체가 비어 있으면 /s3a 로 전개돼 root 아래에 만들지 못한다.
grep -A2 -E "fs.s3a.buffer.dir|hadoop.tmp.dir" /etc/impala/conf/core-site.xml
Cloudera Manager 환경에서 impalad 가 실제로 읽는 conf 는 /etc/impala/conf 가 아니라 프로세스별 디렉터리에 따로 배포된다. 실제 적용값은 여기서 확인해야 한다.
ls -l /proc/<impalad-pid>/cwd
cd $(ls -dt /var/run/cloudera-scm-agent/process/*IMPALAD* | head -1)
grep -iE "s3a.buffer|tmp.dir|fast.upload" core-site.xml
경로가 정해졌으면 각 impalad 호스트에서 존재·권한·용량을 확인한다.
for h in <host1> <host2> <host3>; do
echo "=== $h"
ssh $h 'ls -ld /tmp/hadoop-impala/s3a; df -h /tmp; mount | grep -w /tmp'
done
ps -o user= -C impalad
의심 순서는 /tmp 가 가득 찬 경우, 디렉터리 소유자가 impala 가 아닌 경우, 디렉터리 자체가 없는 경우, /tmp 가 작은 tmpfs 라 64MB 요구를 못 맞추는 경우다. impalad 가 PrivateTmp=yes 로 뜨면 셸에서 보는 /tmp 와 impalad 가 보는 /tmp 가 달라 아무리 찾아도 나오지 않는다. 그때는 프로세스 기준으로 확인한다.
ls -l /proc/<impalad-pid>/root/tmp/
cat /proc/<impalad-pid>/environ | tr '\0' '\n' | grep -i tmp
/tmp 에 hsperfdata_impala 가 impala:impala 소유로 보인다면 impalad JVM 이 /tmp 에 쓸 수 있다는 뜻이고 셸과 같은 /tmp 를 본다는 뜻이므로, 권한 문제와 네임스페이스 분리 가설은 모두 폐기된다.
/tmp 의존을 끊고 넉넉한 데이터 디스크로 명시 지정하는 것이 정석이다. Cloudera Manager → Impala → Impala Service Advanced Configuration Snippet (Safety Valve) for core-site.xml 에 넣는다.
<property>
<name>fs.s3a.buffer.dir</name>
<value>/data/01/impala/s3a,/data/02/impala/s3a</value>
</property>
각 impalad 호스트에 디렉터리를 미리 만들어 둔다.
mkdir -p /data/0{1,2}/impala/s3a
chown impala:impala /data/0{1,2}/impala/s3a
chmod 700 /data/0{1,2}/impala/s3a
df -h /data/01 # 64MB × 동시 업로드 수 이상 여유 확인
Impala 를 재시작한 뒤 재시도한다.
/tmp/hadoop-impala/s3a 를 손으로 만들어 넘기는 것은 임시 확인용이다. systemd-tmpfiles 가 주기적으로 청소하므로 며칠 뒤 같은 증상이 재발한다.fs.s3a.fast.upload.buffer=bytebuffer 로 바꾸면 디스크를 타지 않지만 힙 밖 메모리를 쓰기 때문에 동시 쿼리가 많으면 impalad 가 OOM 으로 죽는다. 임시 회피용으로만 쓴다./varz 페이지는 Impala gflags 를 보여주며 Hadoop Configuration 전체를 덤프하지 않는다. 여기서 fs.s3a.buffer.dir 이나 hadoop.tmp.dir 이 검색되지 않는 것은 설정이 없다는 증거가 되지 못한다./tmp/hsperfdata_impala 는 JVM 이 자동으로 만드는 성능 카운터 디렉터리이고 안의 숫자 파일은 impalad PID 다. S3A 버퍼와는 무관하다.대화에서는 실제 적용 중인 core-site.xml 의 grep 결과를 확보하지 못해 원인을 확정하지 못했다. fs.s3a.buffer.dir 을 명시 지정하고 재시작한 뒤에도 실패한다면 S3A 버퍼가 아니라 staging 경로 권한이나 fs.s3a. 자격 증명 쪽을 확인해야 한다.