스키마 생성과 커스터마이징 이해하기
스키마 생성과 커스터마이징 이해하기
dbt는 기본 매크로 generate_schema_name을 사용해 모델을 어디에 빌드할지 결정해요. 기본적으로 dbt 환경이나 프로필에서 지정한 target 스키마(target.schema)를 사용해요. dbt 프로젝트 객체를 실행하면 dbt는 dbt_projects_profiles.yml 또는 profiles.yml에 지정된 target 스키마가 아직 없으면 그 스키마를 만들려고 시도해요. 두 파일이 모두 존재하면 Snowflake는 dbt_projects_profiles.yml을 사용해요.
출처: Snowflake 문서
본문
일반적으로 각 개발자는 analytics_dev 같은 자신만의 target 스키마를 가져요. 더 큰 프로젝트에서는 커스텀 스키마를 설정해 모델을 그룹화하고 dbt_project.yml 파일에 schema 구성 키를 지정할 수 있어요. dbt는 이를 target 스키마에 덧붙여(예: <target_schema>_<custom_schema>) 중간 단계 모델과 사용자용 모델을 분리해요.
# models/tasty_bytes/ 의 모델은 "*_staging" 스키마에 빌드됩니다.
models:
tasty_bytes:
+schema: staging
모델의 커스텀 스키마는 target 스키마를 대체하지 않아요. dbt는 두 스키마를 결합해 충돌을 피해요. 예를 들어 analytics_dev_staging 형태가 돼요.
그 이유는 dbt가 target 스키마를 무시하고 커스텀 스키마만 사용한다면(여기서는 staging) 모든 개발자가 같은 스키마에 쓰게 되어 서로 덮어쓸 수 있기 때문이에요.
다른 동작을 원한다면(예: 커스텀 스키마만 사용, 사용자 이름 접두사, 환경 접두사 추가 등) /macros/에서 generate_schema_name을 재정의해 최종 스키마 이름이 만들어지는 방식을 바꿀 수 있어요. 자세한 내용과 예시는 dbt 문서의 dbt가 스키마 이름을 생성하는 방식 변경 문서를 참조하세요.
예시: 스키마 출력에 target 이름 사용하기
같은 스키마를 공유하는 두 개의 target이 있는 profiles.yml을 생각해 보세요.
finance_project:
target: dev
outputs:
dev:
schema: analytics
...
prod:
schema: analytics
...
다음 dbt_project.yml은 models/analytics/ 아래 모든 모델에 커스텀 스키마를 설정해요.
models:
analytics:
+schema: finance
기본 generate_schema_name 매크로를 사용하면 models/analytics/ 아래 모든 모델이 analytics_finance 스키마에 빌드돼요. 이는 프로젝트의 폴더 구조가 스키마 이름을 직접 결정한다는 뜻이며, 모든 팀에 적합하지 않을 수 있어요. 다음 매크로는 이 동작을 재정의해 target 이름 접미사를 가진 커스텀 스키마를 대신 사용해요.
-- macros/generate_schema_name.sql
{% macro generate_schema_name(custom_schema_name, node) -%}
{%- set env_suffix = target.name | lower -%}
{%- set default_schema = target.schema -%}
{%- if custom_schema_name is none -%}
{{ default_schema }}
{%- else -%}
{{ custom_schema_name | trim }}_{{ env_suffix }}
{%- endif -%}
{%- endmacro %}
이 재정의를 사용하면 models/analytics/ 아래 모든 모델이 finance_dev(dev target으로 실행 시) 또는 finance_prod(prod target으로 실행 시)에 빌드돼요.