BQ를 사용하여 Databricks에서 Spanner로 역방향 ETL

1. Google Cloud Storage 및 BigQuery를 사용하여 Databricks에서 Spanner로 역방향 ETL 파이프라인 빌드

소개

이 Codelab에서는 Databricks에서 Spanner로 역방향 ETL 파이프라인을 빌드합니다. 기존의 표준 ETL (추출, 변환, 로드) 파이프라인은 분석을 위해 운영 데이터베이스에서 Databricks와 같은 데이터 웨어하우스로 데이터를 이동합니다. 역방향 ETL 파이프라인은 선별되고 처리된 데이터를 데이터 웨어하우스에서 고가용성 애플리케이션에 적합한 전 세계 분산 관계형 데이터베이스인 Spanner와 같은 운영 데이터베이스로 다시 이동시켜 애플리케이션을 지원하거나, 사용자 대상 기능을 제공하거나, 실시간 의사 결정에 사용할 수 있도록 합니다.

목표는 집계된 데이터 세트를 Databricks Iceberg 테이블에서 Spanner 테이블로 이동하는 것입니다.

이를 위해 Google Cloud Storage (GCS)와 BigQuery가 중간 단계로 사용됩니다. 데이터 흐름과 이 아키텍처의 이유는 다음과 같습니다.

Databricks에서 Iceberg 형식으로 Google Cloud Storage (GCS)로:

첫 번째 단계는 Databricks에서 데이터를 개방적이고 잘 정의된 형식으로 가져오는 것입니다. 테이블이 Apache Iceberg 형식으로 내보내집니다. 이 프로세스는 기본 데이터를 Parquet 파일 집합으로, 테이블의 메타데이터 (스키마, 파티션, 파일 위치)를 JSON 및 Avro 파일로 작성합니다. 이 전체 테이블 구조를 GCS에 스테이징하면 Iceberg 형식을 이해하는 모든 시스템에서 데이터를 휴대하고 액세스할 수 있습니다.

GCS Iceberg 테이블을 BigQuery BigLake 외부 테이블로 변환:

GCS에서 Spanner로 직접 데이터를 로드하는 대신 BigQuery가 강력한 중개자로 사용됩니다. GCS의 Iceberg 메타데이터 파일을 직접 가리키는 BigLake 외부 테이블이 BigQuery에 생성됩니다. 이 방식의 장점은 다음과 같습니다.
데이터 중복 없음: BigQuery는 메타데이터에서 테이블 구조를 읽고 Parquet 데이터 파일을 수집하지 않고 제자리에서 쿼리하므로 상당한 시간과 스토리지 비용이 절약됩니다.
통합 쿼리: GCS 데이터가 네이티브 BigQuery 테이블인 것처럼 복잡한 SQL 쿼리를 실행할 수 있습니다.

BigLake 외부 테이블을 Spanner로 리버스 ETL:

마지막 단계는 BigQuery에서 Spanner로 데이터를 이동하는 것입니다. 이는 '역방향 ETL' 단계인 BigQuery의 강력한 기능인 EXPORT DATA 쿼리를 사용하여 달성됩니다.
운영 준비 상태: Spanner는 트랜잭션 워크로드를 위해 설계되어 애플리케이션에 강력한 일관성과 고가용성을 제공합니다. 데이터를 Spanner로 이동하면 지연 시간이 짧은 포인트 조회가 필요한 사용자 대상 애플리케이션, API, 기타 운영 시스템에서 데이터에 액세스할 수 있습니다.
확장성: 이 패턴을 사용하면 BigQuery의 분석 기능을 활용하여 대규모 데이터 세트를 처리한 다음 Spanner의 전역적으로 확장 가능한 인프라를 통해 결과를 효율적으로 제공할 수 있습니다.

서비스 및 용어

DataBricks - Apache Spark를 기반으로 구축된 클라우드 기반 데이터 플랫폼입니다.
Spanner - Google에서 완전 관리하는 전역 분산 관계형 데이터베이스입니다.
Google Cloud Storage - Google Cloud의 블롭 스토리지 제품입니다.
BigQuery - Google에서 완전 관리하는 분석용 서버리스 데이터 웨어하우스입니다.
Iceberg: 일반적인 오픈소스 데이터 파일 형식에 대한 추상화를 제공하는 Apache에 의해 정의된 개방형 테이블 형식입니다.
Parquet - Apache의 오픈소스 열 형식 바이너리 데이터 파일 형식입니다.

학습할 내용

Databricks에 데이터를 Iceberg 테이블로 로드하는 방법
GCS 버킷을 만드는 방법
Databricks 테이블을 Iceberg 형식으로 GCS에 내보내는 방법
GCS의 Iceberg 테이블에서 BigQuery의 BigLake 외부 테이블을 만드는 방법
Spanner 인스턴스를 설정하는 방법
BigQuery의 BigLake 외부 테이블을 Spanner에 로드하는 방법

