BigQuery 스토리지 개요

이 페이지에서는 BigQuery의 스토리지 구성요소를 설명합니다.

BigQuery 스토리지는 대규모 데이터 세트에 대한 분석 쿼리를 실행하는 데 최적화되어 있습니다. 처리량이 높은 스트리밍 수집과 처리량이 높은 읽기도 지원합니다. BigQuery 스토리지를 이해하면 워크로드를 최적화하는 데 도움이 될 수 있습니다.

개요

BigQuery 아키텍처의 주요 특징 중 하나는 스토리지와 컴퓨팅의 분리입니다. 따라서 BigQuery는 필요에 따라 스토리지와 컴퓨팅을 모두 독립적으로 확장할 수 있습니다.

쿼리를 실행하면 쿼리 엔진이 여러 작업자에 작업을 동시에 분산하여 스토리지의 관련 테이블을 스캔하고 쿼리를 처리한 후 결과를 수집합니다. BigQuery는 페타비트 네트워크를 사용해 데이터가 워커 노드로 매우 빠르게 이동하도록 메모리에서 쿼리를 완전히 실행합니다.

BigQuery 스토리지의 몇 가지 주요 기능은 다음과 같습니다.

관리형. BigQuery 스토리지는 완전 관리형 서비스입니다. 스토리지 리소스를 프로비저닝하거나 스토리지 단위를 예약할 필요가 없습니다. BigQuery는 시스템에 데이터를 로드할 때 자동으로 스토리지를 할당합니다. 사용한 스토리지 용량에 대해서만 비용을 지불하면 됩니다. BigQuery 가격 책정 모델은 컴퓨팅과 스토리지 요금을 별도로 청구합니다. 자세한 가격 정보는 BigQuery 가격 책정을 참조하세요.
내구성. BigQuery 스토리지는 연간 내구성 99.999999999%(9 11개)를 위해 설계되었습니다. BigQuery는 여러 가용성 영역에 걸쳐 데이터를 복제하여 머신 수준 장애 또는 영역 장애로 인한 데이터 손실을 방지합니다. 자세한 내용은 안정성: 재해 복구 계획하기을 참조하세요.
암호화됨. BigQuery는 디스크에 기록하기 전에 모든 데이터를 자동으로 암호화합니다. 자체 암호화 키를 제공하거나 Google이 암호화 키를 관리하도록 할 수 있습니다. 자세한 내용은 저장 데이터 암호화를 참조하세요.
효율적. BigQuery 스토리지는 분석 워크로드에 최적화된 효율적인 인코딩 형식을 사용합니다. BigQuery의 스토리지 형식에 대한 자세한 내용은 블로그 게시물인 BigQuery의 차세대 열 형식 저장소 형식인 Capacitor 알아보기를 참조하세요.

테이블 데이터

BigQuery에 저장되는 데이터 대부분은 테이블 데이터입니다. 테이블 데이터에는 표준 테이블, 테이블 클론, 테이블 스냅샷, 구체화된 뷰가 포함됩니다. 이러한 리소스에 대해 사용한 스토리지 요금이 청구됩니다. 자세한 내용은 스토리지 가격 책정을 참조하세요.

표준 테이블에는 구조화된 데이터가 포함됩니다. 모든 테이블에는 스키마가 있으며 스키마의 모든 열에는 데이터 유형이 있습니다. BigQuery는 데이터를 열 형식으로 저장합니다. 이 문서의 스토리지 레이아웃을 참조하세요.
테이블 클론은 표준 테이블의 쓰기 가능한 가벼운 사본입니다. BigQuery는 테이블 클론과 기본 테이블 간의 델타만 저장합니다.
테이블 스냅샷은 테이블의 특정 시점 사본입니다. 테이블 스냅샷은 읽기 전용이지만 테이블 스냅샷에서 테이블을 복원할 수 있습니다. BigQuery는 테이블 스냅샷과 기본 테이블 간의 델타만 저장합니다.
구체화된 뷰는 뷰 쿼리 결과를 주기적으로 캐시하는 미리 계산된 뷰입니다. 캐시된 결과는 BigQuery 스토리지에 저장됩니다.

