Spark 선언적 파이프라인: 데이터 엔지니어링이 엔드투엔드 선언형이 되어야 하는 이유

데이터 엔지니어링 팀은 더 높은 품질의 데이터를 더 빠르게 제공해야 한다는 압박을 받고 있지만, 파이프라인을 구축하고 운영하는 작업은 더 쉬워지는 것이 아니라 더 어려워지고 있습니다. 저희는 수백 명의 데이터 엔지니어를 인터뷰하고 수백만 개의 실제 워크로드를 연구한 결과 놀라운 사실을 발견했습니다. 데이터 엔지니어들은 대부분의 시간을 코드를 작성하는 데 쓰는 것이 아니라 여러 도구를 엮어 발생하는 운영 부담에 쓰고 있다는 것입니다. 이유는 간단합니다. 기존 데이터 엔지니어링 프레임워크는 데이터 엔지니어가 프로덕션 파이프라인의 일반적인 작업인 오케스트레이션, 증분 데이터 처리, 데이터 품질 및 백필을 모두 수동으로 처리하도록 강요합니다. 데이터 볼륨과 사용 사례가 증가함에 따라 이러한 운영 부담은 가중되어, 데이터 엔지니어링이 비즈니스를 가속화하기는커녕 병목 현상을 유발하게 됩니다.

업계가 이러한 장벽에 부딪힌 것은 이번이 처음이 아닙니다. 초기 데이터 처리에서는 모든 질문에 대해 새로운 프로그램을 작성해야 했으며, 이는 확장성이 떨어졌습니다. SQL은 개별 쿼리를 선언적으로 만들어 이러한 상황을 바꾸었습니다. 원하는 결과가 무엇 인지 지정하면 엔진이 이를 어떻게 계산할지 알아냅니다. 이제 SQL 데이터베이스는 모든 비즈니스의 기반이 됩니다.

하지만 데이터 엔지니어링은 단일 쿼리를 실행하는 것이 전부가 아닙니다. 파이프라인은 시간이 지남에 따라 여러 상호 의존적인 데이터 세트를 반복적으로 업데이트합니다. SQL 엔진은 쿼리 경계에서 멈추기 때문에 그 외의 모든 것, 즉 증분 처리, 종속성 관리, 백필, 데이터 품질, 재시도 등은 여전히 수동으로 구성해야 합니다. 대규모 환경에서는 실행 순서, 병렬 처리 및 실패 모드에 대한 추론이 금세 복잡성의 주된 원인이 됩니다.

부족한 점은 파이프라인 전체를 선언할 방법이 없다는 것입니다. Spark Declarative Pipelines (SDP)는 선언적 데이터 처리를 개별 쿼리에서 전체 파이프라인으로 확장하여 Apache Spark가 엔드투엔드로 계획하고 실행할 수 있도록 합니다. 단계 간에 데이터를 수동으로 이동하는 대신, 어떤 데이터 세트가 존재하기를 원하는지 선언하면 SDP가 시간이 지나도 어떻게 데이터 세트를 올바르게 유지할지 책임집니다. 예를 들어, 주간 판매량을 계산하는 파이프라인에서 SDP는 데이터 세트 간의 종속성을 추론하고, 단일 실행 계획을 수립하며, 올바른 순서로 결과를 업데이트합니다. 신규 또는 변경된 데이터만 자동으로 처리하고, 데이터 품질 규칙을 인라인으로 표현하며, 수동 개입 없이 백필 및 지연 도착 데이터를 처리합니다. SDP는 쿼리 시맨틱을 이해하므로 파이프라인을 사전에 검증하고, 안전하게 병렬로 실행하며, 장애로부터 올바르게 복구할 수 있습니다. 이는 Apache Spark에 직접 내장된 일급(first-class)의, 파이프라인을 인식하는 선언형 API를 필요로 하는 기능입니다.

SDP의 종단간 선언적 데이터 엔지니어링은 강력한 이점을 제공합니다.

• 생산성 향상: 데이터 엔지니어는 글루 코드 대신 비즈니스 로직 작성에 집중할 수 있습니다.
• 비용 절감: 프레임워크가 오케스트레이션과 증분 데이터 처리를 자동으로 처리하므로 직접 작성한 파이프라인보다 비용 효율적입니다.
• 운영 부담 감소: 백필, 데이터 품질, 재시도와 같은 일반적인 사용 사례가 통합 및 자동화됩니다.

