데이터 파이프라인 포켓 리퍼런스

9장. 파이프라인 유지 관리를 위한 모범 사례

이 작품은 AI를 사용하여 번역되었습니다. 여러분의 피드백과 의견을 환영합니다: [e-mail]

지금까지 이 책은 데이터 파이프라인을 구축하는 데 중점을 두었습니다. 이 장에서는 복잡성이 증가하고 파이프라인이 의존하는 시스템의 불가피한 변화에 대처할 때 이러한 파이프라인을 유지 관리하는 방법에 대해 설명합니다.

소스 시스템의 변경 사항 처리

데이터 엔지니어의 가장 일반적인 유지 관리 과제 중 하나는 데이터를 수집하는 시스템이 정적이지 않다는 사실을 다루는 것입니다. 개발자는 항상 기능을 추가하거나, 코드베이스를 리팩토링하거나, 버그를 수정하는 등 소프트웨어를 변경하고 있습니다. 이러한 변경으로 인해 수집할 데이터의 스키마나 의미가 변경되면 파이프라인이 실패하거나 부정확해질 위험이 있습니다.

이 책 전반에 걸쳐 설명했듯이, 현대 데이터 인프라의 현실은 매우 다양한 소스에서 데이터가 수집된다는 것입니다. 따라서 소스 시스템의 스키마 및 비즈니스 로직 변경을 처리하기 위한 일률적인 솔루션을 찾기가 어렵습니다. 그럼에도 불구하고 몇 가지 모범 사례에 투자할 것을 권장합니다.

추상화 소개

가능하면 소스 시스템과 수집 프로세스 사이에 추상화 계층을 도입하는 것이 가장 좋습니다. 소스 시스템의 소유자가 추상화 방법을 유지하거나 알고 있는 것도 중요합니다.

예를 들어, Postgres 데이터베이스에서 직접 데이터를 수집하는 대신 데이터베이스 소유자와 협력하여 데이터베이스에서 가져오고 데이터 추출을 위해 쿼리할 수 있는 REST API를 구축하는 것을 고려해 보세요. API가 단순히 패스스루일지라도 소스 시스템의 소유자가 관리하는 코드베이스에 존재한다는 사실은 시스템 소유자가 어떤 데이터가 추출되는지 알 수 있고 Postgres 애플리케이션 데이터베이스의 내부 구조 변경에 대해 걱정할 필요가 없음을 의미합니다. 데이터베이스 테이블의 구조를 수정하려는 경우 API를 수정해야 하지만 다른 코드가 이 테이블에 의존할 수 있다는 점을 고려할 필요가 없습니다.

또한 소스 시스템의 변경으로 인해 지원되는 API 엔드포인트에 포함된 필드가 제거되는 경우 어떻게 해야 할지에 대한 양심적인 결정을 내릴 수 있습니다. 해당 필드가 시간이 지남에 따라 단계적으로 제거되거나 과거 데이터로 지원되지만 앞으로는 NULL이 될 수도 있습니다. 어느 쪽이든 명시적 추상화 계층이 존재할 때 변경 사항을 처리해야 할 필요성을 인식하고 있습니다.

REST API는 추상화를 위한 유일한 옵션이 아니며 때로는 가장 적합하지 않을 수도 있습니다. Kafka 토픽을 통해 데이터를 게시하는 것은 이벤트를 게시하는 소스 시스템과 이벤트를 구독하는 시스템(수집)의 세부 사항을 서로 완전히 분리하면서 합의된 스키마를 유지할 수 있는 훌륭한 방법입니다.

데이터 계약 유지 관리

소스 시스템의 데이터베이스에서 직접 또는 추출을 위해 명시적으로 설계되지 않은 방법을 통해 데이터를 수집해야 하는 경우, 데이터 계약을 ...