1단계: 계획 및 설계¶

이 첫 단계는 성공적인 마이그레이션을 위해 매우 중요합니다. 프로젝트의 범위, 목표 및 요구 사항을 정의하여 토대를 마련합니다. 현재 Databricks 환경을 심층적으로 이해하고 Snowflake에서 향후 달성하고자 하는 명확한 비전을 수립해야 합니다.

2단계: 환경 및 보안¶

마이그레이션을 시작하기 전에 필요한 환경 및 보안 조치를 설정하는 것은 중요한 초기 단계입니다. Snowflake는 플랫폼과 관리자 간의 공유 보안 모델에 따라 운영됩니다.

실행 가능한 단계:

• 환경 설정: 필요한 Snowflake 계정 수를 결정합니다. 최소한 프로덕션 및 개발 환경을 설정해야 합니다. 전략에 따라 다양한 테스트 스테이지를 위한 추가 환경을 고려합니다.

• 보안 조치 구현:

  • VPN 내에서 승인된 사용자만 Snowflake 시스템에 액세스할 수 있도록 하는 네트워크 정책부터 시작합니다.

  • Snowflake의 사용자 액세스 제어는 역할 기반이므로, 비즈니스 요구 사항에 따라 역할을 정의합니다.

  • 사용자 계정을 만들고 모든 사용자에게 다단계 인증(MFA) 또는 Single Sign-On(SSO)을 적용합니다.

  • 기존 사용자 이름 및 비밀번호 인증을 사용하지 않고 서비스 계정을 설정합니다.

• 마이그레이션 중 역할 정의: 마이그레이션 팀의 구체적인 역할을 정의합니다. 팀이 더 자유롭게 작업할 수 있는 비프로덕션 환경에서도 실제 데이터를 처리해야 하므로 강력한 보안을 유지해야 합니다.

• 액세스 모델 재검토: 이 마이그레이션을 통해 액세스 계층 구조를 정리하고 최적화하여 필요한 사용자만 특정 리소스에 액세스할 수 있도록 합니다.

• 재무 부서와 협력: 재무 부서와 협력하여 Snowflake의 소비 기반 가격 모델과 비용 할당을 위한 오브젝트 태깅을 활용하여 부서별 Snowflake 사용량을 추적합니다.

3단계: 데이터베이스 코드 변환¶

이 단계에서는 Databricks 데이터베이스 코드(DDL, SQL, Spark 코드)를 Snowflake 호환 SQL 및 Snowpark로 변환하는 데 중점을 둡니다.

실행 가능한 단계:

• Databricks Spark 데이터 타입을 Snowflake 데이터 타입으로 매핑:

  • Databricks(Spark) 데이터 타입을 꼼꼼하게 식별하고 가장 적절한 Snowflake 데이터 타입으로 매핑합니다. 복잡한 유형에 대한 정밀도, 규모, 타임존 처리에 세심한 주의를 기울입니다(예: TimestampType을 TIMESTAMP_NTZ, TIMESTAMP_LTZ, TIMESTAMP_TZ로 매핑).

  • ByteType이 Snowflake의 INTEGER로 매핑되고, LongType(64비트)이 INTEGER(32비트)로 매핑되는 경우 잘림을 방지하기 위해 범위 검사가 필요할 수 있습니다.

  • ArrayType 및 MapType은 일반적으로 Snowflake의 VARIANT 데이터 타입으로 매핑됩니다.

• 테이블 및 뷰에 대한 데이터 정의 언어(DDL) 변환:

  • Databricks 환경(일반적으로 Delta Lake 테이블)에서 기존 DDL 스크립트를 추출합니다.

  • 추출된 DDL을 Snowflake의 SQL 언어와 완벽하게 호환되도록 조정하고, Databricks 관련 기능(예: Delta Lake 테이블 속성, 클러스터링 키 이외의 특정 파티셔닝 스키마)을 제거하거나 재설계합니다.

  • 더 효과적인 논리적 분리 및 액세스 제어를 위해 대규모 스키마를 여러 Snowflake 데이터베이스 또는 스키마로 분할하는 등 스키마를 재구성할 기회를 고려합니다.

