S3의 데이터를 옮기지 않고 BigQuery로 읽기: Cross-Cloud Lakehouse와 Iceberg REST Catalog

다른 팀의 로그는 늘 다른 클라우드에 있다

회사가 어느 정도 커지면 데이터가 한 클라우드에만 있는 경우는 드뭅니다. 우리도 그렇습니다. 분석은 BigQuery에서 하는데, 서비스팀 하나는 AWS에서 출발해 이벤트 로그를 S3에 쌓고 있습니다.

지금까지는 이렇게 처리했습니다. 매일 새벽 S3 버킷을 GCS로 복사하고, 그걸 BigQuery에 적재합니다.

단순하고 잘 돕니다. 대신 조용히 쌓이는 문제가 셋 있습니다.

복사본이 만드는 세 가지 비용

첫 번째는 당연히 이그레스 요금입니다. AWS 밖으로 데이터를 꺼낼 때마다 돈이 나갑니다. 로그는 매일 늘어나니 요금도 같이 늡니다.

두 번째는 신선도입니다. 하루 한 번 복사하면 BigQuery 쪽 데이터는 최대 하루 늦습니다. 원본 팀은 방금 고친 데이터가 왜 대시보드에 안 보이냐고 묻습니다.

세 번째가 가장 성가십니다. 스키마가 어긋납니다. 원본 팀이 컬럼 하나를 추가하거나 타입을 바꾸면, 우리 적재 작업이 깨지거나 더 나쁘게는 조용히 그 컬럼을 버립니다.

세 문제의 뿌리는 같습니다. 같은 데이터가 두 군데 있다는 것입니다.

BigLake가 Cross-Cloud Lakehouse가 되면서 바뀐 것

Next '26에서 BigLake라는 이름이 Cross-Cloud Lakehouse로 바뀌었습니다. 이름보다 중요한 건 중심에 Apache Iceberg REST Catalog를 놓았다는 점입니다.

Iceberg는 오브젝트 스토리지의 Parquet 파일 묶음을 '테이블'처럼 다루게 해주는 테이블 포맷입니다. 어떤 파일이 현재 테이블의 일부인지, 스키마가 무엇인지를 메타데이터로 관리합니다. REST Catalog는 그 메타데이터를 표준 HTTP API로 노출하는 방식입니다.

비유하자면 도서관 목록 카드를 표준 규격으로 통일한 것과 비슷합니다. 책(파일)이 어느 건물에 있든, 목록 규격만 맞으면 어떤 엔진이든 찾아 읽을 수 있습니다.

이 위에서 발표된 내용을 정리하면 이렇습니다.

• 교차 클라우드 접근: BigQuery가 AWS S3, Azure ADLS의 Iceberg 테이블을 복사 없이 조회합니다.
• 카탈로그 연합: AWS Glue, Databricks, Snowflake, SAP의 카탈로그와 복사 없이 메타데이터를 공유합니다.
• 교차 클라우드 캐싱: 다른 클라우드의 데이터를 처음 읽을 때 캐시해서, 반복 조회 시 이그레스 요금을 줄입니다.
• 관리형 Iceberg 스토리지: 테이블 관리를 자동화하고, 여러 테이블에 걸친 트랜잭션을 지원합니다.
• Spark용 Lightning Engine: 구글은 상용 대안 대비 최대 2배의 가격 대비 성능을 주장했습니다.

캐싱이 해결하는 것과 해결하지 못하는 것

처음 읽었을 때 가장 솔깃했던 건 캐싱이었습니다. 이그레스 문제가 사라지는 줄 알았거든요.

다시 읽어 보니 첫 번째 읽기에 대한 비용은 여전히 남습니다. 캐시는 같은 데이터를 반복해서 읽을 때 효과가 있습니다. 매일 새로 쌓이는 로그를 매일 한 번씩만 읽는 패턴이라면, 지금의 복사 방식과 이그레스 측면에서 큰 차이가 없을 수 있습니다.

반대로 지난 90일치를 여러 분석가가 반복해서 조회하는 패턴이라면 효과가 큽니다. 우리 워크로드가 어느 쪽인지부터 쿼리 로그로 확인해 봐야 했습니다.

신선도와 스키마 문제는 확실히 나아집니다. 원본 팀이 Iceberg 테이블에 쓰는 순간, 같은 메타데이터를 우리도 봅니다. 복사 지연도, 우리 쪽 적재 스크립트가 스키마를 잘못 해석할 여지도 없어집니다.

손으로 확인해 볼 수 있는 부분

교차 클라우드 기능은 발표 시점 기준으로 프리뷰 단계였습니다. 다만 GCS 위의 Iceberg 테이블은 이미 BigQuery에서 다룰 수 있어서, 포맷에 익숙해지는 건 지금 시작할 수 있습니다.

CREATE TABLE `my_project.lake.wiki_events`
(
  event_id STRING,
  doc_id STRING,
  event_type STRING,
  event_ts TIMESTAMP
)
CLUSTER BY doc_id
WITH CONNECTION `my_project.us.lake_conn`
OPTIONS (
  file_format = 'PARQUET',
  table_format = 'ICEBERG',
  storage_uri = 'gs://my-lake-bucket/wiki_events'
);

같은 테이블을 Spark에서 읽으려면 표준 Iceberg REST 카탈로그 설정을 씁니다. 엔드포인트와 인증 방식은 환경마다 다르니 문서를 따릅니다.

from pyspark.sql import SparkSession

spark = (
    SparkSession.builder
    .appName("iceberg-rest-read")
    .config("spark.sql.extensions",
            "org.apache.iceberg.spark.extensions.IcebergSparkSessionExtensions")
    .config("spark.sql.catalog.lake", "org.apache.iceberg.spark.SparkCatalog")
    .config("spark.sql.catalog.lake.type", "rest")
    .config("spark.sql.catalog.lake.uri", "https://<rest-catalog-endpoint>")
    .config("spark.sql.catalog.lake.warehouse", "gs://my-lake-bucket")
    .getOrCreate()
)

df = spark.table("lake.wiki_events").where("event_type = 'EDIT'")
df.groupBy("doc_id").count().show()

도입 전에 정해야 할 한 가지

기술보다 먼저 합의해야 할 게 있었습니다. 누가 이 테이블에 쓰는가입니다.

Iceberg는 여러 엔진이 같은 테이블을 읽고 쓸 수 있게 해줍니다. 바로 그 점 때문에, 쓰는 주체가 둘 이상이 되면 커밋 충돌과 책임 소재가 흐려집니다. 원본 팀의 Spark 잡과 우리 쪽 BigQuery 작업이 같은 테이블을 고치기 시작하면, 장애가 났을 때 누가 고칠지 애매해집니다.

그래서 원칙을 하나 정했습니다. 테이블마다 쓰는 쪽은 하나, 읽는 쪽은 여럿. 카탈로그 소유권도 쓰는 팀이 갖습니다.

멀티클라우드 데이터 통합은 오랫동안 "결국 복사하는 수밖에 없다"로 끝나던 주제였습니다. Iceberg가 표준으로 자리 잡으면서 처음으로 다른 답이 생겼습니다. 다만 그 답은 파이프라인을 없애는 대신, 팀 간 약속을 하나 더 요구합니다.