최신 데이터 플랫폼을 위한 SQL ETL 재고

SQL은 현대 데이터 작업의 기반입니다. 이는 분석 엔지니어가 변환을 정의하고, 데이터 웨어하우스 엔지니어가 파이프라인을 관리하며, 분석가가 데이터를 탐색하고 정제하는 방식입니다.

하지만 SQL 자체는 표준화되어 있지만, SQL ETL을 실행하는 데 사용되는 시스템은 그렇지 않습니다.

대부분의 조직에서 SQL 파이프라인은 여러 도구에 걸쳐 분산되어 있습니다. 실행을 위한 데이터 웨어하우스, 모델링을 위한 변환 프레임워크, 스케줄링을 위한 오케스트레이터, 그리고 모니터링, 데이터 계보, 데이터 품질을 위한 별도의 시스템들이 그것입니다. 각 계층은 특정 요구 사항을 해결하지만, 이들이 함께 모여 운영하기 어렵고 확장하기 점점 더 힘든 파편화된 환경을 만듭니다.

데이터 팀이 확장됨에 따라 이러한 파편화는 일상적인 운영에서 나타나기 시작합니다. 파이프라인은 여러 시스템에서 실패하고, 종속성을 추적하기 어려우며, 문제를 해결하려면 함께 작동하도록 설계되지 않은 도구들 사이를 오가야 하는 경우가 많습니다. 동시에 기대치도 높아집니다. 팀은 운영 오버헤드를 추가하지 않으면서 더 신선한 데이터를 제공하고, 더 많은 사용 사례를 지원하며, 더 빠르게 움직여야 합니다.

이것이 많은 데이터 플랫폼 전략이 무너지기 시작하는 지점입니다. 조직이 현대적인 인프라에 투자하더라도, SQL ETL은 종종 여러 시스템에 분산된 채로 동일한 복잡성과 제약을 안고 갑니다.

문제는 SQL 자체가 아니라 SQL ETL이 구현되는 방식입니다.

만약 SQL ETL이 오늘날 팀이 실제로 일하는 방식에 맞춰 처음부터 설계되었다면, 모습은 매우 달랐을 것입니다. 실제로는 다음을 의미합니다.

• ETL을 위한 단일 플랫폼
• 모든 SQL 실무자 지원
• 개방적이고 미래 지향적인 파이프라인

이러한 원칙들은 SQL ETL에 대한 더 간단하고 견고한 접근 방식을 정의합니다. 이는 오늘날의 파편화를 줄이면서 데이터 워크로드가 시간이 지남에 따라 발전하는 방식을 지원합니다.

단일 플랫폼에서 SQL ETL 실행 및 운영

SQL ETL의 과제는 변환을 작성하는 것이 아니라, 여러 시스템에 걸쳐 있는 파이프라인을 운영하는 것입니다.

실제로 이는 데이터 웨어하우스에서의 실행 조정, 별도 시스템에서의 오케스트레이션, 그리고 그 이후에 추가되는 관측 가능성을 의미합니다. 파이프라인을 계속 실행하려면 이러한 조각들을 함께 엮어야 합니다. 즉, 컨텍스트를 공유하지 않는 도구들 간에 종속성을 추적하고, 실패를 진단하며, 재시도를 관리해야 합니다.

파이프라인의 수와 중요성이 증가함에 따라, 이러한 조정은 상당한 운영 부담이 됩니다.

통합 플랫폼은 이러한 기능들을 한데 모아 이 모델을 단순화합니다. 실행, 오케스트레이션, 관측 가능성, 거버넌스가 동일한 시스템의 일부일 때, 파이프라인은 설계상 관리하기 더 쉬워집니다. 종속성은 자동으로 추적되며, 관련 컨텍스트가 한곳에 있기 때문에 문제를 더 신속하게 식별하고 해결할 수 있습니다.

Databricks에서는 SQL ETL이 단일 플랫폼 내에서 정의되고 실행됩니다. 파이프라인은 내장된 오케스트레이션으로 실행되며, 데이터 계보와 관측 가능성은 각 단계에서 자동으로 캡처됩니다. 데이터 품질 검사 및 거버넌스 제어는 별도의 도구를 통해 관리되는 대신 파이프라인 실행에 직접 통합됩니다.

이러한 접근 방식은 서버리스 인프라와 AI 기반 최적화를 통해 더욱 강화됩니다. 성능 튜닝, 리소스 관리 및 확장은 자동으로 처리되므로, 팀은 시스템 운영보다는 안정적인 데이터 제공에 집중할 수 있습니다.

Databricks 파이프라인을 서버리스 컴퓨팅으로 전환한 후, HP는 32% 이상의 클라우드 비용 절감과 작업 총 실행 시간 36% 감소를 달성했습니다. 서버리스가 제공하는 손쉬운 인프라 관리는 이 결정을 명확하고 전략적인 선택으로 만들었습니다. — Luis Alonso, HP Marketing 데이터 전략 및 엔지니어링 책임자

