Databricks Iceberg 테이블 BigQuery 조회 방법과 Lakehouse 운영

기존 방식은 데이터 복사 파이프라인

Databricks에서 Apache Spark 작업을 돌리고 BigQuery로 동시 접속이 많은 분석을 처리하는 조직은 흔합니다. 지금까지는 두 환경 사이에서 데이터를 복사하는 복잡한 파이프라인을 만들어야 했어요. 원문은 이 방식이 저장 비용을 늘리고, 지연을 만들고, 보안 통제를 쪼갠다고 짚습니다.

이번 방식은 zero-copy 조회

Managed Iceberg 테이블은 네이티브 Delta 로그와 함께 Iceberg 호환 메타데이터를 자동으로 만들어요. Databricks로 Parquet 파일을 Google Cloud Storage(GCS)에 한 번만 저장하면, Lakehouse가 Iceberg 메타데이터를 직접 읽고 BigQuery의 vectorized engine을 GCS의 오픈 포맷 파일에 적용합니다. 변경분은 Lakehouse의 다음 메타데이터 갱신 주기에 보이고, 갱신은 최단 5분마다 가능해요.

연결 구조는 이렇습니다. Databricks Unity Catalog가 중앙 메타데이터 계층 역할을 하고, BigQuery 관리자는 federated connection으로 Lakehouse 런타임 카탈로그를 만듭니다. 쿼리를 실행하면 Lakehouse가 Unity Catalog에서 현재 테이블 상태를 받아 오고, credential vending으로 발급된 단기 토큰이 BigQuery에 GCS 임시 읽기 권한을 줍니다.

Amazon S3와 Azure Blob Storage에 있는 데이터도 같은 방식으로 연합 조회가 됩니다. 각 federated catalog는 데이터와 가까운 Google Cloud 위치에 두는 것이 좋다고 해요. 외부 클라우드 egress 비용은 여전히 발생하지만, Cross-Cloud Interconnect(AWS)와 Lakehouse caching(Preview)이 줄여 줄 수 있습니다.

권한과 거버넌스

접근 통제는 delegated access로 풉니다. 관리자가 BigQuery Cloud Resource Connection을 만들고, GCS 버킷의 IAM 권한을 다루는 서비스 계정에 묶어요. 사용자에게 Lakehouse 테이블 엔터티 접근을 주면 외부 Iceberg 테이블에도 row-level, column-level 보안과 dynamic data masking 같은 BigQuery 통제를 적용할 수 있고, 적재는 Databricks가 계속 맡습니다.

쿼리 성능을 지키는 파티션 설계

BigQuery는 Iceberg 메타데이터로 쿼리를 계획하고, 필요한 데이터 파일만 제자리에서 읽어요. Iceberg의 hidden partitioning 덕에 디렉터리 구조를 몰라도 타임스탬프 같은 논리 컬럼으로 필터링할 수 있습니다. 주의할 점이 두 가지 있어요.

• Databricks managed Iceberg 테이블은 partition transform을 지원하지 않아서, Databricks는 liquid clustering을 권장합니다
• 일반 WHERE 절에서 파티션 컬럼을 리터럴 값과 비교해야 pruning이 적용돼요

Iceberg manifest에는 컬럼 단위 통계 범위가 들어 있어서 BigQuery가 불필요한 파일을 건너뜁니다. 그래서 스캔 바이트와 온디맨드 슬롯 사용량이 줄어요.

운영 체크리스트

잦은 쓰기와 스트리밍 적재는 작은 Parquet 파일을 계속 만들어 내고, 이 파편화가 BigQuery의 읽기 효율을 떨어뜨립니다. 아래 순서로 점검해 보세요.

• Databricks에서 OPTIMIZE로 작은 파일을 256MB-512MB 블록으로 합치기. Databricks는 Liquid Clustering으로 이를 자동 관리하기도 해요
• Databricks API로 정기 compaction을 돌리고 Predictive Optimization 함께 쓰기
• VACUUM으로 활성 스냅샷 밖의 미참조 파일 정리하기. 기본 보존 기간(deletedFileRetentionDuration)은 7일이라 실행 중인 분석 작업이 파일 누락 오류를 만나지 않습니다
• VACUUM을 정기 작업으로 예약하거나 predictive optimization에 맡기기. Iceberg 읽기가 켜진 테이블은 오래된 Iceberg 메타데이터도 함께 정리돼요

자주 묻는 질문

BigQuery란 무엇인가요?

Google Cloud의 데이터 분석 서비스예요. 이 글에서는 Lakehouse를 통해 Databricks가 만든 Iceberg 테이블을 복사 없이 읽는 조회 엔진으로 등장합니다.

Databricks에서 만든 데이터를 BigQuery로 복사해야 하나요?

복사하지 않아도 됩니다. Databricks가 GCS에 저장한 Parquet 파일을 BigQuery가 Iceberg 메타데이터로 그대로 읽어요. 변경분은 Lakehouse의 다음 메타데이터 갱신 주기(최단 5분)에 반영됩니다.

Amazon S3나 Azure에 있는 데이터도 조회할 수 있나요?

가능합니다. 오픈 Apache Iceberg REST Catalog와 cross-cloud connection을 함께 쓰면 데이터를 옮기지 않고 조회해요. 다만 외부 클라우드 egress 비용은 계속 발생하고, Cross-Cloud Interconnect(AWS)와 Lakehouse caching이 이를 줄여 줍니다.

조회가 느려지면 무엇부터 확인하나요?

작은 파일이 쌓였는지 먼저 봅니다. Databricks에서 OPTIMIZE로 파일을 256MB-512MB 블록으로 합치고, WHERE 절에서 파티션 컬럼을 리터럴 값과 비교하는지 확인하세요. 미참조 파일은 VACUUM으로 정리합니다.