Oracle에서 Databricks로의 이동 탐색: 원활한 전환을 위한 팁

많은 조직들이 Lakehouse 아키텍처를 채택하면서, 오라클과 같은 기존의 데이터 웨어하우스에서 Databricks와 같은 현대적인 플랫폼으로 이전하는 것이 일반적인 우선 순위가 되었습니다. 이점 - 더 나은 확장성, 성능, 비용 효율성 - 은 명확하지만, 그곳에 도달하는 경로는 항상 명확하지 않습니다.

이 게시물에서는 Oracle에서 Databricks로의 이전을 진행하는 데 있어 실질적인 전략을 공유하며, 일반적인 함정을 피하는 팁과 프로젝트를 장기적으로 성공으로 이끌기 위한 설정에 대해 이야기하겠습니다.
 

주요 차이점 이해

마이그레이션 전략을 논의하기 전에, Oracle과 Databricks 사이의 핵심 차이를 이해하는 것이 중요합니다 - 기술뿐만 아니라 구조적 차이에서도 말입니다.

Oracle의 관계형 모델 vs. Databricks의 레이크하우스 아키텍처

Oracle 데이터 웨어하우스는 구조화된 트랜잭션 작업량에 최적화된 전통적인 관계형 모델을 따릅니다. Databricks는 사용하는 데이터 모델에 관계없이 데이터 웨어하우스 워크로드를 호스팅하는 데 완벽한 솔루션으로, Oracle과 같은 다른 데이터베이스 관리 시스템과 유사합니다. 반면에, Databricks는 데이터 레이크의 유연성과 데이터 웨어하우스의 성능 및 신뢰성을 결합한 레이크하우스 아키텍처를 기반으로 구축되었습니다.

이러한 변화는 데이터가 저장, 처리, 접근되는 방식을 바꾸지만, 완전히 새로운 가능성을 열어줍니다. Databricks를 사용하면 조직은 다음을 수행할 수 있습니다:

• 머신러닝(ML), 전통적인 AI, 그리고 생성 AI와 같은 현대적인 사용 사례 지원
• 저장소와 컴퓨트의 분리를 활용하여, 여러 팀이 동일한 기본 데이터에 액세스하면서 독립적인 웨어하우스를 구축할 수 있습니다
• 데이터 사일로를 분해하고 중복된 ETL 파이프라인의 필요성을 줄입니다.

SQL 방언과 처리 차이 

두 플랫폼 모두 SQL을 지원하지만, 문법, 내장 함수, 쿼리 최적화 방식 등에 차이가 있습니다. 이러한 차이점들은 호환성과 성능을 보장하기 위해 이전 과정에서 처리해야 합니다.

데이터 처리 및 확장 

Oracle은 행 기반, 수직적으로 확장된 아키텍처를 사용합니다(Real Application Clusters를 통한 제한적인 수평 확장 포함). 반면에 Databricks는 Apache Spark™의 분산 모델을 사용하며, 이는 대규모 데이터셋에서 수평 및 수직 확장을 모두 지원합니다.

Databricks는 또한 Delta Lake 및 Apache Iceberg와 같은 고성능, 대규모 분석에 최적화된 컬럼 기반 저장 형식과 원활하게 작동합니다. 이러한 형식은 ACID 트랜잭션, 스키마 진화, 시간 여행과 같은 기능을 지원하며, 이는 탄력적이고 확장 가능한 파이프라인을 구축하는 데 중요합니다.

이전 단계 (모든 데이터 웨어하우스 이전에 공통)

소스 시스템에 관계없이, 성공적인 마이그레이션은 몇 가지 중요한 단계로 시작됩니다:

• 환경을 인벤토리화하십시오: 모든 데이터베이스 객체, 종속성, 사용 패턴, ETL 또는 데이터 통합 워크플로를 카탈로그화하는 것으로 시작합니다. 이것은 범위와 복잡성을 이해하는 기반을 제공합니다.
• 워크플로우 패턴 분석:  현재 시스템을 통해 데이터가 어떻게 흐르는지 파악합니다. 이에는 배치 대 스트리밍 작업량, 작업량 의존성, 재설계가 필요할 수 있는 플랫폼 특정 로직이 포함됩니다.
• 이전을 우선순위로 하고 단계별로 진행:  “대폭발” 접근법을 피하십시오. 대신 위험, 비즈니스 영향, 그리고 준비 상태에 따라 이전을 관리 가능한 단계로 나눕니다. Databricks 팀과 인증된 통합 파트너 와 협력하여 목표와 일정에 맞는 현실적이고 저위험한 계획을 수립합니다.

데이터 이전 전략

성공적인 데이터 이전은 플랫폼 간의 기술적 차이와 데이터 자산의 독특한 특성을 모두 해결하는 신중한 접근 방식을 필요로 합니다. 다음 전략들은 Databricks의 아키텍처의 이점을 최대화하면서 효율적인 마이그레이션 프로세스를 계획하고 실행하는 데 도움이 될 것입니다.

