Google은 AI 기술을 사용하여 콘텐츠를 사용자의 기본 언어로 번역합니다. AI 번역에는 오류가 있을 수 있습니다.

로드 작업 최적화

쓰기를 일괄 처리하고, 빈번한 업데이트를 스트리밍하고, 대상 테이블을 파티셔닝하여 BigQuery의 테이블당 로드 작업 한도를 초과하지 않도록 할 수 있습니다. 일일 수정 할당량은 고정되어 있으며 늘릴 수 없으므로 기본 제공 클라이언트 재시도를 사용하여 더 적은 수의 더 큰 쓰기를 사용하면 quotaExceeded 오류를 방지할 수 있습니다.

테이블 작업 할당량 작동 방식

프로젝트당 하루에 테이블당 테이블 수정에 대한 BigQuery 한도는 수정이 데이터를 추가 또는 업데이트하는지 또는 테이블을 자르는지 여부에 관계없이 고정됩니다. 이 한도에는 대상 테이블에 추가하거나 덮어쓰는 모든 로드 작업, 복사 작업, 쿼리 작업의 합계가 포함됩니다.

로드 작업에는 보충 비율이 있습니다. 테이블 작업 한도 또는 리필 속도를 초과하면 로드 작업이 quotaExceeded 오류와 함께 실패합니다. 일일 로드 작업의 프로젝트 수준 한도는 24시간 동안 균등하게 보충됩니다. 로드 작업이 완료되면 사용 가능한 할당량이 줄어듭니다. 그런 다음 할당량은 다음 24시간 동안 점진적으로 다시 채워집니다. 실패한 로드 작업도 테이블별 및 프로젝트별 할당량에 반영됩니다. 로드 작업 한도에 대한 자세한 내용은 로드 작업을 참조하세요.

파티션을 나눈 테이블의 경우 표준 테이블 한도 대신 별도의 파티션을 나눈 테이블 수정 한도가 적용됩니다.

일일 테이블 작업 한도를 초과하지 않으려면 24시간 동안 작업을 분산하세요. 예를 들어 각각 60개의 작업이 있는 업데이트를 25회 수행하는 경우 58분마다 약 60개의 작업을 실행할 수 있습니다. 이 접근 방식은 일일 한도를 충족하는 데 도움이 됩니다. 테이블 업데이트를 모니터링하려면 BigQuery INFORMATION_SCHEMA 뷰를 참조하세요.

할당량에서 제외되는 테이블 작업

테이블 정보(메타데이터) 업데이트 및 DML 문 사용은 일일 테이블 수정 한도에 포함되지 않습니다. 이 제외는 표준 테이블과 파티션을 나눈 테이블 모두에 적용됩니다.

프로젝트에서 DML 문을 무제한으로 실행할 수 있습니다. 이전에는 DML 문이 일일 테이블 수정에 포함되었으며 한도에 도달해도 제한되지 않았지만 이제는 그렇지 않습니다.

스트리밍 삽입도 테이블을 수정하지만 자체 특정 할당량이 적용됩니다.

테이블 작업 한도를 피하기 위한 로드 전략

BigQuery의 일일 테이블 작업 한도를 초과하지 않으려면 다음 권장사항을 고려하세요.

작은 쓰기를 여러 번 수행하는 대신 큰 쓰기를 적게 수행합니다.
매일 최종 프로덕션 테이블에 대한 별도의 쓰기 작업을 최소화합니다.

이러한 권장사항을 사용하려면 데이터를 BigQuery로 일괄 처리하거나 스트리밍하세요. 로드 방법은 대량의 데이터를 실시간으로 로드해야 하는지 또는 실시간 로드가 중요하지 않은지에 따라 달라집니다. 다음 섹션에서는 각 방법에 사용할 수 있는 도구와 서비스를 포함하여 일괄 로드 및 데이터 스트리밍을 자세히 설명합니다.

일괄 로드

