dbt와 그래프 엔지니어링 그리고 비즈니스 온톨로지?

비즈니스 온톨로지를 우리는 이미 Analytics engineering이라는 용어하에 설계하고 있었다. 이를 어떻게 그래프로 활용하면 좋을까?

Feb 17, 2025

Contents

왜? Analytics Engineering?Kimball의 차원 모델링 특징 WCOJ(worst-case optimal join)?dbt!!?? opensource(무과금) 와 Cloud(과금) 그리고 그래프..?아키텍쳐(version 최종…최종..최종….)할게 많네요.. 마치며..출처

안녕하세요 정이태입니다.

오늘은 Analytics engineering 과 Orchestration 그리고 Graph에 대해 이야기해보겠습니다. 또 ... 정말 많은 시행착오를 겪었기에, 생각 정리 겸 인사이트?가 있을까하여 글을 작성해봅니다.

왜? Analytics Engineering?

우선, 제가 Analytics engineering에 관심을 갖게된 건 단순합니다. '고객' 그리고 '그래프' 두 가지 니즈를 충족해보기 위해서인데요. 다들 아시다시피 원천 데이터를 바로 그래프로 적재하는 경우는 드뭅니다. 때문에 고객들은 OLTP 에서 가공해서 그래프로 만들어야하는 과정을 거치는 경우가 많은거죠. 이게 그래프의 '진입 장벽'이라 생각해서 이를 어떻게 자동화 혹은 반-자동화해서 부담을 덜 수 있을까 하는 고민을 가지고 시작했네요.

** 물론 관계를 따로 설계할 필요가 없는 자연 그대로의 네트워크, 그래프 데이터는 이런 부하가 덜 합니다.

다시 돌아와서, 조금 더 구체적으로 살펴보겠습니다. 그럼 테이블에서 관계를 발견하고 이를 그래프 형태로 표현하는것. 즉 Analytics가 필요하게 되는데요. 이를 효과적으로 활용하는 툴 "dbt" 가 바로 핵심이라 할 수 있겠습니다.

dbt란 무엇인가 가장 간단한 설명을 인용해보자면, "이미 적재되어 있는 데이터를 조회하고 수정하는 데에 최적화된 도구입니다." 때문에 위에 언급한 OLTP 에 적재되어있는 데이터를 조회 및 수정해서 OLAP 성격을 지닌 GDBMS(그래프 데이터베이스)에 적재를 하기에 적합한 도구인거죠.

뿐만아니라, '최적화'라는 말이 나와있듯이, "modularity, portability, CI/CD and documetnation" 기능이 첨가되어있어 쿼리 엔지니어링 편의성이 많이 개선된 성격을 지닙니다.이렇게 dbt를 도입한다라고 했으면, 과연 어떤 형태로 저희는 데이터 웨어하우스를 만들 수 있을까요? 데이터 웨어하우스 설계 방식 중 하나인 Kimball 차원 모델링 특징을 한 번 살펴보겠습니다.

Kimball의 차원 모델링 특징

비즈니스 내의 주요 프로세스를 식별하고 모델링하는 하향식 접근 방식

스타 조인을 효율적으로 수행할 수 있도록 함

ETL 도구를 사용하여 스냅샷 팩트 테이블을 생성함

테이블 분할을 사용하여 시간에 따라 차원 데이터를 스냅샷으로 캡처함

컨포밍 데이터 차원을 사용하여 데이터를 통합함

** 컨포밍 데이터 차원 : 여러 데이터 마트(Data Mart) 또는 데이터 웨어하우스 내에서 일관되게(shared and reusable) 정의되고 사용되는 차원

스타 조인 , 통합, 팩트 테이블 이 저는 눈에 띄었는데요. 즉, 데이터를 여러 갈래로 분해하고 통합하는데 활용하는게 좋다. 메타 데이터를 가지고 여러 비즈니스 관점으로 프로세스를 추출하는데 이 때 fact table 은 business process ('verbs') , dimension 은 context to a business process ('nouns') 라는 표현을 합니다.

