데이터 웨어하우스와 데이터레이크

왜 운영시스템과 분리해서 데이터 웨어하우스를 만들어야 할까요?

운영시스템는 OLTP라고 하고, 분석 시스템은 OLAP라고 하는데 이 둘간의 목적이 아예 다르기 때문입니다.

OLTP

OLTP는 일상적인 업무 처리가 주된 목적입니다. 예를 들어, 주문, 결제, 회원가입과 같은 작업에서 데이터 삽입(INSERT), 수정(UPDATE), 삭제(DELETE)가 빈번하게 발생합니다. 이때는 단일 트랜잭션의 빠른 처리 속도가 가장 중요합니다.(스피드가 생명) 또한 데이터의 중복을 최소화하고 일관성을 유지하기 위해 정규화된 스키마 구조를 가집니다.

OLAP

반면, OLAP는 데이터 분석에 초점을 맞춥니다. 매출 분석이나 시장 트렌드 파악처럼 대량의 데이터를 집계하고 분석하는 것이 목표입니다. OLAP 시스템은 빠른 데이터 읽기를 위해 비정규화된 스키마 구조를 가지는 경우가 많으며, 읽기 중심의 복잡한 쿼리에 대해 빠른 응답 시간이 중요합니다.

즉, 운영은 스피드가 중요하고, 분석은 좀 깊이 있게 해야 하니까 서로 방해하지 않도록 분리해야 하는 것입니다.

만약 운영 DB에 지난 1년치 전체 매출 분석을 위한 무거운 분석 쿼리를 날리면 시스템 전체가 늘어져서, 정작 중요한 실시간 거래 처리에 영향을 줄 수 있습니다.

DW - 데이터 웨어하우스

이때 DW는 OLAP가 가능하게 해주는 데이터창고 입니다.

DW를 구축해두면 분석가들이 DW를 통해 마음놓고 쿼리를 날려 분석할 수 있습니다.

또한 DW는 여러 시스템에 흩어져 있는 데이터를 한 곳에 모아서 이렇게 통합해놓고, 분석에 필요한 과거 이력 데이터, 히스토리 데이터를 쌓아서 보존해 줍니다

사람들이 많이 사용하는 플랫폼으로는 BigQuery, Snowflake, Databricks, AWS Redshift가 있습니다.

차원 테이블과 사실 테이블

백엔드 개발자가 MYSQL과 같은 DB를 모델링 하는것처럼 데이터 엔지니어는 DW를 차원 모델링을 합니다.

DW는 정형데이터이기 때문에 분석 쿼리 성능을 높이기 위해서는 차원 모델링을 해야합니다.

또한 백엔드 개발자는 바로 테이블을 설계하면 되지만 데이터 엔지니어는 차원 테이블과 사실 테이블로 구분해서 설계해야합니다.

• 차원 테이블은 ‘누가, 언제, 어디서, 무엇을’과 같은 분석의 속성을 담는 테이블입니다.
• 사실 테이블은 ‘얼마나 많이, 몇 개’와 같은 분석의 측정 지표수치를 담는 테이블입니다.

예를 들어 “매출액, 판매 수량, 클릭 수” 같은 것들은 사실 테이블로, “제품 이름, 고객 성별, 날짜” 같은 것들은 차원 테이블로 설계하면 됩니다.

스타 스키마

이제 테이블의 구성을 알았으니 차원 모델링을 할 텐데 차원 테이블의 대표적인 구현 방식 중 하나가 바로 스타 스키마입니다

스타 스키마는 이름처럼 사실 테이블 하나에 여러 차원 테이블들이 직접 딱 붙어 있는 별 모양 같은 단순한 구조입니다.

조인이 적어서 쿼리 속도가 빠르고 딱 보면 구조가 이해가 쉽다는 장점이 있습니다.

단점을 굳이 꼽자면 차원 테이블 안에서 정보가 좀 중복될 수는 있습니다. 그래도 워낙 직관적이고 빨라서 가장 널리 쓰이는 방식입니다.

