[dbt] dbt 도입 이유와 필요성 | LIM

dbt란 무엇인가

data build tool 의 약자로, 추출 -> 변형 -> 적재 중 변형을 더 쉽게 하기 위한 도구이다. 

Transformation 만을 위한 도구이기 때문에 Extract나 Load 를 위해서는 다른 도구와 같이 사용해야 한다.

 

ETL 보다는 ELT 작업에 좀 더 적합한 툴이다. 

위 그림에서 보다시피 Raw Data 에서 Transformation 즉, 변형을 dbt 툴에서 관리하고, 각 데이터 소비자들에게 필요한 Data Mart 를 관리해주는 것이 dbt 의 역할이다. 

 

 

dbt 도입의 필요성

현재 우리회사는 BigQuery를 거의 Data Lake + Data WareHouse 의 개념으로 사용하고 있다.

전사 내 모든 데이터를 BigQuery에 저장하기로 했고, 그 결과 BigQuery에는 그야말로 Big 저장소가 되어가고 있다.

 

물론, 한 곳에서 데이터를 관리하는 것은 매우 좋은 것이라고 생각한다. 

하지만 SQL 기반으로 데이터를 처리하는 것의 가장 안 좋은 점(?) 이라고 할 수 있다면 코드로 관리가 안된다는 것이다. 

 

dbt 를 사용하면 빅쿼리에서 사용하는 SQL 쿼리들을 코드로써 관리할 수 있고, 코드로 관리할 수 있기 때문에 재사용이 용이하다는 장점이 있다. 

 

또한, 많은 데이터가 빅쿼리에 저장되면서 누가 어떤 걸 만들었고, 어떻게 관리되고 있는 지 전혀 모니터링이 안된고 있다.

빅쿼리는 RDBMS에 비해 만들기 쉽다. 만들기 쉽다는 것 때문에 관리가 안된다.

하지만 dbt를 사용한다면 데이터 오너쉽을 관리할 수 있기 때문에 히스토리 추적이 좀 더 수월해진다.

 

즉, dbt 를 사용한다면 다음과 같은 것들을 개선할 수 있다. 

1. SQL 쿼리를 코드로 관리
2. 데이터 오너쉽
3. 데이터 의존성 파악

 

데이터 의존성 파악은 data lineage 로 어떤 테이블들을 이용해서 데이터 마트 혹은 어떤 다른 테이블이 구성되었는 지 한눈에 파악하기 쉬워진다. 

 

- 고객 테이블

- 주문 테이블

- 지불 테이블

 

위 세개의 테이블을 이용해서 거래 테이블인 Data Mart 를 구축했다고 했을 때, 각각 어떤 테이블들을 이용해서 거래 테이블이 나왔는 지 한눈에 파악이 가능해진다.

 

 

이러한 Lineage 를 빅쿼리에 이용한다면 여러 테이블을 조합해 만든 View 테이블들을 관리하기 수월해진다. 

View 에 대한 설명은 여기에 정리해두었다. 

https://amazelimi.tistory.com/entry/MySQL-View-%EB%9E%80

[MySQL] View 란? | LIM

 

 

dbt 용어 정리

dbt 용어 및 기본 개념에 대해 매우 잘 정리되어있다. 

https://www.humphreyahn.dev/blog/efficient-elt-pipelines-with-dbt

dbt로 ELT 파이프라인 효율적으로 관리하기

 

 

dbt Materialization

dbt에서 가장 중요한 개념이다. dbt 모델을 data warehouse 에서 사용하기 위한 전략이라고 생각하면 될 것 같다. 

이 부분을 학습하는데 특히 Incremental 전략을 사용하는데 러닝커브가 있을 것 같다.

 

먼저 dbt Materialization 전략은 아래와 같다.

• table
• view
• incremental
• ephemeral

 

default 설정은 view 로 되어있다. Materialization 을 따로 설정하지 않고 작성한 쿼리를 실행시키면 view 가 생성된다.

 

dbt_project.yml

# The following dbt_project.yml configures a project that looks like this:
# .
# └── models
#     ├── csvs
#     │   ├── employees.sql
#     │   └── goals.sql
#     └── events
#         ├── stg_event_log.sql
#         └── stg_event_sessions.sql

name: my_project
version: 1.0.0
config-version: 2

models:
  my_project:
    csvs:
      +materialized: view

 

 

View

View 로 설정하면 dbt 모델을 실행시켰을 때 create view 가 실행된다.