2. 설정, 요구사항 및 제한사항

기본 요건

Databricks 계정(GCP에 있는 것이 좋음)
BigQuery에서 Spanner로 내보내려면 BigQuery Enterprise 등급 이상의 예약이 있는 Google Cloud 계정이 필요합니다.
웹브라우저를 통한 Google Cloud 콘솔 액세스
Google Cloud CLI 명령어를 실행하는 터미널

Google Cloud 조직에 `iam.allowedPolicyMemberDomains` 정책이 사용 설정되어 있는 경우 관리자가 외부 도메인의 서비스 계정을 허용하기 위해 예외를 부여해야 할 수 있습니다. 해당되는 경우 나중에 설명합니다.

요구사항

결제가 사용 설정된 Google Cloud 프로젝트.
웹브라우저(예: Chrome)
Databricks 계정 (이 실습에서는 GCP에서 호스팅되는 작업공간을 가정함)
데이터 내보내기 기능을 사용하려면 BigQuery 인스턴스가 Enterprise 버전 이상이어야 합니다.
Google Cloud 조직에 iam.allowedPolicyMemberDomains 정책이 사용 설정되어 있는 경우 관리자가 외부 도메인의 서비스 계정을 허용하기 위해 예외를 부여해야 할 수 있습니다. 해당되는 경우 나중에 설명합니다.

Google Cloud Platform IAM 권한

이 Codelab의 모든 단계를 실행하려면 Google 계정에 다음 권한이 있어야 합니다.

서비스 계정
`iam.serviceAccountKeys.create`	서비스 계정 생성을 허용합니다.
Spanner
`spanner.instances.create`	새 Spanner 인스턴스를 만들 수 있습니다.
`spanner.databases.create`	DDL 문을 실행하여
`spanner.databases.updateDdl`	데이터베이스에 테이블을 만들기 위해 DDL 문을 실행할 수 있습니다.
Google Cloud Storage
`storage.buckets.create`	내보낸 Parquet 파일을 저장할 새 GCS 버킷을 만들 수 있습니다.
`storage.objects.create`	내보낸 Parquet 파일을 GCS 버킷에 쓸 수 있습니다.
`storage.objects.get`	BigQuery가 GCS 버킷에서 Parquet 파일을 읽을 수 있도록 허용합니다.
`storage.objects.list`	BigQuery가 GCS 버킷의 Parquet 파일을 나열하도록 허용합니다.
Dataflow
`Dataflow.workitems.lease`	Dataflow에서 작업 항목을 요청할 수 있습니다.
`Dataflow.workitems.sendMessage`	Dataflow 작업자가 Dataflow 서비스에 메시지를 다시 전송할 수 있습니다.
`Logging.logEntries.create`	Dataflow 작업자가 Google Cloud Logging에 로그 항목을 쓸 수 있도록 허용합니다.

편의를 위해 이러한 권한이 포함된 사전 정의된 역할을 사용할 수 있습니다.

roles/resourcemanager.projectIamAdmin

roles/iam.serviceAccountKeyAdmin

roles/spanner.instanceAdmin

roles/spanner.databaseAdmin

roles/storage.admin

roles/dataflow.serviceAgent

roles/dataflow.worker

roles/dataflow.serviceAgent

Google Cloud 프로젝트

프로젝트는 Google Cloud의 기본 조직 단위입니다. 관리자가 사용할 수 있는 인증서를 제공한 경우 이 단계를 건너뛸 수 있습니다.

다음과 같이 CLI를 사용하여 프로젝트를 만들 수 있습니다.

gcloud projects create <your-project-name>

여기에서 프로젝트 만들기 및 관리에 대해 자세히 알아보세요.

제한사항

이 파이프라인에서 발생할 수 있는 특정 제한사항과 데이터 유형 비호환성을 알고 있어야 합니다.

Databricks Iceberg에서 BigQuery로

BigQuery를 사용하여 Databricks에서 관리하는 Iceberg 테이블 (UniForm을 통해)을 쿼리할 때는 다음 사항에 유의하세요.

스키마 변경: UniForm은 Delta Lake 스키마 변경사항을 Iceberg로 변환하는 데 유용하지만 복잡한 변경사항은 예상대로 전파되지 않을 수 있습니다. 예를 들어 Delta Lake에서 열 이름을 변경해도 Iceberg로 변환되지 않으며, Iceberg에서는 이를 drop 및 add로 간주합니다. 항상 스키마 변경사항을 철저히 테스트하세요.
시간 이동: BigQuery는 Delta Lake의 시간 이동 기능을 사용할 수 없습니다. Iceberg 테이블의 최신 스냅샷만 쿼리합니다.
지원되지 않는 Delta Lake 기능: Delta Lake의 id 모드에서 삭제 벡터 및 열 매핑과 같은 기능은 UniForm for Iceberg와 호환되지 않습니다. 실습에서는 지원되는 열 매핑에 name 모드를 사용합니다.

