외부 테이블 소개

이 페이지에서는 외부 테이블을 소개하고 BigQuery 외부에 저장된 데이터를 쿼리하는 방법을 설명합니다.

BigLake 외의 외부 테이블을 사용하면 외부 데이터 스토어에서 구조화된 데이터를 쿼리할 수 있습니다. BigLake 외의 외부 테이블을 쿼리하려면 외부 테이블과 외부 데이터 소스 모두에 대한 권한이 있어야 합니다. 예를 들어 Cloud Storage에서 데이터 소스를 사용하는 BigLake 외부 테이블을 쿼리하려면 다음 권한이 있어야 합니다.

  • bigquery.tables.getData
  • bigquery.jobs.create
  • storage.buckets.get
  • storage.objects.get

지원되는 데이터 스토어

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

임시 테이블 지원

영구 테이블이나 임시 테이블을 사용하여 BigQuery에서 외부 데이터 소스를 쿼리할 수 있습니다. 영구 테이블은 데이터 세트에 생성되고 외부 데이터 소스에 연결된 테이블입니다. 테이블은 영구적이므로 액세스 제어를 사용하여 기본 외부 데이터 소스에 대한 액세스 권한이 있는 다른 사용자와 테이블을 공유할 수 있으며 언제든지 테이블을 쿼리할 수 있습니다.

임시 테이블을 사용하여 외부 데이터 소스를 쿼리하는 경우 쿼리를 포함하고 외부 데이터 소스에 연결된 비영구 테이블을 만드는 명령어를 사용합니다. 임시 테이블을 사용하는 경우 BigQuery 데이터 세트 중 하나에 테이블을 만들지 않습니다. 테이블이 데이터 세트에 영구적으로 저장되지 않으므로 다른 사용자와 테이블을 공유할 수 없습니다. 임시 테이블을 사용하여 외부 데이터 소스를 쿼리하면 외부 데이터에 대한 일회성 임시 쿼리 또는 ETL(추출, 변환, 로드) 프로세스에 유용합니다.

여러 소스 파일

Cloud Storage를 기반으로 BigLake 외의 외부 테이블을 만드는 경우 데이터 소스의 스키마가 동일하면 외부 데이터 소스를 여러 개 사용할 수 있습니다. Bigtable 또는 Google Drive를 기반으로 하는 BigLake 외의 외부 테이블에서는 여러 소스가 지원되지 않습니다.

제한사항

다음 제한사항이 외부 테이블에 적용됩니다.

  • BigQuery에서는 외부 데이터 테이블의 데이터 일관성을 보장하지 않습니다. 쿼리가 실행되는 동안 기본 데이터가 변경되면 예상치 못한 동작이 발생할 수 있습니다.
  • 외부 테이블의 쿼리 성능은 표준 BigQuery 테이블의 데이터를 쿼리할 때보다 느릴 수 있습니다. 쿼리 속도가 중요한 경우에는 외부 데이터 소스를 설정하는 대신 데이터를 BigQuery에 로드합니다. 외부 테이블을 포함한 쿼리 성능은 외부 스토리지 유형에 따라 다릅니다. 예를 들어, Cloud Storage에 저장된 데이터 쿼리는 Google Drive에 저장된 데이터 쿼리보다 빠릅니다. 일반적으로 외부 테이블의 쿼리 성능은 데이터 소스에서 직접 데이터를 읽을 때와 동일합니다.
  • DML 또는 기타 메서드를 사용하여 외부 데이터 테이블을 수정할 수 없습니다. 외부 테이블은 BigQuery에 대해 읽기 전용입니다.
  • TableDataList JSON API 메서드를 사용하여 외부 테이블에서 데이터를 검색할 수 없습니다. 자세한 내용은 tabledata.list를 참조하세요. 제한사항을 우회하려면 대상 테이블에 쿼리 결과를 저장합니다. 그러면 결과 테이블에 TableDataList 메서드를 사용할 수 있습니다.
  • 외부 테이블에서는 데이터를 내보내는 BigQuery 작업을 실행할 수 없습니다. 제한사항을 우회하려면 대상 테이블에 쿼리 결과를 저장합니다. 그런 후 결과 테이블을 대상으로 내보내기 작업을 실행하면 됩니다.
  • 와일드 카드 테이블 쿼리에서는 외부 테이블을 참조할 수 없습니다.
  • 외부 테이블에서는 클러스터링을 지원하지 않습니다. 파티션 나누기는 제한된 방식으로 지원됩니다. 자세한 내용은 외부에서 파티션을 나눈 데이터 쿼리를 참조하세요.
  • Cloud Storage 이외의 외부 데이터 소스를 쿼리하면 결과가 캐시되지 않습니다. (Cloud Storage의 GoogleSQL 쿼리는 지원됩니다.) 동일한 쿼리를 여러 번 발행해도 외부 테이블에 쿼리할 때마다 요금이 청구됩니다. 자주 변경되지 않는 외부 테이블에 반복하여 쿼리해야 하는 경우, 영구 테이블에 쿼리 결과를 작성하여 영구 테이블에 쿼리를 실행하는 것을 고려해 보는 것이 좋습니다.
  • Bigtable 외부 데이터 소스에 대한 동시 쿼리는 16개로 제한됩니다.
  • 외부 테이블을 사용하는 통합 쿼리의 테스트 실행은 행이 반환되더라도 0바이트의 하한 데이터를 보고할 수 있습니다. 이는 외부 테이블에서 처리되는 데이터 양을 실제 쿼리가 완료될 때까지 확인할 수 없기 때문입니다. 통합 쿼리를 실행해도 이 데이터 처리 비용이 발생합니다.
  • 외부 테이블에서는 _object_metadata를 열 이름으로 사용할 수 없습니다. 내부에서 사용하도록 예약되어 있습니다.
  • BigQuery는 외부 테이블의 테이블 스토리지 통계 표시를 지원하지 않습니다.
  • 외부 테이블은 유연한 열 이름을 지원하지 않습니다.

