Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

로드 작업 최적화

이 문서에 설명된 전략과 권장사항은 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: 프로젝트의 ID입니다. Google Cloud
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의 로드 문을 참조하세요.

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

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