dbt Meetup에서 'dagster로 알아보는 dbt'를 주제로 발표한 후기

 

데이터 오케스트레이션 dagster와 dbt에 대해서 알아보기

처음 스피커 제안을 받은 것은 저번달, 데이터 오케스트레이션 dagster와 dbt에 대해서 알아보기라는 블로그 포스팅에 댓글이 시초였다.
서울 dbt 커뮤니티 관리자 혜릭님께서 밋업 스피커로 모시고싶다는 댓글을 받고 고민하다가 연말을 장식하는 이벤트이자 나에게 좋은 기회가 될 수 있을 것 같아서 메일로 연락을 주고 받았다.
필요한 톤앤매너와 주제를 확정하고 최종적으로 dagster로 알아보는 dbt라는 주제로 dbt밋업에 참여해 세션 하나를 공유하게 되었다.
개인적으로는 한국 데이터 엔지니어 2기 모임때 디비지움관련해서 한번 발표한 적이 있었는데 그 이후로 대외적인 발표는 두번째다.
그래도 해마다 한번씩은 발표를 하게 되는 것 같아서 내년에도 기회가 된다면 어떠한 주제로든 발표를 하게되면 좋을 것 같다는 생각이 든다.
이번은 dbt 밋업에서 발표한 후기와 더불어 dbt meetup에서 발표한 내용을 공유하려고 한다.
기존에 포스팅한 데이터 오케스트레이션 dagster와 dbt에 대해서 알아보기라는 포스팅과 전반적인 내용과 기조는 비슷하지만 dbt meeup이었던 만큼이나 좀더 dbt에 대해서 느낀점과 왜 dbt를 도입하지 않게 되었는지 등 dbt에 대한 느낀점에 대해 좀더 분량을 늘렸고 dagster에 대해 조금 지엽적인 부분은 과감히 세션 시간의 할애를 위해서 지웠다.

https://www.meetup.com/ko-KR/seoul-dbt-meetup/events/304791613/?eventorigin=group_past_events
dbt meetup에 참여하고 싶었지만 시간이나 여건상 참석하지 못한 사람들에게 도움이 되길 바란다.

Login to Meetup | Meetup

차분한 분위기에서 시작된 밋업

밋업에서 받은 반다나

처음 모임장소에 들어가자마자 커뮤니티 관리자 혜릭님이 맞이해주셨고 체크인을 도와주셨다. 나는 발표자 특혜(?)로 모자와 반다나 한장을 받을 수 있었다. 사실 에코백이 좀더 탐나긴했었는데…물어보기라도 할 걸 처음에 발표 준비하는데 너무 긴장하기도하고 정신을 집중하느라고 차마 물어보질 못했다.
일단 기존에 다른 밋업들도 자주 참여했었는데 가장 비교적 처음든 느낌은 MBTI I인분들만 모아두신 것같다는 느낌이 들 정도로 되게 차분한 분위기에서 시작되었다는 점이다.
나는 개인적으로 한국 데이터 엔지니어 모임에서 이 밋업에 참여하신다는 분들이 계시다는 소식을 들어서 미리 단체 카톡방에서 알게된 분들과 테이블을 같이하게 되어서 그분들과 소통하고 명함 교환도 하게되었다.
테이블에 음료수가 놓여져 있어서 자유롭게 마실 수 있었고 나중에 발표가 끝나고 피자와 맥주를 함께 먹으며 다른 회사들의 상황과 dbt에 대한 의견 등을 나눴다.
조금 아쉬웠던 것들은 다른 밋업들은 조금 자리를 옮겨가면서 자유로운 분위기속에서 커뮤니케이션이 이루어졌었는데 다들 소극적인 성향이신 것도 있고 이미 테이블 자리가 고정이 되어버려서 더 많은 사람들과 이야기를 나누거나 명함을 교환하지 못한 것은 조금 아쉬웠다.
물론 고정된 테이블로도 충분히 얘기가 길어지고 재밌어서 충분히 만족스러웠고 좋았지만 한국 데이터 엔지니어 모임에 가서도 볼 수 있는 조합이었어서 조금 다른 직군이나 다양한 회사의 의견을 보고 듣고싶었던게 있었는데 이건 내가 좀더 적극적으로 움직일 수도 있었는데 그러지 못했던 잘못도 있으니까 밋업에 대한 아쉬움은 아니고 개인적으로 왜 그렇게 하지 못했을까에 대한 회고적인 내용이다.

