쿼리 태그가 있는 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 필드를 추가하는 것입니다. 프로젝트의 모든 쿼리는 이러한 태그를 자동으로 상속합니다.

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

모델 수준 태그

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

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

태그가 나타나는 위치 – system.query.history

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

이 기능은 지난 7일 동안의 모든 태그가 지정된 쿼리를 반환하며, 사용자 지정 태그와 자동 삽입된 태그가 개별 열에 추출되어 집계할 준비가 되어 있습니다.

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

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

쿼리 태그를 사용한 비용 속성

쿼리 태그를 사용하면 SQL 쿼리를 통해 직접 세분화된 사용 속성을 확인할 수 있으므로 수동 로그 분석이나 웨어하우스 리소스를 분할할 필요가 없습니다.

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

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

옵션 1: 지니

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

옵션 2: SQL

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

자체 모니터링 대시보드 구축

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

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

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

우리의 레퍼런스 프로젝트에서 4개의 마트 모델이 컴퓨팅 시간의 92%를 차지했으며, 쿼리 태그가 없었더라면 이러한 통찰력은 눈에 띄지 않았습니다.

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

메트릭 뷰에 태그 지정

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

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

dbt 프로젝트에 태그를 지정하기 위한 모범 사례

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

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

직접 해보십시오

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

시작하는 방법은 다음과 같습니다.

1. 저장소 복제
2. 파이썬 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. 예약된 실행 및 분석 대시보드를 위한 데이터브릭과 함께 배포 번들 배포

고유한 팀 및 비용 센터 값을 바꾸십시오. 이 패턴은 Databricks의 모든 dbt 프로젝트에 적용됩니다.

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

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