쿼리 태그가 있는 dbt 파이프라인의 세분화된 사용량 속성 - 복제됨

여러분의 dbt 프로젝트는 매일 밤 80개의 모델을 실행합니다. 창고 비용은 지난 분기에 두 배로 늘었습니다. 모델 성능은 매우 다양하며 가장 최근의 최적화의 효과도 명확하지 않습니다. 재무부는 어느 팀이 책임을 맡았는지 묻습니다. 쿼리 기록을 열면 'Databricks Dbt'라는 레이블이 붙은 80개의 동일한 행을 볼 수 있습니다. 행운을

빈다. 쿼리 태그(현재 공개 미리보기로 제공됨)를 사용하면 데이터 팀은 이제 모든 실행을 풍부하게 해주는 dbt_model_name과 같은 기본 자동 삽입 태그를 활용할 수 있습니다. 또한 파이프라인이 생성하는 모든 쿼리에 팀, 비용 센터, 환경 등 원하는 항목에 대한 고유한 사용자 지정 태그를 첨부할 수도 있습니다.

태그는 system.query.history에 기록되므로 비용 속성, 성능 디버깅 및 워크로드 모니터링을 간단한 SQL 쿼리로 수행할 수 있습니다(자세한 내용은 문서 참조).

이 블로그에서는 구성부터 비용 속성 대시보드에 이르기까지 쿼리 태그를 종합적으로 보여주는 완전한 오픈소스 dbt 프로젝트를 살펴봅니다. 여기에 설명된 모든 내용은 GitHub 저장소로 제공되며, 이를 복제하여 자체 작업 공간에 배포하거나 Genie에게 문의할 수

있습니다.dbt-databricks가 쿼

리 태그와 통합되는 방법dbt-databricks 어댑터(버전 1.11 이상)는 쿼리 태그를 기본적으로 지원합니다. 태그를 적용할 수 있는 레벨은 세 가지이며, 각 레벨은 이전 레벨을 기반으로 합니다.

자동 주입된 태그

사용자 지정 태그 외에도 dbt-databricks는 각 모델 실행에 대한 메타데이터를 자동으로 주입합니다.

이러한 자동 태그는 구성이 없어도 모델별로 가시성을 제공한다는 것을 의미합니다—어댑터가 이를 대신해 줍니다.

프로필 수

준 태그가장 간단한 방법은 dbt 프로필의 특정 대상에 query_tags 필드를 추가하는 것입니다. 프로젝트의 모든 쿼리는 이러한 태그를 자동으로 상속합니다.

예를 들어 이 단일 줄은 모든 쿼리에 4가지 차원의 태그를 지정합니다. 즉, 해당 쿼리의 소유자(팀), 비용이 발생하는 곳(cost_center), 해당 쿼리가 속한 파이프라인(project_name), 해당 쿼리가 실행되는 환경(env).

모델 수준 태

그보다 세부적인 속성을 위해, dbt_project.yml에서 특정 모델에 대한 태그를 제공하거나 해당 SQL 정의에서 모델 설정을 제공할 수 있습니다. 

모델 수준 태그는 프로파일 수준 태그와 병합됩니다. 둘 다 동일한 키를 정의한 경우 모델 수준 값이 우선합니다.

곳 – system.query.history

dbt run을 실행한 후, 모든 SQL 문장은 query_tags 열이 MAP으로 채워진 상태로 system.query.history에 나타납니다. 표준 지도 액세스 구문을 사용하여 질의할 수 있습니다.

이 옵션은 사용자 정의 태그 및 자동 삽입된 태그를 개별 열에 추출하여 집계할 준비가 된 상태로 지난 7일 동안의 모든 태그가 반환됩니다.

쿼리 기록 UI 또는 SQL 웨어하우스 모니터링 UI에서 실행한 쿼리의 쿼리 태그를 찾을 수도 있습니다.

페이지에서 쿼리 프로필의 오른쪽 하단에는 사용자가 정의한 쿼리 태그가 표시되므로 필요한 모든 정보를 한 눈에 볼 수 있습니다.

