런 캐싱으로 데이터 웨어하우스 비용 절감

이전에 언급했듯이 Dataform의 핵심 설계 목표 중 하나는 프로젝트 컴파일을 기밀로 만드는 것입니다. 아이디어는 '증분' 테이블 지원과 같이 엄격하게 제어되는 몇 가지 예외를 제외하고 동일한 입력(프로젝트 코드)이 주어졌을 때 최종 ELT 파이프라인을 가능한 한 재현할 수 있도록 하는 것입니다.

Dataform 파이프라인의 코드에 대해 이런 식으로 추론할 수 있다는 것은 Dataform 프레임워크에 몇 가지 멋진 기능을 구축할 수 있는 기회를 제공합니다. 예는 "run caching" feature 입니다.

동일한 데이터를 다시 계산하는 데 시간과 비용을 낭비하지 마십시오.

대부분의 분석 파이프라인은 일정의 일부로 주기적으로 실행됩니다. 일반적으로 이러한 일정은 비즈니스에서 요구하는 최신 데이터를 최신 상태로 유지하기 위해 필요한 만큼 자주 실행되도록 구성됩니다.

불행히도 이것은 자원 낭비로 이어질 수 있습니다. 한 시간에 한 번 실행되는 파이프라인을 고려하십시오. 입력 데이터가 한 번의 실행과 다음 실행 간에 변경되지 않으면 다음 실행에서는 출력 데이터가 변경되지 않지만 실행하는 데 여전히 시간과 비용이 듭니다.

대신 우리는 파이프라인이 출력 데이터를 변경하지 않을 경우 자동으로 감지해야 한다고 생각합니다. 그렇다면 영향을 받는 단계를 건너뛰어 해당 리소스를 절약해야 합니다.

이 기능을 Dataform에 내장했습니다.

Dataform에서 캐싱 실행

Try out an example project with run caching here!

here 에 설명된 몇 가지 작은 변경으로 프로젝트에서 캐싱 실행을 켤 수 있습니다. 활성화되면 캐싱 실행은 출력 데이터를 변경할 수 없는 코드의 재실행을 건너뜁니다.

예를 들어, age_count 관계를 읽는 쿼리의 변환된 결과를 포함하는 테이블 people을 게시하도록 Dataform을 구성하는 다음 SQLX 파일을 고려하십시오.

config { name: "age_count", type: "table" }

select age, count(1) from ${ref("people")} group by age

Dataform은 다음 조건 중 하나라도 해당되는 경우에만 이 테이블을 (재)게시해야 합니다.

출력 테이블 age_count이 존재하지 않습니다

이 테이블이 마지막으로 게시된 이후로 출력 테이블 age_count이 변경되었습니다(즉, Dataform 자체가 아닌 다른 것에 의해 수정됨)

age_count 테이블이 마지막으로 게시된 이후 쿼리가 변경되었습니다.

people 테이블이 마지막으로 게시된 이후로 입력 테이블 age_count이 변경되었습니다(또는 people이 뷰인 경우 people에 대한 입력이 변경된 경우) 10

Dataform은 이러한 규칙을 사용하여 테이블을 게시할지 여부를 결정합니다. 모든 테스트가 실패하면, 즉 테이블을 다시 게시해도 출력 테이블이 변경되지 않으면 이 작업을 건너뜁니다.

할 필요가 없도록 지능을 구축합니다.

Dataform은 분석 워크로드 실행과 관련된 인프라를 관리할 필요가 없다고 생각합니다.

이 철학은 분석 워크로드를 자동으로 관리하고 운영하는 데 도움이 되는 런 캐싱과 같은 기능을 구축하여 귀하가 필요하지 않도록 하는 원동력입니다. 비즈니스 논리 변환을 정의하기만 하면 나머지는 저희가 처리합니다.

더 자세히 알고 싶다면 Dataform 프레임워크 문서는 here 입니다. Slack에서 우리와 함께하고 당신의 생각을 알려주세요!