이 문서에서는 데이터 변경사항을 BigQuery 기반 데이터 웨어하우스(DWH)에 통합하는 데 도움이 될 반복 가능한 워크플로를 구현하는 원칙과 기법을 설명합니다. 이러한 변경사항으로는 새 데이터 세트, 새 데이터 소스, 기존 데이터 세트의 업데이트 및 변경사항이 포함될 수 있습니다. 이 문서에서는 이 작업의 참조 아키텍처도 설명합니다.
이 문서는 BigQuery를 DWH로 사용하는 소프트웨어 및 데이터 설계자 및 데이터 엔지니어를 대상으로 합니다. 이 문서에서는 CI/CD의 기본 개념 또는 이와 비슷한 애플리케이션 수명 주기 관리 작업에 익숙하다고 가정합니다.
소개
지속적 통합 및 지속적 배포(CI/CD)가 소프트웨어 개발 수명 주기에서 필수적인 기술이 되었습니다. CI/CD 원칙을 채택하면 팀에서 기능을 통합하고 수동으로 배포할 때보다 문제 발생이 적으며 더 우수한 소프트웨어를 제공할 수 있습니다. 데이터 웨어하우징을 현대화할 때 CI/CD를 데이터 관리 전략의 일부로 포함할 수도 있습니다.
그러나 BigQuery와 같은 DWH로 작업하는 경우 CI/CD 구현 방법이 소스 코드에 CI/CD를 구현할 때와 다릅니다. 이러한 차이가 발생하는 이유 중 하나는 데이터 웨어하우징이 기본 데이터를 관리하는 본질적인 스테이트풀(Stateful) 시스템이라는 것에 있습니다.
이 문서에서는 다음 정보를 제공합니다.
- BigQuery에서 지속적 통합(CI) 전략을 구현하는 기법
- 맹점을 피하는 데 도움이 되는 안내 및 방법
- BigQuery의 CI에 도움이 되는 BigQuery 기능 제안
이 문서에서는 CI를 중점적으로 다룹니다. 지속적 배포(CD)보다 통합에 데이터 웨어하우징팀의 데이터 관련 고려사항이 더 많기 때문입니다.
BigQuery DWH로 CI를 사용해야 하는 경우
이 문서에서 데이터 통합은 일반적으로 DWH팀에서 수행하는 작업으로서, DWH에 새 데이터를 통합하는 작업이 포함됩니다. 이 작업에서 새 데이터 소스를 DWH에 통합하거나 이미 DWH 내부에 있는 테이블의 구조를 변경해야 할 수 있습니다.
새 데이터를 DWH로 통합하는 것은 새 기능을 기존 소프트웨어에 통합하는 것과 비슷한 태스크입니다. 버그를 일으킬 수 있고 최종 사용자 환경에 부정적인 영향을 줄 수 있습니다. BigQuery에 데이터를 통합하면 스키마 불일치로 인해 데이터의 다운스트림 소비자(예: 애플리케이션, BI 대시보드, 개별 사용자)에게 문제가 발생할 수 있습니다. 또는 원래 데이터 소스의 데이터를 반영하지 않는 잘못된 데이터가 소비자에 사용될 수 있습니다.
DWH용 CI는 다음을 수행하려고 할 때 유용합니다.
- DWH 시스템용 CI의 핵심 사항을 설명합니다.
- BigQuery 환경용 CI 전략을 설계하고 구현합니다.
- BigQuery 기능을 사용하여 CI를 구현하는 방법을 알아봅니다.
이 가이드에서는 Dataflow 및 Bigtable과 같은 데이터 제품을 포함하여 비-DWH 제품의 CI를 관리하는 방법은 설명하지 않습니다.
예시 시나리오
Example Company는 BigQuery에서 DWH를 유지보수하는 대형 소매 기업입니다. 이 회사는 내년에 Example Company에서 최근에 인수된 회사들의 새로운 데이터 소스를 DWH에 통합하려고 합니다. 통합할 새 데이터 소스는 스키마가 다릅니다. 하지만 DWH는 기존 스키마를 유지해야 하며 데이터의 다운스트림 소비자가 부정적인 영향을 받지 않도록 강력한 데이터 일관성과 데이터 완전성을 제공해야 합니다.
현재 Example Company DWH팀이 데이터 통합을 수행하고 있습니다. 통합을 위해서는 기존 데이터 소스를 미리 정의된 스키마에 포함시켜야 합니다. 이 워크플로에는 기존 데이터 가져오기 프로세스, 획득한 데이터베이스, 애플리케이션 서비스가 포함됩니다.
새로운 데이터 소스를 수용하도록 데이터 통합 프로세스를 업데이트하려면 DWH팀에서 강력한 데이터 일관성과 같이 앞에서 언급한 요구사항을 준수하게끔 데이터 통합 방식을 다시 설계해야 합니다. 데이터를 다운스트림 소비자에게 제공하기 전에 데이터 변경사항을 테스트하고 측정할 수 있도록 팀에서 격리된 방식으로 변경사항을 구현해야 합니다.
DWH팀에서 새 워크플로를 채택한 후 팀에 반복 가능한 프로세스가 마련되었습니다. 각 개발자가 프로덕션 데이터를 기반으로 한 격리된 개발 환경을 만들 수 있습니다. 이러한 격리된 환경을 사용해 이후 개발자가 변경하고 변경사항을 테스트 및 검토하고 필요한 변경사항을 프로덕션 환경에 전달할 수 있습니다. 변경사항으로 인해 버그 또는 예기치 않은 문제가 발생하는 경우 변경사항을 쉽게 롤백할 수 있습니다.
DWH에 지속적 통합이 갖는 의미
지속적 통합(CI)은 개발팀이 수동 시스템보다 개발 주기를 단축하고 코드에서 문제를 빠르게 찾을 수 있는 관행 모음입니다. CI 접근 방식을 채택할 때의 주요 이점은 신속하게 개발할 수 있어 개발자 간의 간섭 위험을 줄일 수 있다는 것입니다. 프로세스를 반복 가능하며 각 개발자가 다른 개발자와 개별적으로 작업할 수 있기 때문입니다.
이러한 원칙은 몇 가지 차이가 있지만 조직이 데이터를 DWH에 통합해야 할 때 적용됩니다. 일반적인 소프트웨어 개발의 맥락에서 CI는 스테이트리스(Stateless)인 소스 코드의 변경사항을 격리합니다. 데이터의 CI의 맥락에서 CI는 데이터를 DWH 시스템으로 통합니다. 하지만 데이터는 정의에 따라 스테이트풀(Stateful)입니다. 이러한 차이는 이 문서에 설명된 대로 CI가 DWH 시나리오에 적용되는 방법에 영향을 줍니다.
이 문서에서 다루지 않는 추가 시나리오
이 문서에서는 프로덕션 환경과 개발 변경사항을 격리하는 방법을 중점적으로 설명하지만 데이터 통합의 다음과 같은 측면은 다루지 않습니다.
- 데이터 테스트: 데이터가 비즈니스 요구사항을 준수하는지 검증할 수 있나요? 데이터를 신뢰할 수 있는 정보 소스로 사용할 수 있나요? DWH에서 제공하는 데이터의 신뢰도를 높이려면 데이터를 테스트하는 것이 중요합니다. 테스트를 위해서는 데이터에 누락된 값이 없는지 어설션하거나 '잘못된' 값이 있는지 어설션하는 쿼리 집합을 실행하면 됩니다.
- 데이터 계보: 테이블을 해당 맥락에서 볼 수 있나요? 예를 들어 데이터가 어디에서 수집되었는지, 테이블을 생성하기 위해 어떤 데이터 세트가 사전 계산되었는지 확인할 수 있나요? 현대의 DWH 아키텍처에서 데이터는 서로 다른 전문화된 데이터 구조를 사용하는 여러 시스템으로 분할됩니다. 여기에는 관계형 데이터베이스, NoSQL 데이터베이스, 외부 데이터 소스가 포함됩니다. 보유하고 있는 데이터를 완전히 이해하려면 해당 데이터를 추적해야 합니다. 또한 데이터가 생성된 방법과 생성된 위치도 이해해야 합니다.
이러한 주제는 이 가이드의 범위를 벗어납니다. 하지만 팀의 워크플로를 설계할 때 이러한 주제를 계획하는 것이 데이터 전략에 도움이 됩니다.
BigQuery를 DWH로 사용하는 일반적인 설정
다음 다이어그램은 BigQuery에 대한 일반적인 DWH 디자인을 보여줍니다. 외부 소스의 데이터가 DWH에 수집되는 방법과 소비자가 DWH에서 데이터를 소비하는 방법을 보여줍니다.
데이터는 데이터 소스에서 시작됩니다. 데이터 소스에서 데이터는 OLTP SQL 데이터베이스 및 NoSQL 데이터베이스와 같은 기존의 트랜잭션 또는 지연 시간이 짧은 데이터베이스에 있습니다. 예약된 프로세스에서 데이터를 스테이징 영역에 복사합니다.
데이터는 스테이징 영역에 임시로 저장됩니다. 필요한 경우 데이터가 DWH 테이블에 로드되기 전 분석 시스템에 맞게 변환됩니다. (이 다이어그램에서 스테이징 영역은 Google Cloud 내에 있지만 이것이 반드시 필요하지는 않습니다.) 변환에는 정규화 해제, 특정 데이터 세트 강화, 잘못 된 형식의 항목 처리(예: 값이 누락된 항목)가 포함될 수 있습니다.
스테이징 영역에서 새 데이터는 DWH 테이블에 로드됩니다. 테이블은 DWH 설계에 따라 서로 다른 방식으로 구성될 수 있고 일반적으로 코어 테이블이라고 불립니다. 테이블 설계 패러다임의 일부 예시에는 별표 스키마 패러다임, 비정규화된 패러다임, 다중 계층 집계가 포함됩니다.
테이블 설계에 관계없이 이러한 테이블은 시간이 지남에 따라 데이터를 저장합니다. 테이블은 스키마를 따라야 하며 모든 분석 용도를 위한 정보 소스를 보유한 것으로 간주됩니다. 이러한 테이블 역할은 테이블의 데이터가 완전하고 일관되며 사전 정의된 스키마를 준수해야 함을 의미합니다.
이 테이블은 소비자에게 직접 데이터를 제공하지 않습니다. 대신 기존 데이터에 적용되어야 하는 비즈니스 논리를 캡슐화하도록 설계된 액세스 레이어를 통해 데이터가 제공됩니다. 이러한 비즈니스 논리 유형의 예시에는 각 레코드의 측정항목 계산, 데이터 필터링 및 그룹화가 있습니다.
데이터 소비자는 DWH 액세스 레이어에 연결하여 데이터를 읽을 수 있습니다. 데이터 소비자에는 다음과 같은 시스템이 포함될 수 있습니다.
- 비즈니스 인텔리전스(BI) 대시보드
- 데이터 사이언스 노트
- DWH에서 계산된 데이터에 의존하는 운영 시스템
- 임시 쿼리를 실행하는 사람인 사용자
데이터 소비자는 일관된 스키마를 제공하기 위해 DWH와 DWH가 캡슐화하는 비즈니스 논리에 크게 의존합니다. 이러한 스키마 및 비즈니스 논리는 DWH 플랫폼의 서비스수준계약(SLA)으로 간주할 수 있습니다. 비즈니스 논리, 스키마, 데이터의 완전성에 대한 변경은 다운스트림에 큰 영향을 미칠 수 있습니다. DWH팀은 최신 데이터 플랫폼의 변화하는 특성상 SLA를 엄격하게 준수하면서 이러한 변경을 수행해야 할 수 있습니다. 팀이 이러한 SLA를 충족하고 DWH를 최신 상태로 유지하려면 데이터 통합을 허용하고 동시에 이러한 변경으로 인해 발생할 수 있는 마찰을 최소화하는 워크플로가 필요합니다.
DWH의 지속적 통합을 위한 애셋
다른 개발 또는 IT팀과 마찬가지로 DWH팀도 자신의 책임에 필수적인 자산을 유지보수해야 합니다. 이러한 자산은 일반적으로 다음 카테고리로 나눌 수 있습니다.
데이터 파이프라인의 코드베이스: 이러한 자산은 일반적으로 Python 또는 자바와 같은 고급 프로그래밍 언어의 소스 코드로 구성됩니다. 이러한 유형의 자산의 경우 CI/CD 프로세스는 Git 및 Jenkins와 같은 도구를 사용하거나 Cloud Source Repositories 및 Cloud Build와 같은 Google Cloud 솔루션을 사용하여 빌드됩니다.
SQL 스크립트: 이 애셋은 구조와 DWH 내부에 캡슐화된 비즈니스 로직을 설명합니다. 이 카테고리 내에서 애셋을 다음 하위 카테고리로 더 세분화할 수 있습니다.
- 데이터 정의 언어(DDL): 이 애셋은 테이블 및 뷰의 스키마를 정의하는 데 사용됩니다.
- 데이터 조작 언어(DML): 이러한 자산은 테이블 내에서 데이터를 조작하는 데 사용됩니다. DML 명령어는 또한 기존 테이블을 기준으로 새 테이블을 생성하기 위해 사용됩니다.
- 데이터 제어 언어(DCL): 이러한 자산은 테이블에 대한 권한 및 액세스를 제어하기 위해 사용됩니다. BigQuery 내에서 SQL 및
bq명령줄 도구를 사용하거나 BigQuery REST API를 사용하여 액세스를 제어할 수 있습니다. 하지만 IAM을 사용하는 것이 좋습니다.
이러한 애셋과 구성요소를 빌드하는 데 사용되는 Terraform 스크립트 등의 애셋은 코드 저장소 내에서 유지보수됩니다. Dataform과 같은 도구를 사용하면 SQL 스크립트를 검증하고 DDL 스크립트로 만든 테이블에서 사전 정의된 검증 규칙을 확인하는 CI/CD 파이프라인을 구성할 수 있습니다. 이러한 도구로 대부분 자연스러운 테스트 환경이 없는 SQL에 컴파일 및 테스트 프로세스를 적용할 수 있습니다.
도구 및 프로세스와 관련된 애셋 외에 데이터도 DWH팀의 주요 애셋입니다. 소스 코드를 추적하도록 설계된 Git와 같은 애셋 추적 시스템을 사용하여 데이터를 추적할 수 없습니다. 이 문서에서는 데이터 추적과 관련된 문제를 설명합니다.
데이터 통합 관련 문제
DWH 내부에서 테이블 관계의 잠재적 복잡성(예: 앞에서 언급한 테이블 설계 패러다임 중 하나)으로 인해 프로덕션 데이터의 상태를 테스트 환경과 격리하기가 어렵습니다. 소프트웨어 개발 표준 관행은 데이터 통합 시나리오에 적용할 수 없습니다.
다음 표에는 코드 통합 관행과 데이터 통합 관행의 차이점이 요약되어 있습니다.
| 코드 통합 | 데이터 통합 | |
|---|---|---|
| 로컬 개발 | 비교적 작은 크기로 인해 소스 코드를 쉽게 복제할 수 있습니다. 일반적으로 코드는 (다른 솔루션이 있는 단일 저장소의 경우를 제외한) 대부분의 최종 사용자 머신에 적합합니다. | DWH에서 대부분의 테이블은 크기 때문에 개발 머신에 들어갈 수 없습니다. |
| 중앙 테스트 | 소스 코드의 여러 상태가 중앙 시스템(CI 서버)으로 클론되어 자동화된 테스트를 거칩니다. 코드의 다양한 상태를 통해 정식 버전과 개발 버전의 결과를 비교할 수 있습니다. | 격리된 환경에서 다양한 데이터 상태를 생성하는 것은 간단하지 않습니다. DWH 외부로 데이터를 이동하는 것은 리소스 집약적이고 시간이 오래 걸리는 작업입니다. 테스트에 필요한 만큼 자주 수행하는 것은 실용적이지 않습니다. |
| 이전 버전 | 새 버전의 소프트웨어를 출시하는 프로세스 동안 이전 버전을 추적할 수 있습니다. 새 출시 버전에서 문제가 발견되면 안전한 버전으로 롤백할 수 있습니다. | 롤백해야 하는 경우를 대비하여 DWH 내부에서 테이블을 백업하는 것이 표준 관행입니다. 그러나 영향을 받는 모든 테이블이 동일한 시점으로 롤백되는지 확인해야 합니다. 그래야 관련 테이블이 서로 일관됩니다. |
BigQuery 테이블에 데이터 통합
BigQuery에는 데이터 통합을 위한 워크플로를 설계하는 데 도움이 되는 두 가지 기능인 테이블 스냅샷과 테이블 클론이 있습니다. 이러한 기능을 결합하여 비용 효율적인 개발 환경을 제공하는 워크플로를 달성할 수 있습니다. 개발자는 데이터 및 데이터 구조를 프로덕션 환경과 분리하여 조작할 수 있고 필요에 따라 변경사항을 롤백할 수 있습니다.
BigQuery 테이블 스냅샷은 특정 시점의 테이블(기본 테이블이라고 부름)을 읽기 전용으로 표현한 것입니다. 마찬가지로 BigQuery 테이블 클론은 특정 시점의 테이블에 대한 읽기/쓰기 표현입니다. 두 경우 모두 기본 테이블과의 차이점만 저장되기 때문에 스토리지 비용이 최소화됩니다. 테이블 클론은 기본 테이블이 변경될 때 또는 테이블 클론이 변경될 때 비용이 발생하기 시작합니다. 테이블 스냅샷이 읽기 전용이므로 기본 테이블이 변경될 때만 비용이 발생합니다.
테이블 스냅샷 및 테이블 클론의 가격 책정에 대한 자세한 내용은 테이블 스냅샷 소개 및 테이블 클론 소개를 참조하세요.
BigQuery 시간 이동 기능을 사용하여 (최대 지난 7일간의) 테이블 스냅샷과 테이블 클론을 만들 수 있습니다. 이 기능으로 동시에 여러 테이블의 스냅샷과 클론을 캡처하여 작업 환경과 스냅샷의 일관성을 유지할 수 있습니다. 이 기능은 자주 업데이트되는 테이블에 유용합니다.
테이블 클론 및 테이블 스냅샷을 사용하여 격리를 허용하는 방법
DWH에서 CI에 대한 통합 워크플로를 설명하기 위해 다음과 같은 시나리오를 상상해 보세요. 새로운 데이터 세트를 DWH에 통합하는 태스크를 수행해야 합니다. 여기에서는 새 DWH 테이블을 만들거나, 기존 테이블을 업데이트하거나, 테이블 구조를 변경하거나, 이러한 태스크 조합을 수행해야 할 수 있습니다. 워크플로는 다음 순서로 표시될 수 있습니다.
- 변경사항의 영향을 받을 수 있는 테이블과 확인할 추가 테이블을 식별합니다.
- 이 변경사항의 애셋을 포함할 새 BigQuery 데이터 세트를 만듭니다. 이 데이터 세트는 변경사항을 격리하고 다른 팀원이 수행하는 다른 작업과 이 작업을 분리합니다. 데이터 세트는 소스 데이터 세트와 같은 리전에 있어야 합니다. 하지만 조직의 보안 및 결제 요구사항을 위해 프로젝트를 프로덕션 프로젝트와 분리할 수 있습니다.
각 테이블에서 동일한 시점에 새 데이터 세트에 클론과 스냅샷을 만듭니다. 이 접근 방식에는 다음과 같은 이점이 있습니다.
- 테이블 클론은 프로덕션 테이블에 영향을 주지 않고 자유롭게 변경할 수 있는 작업 사본으로 작동할 수 있습니다. 최소한의 오버헤드로 서로 다른 통합 경로를 동시에 테스트하기 위해 동일한 기본 테이블의 여러 테이블 클론을 만들 수 있습니다.
- 스냅샷은 변경되기 전에 데이터가 작동하는 것으로 알려진 지점인 복원 및 참조 지점으로 기능할 수 있습니다. 스냅샷을 만들면 프로세스 후반부에서 문제가 감지될 경우 롤백을 수행할 수 있습니다.
테이블 클론을 사용하여 테이블에 필요한 변경사항을 구현합니다. 이 작업을 수행하면 테이블 클론의 업데이트된 버전이 생성되고, 격리된 데이터 세트에서 테스트할 수 있습니다.
원하는 경우 구현 단계가 끝날 때 다음 작업에 사용할 수 있는 데이터 세트를 제공할 수 있습니다.
- Dataform과 같은 검증 도구를 사용하는 단위 테스트. 단위 테스트는 독립적으로 실행됩니다. 즉, 자산이 격리된 상태로 테스트됩니다. 이 경우 자산은 BigQuery의 테이블입니다. 단위 테스트는 null 값을 확인하고, 모든 문자열이 길이 요구사항을 충족하는지 확인하고, 특정 집계가 유용한 결과를 생성하는지 확인할 수 있습니다. 단위 테스트에는 테이블이 조직의 비즈니스 규칙을 유지하는지 확인하는 신뢰 테스트가 포함될 수 있습니다.
- 다운스트림 소비자 통합 테스트
- 동료 검토
이 워크플로에서는 다운스트림 소비자에 영향을 주지 않고 프로덕션 데이터로 테스트할 수 있습니다.
새 데이터를 BigQuery에 병합하기 전 다른 스냅샷을 만들 수 있습니다. 이 스냅샷은 기본 테이블의 데이터가 변경될 경우에 다른 롤백 옵션으로 유용합니다.
변경사항을 병합하는 프로세스는 조직에서 채택하려는 프로세스 및 필요한 변경사항에 따라 달라집니다. 예를 들어 SQL 스크립트에 변경사항이 있으면 새 데이터 세트에 표준 코드베이스에 대한 pull 요청이 수반될 수 있습니다. 변경사항이 지정된 테이블 내의 데이터 변경사항으로 제한되는 경우 BigQuery의 표준 메서드를 사용하여 데이터를 복사할 수 있습니다.
저장 프로시져 스크립트를 사용하여 데이터 세트를 만들고 클론 및 스냅샷을 만들기 위한 단계를 캡슐화하고 자동화할 수 있습니다. 이러한 태스크를 자동화하면 작업자 오류 위험이 줄어듭니다. 프로세스를 자동화하는 데 도움이 되는 스크립트 예시는 BigQuery CLI 유틸리티 GitHub 저장소의 데이터를 위한 CI를 참조하세요.
테이블 클론 및 테이블 스냅샷 사용 이점
이전 섹션에서 설명한 워크플로를 사용하면 개발자들이 동료를 방해하지 않고 격리된 상태에서 동시에 작업할 수 있습니다. 개발자가 변경사항을 테스트하고 검토할 수 있고, 문제가 발생하면 변경사항을 롤백할 수 있습니다. 전체 테이블이 아닌 테이블 스냅샷으로 작업하므로 전체 테이블 작업에 비해 비용과 스토리지를 최소화할 수 있습니다.
이 섹션에서는 테이블 스냅샷 및 테이블 클론을 통해 개발자가 이 워크플로를 달성하는 방법에 대해 자세히 설명합니다. 다음 다이어그램은 테이블 스냅샷 및 테이블 클론이 프로덕션 데이터 세트의 데이터와 연관된 방식을 보여줍니다.
다이어그램에서 프로덕션 데이터 세트에는 프로덕션에 사용 중인 모든 테이블이 포함되어 있습니다. 모든 개발자는 자체 개발 환경에 대한 데이터 세트를 만들 수 있습니다. 이 다이어그램은 Dev Dataset 1 및 Dev Dataset 2로 라벨이 지정된 2개의 개발자 데이터 세트를 보여줍니다. 이러한 개발자 데이터 세트를 사용하여 개발자는 서로 간섭하지 않고 동일한 테이블에서 동시에 작업할 수 있습니다.
개발자는 데이터 세트를 만든 후 자신이 작업 중인 테이블의 클론 및 스냅샷을 만들 수 있습니다. 클론 및 스냅샷은 특정 시점의 데이터를 나타냅니다. 이 시점에 개발자는 변경사항이 기본 테이블에 표시되지 않기 때문에 테이블 클론을 자유롭게 변경할 수 있습니다.
개발자는 테이블 클론을 검토하고, 이를 스냅샷과 비교하고 다운스트림 소비자와의 호환성을 테스트할 수 있습니다. 다른 개발자는 간섭을 일으키지 않고 리소스를 너무 많이 소비하는 기본 테이블 사본을 만들지 않고 다른 클론 및 스냅샷으로 작업을 수행할 수 있습니다.
개발자가 필요한 경우 스냅샷을 롤백 옵션으로 안전하게 유지하며 변경사항을 기본 테이블에 병합할 수 있습니다. 이 프로세스를 개발, 테스트, 프로덕션과 같은 다양한 환경에서 반복할 수도 있습니다.
테이블 클론 및 테이블 스냅샷 대안
테이블 클론 및 테이블 스냅샷을 사용하는 대신 비슷한 결과를 얻을 수 있는 방법이 있습니다. 이러한 대체 방법은 일반적으로 클론 및 스냅샷과 다르게 사용됩니다. 이러한 방법의 차이와 각 방법의 선호도 차이를 이해하는 것이 중요합니다.
전체 테이블을 다른 데이터 세트에 복사
한 가지 대안 방법은 다른 데이터 세트를 사용하고 테이블을 데이터 세트에 복사하는 것입니다. 이 방법을 사용하는 것은 테이블 클론 및 스냅샷을 사용하는 것과 비슷하지만 전체 테이블 집합을 복사합니다. 복사할 데이터의 크기에 따라 스토리지 비용이 많이 들 수 있습니다. 일부 조직에서는 BigQuery에서 테이블 클론을 사용할 수 있기 전에 이 방법을 사용했습니다. 하지만 이 방법은 클론 및 스냅샷을 사용하는 것에 비해 어떠한 이점도 제공하지 않습니다.
Cloud Storage로 테이블 내보내기 및 가져오기
또 다른 대안 방법은 Cloud Storage를 통해 데이터를 이동하는 것입니다. 이 방법도 테이블 클론 및 테이블 스냅샷을 사용하는 것과 비슷합니다. 하지만 여기에는 데이터를 Cloud Storage 버킷으로 내보내는 추가 단계가 포함됩니다. 이 방법의 한 가지 이점은 데이터를 추가로 백업할 수 있다는 것입니다. 재해 복구 또는 하이브리드 솔루션을 위한 백업을 원하는 경우 이 방법을 선택할 수 있습니다.
Analytics Hub 사용
Analytics Hub를 사용하면 안전하게 설계된 방식으로 조직 내부 및 외부에서 데이터 세트를 공유할 수 있습니다. 데이터 세트를 게시하여 구독자에게 데이터 세트에 대한 제어된 읽기 전용 액세스 권한을 제공할 수 있는 여러 기능을 제공합니다. 하지만 변경사항을 구현하기 위해 Analytics Hub를 사용해 데이터 세트를 노출하더라도 개발자가 테이블 작업을 위해 테이블 클론을 만들어야 합니다.
DWH 지속적 통합 옵션 요약
다음 표에는 DWH 지속적 통합 옵션의 차이점, 장점, 잠재적인 단점이 요약되어 있습니다. (Analytics Hub는 다른 특성 세트를 제공하므로 표에 나온 매개변수를 사용하여 측정할 수 없습니다.)
| 비용 | 롤백 | 위험 | |
|---|---|---|---|
| 테이블 스냅샷 및 테이블 클론 | 최소. 스냅샷 또는 클론과 기본 테이블 사이의 차이점에 대해서만 비용을 지불합니다. | 필요한 경우 스냅샷이 롤백할 백업의 역할을 합니다. | 위험 수준을 제어합니다. 모든 테이블에 대해 특정 시점에서 스냅샷을 생성할 수 있으므로, 롤백이 있더라도 불일치가 줄어듭니다. |
| 테이블 복사 | 테이블 스냅샷 및 테이블 클론을 사용할 때보다 비용이 높습니다. 데이터 전체가 중복됩니다. 롤백을 지원하려면 동일한 테이블의 사본이 여러 개 필요합니다. | 가능하나 테이블의 사본이 2개 필요합니다. 한 개는 백업 역할을 하고 다른 한 개는 작업과 변경을 위한 사본입니다. | 특정 시점의 클론이 더 어렵습니다. 롤백이 필요한 경우 모든 테이블을 동일한 시점에서 가져오지 않습니다. |
| 내보내기 및 가져오기 | 테이블 스냅샷 및 테이블 클론을 사용할 때보다 비용이 높습니다. 데이터가 중복됩니다. 롤백을 지원하려면 동일한 테이블의 사본이 여러 개 필요합니다. | 내보낸 데이터는 백업으로 사용됩니다. | 내보낸 데이터는 여러 테이블의 특정 시점 내보내기가 아닙니다. |
다음 단계
- 테이블 스냅샷 소개에서 BigQuery 테이블 스냅샷에 대해 알아보기
- DevOps 기술: 지속적 통합에서 소프트웨어 개발을 위한 지속적 통합에 대해 자세히 알아보기
- 클라우드 아키텍처 센터에서 참조 아키텍처, 다이어그램, 권장사항 자세히 살펴보기