BigQuery Omni 소개

BigQuery Omni를 사용하면 BigLake 테이블을 사용하여 Amazon Simple Storage Service(Amazon S3) 또는 Azure Blob Storage에 저장된 데이터에 대해 BigQuery 분석을 실행할 수 있습니다.

많은 조직들이 데이터를 퍼블릭 클라우드에 저장합니다. 하지만 모든 데이터에서 유용한 정보를 얻는 것이 어렵기 때문에 이러한 데이터가 결국 고립되는 경우가 많습니다. 저렴하고, 빠르고, 분산된 데이터 거버넌스에 따른 추가 오버헤드를 일으키지 않는 멀티 클라우드 데이터 도구를 사용해서 데이터를 분석할 수 있어야 합니다. BigQuery Omni를 사용하면 통합된 인터페이스를 통해 이러한 문제를 줄일 수 있습니다.

외부 데이터에 대한 BigQuery 분석을 실행하려면 먼저 Amazon S3 또는 Blob Storage에 연결해야 합니다. 외부 데이터를 쿼리하려면 Amazon S3 또는 Blob Storage 데이터를 참조하는 BigLake 테이블을 만들어야 합니다.

또한 교차 클라우드 전송을 사용하여 클라우드 간에 데이터를 이동하여 클라우드 간 데이터를 결합하거나 교차 클라우드 조인을 사용하여 클라우드 간 데이터를 쿼리할 수 있습니다. BigQuery Omni는 데이터가 있는 위치에서 데이터를 분석하는 기능과 필요에 따라 데이터를 복제할 수 있는 유연성이 포함된 클라우드 간 분석 솔루션을 제공합니다. 자세한 내용은 교차 클라우드 전송으로 데이터 로드교차 클라우드 조인을 참조하세요.

아키텍처

BigQuery 아키텍처는 스토리지에서 컴퓨팅을 분리하고 필요에 따라 대용량 워크로드를 처리하기 위해 BigQuery 수평 확장을 허용합니다. BigQuery Omni는 다른 클라우드에서 BigQuery 쿼리 엔진을 실행하여 이 아키텍처를 확장합니다. 그 결과 데이터를 BigQuery 스토리지로 물리적으로 이동할 필요가 없습니다. 처리 작업은 데이터가 이미 있는 위치에서 수행됩니다.

BigQuery Omni 아키텍처

Google Cloud 콘솔에 표시하는 것과 같이 보안 연결을 통해 쿼리 결과를 Google Cloud로 반환할 수 있습니다. 또는 결과를 Amazon S3 버킷 또는 Blob Storage에 직접 기록할 수 있습니다. 이 경우 쿼리 결과에 대한 클라우드 간 이동이 발생하지 않습니다.

BigQuery Omni는 표준 AWS IAM 역할 또는 Azure Active Directory 원칙을 사용하여 구독 데이터에 액세스합니다. BigQuery Omni에 읽기 또는 쓰기 액세스를 위임하고 언제든지 액세스 권한을 취소할 수 있습니다.

데이터를 쿼리할 때의 데이터 흐름

다음 이미지는 다음 쿼리에 대해 Google Cloud와 AWS 또는 Azure 간에 데이터가 어떻게 이동하는지 설명합니다.

  • SELECT
  • CREATE EXTERNAL TABLE
.
Google Cloud와 AWS 또는 Azure 사이의 쿼리용 데이터 이동
그림 1: Google Cloud와 AWS 또는 Azure 사이의 쿼리용 데이터 이동
  1. BigQuery 제어 영역은 Google Cloud 콘솔, bq 명령줄 도구, API 메서드, 클라이언트 라이브러리를 통해 쿼리 작업을 수신합니다.
  2. BigQuery 제어 영역이 처리를 위해 쿼리 작업을 AWS 또는 Azure의 BigQuery 데이터 영역으로 전송합니다.
  3. BigQuery 데이터 영역이 VPN 연결을 통해 제어 영역의 쿼리를 수신합니다.
  4. BigQuery 데이터 영역은 Amazon S3 버킷 또는 Blob Storage에서 테이블 데이터를 읽습니다.
  5. BigQuery 데이터 영역이 테이블 데이터에서 쿼리 작업을 실행합니다. 지정된 AWS 또는 Azure 리전에서 테이블 데이터 처리가 수행됩니다.
  6. 쿼리 결과는 VPN 연결을 통해 데이터 영역에서 제어 영역으로 전송됩니다.
  7. BigQuery 제어 영역은 쿼리 작업에 대한 응답으로 표시할 쿼리 작업 결과를 수신합니다. 이 데이터는 최대 24시간 동안 저장됩니다.
  8. 쿼리 결과가 반환됩니다.