어디에서 많이 들어본 말들 아니신가요? 네 바로 비즈니스 온톨로지입니다. 이렇게 자연스레 형성되어있는 테이블 맥락들만 있다면, 어렵게만 느껴졌던 그래프 활용을 간단하게 표현해서 활용할 수 있는거죠.그럼 여기서 잠깐, 이렇게 DBT 를 통해 테이블 설계해놓고 이를 굳이 그래프로 한다? 라는 생각이 드실텐데요. 물론 그래프가 잘 하는부분이 있고 못하는 부분이 있습니다.

여기 게시글에서 모두 다루긴 힘드니 우선 그래프를 활용하면 좋은 점 세 가지 정도를 우선 말을해보자면, 1. 조인 연산 2. 시각화 3. fanin fanout 라고 할 수 있겠습니다.이 중 조인 연산에 대해 이야기를 해보자면 "Worst-case Optimal Join Algorithms" 를 짚고 넘어가야 합니다.

WCOJ(worst-case optimal join)?

SQL에서 사용하는 대부분의 JOIN 연산은 pairwise join 방식으로 수행됩니다. 즉, 두 테이블을 한 쌍씩 비교하면서 점진적으로 조인을 수행하는 방식입니다.그러나 WCOJ(Worst-case Optimal Join) 알고리즘은 multi-way join 기법을 사용합니다. 즉, 테이블을 한 번에 여러 개 조인하는 방법을 통해 더 나은 성능을 제공합니다.

기존의 SQL JOIN 방식은 일반적으로 pairwise join을 사용하며, 중간 결과(intermediate results)가 많이 생성될 수 있습니다.WCOJ는 Agarwal, Ngo, and Rudra의 Join processing 이론에 기반하여, 중간 결과 없이 최적의 연산을 수행하도록 설계된 알고리즘입니다.

중간 결과 최소화: SQL에서 전통적인 JOIN 연산은 두 개의 테이블을 조인한 결과를 다시 다른 테이블과 조인하는 방식이므로 중간 데이터가 많이 생성될 수 있습니다.즉, intermediate result 를 최적화하도록 연산이 되어 있는거죠. 심플하게 보면 내 친구의 친구의 친구의 친구와 같은 경우를 연산하려면 다중 join이 필요할텐데, 이때 발생하는 중간 결과값들을 최적화해주는 알고리즘입니다.GDBMS 들마다 이를 어떻게 개선하느냐에 따라 각각 성능이 모두 다르고 장단이 뚜렷하기에 GDBMS 를 선택하는 기준 중 하나입니다.

다시 돌아와서, 결국 여러 데이터 테이블간 조회가 필요한 경우(recursive , multi-way … )엔 GDBMS 의 엔진을 활용하는게 효율적이라는 거죠. 그렇지 않는 경우는 반면에 기존 SQL만으로도 충분히 해결할 수 있는 경우이기 때문에, GDBMS를 사용하는건 그렇게 추천하진 않습니다. 앞서 이야기한 적재 및 스터디 비용이 상당하기 때문이죠.

하지만, dbt를 통해 fact , dimension table들이 있다면 한 번 시도해보는건 나쁘지 않을거 같습니다. 늘 걸림돌이였던, semantic이 자연스레 설계가 되어있으니, 각 부처간 데이터 시멘틱이 사전 정의가 되어있다는 것을 간접적으로 유추할 수 있기 때문에 온톨로지 설계 bottle neck 중 하나인 커뮤니케이션 cost가 상당히 감소하기 때문이죠.

그럼 다시 돌아와서 dbt 입니다.

dbt!!?? opensource(무과금) 와 Cloud(과금) 그리고 그래프..?

dbt core와 dbt cloud 의 차이는 우선 과금입니다. core는 오픈소스인 반면에 cloud는 그렇지 않죠. 또한 jobs orchestration , logging and alerting , admin and metadat API , Semantic Layer 라는 고급 기능을 Cloud 버전에서는 활용할 수 있습니다. 하지만, open-source를 활용할 저였기에 Cloud 에선 가능하나 opensource에선 없는 기능을 오픈소스를 활용해 보완해야했습니다.

