데이터 로드 소개

이 문서에서는 데이터를 BigQuery에 로드하는 방법을 간략히 설명합니다.

개요

여러 가지 방법으로 BigQuery에 데이터를 수집할 수 있습니다.

  • 데이터 레코드 모음을 일괄 로드합니다.
  • 개별 레코드 또는 레코드 일괄 작업을 스트리밍합니다.
  • 쿼리를 사용하여 새 데이터를 생성하고 결과를 테이블에 추가하거나 덮어씁니다.
  • 타사 애플리케이션이나 서비스를 사용합니다.

일괄 로드

일괄 로드를 사용하면 단일 일괄 작업에서 소스 데이터를 BigQuery 테이블에 로드합니다. 예를 들어 데이터 소스는 CSV 파일, 외부 데이터베이스 또는 로그 파일 집합일 수 있습니다. 기존의 추출, 변환, 로드(ETL) 작업이 이 카테고리에 속합니다.

BigQuery의 일괄 로드 옵션에는 다음이 포함됩니다.

  • 로드 작업 로드 작업을 만들어 Cloud Storage나 로컬 파일에서 데이터를 로드합니다. 레코드는 Avro, CSV, JSON, ORC 또는 Parquet 형식일 수 있습니다.
  • SQL. LOAD DATA SQL 문은 데이터를 파일 하나 이상에서 새 테이블이나 기존 테이블로 로드합니다. LOAD DATA 문을 사용하여 Avro, CSV, JSON, ORC 또는 Parquet 파일을 로드할 수 있습니다.
  • BigQuery Data Transfer Service. BigQuery Data Transfer Service를 사용하여 Google SaaS(Software as a Service) 앱이나 타사 애플리케이션 및 서비스에서 데이터 로드를 자동화합니다.
  • BigQuery Storage Write API Storage Write API를 사용하면 임의의 많은 수의 레코드를 일괄 처리하고 단일 원자 작업으로 커밋할 수 있습니다. 커밋 작업이 실패해도 작업을 안전하게 다시 시도할 수 있습니다. BigQuery 로드 작업과 달리 Storage Write API는 Cloud Storage와 같은 중간 스토리지에 데이터를 스테이징할 필요가 없습니다.
  • 기타 관리형 서비스. 다른 관리형 서비스를 사용하여 외부 데이터 저장소에서 데이터를 내보내고 BigQuery로 가져옵니다. 예를 들어 Firestore 내보내기에서 데이터를 로드할 수 있습니다.

일괄 로드 방법을 선택할 때 대부분의 파일 기반 패턴은 로드 작업 또는 LOAD DATA SQL 문을 사용하여 데이터를 일괄 로드해야 합니다. 다른 서비스는 일반적으로 BigQuery Data Transfer Service를 사용하거나 Google 서비스에서 데이터를 내보내야 합니다.

일괄 로드는 일회성 작업 또는 반복 일정으로 수행할 수 있습니다. 예를 들어 다음을 수행할 수 있습니다.

  • 일정에 따라 BigQuery Data Transfer Service 전송을 실행할 수 있습니다.
  • Cloud Composer와 같은 조정 서비스를 사용하여 로드 작업을 예약할 수 있습니다.
  • 크론 작업을 사용하여 일정에 따라 데이터를 로드할 수 있습니다.

스트리밍

스트리밍을 사용하면 실시간으로 더 작은 데이터 배치를 지속적으로 전송하므로 데이터가 도착할 때 데이터를 쿼리할 수 있습니다. BigQuery의 스트리밍 옵션은 다음과 같습니다.

  • Storage Write API. Storage Write API는 단 한 번의 전송 시맨틱스로 처리량이 높은 스트리밍 처리를 지원합니다.
  • Dataflow. Apache Beam SDK와 함께 Dataflow를 사용하여 BigQuery에 쓰는 스트리밍 파이프라인을 설정합니다. 자세한 내용은 Apache Beam 문서의 BigQuery I/O 커넥터 및 Pub/Sub에서 BigQuery로 스트리밍 튜토리얼을 참조하세요.
  • Datastream. Datastream은 BigQuery 변경 데이터 캡처 기능과 Storage Write API를 사용하여 운영 데이터베이스의 데이터 및 스키마 업데이트를 BigQuery로 직접 복제합니다. PostgreSQL용 Cloud SQL 데이터베이스에서 BigQuery로 복제하는 예시는 이 빠른 시작을 참조하세요.
  • SAP용 BigQuery 커넥터 SAP용 BigQuery Connector는 BigQuery에 직접 SAP 데이터를 거의 실시간으로 복제할 수 있게 해줍니다. 자세한 내용은 SAP용 BigQuery Connector 계획 가이드를 참조하세요.
  • Pub/Sub. Pub/Sub는 스트리밍 분석 및 데이터 통합 파이프라인을 조정하는 데 사용할 수 있는 메시지 서비스입니다. BigQuery 구독을 사용하여 기존 BigQuery 테이블에 직접 메시지를 쓸 수 있습니다.