BigQuery의 프로젝트당 일일 로드 한도를 초과하지 않으려면 대량의 데이터를 일괄 처리하고 더 적은 수의 작업으로 BigQuery에 로드합니다. 다음 섹션에서는 데이터를 일괄 로드하는 데 사용할 수 있는 몇 가지 방법을 설명합니다.

각 작업에 더 많은 데이터 로드

새 정보가 제공될 때마다 BigQuery에 데이터를 전송하는 대신 하나의 대규모 작업을 사용하여 데이터를 수집하고 BigQuery에 로드합니다.

예를 들어 몇 행의 데이터마다 별도의 로드 작업을 실행하는 대신 파일(예: CSV 또는 JSON 파일)에 수천 행의 데이터가 누적될 때까지 기다린 후 하나의 로드 작업을 실행하여 모든 데이터를 테이블에 추가할 수 있습니다. 이 작업은 작업에 훨씬 더 많은 데이터가 포함되어 있더라도 하나의 테이블 작업으로 계산됩니다. 로드 작업에 와일드 카드를 사용하여 파일을 일괄 처리할 수 있습니다. 와일드 카드를 사용하면 디렉터리에서 파일 배치를 선택하여 단일 로드 작업에서 여러 파일을 로드할 수 있습니다.

다음 예시에서는 bq load 명령어 또는 SQL LOAD DATA 쿼리와 함께 와일드 카드를 사용하는 방법을 보여줍니다.

bq

다음 예시에서는 bq load 명령어를 사용하여 Cloud Storage에서 my_target_table이라는 BigQuery 테이블로 CSV 데이터를 로드하는 방법을 보여줍니다. 소스 파일 이름을 두 개 이상 선택하려면 명령어와 함께 와일드 카드를 사용합니다. AUTODETECT 플래그는 Cloud Storage의 소스 데이터에서 테이블 스키마를 자동으로 결정하며, 와일드 카드(*)를 지원하여 특정 이름 지정 패턴에 맞는 여러 파일을 BigQuery 테이블에 로드할 수 있습니다.

bq load \
  --source_format=CSV \
  --autodetect \
  --project_id=PROJECT_ID \
  DATASET_NAME.TABLE_NAME \
  "gs://BUCKET_NAME/OBJECT_PATH_WILDCARD"

다음을 바꿉니다.

PROJECT_ID: Google Cloud 프로젝트의 ID입니다.
DATASET_NAME: 데이터를 로드할 BigQuery 데이터 세트의 이름입니다.
TABLE_NAME: 데이터를 로드할 BigQuery 테이블의 이름입니다.
BUCKET_NAME: 소스 파일이 포함된 Cloud Storage 버킷의 이름입니다.
OBJECT_PATH_WILDCARD: Cloud Storage 버킷에 있는 CSV 파일의 경로입니다. 여러 파일을 일치시키려면 와일드 카드 (*)를 포함합니다. 예를 들어 gs://my-bucket/path/to/data/my_prefix_*.csv 문자열은 와일드 카드 문자 *를 사용하여 gs://my-bucket/path/to/data/에서 my_prefix_로 시작하고 .csv로 끝나는 모든 파일을 로드합니다.

자세한 내용은 다음을 참조하세요.

SQL

다음 예시에서는 SQL LOAD DATA 쿼리를 사용하여 Cloud Storage 버킷에서 BigQuery 테이블로 CSV 데이터를 로드하는 방법을 보여줍니다. 소스 파일 이름을 두 개 이상 선택하려면 명령어와 함께 와일드 카드를 사용합니다.