DAGSTER와 함께 알아보는 DBT

dagster와 함께 알아보는 dbt는 사실 회사에서 airflow 이외에 모던 아키텍처 스케줄러가 여러개 있고(prefect, mageAI, dagster…)각각 poc해서 진행하던 중에 내가 맡아서 담당했던게 dagster였고 dbt와 함께 사용하면 시너지가 날 것 같아서 추가적으로 poc중에 더해서 알아본 것을 포스팅했는데 혜릭님이 보시고 발표를 부탁해주셔서 부랴부랴 재구성해서 이렇게 스피커로 발표하게 되었다.
앞서 얘기했던 것처럼 포스팅은 좀더 dagster에 비중이 있었는데 다시 만들면서 짜잘한 내용은 덜어내고 좀더 dbt를 사용했을 때의 느낀 것들을 추가적으로 담았다. dbt보다는 dbt와 함께 사용할 툴에 Dagster가 있고 어떤 도구인지 정도 알고 가면 충분히 얻어갈게 있을 것이라는 생각이 든다.
그래서 제목을 다시 바꿔본다면 ‘dagster 근데 이제 dbt를 곁들인’정도가 될 것 같다.

dagster

• 사용자가 데이터 워크플로우를 정의, 예약 및 모니터링할 수 있는 데이터 오케스트레이션 툴, 일반적인 워크플로우 툴처럼 사용자가 데이터 워크플로우를 정의하고 스케줄링 할 수 있다.
• dagster는 다양한 데이터 도구 및 플랫폼과 잘 통합되어 다양한 데이터 환경에서 사용성을 향상시킴
  • dbt, Airflow, Airbyte, DuckDB, Fivetran, Databricks, Slack, Spark…
• python 데코레이터를 사용해서 함수 기반으로 op와 job을 정의
• airflow에서도 x-com을 지원하기는 하지만 메모리 등 제약이 있는 반면에 dagster는 op간 변수 상속이 용이함
• UI가 직관적이고 op간 리니지 관계가 job단위가 아닌 글로벌 스코프 단위로도 확인할 수 있음

이외에도 메타데이터, 예를들어 테이블을 썼는데 row count를 웹에서 확인하고 싶다던가 plot 라이브러리를 통해서 만든 이미지도 웹에서 표시할 수 있어서 좀더 웹에서 직관적으로 보여지는 부분에서 강점이 있다.
물론 airflow도 가능은 하지만 로그를 찍어서 보는 등 방식이 web ui에서 직관적으로 볼수 있는 방향은 아닌데 dagster는 이런 메타데이터들을 직접 표시해준다.

op

• 가장 작은 단위로 개별 작업을 수행한다. airflow의 task와 유사하다.
• 각각의 op는 별도의 input과 output을 가질 수 있으며, op간 변수 상속이 가능하다

Asset

• 머신러닝 모델, S3, 데이터베이스의 테이블, API와 같은 오브젝트들을 asset이라고 추상화
• 데이터 네이티브한 작업들이 주로 이 Asset에 포함됨
• airflow에서 오퍼레이터 개념
• op와의 차이점은 에셋은 데이터 네이티브한 작업이고 op는 컴퓨팅 워크플로우의 단계를 정의하는데 주로 사용됨

이런식으로 데코레이터를 통해서 asset들을 파이썬 코드로 정의하고 데이터베이스 소스에 쿼리를 날리고 위에 task와 의존성있게 바로 다음 쇼핑리스트 함수가 실행되는 구조.
airflow는 꺽쇠(>>)를 통해서 dag의 방향을 결정하는데, 덱스터는 이런식으로 데코레이터 파라미터에 deps의 값을 통해서 의존성 관계를 표현함

 

 

dbt-native ochestration

실제로 이 예제는 덱스터 공식홈페이지에서 가져온 것, 거기에 설명도 dbt-native ochestration이라고 써져있다.
여기에 잡을 보면 에어바이스에서 데이터베이스에서 EL을 받은 데이터를 dbt를 통해서 조인해서 마트로 만들고 그 테이블을 파이썬 컴퓨트 작업을 통해서 모델을 만들었다.
실제로 dagster를 사용하면 dbt 프로젝트에서 가져온 쿼리들을 자동으로 의존성을 표시해주고 심지어 여기에 표시된 airbyte나 다른 에셋들과의 의존성까지 정의를 내려서 스케줄을 걸어줄 수 있다.
가운데의 dbt는 코드로 덱스터에서 만든 의존성이 아니라 dbt내에서 매크로로 정의된 ref펑션을 읽어서 업스트림과 다운스트림을 표시한다.
해당 에셋이 어떤 에셋인지(airbyte인지 dbt인지) 보여주는 부분도 airflow와 다른 차별화된 점이라고 생각한다.

