[DE] dbt(data build tool) - SQL을 코드처럼 관리하는 도구

데이터 웨어하우스에 데이터를 쌓는 것보다 어려운 것은 쌓인 데이터를 신뢰할 수 있게 유지하는 것이다.
dbt는 이 문제를 해결하기 위해 만들어진 도구이다.

 

 

dbt가 생긴 이유

• dbt 이전의 데이터 변환 작업
  • SQL 파일이 수백 개가 되면 관리가 불가능해진다.
    1. 어떤 순서로 실행해야 하는지 알 수 없다.
    2. 누가 언제 수정했는지 추적이 안된다.
    3. 테스트가 없어서 데이터가 깨져도 한참 뒤에 알게 된다.
    4. 같은 로직을 여러 파일에서 중복으로 작성한다.

transformation_v1.sql
transformation_v1_final.sql
transformation_v1_final_진짜최종.sql
transformation_v2_수정.sql

 

• dbt는 이 문제들을 한 번에 해결한다.

 

핵심 개념 1 - 레이어 구조

• dbt는 SQL 파일을 역할에 따라 세 레이어로 나눠서 관리한다.

models/
├── staging/        ← 소스 데이터를 그대로 올리는 레이어
│   ├── stg_orders.sql
│   └── stg_customers.sql
├── intermediate/   ← 중간 변환 레이어
│   └── int_orders_with_customers.sql
└── marts/          ← 최종 분석용 레이어 (Star Schema)
    ├── fct_orders.sql
    └── dim_customers.sql

 

• 각 레이어의 역할은 명확하다.
  • staging : 소스 원본 데이터를 그대로 올리되, 컬럼명과 타입만 정리한다.
  • intermediate : staging 데이터를 조인하거나 가공하는 중간 단계다.
  • marts : 분석가나 BI 도구가 직접 사용하는 최종 테이블이다.

 

핵심 개념 2 - ref()로 의존성 선언

• dbt에서 테이블 간 참조는 '{{ ref() }}'로 선언한다.

-- marts/fct_orders.sql
SELECT
    o.order_id,
    o.customer_id,
    o.amount,
    c.region
FROM {{ ref('stg_orders') }} o
LEFT JOIN {{ ref('stg_customers') }} c
    ON o.customer_id = c.customer_id

 

• {{ ref() }} 하나로 두 가지가 해결된다.
  • dbt가 자동으로 실행 순서를 결정한다. (DAG 생성)
  • 'stg_orders'가 완료되지 않으면 'fct_orders'는 실행되지 않는다.

 

 

핵심 개념 3 - 데이터 테스트

• dbt test는 데이터 파이프라인에서 데이터가 깨진 줄 모르고 대시보드가 계속 돌아가는 상황을 방지한다.

1. Generic Test - 내장 테스트

• 'schema.yml'에 선언만 하면 된다. SQL을 직접 작성하지 않아도 된다.
• dbt 내장 Generic Test는 4종 : 'unique', 'not_null', 'accepted_values', 'relationships'

models:
  - name: fct_orders
    columns:
      - name: order_id
        tests:
          - unique        # 중복 행 없어야 함
          - not_null      # null 없어야 함

      - name: status
        tests:
          - accepted_values:
              values: ['placed', 'shipped', 'delivered', 'cancelled']

      - name: customer_id
        tests:
          - not_null
          - relationships:
              to: ref('dim_customers')
              field: customer_id  # FK 무결성 검사

 

2. Singular Test - 커스텀 테스트

• 비즈니스 로직에 맞는 테스트는 SQL 파일로 직접 작성한다.
• 핵심 원칙 : 결과가 0건 = 통과, 1건 이상 = 실패
• 문제가 있는 데이터를 찾는 쿼리를 작성하고, 그 결과가 없어야 테스트를 통과한다.

-- tests/assert_revenue_is_positive.sql
-- 환불 건을 제외한 주문의 revenue는 항상 양수여야 한다.

SELECT order_id
FROM {{ ref('fct_orders') }}
WHERE status != 'refunded'
  AND revenue <= 0

 

 

확장 패키지 - dbt-expectations

• 더 풍부한 테스트가 필요하면 'dbt-expectations' 패키지를 쓴다.

- name: amount
  tests:
    - dbt_expectations.expect_column_values_to_be_between:
        min_value: 0
        max_value: 10000000

- name: ordered_at
  tests:
    - dbt_expectations.expect_column_values_to_be_of_type:
        column_type: timestamp

 

 

테스트 심각도 설정

• 모든 테스트 실패가 파이프라인을 멈춰야 하는 건 아니다.
  • 비즈니스 임팩트가 큰 테스트는 'error', 참고용은 'warn'으로 나눠서 관리한다.

- name: order_id
  tests:
    - unique:
        severity: error   # 실패 시 파이프라인 중단 (기본값)
    - not_null:
        severity: warn    # 실패해도 경고만, 파이프라인은 계속

 

 

레이어별 테스트 전략

• 레이어가 올라갈수록 테스트를 더 엄격하게 적용한다.
  • 상위 레이어로 올라올수록 이미 걸러진 데이터이기 때문에 최종 Mart에서 문제가 발견되면 그만큼 더 심각한 이슈

staging 레이어			-> not_null, unique, accepted_values (기본 검사)
intermediate 레이어	-> relationships, 비즈니스 룰 (변환 로직 검사)
marts 레이어 			-> row count, 값 범위, 날짜 연속성 (가장 엄격하게)

 

 

AirFlow와 연동

• 모델 실행 -> 테스트 -> 통과하면 대시보드 갱신. 테스트가 실패하면 깨진 데이터가 대시보드에 올라가지 않는다.

run_dbt_models = BashOperator(
    task_id = 'dbt_run',
    bash_command = 'dbt run --select marts'
)

run_dbt_test = BashOperator(
    task_id = 'dbt_test',
    bash_command = 'dbt test --select marts'
)

load_to_dashboard = BigQueryOperator(...)

run_dbt_models >> run_dbt_tests >> load_to_dashboard

 

 

전체 데이터 흐름에서 dbt의 위치

• ELT 구조에서 T(Transform)를 담당하는 것이 dbt.
• Airflow가 '언제, 어떤 순서로 실행할지'를 결정한다면, dbt는 '데이터를 어떻게 변환할지'를 담당한다.

[OLTP: MySQL / PostgreSQL]
         ↓
  Airbyte / Fivetran       ← Extract & Load
         ↓
  [Raw 데이터: BigQuery]
         ↓
        dbt                ← Transform (여기가 dbt)
         ↓
  [Marts: Star Schema]
         ↓
   Looker / Tableau