데이터 레이크(Data Lake), 데이터 웨어하우스(Data Warehouse), 데이터 마트(Data Mart)의 기초 개념

구글링을 하면 좋은 테크블로그들이 많지만 그런 글들은 정말 잘 하신 분들이 쓴 글들이기 때문에 전문적인 용어들이 많이 섞여있거나 중간에 설명이 생략된 부분이 많아 처음 공부를 시작하는 사람들 입장에서는 조금 이해하기 어려울 수 있다는 생각이 들었다.

 회사에서 데이터 웨어하우스 구축 프로젝트를 처음 시작하면서, 그리고 그 프로젝트가 데이터 레이크 구축 프로젝트로 전환되면서 각 개념에 대해 책을 읽고 강의를 찾아보며 공부했던 개념들을 최대한 쉽게 적어보려 한다.

 

데이터 레이크, 데이터 웨어하우스, 데이터 마트는 데이터를 어떤 목적으로 저장하느냐에 따른 구분이라고 볼 수 있다. 각 용어에 대한 개념을 정립하기 전에 가장 먼저 유념해야할 점은 회사마다 정의하고 있는 개념이 어느 정도 다를 수 있다는 것이다. 따라서 이 글에서는 일반적으로, 그리고 원론적으로 공유하고 있는 개념에 대해서 적을 예정이다.

 

 어떤 "목적"으로 저장하느냐에서 "목적"을 큰 개념으로 구분하면 OLTP와 OLAP로 구분할 수 있다. 데이터 레이크, 데이터 웨어하우스, 데이터 마트에 저장되는 모든 데이터는 기본적으로 OLAP, 즉 "분석" - 많이 사용되는 용어로는 BI(Business Inteligence)활동-을 위한 데이터이다 . 하지만 그렇다고 해서 데이터 레이크 = OLAP 데이터 베이스는 아니다. 데이터 레이크는 OLAP를 위한 데이터를 모아놓는 전초기지 같은 공간이라고 생각하는 편이 더 가깝다.

---

데이터 웨어하우스 (Data Warehouse)

 가장 큰 단위의 저장 공간은 데이터 레이크이지만, 이에 앞서 데이터 웨어하우스를 이해해야한다.

 1990년대 후반까지만 해도 많은 기업에서는 운영과 분석에 동일한 데이터 베이스를 이용했다. 하지만 인터넷 사용자가 늘어나면서 데이터가 많아지고 데이터 분석이라는 활동이 각광받으면서 이런 운영 방식은 다음과 같은 문제점을 초래했다.

 

• 데이터가 운영을 중심으로 저장된다 (e.g. 대출, 예금) - 하지만 분석 기준은 다를 수 있다.
• 데이터가 커지면서 분석을 위한 요청도 서버에 부하를 줄 수 있고, 서버의 부하는 고객의 요청에 대한 응답을 늦춘다.
• 사용자가 사용하기 쉬운 또는 사용자에게 제공되어야하는 데이터의 형태와 분석가가 필요로 하는 데이터의 형태에 차이가 있어 분석에 용이한 형태로 데이터를 제공되지 못하거나, 형태를 변환하기 위한 추가적인 작업이 반복적으로 필요하다.
• 전사적 정보에 대한 통합 분석이 어렵다.
• 운영을 위한 데이터 베이스는 최신의 데이터만 가지고 있지만 분석을 위해서는 시간에 따른 데이터의 변경사항이 필요하다.

 

 이 한계점들을 극복하고자 분석을 위한 데이터 베이스를 분리하고, 통합적인 정보가 주제를 중심으로 저장되는 저장소를 구축하게 되었는데 이것이 데이터 웨어하우스다. 여러가지 저장소로부터 가져온 정보가 통합되기 때문에 데이터의 창고라는 의미에서 데이터 웨어하우스라는 이름이 붙었다. 데이터 웨어하우스는 비즈니스 의사결정을 지원할 수 있는 분석 작업을 목적으로 데이터를 구성하며, 주로 정형 데이터를 기반으로 하기 때문에 관계형 데이터베이스를 엮어서 사용한다.

 여기에서 "엮어서"사용한다는 말이 잘 안와닿을 수 있는데, 이건 데이터 웨어하우스를 지원하는 도구들을 살펴보면 바로 이해할 수 있다. 데이터 베이스 안에 테이블들이 있고, 여러 개의 데이터 베이스들을 마치 테이블처럼 조회해서 사용할 수 있도록 하며 말 그대로 "전사적" 정보를 제공해주기 때문에 일반적으로 회사 하나당 하나의 데이터 웨어하우스가 구축된다.

 대표적으로 많이 사용되는 데이터 웨어하우스 툴로 AWS의 Redshift, Google의 Bigquery, Snowflake가 있다.

 

