BigLake 테이블 소개

이 문서에서는 BigLake에 대해 간략하게 설명하고 데이터베이스 테이블 및 Identity and Access Management(IAM)에 익숙하다고 가정합니다. 지원되는 데이터 저장소에 저장된 데이터를 쿼리하려면 먼저 BigLake 테이블을 만들고 GoogleSQL 구문을 사용하여 이를 쿼리해야 합니다.

Cloud Storage BigLake 테이블 만들기 이후 쿼리를 수행합니다.
Amazon S3 BigLake 테이블 만들기 이후 쿼리를 수행합니다.
Azure Blob Storage BigLake 테이블 만들기 이후 쿼리를 수행합니다.

또한 외부 테이블을 BigLake로 업그레이드할 수 있습니다. 자세한 내용은 외부 테이블을 BigLake로 업그레이드를 참조하세요.

BigLake 테이블을 사용하면 액세스 위임으로 외부 데이터 스토어의 구조화된 데이터를 쿼리할 수 있습니다. 액세스 위임은 BigLake 테이블에 대한 액세스 권한을 기본 데이터 스토어에 대한 액세스 권한과 분리합니다. 서비스 계정과 연결된 외부 연결은 데이터 스토어에 연결하는 데 사용됩니다. 이 서비스 계정이 데이터 스토어에서 데이터 가져오기를 처리하므로 사용자에게 BigLake 테이블에 대한 액세스 권한만 부여하면 됩니다. 이렇게 하면 행 수준 및 열 수준 보안을 포함하여 테이블 수준에서 세부 조정된 보안을 적용할 수 있습니다. Cloud Storage 기반 BigLake 테이블의 경우 동적 데이터 마스킹도 사용할 수 있습니다. Amazon S3 또는 Blob Storage 데이터가 있는 BigLake 테이블을 사용하는 멀티 클라우드 분석 솔루션에 대한 자세한 내용은 BigQuery Omni를 참조하세요.

지원되는 데이터 스토어

BigLake 테이블은 다음 데이터 스토어와 함께 사용할 수 있습니다.

임시 테이블 지원

Cloud Storage 기반의 BigLake 테이블은 임시 또는 영구적일 수 있습니다. Amazon S3 또는 Blob Storage 기반 BigLake 테이블은 영구적이어야 합니다.

여러 소스 파일

여러 외부 데이터 소스를 기반으로 BigLake 테이블을 만들 수 있습니다. 단, 해당 데이터 소스의 스키마는 동일해야 합니다.

교차 클라우드 조인

교차 클라우드 조인을 사용하면 Google Cloud와 BigQuery Omni 리전을 포괄하는 쿼리를 실행할 수 있습니다. GoogleSQL JOIN 작업을 사용하여 AWS, Azure, 공개 데이터 세트, 기타 Google Cloud 서비스와 같은 다양한 스토리지 솔루션의 데이터를 분석할 수 있습니다. 교차 클라우드 조인을 사용하면 쿼리를 실행하기 전에 소스 간에 데이터를 복사할 필요가 없습니다.

서브 쿼리를 사용하여 데이터를 검색하는 데이터 조작 언어(DML) 및 데이터 정의 언어(DDL) 문을 포함한 SELECT 문의 어느 위치에서나 BigLake 테이블을 표준 BigQuery 테이블처럼 참조할 수 있습니다. 동일한 쿼리에서 다양한 클라우드의 BigLake 테이블과 BigQuery 테이블을 사용할 수 있습니다. 모든 BigQuery 테이블이 동일한 리전에 있어야 합니다.

교차 클라우드 조인 필수 권한

교차 클라우드 조인을 실행하는 데 필요한 권한을 얻으려면 관리자에게 조인이 실행되는 프로젝트에 대한 BigQuery 데이터 편집자(roles/bigquery.dataEditor) IAM 역할을 부여해 달라고 요청하세요. 역할 부여에 대한 자세한 내용은 액세스 관리를 참조하세요.

이 사전 정의된 역할에는 교차 클라우드 조인을 실행하는 데 필요한 권한이 포함되어 있습니다. 필요한 정확한 권한을 보려면 필수 권한 섹션을 펼치세요.

필수 권한

교차 클라우드 조인을 실행하려면 다음 권한이 필요합니다.

bigquery.datasets.create
bigquery.tables.create

커스텀 역할이나 다른 사전 정의된 역할을 사용하여 이 권한을 부여받을 수도 있습니다.

BigQuery에서 IAM 역할 및 권한에 대한 자세한 내용은 IAM 소개를 참조하세요.