아키텍쳐(version 최종…최종..최종….)

dbt Core를 활용하는 고객을 전제하에 env manage , jobs orchestration , logging & alerting 은 kestra 를 활용해 보완하고 admin and metadata API 와 Semantic Layer 은 datahub 를 활용해 보완하고자 아키텍쳐를 이렇게 구성했고,아키텍쳐를 설계한 제 의도는 다음과 같습니다.

1. 주요 구성 요소 및 데이터 흐름

OLTP 계층: PostgreSQL

트랜잭션 데이터의 소스(Single Source of Truth) 역할을 합니다.

높은 빈도의 삽입(INSERT), 수정(UPDATE), 삭제(DELETE) 작업을 처리합니다.

하류 분석 처리를 위한 주요 데이터 소스로 활용됩니다.

분석 엔지니어링 계층

이 계층은 Kestra가 오케스트레이션하며, OLTP 데이터를 분석에 최적화된 형식으로 변환하는 역할을 합니다.

dbt (Data Build Tool)

SQL 기반 변환을 수행합니다.
모듈화된, 버전 관리가 가능한, 확장 가능한 변환 모델을 제공합니다.
서로 다른 유형의 분석 쿼리를 적절한 엔진(DuckDB 또는 Neo4j)으로 라우팅합니다.

DataHub (데이터 카탈로그)

메타데이터 및 데이터 계보(lineage) 관리 시스템 역할을 합니다.
스키마 변경, 업데이트 로그, 변환 이력을 추적합니다.
DuckDB, Neo4j, dbt 파이프라인 간 데이터 일관성을 유지합니다.

OLAP 처리 계층

데이터 변환 후 쿼리의 특성에 따라 적절한 분석 엔진으로 라우팅됩니다.

DuckDB (SQL 기반 OLAP 엔진)

컬럼 저장(columnar storage) 및 벡터 연산(vectorized execution) 최적화가 적용되어 있어, 집계 연산 및 필터링 연산이 빠르게 수행됩니다.

재귀적 조인이 필요하지 않은 SQL 기반 쿼리에 적합합니다.

시간 시리즈 분석, 집계, 배치 분석(batch analytics) 등에 활용됩니다.

Neo4j (그래프 기반 OLAP 엔진)

Worst-case Optimal Join (WCOJ) 알고리즘을 활용하여 재귀 조인 및 그래프 탐색 연산을 최적화합니다.

다중 홉 관계, 추천 시스템, 사기 탐지, 개인화 검색과 같은 분석을 처리합니다.

복잡한 비정형 관계 데이터를 다루는 데 적합합니다.

2. 워크플로우 오케스트레이션: Kestra

데이터 추출, 변환, 로드(ETL/ELT) 자동화 및 스케줄링을 수행합니다.

PostgreSQL → dbt → DataHub → DuckDB/Neo4j 간의 데이터 종속성을 관리합니다.

장애 복원력(fault-tolerant) 및 이벤트 기반(event-driven) 실행을 지원합니다.

배치(batch) 및 그래프 기반 증분 업데이트(incremental graph updates)를 최적화합니다.

3. 아키텍처의 설계 오버뷰

구성 요소	역할 및 필요성
PostgreSQL (OLTP)	트랜잭션 데이터를 저장하며, ACID(원자성, 일관성, 독립성, 지속성)를 보장합니다.
Kestra (워크플로우 오케스트레이션)	다단계 데이터 처리 작업을 자동화합니다.
dbt (변환 계층)	모듈화된 SQL 기반 변환을 제공하여 유지보수를 용이하게 합니다.
DuckDB (SQL 기반 OLAP 엔진)	컬럼 저장 및 벡터 연산을 활용한 고성능 SQL 분석을 제공합니다.
Neo4j (그래프 기반 OLAP 엔진)	WCOJ 알고리즘을 통해 재귀 조인 및 그래프 분석을 최적화합니다.
DataHub (메타데이터 및 계보 관리)	스키마 변화 추적 및 비즈니스 로직 업데이트를 관리하여 데이터 일관성을 유지합니다.