쿼리 태그를 사용한 비용

속성쿼리 태그를 사용하면 SQL 쿼리를 통해 직접 세부적인 사용 속성을 결정할 수 있습니다. 수동 로그 분석을 수행하거나 웨어하우스 리소스를 분할할 필요가 없습니다.

어떤 dbt 모델이 웨어하우스 리소스를 가장 많이 사용합니까?

이 질문에 답할 수 있는 두 가지 방법은 간단합니다. 즉, Genie에게 임시 탐색을 요청하거나 반복 가능하고 대시보드에서 사용할 수 있는 결과를 얻기 위해 직접 SQL을 작성하는 것입니다. 둘 다 동일한 시스템.쿼리.기록 데이터를 읽습니다.

옵션 1: Genie

Genie는 동등한 쿼리를 작성하고 실행하며, SQL을 건드리지 않고도 후속 질문을 계속 드릴링합니다.

옵션 2: SQL

두 경로 모두 동일한 그림을 반환합니다. 당사의 레퍼런스 프로젝트에서 4개의 마트 테이블(테이블로 구체화됨)이 컴퓨팅 시간을 주도하고 스테이징 뷰와 메트릭 뷰는 거의 즉각적입니다. 이를 통해 최적화 노력의 초점을 맞추어야 할 부분을 즉시 알 수 있습니다.자체 모니터링 대시보드

구축당사의 참조 프로젝트에는 프로젝트의 자체 쿼리 태그로 필터링된 system.query.history에 쿼리를 수행하는 AI/BI 대시보드가 포함되어 있습니다. 그 결과 청구 데이터를 분석하는 파이프라인은 자체 비용도 추적하여 자체적으로 쿼리 태그를

먹입니다.대시보드에는 다음이 포함됩니다.

• KPI: 총 태그가 지정된 쿼리, 총 컴퓨팅 시간(초), 고유한 dbt 모
• 델일일 활동: 환경별로 분할
• 된 일일 쿼리 수 및 컴퓨팅 시간모델 분석: 구체화 유형별로 색상이 지정된 모델당 계산 시간
• Materialization 분할: 테이블, 뷰 및 metric_view
• Query 세부 정보 테이블에 컴퓨팅이 어떻게 분배되는지 보여주는 원형 차트: 모델, 기간, 환경 및 실행

자를 포함한 태그가 지정된 모든 쿼리에서 우리의 레퍼런스 프로젝트에서 4개의 마트 모델이 컴퓨팅 시간의 92%를 차지했으며, 쿼리 태그가 없으면 이러한 인사이트는 보이지 않았습니다.이 대시보드를 직접

구축하는 데는 몇 분이 걸립니다: 질의 태그로 필터링된 system.query.history에서 dbt 모델당 컴퓨팅 시간을 요청하면 이 시스템이 SQL을 작성하고 시각적 자료를 조합합니다. 완성된 결과로 바로 건너뛰기를 원한다면 대시보드도 참조 프로젝트에 포함되어 있으며 dbt 작업과 함께 하나의 데이터베이스 브릭 번들 배포와 함께 배포됩니다(자세한 지침은 Github 저장소 참조).

메트릭

뷰 태깅데이터베이스 메트릭 뷰(dbt-databricks 1.12+에서 사용 가능)는 Unity 카탈로그에서 직접 차원 및 측정값 형태로 재사용 가능한 비즈니스 의미론을 정의하는 새로운 구체화 유형입니다(전체 문서 참조). 이 모델은 query_tags 구성 매개변수를 사용하여 다른 모델과 마찬가지로 쿼리 태그를 전달할 수 있습니다.

유의하십시오: query_tags는 메트릭 뷰를 생성하거나 새로 고치는 SQL 쿼리에 연결되며(system.query.history에서 추적됨), databasericks_tags는 오브젝트 자체의 Unity 카탈로그 태그입니다(거버넌스 및 검색을 위해). 전자는 쿼리 수준 추적을 위한 것이고, 후자는 전반적인 데이터 검색 가능성을 위한 Unity 카탈로그 객체 수준입니다. 