자세한 내용은 Amazon S3 데이터Blob Storage 데이터 쿼리를 참조하세요.

데이터를 내보낼 때의 데이터 흐름

다음 이미지는 EXPORT DATA 문 중에 Google Cloud와 AWS 또는 Azure 간에 데이터가 어떻게 이동하는지 설명합니다.

Google Cloud와 AWS 또는 Azure 사이의 내보내기 쿼리용 데이터 이동
그림 2: Google Cloud와 AWS 또는 Azure 사이의 내보내기 쿼리용 데이터 이동.
  1. BigQuery 제어 영역은 Google Cloud 콘솔, bq 명령줄 도구, API 메서드, 클라이언트 라이브러리를 통해 내보내기 쿼리 작업을 수신합니다. 쿼리에는 Amazon S3 버킷 또는 Blob Storage의 쿼리 결과에 대한 대상 경로가 포함됩니다.
  2. BigQuery 제어 영역이 처리를 위해 내보내기 쿼리 작업을 AWS 또는 Azure의 BigQuery 데이터 영역으로 전송합니다.
  3. BigQuery 데이터 영역은 VPN 연결을 통해 제어 영역으로부터 내보내기 쿼리를 수신합니다.
  4. BigQuery 데이터 영역은 Amazon S3 버킷 또는 Blob Storage에서 테이블 데이터를 읽습니다.
  5. BigQuery 데이터 영역이 테이블 데이터에서 쿼리 작업을 실행합니다. 지정된 AWS 또는 Azure 리전에서 테이블 데이터 처리가 수행됩니다.
  6. BigQuery는 쿼리 결과를 Amazon S3 버킷 또는 Blob Storage에 지정된 대상 경로에 기록합니다.

자세한 내용은 Amazon S3Blob Storage로 쿼리 결과 내보내기를 참조하세요.

이점

성능. 데이터를 클라우드 간에 복사하지 않고 데이터가 있는 리전과 동일한 리전에서 쿼리가 실행되어 더욱 빠르게 유용한 정보를 얻을 수 있습니다.

비용. 데이터가 이동되지 않으므로 아웃바운드 데이터 전송 비용을 절약할 수 있습니다. Google에서 관리되는 클러스터에서 쿼리가 실행되기 때문에 BigQuery Omni 분석과 관련된 AWS 또는 Azure 계정에 추가 비용이 발생하지 않습니다. BigQuery 가격 책정 모델에 따라 쿼리 실행에 대해서만 비용이 청구됩니다.

보안 및 데이터 거버넌스. 자체 AWS 또는 Azure 구독으로 데이터를 관리합니다. 퍼블릭 클라우드 바깥으로 원시 데이터를 이동하거나 복사할 필요가 없습니다. 모든 계산은 데이터와 동일한 리전 내에서 실행되는 BigQuery 멀티 테넌트 서비스에서 발생합니다.

서버리스 아키텍처. 나머지 BigQuery와 마찬가지로 BigQuery Omni는 서버리스 제품입니다. Google은 BigQuery Omni를 실행하는 클러스터를 배포하고 관리합니다. 리소스를 프로비저닝하거나 클러스터를 관리할 필요가 없습니다.

관리 용이성. BigQuery Omni는 Google Cloud를 통해 통합된 관리 인터페이스를 제공합니다. BigQuery Omni는 기존 Google Cloud 계정 및 BigQuery 프로젝트를 사용할 수 있습니다. Google Cloud 콘솔에서 GoogleSQL 쿼리를 작성하여 AWS 또는 Azure에서 데이터를 쿼리하고 Google Cloud 콘솔에 표시된 결과를 확인할 수 있습니다.

교차 클라우드 전송. S3 버킷 및 Blob Storage에서 표준 BigQuery 테이블로 데이터를 로드할 수 있습니다. 자세한 내용은 Amazon S3 데이터Blob Storage 데이터를 BigQuery로 전송을 참조하세요.

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

