BigQuery란, cross-cloud caching으로 멀티클라우드 쿼리 비용 줄이는 법

AS-IS: 멀티클라우드 데이터는 옮기거나 비싸게 조회하거나

기업 데이터는 한 곳에 모여 있지 않아요. Amazon S3, Azure Data Lake Storage, Google Cloud Storage, Salesforce나 SAP 같은 SaaS 플랫폼에 흩어져 있는 경우가 많습니다. 지금까지는 이걸 통합하려면 깨지기 쉬운 ETL 파이프라인을 짜거나 데이터를 중복 저장해야 했고, 클라우드 간 데이터 전송 비용도 만만치 않았어요. Google은 올해 초 borderless Lakehouse를 내놓으면서 Apache Iceberg REST 카탈로그 규격으로 Databricks Unity Catalog, AWS Glue, Snowflake Horizon 같은 카탈로그에 직접 연합 쿼리를 붙였고, Partner Cross-Cloud Interconnect로 공용 인터넷보다 싼 전용선도 마련했습니다.

이번 내용: 캐싱으로 전송량 자체를 줄인다

이번 발표의 핵심은 전송할 데이터량 자체를 줄이는 겁니다. cross-cloud caching은 Parquet 같은 컬럼형 포맷에서 파일 전체가 아니라 쿼리가 실제로 필요한 컬럼 청크와 딕셔너리 페이지만 sub-file 블록 단위로 캐싱해요. 캐시 미스가 나면 원격 클라우드에서 필요한 데이터만 가져와 로컬 사본을 저장해두고, 다음 쿼리부터는 그 캐시를 씁니다. 캐시된 블록은 기본적으로 Google 관리 암호화 키(GMEK)로 저장 시 암호화되고, 프로젝트와 카탈로그 경계로 엄격히 격리되며, 캐시와 쿼리 실행 모두 지정된 Google Cloud 리전(예: us-east4)에 고정돼 데이터 거주지 규정을 지킬 수 있어요. 원본 테이블이 바뀌면 BigQuery가 이를 감지해 새 파일을 가져오고, 참조되지 않는 캐시 블록은 자동 만료됩니다.

원문에 나온 사례를 보면, Amazon S3에 있는 10TiB짜리 Iceberg 판매 테이블(aws_lakehouse_catalog.sales.web_sales)을 Databricks Unity Catalog로 연합해 조회할 때, 첫 실행에서는 캐시가 비어 있는 상태(cacheBytesRead: 0)에서 파티션 프루닝과 컬럼 프로젝션으로 214.5GiB 중 실제로는 24.1GiB만 S3에서 읽었어요. Zstandard 압축 덕에 8.9대1 압축률이 나온 거고요. 이어서 배송 방법(shipping method) 차원을 추가한 후속 쿼리에서는 기존에 조회했던 컬럼 24.1GiB가 로컬 캐시에서 그대로 서빙되면서 94.8% 캐시 히트율을 기록했고, 새로 필요한 ws_ship_mode_sk 컬럼과 ship_mode 테이블 몫으로 S3에서 1.33GiB만 추가로 전송됐습니다.

실무 적용 포인트

원문이 제시한 TCO 계산식을 보면, 압축률 8대1을 가정하면 논리 데이터 1TiB당 네트워크로 옮겨야 할 물리 데이터는 약 128GiB로 줄고, 여기에 캐시 히트율 80%를 더하면 물리 데이터 100GiB 중 실제 네트워크 전송은 20GiB로 또 줄어듭니다. 두 요소를 함께 적용하면 조직이 처리하는 데이터 1TiB당 네트워크로 전송해야 하는 양은 약 26GiB, 즉 전체 처리량의 3% 미만이라고 합니다. Partner Cross-Cloud Interconnect와 결합하면 페타바이트 규모에서도 크로스클라우드 분석과 AI 활용의 TCO를 낮출 수 있다는 게 Google의 설명이에요.

실무에서 어느 기능을 쓸지는 데이터 형태로 갈립니다. Iceberg 카탈로그로 관리되는 데이터라면 Lakehouse catalog federation을 써서 스키마와 스냅샷을 자동 동기화하면 되고, 카탈로그 없는 CSV, JSON, ad-hoc Parquet 같은 원시 파일이라면 이번에 나온 BigQuery cross-cloud connections로 원격 버킷 경로를 바로 참조하는 외부 테이블을 만들면 됩니다. cross-cloud connections는 다른 클라우드의 컴퓨트 워커가 아니라 Google Cloud 리전의 표준 BigQuery 컴퓨트 워커를 쓰기 때문에 글로벌 리전 가용성과 BigQuery AI, Gemini를 포함한 기능 완전성을 그대로 누릴 수 있고, cross-cloud caching은 connections와 catalog federation 양쪽 모두에 적용됩니다.

자주 묻는 질문

bigquery 란

BigQuery는 Google Cloud가 제공하는 서버리스 데이터 웨어하우스로, 대용량 데이터를 SQL로 분석하는 도구입니다. 최근에는 Lakehouse 기능을 통해 Amazon S3, Azure Data Lake Storage 등 다른 클라우드에 있는 데이터도 이동 없이 직접 쿼리할 수 있도록 확장되고 있어요.

bigquery vs motherduck 비교

원문에는 MotherDuck과의 직접 비교는 나오지 않습니다. 원문 기준으로는 BigQuery의 이번 업데이트가 Amazon S3, Azure Data Lake Storage 등 여러 클라우드에 흩어진 Iceberg 데이터를 카탈로그 연합과 cross-cloud caching으로 직접 쿼리하는 데 초점이 맞춰져 있다는 점만 확인할 수 있어요.

cross-cloud caching은 어떻게 비용을 줄이나요

파일 전체가 아니라 쿼리가 필요로 하는 컬럼 청크만 sub-file 블록 단위로 Google Cloud 리전에 캐싱해서 원격 전송량을 줄이는 방식입니다. 원문 사례에서는 후속 쿼리의 94.8%가 캐시에서 처리돼 추가 전송량이 1.33GiB에 그쳤어요.

데이터를 BigQuery로 복제하지 않아도 되나요

네, cross-cloud caching과 catalog federation 모두 Amazon S3나 Azure Data Lake Storage에 있는 데이터를 BigQuery로 옮기지 않고 원본 위치에서 그대로 쿼리하는 방식입니다. 자주 조회되는 부분만 자동으로 로컬 캐시에 저장돼요.