• Databricks SQL 및 Spark 코드를 Snowflake SQL 및 Snowpark로 변환:

  • Databricks SQL을 Snowflake SQL로 변환: 이제 Snowconvert AI는 TABLES 및 VIEWS에 대한 Spark SQL 및 Databricks SQL 평가와 변환을 지원합니다.

  • Spark 코드(PySpark 및 Scala)를 Snowpark로 변환: Databricks 노트북 및 작업의 PySpark 또는 Scala 코드를 Snowflake의 Snowpark API(Python, Java, Scala)로 변환합니다. Snowpark DataFrames는 Spark DataFrames와 유사한 기능(filter, select, join, groupBy, agg)을 제공하며, 처리 논리를 Snowflake 내의 데이터에 직접 가져오는 것을 목표로 합니다.

  • 사용자 정의 함수(UDFs): Databricks UDFs(Python, Scala)를 Snowflake UDFs(SQL, JavaScript, Python, Java, Scala)로 다시 구현합니다. 복잡한 Spark UDFs의 경우 Snowpark를 효과적으로 활용하기 위해 상당한 재설계가 필요할 수 있습니다.

  • 오케스트레이션 논리: 증분 변환 및 예약을 위해 Streams 및 Tasks와 같은 네이티브 기능을 사용하여 Snowflake에서 Databricks 작업, 워크플로, Delta Live Tables(DLT) 오케스트레이션 논리를 재설계하고 재구현합니다. 또는 외부 오케스트레이터(예: Airflow)를 Snowflake로 다시 지정하여 임베드된 Databricks 관련 코드를 다시 작성합니다.

4단계: 데이터 마이그레이션¶

데이터 마이그레이션은 Databricks 환경에서 Snowflake로 기존 데이터 세트를 전송하는 프로세스입니다. 이 단계에는 일반적으로 과거 대량 데이터 전송과 지속적인 증분 데이터 수집이 모두 이루어집니다.

실행 가능한 단계:

• Databricks에서 데이터 추출:

  • Delta Lake 테이블의 경우 Snowflake가 직접 읽을 수 있는 기본 Parquet 데이터 파일을 가리키는 Apache Spark를 사용하여 매니페스트 파일을 생성합니다.

  • 큰 테이블의 경우 효율적인 병렬 처리를 위해 데이터 내보내기를 분할합니다.

  • Databricks의 네이티브 Snowflake Connector를 활용하여 Databricks에서 데이터를 직접 읽어와 클라우드 저장소(예: AWS S3, Azure Blob Storage)에 Snowflake의 스테이징 영역으로 작성합니다.

  • 수집 시간에 대한 타임스탬프 열과 소스 시스템 이름 열을 추가하여 Snowflake에서 계보와 제어를 유지합니다.

• Snowflake에 데이터 로드:

  • Snowflake의 COPY INTO 명령을 사용하여 외부 스테이지(클라우드 저장소 위치)에서 Snowflake 테이블로 데이터를 대량 로드합니다.

  • Parquet 파일의 성능을 최적화하려면 Snowflake의 벡터화된 스캐너를 사용합니다(COPY 명령에 USE_VECTORIZED_SCANNER를 설정하거나 향후 기본값으로 설정).

  • 로드 모범 사례:

    • 파일 크기 최적화: 최적의 처리량을 위해 파일을 압축하여 100~250MB 범위의 파일을 생성합니다(예: Parquet용 Snappy).

    • 스테이징된 파일 제거: 로드에 성공한 후 COPY 명령에서 PURGE=TRUE를 사용하여 스테이지에서 파일을 제거하면 성능을 최적화하고 저장소 비용을 관리할 수 있습니다.

    • 오류 처리: 잠재적인 불량 데이터가 있는 대용량 파일의 경우 COPY 명령에서 ON_ERROR=’CONTINUE’를 사용하면 문제가 있는 행을 무시하면서 양호한 데이터를 로드할 수 있습니다.

    • 내부 스테이지: 외부 스테이지에 비해 로딩 속도를 높이려면 Snowflake의 내부 스테이지를 사용하는 것이 좋지만, 저장소 비용을 비교해야 합니다.

  • 증분 데이터 로딩의 경우 변경 데이터 캡처(CDC) 파이프라인을 구현하여 Databricks에서 Snowflake로 새 데이터 또는 변경된 데이터를 복제할 수 있습니다. Fivetran 또는 Matillion과 같은 도구는 이러한 동기화를 자동화할 수 있습니다.