또한 캐시된 쿼리 결과는 임시 테이블로 저장됩니다. 임시 테이블에 저장된 캐시된 쿼리 결과는 비용이 청구되지 않습니다.

외부 테이블은 Cloud Storage와 같이 BigQuery 외부에 있는 데이터 저장소에 데이터가 있는 특수한 유형의 테이블입니다. 외부 테이블에는 표준 테이블과 마찬가지로 테이블 스키마가 있지만 테이블 정의는 외부 데이터 저장소를 가리킵니다. 이 경우 테이블 메타데이터만 BigQuery 스토리지에 유지됩니다. BigQuery는 외부 테이블 스토리지에 대한 요금을 부과하지 않지만 외부 데이터 저장소에는 스토리지 요금이 부과될 수 있습니다.

BigQuery는 테이블 및 기타 리소스를 데이터 세트라는 논리 컨테이너로 구성합니다. BigQuery 리소스를 그룹화하는 방법은 BigQuery 워크로드의 권한, 할당량, 결제, 기타 측면에 영향을 줍니다. 자세한 내용과 권장사항은 BigQuery 리소스 구성을 참조하세요.

테이블에 사용되는 데이터 보관 정책은 테이블이 포함된 데이터 세트의 구성에 따라 결정됩니다. 자세한 내용은 시간 이동 및 장애 안전을 위한 데이터 보관을 참조하세요.

메타데이터

BigQuery 스토리지에는 BigQuery 리소스에 대한 메타데이터도 저장됩니다. 메타데이터 스토리지에는 요금이 부과되지 않습니다.

BigQuery에서 테이블, 뷰 또는 사용자 정의 함수(UDF)와 같은 영구 항목을 만들면 BigQuery가 항목에 대한 메타데이터를 저장합니다. UDF 및 논리 뷰와 같은 테이블 데이터가 포함되지 않은 리소스에도 마찬가지입니다.

메타데이터에는 테이블 스키마, 파티션 나누기 및 클러스터링 사양, 테이블 만료 시간, 기타 정보가 포함됩니다. 이 유형의 메타데이터는 사용자에게 표시되며 리소스를 만들 때 구성할 수 있습니다. 또한 BigQuery는 쿼리를 최적화하기 위해 내부적으로 사용되는 메타데이터를 저장합니다. 이 메타데이터는 사용자에게 직접 표시되지 않습니다.

스토리지 레이아웃

기존의 많은 데이터베이스 시스템은 데이터를 행 기반 형식으로 저장합니다. 즉, 행이 함께 저장되며 각 행의 필드가 디스크에 순차적으로 표시됩니다. 행 기반 데이터베이스는 개별 레코드를 효율적으로 조회할 수 있습니다. 하지만 레코드에 액세스할 때 시스템이 모든 필드를 읽어야 하므로 여러 레코드에서 분석 함수를 수행하는 것이 효율적이지 않을 수 있습니다.

BigQuery는 테이블 데이터를 열 형식으로 저장합니다. 즉, 각 열을 개별적으로 저장합니다. 열 기반 데이터베이스는 전체 데이터 세트에서 개별 열을 스캔하는 데 특히 효율적입니다.

열 기반 데이터베이스는 수많은 레코드에 데이터를 집계하는 분석 워크로드에 최적화되어 있습니다. 분석 쿼리는 테이블에서 몇 개의 열만 읽으면 되는 경우가 많습니다. 예를 들어 수백만 개의 행에 대한 열의 합계를 계산하려는 경우 BigQuery는 모든 행의 모든 필드를 읽지 않고 해당 열 데이터를 읽을 수 있습니다.