스키마 번역 및 최적화

Oracle 스키마를 Databricks에 대한 설계를 재고하지 않고 직접 복사하는 것을 피하십시오. 예를 들어, Oracle의 NUMBER 데이터 유형은 Databricks가 허용하는 것보다 더 큰 정밀도를 지원합니다(최대 정밀도 및 스케일 38). 이런 경우에는 정확한 일치를 유지하려고 시도하는 대신 DOUBLE 유형을 사용하는 것이 더 적절할 수 있습니다.

스키마를 신중하게 변환하면 호환성을 보장하고 성능 또는 데이터 정확성 문제를 피할 수 있습니다.

자세한 내용은 Oracle에서 Databricks로의 마이그레이션 가이드 를 확인하십시오.

데이터 추출 및 로딩 방법

Oracle 이전은 종종 데이터를 온프레미스 데이터베이스에서 Databricks로 이동하는 것을 포함하며, 여기서 대역폭과 추출 시간이 병목 현상이 될 수 있습니다. 추출 전략은 데이터 볼륨, 업데이트 빈도, 다운타임에 대한 허용도와 일치해야 합니다.

일반적인 옵션은 다음과 같습니다:

• JDBC 연결 – 작은 데이터셋이나 저량 전송에 유용
• Lakehouse Federation - 데이터 마트를 직접 Databricks로 복제하기 위한 것
• Azure Data Factory 또는 AWS Database Migration Services – 대규모로 조정된 데이터 이동을 위해
• Oracle-native export tools:
  • DBMS_CLOUD.EXPORT_DATA (Oracle Cloud에서 사용 가능)
  • SQL Developer unload (사내 또는 로컬 사용을 위한)
  • Oracle 19.9+ 온프레미스 배포에 대한 DBMS_CLOUD 의 수동 설정
• Bulk transfer options - 예를 들어 AWS Snowball 또는 Microsoft Data Box, 대규모의 과거 테이블을 클라우드로 이동시키기 위한 것

올바른 도구를 선택하는 것은 데이터 크기, 연결성 제한, 그리고 복구 필요성에 따라 달라집니다.

성능 최적화

마이그레이션된 데이터는 종종 Databricks에서 잘 작동하도록 재구성해야 합니다. 이것은 데이터가 어떻게 파티션되는지에 대해 다시 생각하는 것으로 시작됩니다.

만약 당신의 Oracle 데이터 웨어하우스가 정적이거나 불균형한 파티션을 사용했다면, 그 전략들이 잘 적용되지 않을 수 있습니다. 쿼리 패턴을 분석하고 파티션을 그에 따라 재구성합니다. Databricks는 성능 향상을 위한 여러 기법을 제공합니다:

• 수동 튜닝 없이 지속적인 최적화를 위한 자동 액체 클러스터링
• 자주 필터링되는 열에 대한 클러스터링을 위한 Z-Ordering
• 데이터를 동적으로 구성하는 Liquid Clustering

추가로:

• 오버헤드를 줄이기 위해 작은 파일 압축
• 핫 데이터와 콜드 데이터를 분리하여 비용과 저장 효율성을 최적화합니다
• 과도한 파티션을 피하십시오, 이것은 스캔을 느리게 하고 메타데이터 오버헤드를 증가시킵니다.

예를 들어, 데이터 분포가 불균형한 거래 날짜를 기반으로 한 파티셔닝은 Automatic Liquid Clustering을 사용하여 재조정할 수 있으며, 이는 시간 기반 쿼리의 성능을 향상시킵니다.

Databricks의 처리 모델을 염두에 두고 설계하면 작업 부하가 효율적으로 확장되고 이전 후에도 유지 관리가 가능합니다.

코드 및 로직 마이그레이션

데이터 이전은 전환의 기초를 형성하지만, 애플리케이션 로직과 SQL 코드를 이동하는 것은 Oracle에서 Databricks로의 이전에서 가장 복잡한 측면 중 하나를 나타냅니다. 이 과정은 구문을 번역하고 Databricks의 분산 처리 모델에 맞는 다른 프로그래밍 패러다임과 최적화 기법에 적응하는 것을 포함합니다.

SQL 번역 전략

구조화된 접근법을 사용하여 Oracle SQL을 Databricks SQL로 변환합니다. 자동화 도구인 BladeBridge (이제 Databricks의 일부)는 코드 복잡성을 분석하고 대량 번역을 수행할 수 있습니다. 코드베이스에 따라, 일반적인 변환률은 약 75% 또는 더 높습니다.

이러한 도구들은 수동 작업을 줄이고 이전 후 재작업이나 아키텍처 변경이 필요한 영역을 식별하는 데 도움이 됩니다.

저장 프로시저 마이그레이션

Oracle PL/SQL 구조체에 대한 정확한 일대일 대체를 찾으려고 시도하는 것을 피하십시오. DBMS_X, UTL_X, 그리고 CTX_X 는 Databricks에 존재하지 않으며, 플랫폼에 맞게 로직을 다시 작성해야 합니다.