교차 클라우드 조인 비용

교차 클라우드 조인 작업을 실행하면 BigQuery가 쿼리를 로컬 및 원격 부분으로 파싱합니다. 로컬 부분은 BigQuery 리전의 표준 쿼리로 처리됩니다. 원격 부분은 BigQuery Omni 리전의 참조된 BigLake 테이블에서 CREATE TABLE AS SELECT(CTAS) 작업으로 변환되어 BigQuery 리전에 임시 테이블을 만듭니다. 그러면 BigQuery가 이 임시 테이블을 사용하여 교차 클라우드 조인을 실행하고 8시간 후에 테이블을 자동으로 삭제합니다.

참조된 BigLake 테이블의 데이터에는 데이터 전송 비용이 부과됩니다. 하지만 BigQuery는 전체 테이블이 아닌 쿼리에서 참조된 BigLake 테이블의 열과 행만 전송하므로 이러한 비용을 줄이는 데 도움이 됩니다. 전송 비용을 줄이기 위해 가능한 한 좁은 열 필터를 지정하는 것이 좋습니다. 작업 기록에 CTAS 작업이 나타나고 전송된 바이트 수와 같은 정보가 표시됩니다. 기본 쿼리 작업이 실패하더라도 전송에 성공하면 비용이 부과됩니다. 자세한 내용은 BigQuery Omni 가격 책정을 참조하세요.

다음 쿼리를 예시로 들어 보겠습니다.

SELECT *
FROM bigquery_dataset.bigquery_table AS clients
WHERE clients.sales_rep IN (
  SELECT id
  FROM aws_dataset.aws_table1 AS employees
  INNER JOIN aws_dataset.aws_table2 AS active_employees
    ON employees.id = active_employees.id
  WHERE employees.level > 3
);

이 예시에는 직원 테이블(수준 필터 포함)에서 전송하는 경우와 활성 직원 테이블에서 전송하는 경우 등 두 가지 전송이 있습니다. 전송이 발생한 후 BigQuery 리전에서 조인이 수행됩니다. 한 전송에 실패하고 다른 전송에 성공하더라도 성공한 전송에 대한 데이터 전송 요금이 계속 부과됩니다.

교차 클라우드 조인 제한사항

교차 클라우드 조인은 BigQuery 무료 등급 및 BigQuery 샌드박스에서 지원되지 않습니다.
동일한 리전의 여러 BigLake 테이블 조인은 BigQuery Omni 리전으로 푸시다운되지 않습니다.
쿼리에 JOIN 문이 포함된 경우 집계가 BigQuery Omni 리전으로 푸시다운되지 않을 수 있습니다.
각 임시 테이블은 단일 교차 클라우드 쿼리에만 사용되며 동일한 쿼리가 여러 번 반복되더라도 재사용되지 않습니다.
각 전송의 전송 크기 한도는 20GB입니다. 특히 BigLake 테이블에 필터를 적용하고 결과를 로드하는 경우 20GB보다 작아야 합니다. 필요한 경우 더 높은 할당량 한도를 요청할 수 있습니다. 스캔되는 바이트에는 제한이 없습니다.
교차 클라우드 조인 쿼리는 쿼리 비율에 내부 할당량을 사용합니다. 쿼리 비율이 할당량을 초과하면 All our servers are busy processing data transferred between regions 오류가 발생할 수 있습니다. 대부분의 경우 쿼리 재시도가 작동합니다. 내부 할당량을 늘려 더 높은 쿼리 비율을 지원하려면 지원팀에 문의하세요.
교차 클라우드 조인은 해당하는 BigQuery Omni 리전과 같은 위치에 배치된 BigQuery 리전과 US 및 EU 멀티 리전에서만 지원됩니다. US 또는 EU 멀티 리전에서 실행되는 교차 클라우드 조인은 각각 US 또는 EU BigQuery Omni 리전의 데이터에만 액세스할 수 있습니다.
기본적으로 교차 클라우드 조인은 모든 데이터 세트가 알파벳순으로 정렬된 경우 먼저 나열되는 BigQuery 데이터 세트의 BigQuery 리전에서 실행됩니다. 그러나 알파벳순으로 처음 10개의 데이터 세트만 스캔되므로 모두 BigQuery Omni 리전의 BigLake 테이블이면 BigQuery 테이블이 포함된 경우 작업이 실패합니다. 이 문제를 방지하려면 10개가 넘는 데이터 세트를 참조하는 교차 클라우드 조인을 실행할 때 위치를 명시적으로 지정하는 것이 좋습니다. BigQuery 리전을 명시적으로 지정하는 경우 쿼리에 BigLake 테이블만 포함되어 있으면 쿼리가 교차 클라우드 쿼리로 실행되고 데이터 전송 비용이 부과됩니다.
교차 클라우드 조인으로는 _FILE_NAME 유사 열을 쿼리할 수 없습니다.
WHERE 절에서 BigLake 테이블 열을 참조할 때는 NUMERIC, BIGNUMERIC, BYTES, TIME, INTERVAL 리터럴을 사용할 수 없습니다.
교차 클라우드 조인 작업은 다른 클라우드에서 처리되어 전송된 바이트 수를 보고하지 않습니다. 이 정보는 교차 클라우드 쿼리 실행의 일부로 생성되는 하위 CTAS 작업에서 사용할 수 있습니다.

