데이터 마트에서는 뭘 파나요?(feat. OLTP, OLAP)

자~데이터 담으러 가자(feat.안내상님, 송곳)

 

- 들뜬 마음으로 마트에 방문한 A씨. 

- 어라? 그런데 구매하려고 했던 바나나가 없다. 

- 바나나 다 팔렸나요? 질문을 남긴 안씨. 직원C씨는 알아 보고 오겠다는 말을 남긴채.. 다시 돌아오지 않았다.

- 왜 직원은 돌아 오지 않았을까?

 

1. 화장실이 급해서

2. 갑자기 관둠

---

고민에 빠진 직원

---

- 정답은 둘다 아니다.

- C씨는 A씨의 질문을 받자 말자 곧장 마트 창고로 달려갔다. 

- 창고에도 남은 바나나가 없었다.

- 하지만, C씨는 일전에 있는 재고를 없다고 하여 혼난 적이 있다 

- 또 혼나기 싫었던 C씨 확실히 확인하기 위해 사내 데이터 베이스에 먼저 접속했다.

상품 상태 테이블

발주일자	상품명	발주물량	상태	업데이트일자
2023-03-10	SuperSweetBanana	3	판매완료	2023-03-10 11:00:00
2023-03-10	SuperHoBak	3	판매중	2023-03-10 10:00:00

판매 테이블

판매일자	상품명	구매량	재고
2023-03-10 10:00:00	SuperSweetBanana	2	1
2023-03-10 11:00:00	SuperSweetBanana	1	0

- 이제 바나나 재고가 확실히 없다는 사실을 알게된 C씨.

- 그런데, 그때 무전이 온다. 띠링 띠링. 호박 다 떨어졌어?

발주일자	상품명	발주물량	상태	업데이트일자
2023-03-10	SuperSweetBanana	3	판매완료	2023-03-10 11:00:00
2023-03-10	SuperHoBak	3	판매완료	2023-03-10 12:00:00

판매일자	상품명	구매량	재고
2023-03-10 10:00:00	SuperHoBak	2	1
2023-03-10 12:00:00	SuperHoBak	1	0

- 확인해보니 정말 다 떨어졌다.

- A씨가 아쉬운대로 마지막 남은 대왕호박을 사갔기 때문

https://www.chosun.com/site/data/html_dir/2015/11/06/2015110602272.html

---

OLTP

---

- 이제 C씨는 바나나 다 떨어졌어? 호박 다 떨어졌어? 에 대해 확실히 대답을 할 수 있게 됐다.

- C씨가 이 질문에 대해서 확실히 대답을 할 수 있었던 이유는 데이터 베이스가 있었기 때문이다.

- 데이터 베이스가 도움이 된 이유는 데이터 베이스가 OLTP(Online Transaction Processing)를 하기 때문이다.

- 여기서 Transaction이란 데이터 베이스에서 수행하는 작업 단위이다.

- 예를 들어서 호박 판매 중 -> 판매 완료로 변하는 Transaction을 살펴 보자.

- 오전 11시에는 판매중이었지만, 12시에 재고가 0이되면서 판매 중 -> 판매 완료로 업데이트 되었다. 즉, 판매 중 -> 판매 완료로 업데이트 하기 위해서는 재고가 0이 되어야 한다. 재고가 0이 되지 않으면 상품 상태는 변하지 않는다.

- 이와 같이 논리적인 순서로 구성되어 있는 작업들의 집합을 Transaction이라고 한다. 

- 상품 상태 테이블에서 변화가 발생하기 위해서는 판매 테이블에서 먼저 변화가 일어 나야한다.

- 데이터 베이스는 OLTP를 이용해서 본인을 최신 상태로 유지한다.

- 여하튼, 데이터 베이스 덕분에 C씨는 고객한테 답변을 할 수 있게 됐다. 

---

OLAP

---