다음과 같은 공통 구조체에 대해:

• Cursors
• 예외 처리
• Loops and control flow statements
   

Databricks는 이제 SQL Scripting을 제공하며, 이는 노트북에서 절차적 SQL을 지원합니다. 또는, 이러한 워크플로우를 Python 또는 Scala 로 변환하여 Databricks Workflows 또는 DLT pipelines에서 사용하는 것을 고려해 보십시오. 이들은 분산 처리와의 통합을 더욱 쉽게 해주는 더 큰 유연성을 제공합니다.

BladeBridge는 이 로직을 Databricks SQL 또는 PySpark 노트북으로 번역하는 데 도움을 줄 수 있습니다.

ETL 워크플로 변환

Databricks는 기존 Oracle ETL을 단순화하는 ETL 프로세스를 구축하기 위한 여러 가지 접근법을 제공합니다.

• 매개변수가 있는 Databricks 노트북 – 간단하고 모듈식 ETL 작업에 적합
• DLT - 배치 및 스트리밍, 증분 처리, 내장된 데이터 품질 검사를 지원하는 선언적 파이프라인 정의
• Databricks 워크플로우 – 플랫폼 내에서 스케줄링 및 오케스트레이션에 적합
   

이 옵션들은 팀이 현대적인 데이터 엔지니어링 패턴에 맞추면서 마이그레이션 후의 ETL을 리팩토링하고 운영하는 데 유연성을 제공합니다.

 

마이그레이션 후: 검증, 최적화, 및 적용

기술적 및 비즈니스 테스트로 검증합니다

사용 사례가 마이그레이션된 후에는, 기술적으로나 기능적으로 모든 것이 예상대로 작동하는지 확인하는 것이 중요합니다.

• 기술 검증 은 다음을 포함해야 합니다:
  • 시스템 간 행 수와 집계 조정
  • 데이터 완전성 및 품질 검사
  • 소스와 대상 플랫폼 간의 쿼리 결과 비교
• 비즈니스 검증 은 두 시스템을 병렬로 실행하고 이전 전에 이해당사자들이 출력이 기대치와 일치하는지 확인하는 과정을 포함합니다.

비용과 성능 최적화

검증 후, 실제 작업량에 기반하여 환경을 평가하고 미세 조정합니다. 주요 영역은 다음과 같습니다:

• 파티셔닝 및 클러스터링 전략 (예: Z-Ordering, Liquid Clustering)
• 파일 크기 및 형식 최적화
• 리소스 구성 및 확장 정책. 이러한 조정은 인프라를 성능 목표와 비용 목표와 일치시키는 데 도움이 됩니다.

지식 전달 및 조직 준비

성공적인 이전은 기술적 구현으로 끝나지 않습니다. 팀이 새로운 플랫폼을 효과적으로 사용할 수 있도록 하는 것이 마찬가지로 중요합니다.

• 실습 교육 및 문서화 계획
• 협업 개발, 노트북 기반 로직, 선언적 파이프라인을 포함한 새로운 워크플로우를 채택할 수 있도록 팀을 지원
• 새 시스템에서 데이터 품질, 거버넌스, 성능 모니터링에 대한 소유권을 할당합니다.

마이그레이션은 단순히 기술적인 전환 이상입니다

Oracle에서 Databricks로의 마이그레이션은 단순히 플랫폼을 바꾸는 것이 아니라, 데이터가 관리, 처리, 소비되는 방식에 대한 변화입니다.

철저한 계획, 단계적 실행, 기술 팀과 비즈니스 이해관계자 간의 긴밀한 협력은 위험을 줄이고 원활한 전환을 보장하는 데 필수적입니다.

동등하게 중요한 것은 조직을 다르게 작동하도록 준비하는 것입니다: 새로운 도구, 새로운 프로세스, 그리고 분석이나 AI에 대한 새로운 마인드셋을 채택하는 것입니다. 구현과 적용에 균형있게 초점을 맞춤으로써, 귀하의 팀은 현대적인 레이크하우스 아키텍처의 전체 가치를 활용할 수 있습니다.

다음에 할 일

이전은 거의 항상 간단하지 않습니다. 타협, 지연, 예상치 못한 도전은 프로세스의 일부이며, 특히 사람, 프로세스, 기술을 조정할 때 그렇습니다.

그래서 이전에 이 작업을 수행한 팀과 함께 작업하는 것이 중요합니다. Databricks Professional Services와 우리의 인증된 이전 파트너들 은 시간 내에 고품질의 이전을 대규모로 제공하는 데 깊은 경험을 가지고 있습니다. 이전 평가를 시작하려면 저희에게 연락하십시오.

더 많은 지침이 필요하신가요? 실질적인 단계, 도구에 대한 통찰력, 계획 템플릿을 돕기 위해 Oracle에서 Databricks로의 마이그레이션 가이드 를 전체 다운로드하십시오.

 

 

(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)