**5단계: 데이터 수집¶

이 단계에서는 진행 중인 데이터 수집 프로세스 및 ETL 및 ELT 파이프라인을 Databricks에서 Snowflake로 마이그레이션하여 실시간 데이터의 지속적인 흐름을 보장하는 데 중점을 둡니다.

실행 가능한 단계:

• Databricks ETL 및 ELT 워크플로 재설계:

  • Snowflake에 맞게 Databricks ETL 및 ELT 워크플로를 재설계합니다(대개 PySpark, Scala 또는 SQL를 사용하여 구축하며 Delta Live Tables(DLT) 또는 Databricks 작업을 활용).

  • 복잡한 ETL 및 ELT의 경우, Spark 코드를 Snowpark DataFrames 및 UDFs로 변환합니다(1단계에서 설명한 대로). SQL 기반 변환의 경우 Snowflake 내 변환을 위해 dbt(데이터 빌드 도구)를 고려합니다.

  • Snowflake 네이티브 기능 활용:

    • Streams 및 Tasks: Streams를 사용하여 증분 처리를 위한 DML 변경 사항을 기록하고, Tasks를 사용하여 Snowflake 내에서 바로 증분 변환 및 오케스트레이션을 하기 위한 SQL 문 또는 저장 프로시저를 예약합니다.

    • Snowpipe: 새 데이터를 실시간으로 연속 로드하려면 트리클 피드에 Snowpipe를 사용합니다. 일괄 로드의 경우 COPY 명령은 여전히 강력한 옵션입니다.

    • Snowpipe Streaming: 지연 시간이 짧은 스트리밍 사용 사례에 이상적입니다.

• 데이터 소스 및 싱크 재정렬:

  • Snowflake 스테이지 또는 테이블을 직접 가리키도록 커넥터 또는 사용자 지정 수집 프로세스를 구성하여 현재 Databricks에 도착하는 여러 인바운드 데이터 소스를 Snowflake 수집 패턴으로 리디렉션합니다.

  • 데이터 파이프라인이 안정화되고 데이터 유효성 검사가 완료되면 현재 Databricks에서 Snowflake로 읽어오는 다운스트림 시스템(예: BI 도구, 기타 애플리케이션)을 다시 지정하는 계획을 개발합니다.

6단계: 보고 및 분석 전환¶

이 단계에서는 비즈니스 인텔리전스(BI) 및 분석 도구가 새로운 데이터 소스인 Snowflake에서 계속해서 정확하고 최적의 상태로 작동하도록 하는 데 중점을 둡니다.

실행 가능한 단계:

• BI 도구 및 사용자 지정 쿼리 조정:

  • 기존 보고 도구(예: Tableau, Power BI, Looker)를 다시 지정하거나 리팩터링하고 이전에 Databricks에 대해 실행한 사용자 지정 쿼리를 조정합니다.

  • Snowflake의 요구 사항에 따라 데이터베이스로 전송되는 SQL 쿼리를 조정합니다. 간단한 이름 변경부터 더 복잡한 구문 및 의미 체계 변경에 이르기까지 다양한 조정이 이루어질 수 있습니다.