BigQuery to Spanner

BigQuery에서 Spanner로의 EXPORT DATA 명령어는 모든 BigQuery 데이터 유형을 지원하지 않습니다. 다음 유형의 테이블을 내보내면 오류가 발생합니다.

STRUCT
GEOGRAPHY
DATETIME
RANGE
TIME

또한 BigQuery 프로젝트에서 GoogleSQL 다이얼렉트를 사용하는 경우 다음 숫자 유형도 Spanner로 내보내기가 지원되지 않습니다.

BIGNUMERIC

제한사항의 전체 최신 목록은 공식 문서인 Spanner로 내보내기 제한사항을 참고하세요.

문제 해결 및 주의사항

GCP Databricks 인스턴스에 있지 않은 경우 GCS에서 외부 데이터 위치를 정의하지 못할 수 있습니다. 이러한 경우 Databricks 작업공간의 클라우드 제공업체 스토리지 솔루션에 파일을 스테이징한 다음 GCS로 별도로 마이그레이션해야 합니다.
이렇게 하면 정보에 스테이징된 파일의 경로가 하드 코딩되어 있으므로 메타데이터를 조정해야 합니다.

3. Google Cloud Storage (GCS) 설정

Google Cloud Storage (GCS)는 Databricks에서 생성된 Parquet 데이터 파일을 저장하는 데 사용됩니다. 이렇게 하려면 먼저 파일 대상으로 사용할 새 버킷을 만들어야 합니다.

Google Cloud Storage

새 버킷 만들기

클라우드 콘솔에서 Google Cloud Storage 페이지로 이동합니다.
왼쪽 패널에서 버킷을 선택합니다.

만들기 버튼을 클릭합니다.

버킷 세부정보를 입력합니다.

사용할 버킷 이름을 선택합니다. 이 실습에서는 codelabs_retl_databricks라는 이름을 사용합니다.
버킷을 저장할 리전을 선택하거나 기본값을 사용합니다.
스토리지 클래스를 standard로 유지
액세스 제어의 기본값을 유지합니다.
객체 데이터 보호의 기본값 유지

완료되면 Create 버튼을 클릭합니다. 공개 액세스가 차단됨을 확인하는 메시지가 표시될 수 있습니다. 확인하세요.
축하합니다. 새 버킷이 생성되었습니다. 버킷 페이지로 리디렉션됩니다.

나중에 필요하므로 새 버킷 이름을 어딘가에 복사합니다.

다음 단계 준비

다음 단계에서 필요하므로 다음 세부정보를 기록해 둡니다.

Google 프로젝트 ID
Google Storage 버킷 이름

4. Databricks 설정

TPC-H 데이터

이 실습에서는 의사 결정 지원 시스템의 업계 표준 벤치마크인 TPC-H 데이터 세트를 사용합니다. 이 스키마는 고객, 주문, 공급업체, 부품이 있는 현실적인 비즈니스 환경을 모델링하므로 실제 분석 및 데이터 이동 시나리오를 보여주는 데 적합합니다.

원시 정규화된 TPC-H 테이블 대신 새로운 집계 테이블이 생성됩니다. 이 새 테이블은 orders, customer, nation 테이블의 데이터를 조인하여 지역별 매출의 비정규화된 요약 뷰를 생성합니다. 이 사전 집계 단계는 분석에서 일반적인 방법입니다. 이 시나리오에서는 운영 애플리케이션에서 사용할 수 있도록 특정 사용 사례에 맞게 데이터를 준비하기 때문입니다.

집계된 테이블의 최종 스키마는 다음과 같습니다.

Col	유형
nation_name	문자열
market_segment	문자열
order_year	int
order_priority	문자열
total_order_count	bigint
total_revenue	decimal(29,2)
unique_customer_count	bigint

Delta Lake 유니버설 형식 (UniForm)을 사용한 Iceberg 지원

이 실습에서는 Databricks 내부의 테이블이 Delta Lake 테이블입니다. 하지만 BigQuery와 같은 외부 시스템에서 읽을 수 있도록 범용 형식 (UniForm)이라는 강력한 기능이 사용 설정됩니다.

UniForm은 테이블 데이터의 단일 공유 사본에 대한 Delta Lake 메타데이터와 함께 Iceberg 메타데이터를 자동으로 생성합니다. 이를 통해 다음과 같은 장점을 모두 누릴 수 있습니다.