그 결과, SQL ETL을 위한 더욱 간소화되고 신뢰할 수 있는 기반이 마련되었습니다. 이는 운영 오버헤드를 줄이면서 대규모 성능과 안정성을 향상시킵니다.

팀이 실제로 SQL 파이프라인을 구축하는 방식 지원

SQL ETL은 도구 때문만이 아니라, 팀마다 파이프라인을 구축하는 방식이 다르기 때문에 파편화되어 있습니다.

SQL에서 비즈니스 로직을 정의하는 데 중점을 두는 분석 엔지니어는 종종 기본 인프라를 관리하지 않고, 테스트, 버전 제어 및 종속성이 자동으로 처리되는 방식으로 파이프라인을 구축하기를 원합니다. 데이터 웨어하우스 엔지니어는 종종 엄격하게 제어되는 실행 환경 내에서 SQL 스크립트와 저장 프로시저에 의존하는 경향이 있습니다. 분석가는 노코드 도구 또는 경량 SQL 인터페이스 내에서 직접 변환을 생성할 수 있습니다.

많은 플랫폼은 암묵적으로 이러한 접근 방식 중 하나를 선호합니다. 조직이 성장함에 따라, 다른 페르소나를 지원하기 위해 추가 시스템을 도입하는 경우가 많으며, 이는 표준화하고 유지 관리하기 어려운 병렬 환경을 초래합니다.

더 효과적인 접근 방식은 인터페이스보다는 플랫폼을 표준화하는 것입니다.

Databricks는 동일한 환경 내에서 다양한 SQL ETL 워크플로를 지원합니다. 팀은 기존 dbt 워크플로를 플랫폼에서 직접 실행하거나, 웨어하우스 스타일 SQL을 스크립트 및 저장 프로시저로 전환하고, Databricks SQL의 Materialized Views로 BI 워크로드를 가속화하며, 프로덕션 워크플로를 단순화하는 선언적 파이프라인을 정의하거나, 동일한 플랫폼에 구축된 비즈니스 분석가를 위한 노코드 도구를 사용할 수 있습니다. 이러한 접근 방식은 파이프라인 작성 방식에서 차이가 있지만, 동일한 실행 엔진, 거버넌스 모델 및 관측 가능성 프레임워크를 공유합니다.

이러한 일관성을 통해 조직은 파이프라인 실행 방식에 파편화를 도입하지 않고도 여러 개발 스타일을 지원할 수 있습니다. 팀은 필요에 맞는 추상화 수준에서 작업하면서도 공유된 데이터 계보, 모니터링 및 운영 제어의 이점을 누릴 수 있습니다.

또한 기존 웨어하우스 스타일 SQL 스크립트와 새로운 접근 방식이 동일한 기반 위에서 공존할 수 있도록 보장합니다. 팀은 기존 방식을 유지할지 새로운 패턴을 채택할지 선택할 필요 없이, 단일 시스템 내에서 두 가지 모두를 수행할 수 있습니다.

이러한 각 워크플로는 전용 작성 환경에 반영됩니다.

1. SQL 스크립트 및 저장 프로시저를 실행하는 데이터 웨어하우스 엔지니어의 경우:

저장 프로시저 및 Materialized Views용 SQL 편집기

">

2. SQL로 프로덕션 파이프라인을 구축하는 분석 엔지니어의 경우:

Spark 선언적 파이프라인 편집기

3. 코드 없이 데이터를 준비하는 분석가 및 비즈니스 사용자의 경우:

Lakeflow Designer

그 결과, SQL ETL을 위한 더욱 응집력 있는 환경이 조성되어 협업이 향상되고 운영 복잡성이 규모에 따라 증가하지 않습니다.

워크로드에 따라 발전하는 SQL 파이프라인 구축

새로운 데이터 소스, 실시간 사용 사례 및 AI 워크로드가 등장함에 따라, 팀은 종종 추가 시스템을 도입하거나 기존 파이프라인을 다시 작성해야 하며, 이는 시간이 지남에 따라 복잡성과 비용을 증가시킵니다.

많은 SQL ETL 솔루션은 독점 형식, 긴밀하게 결합된 실행 모델 또는 데이터 처리 방식에 대한 가정 등을 통해 이러한 제약을 도입합니다. 이러한 제약은 즉시 명확하게 드러나지 않을 수 있지만, 조직이 새로운 워크로드로 확장하거나, 더 신선한 데이터를 요구하거나, 더 광범위한 사용 사례를 지원함에 따라 나타나는 경향이 있습니다.

미래 지향적인 SQL ETL 접근 방식은 처음부터 개방성과 유연성을 우선시합니다.

Databricks는 개방형 테이블 형식과 ANSI SQL을 기반으로 SQL ETL을 구축하여, 파이프라인이 시스템 간에 이식 가능하고 상호 운용 가능하도록 보장합니다. 이는 종속 위험을 줄이고, 조직이 아키텍처가 발전함에 따라 데이터와 로직에 대한 제어권을 유지할 수 있도록 합니다.

