개요: BigQuery로 데이터 웨어하우스 마이그레이션
이 문서에서는 모든 데이터 웨어하우징 기술에 적용되는 일반적인 개념을 설명하고 BigQuery로의 마이그레이션을 구성하고 구조화하는 데 사용할 수 있는 프레임워크를 설명합니다.
용어
데이터 웨어하우스 마이그레이션에 대해 논의할 때는 다음 용어를 사용합니다.
- 사용 사례
-
사용 사례는 비즈니스 가치를 실현하는 데 필요한 모든 데이터 세트, 데이터 처리, 시스템, 사용자 상호작용으로 구성됩니다(예: 시간 경과에 따른 제품의 판매량 추적). 데이터 웨어하우징에서 사용 사례는 다음 항목으로 구성되는 경우가 많습니다.
- 고객 관계 관리(CRM) 데이터베이스와 같은 다양한 데이터 소스의 원시 데이터를 수집하는 데이터 파이프라인
- 데이터 웨어하우스에 저장된 데이터
- 데이터를 조작하고 추가 처리 및 분석하는 스크립트 및 절차
- 데이터를 읽거나 데이터와 상호작용하는 비즈니스 애플리케이션
- 워크로드
- 연결된 상태이고 종속 항목을 공유하는 사용 사례 집합입니다. 예를 들어 사용 사례에는 다음과 같은 관계와 종속 항목이 있을 수 있습니다.
- 구매 보고는 단독으로 실행될 수 있으며 지출을 확인하고 할인을 요청하는 데 유용합니다.
- 판매 보고는 단독으로 실행될 수 있으며 마케팅 캠페인 계획에 유용합니다.
- 그러나 손익 보고는 구매 및 판매에 의존하며 회사의 가치를 결정하는 데 유용합니다.
- 비즈니스 애플리케이션
- 최종 사용자가 상호작용하는 시스템입니다(예: 시각적 보고서나 대시보드). 비즈니스 애플리케이션은 운영 데이터 파이프라인 또는 피드백 루프의 형태를 취할 수도 있습니다. 예를 들어 제품 가격 변동 계산 또는 예측이 완료된 후 운영 데이터 파이프라인이 트랜잭션 데이터베이스에서 새 제품 가격을 업데이트할 수 있습니다.
- 업스트림 프로세스
- 데이터 웨어하우스에 데이터를 로드하는 소스 시스템과 데이터 파이프라인입니다.
- 다운스트림 프로세스
- 데이터 웨어하우스의 데이터를 처리, 쿼리, 시각화하는 데 사용되는 스크립트, 절차, 비즈니스 애플리케이션입니다.
- 오프로드 마이그레이션
-
새 환경에서 최종 사용자에게 사용 사례의 효과가 최대한 빨리 나타나게 하거나 새 환경에서 사용 가능한 추가 용량을 활용하는 것을 목표로 하는 마이그레이션 전략입니다. 다음을 수행하면 사용 사례가 오프로드됩니다.
- 기존 데이터 웨어하우스의 스키마와 데이터를 복사한 후 동기화
- 다운스트림 스크립트, 절차, 비즈니스 애플리케이션 마이그레이션
마이그레이션 오프로드는 데이터 파이프라인 마이그레이션과 관련된 복잡성과 작업을 증가시킬 수 있습니다.
- 전체 마이그레이션
- 오프로드 마이그레이션과 유사하지만 스키마와 데이터를 복사한 후 동기화하는 대신 업스트림 소스 시스템에서 새 클라우드 데이터 웨어하우스로 직접 데이터를 수집하도록 구성하는 마이그레이션 방식입니다. 즉, 사용 사례에 필요한 데이터 파이프라인도 마이그레이션됩니다.
- 엔터프라이즈 데이터 웨어하우스(EDW)
- 분석 데이터베이스뿐 아니라 여러 중요한 분석 구성요소와 절차로 구성된 데이터 웨어하우스입니다. 여기에는 조직의 워크로드를 처리하는 데 필요한 데이터 파이프라인, 쿼리 및 비즈니스 애플리케이션이 포함됩니다.
- 클라우드 데이터 웨어하우스(CDW)
- 특성은 EDW와 동일하지만 클라우드의 완전 관리형 서비스(이 경우 BigQuery)에서 실행되는 데이터 웨어하우스입니다.
- 데이터 파이프라인
- 다양한 유형의 데이터 변환을 수행하는 일련의 함수와 작업을 통해 데이터 시스템을 연결하는 프로세스입니다. 자세한 내용은 이 시리즈의 데이터 파이프라인이란?을 참조하세요.
BigQuery로 마이그레이션해야 하는 이유
지난 수십 년 동안 조직들은 데이터 웨어하우징 기술에 거의 통달했으며, 핵심 비즈니스 운영에 대한 통찰력을 얻기 위해 저장된 대량의 데이터에 설명적인 분석 기술을 점점 더 많이 적용하고 있습니다. 쿼리, 보고, 온라인 분석 처리에 중점을 둔 기존의 비즈니스 인텔리전스(BI)는 과거에 회사를 만들거나 없앨 수도 있는 차별화 요소였을지 모르지만, 이제는 이것만으로 충분하지 않습니다.
오늘날 조직은 과거의 이벤트를 이해하기 위한 설명적 분석 기술만 필요한 것이 아니라, 데이터 패턴을 추출하고 미래에 대한 개연성을 주장하기 위해 ML(머신러닝)이 자주 사용되는 예측적 분석 기술도 필요합니다. 궁극적인 목표는 과거의 교훈과 미래 예측을 통합하여 실시간으로 작업을 자동 안내할 수 있는 처방적 분석 기술을 개발하는 것입니다.
기존의 데이터 웨어하우스 방식에서는 주로 온라인 트랜잭션 처리(OLTP) 시스템을 사용해서 여러 소스로부터 원시 데이터를 캡처합니다. 그런 후 일괄적으로 데이터 하위 집합을 추출하고, 정의된 스키마에 따라 변환하고, 데이터 웨어하우스에 로드합니다. 기존의 데이터 웨어하우스는 데이터의 하위 집합을 일괄적으로 캡처하고 엄격한 스키마를 기반으로 데이터를 저장하기 때문에 실시간 분석을 처리하거나 자발적 쿼리에 응답하기에 적합하지 않습니다. Google은 이러한 내재적인 한계에 대응하기 위한 한 가지 방편으로 BigQuery를 설계했습니다.
혁신적인 생각은 종종 이러한 기존의 데이터 웨어하우스를 구현하고 유지하는 IT 조직의 크기와 복잡성에 의해 방해될 수 있습니다. 확장성, 고도의 가용성, 보안성이 뛰어난 데이터 웨어하우스 아키텍처를 구축하기 위해서는 수년의 시간과 상당한 투자가 필요할 수 있습니다. BigQuery는 서버리스 데이터 웨어하우스 작업에 사용할 수 있는 정교한 Software as a service(SaaS) 기술을 제공합니다. 따라서 인프라 유지보수 및 플랫폼 개발을 Google Cloud에 맡기고 핵심 비즈니스를 발전시키는 데 집중할 수 있습니다.
BigQuery는 확장 가능하고 유연하며 경제적인 구조화된 데이터 스토리지, 처리, 분석에 대한 액세스를 제공합니다. 이러한 특성은 데이터 볼륨이 기하급수적으로 증가할 때 스토리지 및 처리 리소스를 필요에 따라 사용 가능하게 하고 해당 데이터로 가치를 창출하려는 경우에 필수적입니다. 또한 BigQuery는 빅데이터 분석 및 머신러닝을 이제 막 시작했으며 온프레미스 빅데이터 시스템의 잠재적 복잡성을 배제하려는 조직에서 관리형 서비스로 실험하며 사용한 만큼만 지불할 수 있게 해줍니다.
BigQuery를 사용하면 이전에는 해결할 수 없던 문제에 대한 해답을 찾아내고, 머신러닝을 적용해서 새로운 데이터 패턴을 검색하고, 새로운 가정을 테스트할 수 있습니다. 따라서 비즈니스 수행 방식에 대한 통찰력을 적시에 확보하고 더 나은 결과를 위해 프로세스를 수정할 수 있게 되었습니다. 또한 빅데이터 분석으로 얻은 관련 정보로 최종 사용자의 업무 환경도 개선되었습니다. 이 내용은 이 시리즈의 후반부에서 설명합니다.
마이그레이션 대상과 방법: 마이그레이션 프레임워크
마이그레이션은 복잡하고 오랜 시간이 걸릴 수 있습니다. 따라서 프레임워크를 준수하여 마이그레이션 작업을 단계적으로 구성하고 구조화하는 것이 좋습니다.
- 준비 및 탐색: 워크로드 및 사용 사례 탐색을 통해 마이그레이션을 준비합니다.
- 계획: 사용 사례의 우선순위를 지정하고 성공의 척도를 정의하고 마이그레이션을 계획합니다.
- 실행: 평가부터 검증까지 마이그레이션 단계를 반복합니다.
준비 및 탐색
초기 단계에서는 준비와 탐색에 중점을 둡니다. 사용자와 이해관계자가 기존의 사용 사례를 탐색하고 초기 우려 사항을 제기할 수 있는 기회를 제공합니다. 또한 예상되는 이점에 대한 초기 분석을 수행해야 합니다. 여기에는 성능 향상(예: 향상된 동시 실행) 및 총 소유 비용(TCO) 감소가 포함됩니다. 이 단계는 마이그레이션의 가치를 확립하는 데 중요한 역할을 합니다.
일반적으로 데이터 웨어하우스는 광범위한 사용 사례를 지원하며 데이터 분석가부터 비즈니스 의사 결정권자까지 다양한 이해관계자를 지원합니다. 이러한 그룹의 대표를 참여시켜 어떤 사용 사례가 있는지, 이러한 사용 사례의 실적이 우수한지, 이해관계자가 새로운 사용 사례를 계획 중인지 여부를 파악하는 것이 좋습니다.
탐색 단계 프로세스는 다음 작업으로 구성됩니다.
- BigQuery의 가치 제안을 살펴보고 기존 데이터 웨어하우스의 가치와 비교합니다.
- 초기 TCO 분석을 수행합니다.
- 마이그레이션의 영향을 받는 사용 사례를 확인합니다.
- 종속 항목을 식별하기 위해 마이그레이션할 기본 데이터 세트와 데이터 파이프라인의 특성을 모델링합니다.
사용 사례에 대한 유용한 정보를 얻으려면 설문지를 만들어 주제 전문가(SME), 최종 사용자, 이해관계자로부터 정보를 수집하면 됩니다. 설문지에는 다음과 같은 정보를 묻는 질문이 포함되어야 합니다.
- 사용 사례의 목표는 무엇인가요? 비즈니스 가치는 무엇인가요?
- 비기능적 요구사항은 무엇인가요? (데이터 업데이트, 동시 사용 등)
- 사용 사례가 더 큰 워크로드의 일부인가요? 다른 사용 사례에 종속되나요?
- 사용 사례의 토대가 되는 데이터 세트, 테이블, 스키마는 무엇인가요?
- 이러한 데이터 세트에 데이터 파이프라인을 피드하는 방법에 대해 알고 계신가요?
- 현재 어떤 BI 도구, 보고서, 대시보드를 사용하고 있나요?
- 운영 요구사항, 성능, 인증, 네트워크 대역폭과 관련된 현재 기술 요구사항은 무엇인가요?
다음 다이어그램은 마이그레이션하기 전 기존 아키텍처를 대략적으로 보여줍니다. 사용 가능한 데이터 소스, 기존 데이터 파이프라인, 이전 운영 파이프라인 및 피드백 루프, 최종 사용자가 액세스하는 기존 BI 보고서 및 대시보드의 카탈로그를 보여줍니다.
계획
계획 단계는 준비 및 탐색 단계에서 의견을 받고 평가하여 마이그레이션을 계획하는 단계입니다. 이 단계는 다음 작업으로 나눌 수 있습니다.
사용 사례 카탈로그 작성 및 우선순위 지정
마이그레이션 프로세스를 여러 반복 작업으로 나누는 것이 좋습니다. 기존 사용 사례와 새로운 사용 사례를 모두 카탈로그로 작성하고 우선순위를 지정합니다. 자세한 내용은 이 문서의 반복적인 접근법을 사용한 마이그레이션 및 사용 사례 우선순위 지정 섹션을 참조하세요.
성공의 척도 정의
마이그레이션하기 전에 핵심성과지표(KPI)와 같은 명확한 성공의 척도를 정의하면 유용합니다. 이러한 척도를 사용하면 각 반복 작업에서 마이그레이션의 성공 여부를 평가할 수 있습니다. 그러면 이후 반복 작업에서 마이그레이션 프로세스를 개선할 수 있습니다.
'완료'의 정의 만들기
복잡한 마이그레이션의 경우 특정 사용 사례의 마이그레이션을 완료한 시기를 반드시 확실히 알 수 있는 것은 아닙니다. 따라서 원하는 최종 상태의 공식적인 정의를 약술해야 합니다. 이 정의는 마이그레이션하려는 모든 사용 사례에 적용될 수 있을 정도로 일반적이어야 합니다. 이 정의는 사용 사례가 완전히 마이그레이션된 것으로 간주할 수 있는 최소 기준 집합 역할을 해야 합니다. 일반적으로 이 정의에는 사용 사례가 통합, 테스트, 문서화되었는지 확인하는 데 사용되는 체크포인트가 포함됩니다.
개념 증명(POC), 단기 상태, 이상적인 최종 상태 설계 및 제안
사용 사례의 우선순위를 정한 후 전체 마이그레이션 기간 동안 사용 사례를 생각할 수 있습니다. 첫 번째 사용 사례 마이그레이션은 초기 마이그레이션 접근법의 유효성을 검증하기 위한 개념 증명(PoC)으로 간주합니다. 처음 몇 주에서 몇 달 사이에 달성할 수 있는 것은 단기 상태로 간주하세요. 마이그레이션 계획이 사용자에게 어떤 영향을 줄까요? 사용자가 하이브리드 솔루션을 보유하게 되거나 일부 User First 하위 집합을 위해 전체 워크로드를 마이그레이션할 수 있나요?
예상 시간 및 비용 계산
프로젝트를 성공적으로 마이그레이션하려면 예상 시간을 현실적으로 예측하는 것이 중요합니다. 이를 위해 모든 관련 이해관계자와 협력하여 참석 여부를 논의하고 프로젝트 전반에 대한 참여 수준에 합의합니다. 이렇게 하면 인건비를 더 정확하게 산출하는 데 도움이 됩니다. 예상 클라우드 리소스 소비량과 관련된 비용을 산출하려면 BigQuery 문서의 스토리지 및 쿼리 비용 산출과 BigQuery 비용 관리 소개를 참조하세요.
마이그레이션 파트너 식별 및 참여 유도
BigQuery 문서에서는 마이그레이션을 수행하는 데 사용할 수 있는 다양한 도구와 리소스를 설명합니다. 그러나 사전 경험이 없거나 조직 내에서 필요한 전문 기술을 보유하지 않은 경우 복잡한 대규모 마이그레이션을 직접 수행하는 것은 어려울 수 있습니다. 따라서 처음부터 마이그레이션 파트너를 식별하고 참여시키는 것이 좋습니다. 자세한 내용은 글로벌 파트너 및 컨설팅 서비스 프로그램을 참조하세요.
반복적인 접근법을 사용한 마이그레이션
대규모 데이터 웨어하우징 작업을 클라우드로 마이그레이션할 때는 반복적인 접근법을 사용하는 것이 좋습니다. 따라서 반복 작업을 통해 BigQuery로 전환하는 것이 좋습니다. 마이그레이션 작업을 반복 작업으로 나누면 전체 프로세스가 더 쉬워지고 위험이 줄어들며 매 반복 작업 후 학습 및 개선 기회를 얻을 수 있습니다.
iteration 작업은 하나 이상의 관련 사용 사례를 일정 기간 내에 오프로드하거나 완전히 마이그레이션하는 데 필요한 모든 작업으로 구성됩니다. 반복 작업을 애자일 방법론에 비유하면 하나 이상의 사용자 스토리로 구성된 스프린트 사이클과 같습니다.
편의성과 추적 용이성을 고려하여 개별 사용 사례를 하나 이상의 사용자 스토리와 연결하는 방법을 고려할 수 있습니다. 다음 사용자 스토리를 예로 들어 보겠습니다. 가격 분석가가 '미래 가격을 계산하기 위해 전년도 제품 가격 변동을 분석하고자 합니다'라고 말했습니다.
해당 사용 사례는 다음과 같습니다.
- 제품과 가격을 저장하는 트랜잭션 데이터베이스에서 데이터 수집
- 데이터를 각 제품의 단일 시계열로 변환하고 누락된 값 입력
- 데이터 웨어하우스에서 하나 이상의 테이블에 결과 저장
- Python 메모장(비즈니스 애플리케이션)을 통해 결과 제공
이 사용 사례의 비즈니스 가치는 가격 분석을 지원하는 것입니다.
대부분의 사용 사례와 마찬가지로 이 사용 사례는 여러 사용자 스토리를 지원할 것입니다.
오프로드된 사용 사례 다음에 이어지는 반복 작업으로 사용 사례가 완전히 마이그레이션될 수 있습니다. 그렇지 않으면 데이터가 복사된 기존의 레거시 데이터 웨어하우스에 계속 종속될 수 있습니다. 오프로드가 선행된 전체 마이그레이션은 오프로드 마이그레이션과 오프로드가 선행되지 않은 전체 마이그레이션 사이의 델타입니다. 즉, 데이터를 추출, 변환하고 데이터 웨어하우스에 로드하는 데이터 파이프라인 마이그레이션입니다.
사용 사례 우선순위 지정
이전을 시작하고 종료하는 시점은 특정 비즈니스 요구에 따라 달라집니다. 클라우드 도입 경로를 계속 유지하려면 마이그레이션 중 조기 성공이 중요하므로 사용 사례를 마이그레이션하는 순서를 결정하는 것이 중요합니다. 초기 단계에서 장애가 발생하면 전체 마이그레이션 작업에 심각한 지장을 줄 수 있습니다. Google Cloud와 BigQuery의 이점을 누릴 수도 있지만, 각기 다른 사용 사례에 대해 기존 데이터 웨어하우스에서 생성되거나 관리된 데이터 세트와 데이터 파이프라인을 모두 처리하는 작업은 복잡하고 시간이 오래 걸릴 수 있습니다.
모든 상황을 충족하는 단일 해결책은 없지만 온프레미스 사용 사례 및 비즈니스 애플리케이션을 평가할 때 사용할 수 있는 권장사항은 있습니다. 이러한 사전 계획을 통해 마이그레이션 프로세스를 간소화하고 BigQuery로의 전체 전환을 더 원활하게 수행할 수 있습니다.
다음 섹션에서는 사용 사례의 우선순위를 정하는 데 사용할 수 있는 방법을 살펴봅니다.
접근법: 현재 기회 활용
특정 사용 사례에 대한 투자수익을 극대화할 수 있는 현재 기회를 확인하세요. 이 접근법은 클라우드로 마이그레이션할 경우의 비즈니스 가치를 정당화해야 할 때 특히 유용합니다. 또한 총 마이그레이션 비용을 평가하는 데 도움이 되는 추가 데이터 포인트를 수집할 기회를 제공합니다.
다음은 우선순위를 지정할 사용 사례를 파악하는 데 도움이 되는 몇 가지 질문의 예시입니다.
- 현재 레거시 엔터프라이즈 데이터 웨어하우스에 의해 제한되는 데이터 세트나 데이터 파이프라인이 사용 사례에 포함되나요?
- 기존 엔터프라이즈 데이터 웨어하우스에 하드웨어 교체가 필요한가요? 아니면 하드웨어를 확장해야 할 필요가 있다고 예상되나요? 그렇다면 차라리 일찌감치 사용 사례를 BigQuery에 오프로드하는 것이 좋습니다.
마이그레이션 기회를 파악하면 사용자와 비즈니스에 실질적이고 즉각적인 이점을 제공하는 몇 가지 단기 성과를 얻을 수 있습니다.
접근법: 분석 워크로드를 먼저 마이그레이션
온라인 분석 처리(OLAP) 워크로드를 온라인 트랜잭션 처리(OLTP) 워크로드보다 먼저 마이그레이션합니다. 데이터 웨어하우스는 조직의 모든 작업을 전체적으로 한눈에 볼 수 있는 유일한 데이터 저장소인 경우가 많습니다. 따라서 조직은 트랜잭션 시스템에 다시 피드되어 상태를 업데이트하거나 프로세스를 트리거하는 데이터 파이프라인이 있는 경우가 많습니다(예: 제품 재고가 부족할 때 추가 재고를 구매하는 경우). OLTP 워크로드는 OLAP 워크로드보다 복잡하고 운영 요구사항 및 서비스수준계약(SLA)이 엄격한 편이므로 OLAP 워크로드를 먼저 마이그레이션하면 더 수월합니다.
접근법: 사용자 환경에 집중
특정 데이터세트를 마이그레이션하고 새로운 유형의 고급 분석을 사용 설정하여 사용자 환경을 개선할 기회를 찾으세요. 예를 들어 실시간 분석을 통해 사용자 환경을 개선할 수 있습니다. 실시간 데이터 스트림을 이전 데이터와 통합하면 실시간 데이터 스트림을 중심으로 정교한 사용자 환경을 구축할 수 있습니다. 예를 들면 다음과 같습니다.
- 백오피스 직원의 모바일 앱에 재고 부족 알림 표시
- 온라인 고객에게 1달러를 더 지출하면 다음 리워드 등급에 도달한다는 유용한 정보를 제공
- 환자의 스마트시계에 표시된 이상 신호를 간호사에게 알리거나, 환자의 치료 기록을 태블릿에 표시해서 최상의 치료 방법 제시
예측 및 처방적 분석을 통해 사용자 환경을 개선할 수도 있습니다. 이를 위해 BigQuery ML, Vertex AI AutoML 테이블 형식 또는 Google의 선행 학습된 모델을 사용하여 이미지 분석, 동영상 분석, 음성 인식, 자연어, 번역을 수행할 수 있습니다. 또는 비즈니스 요구사항에 맞는 사용 사례에 Vertex AI를 사용하여 커스텀 학습 모델을 제공할 수 있습니다. 여기에는 다음 항목이 포함될 수 있습니다.
- 마켓 트렌드 및 사용자 구매 행동을 기반으로 제품 추천
- 비행 지연 시간 예측
- 사기 활동 감지
- 부적절한 콘텐츠 신고
- 자신의 앱을 경쟁 제품과 차별화할 수 있는 기타 혁신적인 아이디어
접근법: 가장 위험성이 낮은 사용 사례에 우선순위 지정
IT 부서에서 마이그레이션 위험이 가장 낮아서 마이그레이션 초기 단계에서 마이그레이션하면 가장 좋은 사용 사례를 평가할 때 유용한 여러 가지 질문이 있습니다. 예를 들면 다음과 같습니다.
- 이 사용 사례의 비즈니스 중요도는 어느 정도인가요?
- 다수의 직원이나 고객이 이 사용 사례에 의존하나요?
- 사용 사례의 대상 환경(예: 개발 또는 프로덕션)은 무엇인가요?
- IT 팀의 사용 사례에 대한 이해도는 어떤가요?
- 사용 사례의 종속 항목과 통합은 얼마나 되나요?
- IT 팀이 사용 사례에 대한 적절한 최신 문서를 보유하고 있나요?
- 사용 사례의 운영 요구사항(SLA)은 무엇인가요?
- 사용 사례에 대한 법적 또는 정부 규정 준수 요구사항은 무엇인가요?
- 기본 데이터 세트에 액세스하는 경우의 다운타임 및 지연 시간 민감도는 무엇인가요?
- 초기에 사용 사례를 마이그레이션하기를 열망하는 비즈니스 계열 대표가 있나요?
이 질문 목록을 살펴보면 데이터 세트와 데이터 파이프라인에 위험 순위를 매길 수 있습니다. 위험성이 낮은 애셋을 먼저 마이그레이션하고 위험성이 높은 애셋은 나중에 마이그레이션해야 합니다.
실행
레거시 시스템에 대한 정보를 수집하고 우선순위가 지정된 사용 사례 백로그를 만든 후에는 사용 사례를 워크로드로 그룹화하고 반복 작업으로 마이그레이션을 진행할 수 있습니다.
반복 작업은 단일 사용 사례, 몇 가지 개별 사용 사례 또는 단일 워크로드와 관련된 여러 사용 사례로 구성될 수 있습니다. 반복 작업에 선택하는 이러한 옵션은 사용 사례의 상호 연관성, 공통된 종속 항목, 작업을 수행하는 데 사용할 수 있는 리소스에 따라 다릅니다.
일반적으로 마이그레이션에는 다음 단계가 포함됩니다.
이러한 단계에 대해서는 다음 섹션에서 더 자세히 설명합니다. 각 반복 작업에서 이러한 단계를 모두 수행하지 않아도 됩니다. 예를 들어 한 반복 작업에서는 레거시 데이터 웨어하우스의 일부 데이터를 BigQuery로 복사하는 데 집중하고 다음 반복 작업에서는 원래 데이터 소스의 수집 파이프라인을 직접 BigQuery로 수정하는 데 집중할 수 있습니다.
1. 설정 및 데이터 거버넌스
설정은 Google Cloud에서 사용 사례를 실행하는 데 필요한 기본 작업입니다. 설정에는 Google Cloud 프로젝트, 네트워크, Virtual Private Cloud(VPC), 데이터 거버넌스 구성이 포함될 수 있습니다. 또한 현재 상황과 효과적인 것과 그렇지 않은 것을 면밀히 파악하는 것이 포함됩니다. 이를 통해 마이그레이션 작업에 필요한 요구사항을 이해하는 데 도움이 됩니다. BigQuery 마이그레이션 평가 기능을 사용하면 이 단계에 도움이 됩니다.
데이터 거버넌스는 수집에서 사용, 폐기에 이르는 수명 주기 동안 데이터를 관리하는 데 사용되는 원칙적인 접근법입니다. 데이터 거버넌스 프로그램은 데이터 활동을 둘러싼 정책, 절차, 책임, 제어를 명확하게 설명합니다. 이 프로그램은 조직의 데이터 무결성 및 보안 요구사항을 모두 충족하는 방식으로 정보를 수집, 유지 관리, 사용, 배포하는 데 도움이 되고 직원이 데이터를 발견하고 최대한 활용하는 데도 도움이 됩니다.
데이터 거버넌스 문서는 온프레미스 데이터 웨어하우스를 BigQuery로 마이그레이션할 때 필요한 데이터 거버넌스 및 제어를 이해하는 데 도움이 됩니다.
2. 스키마 및 데이터 마이그레이션
데이터 웨어하우스 스키마는 데이터를 구조화하는 방법을 정의하고 데이터 항목 간의 관계를 정의합니다. 스키마는 데이터 설계의 핵심이며 업스트림 및 다운스트림의 여러 프로세스에 영향을 미칩니다.
스키마 및 데이터 전송 문서는 BigQuery로 데이터를 이전하는 방법에 대한 자세한 정보와 BigQuery의 기능을 최대한 활용하도록 스키마를 업데이트할 때의 권장사항을 제공합니다.
3. 쿼리 번역
일괄 SQL 변환을 사용하여 SQL 코드를 일괄적으로 마이그레이션하거나 대화형 SQL 변환을 사용하여 임시 쿼리를 변환합니다.
일부 레거시 데이터 웨어하우스에는 제품의 기능을 사용할 수 있게 SQL 표준에 대한 확장 프로그램이 포함됩니다. BigQuery는 이러한 독점 확장 프로그램을 지원하지 않으며 대신 ANSI/ISO SQL:2011 표준을 준수합니다. 즉, SQL 변환기가 해석하지 못하는 일부 쿼리는 여전히 수동 리팩터링이 필요할 수 있습니다.
4. 비즈니스 애플리케이션 마이그레이션
비즈니스 애플리케이션은 대시보드부터 커스텀 애플리케이션, 트랜잭션 시스템에 피드백 루프를 제공하는 운영 데이터 파이프라인까지 다양한 형태를 취할 수 있습니다.
BigQuery로 작업할 때 분석 옵션에 대한 자세한 내용은 BigQuery 분석 개요를 참조하세요. 이 주제에서는 데이터에서 유용한 정보를 얻는 데 사용할 수 있는 보고 도구와 분석 도구를 간략하게 설명합니다.
데이터 파이프라인 문서의 피드백 루프 섹션에서는 데이터 파이프라인을 사용하여 업스트림 시스템을 프로비저닝하는 피드백 루프를 만드는 방법을 설명합니다.
5. 데이터 파이프라인 마이그레이션
데이터 파이프라인 문서에는 레거시 데이터 파이프라인을 Google Cloud로 마이그레이션하기 위한 절차, 패턴, 기술이 나와 있습니다. 데이터 파이프라인이 무엇인지, 어떤 절차와 패턴을 사용할 수 있는지, 더 큰 데이터 웨어하우스 마이그레이션과 관련하여 사용 가능한 마이그레이션 옵션 및 기술은 무엇인지 이해하는 데 도움이 됩니다.
6. 성능 최적화
BigQuery는 작은 데이터세트부터 페타바이트 규모의 데이터세트까지 모두 효율적으로 처리합니다. BigQuery를 사용하면 새로 마이그레이션된 데이터 웨어하우스에서 수정 작업 없이도 데이터 분석 작업을 원활하게 수행할 수 있습니다. 특정한 상황에서 쿼리 성능이 기대에 부합하지 않으면 자세한 내용은 쿼리 성능 최적화 소개를 참조하세요.
7. 확인 및 검증
반복 작업이 끝날 때마다 다음 사항을 확인하여 사용 사례 마이그레이션이 성공했는지 확인합니다.
- 데이터 및 스키마가 완전히 마이그레이션되었습니다.
- 데이터 거버넌스 우려사항이 완전히 해소되고 테스트되었습니다.
- 유지보수 및 모니터링 절차와 자동화가 수립되었습니다.
- 쿼리가 올바르게 번역되었습니다.
- 마이그레이션된 데이터 파이프라인이 예상대로 작동합니다.
- 비즈니스 애플리케이션이 마이그레이션된 데이터 및 쿼리에 액세스하도록 올바르게 구성되었습니다.
소스 환경과 대상 환경의 데이터를 비교하여 일치 여부를 확인하는 오픈소스 Python CLI 도구인 데이터 검증 도구로 작업을 시작할 수 있습니다. 이 도구는 다중 수준 유효성 검사 기능과 함께 여러 연결 유형을 지원합니다.
예를 들어 성능 개선, 비용 절감, 새로운 기술 또는 비즈니스 기회 제공과 같은 측면에서 사용 사례 마이그레이션의 영향을 측정하는 것도 좋습니다. 그러면 투자수익의 가치를 더 정확하게 정량화하고 반복의 성공 기준과 비교할 수 있습니다.
반복 작업이 검증된 후에는 마이그레이션된 사용 사례를 프로덕션 환경으로 릴리스하고 사용자에게 마이그레이션된 데이터 세트 및 비즈니스 애플리케이션에 대한 액세스 권한을 부여할 수 있습니다.
마지막으로 이 반복 작업에서 얻은 교훈을 메모하고 문서화하면 다음 반복 작업에서 이러한 교훈을 반영하고 마이그레이션을 가속화할 수 있습니다.
마이그레이션 작업 요약
마이그레이션 중에 이 문서에 설명된 대로 레거시 데이터 웨어하우스와 BigQuery를 모두 실행합니다. 다음 다이어그램의 참조 아키텍처는 두 데이터 웨어하우스 모두 소스 시스템에서 데이터를 수집하며, 비즈니스 애플리케이션과 통합되고, 필요한 사용자 액세스 권한을 제공하는 등 둘 다 유사한 기능과 경로를 제공할 수 있음을 강조합니다. 중요한 점은 데이터 웨어하우스에서 BigQuery로 데이터가 동기화된다는 점입니다. 따라서 마이그레이션 작업이 진행되는 동안 계속 사용 사례가 오프로드될 수 있습니다.
데이터 웨어하우스에서 BigQuery로 완전히 마이그레이션하려는 경우 마이그레이션의 최종 상태는 다음과 같습니다.
다음 단계
데이터 웨어하우스 마이그레이션의 다음 단계를 자세히 알아보세요.
특정 데이터 웨어하우스 기술에서 BigQuery로 이전하는 방법도 알아볼 수 있습니다.