4. 이 아키텍처의 장점

✅ 최적화된 쿼리 성능

SQL 기반 쿼리는 DuckDB에서 기존 RDBMS보다 빠르게 실행됩니다.

재귀 조인 및 패턴 매칭이 필요한 경우 Neo4j의 WCOJ 알고리즘을 활용하여 최적화합니다.

✅ 하이브리드 스토리지 및 처리 방식

*컬럼 저장 기반 OLAP(DuckDB)**과 **그래프 네이티브 OLAP(Neo4j)**을 혼합하여 최적의 데이터 처리 방식을 선택할 수 있습니다.

SQL 기반 분석이 불가능한 복잡한 그래프 관계 데이터를 Neo4j에서 처리하여, 전통적인 SQL의 오버헤드를 줄일 수 있습니다.

✅ 확장성 및 유지보수성

dbt를 활용한 모듈화된 변환 방식 덕분에 유지보수가 쉬워집니다.

Kestra를 활용한 스케일링 가능한 자동화가 가능하여, 다양한 데이터 파이프라인을 동시에 관리할 수 있습니다.

DataHub를 통한 스키마 및 비즈니스 로직 관리로 데이터 일관성을 유지할 수 있습니다.

✅ 중간 결과 및 오버헤드 감소

Neo4j의 Worst-case Optimal Join (WCOJ) 알고리즘은 불필요한 중간 데이터를 최소화합니다.

DuckDB는 메모리 사용을 최적화하며, 벡터 연산을 활용하여 빠른 SQL 쿼리를 제공합니다.

Kestra는 복잡한 데이터 흐름을 자동화하여 수작업 개입을 최소화합니다.

5. 결론

이 아키텍처는 쿼리의 복잡도에 따라 최적의 분석 엔진을 자동 선택하는 방식으로 설계되었습니다.

일반 SQL 기반 분석 → DuckDB

재귀 조인 & 그래프 분석 → Neo4j

워크플로우 오케스트레이션 및 메타데이터 관리 → Kestra + DataHub

이러한 설계를 통해 dbt 기반 변환, Kestra 기반 오케스트레이션, DataHub 기반 메타데이터 관리가 결합된 고성능 하이브리드 데이터 처리 아키텍처가 구축되었습니다.

할게 많네요.. 마치며..

오늘은 고객분들이 어떤 문제를 겪고 있을지 직접 체험해보고 어떻게 하면 그래프를 잘 활용할 수 있을지 고민하며 얻은 인사이트를 작성해봤습니다. Analytics engineering 부터 아키텍쳐 그리고 그래프가 유용한 경우 , 데이터 웨어하우스 모델링과 같은 여러 개념들이 많이 혼재되어 있습니다. 얼핏보면 각기 다른 관점이라 생각할 수 있는데요. 데이터 내 비즈니스 로직 구현 그리고 ‘(반)자동’으로 그래프 적재한다면, 기존 고객이 겪었던 그래프 모델링에 대한 비용을 줄일 수 있을것이다라는 제 생각이 반영된 글을 작성해보았습니다.

뿐만아니라, 아직 완벽하진 않지만 얼추 합리적이라 생각되는 아키텍쳐에 대해서도 언급드렸구요. 하지만, 이쪽에 대해 미숙한게 많다보니 인프라 구성(저 모든 툴들을 단일 인프라에 구성해서 docker-compose 에 잘! 말아넣으려니 오류가 이만저만이 아닙니다.) , 다른 데이터 모델링 방식 등 여러 개선점이 많을거라 생각됩니다. 혹시나 이 아키텍쳐에 대해 경험 , 비즈니스 로직 구현 (A/B test) 등에 대한 노하우가 있으신분들은 연락 부탁드립니다. 한 수 배우겠습니다!