Do you know DBT?�- DBT로 쉽게 모델링하기

김도진 | 당근

발표자 소개

김도진

• Software Engineer, Data @당근
• (전) Server Engineer @뱅크샐러드

LinkedIn

오늘 전달드릴 이야기

이런 분들이 들으면 좋아요

• DBT 도입을 시도하려고 하는데 고민이 되시는 분
• DBT 도입을 했거나 비슷한 방식으로 만들어서 모델링을 하고 있었으나 문제를 겪고 계시는 분
• 당근 데이터 가치화팀이 어떤 문제를 겪고 있었고 어떤 방식으로 문제를 풀어갔는지 궁금하신 분

​

이런 내용들은 다루지 않아요

• DBT나 Airflow 관련한 딥한 코드 얘기

오늘 전달드릴 이야기

당근 데이터 가치화팀이 어떤 문제의식에서 출발하여 DBT를 도입하게 된 배경과 그 과정, 그리고 앞으로의 계획을 공유하려고 합니다.

용어

DBT에 대한 간단한 설명

: DBT는 ETL에서 T를 SQL과 Yaml만으로 할 수 있게 해주는 워크플로우 툴입니다. 데이터 테스트나 모듈화 등 소프트웨어 엔지니어링적인 역량을 갖추게 해줍니다.

​

참고: DBT 공식 문서

당근 소개

당근 소개

당근에서의 지표 (당근 지표 플랫폼 Karrotmetrics)

당근에서의 실험 (당근 실험플랫폼)

Part 1 - 당근이 겪은 문제와 DBT 도입 배경

문제 의식

데이터 보는 것이 어려워요

문제 의식

데이터 보는 것이 어려워요

보고 싶은 데이터가 있는데 무엇을 봐야할지 모르겠어요

문제 의식

데이터 보는 것이 어려워요

보고 싶은 데이터가 있는데 무엇을 봐야할지 모르겠어요

다른 팀의 데이터를 보고 있는데 무슨 의미인지 모르겠어요

문제 의식

데이터 보는 것이 어려워요

보고 싶은 데이터가 있는데 무엇을 봐야할지 모르겠어요

다른 팀의 데이터를 보고 있는데 무슨 의미인지 모르겠어요

이 데이터는 신뢰할 수 있나요?

문제 의식

데이터 보는 것이 어려워요

보고 싶은 데이터가 있는데 무엇을 봐야할지 모르겠어요

다른 팀의 데이터를 보고 있는데 무슨 의미인지 모르겠어요

이 데이터는 신뢰할 수 있나요?

A,B,C 데이터 중에 어떤걸 사용해야 해요? �: A는 이제 사용안한다고요!?

문제 의식

데이터 보는 것이 어려워요

보고 싶은 데이터가 있는데 무엇을 봐야할지 모르겠어요

다른 팀의 데이터를 보고 있는데 무슨 의미인지 모르겠어요

이 데이터는 신뢰할 수 있나요?

X 정보를 얻기 위해 1000줄 쿼리를 만들고 관리해야 해요

A,B,C 데이터 중에 어떤걸 사용해야 해요? �: A는 이제 사용안한다고요!?

문제 의식 - 시나리오

A

B

C

D

방문한 유저의 1/3이 A피드를 보고 결제를 했어요!

요리조리, 이런저런 로직

문제 의식 - 시나리오

A

B

C

D

방문한 유저의 1/3이 A피드를 보고 결제를 했어요!

요리조리, 이런저런 로직

팀장님: �그러면 B피드를 보고 결제한 유저는 얼마나 되나요?

문제 의식 - 시나리오

A

B

C

D

방문한 유저의 1/3이 A피드를 보고 결제를 했어요!

요리조리, 이런저런 로직

팀장님: �그러면 B피드를 보고 결제한 유저는 얼마나 되나요?

​

나:

잠시만요 (방문한 유저 JOIN, B 피드 본 유저 JOIN, 결제한 유저 JOIN…) 1/6이네요!

문제 의식 - 시나리오