위치 고려사항

데이터 위치를 선택할 때는 다음 사항을 고려해야 합니다.

Cloud Storage

다음 방법으로 BigQuery를 사용하여 Cloud Storage 데이터와 통합할 수 있습니다.

Cloud Storage 데이터 쿼리

BigLake 또는 BigLake 이외의 외부 테이블을 사용하여 Cloud Storage에서 데이터를 쿼리할 때는 쿼리하는 데이터가 BigQuery 데이터 세트와 같은 위치에 있어야 합니다. 예를 들면 다음과 같습니다.

  • 단일 리전 버킷: BigQuery 데이터 세트가 바르샤바(europe-central2) 리전에 있으면 해당 Cloud Storage 버킷도 바르샤바 리전 또는 바르샤바가 포함된 Cloud Storage 이중 리전에 있어야 합니다. BigQuery 데이터 세트가 US 멀티 리전에 있으면 Cloud Storage 버킷은 US 멀티 리전, 아이오와(us-central1) 단일 리전 또는 아이오와가 포함된 모든 이중 리전에 있을 수 있습니다. 버킷이 데이터 세트의 멀티 리전 내에 포함된 위치에 있더라도 다른 단일 리전의 쿼리는 실패합니다. 예를 들어 외부 테이블이 US 멀티 리전에 있고 Cloud Storage 버킷이 오리건(us-west1)에 있으면 작업이 실패합니다.

    BigQuery 데이터 세트가 EU 멀티 리전에 있으면 Cloud Storage 버킷은 EU 멀티 리전, 벨기에(europe-west1) 단일 리전 또는 벨기에가 포함된 모든 이중 리전에 있을 수 있습니다. 버킷이 데이터 세트의 멀티 리전 내에 포함된 위치에 있더라도 다른 단일 리전의 쿼리는 실패합니다. 예를 들어 외부 테이블이 EU 멀티 리전에 있고 Cloud Storage 버킷이 바르샤바(europe-central2)에 있으면 작업이 실패합니다.

  • 이중 리전 버킷: BigQuery 데이터 세트가 도쿄(asia-northeast1) 리전에 있으면 해당 Cloud Storage 버킷은 도쿄 리전 또는 도쿄가 포함된 이중 리전(예: ASIA1 이중 리전)에 있어야 합니다.

    Cloud Storage 버킷이 NAM4 이중 리전 또는 아이오와(us-central1) 리전이 포함된 이중 리전에 있으면 해당 BigQuery 데이터 세트는 US 멀티 리전 또는 아이오와(us-central1)에 있을 수 있습니다.

    Cloud Storage 버킷이 EUR4 이중 리전 또는 벨기에(europe-west1) 리전이 포함된 이중 리전에 있으면 해당 BigQuery 데이터 세트는 EU 멀티 리전 또는 벨기에(europe-west1)에 있을 수 있습니다.

  • 멀티 리전 버킷: 외부 쿼리 성능은 최소 지연 시간과 최적의 네트워크 대역폭에 따라 달라지므로 외부 테이블에는 멀티 리전 Cloud Storage 버킷이 있는 멀티 리전 데이터 세트 위치를 사용하지 않는 것이 좋습니다.

    BigQuery 데이터 세트가 US 멀티 리전에 있으면 해당 Cloud Storage 버킷은 US 멀티 리전, 아이오와(us-central1)가 포함된 이중 리전(예: NAM4 이중 리전) 또는 아이오와(us-central1)가 포함된 커스텀 이중 리전에 있어야 합니다.

    BigQuery 데이터 세트가 EU 멀티 리전에 있으면 해당 Cloud Storage 버킷은 EU 멀티 리전, 벨기에(europe-west1)가 포함된 이중 리전(예: EUR4 이중 리전) 또는 벨기에가 포함된 커스텀 이중 리전에 있어야 합니다.

