경계 없는 Lakehouse 및 관련 리소스에서 메타데이터 테이블 쿼리, metadata.json 파일 크기 제한, 멀티 리전 카탈로그 구성과 관련된 문제를 포함한 오류를 진단하고 해결할 수 있습니다.
이러한 문제를 해결하면 레이크하우스 워크로드 전반에서 테이블 작업 및 쿼리 실행을 복원할 수 있습니다.
메타데이터 테이블을 쿼리할 수 없음
이 문제는 5부분으로 구성된 이름 식별자를 사용하여 BigQuery의 Lakehouse 런타임 카탈로그에서 지원하는 Apache Iceberg 테이블의 메타데이터 테이블(예: .snapshots 또는 .files)을 쿼리할 때 발생합니다.
이 문제를 해결하려면 Apache Spark를 사용하여 이러한 테이블을 쿼리하세요.
metadata.json 파일 크기 한도
Apache Iceberg metadata.json 파일 크기는 1MB로 제한됩니다. 이 한도는 테이블 스냅샷, 스키마, 파티션 사양을 추적하는 메타데이터 파일에 적용됩니다. 메타데이터 파일이 이 크기를 초과하면 Apache Iceberg REST 카탈로그 엔드포인트를 통해 테이블 작업을 수행할 때 오류가 발생할 수 있습니다.
이 문제를 해결하려면 Google 계정팀에 문의하여 한도 상향을 요청하세요.
멀티 리전 카탈로그를 쿼리할 때 NOT_FOUND 오류
이 문제는 기본 위치를 지정하지 않고 멀티 리전 Cloud Storage 버킷을 사용하여 Lakehouse 런타임 카탈로그에서 카탈로그를 만든 후 BigQuery 가상 리전(예: US 또는 EU)을 지정하여 카탈로그를 쿼리하려고 할 때 발생합니다.
멀티 리전 버킷으로 카탈로그를 만들면 해당 메타데이터는 해당 BigQuery 가상 리전이 아닌 멀티 리전의 지리적 범위 내에 있는 특정 리전 위치에 저장됩니다. 메타데이터가 없는 가상 리전에서 쿼리를 강제로 실행하면 NOT_FOUND 오류와 함께 쿼리가 실패합니다.
이 문제를 해결하려면 카탈로그를 만들 때 기본 위치(예: US 또는 EU)를 지정합니다. 자세한 내용은 미국 및 EU 멀티 리전의 기본 리전 지정을 참조하세요.
스토리지 최적화 작업이 INFORMATION_SCHEMA.JOBS에 표시되지 않음
이 문제는 Apache Iceberg 테이블에서 테이블 관리를 사용 설정하고 데이터 변형(예: 삽입 또는 DML 문)을 수행하지만 INFORMATION_SCHEMA.JOBS 뷰에 스토리지 최적화 작업(예: CALL BQ.OPTIMIZE_STORAGE)이 표시되지 않는 경우에 발생합니다. 이러한 작업을 쿼리하는 방법에 대한 자세한 내용은 Iceberg 스토리지 최적화 작업 가져오기를 참조하세요.
이는 저장용량 최적화를 건너뛸 때 발생하는 정상적인 동작입니다. 테이블 관리는 데이터 변형 후 테이블 레이아웃을 평가하고 데이터 파일에 압축 또는 재구조화가 필요한 경우에만 최적화 작업을 실행합니다. 백그라운드 테이블 관리 작업은 프로젝트에서 실행되고 컴퓨팅 리소스를 사용하므로 테이블 레이아웃이 이미 최적화된 경우 BigQuery는 데이터를 다시 작성하지 않습니다. 다음 조건에서는 최적화가 건너뛰기됩니다.
- 파일이 이미 최적임: 기존 데이터 파일이 이미 대상 파일 크기에 가깝거나 그 이상입니다(압축되지 않은 평균 크기가 256MB의 50% 이상).
- 기준 미충족: 테이블에 작은 파일이 충분히 누적되지 않았거나 압축에 필요한 크기 기준(예: 총 테이블 크기 1GB 초과)을 충족하지 않습니다.
저장소 최적화를 건너뛰면 백그라운드 작업이 실행되지 않고 INFORMATION_SCHEMA.JOBS에 항목이 로깅되지 않습니다.
쿼리 성능이 요구사항을 충족하고 파일 크기가 이미 적절한 경우 별도의 조치가 필요하지 않습니다. 향후 쓰기로 인해 파일 단편화가 충분히 발생하면 스토리지 최적화가 자동으로 실행됩니다.
테스트 환경에서 스토리지 최적화 작업을 관찰하려면 시간이 지남에 따라 크기가 1GB를 초과하는 테이블에 여러 개의 작은 데이터 배치를 삽입하여 파일 단편화를 시뮬레이션합니다.