A

B

C

D

방문한 유저의 1/3이 A피드를 보고 결제를 했어요!

요리조리, 이런저런 로직

팀장님: �그러면 B피드를 보고 결제한 유저는 얼마나 되나요?

​

나:

잠시만요 (방문한 유저 JOIN, B 피드 본 유저 JOIN, 결제한 유저 JOIN…) 1/6이네요!

​

팀장님:

어떤 로직으로 계산하신거죠?

문제 의식 - 시나리오

A

B

C

D

방문한 유저의 1/3이 A피드를 보고 결제를 했어요!

요리조리, 이런저런 로직

팀장님: �그러면 B피드를 보고 결제한 유저는 얼마나 되나요?

​

나:

잠시만요 (방문한 유저 JOIN, B 피드 본 유저 JOIN, 결제한 유저 JOIN…) 1/6이네요!

​

팀장님:

어떤 로직으로 계산하신거죠?

​

나:

A JOIN B LEFT JOIN C LEFT JOIN D WHERE A.type = “A”

문제 의식 - 시나리오

A

B

C

D

방문한 유저의 1/3이 A피드를 보고 결제를 했어요!

요리조리, 이런저런 로직

팀장님: �그러면 B피드를 보고 결제한 유저는 얼마나 되나요?

​

나:

잠시만요 (방문한 유저 JOIN, B 피드 본 유저 JOIN, 결제한 유저 JOIN…) 1/6이네요!

​

팀장님:

어떤 로직으로 계산하신거죠?

​

나:

A JOIN B LEFT JOIN C LEFT JOIN D WHERE A.type = “A”

​

팀장님:

A.type이 아니고 B.type으로 필터해야할 것 같은데요? B 데이터가 원래 그래요…

문제 의식

데이터 보는 것이 어려워요 쉬워요

• 원하는 정보가 이미 정제되어서 존재한다.
• 짧은 쿼리로 정보를 손쉽게 접근할 수 있다.
• 정보를 재사용할 수 있고, 원본을 보는 것보다 효율적이다.
• 원하는 정보가 신뢰할 수 있는 형태로 만들어졌다.
• 추가적인 가공이나 확인이 필요 없다.
• 정보가 잘 정의가 되어 있고, 정보를 쉽게 이해할 수 있는 방법이 있다.
• 정보가 어떻게 만들어졌는지 쉽게 알고 이해할 수 있다.
• 정보 탐색이 쉽다
• 원하는 정보가 있을 때 거의 바로 찾아서 활용할 수 있다.

​

문제 의식

데이터 보는 것이 어려워요 쉬워요

• 원하는 정보가 이미 정제되어서 존재한다.
• 짧은 쿼리로 정보를 손쉽게 접근할 수 있다.
• 정보를 재사용할 수 있고, 원본을 보는 것보다 효율적이다.
• 원하는 정보가 신뢰할 수 있는 형태로 만들어졌다.
• 추가적인 가공이나 확인이 필요 없다.
• 정보가 잘 정의가 되어 있고, 정보를 쉽게 이해할 수 있는 방법이 있다.
• 정보가 어떻게 만들어졌는지 쉽게 알고 이해할 수 있다.
• 정보 탐색이 쉽다
• 원하는 정보가 있을 때 거의 바로 찾아서 활용할 수 있다.

​

=> 잘 만들어진 정보가 있어야 한다

문제 의식

원하는 데이터 만드는 것이 어려워요…!

문제 의식

쉽게 데이터를 볼 수 있으려면…

​

신뢰할 수 있는 정보들이 �지속적으로 만들어지고 관리되어야 하고,

정보를 만드는 것이 쉬워야 해요

DBT 도입 배경

신뢰할 수 있는 정보들이 지속적으로 만들어지고 관리되기 위해서는

​

1. 신뢰할 수 있는 정보를 만들 수 있는 데이터 엔지니어링 역량 필요
2. 사용자들에 대한 정보를 정의하고 이해할 수 있는 도메인 지식 필요

DBT 도입 배경