- 그런데, C씨는 아직 사무실을 떠나지 못했다. 왜냐하면, 발주 물량을 정해야 하기 때문.

- 지난 해 바나나를 너무 많이 발주하여 집에서 남은 바나나를 혼자 다 먹은 경험이 있어서일까? 

- C씨는 생각에 잠겼다. 얼마나 발주해야하지?

- C씨는 침착하게 데이터베이스에서 과거 판매 내역을 살펴 보기로 했다.

- 하지만, 웬 영문인지 데이터 베이스에서는 최근 발주 내역밖에 없었다.

- 어렴풋이, 생각해보니 마트 영업 기간이 길어지면서 데이터가 많이 쌓이다보니, 데이터 베이스가 무거워지면서 운영성 조회 속도가 너무 느려졌다는 얘기를 들었던 것 같다. 

- 데이터 업무를 담당하는 D씨에게 과거 데이터를 찾고 싶다고 급한대로 연락했고, 다행히 D씨가 도와준다고 했다.

- 그런데, D씨는 과거 데이터를 어디서 찾는다는 걸까?

- 윗 줄에서 말했듯이 조회 속도가 느려짐에 따라 운영성 업무에 차질이 생겼고

- 이에 따라 데이터 베이스에는 최근 발주 내역만 남길 필요성이 생겼다. 

- 그래서 과거 판매 내역(Historical Data)은 데이터 웨어하우스(DataWareHouse)라는 곳에 저장하기로 했다.

- 우여곡절 끝에 D씨를 통해 과거 판매 데이터를 전달 받은 C씨는 과거 판매 내역을 분석하여 발주량을 결정해보기로 했다.

- 이와 같은 업무를 OLAP(Online Analytic Processing)라고 한다. 그리고 이를 데이터 웨어하우스에서 독립적으로 수행하면

- 데이터 베이스에 주는 부담(조회 속도 저하)도 덜 수 있다.

- 데이터를 전달 받은 C씨는 20초만에 시계열 차트를 그려볼 수 있었다.

- 그 이유는 D씨한테 전달 받은 데이터가 깔끔하게 처리되어 있었기 때문이다.

발주일자	상품명	판매량	판매 일자
2022-03-10	SuperSweetBanana	20	2023-03-10
2022-03-10	SuperSweetBanana	30	2023-03-11
2022-03-10	SuperSweetBanana	40	2023-03-12
2022-06-10	SuperSweetBanana	100	2023-06-10
2022-06-10	SuperSweetBanana	200	2023-06-11

- D씨는 이럴 때를 대비해서 매일 자정 판매 테이블에서 데이터를 불러와서(Extract) 일간 판매량을 합산하여(Transformation) 데이터 웨어하우스에 별도로 저장(Load)하고 있었다. 

- 이러한 과정을 ETL이라고 한다.

- 여하튼, D씨의 도움 덕분에 C씨는 30개 쯤 발주하면 되겠다라고 결론을 내리고 퇴근을 하나 싶었으나..

- 책상 밑에서 잠복하고 있던 상사 E씨가 나타났다. 

MBC. 무한도전

- C씨는 온몸에 소름이 쫙 돋았지만 침착하게 작년도 판매 내역을 보고 30개만 발주하기로 결정했다라고 상사에게 말했다.

- 그리고 혼자 은근 칭찬도 기대했다

- 그렇지만, 칭찬은 커녕 C씨는 또 혼났다. 

- 왜 혼났을까?

- 작년 3월의 경우 적게 발주했지만 당도가 높아 순식간에 완판됐고, 6월의 경우 많이 발주했지만 당도가 낮아 발주량 대비 판매량이 적었다. C씨가 현상을 너무 단순하게 본 것이다.

- 여하튼, 발주량 대비 판매량과 당도를 같이 볼 필요가 생긴 C씨는 다시 D씨에게 연락했다. D씨가 도와준다고는 했지만

- 아까 보다 훨씬 많은 시간이 걸렸는데.. 그 이유는 2 가지 때문이다.