Databricks 내부: Delta Lake의 모든 성능 및 거버넌스 이점을 얻을 수 있습니다.
Databricks 외부: BigQuery와 같은 Iceberg 호환 쿼리 엔진에서 기본 Iceberg 테이블인 것처럼 테이블을 읽을 수 있습니다.

따라서 별도의 데이터 사본을 유지하거나 수동 변환 작업을 실행할 필요가 없습니다. UniForm은 테이블이 생성될 때 특정 테이블 속성을 설정하여 사용 설정됩니다.

Databricks 카탈로그

Databricks 카탈로그는 Databricks의 통합 거버넌스 솔루션인 Unity Catalog의 데이터용 최상위 컨테이너입니다. Unity Catalog는 데이터 애셋을 관리하고, 액세스를 제어하고, 계보를 추적하는 중앙 집중식 방법을 제공하며, 이는 잘 관리된 데이터 플랫폼에 매우 중요합니다.

3단계 네임스페이스를 사용하여 데이터를 구성합니다(catalog.schema.table).

카탈로그: 환경, 사업부 또는 프로젝트별로 데이터를 그룹화하는 데 사용되는 최상위 수준입니다.
스키마 (또는 데이터베이스): 카탈로그 내의 테이블, 뷰, 함수의 논리적 그룹화입니다.
표: 데이터를 포함하는 객체입니다.

집계된 TPC-H 테이블을 만들려면 먼저 이를 저장할 전용 카탈로그와 스키마를 설정해야 합니다. 이렇게 하면 프로젝트가 깔끔하게 정리되고 작업공간의 다른 데이터와 격리됩니다.

새 카탈로그 및 스키마 만들기

Databricks Unity Catalog에서 카탈로그는 데이터 애셋의 최상위 조직 수준으로, 여러 Databricks 워크스페이스에 걸쳐 있을 수 있는 보안 컨테이너 역할을 합니다. 이를 통해 명확하게 정의된 권한과 액세스 제어를 사용하여 비즈니스 단위, 프로젝트 또는 환경을 기반으로 데이터를 정리하고 격리할 수 있습니다.

카탈로그 내에서 스키마 (데이터베이스라고도 함)는 테이블, 뷰, 함수를 추가로 정리합니다. 이 계층 구조를 사용하면 관련 데이터 객체를 세부적으로 제어하고 논리적으로 그룹화할 수 있습니다. 이 실습에서는 TPC-H 데이터를 저장할 전용 카탈로그와 스키마를 만들어 적절한 격리와 관리를 보장합니다.

카탈로그 만들기

로 이동
+를 클릭한 다음 드롭다운에서 카탈로그 만들기를 선택합니다.

다음 설정으로 새 Standard 카탈로그가 생성됩니다.

카탈로그 이름: retl_tpch_project
스토리지 위치: 작업공간에 설정된 위치가 있으면 기본값을 사용하고, 없으면 새 위치를 만듭니다.

스키마 만들기

로 이동
왼쪽 패널에서 새로 만든 카탈로그를 선택합니다.

를 클릭합니다.
스키마 이름이 tpch_data인 새 스키마가 생성됩니다.

외부 데이터 설정

Databricks에서 Google Cloud Storage (GCS)로 데이터를 내보내려면 Databricks 내에서 외부 데이터 사용자 인증 정보를 설정해야 합니다. 이를 통해 Databricks가 GCS 버킷에 안전하게 액세스하고 쓸 수 있습니다.

카탈로그 화면에서 를 클릭합니다.

External Data 옵션이 표시되지 않으면 Connect 드롭다운 아래에 External Locations이 표시될 수 있습니다.

를 클릭합니다.
새 대화상자 창에서 사용자 인증 정보에 필요한 값을 설정합니다.

사용자 인증 정보 유형: GCP Service Account
사용자 인증 정보 이름: retl-gcs-credential

만들기를 클릭합니다.
그런 다음 외부 위치 탭을 클릭합니다.
위치 만들기를 클릭합니다.
새 대화상자 창에서 외부 위치에 필요한 값을 설정합니다.