1. 신뢰할 수 있는 정보를 만들기 위한 데이터 엔지니어링 역량
1. 주기적으로 정보가 만들어져야 해요
2. 정보에 대한 퀄리티가 보장되어야 해요
• 데이터간 의존성, 데이터 테스트, 데이터 관측성, 등
3. 정보가 잘 관리되어야 해요
• 정의, 메타데이터, 통합된 정보, 탐색 용이한 구조, 등

DBT 도입 배경

2. 사용자들에 대한 정보를 정의하고 이해할 수 있는 도메인 지식

• 도메인 지식이 반영된 비즈니스 로직으로 정보가 만들어져야 해요
• 예를 들어, X서비스 활성화 유저는 name = ‘xxxx’로 필터해야 해요.
• 변화에 따라 지속적으로 정보가 업데이트 및 관리되어야 해요
• 예를 들어, X를 바라보던 로직이 데이터 마이그레이션 이후에는 Y를 바라보도록 수정되어야 해요.

DBT 도입 배경

데이터 엔지니어 역량 갖춘 사람 + 도메인 지식

​

VS

​

도메인 지식 갖춘 사람 + 데이터 엔지니어링 역량

DBT 도입 배경

현실

DBT 도입 배경

도메인 지식을 가지고 있는 구성원이 �데이터 엔지니어링 역량을 발휘할 수 있도록 도와주는 것이 더 확장성 있는 방안

Part 2 - DBT 도입 과정

DBT - Are you 만병통치약?

DBT with Airflow가 모든 회사의 모든 문제를 해결해 줄 수 있는 �Silver Bullet은 아닙니다.

​

데이터의 형태, 적재된 장소, 도메인, 비즈니스 니즈, 데이터 리터러시, 데이터 문화, 회사의 일하는 방식에 따라서 문제를 해결하는 방법은 달라질 수 있습니다. 그리고, DBT가 있기 전에 이미 사내에 비슷한 플랫폼을 구축하고 이미 잘 사용하고 있었더라면 더더욱 DBT를 꼭 도입해야할지 두번 고민하시길 바랍니다.

DBT 도입 과정

Why DBT & Airflow?

1. Easy Transformation

: yaml과 sql만으로 원하는 곳에 원하는 정의, 방식대로 데이터를 가공해서 저장할 수 있음

• Data Quality

: DBT 모델간 의존성 기능을 통해 특정 모델이 실행되고 나서 다음 모델이 실행되게 할 수 있음. 가공된 DBT 모델

데이터에 대해 테스트 할 수 있음 (ex. NOT NULL, UNIQUE…)

• Documentation

: 모델의 정의와 각 컬럼들에 대한 정의 및 설명을 통해 모델에 대한 도큐먼트화가 자동으로 됨

• Reusability

: 반복되는 로직을 재사용성 있는 포맷으로 만들 수 있음

• Data Freshness

: 주기적인 스케줄링을 통해 최신 데이터가 모델에 반영될 수 있음

• Observability

: 모델이 실제로 실행되었는지, 실패된 경우가 있는지 모니터링 가능. 실패했을 때 빠르게 인지 가능.

DBT 도입 과정

Why DBT & Airflow?

• Easy Transformation

: yaml과 sql만으로 원하는 곳에 원하는 정의, 방식대로 데이터를 가공해서 저장할 수 있음

• Data Quality

: DBT 모델간 의존성 기능을 통해 특정 모델이 실행되고 나서 다음 모델이 실행되게 할 수 있음. 가공된 DBT 모델

데이터에 대해 테스트 할 수 있음 (ex. NOT NULL, UNIQUE…)

• Documentation

: 모델의 정의와 각 컬럼들에 대한 정의 및 설명을 통해 모델에 대한 도큐먼트화가 자동으로 됨

• Reusability

: 반복되는 로직을 재사용성 있는 포맷으로 만들 수 있음

• Data Freshness

: 주기적인 스케줄링을 통해 최신 데이터가 모델에 반영될 수 있음