1. 데이터 웨어하우스 안에 테이블이 너무 많아 뭐가 당도고 뭐가 발주량인지 확인하는데 너무 오래 걸렸고

2. 각각의 테이블을 하나로 합치는데(Join)또 많은 시간이 걸렸기 때문이다.

데이터 웨어하우스의 미로에 빠져버렸다..

---

데이터 마트

---

- 여하튼, 발주량 대비 판매량과 당도를 같이 살펴본 끝에 C씨는 겨우 퇴근할 수 있었다.

- 안쓰러웠던 D씨는 각각의 테이블을 합쳐서 아래와 같은 데이터 마트를 만들어줬다.

발주일자	상품명	판매량	재고	당도	판매 일자
2022-03-10	SuperSweetBanana	20	70	10	2023-03-10
2022-03-10	SuperSweetBanana	30	40	10	2023-03-11
2022-03-10	SuperSweetBanana	40	0	10	2023-03-12
2022-06-10	SuperSweetBanana	100	600	7	2023-06-10
2022-06-10	SuperSweetBanana	200	400	7	2023-06-11

- 또한, 위 데이터 마트를 이용해서 당도별로 판매량을 살펴볼 수 있는 대시보드도 같이 구성해줬다.

- 그리고, C씨는 더 이상 야근을 하지 않게 되었다.

- 왜일까? 

- 그 이유는 중요 데이터에 대한 접근성을 높였고 이에 따라 동일한 시간에 더 많은 비즈니스 문제(발주량)를 해결할 수 있게 되었기 때문이다. (더 이상 데이터 웨어하우스의 미로를 탐험할 일도, 탐험을 다한 후 조인을 할 필요도 없어졌다.)

- 이제 제목의 질문에 대해 대답을 할 수 있게 되었다.

데이터 마트에서는 뭘 파나요?

- 데이터 마트에서는 데이터에 대한 접근성을 판매한다.

- 아무리 잘 만든 데이터라도 사용자들의 접근성이 낮다면 활용되지 못하고

- 결국 구석 한켠에서 저장 비용만 차지하고 있게 된다. 

- 그렇지만, 접근성을 높이려고 계속 마트를 생성하는 것이 능사는 아니다.

- 왜냐하면, 접근성에 대한 담보로 중복 데이터가 생성될 수 밖에 없기 때문이다(data redundancy).

- 위에서 예시로 든 데이터 마트도 결국에는 각각의 테이블에 나누어져서 저장되어 있었다.

- 이를 하나로 합치면 결국 동일한 데이터가 중복돼서 생길 수 밖에 없다.

- 그럼, 어떻게 마트를 구성하는게 좋은 걸까?

- 스키마를 어떻게 구성할 것인지(Star, Snowflake) / 데이터 소스를 어디서 가져올 것인지 (Dependent Data Mart, Independent Data Mart, Hybrid Data Mart)에 대해 많은 설명들을 봤지만.. 개인적으로 제일 와닿았던 것은 

I say data marts should be by subject area, not by department.

https://dataakkadian.medium.com/data-lake-data-mart-and-data-warehouse-4644fc0ac18

 

위 문구였다. 위에서 예시로든 발주량을 선정하는 일은 모두가 관심을 가질만한 중요한 주제이다. 어떤 스키마를 짤지, 데이터를 어디에서 가져올지(데이터 소스)도 중요하지만 마트를 흥행(=데이터 접근성 향상)시키기 위해서는

 결국에는 잘 팔릴만한 주제(subject area)인지가 가장 중요할 것이다.

 

Ref.

---

https://medium.com/@michelle.xie/explain-by-example-oltp-vs-olap-d5603ac2038b

https://www.youtube.com/watch?v=FxpRL0m9BcA&list=LL&index=47 

https://dataakkadian.medium.com/data-lake-data-mart-and-data-warehouse-4644fc0ac18