교차 클라우드 조인 예시

다음 쿼리는 BigQuery 리전의 orders 테이블을 BigQuery Omni 리전의 lineitem 테이블과 조인합니다.

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN aws_dataset.lineitem
  ON orders.o_orderkey = lineitem.l_orderkey
WHERE
  l_shipmode IN ('AIR', 'REG AIR')
  AND l_commitdate < l_receiptdate
  AND l_shipdate < l_commitdate
  AND l_receiptdate >= DATE '1997-01-01'
  AND l_receiptdate < DATE '1997-02-01'
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

이 쿼리는 로컬 부분과 원격 부분으로 나뉩니다. 다음 쿼리는 먼저 실행하기 위해 BigQuery Omni 리전으로 전송됩니다. 그 결과 BigQuery 리전에 임시 테이블이 생성됩니다. 작업 기록에서 이 하위 CTAS 작업과 해당 메타데이터를 볼 수 있습니다.

CREATE OR REPLACE TABLE temp_table
AS (
  SELECT
    l_shipmode,
    l_linenumber,
    l_orderkey
  FROM aws_dataset.lineitem
  WHERE
    l_shipmode IN ('AIR', 'REG AIR')
    AND l_commitdate < l_receiptdate
    AND l_shipdate < l_commitdate
    AND l_receiptdate >= DATE '1997-01-01'
    AND l_receiptdate < DATE '1997-02-01'
);

임시 테이블이 생성되면 JOIN 작업이 완료되고 다음 쿼리가 실행됩니다.

SELECT
  l_shipmode,
  o_orderpriority,
  count(l_linenumber) AS num_lineitems
FROM bigquery_dataset.orders
JOIN temp_table
  ON orders.o_orderkey = lineitem.l_orderkey
GROUP BY l_shipmode, o_orderpriority
ORDER BY l_shipmode, o_orderpriority;

또 다른 예시로 다음 교차 클라우드 조인을 고려해 보세요.

SELECT c_mktsegment, c_name
FROM bigquery_dataset.customer
WHERE c_mktsegment = 'BUILDING'
UNION ALL
  SELECT c_mktsegment, c_name
  FROM aws_dataset.customer
  WHERE c_mktsegment = 'FURNITURE'
  LIMIT 10;

이 쿼리에서 LIMIT 절은 BigQuery Omni 리전으로 푸시다운되지 않습니다. FURNITURE 시장 분야의 모든 고객이 먼저 BigQuery 리전으로 전송된 다음 10개 한도가 적용됩니다.

커넥터

BigQuery 커넥터를 사용하여 다른 데이터 처리 도구에서 Cloud Storage 기반 BigLake 테이블의 데이터에 액세스할 수 있습니다. 예를 들어 Apache Spark, Apache Hive, TensorFlow, Trino 또는 Presto에서 BigLake 테이블의 데이터에 액세스할 수 있습니다. BigQuery Storage API는 커넥터를 포함하여 BigLake 테이블에 대한 모든 데이터 액세스에 행 및 열 수준 거버넌스 정책을 적용합니다.

예를 들어 다음 다이어그램은 BigQuery Storage API를 통해 사용자가 Apache Spark와 같은 오픈소스 쿼리 엔진을 사용하여 승인된 데이터에 액세스하는 방법을 보여줍니다.

BigLake 아키텍처.

BigQuery에서 지원하는 커넥터에 대한 자세한 내용은 BigQuery 커넥터를 참조하세요.

객체 저장소의 BigLake 테이블