db

t 프로젝트에 태그를 지정하기 위한 모범 사례이 기사에서는 쿼리 태그가 비용 기여의 기본이 되는 견고한 FinOps 사례를 구축하기 위한 총체적인 프로세스를 설명했습니다. 다음은 참조 프로젝트를 구축하고 DBT 고급 사용자들과 대화하면서 배운 내용입니다.

• 일관된 태그 계층 구조를 사용하십시오. 프로필 수준에서 조직 전체의 태그를 정의하고(팀, 비용_센터, 프로젝트_이름, 환경), 예외적인 경우를 위해 모델 수준의 태그를 예약하세요. 이를 통해 태그를 예측 가능하게 유지하고 모델별 구성의 무분별한 증가를 방지할 수 있습니다.
• 항상 환경에 태그를 지정하십시오. 로컬 개발(local-dev)과 배포된 작업(dev, staging, prod)에 대해 서로 다른 env 값을 사용하세요. 이를 통해 분석에서 임시 개발 쿼리를 예약된 프로덕션 실행과 분리할 수 있습니다. 우리의 레퍼런스 프로젝트에서 로컬 프로파일은 "env": "local-dev"를 설정하고 배포된 프로파일은 "env": "dev"를 설정합니다.
• `project_name`을 사용하여 파이프라인을 구별하십시오. 여러 dbt 프로젝트가 하나의 웨어하우스를 공유할 때, project_name을 사용하면 웨어하우스를 분할하지 않고도 파이프라인당 비용을 속성화할 수 있습니다. 자동 주입된 @@dbt_model_name과 결합하면 프로젝트 → 모델 → 구체화에서 완전한 추적 가능성을 얻을 수 있습니다.
• 과도한 태그를 사용하지 마십시오. 자동 삽입된 태그에는 이미 모델 이름, 구체화 유형 및 어댑터 버전이 포함되어 있습니다. 이 정보를 사용자 지정 태그에 복제할 필요는 거의 없습니다. DBT가 추론할 수 없는 비즈니스 컨텍스트(팀 소유권, 비용 센터, 프로젝트 정체성)에 맞춰 사용자 지정 태그를 설정하세요. 메트릭 뷰에 명시적으로
• 태그를 지정하세요. 메트릭 뷰는 새로운 구체화이므로 비용 분석에서 메트릭 뷰 생성 쿼리를 쉽게 필터링할 수 있도록 기능 키(예: "feature": "metric_view")로 태그를 지정하는 것이

유용합니다.직접 시도해보세

요.전체 참조 프로젝트는 GitHub에서 사용할 수 있습니다. github.com/databricks-solutions/dbt-query-tags

시작하기:

1. 저장소를 복제합니다.
2. Python 3.12 가상 환경을 만들고 종속성을 설치합니다. pip install dbt-databricks>=1.12.0a1
3. 작업 공간 호스트, SQL 웨어하우스 HTTP 경로, 카탈로그 및 사용자 지정 쿼리 태그를 사용하여 profiles.yml을 업데이트합니다.
4. dbt deps 실행 && dbt run --profiles-dir . 파이프라인
5. 쿼리 system.query.history를 실행하여 작업의 태그를 확인하십시오. 올바른 구성을 가리키도록
6. dbt_profiles/profiles.yml 및 databricks.yml을 업데이트하십시오.
7. 데이터브릭스와 함께 배포 예약된 실행을 위해 번들 배포 및 분석 대시보드를 고유한 팀 및 비용 센터 값으로 Swap하십시오.

이 패턴은 Databricks의 모든 dbt 프로젝트에 적용됩니다.

지금 바로 저장소를 복제하세요! 전체 웨어하우스에 걸쳐 모델 수준의 사용 속성 가시성을 잠금 해제하려면 프로필에 한 줄만 있으면 됩니다.

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