Storage Write API를 사용해 데이터를 BigQuery로 스트리밍하기

* 본 아티클의 원문은 2022년 2월 19일 Google Cloud 블로그(영문)에 게재되었습니다.

많은 고객이 즐겨 사용하는 BigQuery는 높은 확장성과 비용 효율성을 자랑하는 서버리스 데이터 웨어하우스입니다. Dataflow 역시 대규모 데이터 처리를 위해 수평 확장 및 수직 확장되는 서버리스 플랫폼입니다. 많은 사용자가 오늘날 기업에서 생성되는 방대한 데이터를 적시에 분석하기 위해 두 제품을 함께 사용하고 있습니다.  Google Cloud는 BigQuery와 Dataflow를 함께 사용하는 사용자가 만족스러운 경험을 하도록 보다 간편하게 사용, 확장, 최적화할 수 있는 새로운 통합을 선보이기 위해 계속 노력 중입니다.  예를 들어 최근 Google Cloud는 BigQueryIO 커넥터를 위한 자동 샤딩 지원을 출시했습니다. 이 기능은 스트리밍 파이프라인의 처리량을 평균 3배 증가시킵니다.

오늘 Dataflow 사용자에게 BigQuery 최고의 기능을 제공하는 또 다른 통합을 출시하게 되어 기쁩니다. 최근 BigQuery팀에서는 새로운 BigQuery Storage Write API를 정식 버전으로 출시했습니다. BigQuery Storage Write API는 BigQuery용 통합 데이터 수집 API입니다. Dataflow 사용자가 이 기능을 사용하면 스트리밍 수집 및 일괄 로드를 하나의 고성능 API로 결합할 수 있습니다. Storage Write API를 사용하면 기록될 때 쿼리에 사용할 수 있는 레코드를 BigQuery로 스트리밍하거나 많은 수의 레코드를 일괄 처리하고 단일 원자적 작업으로 커밋할 수 있습니다. 새 API는 이전 버전인 table.insertAll() API보다 많은 처리량을 제공하며 최대 2TB의 무료 월별 사용량 등으로 스트리밍 수집 비용을 크게 절감시켜 줍니다.

새로운 API는 자바 클라이언트 라이브러리, Python 클라이언트 라이브러리를 통해 사용하거나 gRPC를 지원하는 모든 언어로 사용할 수 있습니다.

이제 BigQueryIO 커넥터에 두 가지 메서드를 추가로 제공하여 Dataflow에서 Storage Write API를 지원합니다. BigQuery에 데이터를 삽입하는 1회만 실행되는 시맨틱스를 사용하는 메서드와 1회 이상 실행되는 시맨틱스를 사용하며 지연 시간이 짧고 보다 저렴한 메서드 중에서 선택할 수 있습니다.

1회만 실행되는 시맨틱스를 통한 BigQuery Storage Write API 사용

다음 섹션은 약간의 변경만으로 기존 자바 파이프라인을 업데이트하고 Storage Write API의 강력한 트랜잭션 시맨틱스를 활용하는 방법을 보여줍니다.

1. Write API(버전 2.36.0 이상 권장)를 지원하고 Dataflow에서 지원되는 Beam SDK 버전으로 파이프라인을 업데이트합니다.

2. 새로운 API를 사용하려면 BigQueryIO의 Write 변환을 만들 때 새 메서드인 STORAGE_WRITE_API를 설정합니다. 일반적으로 코드는 다음과 같이 표시됩니다.

3. 파이프라인에서 테이블을 만들어야 하는 경우(테이블이 존재하지 않고 생성 배치를 CREATE_IF_NEEDED로 지정한 경우) 테이블 스키마를 제공해야 합니다. 테이블 스키마는 백엔드를 호출하기 전에 API에서 데이터를 검증하여 효율적인 바이너리 프로토콜 버퍼 메시지로 변환하는 데에도 사용됩니다. 백엔드에 제출하기 전에 새 API에서 이 스키마를 사용해 데이터 검증을 수행합니다.