데이터 레이크 관리자의 경우 BigLake를 사용하면 파일이 아닌 테이블에 대해 액세스 제어를 설정하여, 데이터 레이크에서 데이터에 대해 사용자 액세스를 설정할 때 세밀한 조정 옵션을 선택할 수 있습니다.

BigLake 테이블에서는 이러한 방식으로 액세스 제어가 간소화되기 때문에 BigLake 테이블을 사용하여 외부 객체 저장소에 대한 연결을 빌드하고 유지관리하는 것이 좋습니다.

거버넌스가 필수가 아니거나 임시 데이터 검색 및 조작의 경우 외부 테이블을 사용할 수 있습니다.

제한사항

모든 외부 테이블 제한사항이 BigLake 테이블에 적용됩니다.
객체 저장소의 BigLake 테이블에는 BigQuery 테이블과 동일한 제한사항이 적용됩니다. 자세한 내용은 할당량을 참조하세요.
BigLake는 Dataproc 개인 클러스터 인증의 축소된 사용자 인증 정보를 지원하지 않습니다. 문제 해결을 위해 개인 클러스터 인증으로 클러스터를 사용하려면 --access-boundary=<(echo -n "{}") 플래그와 함께 빈 사용자 인증 정보 액세스 경계를 사용하여 사용자 인증 정보를 삽입해야 합니다. 예를 들어 다음 명령어는 mycluster라는 클러스터의 myproject라는 프로젝트에서 사용자 인증 정보 전파 세션을 사용 설정합니다.
```
gcloud dataproc clusters enable-personal-auth-session \
    --region=us \
    --project=myproject \
    --access-boundary=<(echo -n "{}") \
    mycluster
```
주의: 빈 사용자 인증 정보 액세스 경계를 사용하면 Dataproc 클러스터에서 도용된 사용자 인증 정보를 통한 공격에 대한 한 가지 보호 레이어가 삭제됩니다. 도용된 사용자 인증 정보는 범위 축소 없이 더 큰 영향 범위를 갖습니다.

또는 개인 클러스터 인증을 사용 중지하고 Dataproc 가상 머신(VM) 서비스 계정을 사용자 그룹의 프록시로 사용할 수 있습니다.
BigLake 테이블은 읽기 전용입니다. DML 문 또는 다른 메서드를 사용하여 BigLake 테이블을 수정할 수 없습니다.
BigLake 테이블은 다음 형식을 지원합니다.
- Avro
- CSV
- Delta Lake
- Iceberg
- JSON
- ORC
- Parquet
Apache Iceberg BigLake 테이블에는 캐시된 메타데이터를 사용할 수 없습니다. BigQuery는 이미 Iceberg가 매니페스트 파일에서 캡처하는 메타데이터를 사용하고 있습니다.
AWS 및 Azure와 같은 다른 클라우드 환경에서는 BigQuery Storage API를 사용할 수 없습니다.
캐시된 메타데이터를 사용하는 경우 다음 제한사항이 적용됩니다.
- Avro, ORC, Parquet, JSON, CSV 형식을 사용하는 BigLake 테이블에만 캐시된 메타데이터를 사용할 수 있습니다.
- Amazon S3에서 파일을 만들거나, 업데이트하거나, 삭제하는 경우 파일을 쿼리해도 다음번에 메타데이터 캐시를 새로고침할 때까지 업데이트된 데이터가 반환되지 않습니다. 이로 인해 예기치 않은 결과가 발생할 수 있습니다. 예를 들어 파일을 삭제하고 새 파일을 작성하면 캐시된 메타데이터가 마지막으로 업데이트된 시간에 따라 쿼리 결과에서 이전 파일과 새 파일이 모두 제외될 수 있습니다.
- Amazon S3 또는 Blob Storage 데이터를 참조하는 BigLake 테이블에는 캐시된 메타데이터를 사용하는 고객 관리 암호화 키(CMEK)가 지원되지 않습니다.

보안 모델

BigLake 테이블 관리 및 사용에는 일반적으로 다음과 같은 조직 역할이 포함됩니다.

데이터 레이크 관리자. 이러한 관리자는 일반적으로 Cloud Storage 버킷 및 객체에서 Identity and Access Management(IAM) 정책을 관리합니다.
데이터 웨어하우스 관리자. 이러한 관리자는 일반적으로 테이블을 생성, 삭제, 업데이트합니다.
데이터 분석가. 일반적으로 분석가는 데이터를 읽고 쿼리를 실행합니다.

데이터 레이크 관리자는 연결을 만들어 데이터 웨어하우스 관리자와 공유해야 합니다. 그런 다음 데이터 웨어하우스 관리자가 테이블을 생성하고, 적절한 액세스 제어를 설정하고, 테이블을 데이터 분석기와 공유합니다.