JOB

• 여러 op 또는 asset을 결합하여 특정 작업을 수행한다. job은 op간의 실행 순서를 정의한다.
• 센서나 스케줄을 정의
• airflow로 치면 dag를 만드는 것

dbt

• ELT에서 T(transformation)를 담당
• 오픈소스인 dbt-core와 cloud버전인 DBT Cloud가 존재
• SQL base의 transformation만 가능하고, 대신 jinja template을 활용해서 다양한 처리를 제공함

분석가와 엔지니어의 통합

예를들어 이런식으로 sql쿼리가 있다고 했을 때 ref함수로 소스를 표시하면 자동으로 dbt가 의존성 관계를 만들어준다. 그래서 관리하기 편하다는 장점이 가장 크다.
일적으로 카프카를 주로 다루는데 카프카에서 k-sql라는 프로세싱 모듈이 있다. sql로 카프카의 토픽들을 제어할 수 있는 도구인데, 이 k-sql을 통해서 분석가나 엔지니어 모두 편하게 sql을 통해서 스트림을 생성하거나 토픽을 제어할 수 있다. sql은 개인적으로 분석가들과 엔지니어, 그리고 실무자들까지도 다루는 언어중립적인 특성이 있기 때문에 모두가 한 장소에서 공유하고 소통할 수 있다는 장점이 있다고 생각한다.
그래서 이 dbt는 통합성에 강점이 있다. 하나는 다른 플랫폼과의 통합성이고 다른 하나는 분석과 엔지니어링에 통합이 하나다.
앞서 말했던 것처럼 dbt를 단일로 쓰는 것보다는 덱스터나 airflow 등 다른 툴들과의 통합했을 때 더 시너지가 나고, sql이라는 언어중립적인 표현방식을 통해 좀더 소통과 관리가 원활하게 이루어진다는 점 때문

dbt의 기본 구조

그냥 단순히 sql만 다룰 줄 안다고해서 dbt를 바로 사용하기에는 조금 어려움. 이와같은 기본 구조를 일단 숙지해야함

• models: transformation 관련 쿼리를 정의
• macros: 쿼리에 활용될 사용자 정의 함수 등을 정의
• dbt profile: dbt에서 쿼리를 실행할 때 어떤 쿼리엔진 또는 DB를 사용할 것인지 정의(ex. spark, postgresql, trino, duckDB…)
• dbt_project.yml: project에서 사용되는 model에 대한 설정을 정의할 수도 있고 모델별로 {{ config() }}로 설정할 수도 있음

모델 정의

• materialized라는 항목으로 모델의 타입을 정의할 수 있음
• table: 실제 테이블로 생성
• view: view로 생성
• incremental: 증분 처리할 경우 사용, is_incremental()과 함께 쓰임
• ephemeral: 임시 테이블(실행할 때만 잠깐 생성됐다가 실행 후 삭제)

데이터 거버넌스 관리

• 간단하게 로컬에서 각 테이블 명세를 문서화하고 확인할 수 있음
• 연결된 데이터베이스 카탈로그 관리
• dbt docs generate
• dbt docs serve

의외로 가장 마음에 들었던 점은 dbt를 사용하면 이 데이터 거버넌스 관리가 자동으로 따라온다는 점이었음. 물론 discription이나 세부적인 내용은 추가적으로 작성해야하지만 자동으로 파싱된 의존성 관계나 프로젝트 구조, 데이터베이스 연결된 상황 등을 한번에 로컬에서 관리하고 작업할 수 있다는 점이 매리트가 있다고 느낌

dbt를 테스트하면서 느낀점

• 애드훅하게 빠르게 테스트나 결과를 확인해볼 수는 없어서 간단한 문법 오류나 중간 테이블 확인 등 롱 쿼리 작업, 디버깅 등의 불편함
• DBT 하나에 데이터 리니지를 자동으로 명세하고 탐색할 수 있고 관리할 수 있는 장점
• 여러 모던 아키텍처 도구들과 통합이 용이(airbyte, prefect, dagster, airflow 등)
• 팀 규모의 활용과 배포를 위해서는 유닛 테스트와 함께 CI/CD 기반이 필요