생성된 데이터

SQL을 사용하여 데이터를 생성하고 BigQuery에 결과를 저장할 수 있습니다. 데이터 생성 옵션은 다음과 같습니다.

  • DML 문을 사용하여 기존 테이블에 일괄 삽입을 수행하거나 새 테이블에 쿼리 결과를 저장할 수 있습니다.

  • CREATE TABLE ... AS 문을 사용하여 쿼리 결과에서 새 테이블을 만듭니다.

  • 쿼리를 실행하고 결과를 테이블에 저장합니다. 결과를 기존 테이블에 추가하거나 새 테이블에 쓸 수 있습니다. 자세한 내용은 쿼리 결과 쓰기를 참조하세요.

타사 애플리케이션

일부 타사 애플리케이션과 서비스에서는 데이터를 BigQuery에 수집할 수 있는 커넥터를 제공합니다. 수집 파이프라인을 구성하고 관리하는 방법의 세부정보는 애플리케이션에 따라 다릅니다. 예를 들어 외부 소스의 데이터를 BigQuery 스토리지로 로드하려면 Informatica Data loader 또는 Fivetran Data Pipelines를 사용하면 됩니다. 자세한 내용은 타사 애플리케이션을 사용하여 데이터 로드를 참조하세요.

데이터 수집 방법 선택

다음은 데이터 수집 방법을 선택할 때 생각해야 할 몇 가지 고려사항입니다.

데이터 소스. 데이터 소스 또는 데이터 형식의 소스에 따라 일괄 로드와 스트리밍 중에 구현 및 유지 관리가 더 간편한 것이 무엇인지 결정할 수 있습니다. 다음 사항을 고려하세요.

  • BigQuery Data Transfer Service에서 데이터 소스를 지원하는 경우 데이터를 BigQuery로 직접 전송하는 것이 구현하기 가장 간단한 솔루션일 수 있습니다.

  • BigQuery Data Transfer Service에서 지원되지 않는 타사 소스의 데이터의 경우 데이터를 일괄 로드에서 지원하는 형식으로 변환하고 이 메서드를 대신 사용합니다.

  • 데이터가 Spark 또는 Hadoop에서 제공되는 경우 BigQuery 커넥터를 사용하여 데이터 수집을 단순화하는 것이 좋습니다.

  • 로컬 파일의 경우 특히 BigQuery에서 변환 또는 데이터 정리 단계를 요구하지 않고 파일 형식을 지원하는 경우 일괄 로드를 사용하는 것이 좋습니다.

  • 애플리케이션 이벤트 또는 로그 스트림과 같은 애플리케이션 데이터의 경우 일괄 로드를 구현하는 것보다 실시간으로 데이터를 스트리밍하는 것이 더 쉬울 수 있습니다.

지연 변경 데이터와 급변하는 데이터 비교. 데이터를 거의 실시간으로 수집하고 분석해야 하는 경우에는 데이터 스트리밍을 사용하는 것이 좋습니다. 스트리밍을 사용하면 각 레코드가 도착하자마자 데이터를 쿼리할 수 있습니다. DML 문을 사용하여 다수의 개별 행 업데이트 또는 삽입을 제출하지 마세요. 자주 업데이트되는 데이터의 경우 변경 로그를 스트리밍하고 뷰를 사용하여 최신 결과를 얻는 것이 더 나은 경우가 많습니다. 또 다른 옵션은 Cloud SQL을 온라인 트랜잭션 처리(OLTP) 데이터베이스로 사용하고 통합 쿼리를 사용하여 BigQuery의 데이터에 조인하는 것입니다.

소스 데이터가 느리게 변경되거나 지속적으로 업데이트되는 결과가 필요하지 않으면 로드 작업을 사용하는 것이 좋습니다. 예를 들어 데이터를 사용하여 일일 또는 시간별 보고서를 실행하는 경우 로드 작업에 비용이 적게 들 수 있으며 시스템 리소스를 더 적게 사용할 수 있습니다.