성능을 위한 메타데이터 캐싱

캐시된 메타데이터를 사용해서 BigLake 테이블에서 쿼리 성능을 향상시킬 수 있습니다. 이 방법은 많은 파일로 작업하거나 데이터가 하이브로 분할되는 경우에 특히 유용합니다. BigLake 및 객체 테이블은 Cloud Storage 및 Amazon Simple Storage Service(Amazon S3)와 같은 외부 데이터 소스의 파일에 대한 메타데이터 캐싱을 지원합니다. 메타데이터에는 파일 이름, 파티셔닝 정보, 행 수와 같은 파일의 물리적 메타데이터가 포함됩니다. 테이블에서 메타데이터 캐싱을 사용 설정할지 여부를 선택할 수 있습니다. 파일 수가 더 많고 Hive 파티션 필터가 포함된 쿼리는 메타데이터 캐싱의 이점을 극대화할 수 있습니다.

메타데이터 캐싱을 사용 설정하지 않으면 테이블의 쿼리에서 외부 데이터 소스를 읽어 객체 메타데이터를 가져와야 하므로 쿼리 지연 시간이 길어집니다. 이로 인해 외부 데이터 소스에서 수백만 개의 파일을 나열하는 데 몇 분 정도 걸릴 수 있습니다. 메타데이터 캐싱을 사용 설정하면 쿼리가 외부 데이터 소스의 파일을 나열하지 않고 파티션과 파일 프루닝을 더 빠르게 수행할 수 있습니다.

이 기능을 제어하는 속성은 두 가지입니다.

최대 비활성 - 쿼리가 캐시된 메타데이터를 사용하는 경우 이를 제어
메타데이터 캐시 모드 - 메타데이터 수집 방법 제어

메타데이터 캐싱을 사용 설정했으면 테이블 작업에 허용되는 메타데이터 비활성 간격을 최대한으로 지정합니다. 예를 들어 1시간 간격을 지정하면 이전 한 시간 내에 새로고침된 경우 테이블 작업에 캐시된 메타데이터가 사용됩니다. 캐시된 메타데이터가 이보다 오래된 경우 작업이 Cloud Storage에서 메타데이터를 대신 검색하도록 되돌아갑니다. 비활성 간격은 30분부터 7일까지로 지정할 수 있습니다.

캐시를 자동 또는 수동으로 새로고침하도록 선택할 수 있습니다.

자동 새로고침의 경우 일반적으로 30분에서 60분 사이로 시스템에서 정의된 간격으로 캐시가 새로고침됩니다. 외부 데이터 소스의 파일이 작위 간격으로 추가, 삭제, 수정될 경우에는 캐시를 자동으로 새로고침하는 것이 좋습니다. 추출-변환-로드 작업이 끝날 때 새로고침을 트리거할 때와 같이 새로고침 시간을 제어해야 할 경우에는 수동 새로고침을 사용합니다.
수동 새로고침의 경우 BQ.REFRESH_EXTERNAL_METADATA_CACHE 시스템 프로시져를 실행하여 요구사항을 충족하는 일정에 따라 메타데이터 캐시를 새로고침합니다. 메타데이터를 선택적으로 새로고침하려면 불필요한 메타데이터 처리를 방지하기 위해 테이블 데이터 디렉터리의 하위 디렉터리를 제공하면 됩니다. Cloud Storage의 파일이 파이프라인 출력과 같이 알려진 간격으로 추가, 삭제, 수정될 경우에는 캐시를 수동으로 새로고침하는 것이 좋습니다.

여러 번의 수동 새로고침을 동시에 수행하면 하나만 성공합니다.

메타데이터 캐시는 새로고침되지 않을 경우 7일 후 만료됩니다.

설정하기 전 비활성 간격 및 메타데이터 캐싱 모드 값이 상호작용하는 방식을 고려해야 합니다. 다음 예를 고려하세요.

테이블에 대해 메타데이터 캐시를 수동으로 새로고침할 때 비활성 간격을 2일로 설정하면 테이블 작업에 캐시된 메타데이터가 사용되도록 하려면 BQ.REFRESH_EXTERNAL_METADATA_CACHE 시스템 프로시져를 2일 이내 간격으로 실행해야 합니다.
테이블에 대해 메타데이터 캐시를 자동으로 새로고침할 때 비활성 간격을 30분으로 설정한 경우 메타데이터 캐시 새로고침이 일반적인 30분~60분 기간보다 길어지면 테이블에 대한 작업 중 일부에서 Cloud Storage 읽기가 수행될 수 있습니다.