열 기반 데이터베이스의 또 다른 이점은 열 내의 데이터가 일반적으로 행의 데이터보다 중복성이 더 높다는 점입니다. 이 특성은 실행 길이 인코딩과 같은 기술을 사용하여 읽기 성능을 향상시킬 수 있으므로 더 큰 데이터 압축을 가능하게 합니다.

스토리지 청구 모델

BigQuery 데이터 스토리지 요금은 논리적 또는 물리적(압축) 바이트 또는 이 둘의 조합으로 청구될 수 있습니다. 선택한 스토리지 청구 모델에 따라 스토리지 가격이 결정됩니다. 선택한 스토리지 청구 모델은 BigQuery 성능에 영향을 미치지 않습니다. 어떤 청구 모델을 선택하든 데이터는 물리적 바이트로 저장됩니다.

데이터 세트 수준에서 스토리지 청구 모델을 설정합니다. 데이터 세트를 만들 때 스토리지 청구 모델을 지정하지 않으면 기본적으로 논리적 스토리지 청구가 사용됩니다. 하지만 데이터 세트를 만든 후에 데이터 세트의 스토리지 청구 모델을 변경할 수 있습니다. 데이터 세트의 스토리지 청구 모델을 변경한 경우 스토리지 청구 모델을 다시 변경할 수 있으려면 14일을 기다려야 합니다.

데이터 세트의 청구 모델을 변경하면 변경사항이 적용되는 데 24시간 정도 걸립니다. 데이터 세트의 청구 모델을 변경하는 경우 장기 스토리지의 테이블 또는 테이블 파티션은 활성 스토리지로 재설정되지 않습니다. 쿼리 성능 및 쿼리 지연 시간은 데이터 세트의 청구 모델을 변경해도 영향을 받지 않습니다.

데이터 세트는 데이터 보관에 시간 이동 및 장애 안전 스토리지를 사용합니다. 시간 이동 및 장애 안전 스토리지는 물리적 스토리지 청구를 사용할 때 활성 스토리지 요금이 별도로 청구되지만 논리적 스토리지 청구를 사용할 경우 청구되는 기본 요율에 포함됩니다. 물리적 스토리지 비용과 데이터 보관의 균형을 맞추기 위해 데이터 세트에 사용되는 시간 이동 기간을 수정할 수 있습니다. 장애 안전 기간은 수정할 수 없습니다. 데이터 세트 데이터 보관에 대한 자세한 내용은 시간 이동 및 장애 안전을 통해 데이터 보관을 참조하세요. 스토리지 비용 예측에 대한 자세한 내용은 스토리지 청구 예측을 참조하세요.

조직에 데이터 세트와 동일한 리전에 있는 기존 레거시 정액제 슬롯 약정이 있으면 물리적 스토리지 청구에 데이터 세트를 등록할 수 없습니다. 이는 BigQuery 버전으로 구입한 약정에 적용되지 않습니다.

스토리지 최적화

BigQuery 스토리지를 최적화하면 쿼리 성능을 높이고 비용을 관리할 수 있습니다. 테이블 스토리지 메타데이터를 보려면 다음 INFORMATION_SCHEMA 뷰를 쿼리합니다.

스토리지 최적화에 대한 자세한 내용은 BigQuery에서 스토리지 최적화를 참조하세요.

데이터 로드

BigQuery로 데이터를 수집하기 위한 몇 가지 기본 패턴이 있습니다.

일괄 로드: 단일 일괄 작업으로 소스 데이터를 BigQuery 테이블에 로드합니다. 이 작업은 일회성 작업일 수 있으며 일정에 따라 발생하도록 자동화할 수 있습니다. 일괄 로드 작업에서 새 테이블을 만들거나 기존 테이블에 데이터를 추가할 수 있습니다.
스트리밍: 소규모의 데이터 배치를 지속적으로 스트리밍하므로 데이터를 거의 실시간으로 쿼리할 수 있습니다.
생성된 데이터: SQL 문을 사용하여 기존 테이블에 행을 삽입하거나 쿼리 결과를 테이블에 씁니다.