동시에 Databricks는 배치 및 실시간 분석 사용 사례를 모두 지원하는 통합 SQL 모델을 제공합니다. 서로 다른 워크로드에 대해 별도의 시스템을 요구하는 대신, 동일한 SQL 기반 접근 방식을 광범위한 사용 사례에 적용할 수 있습니다.

이러한 유연성을 통해 파이프라인은 조직과 함께 발전할 수 있습니다. 팀은 필요에 따라 증분 처리 또는 선언적 파이프라인과 같은 고급 패턴을 채택하면서 기존 SQL 워크플로우를 계속 실행할 수 있습니다.

구체화된 뷰로의 전환은 쿼리 성능을 획기적으로 향상시켜 실행 시간이 8분에서 단 3초로 단축되었습니다. 이를 통해 우리 팀은 데이터를 통해 얻은 인사이트를 바탕으로 더욱 효율적으로 작업하고 더 빠른 의사 결정을 내릴 수 있습니다. 또한, 추가적인 비용 절감 효과도 매우 컸습니다. — Karthik Venkatesan, Adobe 보안 소프트웨어 엔지니어링 선임 관리자

이 접근 방식은 엄격한 아키텍처 제약을 피함으로써 파괴적인 변경 없이 현재 요구 사항과 미래 수요를 모두 지원할 수 있는 안정적인 기반을 제공합니다.

SQL ETL이 데이터 플랫폼 전략을 형성해야 하는 이유

데이터 플랫폼 논의는 종종 데이터가 어디에 저장되고 쿼리가 어떻게 실행되는지에 초점을 맞춥니다. 그러나 실제로는 플랫폼의 효율성이 데이터 파이프라인이 어떻게 구축되고 유지 관리되는지, 그리고 장기적인 종속을 피하는 개방적이고 상호 운용 가능한 방식으로 정의되는지에 달려 있습니다.

SQL ETL이 여러 시스템에 걸쳐 분산되어 있으면, 조직은 새로운 플랫폼을 도입한 후에도 동일한 운영 복잡성과 비효율성을 계속 겪을 가능성이 높습니다. 시간이 지남에 따라 이는 플랫폼의 가치를 제한하고 데이터 운영을 확장하기 어렵게 만듭니다.

더 효과적인 접근 방식은 개발 및 실행부터 모니터링 및 거버넌스에 이르기까지 전체 수명 주기 동안 플랫폼이 SQL ETL을 얼마나 잘 지원하는지 평가하는 것입니다. 여기에는 다양한 작업 스타일을 지원하고, 운영 오버헤드를 줄이며, 추가 시스템 도입 없이 변화하는 요구 사항에 적응하는 능력이 포함됩니다.

Databricks는 단일 플랫폼 내에서 SQL 실행, 파이프라인 관리, 거버넌스 및 최적화를 결합하여 이러한 요구 사항을 해결합니다. 이 통합 접근 방식은 팀이 광범위한 워크로드를 지원할 유연성을 유지하면서 SQL 파이프라인을 보다 효율적으로 구축하고 운영할 수 있도록 합니다.

결론

SQL은 조직이 데이터를 다루는 방식에서 계속해서 핵심적인 역할을 할 것입니다.

결과적으로 SQL ETL이 구현되는 방식은 전체 데이터 플랫폼의 효율성에 직접적인 영향을 미칩니다. 분산된 접근 방식은 복잡성을 야기하고 팀의 속도를 늦추는 반면, 통합된 접근 방식은 운영을 단순화하고 확장성을 향상시킵니다.

데이터 플랫폼을 발전시키는 방법을 평가하는 조직에게 SQL ETL은 핵심 고려 사항입니다. Databricks는 요구 사항이 발전함에 따라 개방적이고 적응력을 유지하면서 단일 플랫폼 내에서 실행, 파이프라인 관리 및 거버넌스를 통합하는 통일되고 미래 지향적인 SQL ETL 모델을 제공합니다.

실제로 대부분의 조직은 처음부터 시작하지 않습니다. SQL ETL 현대화는 종종 프로덕션 파이프라인을 다시 작성하는 비용과 위험이 너무 높기 때문에 지연됩니다. 파괴적인 재구축을 강요하기보다는, 기존 파이프라인을 먼저 실행하고, 시간이 지남에 따라 시스템을 통합하며, 단계별로 현대화하는 방식으로 점진적으로 발전하는 것이 더 효과적인 접근 방식입니다.

이것이 팀이 오늘날의 분산화를 줄이면서 시간이 지남에 따라 더욱 통합되고 미래 지향적인 데이터 플랫폼을 구축할 수 있는 방법입니다. 이 접근 방식에 대해서는 다음 게시물에서 더 자세히 다룰 예정입니다. 그동안 이 전자책 SQL로 ETL 파이프라인 구축 가이드에서 통합 레이크하우스 플랫폼에서 SQL 파이프라인을 구축, 실행 및 확장하는 방법에 대해 자세히 알아볼 수 있습니다.

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