외부 위치 이름: retl-gcs-location
스토리지 유형: GCP
URL: GCS 버킷의 URL입니다(gs://YOUR_BUCKET_NAME 형식).
스토리지 사용자 인증 정보: 방금 만든 retl-gcs-credential을 선택합니다.

다음 단계에서 필요하므로 스토리지 사용자 인증 정보를 선택하면 자동으로 입력되는 서비스 계정 이메일을 기록해 둡니다.

만들기를 클릭합니다.

5. 서비스 계정 권한 설정

서비스 계정은 애플리케이션 또는 서비스가 Google Cloud 리소스에 대해 승인된 API 호출을 수행하는 데 사용하는 특별한 계정 유형입니다.

이제 GCS의 새 버킷에 대해 생성된 서비스 계정에 권한을 추가해야 합니다.

GCS 버킷 페이지에서 권한 탭을 선택합니다.

주 구성원 페이지에서 액세스 권한 부여를 클릭합니다.
오른쪽에서 슬라이드되는 액세스 권한 부여 패널의 새 주 구성원 필드에 서비스 계정 ID를 입력합니다.
역할 할당에서 Storage Object Admin 및 Storage Legacy Bucket Reader을 추가합니다. 이러한 역할을 통해 서비스 계정이 스토리지 버킷의 객체를 읽고 쓰고 나열할 수 있습니다.

TPC-H 데이터 로드

이제 카탈로그와 스키마가 생성되었으므로 Databricks에 내부적으로 저장된 기존 samples.tpch 테이블에서 TPCH 데이터를 로드하고 새로 정의된 스키마의 새 테이블로 조작할 수 있습니다.

Iceberg 지원으로 테이블 만들기

UniForm과의 Iceberg 호환성

Databricks는 내부적으로 이 테이블을 Delta Lake 테이블로 관리하여 Databricks 생태계 내에서 Delta의 성능 최적화 및 거버넌스 기능의 모든 이점을 제공합니다. 하지만 UniForm (Universal Format의 약자)을 사용 설정하면 테이블이 업데이트될 때마다 Databricks가 Delta Lake 메타데이터 외에 해당 Iceberg 메타데이터를 자동으로 생성하고 유지관리하도록 지시됩니다.

즉, 이제 단일 공유 데이터 파일 세트 (Parquet 파일)가 두 개의 서로 다른 메타데이터 세트로 설명됩니다.

Databricks: _delta_log를 사용하여 테이블을 읽습니다.
외부 리더 (예: BigQuery): Iceberg 메타데이터 파일 (.metadata.json)을 사용하여 테이블의 스키마, 파티셔닝, 파일 위치를 파악합니다.

그 결과 Iceberg를 인식하는 모든 도구와 완전히 투명하게 호환되는 테이블이 생성됩니다. 데이터가 중복되지 않으며 수동 변환이나 동기화가 필요하지 않습니다. Databricks의 분석 세계와 개방형 Iceberg 표준을 지원하는 더 광범위한 도구 생태계에서 원활하게 액세스할 수 있는 단일 소스입니다.

새로 만들기를 클릭한 다음 쿼리를 클릭합니다.

쿼리 페이지의 텍스트 필드에서 다음 SQL 명령어를 실행합니다.

CREATE TABLE retl_tpch_project.tpch_data.regional_sales_iceberg
USING DELTA
LOCATION 'gs://<Your bucket name>/regional_sales_iceberg'
TBLPROPERTIES (
  'delta.columnMapping.mode' = 'name',
  'delta.enableIcebergCompatV2' = 'true',
  'delta.universalFormat.enabledFormats' = 'iceberg'
)
AS 

SELECT 
    n.n_name AS nation_name,
    c.c_mktsegment AS market_segment,
    YEAR(o.o_orderdate) AS order_year,
    o.o_orderpriority AS order_priority,
    COUNT(o.o_orderkey) AS total_order_count,
    ROUND(SUM(o.o_totalprice), 2) AS total_revenue,
    COUNT(DISTINCT c.c_custkey) AS unique_customer_count
FROM samples.tpch.orders AS o
INNER JOIN samples.tpch.customer AS c 
    ON o.o_custkey = c.c_custkey
INNER JOIN samples.tpch.nation AS n
    ON c.c_nationkey = n.n_nationkey
GROUP BY 
    n.n_name, 
    c.c_mktsegment, 
    YEAR(o.o_orderdate), 
    o.o_orderpriority;

OPTIMIZE retl_tpch_project.tpch_data.regional_sales_iceberg;

DESCRIBE EXTENDED retl_tpch_project.tpch_data.regional_sales_iceberg;

참고:

Using Delta - Delta Lake 테이블을 사용하고 있음을 지정합니다. Databricks의 Delta Lake 테이블만 외부 테이블로 저장할 수 있습니다.
위치 - 외부 테이블인 경우 테이블이 저장될 위치를 지정합니다.
TablePropertoes - delta.universalFormat.enabledFormats = ‘iceberg'는 Delta Lake 파일과 함께 호환되는 Iceberg 메타데이터를 만듭니다.
최적화 - 일반적으로 비동기적으로 발생하는 UniForm 메타데이터 생성을 강제로 트리거합니다.

쿼리 출력에 새로 생성된 테이블에 관한 세부정보가 표시됩니다.

GCS 테이블 데이터 확인

GCS 버킷으로 이동하면 새로 만든 테이블 데이터를 확인할 수 있습니다.

metadata 폴더 내에 Iceberg 메타데이터가 있으며, 이는 BigQuery와 같은 외부 리더에서 사용됩니다. Databricks에서 내부적으로 사용하는 Delta Lake 메타데이터는 _delta_log 폴더에서 추적됩니다.

실제 테이블 데이터는 다른 폴더 내에 Parquet 파일로 저장되며, 일반적으로 Databricks에서 무작위로 생성된 문자열로 이름이 지정됩니다. 예를 들어 아래 스크린샷에서 데이터 파일은 9M 폴더에 있습니다.

6. BigQuery 및 BigLake 설정

이제 Iceberg 테이블이 Google Cloud Storage에 있으므로 다음 단계는 BigQuery에서 액세스할 수 있도록 하는 것입니다. BigLake 외부 테이블을 만들어 이 작업을 수행합니다.

BigLake는 Google Cloud Storage와 같은 외부 소스에서 데이터를 직접 읽는 BigQuery 테이블을 만들 수 있는 스토리지 엔진입니다. 이 실습에서는 데이터를 수집하지 않고도 BigQuery가 방금 내보낸 Iceberg 테이블을 이해할 수 있도록 지원하는 핵심 기술입니다.

이 기능을 사용하려면 다음 두 가지 구성요소가 필요합니다.

Cloud 리소스 연결: BigQuery와 GCS 간의 보안 링크입니다. 인증을 처리하기 위해 특수 서비스 계정을 사용하여 BigQuery에 GCS 버킷에서 파일을 읽는 데 필요한 권한이 있는지 확인합니다.
외부 테이블 정의: BigQuery에 GCS에서 Iceberg 테이블의 메타데이터 파일을 찾을 위치와 해석 방법을 알려줍니다.

Cloud 리소스 연결 만들기

먼저 BigQuery가 GCS에 액세스할 수 있도록 연결이 생성됩니다.

Cloud 리소스 연결 생성에 대한 자세한 내용은 여기를 참고하세요.

BigQuery로 이동
탐색기에서 연결을 클릭합니다.

탐색기 창이 표시되지 않으면 를 클릭합니다.

연결 페이지에서 아이콘을 클릭합니다.
연결 유형으로 Vertex AI remote models, remote functions, BigLake and Spanner (Cloud Resource)를 선택합니다.
연결 ID를 databricks_retl로 설정하고 연결을 만듭니다.

이제 새로 만든 연결의 연결 표에 항목이 표시됩니다. 해당 항목을 클릭하여 연결 세부정보를 확인합니다.

연결 세부정보 페이지에서 서비스 계정 ID를 적어 둡니다. 나중에 필요합니다.

연결 서비스 계정에 대한 액세스 권한 부여

IAM 및 관리자로 이동
액세스 권한 부여를 클릭합니다.

새 주 구성원 필드에 위에서 만든 연결 리소스의 서비스 계정 ID를 입력합니다.
역할에서 Storage Object User을 선택한 다음 을 클릭합니다.

연결이 설정되고 서비스 계정에 필요한 권한이 부여되면 이제 BigLake 외부 테이블을 만들 수 있습니다. 먼저 BigQuery에서 새 테이블의 컨테이너 역할을 하는 데이터 세트가 필요합니다. 그러면 GCS 버킷의 Iceberg 메타데이터 파일을 가리키는 테이블이 생성됩니다.

BigQuery로 이동
탐색기 패널에서 프로젝트 ID를 클릭한 다음 점 3개를 클릭하고 데이터 세트 만들기를 선택합니다.

데이터 세트 이름은 databricks_retl입니다. 다른 옵션은 기본값으로 두고 데이터 세트 만들기 버튼을 클릭합니다.

이제 탐색기 패널에서 새 databricks_retl 데이터 세트를 찾습니다. 옆에 있는 점 3개를 클릭하고 테이블 만들기를 선택합니다.

표 생성에 필요한 다음 설정을 입력합니다.

테이블을 만들 소스: Google Cloud Storage
GCS 버킷에서 파일 선택 또는 URI 패턴 사용: GCS 버킷을 찾아 Databricks 내보내기 중에 생성된 메타데이터 JSON 파일을 찾습니다. 경로는 regional_sales/metadata/v1.metadata.json와 같이 표시됩니다.
파일 형식: Iceberg
표: regional_sales
표 유형: External table
연결 ID: 이전에 만든 databricks_retl 연결을 선택합니다.
나머지 값은 기본값으로 두고 테이블 만들기를 클릭합니다.

생성되면 새 regional_sales 테이블이 databricks_retl 데이터 세트 아래에 표시됩니다. 이제 다른 BigQuery 테이블과 마찬가지로 표준 SQL을 사용하여 이 테이블을 쿼리할 수 있습니다.

7. Spanner에 로드

파이프라인의 마지막이자 가장 중요한 부분인 BigLake 외부 테이블에서 Spanner로 데이터를 이동하는 단계에 도달했습니다. 데이터 웨어하우스에서 처리되고 선별된 데이터가 애플리케이션에서 사용할 수 있도록 운영 시스템에 로드되는 '역방향 ETL' 단계입니다.

Spanner는 완전 관리형의 전역 분산 관계형 데이터베이스입니다. 기존 관계형 데이터베이스의 트랜잭션 일관성을 제공하지만 NoSQL 데이터베이스의 수평 확장성을 갖습니다. 따라서 확장 가능하고 가용성이 높은 애플리케이션을 빌드하는 데 이상적입니다.

프로세스는 다음과 같습니다.

리소스의 물리적 할당인 Spanner 인스턴스를 만듭니다.
해당 인스턴스 내에 데이터베이스를 만듭니다.
regional_sales 데이터의 구조와 일치하는 테이블 스키마를 데이터베이스에 정의합니다.
BigQuery EXPORT DATA 쿼리를 실행하여 BigLake 테이블의 데이터를 Spanner 테이블에 직접 로드합니다.

Spanner 인스턴스, 데이터베이스, 테이블 만들기

Spanner로 이동합니다.
를 클릭합니다 . 사용 가능한 기존 인스턴스가 있으면 사용해도 됩니다. 필요에 따라 인스턴스 요구사항을 설정합니다. 이 실습에서는 다음이 사용되었습니다.

버전	Enterprise
인스턴스 이름	databricks-retl
리전 구성	선택한 지역
컴퓨팅 단위	처리 단위 (PU)
수동 할당	100

생성되면 Spanner 인스턴스 페이지로 이동하여 를 선택합니다. 사용 가능한 기존 데이터베이스가 있는 경우 이를 사용해도 됩니다.

이 실습에서는 다음을 사용하여 데이터베이스를 만듭니다.
이름:databricks-retl
Database Dialect(데이터베이스 다이얼렉트): Google Standard SQL

데이터베이스가 생성되면 Spanner 인스턴스 페이지에서 데이터베이스를 선택하여 Spanner 데이터베이스 페이지로 이동합니다.
Spanner 데이터베이스 페이지에서 아이콘을 클릭합니다.
새 쿼리 페이지에 Spanner로 가져올 테이블의 테이블 정의가 생성됩니다. 이렇게 하려면 다음 SQL 쿼리를 실행하세요.

CREATE TABLE regional_sales (
    nation_name STRING(MAX),
    market_segment STRING(MAX),
    order_year INT64,
    order_priority STRING(MAX),
    total_order_count INT64,
    total_revenue NUMERIC,
    unique_customer_count INT64
) PRIMARY KEY (nation_name, market_segment, order_year, order_priority);

SQL 명령어가 실행되면 이제 BigQuery에서 데이터를 역방향 ETL할 수 있도록 Spanner 테이블이 준비됩니다. 테이블이 생성되었는지 확인하려면 Spanner 데이터베이스의 왼쪽 패널에 테이블이 표시되는지 확인하면 됩니다.

`EXPORT DATA`를 사용하여 Spanner로 역방향 ETL

마지막 단계입니다. BigQuery BigLake 테이블에 소스 데이터가 준비되고 Spanner에 대상 테이블이 생성되면 실제 데이터 이동은 매우 간단합니다. 단일 BigQuery SQL 쿼리(EXPORT DATA)가 사용됩니다.

이 쿼리는 이와 같은 시나리오를 위해 특별히 설계되었습니다. BigQuery 테이블 (BigLake 테이블과 같은 외부 테이블 포함)의 데이터를 외부 대상으로 효율적으로 내보냅니다. 이 경우 대상은 Spanner 테이블입니다. 내보내기 기능에 대한 자세한 내용은 여기를 참고하세요.

BigQuery에서 Spanner로의 역방향 ETL 설정에 대한 자세한 내용은 여기를 참고하세요.

BigQuery로 이동
새 쿼리 편집기 탭을 엽니다.
쿼리 페이지에 다음 SQL을 입력합니다. uri의 프로젝트 ID와 테이블 경로를 올바른 프로젝트 ID로 바꿔야 합니다.

EXPORT DATA OPTIONS(

uri='https://spanner.googleapis.com/projects/YOUR_PROJECT_ID/instances/databricks-retl/databases/databricks-retl',
  format='CLOUD_SPANNER',
   spanner_options="""{
      "table": "regional_sales",
      "priority": "MEDIUM"
  }"""
) AS

SELECT * FROM `YOUR_PROJECT_ID.databricks_retl.regional_sales`;

명령어가 완료되면 데이터가 Spanner로 성공적으로 내보내진 것입니다.

8. Spanner에서 데이터 확인

축하합니다. Databricks 데이터 웨어하우스에서 운영 Spanner 데이터베이스로 데이터를 이동하는 완전한 역방향 ETL 파이프라인이 성공적으로 빌드되고 실행되었습니다.

마지막 단계는 데이터가 Spanner에 예상대로 도착했는지 확인하는 것입니다.

Spanner로 이동합니다.
databricks-retl 인스턴스로 이동한 다음 databricks-retl 데이터베이스로 이동합니다.
테이블 목록에서 regional_sales 테이블을 클릭합니다.
테이블의 왼쪽 탐색 메뉴에서 데이터 탭을 클릭합니다.

원래 Databricks에서 가져온 집계된 판매 데이터가 이제 Spanner 테이블에 로드되어 사용할 준비가 되었습니다. 이제 이 데이터는 운영 시스템에 있으며, 라이브 애플리케이션을 지원하거나, 대시보드를 제공하거나, API로 쿼리할 수 있습니다.

분석 데이터와 운영 데이터 간의 격차가 성공적으로 해소되었습니다.

9. 삭제

이 실습을 완료한 후 추가된 모든 테이블과 저장된 데이터를 삭제합니다.

Spanner 테이블 정리

Spanner로 이동
databricks-retl이라는 목록에서 이 실습에 사용된 인스턴스를 클릭합니다.

인스턴스 페이지에서 를 클릭합니다.
팝업되는 확인 대화상자에 databricks-retl을 입력하고 을 클릭합니다.

GCS 정리

GCS로 이동
왼쪽 메뉴에서 를 선택합니다.
``codelabs_retl_databricks 버킷을 선택합니다.

선택한 후 상단 배너에 표시되는 버튼을 클릭합니다.

팝업되는 확인 대화상자에 DELETE을 입력하고 을 클릭합니다.

Databricks 정리

카탈로그/스키마/테이블 삭제

Databricks 인스턴스에 로그인
왼쪽 사이드 메뉴에서 를 클릭합니다.
카탈로그 목록에서 이전에 만든 를 선택합니다.
스키마 목록에서 생성된 을 선택합니다.
표 목록에서 이전에 만든 를 선택합니다.
를 클릭하여 표 옵션을 펼치고 Delete를 선택합니다.
확인 대화상자에서 를 클릭하여 표를 삭제합니다.
표가 삭제되면 스키마 페이지로 다시 이동합니다.
를 클릭하여 스키마 옵션을 펼치고 Delete를 선택합니다.
확인 대화상자에서 를 클릭하여 스키마를 삭제합니다.
스키마가 삭제되면 카탈로그 페이지로 돌아갑니다.
default 스키마가 있는 경우 4~11단계를 다시 따라 스키마를 삭제합니다.
카탈로그 페이지에서 를 클릭하여 카탈로그 옵션을 펼치고 Delete를 선택합니다.
확인 대화상자에서 를 클릭하여 카탈로그를 삭제합니다.

외부 데이터 위치 / 사용자 인증 정보 삭제

카탈로그 화면에서 를 클릭합니다.
External Data 옵션이 표시되지 않으면 Connect 드롭다운 아래에 External Location이 표시될 수 있습니다.
이전에 만든 retl-gcs-location 외부 데이터 위치를 클릭합니다.
외부 위치 페이지에서 를 클릭하여 위치 옵션을 펼치고 Delete을 선택합니다.
확인 대화상자에서 를 클릭하여 외부 위치를 삭제합니다.
를 클릭합니다.
이전에 만든 retl-gcs-credential를 클릭합니다.
사용자 인증 정보 페이지에서 를 클릭하여 사용자 인증 정보 옵션을 펼치고 Delete를 선택합니다.
확인 대화상자에서 를 클릭하여 사용자 인증 정보를 삭제합니다.

10. 마무리

축하합니다. Codelab을 완료했습니다.

학습한 내용

Databricks에 데이터를 Iceberg 테이블로 로드하는 방법
GCS 버킷을 만드는 방법
Databricks 테이블을 Iceberg 형식으로 GCS에 내보내는 방법
GCS의 Iceberg 테이블에서 BigQuery의 BigLake 외부 테이블을 만드는 방법
Spanner 인스턴스를 설정하는 방법
BigQuery의 BigLake 외부 테이블을 Spanner에 로드하는 방법