지원되는 Cloud Storage 위치에 대한 자세한 내용은 Cloud Storage 문서의 버킷 위치를 참조하세요.

Cloud Storage에서 데이터 로딩

BigLake 또는 BigLake 외의 외부 테이블을 사용하여 Cloud Storage에서 데이터를 로드할 때 로드하는 데이터는 BigQuery 데이터 세트와 같은 위치에 있어야 합니다.

  • BigQuery 데이터 세트가 US 멀티 리전에 있으면 모든 위치에 있는 Cloud Storage 버킷에서 데이터를 로드할 수 있습니다.

  • 멀티 리전 버킷: 로드하려는 Cloud Storage 버킷이 멀티 리전 버킷에 있으면 BigQuery 데이터 세트는 같은 멀티 리전이나 같은 멀티 리전 버킷에 포함된 단일 리전 버킷에 있을 수 있습니다. 예를 들어 Cloud Storage 버킷이 EU 리전에 있으면 BigQuery 데이터 세트는 EU 멀티 리전이나 EU의 단일 리전에 있을 수 있습니다.

  • 이중 리전 버킷: 로드하려는 Cloud Storage 버킷이 이중 리전 버킷에 있으면 BigQuery 데이터 세트는 이중 리전 버킷에 포함된 리전이나 이중 리전이 포함된 멀티 리전에 있을 수 있습니다. 예를 들어 Cloud Storage 버킷이 EUR4 리전에 있으면 BigQuery 데이터 세트는 핀란드(europe-north1) 단일 리전, 네덜란드(europe-west4) 단일 리전 또는 EU 멀티 리전 중 하나에 있을 수 있습니다.

  • 단일 리전 버킷: 로드하려는 Cloud Storage 버킷이 단일 리전에 있으면 BigQuery 데이터 세트는 같은 단일 리전이나 단일 리전이 포함된 멀티 리전에 있을 수 있습니다. 예를 들어 Cloud Storage 버킷이 핀란드(europe-north1) 리전에 있으면 BigQuery 데이터 세트는 핀란드 또는 EU 멀티 리전에 있을 수 있습니다.

  • 한 가지 예외는 BigQuery 데이터 세트가 asia-northeast1 리전에 있는 경우 Cloud Storage 버킷이 EU 멀티 리전에 있을 수 있다는 점입니다.

자세한 내용은 데이터 일괄 로드를 참조하세요.

Cloud Storage로 데이터 내보내기

데이터를 내보내기 위한 Cloud Storage 버킷을 같은 위치에 배치합니다.
  • BigQuery 데이터 세트가 EU 멀티 리전에 있는 경우 내보내는 데이터가 포함된 Cloud Storage 버킷이 동일한 멀티 리전이나 멀티 리전 내에 포함된 위치에 있어야 합니다. 예를 들어 BigQuery 데이터 세트가 EU 멀티 리전에 있으면 Cloud Storage 버킷은 EU 내에 있는 europe-west1 벨기에 리전에 있을 수 있습니다.

    데이터 세트가 US 멀티 리전에 있는 경우 데이터를 모든 위치의 Cloud Storage 버킷으로 내보낼 수 있습니다.

  • 데이터 세트가 한 리전에 있으면 Cloud Storage 버킷은 같은 리전에 있어야 합니다. 예를 들어 데이터 세트가 asia-northeast1 도쿄 리전에 있으면 Cloud Storage 버킷은 ASIA 멀티 리전에 있을 수 없습니다.