캐시된 메타데이터를 사용하여 Amazon S3 데이터를 참조하는 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;

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

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

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

조인에 지원되는 BigQuery 리전에서 구체화된 뷰의 Amazon S3 데이터를 사용할 수 있도록 하려면 구체화된 뷰의 복제본을 만듭니다. 승인된 구체화된 뷰를 통해서만 구체화된 뷰 복제본을 만들 수 있습니다.

제한사항

BigLake 테이블 제한사항 외에도 Amazon S3 및 Blob Storage 데이터를 기반으로 하는 BigLake 테이블이 포함된 BigQuery Omni에는 다음 제한사항이 적용됩니다.

  • BigQuery Omni 리전에서의 데이터 작업은 Standard 및 Enterprise Plus 버전에서 지원되지 않습니다. 버전에 대한 자세한 내용은 BigQuery 버전 소개를 참조하세요.
  • Amazon S3 및 Blob Storage 데이터 기반의 BigLake 테이블에는 OBJECT_PRIVILEGES, STREAMING_TIMELINE_BY_*, TABLE_SNAPSHOTS, TABLE_STORAGE, PARTITIONS INFORMATION_SCHEMA를 사용할 수 없습니다.
  • Blob 스토리지에는 구체화된 뷰가 지원되지 않습니다.
  • JavaScript UDF는 지원되지 않습니다.
  • 다음 SQL 문이 지원되지 않습니다.

  • 대상 임시 테이블 쿼리 및 읽기에는 다음 제한사항이 적용됩니다(미리보기).

    • SELECT 문을 포함하는 대상 임시 테이블 쿼리는 지원되지 않습니다.
    • 대상 임시 테이블에서 데이터를 읽기 위한 BigQuery Storage Read API 사용은 지원되지 않습니다.
    • ODBC 드라이버를 사용할 때 높은 처리량 읽기(EnableHTAPI 옵션)는 지원되지 않습니다.
  • 예약된 쿼리는 API 또는 CLI 메서드를 통해서만 지원됩니다. 쿼리에는 대상 테이블 옵션이 사용 중지되어 있습니다. EXPORT DATA 쿼리만 허용됩니다.

  • BigQuery Storage APIBigQuery Omni 리전에서 사용할 수 없습니다.

  • 쿼리에서 ORDER BY 절을 사용하고 결과 크기가 256MB보다 크면 쿼리가 실패합니다. 이 문제를 해결하려면 결과 크기를 줄이거나 쿼리에서 ORDER BY 절을 삭제합니다. BigQuery Omni 할당량에 대한 자세한 내용은 할당량 및 한도를 참조하세요.

  • 데이터 세트 및 외부 테이블과 함께 고객 관리 암호화 키(CMEK)를 사용할 수 없습니다.

가격 책정

BigQuery Omni의 가격 책정 및 기간 한정 혜택에 대해서는 BigQuery Omni 가격 책정을 참조하세요.

할당량 및 한도

BigQuery Omni 할당량에 대한 자세한 내용은 할당량 및 한도를 참조하세요.

쿼리 결과가 20GiB보다 크면 결과를 Amazon S3 또는 Blob Storage로 내보내는 것이 좋습니다. BigQuery Connection API의 할당량에 대한 자세한 내용은 BigQuery Connection API를 참조하세요.

위치

BigQuery Omni는 쿼리 중인 테이블이 포함된 데이터 세트와 동일한 위치에 있는 쿼리를 처리합니다. 데이터 세트를 만든 후에는 이 위치를 변경할 수 없습니다. 데이터는 자체 AWS 또는 Azure 계정 내에 있습니다. BigQuery Omni 리전은 Enterprise 버전 예약과 주문형 컴퓨팅(분석) 가격 책정을 지원합니다. 버전에 대한 자세한 내용은 BigQuery 버전 소개를 참조하세요.
리전 설명 리전 이름 같은 위치에 배치된 BigQuery 리전
AWS
AWS - 미국 동부(북 버지니아) aws-us-east-1 us-east4
AWS 미국 서부(오리건) aws-us-west-2 us-west1
AWS - 아시아 태평양(서울) aws-ap-northeast-2 asia-northeast3
AWS - 유럽(아일랜드) aws-eu-west-1 europe-west1
Azure
Azure - 미국 동부 2 azure-eastus2 us-east4

다음 단계