또 다른 시나리오는 가끔 발생하거나 이벤트에 응답하는 데이터입니다. 이 경우 Dataflow를 사용하여 데이터를 스트리밍하거나 Cloud Functions를 사용하여 트리거에 대한 응답으로 스트리밍 API를 호출하는 것이 좋습니다.

솔루션 안전성. BigQuery에는 서비스수준계약(SLA)이 적용됩니다. 또한 구현하는 특정 솔루션의 안정성도 고려해야 합니다. 다음 사항을 고려하세요.

  • JSON 또는 CSV와 같이 느슨하게 유형이 지정된 형식을 사용하면 부적합 데이터로 인해 전체 로드 작업이 실패할 수 있습니다. 로드하기 전에 데이터 정리 단계가 필요한지 확인하고 오류에 어떻게 응답해야 하는지 고려하세요. 또한 Avro, ORC, Parquet와 같이 강력하게 유형이 지정된 형식을 사용하는 것이 좋습니다.
  • 정기적 로드 작업에는 Cloud Composer, 크론 또는 다른 도구를 사용하여 예약을 수행해야 합니다. 예약 구성요소는 솔루션의 장애 지점일 수 있습니다.
  • 스트리밍을 사용하면 각 레코드의 성공 여부를 확인하고 오류를 신속하게 보고할 수 있습니다. 나중에 분석하고 처리할 수 있도록 처리되지 않은 메시지 큐에 실패한 메시지를 작성하는 것이 좋습니다. BigQuery 스트리밍 오류에 대한 자세한 내용은 스트리밍 삽입 문제 해결을 참조하세요.
  • 스트리밍 및 로드 작업에는 할당량이 적용됩니다. 할당량 오류를 처리하는 방법에 대한 자세한 내용은 BigQuery 할당량 오류 문제 해결을 참조하세요.
  • 타사 솔루션은 구성 가능성, 안정성, 순서 보장, 기타 요소에 따라 다를 수 있으므로 이들을 고려한 후에 솔루션을 채택합니다.

지연 시간. 로드하는 데이터 양과 필요한 데이터가 얼마나 빨리 제공되는지 고려합니다. 스트리밍에서 분석에 사용 가능하면서 지연 시간이 가장 짧은 데이터를 제공합니다. 정기적 로드 작업에서는 각 로드 작업이 완료된 후에만 새 데이터를 사용할 수 있으므로 지연 시간이 더 깁니다.

로드 작업은 기본적으로 슬롯의 공유 풀을 사용합니다. 특히 매우 많은 데이터 양을 로드하는 경우 슬롯을 사용할 수 있을 때까지 로드 작업이 대기 중 상태일 수 있습니다. 허용되지 않는 대기 시간이 생성되면 공유 슬롯 풀을 사용하는 대신 전용 슬롯을 구매할 수 있습니다. 자세한 내용은 예약 소개를 참조하세요.

외부 데이터 소스의 쿼리 성능은 BigQuery에 저장된 데이터의 쿼리 성능보다 낮을 수 있습니다. 쿼리 지연 시간 최소화가 중요한 경우에는 데이터를 BigQuery에 로드하는 것이 좋습니다.

데이터 수집 형식. 다음 요소를 기준으로 데이터 수집 형식을 선택합니다.

  • 스키마 지원. Avro, ORC, Parquet, Firestore 내보내기는 자체 설명적 형식입니다. BigQuery는 소스 데이터를 기준으로 테이블 스키마를 자동으로 만듭니다. JSON 및 CSV 데이터의 경우 명시적 스키마를 제공하거나 스키마 자동 감지를 사용할 수 있습니다.

  • 플랫 데이터 또는 중첩 및 반복 필드. Avro, CSV, JSON, ORC, Parquet는 모두 플랫 데이터를 지원합니다. Avro, JSON, ORC, Parquet, Firestore 내보내기는 중첩 및 반복 필드가 있는 데이터도 지원합니다. 중첩 및 반복 데이터는 계층구조 데이터를 표현할 때 유용합니다. 중첩 및 반복 필드는 데이터를 로드할 때 데이터 중복을 줄여줍니다.

  • 삽입된 줄바꿈. JSON 파일에서 데이터를 로드하는 경우 행은 줄바꿈으로 구분해야 합니다. BigQuery는 줄바꿈으로 구분된 JSON 파일에 한 줄당 하나의 레코드가 포함된 것으로 예상합니다.

  • 인코딩. BigQuery는 중첩 또는 반복 데이터, 그리고 플랫 데이터에서 모두 UTF-8 인코딩을 지원합니다. BigQuery는 CSV 파일에서만 플랫 데이터용 ISO-8859-1 인코딩을 지원합니다.