dbt로 전환하지 않은 이유

dbt로 전환을 했느냐하면은 일단 지금 현상태에서는 dbt를 사용하지 않는 방향으로 poc를 통해서 결정됨

첫번째로 dbt로 옮기기 위해서는 기존에 쿼리방식으로 동작하는 airflow에 있는 쿼리들을 dbt로 옮기고 dbt에 맞춰서 매크로나 모델을 설정해야하는데 그 노동 대비 효율이 크지 않았음. 추가적으로 기존에 이미 자체적으로 개발을 통해서 내부 쿼리를 파싱하는 라이브러리를 만들었고 이를 통해서 태스크간 테이블 리니지 관계를 표현할 수 있었음.

두번째로 dbt에서 스파크를 사용하려면 스리프트 서버를 이용해 연결해야했는데 기존에 사용하고있는 스파크 오퍼레이터 방식은 airflow에서 원하는 리소스를 설정하면 쿠버네티스상에 task 개별 스파크오퍼레이터가 떠서 task간 간섭이 없고 독립적으로 돌아가고있고 이미 검증되고 안정된 프로세스였음. dbt의 스리프트 서버를 사용하면 스파크 클러스터를 항시 운용하면서 Dynamic Allocation을 통해서 잡을 제출하는 식이 될것같은데 충분한 검증이 필요해보임

데이터 거버넌스도 사실 저희는 데이터허브나 아문센을 따로 또 직접 운영하고 사용하고 있기 때문에 따로 dbt에서 제공하는 리니지나 거버넌스가 그렇게 큰 매리트로 다가오지는 않음.

즉 종합하면 대안이 이미 있었기 때문에 나중에라면 몰라도 지금 당장은 여유나 이유가 크지 않았음

그래서 언제 dbt를 사용하면 좋을까?🤔

에어플로우에 dbt를 표시하기 위해 Astronomer-cosmos라고 하는 라이브러리도 테스트를 해봤었는데 조금 다른 기존 에어플로우 스케줄과의 의존성 관계나 센싱하는 것이 살짝 커스텀이 필요한 부분을 제외하면 무리없이 적용이 가능했음. 그래서 이런식으로 다른 스케줄러들과 충분히 이식 및 통합이 가능하다는 장점이 있기 때문에 여기서 설명한 댁스터 이외에도 에어플로우나 프리펙트, 댁스터와 같은 것들과 어울려 사용하기에 적합함.

데이터 거버넌스를 한번에 관리하고 싶은 경우와 쿼리를 체계적으로 관리하고 싶은 경우.
dbt하나로 다른 데이터허브나 아문센 등을 사용하지 않아도 테이블의 목적이나 명세, 의존성 등을 체계적으로 정리할 수 있다는 점.
데이터플랫폼을 운영하다가 보면 항상 시간이나 리소스 부족으로 인해서 미쳐 마트작업 이후에 테이블에 대한 문서화까지 이루어지지 않는 부분들이 많은데 특히 아무리 좋은 툴을 써도 이원화가 되면 데이터브릭스처럼 ai로 어느정도 부분 자동화가 이루어져서 컬럼 설명이 자동으로 적히거나 그런게 아니라면 대부분 사람이 접속해서 직접 해줘야하는게 대부분임. 그런것들을 dbt한곳으로 모으고 하나의 레포에서 일원화해서 관리한다는 것은 그런 툴들간의 전환에 필요한 비용을 줄일 수 있는 장점이 있다.

애널리틱엔지니어가 존재하는 곳.
애널리틱스엔지니어는 분석과 엔지니어 중간 단계에 있는 성격의 직군. 사실 앞서서 sql을 사용한다는게 언어중립적이고 통합할 수 있는 장점이 있다고 말했는데 생각보다 엔지니어적으로나 모델이나 매크로같이 챙겨줘야할 것들이 많이 있다. 그래서 이런 것들이 이용하는 모두에게 인지가 되어있어야 한다. 오히려 스트릭트하게 분석이나 쿼리 업무랑 엔지니어업무랑 나뉘어져있으면 오히려 dbt가 애매하거나 회색지대처럼 여겨질 수도있어서 차라리 이 회색지역을 맡는게 에널리틱 엔지니어 직군이 적합하다는 생각이 든다.