• Observability

: 모델이 실제로 실행되었는지, 실패된 경우가 있는지 모니터링 가능. 실패했을 때 빠르게 인지 가능.

DBT 도입 과정

Why DBT & Airflow?

2. Data Quality

: DBT 모델간 의존성 기능을 통해 특정 모델이 실행되고 나서 다음 모델이 실행되게 할 수 있음. 가공된 DBT 모델

데이터에 대해 테스트 할 수 있음 (ex. NOT NULL, UNIQUE…)

​

DBT 도입 과정

Why DBT & Airflow?

3. Documentation

: 모델의 정의와 각 컬럼들에 대한 정의 및 설명을 통해 모델에 대한 도큐먼트화가 자동으로 됨

• Reusability

: 반복되는 로직을 재사용성 있는 포맷으로 만들 수 있음

• Data Freshness

: 주기적인 스케줄링을 통해 최신 데이터가 모델에 반영될 수 있음

• Observability

: 모델이 실제로 실행되었는지, 실패된 경우가 있는지 모니터링 가능. 실패했을 때 빠르게 인지 가능.

DBT 도입 과정

Why DBT & Airflow?

4. Reusability

: 반복되는 로직을 재사용성 있는 포맷으로 만들 수 있음

. 실패했을 때 빠르게 인지 가능.

user model

a model

b model

c model

macros

DBT 도입 과정

Why DBT & Airflow?

5. Data Freshness

: 주기적인 스케줄링을 통해 최신 데이터가 모델에 반영될 수 있음

​

. 실패했을 때 빠르게 인지 가능.

DBT 도입 과정

Why DBT & Airflow?

6. Observability

: 모델이 실제로 실행되었는지, 실패된 경우가 있는지 모니터링 가능. 실패했을 때 빠르게 인지 가능.

​

​

. 실패했을 때 빠르게 인지 가능.

DBT 도입 과정

DBT 도입 과정

DBT x Airflow를 사용하면 데이터를 만드는 것은 쉬워지지만…구조나 규칙이 없다면?

DBT 도입 과정

DBT x Airflow를 사용하면 데이터를 만드는 것은 쉬워지지만…구조나 규칙이 없다면?

DBT 도입 과정

그 중에서 “직관적이고 쉬운 형태의 구조화"가 있어야 도메인 지식을 아는 구성원이 데이터 엔지니어링 역량을 쉽게 갖출 수 있을 것이라고 생각했습니다.�

DBT 도입 과정 - 구조화

그렇다면 사용자에 대해 평소에 알아가는 과정은 어떻게 되지?

DBT 도입 과정 - 구조화

그렇다면 사용자에 대해 평소에 알아가는 과정은 어떻게 되지?

1. 사용자가 앱에 무언가를 하려고 한다

DBT 도입 과정 - 구조화

그렇다면 사용자에 대해 평소에 알아가는 과정은 어떻게 되지?

• 사용자가 앱에 무언가를 하려고 한다
• 기기에 어떠한 일(?)을 한다

DBT 도입 과정 - 구조화

그렇다면 사용자에 대해 평소에 알아가는 과정은 어떻게 되지?

• 사용자가 앱에 무언가를 하려고 한다
• 기기에 어떠한 일(?)을 한다
• 기기가 데이터를 보낸다

DBT 도입 과정 - 구조화

그렇다면 사용자에 대해 평소에 알아가는 과정은 어떻게 되지?

• 사용자가 앱에 무언가를 하려고 한다
• 기기에 어떠한 일(?)을 한다
• 기기가 데이터를 보낸다
• 기계가 보낸 데이터를 보고 사람의 행동으로 치환한다

DBT 도입 과정 - 구조화

그렇다면 사용자에 대해 평소에 알아가는 과정은 어떻게 되지?

• 사용자가 앱에 무언가를 하려고 한다
• 기기에 어떠한 일(?)을 한다
• 기기가 데이터를 보낸다
• 기계가 보낸 데이터를 보고 사람의 행동으로 치환한다
• 행동들을 이리저리 살펴본다