4. 마지막으로 스트리밍 파이프라인에서는 스트림 수 및 트리거 빈도라는 두 매개변수를 추가로 설정해야 합니다.

스트림 수는 BigQueryIO Write 변환의 동시 로드를 정의하며 파이프라인에서 사용될 Storage Write API의 스트림 수와 대략 일치합니다. withNumStorageWriteApiStreams 메서드를 통해 변환에서 명시적으로 설정하거나 BigQueryOptions 클래스에 정의된 대로 'numStorageWriteApiStreams' 옵션을 파이프라인에 제공하면 됩니다.

트리거 빈도는 BigQuery에서 쿼리하는 데이터가 표시되는 속도를 결정합니다. withTriggeringFrequency 메서드를 통해 명시적으로 설정하거나 'storageWriteApiTriggeringFrequencySec' 옵션을 설정하여 시간(초)을 지정하면 됩니다.

이 두 매개변수 조합은 Storage Write API를 호출하기 전에 BigqueryIO에서 만드는 행의 배치 크기에 영향을 줍니다. 빈도를 너무 높게 설정하면 배치 크기가 작아져 성능에 영향을 줄 수 있습니다.

프로덕션에서 실행하기 전에 대표적 볼륨으로 파이프라인을 테스트하고(모든 파이프라인에 권장) 앞서 언급한 두 매개변수에 대한 최적의 값을 찾는 것이 좋습니다.  먼저 시작에 도움이 될 몇 가지 지침을 알려드립니다. 단일 스트림에서 초당 1Mb 이상의 처리량을 처리할 수 있어야 합니다. 이 메서드에서 사용할 독점 스트림을 만드는 BigQuery 서비스 작업에는 많은 비용이 발생합니다. 사용 사례에 필요한 수량의 스트림만 사용하세요. 대부분의 파이프라인에서는 한 자릿수 초 단위의 트리거 빈도가 적절합니다.

앞으로 자동 샤딩을 통해 런타임에서 매개변수를 결정하고 조정할 수 있도록 지원할 계획입니다.

1회 이상 실행되는 시맨틱스를 통한 BigQuery Storage Write API 사용

대상 테이블의 잠재적 중복 레코드가 허용되는 사용 사례의 경우 STORAGE_WRITE_API 메서드의 사촌 격인 STORAGE_API_AT_LEAST_ONCE 메서드를 사용할 수 있습니다. 이 메서드는 BigQuery에 기록할 레코드를 셔플 스토리지(STORAGE_WRITE_API 메서드의 1회만 실행되는 시맨틱스를 제공할 때 필요)에 유지하지 않으므로 비용이 더 저렴하고 대부분의 파이프라인에서 지연 시간이 더 짧습니다.  사용도 더 간단합니다. 앞서 다룬 두 개의 추가 매개변수가 필요하지 않습니다.

상당수(수천 개)의 스트림이 필요한 대규모 파이프라인을 실행하기 전에 Storage Write API 할당량을 검토하세요. 이 할당량은 BigQuery 서비스에 열려 있는 gRPC 연결 수와 관련이 있습니다. BigQueryIO 구현에서 연결 수는 메서드에 따라 다릅니다. STORAGE_WRITE_API 메서드에서는 대략 스트림 수와 같습니다. STORAGE_API_AT_LEAST_ONCE 메서드의 경우에는 연결 수를 파이프라인의 최대 작업자 수까지 사용할 수 있습니다. 멀티 리전 BigQuery 위치('us' 및 'eu')에 위치한 테이블로 수집하기 위한 최대 연결 수는 리전별 위치에서보다 많습니다.

다음 단계

BigQuery Storage Write API와 이에 대한 Dataflow 지원이 Beam SDK 2.36.0(또는 이상)을 사용하는 모든 사용자에게 제공됩니다.