자세한 내용은 테이블 데이터 내보내기를 참조하세요.

Bigtable

BigQuery 외부 테이블을 통해 Bigtable에서 데이터를 쿼리할 때는 Bigtable 인스턴스가 BigQuery 데이터 세트와 동일한 위치에 있어야 합니다.

  • 단일 리전: BigQuery 데이터 세트가 벨기에(europe-west1) 리전 위치에 있는 경우 해당 Bigtable 인스턴스가 벨기에 리전에 있어야 합니다.
  • 멀티 리전: 외부 쿼리 성능은 최소 지연 시간과 최적의 네트워크 대역폭에 따라 달라지므로 Bigtable의 외부 테이블에 멀티 리전 데이터 세트 위치를 사용하지 않는 것이 좋습니다.

지원되는 Bigtable 위치에 대한 자세한 내용은 Bigtable 위치를 참조하세요.

Google Drive

위치 고려 사항은 Google Drive 외부 데이터 소스에는 적용되지 않습니다.

데이터 관리

    데이터 관리 계획을 세웁니다.
    • BigQuery 데이터 세트 또는 Cloud Storage 버킷과 같은 리전 내 스토리지 리소스를 선택한 경우 데이터를 지리적으로 관리하기 위한 계획을 세웁니다.

위치 간 데이터 이동

한 위치에서 다른 위치로 데이터 세트를 수동으로 이동하려면 다음 단계를 수행합니다.

  1. 데이터 세트와 같은 위치 또는 데이터 세트 위치에 포함된 위치에 있는 Cloud Storage 버킷으로 BigQuery 테이블의 데이터를 내보냅니다. 예를 들어 데이터 세트가 EU 멀티 리전 위치에 있으면 데이터를 EU에 속하는 europe-west1 벨기에 위치로 내보낼 수 있습니다.

    BigQuery에서 데이터를 내보내는 경우에는 요금이 청구되지 않지만 Cloud Storage에 내보낸 데이터를 저장하는 경우에는 요금이 청구됩니다. BigQuery 내보내기를 사용하는 경우 내보내기 작업의 제한사항이 적용됩니다.

  2. 내보낸 Cloud Storage 버킷에서 대상 위치에 만든 새 버킷으로 데이터를 복사하거나 옮깁니다. 예를 들어 데이터를 US 멀티 리전에서 asia-northeast1 도쿄 리전으로 이동하는 경우 데이터를 도쿄에서 만든 버킷으로 전송합니다. Cloud Storage 객체 전송에 대한 자세한 내용은 Cloud Storage 문서에서 객체 복사, 이름 바꾸기, 이동을 참조하세요.

    리전 간에 데이터를 전송하면 Cloud Storage에서 네트워크 이그레스 요금이 청구됩니다.

  3. 새 위치에 새 BigQuery 데이터 세트를 만들고 Cloud Storage 버킷에서 새 데이터 세트로 데이터를 로드합니다.

    BigQuery로 데이터를 로드하는 경우에는 요금이 청구되지 않지만 데이터 또는 버킷을 삭제하기 전에 데이터를 Cloud Storage에 저장하면 요금이 청구됩니다. 데이터를 로드한 후 BigQuery에 데이터를 저장하는 경우에도 요금이 청구됩니다. BigQuery에 데이터 로드에는 로드 작업 한도가 적용됩니다.

Cloud Composer를 사용하여 대규모 데이터 세트를 프로그래매틱 방식으로 이동하고 복사할 수도 있습니다.

Cloud Storage를 사용하여 대규모 데이터세트를 저장 및 이동하는 방법에 대한 자세한 내용은 빅데이터에 Cloud Storage 사용을 참조하세요.

가격 책정

BigQuery에서 외부 테이블을 쿼리할 때는 BigQuery 주문형(TiB당) 가격 책정을 사용하는 경우 쿼리 실행 및 해당 읽은 바이트 수에 따라 또는 BigQuery 용량(슬롯 시간당) 가격 책정을 사용하는 경우에는 슬롯 소비에 따라 비용이 청구됩니다.

데이터가 ORC 또는 Cloud Storage의 Parquet에 저장된 경우 데이터 크기 계산을 참조하세요.

또한 애플리케이션의 가격 책정 가이드 라인에 따라 소스 애플리케이션에서 사용되는 데이터 및 리소스 저장 비용이 청구됩니다.

다음 단계