DBT 도입 과정 - 구조화

그렇다면 사용자에 대해 평소에 알아가는 과정은 어떻게 되지?

• 사용자가 앱에 무언가를 하려고 한다
• 기기에 어떠한 일(?)을 한다
• 기기가 데이터를 보낸다
• 기계가 보낸 데이터를 보고 사람의 행동으로 치환한다
• 행동들을 이리저리 살펴본다
• 사용자가 어떤 상태인지, 무슨 의도인지 추론한다

DBT 도입 과정 - 구조화

그렇다면 사용자에 대해 평소에 알아가는 과정은 어떻게 되지?

• 사용자가 앱에 무언가를 하려고 한다
• 기기에 어떠한 일(?)을 한다
• 기기가 데이터를 보낸다
• 기계가 보낸 데이터를 보고 사람의 행동으로 치환한다
• 행동들을 이리저리 살펴본다
• 사용자가 어떤 상태인지, 무슨 의도인지 추론한다

보통 3) > 6) 으로 때 중간 단계들을 따로 만들지 않고 6)에 해당하는 데이터를 만들어두거나, 따로 저장하지 않고 일회성으로 사용하고 있는 경우가 많다.

DBT 도입 과정 - 구조화

데이터로 정보를 만들기 위한 과정을 살펴보고 이를 구조화했습니다

DBT 도입 과정 - 개발

DBT로 Base, Fact, Dimension 형태로 모델링하고, 이를 Airflow가 주기적으로 실행할 수 있게 하기

DBT 도입 과정 - 개발

HOW?

DBT 도입 과정 - 개발

HOW?

DBT 도입 과정 - 개발

HOW?

DBT 도입 과정 - 개발

: DBT 모델들을 의존성대로 Airflow task로 만들어주는 패키지

DBT 도입 과정 - 개발

DBT로 Base, Fact, Dimension 형태로 모델링하고, �이를 Astronomer Comos를 활용해서 Airflow task로 만들고,�Airflow가 scheduling interval, 타임존 등에 따라 주기적으로 실행할 수 있게 하기

DAILY - Asia

DAILY - North America

HOURLY…

…

DBT 도입 과정 - 개발

​

Astronomer Cosmos는 Silver Bullet이 아닙니다.

• 개발 당시 아직 0.x.x 버전대의 이제 막 개발중인 패키지
• vars로 다이나믹하게 사용하기에 조금의 부족함
• 느린 parsing 속도
• 매번 dbt full parse로 인한 속도 저하
• etc.

​

DBT 도입 과정 - 개발

​

그래도 계속 발전중 …

• 개발 당시 아직 0.x.x 버전대의 이제 막 개발중인 패키지
• vars로 다이나믹하게 사용하기에 조금의 부족함
• 느린 parsing 속도
• 매번 dbt full parse로 인한 속도 저하
• etc.

​

Part 3 - DBT 사용

DBT 사용 - 구조화

• Raw (Source)

: 데이터 인프라가 Data Warehouse에 적재한 원천 데이터를 의미해요

​

• Base Layer

: 원천 데이터를 한 번 가공한 기본 데이터 (DBT의 staging이라고도 볼 수 있음). 여기서 가공은 “필요한 컬럼들 SELECT, 문제 있는 데이터의 수정, 데이터 타입의 Casting” 등을 의미해요.

​

• Dimension Layer

: User, Product와 같은 특정 개체의 속성값을 갖고 있는 계층이예요.

​

• Fact Layer

: “어떠한 X가 Y했다”를 반드시 담고 있는 레이어이며, 여기에는 사용자 행동 데이터, 객체의 생성 및 변화 이벤트가 포함될 수 있어요. 이전 예제에서 “유저가 피드를 보고 결제했다"와 같은 행동을 예시로 들 수 있어요.

DBT 사용 - 규칙

Base Layer

• 원천 데이터를 한 번 가공한 기본 데이터 (DBT의 staging이라고도 볼 수 있음).

​