LOAD DATA INTO
DATASET_NAME.TABLE_NAME
FROM FILES (
  format = 'SOURCE_FORMAT',
  uris = ['gs://BUCKET_NAME/OBJECT_PATH_WILDCARD]
  );

다음을 바꿉니다.

DATASET_NAME: 데이터를 로드할 BigQuery 데이터 세트의 이름입니다.
TABLE_NAME: 데이터를 로드할 BigQuery 테이블의 이름입니다.
SOURCE_FORMAT는 소스 파일의 유형을 설정합니다(예: CSV 또는 JSON). 이 예시에서는 CSV을 사용합니다.
BUCKET_NAME: 소스 파일이 포함된 Cloud Storage 버킷의 이름입니다.
OBJECT_PATH_WILDCARD: Cloud Storage 버킷에 있는 CSV 파일의 경로입니다. 여러 파일을 일치시키려면 와일드 카드 (*)를 포함합니다. 예를 들어 gs://my-bucket/path/to/data/my_prefix_*.csv 문자열은 와일드 카드 문자 *를 사용하여 gs://my-bucket/path/to/data/에서 my_prefix_로 시작하고 .csv로 끝나는 모든 파일을 로드합니다.

자세한 내용은 GoogleSQL의 LOAD 문을 참조하세요.

BigQuery Storage Write API (gRPC)를 사용한 일괄 로드

BigQuery에 일괄 데이터를 로드하는 한 가지 옵션은 Google API 클라이언트 라이브러리를 사용하여 애플리케이션에서 직접 Storage Write API (gRPC)를 사용하는 것입니다.

Storage Write API (gRPC)는 테이블 한도 내에서 데이터 로드를 최적화합니다. 대용량 실시간 스트리밍의 경우 COMMITTED 스트림 대신 PENDING 스트림을 사용합니다. PENDING 스트림을 사용하면 API는 스트림을 커밋할 때까지 레코드를 일시적으로 저장합니다.

Storage Write API를 사용한 데이터 일괄 로드의 전체 예시는 Storage Write API를 사용한 데이터 일괄 로드를 참조하세요.

Dataflow를 사용한 일괄 로드

데이터 파이프라인을 사용하여 데이터를 BigQuery로 스트리밍, 변환, 작성하려면 Dataflow를 사용하면 됩니다. 만든 데이터 파이프라인은 Pub/Sub 또는 Apache Kafka와 같은 지원되는 소스에서 읽습니다. 고성능 데이터 스트리밍 및 정확히 한 번 시맨틱스에 Storage Write API(gRPC)를 사용하는 BigQueryIO 커넥터를 사용하여 Dataflow 파이프라인을 만들 수도 있습니다.

Dataflow를 사용하여 BigQuery에 데이터를 일괄 로드하는 방법에 대한 자세한 내용은 Dataflow에서 BigQuery로 쓰기를 참조하세요.

데이터 스트리밍

자주 업데이트되는 대량의 데이터를 로드하려면 데이터를 BigQuery로 스트리밍하는 것이 좋습니다. 데이터 스트리밍을 사용하면 새 데이터가 클라이언트 애플리케이션에서 BigQuery로 지속적으로 기록되므로 너무 많은 로드 작업을 실행하는 한도에 도달하지 않습니다. 다음 섹션에서는 데이터를 BigQuery로 스트리밍하는 여러 방법을 설명합니다.

Storage Write API(gRPC)를 사용한 데이터 스트리밍

Storage Write API (gRPC)를 사용하여 최소한의 지연 시간으로 레코드를 BigQuery로 실시간 스트리밍합니다. Storage Write API(gRPC)는 정확히 한 번 전송 시맨틱스, 스키마 업데이트 감지, 스트리밍 변경 데이터 캡처(CDC) 삽입/업데이트(upsert)와 같은 고급 기능을 제공하는 효율적인 스트리밍 프로토콜을 제공합니다. 또한 매월 최대 2TiB를 무료로 수집할 수 있습니다.

Storage Write API (gRPC) 사용에 대한 자세한 내용은 Storage Write API를 사용한 데이터 스트리밍을 참조하세요.

Dataflow를 사용하여 데이터 스트리밍

Dataflow를 사용하여 Pub/Sub 또는 Apache Kafka와 같은 지원되는 소스에서 읽는 데이터 파이프라인을 만듭니다. 그런 다음 이러한 파이프라인은 데이터를 변환하고 BigQuery에 대상으로 씁니다. Storage Write API(gRPC)를 사용하는 BigQueryIO 커넥터를 사용하여 Dataflow 파이프라인을 만들 수 있습니다.

Dataflow를 사용하여 BigQuery로 데이터를 스트리밍하는 방법은 Dataflow에서 BigQuery로 쓰기를 참조하세요.

로드할 테이블 관리 권장사항

BigQuery에 데이터를 일괄 로드하거나 스트리밍하는 것 외에도 다음과 같은 방법으로 테이블을 관리하여 데이터 수집에 최적화합니다.

파티션을 나눈 테이블 사용

테이블 파티셔닝은 BigQuery에서 대규모 테이블을 관리하는 데 유용한 기술이며, 특히 빈번한 데이터 로드 작업을 수행해야 하는 경우에 유용합니다. 날짜, 타임스탬프 또는 정수를 기준으로 테이블을 더 작고 관리하기 쉬운 세그먼트로 나누면 테이블 성능과 비용 효율성을 크게 향상시킬 수 있습니다.

데이터 로드를 위한 파티션 나누기의 주요 이점은 BigQuery의 일일 테이블 작업 할당량이 테이블 수준이 아닌 파티션 수준에서 적용된다는 것입니다. 파티션을 나눈 테이블의 경우 표준 테이블 한도를 대체하는 파티션 수정에 별도의 더 높은 한도가 적용됩니다. 파티션을 나눈 테이블의 한도는 할당량 한도에 도달하지 않고 하루에 실행할 수 있는 로드 작업 수를 크게 늘립니다.

일반적이고 매우 효과적인 전략은 일일 데이터를 일괄 로드하는 것입니다. 예를 들어 임시 스테이징 테이블에 2025-09-18의 모든 일일 데이터를 수집할 수 있습니다. 그런 다음 하루가 끝날 때 단일 작업을 실행하여 이 데이터를 기본 프로덕션 테이블의 이 날짜에 해당하는 특정 파티션에 로드합니다. BigQuery는 단일 파티션의 데이터와만 상호작용하므로 이 접근 방식을 사용하면 데이터를 잘 정리하고 로드 작업을 더 빠르고 저렴하게 수행할 수 있습니다.

크기가 계속 증가하는 대규모 테이블에는 파티션 나누기를 사용하는 것이 좋지만 파티션이 지속적으로 10GB보다 작으면 파티션 나누기를 사용하지 않는 것이 좋습니다. 자세한 내용은 파티셔닝을 사용하는 경우를 참조하세요.

시간 단위 및 정수 범위 파티션 나누기와 같이 사용 가능한 다양한 파티션 나누기 방법에 대한 자세한 내용은 파티션을 나눈 테이블 유형을 참조하세요.

기본 제공되는 지수 백오프, 자르기, 지터 활용

기본 제공되는 지수 백오프 및 재시도는 작업이 일시적으로 실패할 때 애플리케이션이 원활하게 복구되도록 도와주는 오류 처리 방법입니다. 이러한 실패에는 비율 제한 오류(rateLimitExceeded) 또는 일시적인 네트워크 문제(unavailable)가 포함될 수 있습니다.

안정적인 시스템에서는 클라이언트 측 큐에서 작업을 가져오는 작업자도 지수 백오프 및 재시도를 사용합니다. BigQuery를 호출할 때 이 작업을 수행하므로 두 가지 수준의 보호가 생성됩니다.

예를 들어 Python용 공식 google-cloud-bigquery-storage 라이브러리에는 지수 백오프를 사용하는 기본 제공 재시도 로직이 포함되어 있습니다. 이 로직은 일시적인 gRPC 오류(예: UNAVAILABLE)를 처리합니다. 대부분의 경우 이 재시도 코드를 직접 작성할 필요가 없습니다. client.append_rows() 호출은 이러한 재시도를 자동으로 처리합니다.

이러한 기본 제공 처리는 공식 클라이언트 라이브러리를 사용할 때의 중요한 이점입니다. 스키마 불일치를 의미하는 INVALID_ARGUMENT와 같이 재시도할 수 없는 오류만 처리하면 됩니다.