엔드투엔드 선언적 데이터 엔지니어링의 이점을 설명하기 위해 PySpark로 작성된 주간 판매 파이프라인부터 시작하겠습니다. PySpark는 엔드투엔드 선언형이 아니므로 실행 순서, 증분 처리, 데이터 품질 로직을 수동으로 인코딩해야 하며, 재시도, 알림, 모니터링을 위해 Airflow와 같은 외부 오케스트레이터에 의존해야 합니다(간결함을 위해 여기서는 생략함).

SQL dbt 프로젝트로 표현된 이 파이프라인은 여러 가지 동일한 한계를 가집니다. 증분 데이터 처리를 여전히 수동으로 코딩해야 하고, 데이터 품질은 별도로 처리되며, 재시도 및 실패 처리를 위해 Airflow와 같은 오케스트레이터에 의존해야 합니다.

이 파이프라인을 SDP로 다시 작성하여 그 이점을 살펴보겠습니다. 먼저 SDP를 설치하고 새로운 파이프라인을 생성해 보겠습니다.

다음으로, 다음 코드를 사용하여 파이프라인을 정의합니다. 커뮤니티와 협력하여 오픈 소스로 공개하기 위해 expect_or_drop 데이터 품질 기대치 API를 주석으로 처리했습니다.

파이프라인을 실행하려면 터미널에 다음 명령어를 입력하세요.

이 명령어를 사용하면 파이프라인을 먼저 실행하지 않고도 미리 검증할 수 있습니다. 구문 오류와 스키마 불일치를 찾아내는 데 유용합니다.

백필이 훨씬 간단해집니다. raw_sales 테이블을 백필하려면 다음 명령어를 실행하세요.

코드는 훨씬 간단하며, PySpark 및 dbt 버전에서 외부 도구를 통해 제공해야 하는 모든 것을 단 20줄로 제공합니다. 또한 다음과 같은 강력한 이점을 얻을 수 있습니다.

• 자동 증분 데이터 처리. 프레임워크는 처리된 데이터를 추적하고 신규 또는 변경된 레코드만 읽습니다. MAX 쿼리, 체크포인트 파일, 조건부 로직이 필요 없습니다.
• 통합된 데이터 품질. @dp.expect_or_drop 데코레이터는 불량 레코드를 자동으로 격리합니다. PySpark에서는 정상/불량 레코드를 수동으로 분할하여 별도의 테이블에 작성했습니다. dbt에서는 별도의 모델이 필요했으며 수동으로 처리해야 했습니다.
• 자동 종속성 추적. 프레임워크는 weekly_sales 가 raw_sales 에 종속된다는 것을 감지하고 실행 순서를 자동으로 오케스트레이션합니다. 외부 오케스트레이터가 필요하지 않습니다.
• 통합된 재시도 및 모니터링. 프레임워크는 기본 내장 UI를 통해 실패를 처리하고 관측 가능성을 제공합니다. 외부 도구가 필요 없습니다.

Apache Spark 4.1 의 SDP는 데이터 파이프라인에 탁월한 선택이 되도록 하는 다음과 같은 기능 을 갖추고 있습니다.

• 데이터세트 정의를 위한 Python 및 SQL API
• 배치 및 스트리밍 쿼리 지원
• 데이터세트 간의 자동 종속성 추적 및 효율적인 병렬 업데이트
• 로컬 또는 프로덕션에서 파이프라인을 스캐폴드, 검증, 실행하기 위한 CLI

저희는 Spark 커뮤니티와 함께 공개적으로 개발 중인 SDP의 로드맵에 대해 기대가 큽니다. 향후 Spark 릴리스는 이 기반을 바탕으로 연속 실행 및 더 효율적인 증분 처리를 지원할 것입니다. 저희는 또한 실제 사용 사례와 커뮤니티 피드백을 바탕으로 변경 데이터 캡처(CDC)와 같은 핵심 기능을 SDP에 도입할 계획입니다. 우리의 목표는 Spark 생태계 전반에 걸쳐 안정적인 배치 및 스트리밍 파이프라인을 구축하기 위해 SDP를 공유 가능하고 확장 가능한 기반으로 만드는 것입니다.

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