• Pros: view 는 데이터를 추가적으로 저장하는 것이 아니고, 쿼리의 결과를 정의하는 논리적인 가상 테이블을 생성할 수 있다.
• Cons: 어떤 중요한 변환을 실행하거나, 아니면 어떤 다른 view 위에 있는 view 쿼리를 실행하는 건 느릴 수 있다.
• Advice: 
  • 처음에는 view 로 시작하고 모델에 대한 쿼리 성능이 안좋아질 경우 다른 materialization 전략 취하기
  • view 는 어떤 중요한 변환을 하지 않는 작업에 매우 적합한다. 예를 들어서 컬럼 Rename이나 column recasting 같은 것들

 

Table

Table 로 설정하면 dbt 모델을 실행시켰을 때 create table 이 실행된다.

• Pros: Table 은 쿼리할 때 매우 빠르다.
• Cons: 
  • 테이블은 rebuild 할 때 시간이 오래걸린다. 특히 중요한 변환에서는 더 오래걸린다.
  • 새로운 record가 테이블에 추가될 수 없다. create table 이기 때문에 매번 새롭게 생성된다.
• Advice:
  • Table Materialization 은 BI 툴에서 쿼리할 때 사용. 즉, 데이터 마트를 만들 때 적합
  • 느린 변환(복잡한 변환)에 대해서 테이블에 미리 작업해서 저장해둠으로써 다른 모델이나 분석에서 필요할 때 빠르게 접근해서 활용할 수 있도록 함
    • 예를 들어 빅쿼리에서 많은 하위모델들이 사용하는 복잡한 데이터 조인 작업이 있을 때 이 작업을 한 번 수행하고 그 결과를 테이블로 저장함으로써 다른 모델들은 그 테이블을 활용해서 빠르게 결과를 얻을 수 있음

 

Incremental

Incremental 로 설정하면 정해진 테이블에 insert 또는 update 또는 업데이트가 된다.

• Pros: 새로운 데이터만 변형하는 것이기 때문에 build 타임을 줄일 수 있다.
• Cons: Incremental 모델의 경우 다른 추가적으로 다른 config 설정이 필요하고, 이 부분이 사용하기 까다로울 수 있고, 러닝커브가 있다.
• Advice:
  
  • Incremental 모델은 데이터가 이벤트 형태로 발생하는 경우에 가장 효과적이다.
    • 즉, 데이터가 특정 사건이나 특정 동작이 발생할 때마다 생성되거나 기록되는 형태의 데이터를 말한다. 일반적으로 시간적 순서나 타임스탬프를 포함한다.

 

Ephemeral

학습하면서 가장 좋은 부분이라고 생각했던 materialization 전략 중 하나인데, database에 모델을 직접적으로 생성하지 않고 dbt 는 이 모델의 코드를 종속 모델에 Common Table Expression(CTE) 로 insert 한다. 

이 전략을 잘 활용하면 여러 테이블을 database에 직접 만들지 않고도 쿼리 재사용성을 높일 수 있다.

• Pros: 
  • 여전히 reusable 로직을 작성할 수 있다.
  • 실직적으로 database에 어떤 것을 생성하지 않기 때문에 깔끔하게 관리할 수 있다.
• Cons:
  • 이 모델에서는 당연히 database에 무언가 생성되는 것이 아니기 때문에 직접적으로 쿼리할 수 없다.
  • Operation 이 작동하지 않는다.(dbt run-operation 을 사용할 수 없다.)
  • Ephemeral 을 많이 사용, 남발하게 되면 쿼리 디버깅이 힘들어진다. 
    • A Ephemeral 을 사용하는 B Ephermeral 을 만들고 또 B Ephemeral 을 사용하는 C Ephemeral 을 만드는 것은 좋지 않은 전략이다.
• Advice:
  • light-weight 한 변형을 위해서 사용할 것
  • 한 두개의 down stream 모델 정도에만 사용할 것
  • Ephemeral 모델에 직접적으로 쿼리는 안된다.

 

이처럼 dbt는 Data Lake, Data WareHouse 에 쌓여가는 데이터들을 효과적으로 관리하고 Data Mart 를 구축할 때 필요한 쿼리들을 코드로써 관리할 수 있다는 점에서 도입하기에 적합한 툴이라고 생각했다.

 

추후, 더 사용해보면서 알게된 점을 정리해야겠다.