[DW] Star Schema와 Snowflake Schema에 대하여...
안녕하세요. 주형권입니다.
데이터웨어하우스 관련 글을 오랜만에 쓰는 것 같습니다. 글을 읽기 전에 이 글의 내용은 제가 알고 있고 공부한 내용을 바탕으로 설명하였습니다. 이 내용을 꼭 맹신하지 않고 혹시라도 다른 내용이 있다면, 서로 비교하여 읽기를 추천드립니다.
데이터웨어하우스 (이하 DW) 관련한 여러 가지 글이 있는데 그중에 DW의 설계 기법인 Star Schema와 Snowflake Schema에 대해서 설명해 보려고 합니다. DW를 하다 보면 가히 필수로 알아야 하는 개념이며 추가적으로 Galaxy Schema라는 설계 기법도 존재합니다. 최근에는 BigQuery와 같은 컬럼 형식으로 저장하면서 이러한 기법을 굳이 사용하지 않아도 최적의 저장 효율을 제공합니다.
DW 기법이 필요한 이유는?
DW 기법이 필요한 이유는 제 생각에는 초기에 DW를 만들 때 데이터를 저장하는 공간의 부족과 가격 그리고 성능 문제였다고 생각합니다. 제가 처음에 DW에 입문했을 때에 저는 RDB를 이용하여 DW를 구축하였습니다. 그 당시 Microsoft에 MS SQL Server (이하 MSSL)을 사용하여 구축했을 당시 저장 공간이 1TB였습니다.
현재 생각해 보면 정말 턱 없이 부족한 공간입니다. 요즘에는 시간당 1TB가 넘게 데이터가 들어오는 곳도 흔하고 작은 회사라도 수십수백 TB의 데이터를 보유한 곳이 정말 많습니다. 하지만 그 당시에는 HDD의 가격이 있는 것도 있고 클라우드가 그렇게 흔하지 않았습니다. IDC (International Data Corporation)가 대부분이었고 서버의 DISK를 연결할 수 있는 Slot 자체가 한정적이었습니다. 그렇기에 한정적인 자원에서 데이터를 저장하고 이를 효율적으로 읽을 수 있도록 하는 게 굉장히 큰 과제였습니다.
그렇다면 그림을 통해서 실제로 RDB에서 DW 기법을 사용했을 때와 안 했을 때의 차이를 한번 알아볼 필요가 있을 것 같습니다. 아래의 그림은 신규 가입자(NRU) FACT 테이블을 나타낸 그림입니다.
위와 같이 설계 기법을 무시하고 설계할 경우 지역, 성별, 연령대를 모두 한글로 표기하여 보여줍니다. 당연히 지표를 봐야 하기 때문에 FACT 테이블에 한글로 표기하였으며 지금 현재의 데이터를 실제로 넣고 DW를 설계하여도 크게 성능상 문제나 BI를 만들었을 때 속도가 전혀 느리지 않을 것입니다. 앞서 이야기 하였던 용량 문제도 크게 문제가 없을 것 입니다. 그 이유는 건수가 현재 5건뿐이기 때문입니다.
하지만 위와 같은 내용이 2억 건이라고 생각해보면 어떨까요? MSSQL에서는 한글 1글자가 2byte를 차지합니다. 그렇기 때문에 이 데이터의 건수가 늘어날수록 계속해서 용량은 기하급수적으로 증가합니다.
이 경우 데이터의 저장 공간을 줄이기 위해서 tinyint와 같은 작은 숫자 값을 이용해서 데이터의 수치를 나타낼 필요가 있습니다. 또한 RDB의 페이지 저장 구조 기법의 경우 페이지의 크기가 커지면 커질수록 성능이 현저하게 느려집니다. 데이터를 가져올 때 읽어야 하는 범위 자체가 많아지므로 성능이 매우 느려집니다. 데이터 분석가, 마케터 분들이 시라면 지표를 보실 때 당연히 1~2일 정도가 아닌 1~2년 치의 데이터를 보시는 경우가 흔할 거라고 생각됩니다.
최근에 DW 기법의 중요성이 강조되지 않는 이유?
최근에는 AWS, GCP, Azure 등 클라우드 컴퓨팅이 나오면서 DISK 증설이나 새로운 DISK를 버튼 몇 번으로 추가가 가능하지만 당시에는 이러한 일이 굉장히 큰 일이었습니다. 서버를 이미 샀기 때문에 이를 환불할 수도 없고 함부로 업그레이드하는 일도 쉽지 않았습니다.
하지만 앞서 언급했듯이 클라우드가 등장하면서 컴퓨팅 자원의 가히 무한대에 가까워지고 (비싸지만...) 여러 가지 저장 기법(column store,key-value store)과 같이 여러가지 저장기법 그리고 여러가지 데이터웨어하우스를 구축할 수 있는 도구 (BigQuery , Snowflake )등이 등장하면서 DW 설계 기법은 조금씩 고려되지 않고 있습니다.
그렇지만 DW 설계 기법이 완전히 무시되지는 않습니다. 실제로 많은 회사에서는 FACT와 Dimension 테이블을 만들고 이를 조인하여 보는 경우가 굉장히 많고 많은 회사에서 FACT 테이블을 이용하여 BI를 구현합니다. (row 형태로 할 경우 성능이 매우 좋지 않음) 그렇기에 DW 설계 기법은 당연히 알고 있어야 하는 설계 기법이며 데이터 엔지니어의 경우는 필수라고 생각되는 설계 기법입니다.
Start Schema란?
그렇다면 Start Schema란 무엇일까요?
앞서 위에서 언급했던 그림을 그대로 가져와서 위에서 잠깐 언급했던 것과 같이 tinyint로 변형하여 값을 나타내 보겠습니다.
위와 같이 FACT 테이블의 한글로 표기된 값을 숫자인 tinyint로 변환하여 저장하면 다음과 같이 변환이 됩니다. 지금 보시면 전혀 무슨 값인지 알 수 없는데요. 이를 알수 있게 하기 위해서 필요한 게 Dimension 테이블입니다. Dimension의 정의를 찾아보면 Label 테이블이라고 하는 경우가 있습니다. 이게 무슨 말인지 이해가 안 가셨다면 지금 무슨 말인지 이해가 가실 것 같습니다. 이것도 그림으로 표현하면 다음과 같습니다.
Dimension 테이블을 만들었더니 정확하게 저기에 표현된 숫자(키) 값이 무슨 말인지 알 수 있습니다. 각각의 키값과 그에 따른 값을 매칭 하여 보면 어떤 값을 표현하는지 알 수 있습니다. 당연한 이야기지만 FACT의 경우는 계속해서 수치가 기하급수적으로 늘어나지만 Dimension의 경우는 그 값이 기하급수적으로 늘어나진 않습니다.
그래서 이 테이블을 JOIN 하여 데이터를 가공하고 BI 도구를 이용하여 데이터를 사용자에게 보여주는 것 입니다. 자 그렇다면 왜 우리는 이것을 Start Schema라고 부를까요? 답은 정말로 간단합니다. 앞서 이야기 했듯이 우리가 데이터를 보거나 BI로 데이터를 보여줄때는 이 FACT와 Dimension을 JOIN하여 사용하는데요.
이것을 나타낼 때 ERD에서는 가운데 FACT를 두고 옆에 Dimension 테이블을 옆에 그린 뒤 관계를 연결하여 표현합니다. 그래서 이것을 그림으로 그릴 때 모양이 꼭 별같이 생겼다고 해서 Star Schema입니다.
Snowflake Schema란?
그렇다면 Snowflake Schema란 무엇일까요?
이 기법은 Star Schema에서 파생된 개념입니다. 이것을 그리려면 정규화가 필요한데요. 미리 말씀드리면 Star Schema에서 Dimension을 정규화하여 표현한 게 Snowflake Schema입니다.
그래서 Snowflake Schema의 단점을 찾아보면 JOIN을 많이 해야 한다고 쓰여있는데요. 그럴 수밖에 없는 게 정규화를 했으므로 테이블이 더욱 세분 환 됩니다. 예시를 한 가지만 보면 다음과 같습니다. 예를 들어서 위에서 나온 지역을 더욱 세분화하여 시, 구까지 요구할 경우가 있습니다. 처음에 정규화를 알지 못하여 테이블을 다음과 같이 설계하였습니다. (예시가 조금 별로지만 정규화를 설명하는 것이 아니기 때문에 이해 부탁드립니다.)
위의 내용을 보면 1차 정규화 위반입니다. 1차 정규화는 다음과 같은 내용이 만족해야 합니다. 위에서 보면 시, 구 칼럼에 속성이 2개씩 들어가 있습니다. 이를 정규화시켜야 합니다.
- 각 컬럼이 하나의 속성만을 가져야 한다.
- 하나의 컬럼은 같은 종류나 타입(type)의 값을 가져야 한다.
- 각 컬럼이 유일한(unique) 이름을 가져야 한다.
- 컬럼의 순서가 상관없어야 한다.
1차 정규화를 통해서 테이블을 분리하면 다음과 같은 형태가 나옵니다. 이를 다시 한번 FACT와 연결하면 다음과 같은 그림이 나옵니다. (대충 그린 점 이해 부탁드립니다...)
정규화를 여러 개 했기 때문에 테이블을 모두 연결하면 그 모양이 눈 결정 모양이라고 하여 Snowflake Schema라고 부릅니다. 저 같은 경우는 주로 Star Schema를 사용하였고 Snowflake Schema의 경우는 앞서 언급한 JOIN을 너무 여러 번 해야 하는 이슈도 있고 하여 많이 써보진 않았습니다.
마치며...
위에서 설명한 DW 기법은 매우 중요한 기법입니다. 위에서 그 중요도가 많이 떨어졌다고는 하지만 아직도 많은 회사와 사람들은 FACT 중심으로 데이터를 가공하여 저장하고 Dimension을 이용하여 JOIN 후 데이터를 보는 경우가 많습니다. 그렇기 때문에 위에 2가지 설계 기법은 매우 중요한 개념이라고 할 수 있습니다.
아마도 데이터 엔지니어를 준비하시는 분들이라면 이 2개의 설계 기법을 많이 물어볼 것이라고 생각됩니다. 그렇기 때문에 이 블로그 이외에도 많은 블로그를 통해서 조금 더 정확하게 공부해서 가시면 도움이 많이 될 것이라고 생각 됩니다.