메타데이터 새로고침 작업에 대한 정보를 보려면 다음 예시에 표시된 것처럼 INFORMATION_SCHEMA.JOBS 뷰를 쿼리합니다.

SELECT *
FROM `region-us.INFORMATION_SCHEMA.JOBS_BY_PROJECT`
WHERE job_id LIKE '%metadata_cache_refresh%'
AND creation_time > TIMESTAMP_SUB(CURRENT_TIMESTAMP(), INTERVAL 6 HOUR)
ORDER BY start_time DESC
LIMIT 10;

Parquet 파일을 기반으로 하는 BigLake 테이블의 경우 메타데이터 캐시 새로고침 중에 테이블 통계가 수집되어 쿼리 계획을 개선하는 데 사용됩니다.

자세한 내용은 메타데이터 캐싱을 참조하세요.

캐싱 옵션 설정에 대한 자세한 내용은 BigLake 테이블 만들기 또는 BigLake 테이블 업데이트를 참조하세요.

구체화된 뷰가 있는 캐시 지원 테이블

Cloud Storage 또는 Amazon Simple Storage Service(Amazon S3)에 저장된 정형 데이터를 쿼리할 때 BigLake 메타데이터 캐시 지원 테이블을 통해 구체화된 뷰를 사용하여 성능과 효율성을 개선할 수 있습니다. 이 구체화된 뷰는 자동 새로고침 및 스마트 조정의 이점을 포함하여 BigQuery 관리형 스토리지 테이블에 대한 구체화된 뷰처럼 작동합니다.

통합

강조 표시된 다음 서비스를 포함한 다른 여러 BigQuery 기능과 gcloud CLI 서비스에서 BigLake 테이블에 액세스할 수 있습니다.

Analytics Hub

BigLake 테이블은 Analytics Hub와 호환됩니다. BigLake 테이블이 포함된 데이터 세트는 Analytics Hub 목록으로 게시할 수 있습니다. Analytics Hub 구독자는 연결된 데이터 세트라고 하는 읽기 전용 데이터 세트를 프로젝트에 프로비저닝하는 이러한 목록을 구독할 수 있습니다. 구독자는 모든 BigLake 테이블을 포함하여 연결된 데이터 세트의 모든 테이블을 쿼리할 수 있습니다. 자세한 내용은 목록 구독을 참조하세요.

BigQuery ML을 사용하여 Cloud Storage의 BigLake에서 모델을 학습시키고 실행할 수 있습니다.

Sensitive Data Protection은 BigLake 테이블을 스캔하여 민감한 정보를 식별하고 분류합니다. 민감한 정보가 감지되면 Sensitive Data Protection 익명화 변환이 해당 데이터를 마스킹 또는 삭제하거나 모호하게 만들 수 있습니다.

비용

비용은 BigLake 테이블의 다음 측면과 관련이 있습니다.

테이블 쿼리
메타데이터 캐시 새로고침

슬롯 예약이 있으면 외부 테이블 쿼리 요금은 청구되지 않습니다. 대신 이러한 쿼리에 슬롯이 소비됩니다.

다음 표에서는 가격 책정 모델이 이러한 비용 적용 방식에 미치는 영향을 보여줍니다.

	주문형 가격 책정	Standard, Enterprise, Enterprise Plus 버전
쿼리	사용자 쿼리로 처리되는 바이트 수에 대한 요금이 청구됩니다.	`QUERY` 작업 유형의 예약 할당에 포함된 슬롯은 쿼리 시간 중에 소비됩니다.
메타데이터 캐시 수동 새로고침	캐시 새로고침을 위해 처리되는 바이트 수에 대한 요금이 청구됩니다.	`QUERY` 작업 유형의 예약 할당에 포함된 슬롯은 캐시 새로고침 중에 소비됩니다.
메타데이터 캐시 자동 새로고침	캐시 새로고침을 위해 처리되는 바이트 수에 대한 요금이 청구됩니다.	`BACKGROUND` 작업 유형의 예약 할당에 포함된 슬롯은 캐시 새로고침 중에 소비됩니다. 메타데이터 캐시 새로고침에 사용 가능한 `BACKGROUND` 예약이 없으면 Enterprise 또는 Enterprise Plus 버전을 사용하는 경우 BigQuery가 대신 `QUERY` 예약의 슬롯을 자동으로 사용합니다.