데이터 레이크 (Data Lake)

 Lake - 호수, 즉 자연 상태를 의미한다. 원천 데이터가 수집되는 장소이다.

 빅데이터 시대가 도래하면서 데이터가 사물인터넷, 소셜미디어, 클릭 스트림 등 다양한 소스에서 예상할 수 없는 형태로 빠르게 발생하기 시작했다. 이러한 데이터들도 분석 대상이 되면서 데이터 형태에 관계없이 데이터를 빠르게 한 곳에 저장하기 위해 등장한 것이 데이터 레이크다(현재는 이 이유가 데이터 레이크를 구축하는 유일한 이유는 아니며, 회사마다 다양할 수 있다.).

 

 즉, 데이터 웨어하우스와 데이터 마트는 저장된 데이터를 '분석'하는 것이 주요 목적이라면 데이터 레이크는 발생하는 모든 데이터를 (분석에 사용 될지 안 될지 모르겠지만)한 곳에 '일단 저장'하는 것이 목적이다. 따라서 데이터 레이크에는 소스로부터 발생한 데이터가 가공되지 않은 형태로 저장되며, 이 데이터를 원시 데이터(raw data)라고 부른다.

 

   앞서 언급했듯, 데이터 웨어하우스는 분석을 목적으로 하기 때문에 관계형 데이터베이스로 구성되는 것이 일반적이었다. 관계형 데이터베이스의 단점은 쓰기 속도가 느리다는 점이다. 더군다나 데이터 베이스 스키마에 맞추기 위해서는 추가 가공(transformation)작업이 필요한 경우가 많다.

 

• 데이터의 가공 및 저장 속도가 발생 속도를 따라잡지 못함
• 비정형, 반정형 데이터의 저장 필요

 

 위의 두 가지 요건 중 하나 이상을 충족하기 위해 데이터 레이크는 일반적으로 파일 저장소나 NoSQL을 사용하여 구축된다. 대표적으로 AWS의 S3나 HDFS가 있다 (MongoDB에 만들었다는 얘기도 들어본 것 같기도 하다..). 데이터 레이크에 저장되는 데이터는 그 자체로 사용되는 것이 아니라 가공되어 데이터 웨어하우스 또는 데이터 베이스에 옮겨지는 것이 목적이기 때문에 ETL도구 또는 데이터 웨어하우스 툴과의 호환성이 좋은 저장소로 선택하는 것이 좋은 것 같다.

 데이터 레이크 툴을 선택할 때 고려해야할 부분이 하나 더 있다. 어느 정도의 사이즈로 발생할 지도 모르는 데이터를 모두 한 곳에, 발생할 때마다 저장하는 것은 쉬운 일은 아니다. 데이터를 저장하기 위한 공간을 미리 확보해야하는데, 물리적인 공간을 확보하는 속도가 데이터가 들어오는 속도를 따라갈 수 없기 때문이다. 속도를 따라잡기 위해 큰 저장 공간을 확보해뒀다가 그만큼의 데이터가 쌓이지 않으면 그 비용은 고스란히 회사의 손실로 돌아가게 된다. 이럴 때는 데이터 레이크를 클라우드 환경에 구축하는 것이 일반적이다. 클라우드 서비스의 장점 중 하나는 서비스를 이용하는 만큼만 비용을 지불하면 되기 때문에 갑작스러운 변화에 대처하기 용이하며 빠르게 인프라를 구축할 수 있다는 점이다. 단점은 사소한 실수 하나가 엄청난 비용 문제를 초래할 수 있다 (예를 들면 잘못 짠 쿼리라던가..)

 데이터 레이크에 저장된 데이터는 주기적으로 소멸시키는 것이 좋다. 그렇지 않으면 dark data(사용하지 않는 데이터, 불필요한 데이터)가 비용을 계속 잡아먹는 문제가 발생할 수 있다.

(+) 추가로 데이터 레이크 티어링(Tiering)이라는 것도 있다. AWS에 정말 좋은 컨퍼런스(?)들이 많은 것 같다.

 

