이 페이지는 Cloud Translation API를 통해 번역되었습니다.

로드 작업 최적화

이 문서에 설명된 전략과 권장사항은 BigQuery로의 일괄 로드 또는 스트리밍 데이터 로드를 최적화하여 테이블별, 일별 로드 작업 수 제한에 도달하지 않도록 하는 데 도움이 됩니다.

로드 작업의 한도는 고정되어 있으며 늘릴 수 없으므로 테이블 파티션과 같은 방법을 통해 테이블을 구조화하거나 일괄 로드 또는 스트리밍과 같은 방법을 통해 로드를 관리하여 로드 작업을 최적화해야 합니다.

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

수정사항이 데이터를 추가하거나 업데이트하는지, 테이블을 자르는지에 관계없이 프로젝트당 테이블당 하루에 허용되는 테이블 수정사항의 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

다음 예에서는 Cloud Storage에서 my_target_table라는 BigQuery 테이블로 CSV 데이터를 로드하는 bq load 명령어를 보여줍니다. 소스 파일 이름을 두 개 이상 선택하려면 명령어와 함께 와일드 카드를 사용합니다. 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 문자열은 와일드 카드 문자 *을 사용하여 my_prefix_로 시작하고 .csv로 끝나는 gs://my-bucket/path/to/data/의 모든 파일을 로드합니다.

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

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 문자열은 와일드 카드 문자 *을 사용하여 my_prefix_로 시작하고 .csv로 끝나는 gs://my-bucket/path/to/data/의 모든 파일을 로드합니다.

자세한 내용은 GoogleSQL의 로드 문을 참고하세요.

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

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

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

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

Dataflow를 사용한 일괄 로드

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

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

데이터 스트리밍

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

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

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

Storage Write API 사용에 관한 자세한 내용은 Storage Write API를 사용하여 데이터 스트리밍하기를 참고하세요.

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

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

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

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

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

파티션을 나눈 테이블 사용

테이블 파티션 나누기는 특히 데이터 로드 작업을 자주 실행해야 하는 경우 BigQuery에서 대규모 테이블을 관리하는 강력한 기법입니다. 날짜, 타임스탬프 또는 정수를 기준으로 테이블을 더 작고 관리하기 쉬운 세그먼트로 나누면 테이블 성능과 비용 효율성을 크게 개선할 수 있습니다.

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

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

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

시간 단위 및 정수 범위 파티션과 같은 다양한 파티션 방법 자세히 알아보려면 파티션을 나눈 테이블 유형을 참고하세요.

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

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

신뢰할 수 있는 시스템에서 클라이언트 측 큐에서 작업을 가져오는 작업자도 지수 백오프를 사용하고 재시도합니다. 이렇게 하면 BigQuery를 호출할 때 두 가지 수준의 보호가 생성됩니다.

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

이 내장 처리는 공식 클라이언트 라이브러리를 사용할 때 얻을 수 있는 중요한 이점입니다. 재시도할 수 없는 오류만 처리하면 됩니다. 예를 들어 스키마 불일치가 있음을 의미하는 INVALID_ARGUMENT가 있습니다.