중첩되고 반복되는 데이터 로드

중첩되고 반복되는 필드에 데이터를 로드하는 데이터 형식은 다음과 같습니다.

  • Avro
  • JSON(줄바꿈으로 구분)
  • ORC
  • Parquet
  • Datastore 내보내기
  • Firestore 내보내기

데이터 로드 시 스키마의 중첩 및 반복 필드 지정에 대한 자세한 내용은 중첩 및 반복 필드 지정을 참조하세요.

다른 Google 서비스에서 데이터 로드

일부 Google 서비스는 예약된 쿼리, 내보내기, 전송을 사용하여 BigQuery로 데이터를 내보냅니다. BigQuery로 내보내기를 지원하는 서비스에 대한 자세한 내용은 Google 서비스에서 데이터 로드를 참조하세요.

다른 Google 서비스는 BigQuery Data Transfer Service에서 시작된 데이터 내보내기 도구를 지원합니다. BigQuery Data Transfer Service에서 시작된 내보내기를 지원하는 서비스에 대한 자세한 내용은 BigQuery Data Transfer Service를 참조하세요.

할당량

할당량에 대한 자세한 내용은 다음 섹션을 참조하세요.

데이터 로드의 대안

다음과 같은 상황에서는 쿼리를 실행하기 전에 데이터를 로드할 필요가 없습니다.

공개 데이터 세트
공개 데이터 세트는 BigQuery에 저장되고 일반 대중에 공유되는 데이터 세트입니다. 자세한 내용은 BigQuery 공개 데이터세트를 참조하세요.
공유 데이터세트
BigQuery에 저장된 데이터세트를 공유할 수 있습니다. 다른 사람이 데이터세트를 공유한 경우 데이터를 로드하지 않고도 해당 데이터세트를 쿼리할 수 있습니다.
외부 데이터 소스
BigQuery는 BigQuery 스토리지에 데이터를 로드하지 않고도 특정 형식의 외부 데이터에 대한 쿼리를 실행할 수 있습니다. 이 방법을 사용하면 다른 곳에 저장된 데이터를 이동하지 않고도 BigQuery의 분석 기능을 활용할 수 있습니다. 이 방법의 이점과 제한사항에 대한 자세한 내용은 외부 데이터 소스를 참조하세요.
파일 로깅
Cloud Logging은 BigQuery로 로그 파일을 내보내는 옵션을 제공합니다. 자세한 내용은 싱크 구성 및 관리를 참조하세요.

로드 작업 사용량 모니터링

다음 두 가지 방법으로 로드 작업 사용을 모니터링할 수 있습니다.

  • Cloud Monitoring 사용. 자세한 내용은 BigQuery 측정항목을 참조하세요. 구체적으로는 특정 테이블에 업로드된 데이터 양과 행 수를 모니터링할 수 있습니다. 로드 작업이 특정 테이블에 데이터를 업로드하는 경우 이는 로드 작업 업로드 데이터 사용량을 모니터링하는 프록시가 될 수 있습니다.

  • INFORMATION_SCHEMA.JOBS_BY_PROJECT 사용. INFORMATION_SCHEMA.JOBS_BY_PROJECT 뷰를 사용하여 테이블당 일일 로드 작업 수를 가져올 수 있습니다.

사용 사례

다음 예시에서는 사용 사례에 따라 사용하는 방법과 다른 데이터 분석 솔루션에서 사용하는 방법을 설명합니다.

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

엔드포인트 로그의 이벤트 데이터를 처리하는 파이프라인이 있다고 가정해 보겠습니다. 이벤트는 연속적으로 생성되며 최대한 빨리 BigQuery에서 쿼리할 수 있어야 합니다. 이 사용 사례에는 최신 데이터가 가장 중요하므로 BigQuery로 데이터를 수집하는 가장 좋은 방법은 Storage Write API입니다. 이러한 엔드포인트를 가볍게 만들기 위한 권장 아키텍처는 이 이벤트를 Pub/Sub로 전송하며, 이러한 이벤트는 여기서부터 BigQuery로 직접 스트리밍되는 스트리밍 Dataflow 파이프라인에서 소비됩니다.