스노우플레이크 스키마

차원 테이블의 대표적인 구현 방식 중 다른 하나는 스노우플레이크 스키마입니다.

스노우플레이크 스키마는 이름 그대로 눈꽃처럼 모양처럼 스타 스키마의 차원 테이블을 더 잘게 쪼개서 정규화한 것입니다.

데이터 중복을 줄일 수 있으니까 저장 공간을 좀 아낄 수 있습니다. 대신에 테이블 조인이 훨씬 많아져서 쿼리가 복잡해지고 성능은 오히려 느려질 수 있습니다.

그래서 스노우플레이크 스키마로 설계를 할 때는 복잡하고 계층적인 차원 구조를 좀 명확하게 관리해야 할 필요가 있을 때 성능 저하 가능성을 염두하고 고려해야합니다.

ETL

분석에 좋은 구조를 만들었다면 이제 실제로 데이터를 그 안으로 가져와야 합니다.

이 과정이 바로 ETL(추출-정제-적재)입니다.

추출

추출은 말 그대로 운영 DB나 로그 파일, 외부 데이터 같은 다양한 소스에서 필요한 데이터를 가져오는 단계입니다. 처음에는 전체 데이터를 다 가져오고(Full Load), 그 다음부터는 바뀐 부분만 골라서 가져오는 방식(Incremental Load)입니다.

변환

변환은 추출해서 가져온 원본 데이터를 깨끗하게 다듬는 작업입니다. 예를들어 결측치 채우고, 날짜 형식 통일하고 여러 소스에서 온 데이터를 통합합니다. 또한 분석 목적에 맞게 데이터를 가공하기도 합니다. 예를들어 고객의 최근 3개월간 구매 금액을 계산하여 새로운 지표를 생성하는 것이 여기에 해당합니다.

적재

적재는 그렇게 잘 변환된 데이터를 데이터 웨어하우스의 미리 만들어 둔 테이블 구조에 맞게 집어넣는 과정입니다. 대량으로 한 번에 넣는 방식(Bulk Load)과, 주기적으로 변경된 것만 업데이트하는 방식(Incremental Load)이 있습니다.

DL - 데이터 레이크

데이터 웨어하우스는 주로 분석을 위해 잘 정제되고 구조화된 데이터(정형 데이터)를 저장합니다. 그리고 데이터, 저장하기 전에 미리 스키마, 즉 테이블 구조를 정의합니다. (Schema on write)

반면에 데이터 레이크는 정형 데이터는 물론이고 이미지, 동영상, 센서 데이터, 로그 파일 같은 반정형, 비정형 데이터까지 모든 형태의 원시 데이터, 로우 데이터를 일단 그대로 다 저장하는 거대한 저장소입니다. 스키마는 데이터를 저장할 때 정하는 게 아니라 나중에 데이터를 읽어서 분석할 시점에 필요에 따라 정의합니다. (Schema on read)

장점은 DW보다 유연하고, 다양한 데이터를 탐색하기 좋습니다. 또한 데이터 레이크는 보통 AWS S3나 Azure Data Lake Storage, Google Cloud Storage 같은 저렴한 객체 스토리지를 사용하기 때문에 많은 양의 데이터도 비용 부담을 좀 덜면서 저장할 수 있습니다.

단점은 관리를 제대로 안 하면 뭐가 뭔지 알 수 없는 데이터스웜프(늪)에 빠질 수 있습니다.

정리하면, 이름에서 알 수 있듯이 데이터 웨어하우스는 데이터를 차곡차곡 쌓아둔 창고와 같고, 데이터 레이크는 모든 자료를 모아둔 거대한 호수 같은 느낌입니다.

데이터 레이크와 데이터 웨어하우스는 어느 하나가 더 좋다고 단정하기보다, 각각의 용도에 따라 다르게 활용된다고 보면 됩니다. 그래서 이 둘의 장점만 합친 데이터 레이크 하우스라는 아키텍처도 있습니다.

이미지 출처:
· Tracking Garden
· NashTech Blog
· Nix United