시작하기 전..
RDB란, Relational DataBase로 관계형 데이터베이스를 의미한다. DW(Data Warehouse)는 데이터웨어하우스 포스팅에서 공부한 것처럼, 여기저기에 축적된 데이터들을 공통된 형식으로 변환하여 관리하는 데이터베이스를 말한다. 즉, DW는 RDB와 같은 곳에 저장된 데이터들을 공통된 형식으로 변환하여 저장하는 곳이라고 볼 수 있다.
오늘은 RDB와 DW의 차이점과 다양한 DW 아키텍처에 대해 알아보고자 한다.
RDB vs DW
목적
RDB는 주로 빠른 읽기/쓰기를 필요로 하는 어플리케이션을 위해 사용된다.
DW는 여러 개의 RDB의 데이터들을 모아서 분석하기 위해 사용된다.
MSA에서는 RDB가 여러 개이기 때문에 하나로 모은다는 것이 말이 되지만, 모노리스에서도 DW가 필요한 이유는 무엇일까? 바로, 실제로 사용되고 있는 RDB에 쿼리를 날려 분석을 하게 되면 실제 서비스에 영향을 줄 수 있기 때문이다.
구조
RDB는 데이터 중복을 피하고 데이터 무결성을 위하여 정규화된 구조를 사용한다.
DW는 복잡한 쿼리를 최적화하기 위해 비정규화된 구조를 사용한다. 또한, 쿼리 성능을 높이기 위하여 데이터 중복을 허용한다.
데이터 소스
RDB는 주로 운영되고 있는 서비스를 통해 데이터가 생성된다.
DW는 운영되는 서비스를 통해 생성되는 데이터뿐만 아니라, 운영 시스템에서 생성되는 로그 및 다양한 소스에서 데이터를 통합하여, ETL 프로세스를 사용하여 공통된 형식으로 변환하여 저장한다.
성능 최적화
RDB는 빠른 읽기/쓰기를 위해 최적화되어 있고, 트랜잭션 성능을 위해 설계되어 있다.
DW는 대규모 데이터에 대하여 복잡한 쿼리와 분석을 위해 읽기 성능을 우선시한다.
DW Architecture
화해의 Data Warehouse
화해의 데이터 웨어하우스 아키텍처에 대한 기술 블로그를 참고하여 데이터 웨어하우스의 적용 사례에 대해 알아보았다.
화해에서는 상품과 관련된 상품 DB와 쇼핑과 관련된 쇼핑 DB가 있었다고 한다. 이때 발생한 문제는, 브랜드마다의 매출 비교를 할 때 발생했다. 브랜드의 상품들의 정보가 담긴 상품 DB와 매출 정보가 담긴 쇼핑 DB를 사용해야하는데, 문제는 복잡한 데이터를 추출하기에는 운영 DB에 부하가 발생할 수 있고 데이터를 추출하는데 많은 시간이 든다는 것이다.
화해는 이를 해결하고자 Data Lake를 도입하였다. 각 DB에 있는 데이터들을 그대로 Data Lake에 저장하였다. 하지만 여기에서도 발생한 문제는, 운영 DB의 부하는 줄였지만 기존 테이블의 컬럼, 다른 테이블과의 Join Key, 비즈니스 로직을 파악하고 쿼리를 작성해야 한다는 점이었다.
화해는 이를 해결하고자 Data Warehouse를 도입했다. 아키텍처는 다음과 같다.
아키텍처를 이렇게 설계함으로써, Data Lake에 쌓이는 데이터들은 ETL을 통해 원하는 스키마로 만들어 Data Warehouse에 적재하고 이를 분석에 용이하게 사용할 수 있게 되었다고 한다.
해당 글은 2022년 글로 아마 더 발전한 아키텍처로 구현되어 있지 않을까? 싶다. 하지만 현재 아키텍처에 대한 기술 블로그를 아직 찾을 수 없어 조금 아쉽다..
나의 생각
해당 글을 읽기 전의 나였다면 제품 DB와 쇼핑 DB의 데이터들을 Data Lake에 넣지 않고 바로 Data Warehouse 에 적재했을 것이다. 단순한 파이프라인만 생각하여 제품 DB와 쇼핑 DB의 데이터들을 미리 변환하여 Data Warehouse에 적재했을 것 같다.
하지만 해당 글을 읽고 나니 DW에 적재하기 전 DL에 미리 원시 데이터를 만들어 놓는 것이 중요하다는 생각을 하게 되었다. 만약 운영 DB에서 바로 ETL을 통해 DW에 적재하게 된다면 운영 DB에 부하를 줄 수도 있지만 DL을 경유하여부담을 덜 수 있다.
오토피디아의 Data Warehouse
오토피디아는 초기에는 DW 구축 없이 데이터 분석 요청이 발생할 경우, DB의 덤프 파일을 로컬에서 다운받은 후 주피터 노트북을 통해 다른 데이터들과 변환을 통해 분석을 진행했다고 한다. 데이터를 올바르게 수집하고 빠르게 분석하기 위하여 데이터 웨어하우스를 구축하게 되었다고 한다.
오토피디아에서는 위와 같은 아키텍처로 데이터 웨어하우스를 구축했다고 한다. 서비스별로 GCP 프로젝트를 할당하고, 데이터을 여러 과정을 통해 모두 BigQuery에 적재했다. 그리고 dbt를 통해 분석용 GCP 프로젝트에 1시간 단위로 데이터를 업데이트했다고 한다.
나의 생각
현재 사내에서는 빅쿼리에 저장하는 데이터셋이 2개뿐이라서, 데이터 정리 규칙과 네이밍 컨벤션에 대해서 제대로 된 정립을 하지 않았지만, 오토피디아의 글을 통해서 데이터와 비즈니스가 확장될 수 있음을 고려하여 데이터웨어하우스 내에서도 데이터 정리 규칙과 네이밍 컨벤션을 함께 정립해야함을 알게 되었다.