• Join이나 Aggregation과 같은 별도의 연산을 하지 않고 원천 데이터와 1:1로 최대한 매핑되는 구조

​

• 필요한 컬럼들은 Rename, Type Casting, 문제 있는 데이터의 수정 등을 해서 이후 모델링 과정에서 통일성과 효율성 챙기기
• 예시) userId > user_id, id류는 string type 등�
• 물리적 테이블이 아닌 view로 materialize

DBT 사용 - 규칙

Dimension Layer

• Dimension 계층부터는 JOIN, WHERE 등 복잡한 연산이 들어갈 수 있음

​

• 개체의 속성을 표현하기 때문에 많은 컬럼 + 개체의 수만큼의 row 수 => table로 materialize

​

• 데이터의 최신화가 필요하기 때문에 주기적으로 계산되도록 구성했고, dbt tags로 최신화 주기를 자동 조정할 수 있도록 구성

​

• 자주, 전사적으로 사용되는 Dimension들에 대해서는 데이터 가치화팀에서 직접 관리하고, 각 로직이나 컬럼들에 대한 컨텍스트를 최대한 담았음

DBT 사용 - 규칙

Fact Layer

• Fact에도 복잡한 연산이 들어갈 수 있고 시간 흐름에 따라 데이터가 지속해서 추가 돼서 데이터 크기가 큼.
• 데이터 크기가 크고, 시간 단위로 데이터를 나눌 수 있기 때문에 데이터 조회와 적재 효율성에서 이점을 얻기 위해 incremental로 materialize

​

• One big fact table로 만들어서 fact만 사용해도 충분할 수 있도록 필요한 컬럼들을 다 추가했음

​

• Dimension layer와 동일하게 dbt tags로 데이터 최신화 주기를 자동 조정할 수 있도록 구성했습니다.

​

DBT 사용 - sql

• ref로 sql내에서 다른 모델 의존할 수 있도록 구성.
• 이때, 모델들이 서로 참조할 때 cyclic한 상황이 발생하지 않도록 방어 로직 작성

​

• 모델의 특성에 따라 필요한 macros들을 만들어서 sql내에서 사용

ㅍ

reference

ㅍ

macros

DBT 사용 - macros

snapshot으로 저장하는 macros

bigquery query에 custom label추가하는 macros

DBT 사용 - yaml

materialization

• yaml, sql에 config 정의만으로 저장 방식, 파티셔닝, 클러스터링 방식을 쉽게 정의 가능

​

• yaml에서 모델의 버전 지정 가능

partitioning, clustering

versioning

ㅍ

DBT 사용 - Airflow 주기적 적재 - 테스트

DBT 사용 - Airflow 주기적 적재 - 테스트

• dbt tag 기반 scheduling interval 등을 조정해서 별도의 DAG 생성

DBT 사용 - Airflow 관측성

DBT 사용 - 개발

• 각자 로컬에 DBT를 설치하지 않고 Github에 코드를 올리면 별도의 환경에서 개발할 수 있도록 구성
• 환경세팅이나 credential등을 신경쓰지 않을 수 있도록
• 다수의 구성원들이 사용할 예정이기 때문에 개개인의 쿼리가 큰 비용이 나오게 하는 것을 방지하기 위해

DBT 사용 - Docs

DBT 사용 - Docs

DBT 사용 - Docs

DBT 사용 - Good Points

1. 원하는 정보가 이미 정제되어서 존재한다. 짧은 쿼리로 정보를 손쉽게 접근할 수 있다.
2. 원하는 정보가 신뢰할 수 있는 형태로 만들어졌다. 추가적인 가공이나 확인이 필요 없다.
3. 정보가 잘 정의가 되어 있고, 정보를 쉽게 이해할 수 있는 방법이 있다. 정보가 어떻게 만들어졌는지 쉽게 알고 이해할 수 있다.
4. 정보 탐색이 쉽다. 원하는 정보가 있을 때 거의 바로 찾아서 활용할 수 있다.

SELECT

a.userId AS user_id

…