• 비즈니스 사용자 참여 및 교육 제공:

  • 비즈니스 사용자를 마이그레이션 프로세스의 주요 이해관계자로 포함합니다(예: 계획 프로세스의 RACI 행렬). 레거시 플랫폼에서 완전히 전환하려면 이러한 사용자 수용이 매우 중요합니다.

  • 비즈니스 사용자에게 Snowflake의 운영 방식을 교육하고 플랫폼의 차이점을 명확하게 이해할 수 있도록 합니다. 이를 통해 필요에 따라 사용자 지정 쿼리와 보고서를 수정할 수 있습니다.

  • 비즈니스 사용자를 위한 병행 교육 과정을 제공한 후 플랫폼 간의 차이를 해결 사용자에게 필요한 조정을 안내할 수 있는 마이그레이션 전문가와의 상담 시간을 마련합니다.

7단계: 데이터 유효성 검사 및 테스트¶

데이터 유효성 검사 및 테스트는 마이그레이션 계획 프로세스에서 간과되는 경우가 많지만, 새로운 Snowflake 환경에서 데이터 무결성과 정확성을 보장하는 데 매우 중요합니다. 목표는 이 단계에 들어가기 전에 데이터를 최대한 정리하는 것입니다.

실행 가능한 단계:

• 포괄적인 테스트 전략 수행: 조직마다 데이터를 프로덕션 환경으로 이동하기 위한 고유한 테스트 방법론과 요구 사항이 있으며, 프로젝트 시작부터 이에 대해 완전히 이해해야 합니다.

  • 기능 테스트: 마이그레이션된 모든 애플리케이션과 기능이 새 환경 내에서 예상대로 작동하는지 확인하여 데이터 무결성과 정확성을 보장합니다. 여기에는 마이그레이션된 ETLs 및 보고서가 올바른 결과를 생성하는지 확인하는 작업이 포함됩니다.

  • 성능 테스트: 쿼리 성능, 데이터 로딩 속도, 전반적인 시스템 응답성을 평가합니다. 이를 통해 Snowflake에서 발생하는 모든 성능 병목 상태를 식별하고 해결하여 새 플랫폼이 성능 기대치 이상을 충족하도록 보장할 수 있습니다.

  • 사용자 수용 테스트(UAT): 마이그레이션된 시스템이 비즈니스 요구 사항을 충족하는지 확인하고 잠재적 개선을 위한 피드백을 수집하기 위해 테스트 프로세스에 최종 사용자를 참여시킵니다. 이는 사용자 신뢰 및 채택률을 높이는 데 매우 중요합니다.

  • 데이터 유효성 검사 기법: 소스 시스템(Databricks) 및 대상 시스템(Snowflake) 간의 일대일 연결을 위해 행 수를 비교하고, 열의 합계, 최대값, 최소값, 평균값을 계산하며, 행 값을 해시합니다. 일정 기간 동안 병렬 시스템을 실행하면 실시간 비교가 가능합니다.

• 교육 및 설명서 제공:

  • Snowflake의 기능, 모범 사례와 더불어, 데이터 액세스, 쿼리 최적화, 보안과 같은 항목을 다루는 포괄적인 교육을 최종 사용자에게 제공합니다.

  • 쉽게 참조하고 지속적인 지원을 받을 수 있도록 시스템 아키텍처 다이어그램, 데이터 흐름 다이어그램, 운영 절차, 사용자 가이드, 문제 해결 가이드, FAQs 등이 포함된 포괄적인 문서를 작성합니다.

8단계: 배포 시작¶

이 단계에서는 프로덕션 환경으로 최종 배포하기 전에 중요한 사항을 고려하고 원활하고 조정된 전환이 이루어져야 합니다.

실행 가능한 단계:

• 단계적 롤아웃 및 브리징 전략 계획:

  • 이상적으로는 레거시 애플리케이션을 하나씩 마이그레이션하고 동일한 순서로 프로덕션 환경으로 배포하는 것이 좋습니다.

  • 비즈니스 사용자가 Snowflake와 레거시 Databricks 시스템을 모두 쿼리할 필요가 없도록 브리징 전략이 마련되어 있는지 확인합니다. 아직 마이그레이션되지 않은 애플리케이션에 대한 데이터 동기화는 이 메커니즘을 통해 백그라운드에서 이루어져야 합니다.

• 이해 관계자 정렬 및 공식 승인 획득:

  • 전환할 준비가 되면 모든 이해관계자가 정렬된 상태이며 Snowflake가 레거시 Databricks 플랫폼이 아닌 공식 시스템(System of Record, RoS)이 될 것이라는 점을 이해하는지 확인합니다.

  • 계속 진행하기 전에 모든 이해관계자로부터 최종적이고 공식적인 승인을 받습니다.

  • 마이그레이션되지 않은 모든 보고서는 이제 비즈니스 사용자의 책임이며 조기 사용자 참여가 중요함을 강조합니다.

  • Active Directory 기반 역할을 포함하여 Snowflake에서 모든 권한이 올바르게 부여되었는지 확인합니다.

• 전환에 대한 중요 고려 사항 해결:

  • 대체 키: 대체 키를 사용하는 경우, 대체 키의 수명 주기가 레거시 시스템 및 Snowflake 시스템 간에 다를 수 있다는 점에 유의합니다. 대체 키는 전환 중에 동기화해야 합니다.

  • 전환 타이밍: 비즈니스 영향을 최소화하기 위해 업종에 따라 최적의 전환 타이밍을 고려합니다.

  • 레거시 플랫폼 해제: 레거시 플랫폼 라이선스 및 데이터 보존 정책을 고려하면서 레거시 Databricks 환경의 해제를 계획합니다.

9단계: 최적화 및 실행 - 지속적 개선¶

시스템이 Snowflake로 마이그레이션되면 이 단계가 일반 유지 관리 모드로 전환됩니다. “최적화 및 실행”이라고 하는 이 단계는 마이그레이션 자체에 포함되지 않지만 지속적 최적화 및 지속적 개선에 중점을 둡니다.

실행 가능한 단계:

• 지속적 최적화 및 비용 관리에 집중:

  • 팀은 Snowflake의 시스템에 대한 모든 소유권을 가지며 사용량 패턴에 따라 최적화됩니다.

  • 일반적으로 Snowflake의 작업은 더 빠르게 실행되지만, 성능이 기대에 미치지 못하는 경우 Snowflake의 고유한 아키텍처를 최대한 활용하기 위해 최적화가 필요할 수 있습니다.

  • Snowflake의 쿼리 분석 도구를 활용하여 병목 상태를 식별하고 워크플로의 특정 부분을 최적화합니다.

  • 마이그레이션 중에는 중요한 성능 문제만 해결하고 마이그레이션 이후에 광범위한 최적화 작업을 수행합니다.

  • 지속적인 비용 관리 구현:

    • Snowflake는 웨어하우스가 실행되는 매초마다 재개당 최소 60초의 요금을 청구하므로, 가상 웨어하우스의 자동 일시 중단 시간 제한을 60초로 설정하면 비용을 크게 절감할 수 있습니다.

    • 웨어하우스 크기에 따라 컴퓨팅 리소스와 비용이 기하급수적으로 증가하므로 워크로드 요구 사항에 따라 가상 웨어하우스 크기를 줄입니다.

    • 사용 패턴을 지속적으로 모니터링하고 재무 부서와 협력하여 비용 할당을 위해 부서별 사용량을 추적합니다.

• 거버넌스 및 보안 강화:

  • 역할 기반 액세스 제어를 구체화하고, 민감한 데이터에 대한 동적 데이터 마스킹 및 행 액세스 정책을 구현하며, 액세스 패턴을 정기적으로 감사합니다.

  • 액세스 모델을 재고하여 사용자 계층 구조를 정리하고 필요한 사용자만 특정 리소스에 액세스할 수 있도록 보장합니다.