이 아키텍처의 주요 안정성 문제는 BigQuery에 레코드를 삽입하지 못한 문제를 처리하는 방법입니다. 각 레코드가 중요하고 손실되지 않으면 데이터는 삽입되기 전에 버퍼링되어야 합니다. 위의 권장 아키텍처에서 Pub/Sub는 메시지 보관 기능을 갖춘 버퍼 역할을 수행할 수 있습니다. 잘린 지수 백오프로 BigQuery 스트리밍 삽입을 다시 시도하도록 Dataflow 파이프라인을 구성해야 합니다. 버퍼로써의 Pub/Sub의 용량이 소진되면(예: BigQuery를 장기간 사용할 수 없거나 네트워크 장애가 발생하는 경우) 클라이언트에서 데이터가 유지되어야 하며 클라이언트에는 BigQuery를 다시 사용할 수 있을 때 유지된 레코드를 다시 삽입하는 메커니즘이 필요합니다. 이러한 상황을 처리하는 방법에 대한 자세한 내용은 Google Pub/Sub 신뢰성 가이드 블로그 게시물을 참조하세요.

처리할 수 있는 또 다른 실패 사례는 악성 레코드입니다. 악성 레코드는 레코드를 재시도할 수 없는 오류와 함께 삽입하지 못했거나 최대 재시도 횟수 후에 성공적으로 삽입되지 않았기 때문에 BigQuery에서 거부된 레코드입니다. 두 가지 레코드 모두 추가 조사를 위해 Dataflow 파이프라인에 의해 '데드 레터 큐'에 저장해야 합니다.

정확히 한 번의 시맨틱스가 필요한 경우 클라이언트에서 제공된 레코드 오프셋과 함께 커밋된 유형으로 쓰기 스트림을 만듭니다. 이렇게 하면 오프셋 값이 다음 추가 오프셋과 일치하는 경우에만 쓰기 작업이 수행되므로 중복이 방지됩니다. 오프셋을 제공하지 않으면 레코드가 스트림의 현재 끝에 추가되고 실패한 추가 작업을 다시 시도하면 레코드가 스트림에 두 번 이상 표시될 수 있습니다.

정확한 1회 보장이 필요하지 않은 경우 기본 스트림에 작성하면 더 높은 처리량을 허용하고 쓰기 스트림을 만들 때 할당량 한도에 포함되지도 않습니다.

네트워크 처리량을 예측하고 처리량을 지원하기 위해 할당량이 적절한지 미리 확인합니다.

워크로드가 매우 균일하지 않은 속도로 데이터를 생성하거나 처리하는 경우 클라이언트의 부하 급증을 완화하고 일정한 처리량으로 BigQuery로 스트리밍합니다. 이렇게 하면 용량 계획을 단순화할 수 있습니다. 이 작업이 가능하지 않으면 처리량이 짧은 급증 동안 할당량을 초과하는 경우 429(리소스 소진됨) 오류를 처리할 준비가 되어 있어야 합니다.

일괄 데이터 처리

야간 일괄 처리 파이프라인이 고정 기한 내에 완료해야 한다고 가정해 보겠습니다. 규제 기관에 전송할 보고서를 생성하려면 다른 일괄 프로세스에서의 추가 처리를 위해 이 기한까지 데이터를 사용할 수 있어야 합니다. 이 사용 사례는 금융과 같은 규제 대상 업계에서 일반적입니다.

기한을 충족할 수 있다면 지연 시간이 문제가 되지 않으므로 로드 작업을 사용한 데이터 일괄 로드가 이 사용 사례에 적합한 접근 방법입니다. Cloud Storage 버킷이 BigQuery 데이터 세트로 데이터를 로드하는 데 필요한 위치 요구사항을 충족하는지 확인합니다.

BigQuery 로드 작업 결과는 원자적입니다. 모든 레코드가 삽입되거나 아무것도 삽입되지 않습니다. 모든 데이터를 단일 로드 작업에 삽입할 때 JobConfigurationLoad 리소스의 WRITE_TRUNCATE 처리를 사용하여 새 테이블을 만드는 것이 좋습니다. 이는 실패한 로드 작업을 재시도할 때 중요합니다. 작업이 실패한 것인지 아니면 성공 상태를 클라이언트에 다시 전달하는 데 실패했는지 클라이언트에서 구분하지 못할 수 있기 때문입니다.

수집될 데이터가 Cloud Storage에 이미 복사되었다고 가정하면 지수 백오프를 재시도해도 수집 실패를 해결하는 데 충분합니다.

야간 일괄 작업은 재시도까지 포함하여 기본 할당량(테이블당 일일 로드 1,500회)에 도달하지 않는 것이 좋습니다. 데이터를 증분식으로 로드하는 경우 기본 할당량은 5분마다 로드 작업을 실행하기에 충분하며 작업당 평균 최소 한 번 이상 재시도할 수 있는 소비하지 않은 할당량이 여전히 존재합니다.

다음 단계