데이터 마트 (Data Mart)

 데이터 웨어하우스가 코스트코라면 데이터 마트는 편의점이다. 동네에 코스트코도 있지만(심지어 동네에 없을 수도 있음) 편의점도 있는 이유와 같다. 바나나 한 송이를 사기 위해서 넓디 넓은 코스트코를 탐험하는 것도, 코스트코까지 걸어가서 청과물 코너까지 다다르는 머나먼 여정도 굳이 감내할 필요가 있을까? 만약 바나나 한 송이를 사는 작업이 매일 일어난다면?

 데이터 마트는 특정 부서가 필요로하는 분석 목적에 맞는 데이터를 다루기 위해 구축된다. 데이터 웨어하우스에는 통합된 정보가 저장된기 때문에, 데이터가 커질수록 조회에 많은 비용이 발생한다. 따라서 데이터 웨어하우스에서 각 분석 목적에 맞는 데이터들을 따로 빼 놓은 저장소가 데이터 마트이다.

 데이터 웨어하우스가 정형 데이터를 저장하고 있기 때문에 데이터 마트 역시 정형 데이터를 다루는 관계형 데이터베이스를 사용한다.

 

 데이터 마트를 구축함으로써 특정 분석가나 부서가 더욱 보기 쉬운 형태 또는 플랫폼으로 데이터가 제공 될 수 있고, 조회 시간과 비용을 아낄 수 있다는 장점이 있다.  추가로 데이터 저장소의 권한을 부서로 축소하여 데이터의 권한에 대한 관리도 가능하다.

 즉, 데이터 마트 구축의 필요성에 대해 검토할 때는, 데이터 마트 구축 비용과 데이터 마트를 구축함으로써 아낄 수 있는 시간, 금액 등을 비교해볼 수 있다.

 

ETL

 마지막으로 ETL이라는 용어에 대해서 간략히 설명하자면, 앞서 데이터 웨어하우스에는 원천 데이터가 저장된다고 했고, 데이터 웨어하우스에는 정형 데이터가 저장된다고 했다. 그러니 데이터 레이크에서 데이터 웨어하우스로 데이터를 옮기기 위해서는 데이터를 레이크에서 추출해서(Extract) 데이터 웨어하우스의 스키마에 맞게 변환해서(Transform) 데이터 웨어하우스에 적재하는(Load) 작업이 필요하다. 그리고 데이터는 계속해서 쌓이므로 이 작업이 주기적으로 일어나야한다.

 각 작업의 앞글자를 따서 데이터를 옮기는 전체 과정을 ETL 파이프라인이라고 하고, 이 작업이 주기적으로 & 자동으로 일어날 수 있도록 도와주는 툴을 구축하고, 모니터링할 수 있는 작업을 데이터 엔지니어들이 한다.

 현재는 꼭 데이터 레이크에서 데이터 웨어하우스로 옮기는 작업에만 국한되어 사용되는 것은 아니다. 어떤 소스가 있고, 해당 소스에서 데이터를 추출해서 분석을 목적으로한 구조로 변환한 후 대상 저장소로 적재하면 ETL이라고 할 수 있다 (그리고 요즘은 ELT로 바뀌고 있다고 하는데..To be continued..)

 

 ETL 툴이라고 해서 Airflow, Glue같은 기술들이 많이 들리지만 ETL툴을 사용해야지만 ETL작업을 한 것은 아니다 (이렇게 생각했다면 ETL을 다시 이해해야한다). 간단하게 파이썬 코드 몇 줄과 DB API, 스케줄러만 가지고도 구현할 수 있다. 다만 해당 툴들은 다른 프레임워크나 툴들과의 호환성이 좋고 많은 기능들을 제공하기 때문에 큰 데이터들을 몇 줄의 코드나 클릭 몇 번으로 편하고 빠르게 옮기도록 도와주며, 작업들이 잘 진행되고 있는지 모니터링을 하는 것도 쉽게 도와주는 도구들이라고 생각할 수 있다.

 

---

 

 서두에 말했듯 데이터 레이크, 데이터 웨어하우스, 데이터 마트라는 용어들은 기술적인 구분이 아닌 사용적인 구분이므로 모든 회사에서 세 개를 다 구축하고 있는 것도 아니며 의미 또한 조금씩 다르게 사용될 수 있다 (실제로 데이터 레이크 -> ETL -> 데이터 베이스(마트라고 할 수 없음) 프로젝트를 함 (중간에 데이터 웨어하우스 없음))는 점을 꼭 기억해주었으면 한다.

 

 *혹시 글에 수정해야할 부분이나 코멘트 있으시면 자유롭게 댓글 남겨주세요!