FROM table_a AS a

LEFT JOIN table_b AS b

ON a.userId = b.user_id

WHERE deleted IS NULL

AND a.userId IS NOT NULL

AND status = “SOMETHING”

AND type IN (“A”, “B”)

…

SELECT

*

FROM users_bought_something

+) 복잡한 쿼리를 많이 할 필요가 없어 비용 효율성도 증가

DBT 사용 - Good Points

• 원하는 정보가 이미 정제되어서 존재한다. 짧은 쿼리로 정보를 손쉽게 접근할 수 있다.
• 원하는 정보가 신뢰할 수 있는 형태로 만들어졌다. 추가적인 가공이나 확인이 필요 없다.
• 정보가 잘 정의가 되어 있고, 정보를 쉽게 이해할 수 있는 방법이 있다. 정보가 어떻게 만들어졌는지 쉽게 알고 이해할 수 있다.
• 정보 탐색이 쉽다. 원하는 정보가 있을 때 거의 바로 찾아서 활용할 수 있다.

+) 도메인 지식을 갖춘 구성원이 직접 만든 SQL 로직 + 데이터 테스트

+) 모델의 변경사항이 필요하면 원천 데이터를 업데이트 하지 않고 모델을 변경하면 됨.

DBT 사용 - Good Points

• 원하는 정보가 이미 정제되어서 존재한다. 짧은 쿼리로 정보를 손쉽게 접근할 수 있다.
• 원하는 정보가 신뢰할 수 있는 형태로 만들어졌다. 추가적인 가공이나 확인이 필요 없다.
• 정보가 잘 정의가 되어 있고, 정보를 쉽게 이해할 수 있는 방법이 있다. 정보가 어떻게 만들어졌는지 쉽게 알고 이해할 수 있다.
• 정보 탐색이 쉽다. 원하는 정보가 있을 때 거의 바로 찾아서 활용할 수 있다.

+) Documentation을 통해 각 모델들에 대한 정의와 설명, 비즈니스 로직을 볼 수 있음

DBT 사용 - Good Points

• 원하는 정보가 이미 정제되어서 존재한다. 짧은 쿼리로 정보를 손쉽게 접근할 수 있다.
• 원하는 정보가 신뢰할 수 있는 형태로 만들어졌다. 추가적인 가공이나 확인이 필요 없다.
• 정보가 잘 정의가 되어 있고, 정보를 쉽게 이해할 수 있는 방법이 있다. 정보가 어떻게 만들어졌는지 쉽게 알고 이해할 수 있다.
• 정보 탐색이 쉽다. 원하는 정보가 있을 때 거의 바로 찾아서 활용할 수 있다.

솔직히 어려운 부분 🙏 �데이터 가치화팀도 노력하고 있는 부분

Part 4 - 앞으로의 계획

앞으로의 계획

• 더 많은 핵심적인 정보들이 DBT with Airflow로 생산될 수 있게 하는 것 (feat. 발로뛰기)
• Base/Dimension/Fact외에 필요한 계층들에 대한 지원과 모델링에 대한 고민
• 도메인 지식을 갖은 구성원들이 더 쉽게 모델을 개발하고, 데이터를 백필하고, 테스트할 수 있는 환경의 구축
• 데이터 가치화팀의 다른 Karrotmetrics, 실험플랫폼 등과의 유기적인 연결

쉬운 정보 생산

앞으로의 계획

• 더 쉽게 원하는 데이터의 탐색이 이루어질 수 있도록 탐색 경험 개선
• 원하는 데이터를 쉽게 활용하고 데이터 드리븐 의사결정 iteration을 더 빠르게 할 수 있도록 지원
• ex) UI based charts, LLM

쉬운 정보 사용

채용 + Q&A

당근과 함께 할 멋진 동료를 찾고 있어요!

🥕 Software Engineer, Data

🥕 Data Scientist, Decision

🥕 Data Analyst - Enterprise-wide

​

당근마켓 데이터 직군 채용

https://about.daangn.com/jobs/data/