레이크하우스, Spark Declarative Pipelines 또는 PySpark 중에서 선택하는 방법 및 이들을 조합하여 사용하는 시기
작성자: Rafael Aielo
여러분의 팀에는 수백 개의 저장 프로시저(stored procedures), 몇 개의 스케줄러, 여러 역할과 스키마에 분산된 권한이 있으며, 클라우드 데이터 웨어하우스 갱신 기한이 다가오고 있습니다. 무엇을 먼저 이전해야 할지 아무도 합의하지 못합니다. 어떤 이들은 모든 것을 PySpark로 다시 작성하고 싶어 합니다. 다른 이들은 SQL을 있는 그대로 옮기고 끝내고 싶어 합니다. 이 과정에서 코드와 함께 이동하는 메타데이터, 리니지(lineage), 권한은 물론, 마이그레이션 과정에서 이를 통합할 기회마저 논의에서 잊혀지곤 합니다.
어느 한쪽의 극단적인 방식도 통하지 않습니다. 데이터 웨어하우스 마이그레이션에 성공하는 팀은 각 워크로드를 개별적으로 살펴보고 작업에 적합한 도구를 선택합니다. 이 글에서는 선택을 위한 의사 결정 프레임워크를 제안합니다. 즉, Lakehouse(Databricks SQL), Spark Declarative Pipelines 또는 PySpark를 언제 사용해야 하는지, 그리고 계획만 세우다 지체되는 대신 결과를 신속하게 인도할 수 있도록 작업을 단계별로 나누는 방법을 소개합니다.
Databricks에서는 주로 세 가지 방식으로 ETL 파이프라인을 마이그레이션할 수 있으며, 이 방식들은 종종 함께 사용됩니다.
이는 SQL을 주로 사용하는 팀에게 가장 직접적인 경로입니다. 단순한 작업부터 복잡한 작업까지 광범위하게 적용됩니다. 이 경로는 기본적으로 Photon으로 가속화되며 ANSI 및 Spark SQL (%sql)과 완전히 호환되는 SQL 웨어하우스에서 실행됩니다. 가변적이거나 예측하기 어려운 워크로드에는 Serverless를 선택하세요(빠른 시작, 제로로 스케일링, 초당 과금). 안정적인 워크로드나 특정 네트워킹 또는 비용 제어가 필요한 경우에는 Classic을 선택하세요.
간단한 SQL 작업:
로직에 흐름 제어(조건문), 루프, 변수, 오류 처리 또는 매개변수 기반 실행이 필요한 경우, 저장 프로시저가 이러한 절차적 레이어를 제공합니다. 이는 Unity Catalog를 통해 거버넌스가 수행되며 매개변수와 함께 Workflows에서 호출할 수 있습니다.
기본 원칙은 다음과 같습니다. 기존 레거시 코드가 단일 SQL 문인 경우 SQL 작업으로 마이그레이션하세요. 절차적 로직(변수, 루프, 매개변수, 오류 처리)이 있는 경우 Unity Catalog에서 관리되고 Workflows에서 호출할 수 있는 저장 프로시저로 래핑하세요. 원래 시스템에서 요구했다는 이유만으로 단순한 SQL을 프로시저로 래핑하지는 마세요.
Lakeflow의 일부인 이 방식은 다른 접근 방식을 취합니다. 파이프라인이 생성해야 하는 결과를 선언하면 엔진이 실행 순서, 재시도 및 스케일링을 처리합니다. 동일한 정의 내에서 내장된 데이터 품질 제약 조건, 자동 종속성 해결, 통합된 배치 및 스트리밍을 제공받을 수 있습니다.
내부적으로 Enzyme이 파생 테이블을 점진적으로 업데이트할지 아니면 완전히 다시 계산할지 결정합니다. 자동 확장(Autoscaling)은 수동 튜닝 없이 데이터 볼륨 변화에 맞춰 용량을 조정합니다. Block과 같은 기업들은 사용량이 증가함에 따라 파이프라인 오케스트레이션을 단순화하기 위해 이 선언적 모델에 의존하고 있습니다.
이는 완전한 제어 권한을 제공합니다. 작업 클러스터에서 실행되며 SQL 웨어하우스나 선언적 파이프라인에 적합하지 않은 워크로드를 처리합니다.
워크로드에 복잡한 비즈니스 로직, ML 피처 엔지니어링, API 통합 또는 맞춤형 검증이 필요한 경우 PySpark를 활용하세요. 아래 예시는 Unity Catalog에 등록된 모델을 사용하여 트랜잭션을 점수화(scoring)하는 방법입니다:
언어는 여전히 SQL이지만 워크로드가 SQL 웨어하우스의 적합 범위 를 초과할 수 있는 경우(예: 초대형 테이블, 과도한 셔플, 파티셔닝, 브로드캐스트 조인 또는 캐싱에 대한 명시적 제어가 필요한 장시간 실행되는 배치 ETL)에는 노트북의 Spark SQL을 활용하세요.
대규모 조인, 집계, 윈도우 함수, 대형 컬럼형 테이블 스캔 등 컴퓨팅 집약적인 SQL 또는 DataFrame 작업의 경우 작업 클러스터에서 Photon을 활성화하세요. Photon은 Pandas UDF(Arrow 기반)를 포함하여 코드 변경 없이 이러한 패턴을 가속화하는 네이티브 벡터화 엔진입니다. 행 단위 Python UDF가 대부분이거나, 데이터 세트가 작거나, 작업이 순수 I/O인 경우에는 Photon을 제외하세요.
노트북은 하이브리드 파이프라인에도 잘 맞습니다. 예를 들어 SDP에서 수집(ingestion)을 수행하고 노트북 작업에서 보강(enrichment)을 수행할 수 있습니다.
아래 표는 팀 논의를 위한 출발점일 뿐이며 엄격한 규칙은 아닙니다.
| 기준 | Lakehouse(작업 및 저장 프로시저) | Spark Declarative Pipelines | PySpark + Spark SQL 노트북 |
|---|---|---|---|
| 팀 프로필 | SQL 중심 팀, DBA, DW 엔지니어 | 관리형 파이프라인을 구축하는 데이터 엔지니어 및 SQL 팀 | Python/Spark 개발자, ML 엔지니어 |
| 로직 유형 | SQL ETL: 단일 문을 위한 간단한 작업, 절차적 로직을 위한 저장 프로시저 | 선언적 파이프라인, CDC, SCD | 복잡한 로직, 맞춤형 UDF, ML 준비 |
| SQL 마이그레이션 속도 | SQL ANSI 유사 워크로드의 경우 빠름 | 보통: 파이프라인 재설계가 필요하지만 SQL 재사용 가능 | 가변적: 상당한 리팩터링이 필요할 수 있음 |
| 파이프라인 오케스트레이션 | Workflows의 SQL 작업 또는 CALL 프로시저 | 파이프라인에 내장됨 | Workflows의 노트북 작업 |
| 배치 vs. 스트리밍 | 주로 배치 | 통합 배치 및 스트리밍 | Structured Streaming을 통한 배치 및 스트리밍 |
| 데이터 품질 | 수동 SQL 검사 | 선언적 제약 조건 | 코드 내 맞춤형 검증 |
열에서 여러분의 팀 유형을 찾고, 행에서 워크로드 복잡도를 찾으세요. 해당 칸이 시작할 위치를 제안해 줍니다.
| 워크로드 복잡도 | SQL 우선 팀 | 하이브리드 팀 | 코드 우선 팀 |
|---|---|---|---|
| 낮음 (배치 로드, 집계, MERGE) | Workflows의 SQL 작업 | SQL 작업 또는 SDP | PySpark 또는 SDP |
| 보통 (다단계 파이프라인, CDC, 데이터 품질) | 저장 프로시저 또는 SDP | SDP | SDP 또는 PySpark |
| 높음 (ML 준비, 맞춤형 UDF, API, 복잡한 비즈니스 로직) | SDP + PySpark 지원 | 수집용 PySpark + SDP | PySpark |
"모든 것에 어떤 방식을 적용할지" 결정하기보다, 각 단계에서 "다음에 무엇을 할지" 결정하세요.
1단계 — 평가. 기존 데이터 웨어하우스에서 CPU 시간, 실행 시간, 빈도, 소스 및 타겟 테이블 등의 메트릭을 수집합니 다. 복잡성에 따라 워크로드를 분류합니다. 가능한 경우 마이그레이션 도구를 사용하여 가치 대비 난이도로 점수가 매겨진 인벤토리를 구축합니다. 이 데이터를 찾는 위치는 소스에 따라 다릅니다. Teradata의 경우, DBC.QryLog를 쿼리합니다. SQL Server의 경우, sys.dm_exec_query_stats를 사용합니다. Oracle의 경우, AWR 보고서를 사용합니다. Snowflake의 경우, QUERY_HISTORY를 사용합니다. 세부 사항은 다를 수 있습니다. 통합 도구가 이미 마련되어 있다면 해당 메타데이터를 활용하여 테이블 간의 관계를 식별하거나, LLM의 도움을 받아 이러한 계보를 구축할 수 있습니다. 출력물은 재작성 계획이 아니라 하나의 지도(map)입니다. 목표는 동일합니다. 리소스 소비량과 종속성 수준에 따라 워크로드의 순위를 매겨 어디서부터 시작해야 할지 파악하는 것입니다. 제대로 수행된다면 마이그레이션 도구를 사용해 몇 주 동안 수동으로 스크립트를 작성하는 대신 단 며칠 만에 이 평가를 마칠 수 있습니다.
2단계 — 빠른 성과(Quick wins). 마이그레이션 위험은 낮으면서 비즈니스 가시성은 높은 유스케이스가 결합된 워크로드를 선택하세요. 이는 전환하기 쉬운 대규모 SQL 작업부터 시작하거나, 이해관계자들에게 새로운 플랫폼을 조기에 보여줄 수 있는 보고 파이프라인부터 시작하는 것을 의미할 수 있습니다. 단순한 문(statement)은 Workflows의 SQL 태스크가 됩니다. 절차적 로직은 저장 프로시저가 됩니다. 초기 변환에는 트랜스파일러와 AI 지원 전환 도구를 사용하세요. 두 시스템을 병렬로 실행하고 행 수, 체크섬, 샘플 레코드를 비교해 보세요. 핵심은 기술적 및 조직적 차원 모두에서 신뢰를 구축하는 것입니다.
예를 들어, Walgreens는 단계적 마이그레이션을 통해 온프레미스 Teradata를 폐기하고 현재 레이크하우스에서 초당 약 40,000개의 데이터 이벤트를 처리하며 약 9,000개 매장의 공급망 최적화를 지원하고 있습니다.
3단계 — 현대화. 이제 현대화할 가치가 있는 파이프라인을 재설계합니다. 대상 후보: 데이터 품질 제약 조건과 계보 덕분에 수동 검사가 줄어드는 흐름, 스트리밍 테이블과 CDC의 이점을 누릴 수 있는 배치 작업, 구체화된 뷰(materialized views)를 통해 복잡성을 줄이는 파이프라인, 그리고 이전에는 별도의 도구에 분산되어 있었으나 이제 Unity Catalog로 통합된 메타데이터, 권한 및 감사 등입니다. 일반적인 패턴은 새 파이프라인이 검증을 통과할 때까지 병렬로 실행하는 동안 기존 프로시저를 대체 수단(fallback)으로 유지하는 것입니다. 현대화된 파이프라인은 종종 배치 윈도우를 몇 시간에서 몇 분으로 단축하고 별도의 DQ 도구의 필요성을 없애줍니다.
4단계 — 최적화. 이전 DW의 한계를 우회하기 위해서만 존재했던 중복 ETL 파이프라인을 통합합니다. 로직이 단순해진다면 복잡한 핫스팟을 PySpark로 이동하세요. 이제 통합 엔진을 갖추었으므로 배치와 스트리밍의 경계를 다시 검토해 보세요. 이 단계에서 마이그레이션의 결실을 맺게 됩니다. 기존 플랫폼은 종료되고 중복 파이프라인은 사라지며, 아키텍처는 두 개가 아닌 하나의 시스템에서 실행됩니다.
마이그레이션 도구는 기계적인 작업을 자동화하지만 아키텍처 결정을 대체하지는 않습니다. 세 가지 대표적인 역할은 다음과 같습니다.
실용적인 접근 방식: 도구가 초기 변환의 60~80%를 처리하도록 하고, 엔지니어의 시간은 실제로 현대화하려는 패턴을 위해 아껴두세요. 이렇게 하면 기술 부채가 그대로 이전되는 것을 방지할 수 있습니다.
성공적인 마이그레이션은 단순히 코드를 변환하는 데 그치지 않고 독립형 스케줄러 서버, 맞춤형 DQ 프레임워크, 별도의 계보 및 메타데이터 도구, 벤더 전용 저장 프로시저 컴파일러, 수동으로 구축한 검증 하네스 등의 시스템을 적극적으로 폐기합니다. 이러한 시스템이 종료되고 비용 청구가 중단될 때까지는 마이그레이션이 완료된 것이 아닙니다.
SQL ETL이 여러 엔진, 레이어, 도구에 걸쳐 파편화되어 있다면, 데이터가 오픈 형식으로 저장되어 있더라도 플랫폼은 계속 파편화된 상태로 남게 됩니다.
데이터 파이프라인을 마이그레이션하는 정답은 단 하나만 존재하지 않습니다. 레이크하우스를 사용하면 빠르게 목표에 도달할 수 있습니다. 단순한 로직에는 단순한 태스크를 사용하고, 절차적 제어가 필요할 때는 저장 프로시저를 사용하세요. SDP는 품질과 계보가 기본으로 내장된 현대적인 ETL 파이프라인을 제공합니다. PySpark를 사용하든 Spark SQL을 사용하든 나머지는 Notebooks가 처리합니다. 작업을 단계별로 나누고, 빠른 성과부터 시작하며, 가능한 모든 가속기를 활용하세요.
기술적인 가이드는 Databricks 마이그레이션 가이드를 살펴보거나, Databricks 무료 에디션을 통해 직접 체험해 보세요.
(이 글은 AI의 도움을 받아 번역되었습니다. 원문이 궁금하시다면 여기를 클릭해 주세요)
블로그를 구독하고 최신 게시물을 이메일로 받아보세요.