이러한 각 수집 방법을 선택해야 하는 경우에 대한 자세한 내용은 데이터 로드 소개를 참조하세요. 자세한 내용은 데이터 수집 가격 책정을 참조하세요.

BigQuery 스토리지에서 데이터 읽기

대부분의 경우 데이터에 대한 분석 쿼리를 실행하기 위해 BigQuery에 데이터를 저장합니다. 하지만 테이블에서 직접 레코드를 읽으려는 경우가 있습니다. BigQuery는 테이블 데이터를 읽는 몇 가지 방법을 제공합니다.

BigQuery API: tabledata.list 메서드를 사용하여 동기식 페이지로 나눈 액세스. 직렬 방식으로 호출당 1페이지씩 데이터를 읽습니다. 자세한 내용은 테이블 데이터 찾아보기를 참조하세요.
BigQuery Storage API: 서버 측 열 프로젝션 및 필터링을 지원하는 처리량이 높은 스트리밍 액세스. 읽기를 분리된 스트림 여러 개로 분할하여 여러 리더에 병렬화할 수 있습니다.
내보내기: 추출 작업이나 EXPORT DATA 문을 사용하여 Google Cloud Storage로 비동기 고처리량 복사. Cloud Storage에서 데이터를 복사해야 하는 경우 추출 작업이나 EXPORT DATA 문을 사용하여 데이터를 내보냅니다.
복사: BigQuery 내에서 데이터 세트 비동기 복사. 복사는 소스 및 대상 위치가 동일할 때 논리적으로 수행됩니다.

가격 정보는 데이터 추출 가격 책정을 참조하세요.

애플리케이션 요구사항에 따라 테이블 데이터를 읽을 수 있습니다.

읽기 및 복사: Cloud Storage에 저장 데이터 사본이 필요하면 추출 작업이나 EXPORT DATA 문을 사용하여 데이터를 내보냅니다. 데이터를 읽기만 하려면 BigQuery Storage API를 사용합니다. BigQuery 내에서 사본을 만들려면 복사 작업을 사용하세요.
확장: BigQuery API는 가장 효율적인 메서드이며 대량 읽기에 사용해서는 안 됩니다. 하루에 50TB를 초과하는 데이터를 내보내야 하는 경우 EXPORT DATA 문이나 BigQuery Storage API를 사용합니다.
첫 번째 행 반환 시간: BigQuery API는 첫 번째 행을 반환하는 가장 빠른 메서드이지만 소량의 데이터를 읽는 데만 사용되어야 합니다. BigQuery Storage API는 첫 번째 행을 반환하는 속도가 더 느리지만 처리량이 훨씬 많습니다. 내보내기 및 사본은 모든 행을 읽기 전에 완료되어야 하므로 이러한 작업 유형의 첫 번째 행의 시간은 몇 분 정도 걸릴 수 있습니다.

삭제

테이블을 삭제하면 데이터가 적어도 시간 이동 기간 동안 유지됩니다. 이후 Google Cloud 삭제 타임라인 내에 있는 디스크에서 데이터가 삭제됩니다. DROP COLUMN 문과 같은 일부 삭제 작업은 메타데이터 전용 작업입니다. 이 경우 다음에 영향을 받은 행을 수정하면 스토리지가 확보됩니다. 테이블을 수정하지 않으면 스토리지 확보가 보장되는 시간이 없습니다. 자세한 내용은 Google Cloud에서 데이터 삭제를 참조하세요.

다음 단계

테이블 작업 알아보기
스토리지 최적화 방법 알아보기
BigQuery에서 데이터를 쿼리하는 방법 알아보기
데이터 보안 및 거버넌스에 대해 알아보기