DW , DM 설계에 대한 내 생각 (BI ,DS 나눠서 생각해봄 )

DW ,DM을 정말 초창기부터 설계하는일은 경험하기가 쉽지 않은 것 같다 . 보통은 어느정도 자리잡은 회사에 들어가게 되니.

이걸 처음부터 설계한다고하면 어떻게 해야할까? BI ( Data Analyst를 위한 ) 와 DS( Data Scientist를 위한)를 나눠서 생각해보았다.

1. BI

RAW

 우선 기본적으로 DB에 있는 테이블들을 그대로 가져오는 작업을 하게 될 것이다. 데이터가 유실될 가능성이 있기도 하고 우선 복사해두면 데이터에 대해 추가적으로 변경을 한다고 할 때 다시 DB에 접근할 필요없이 RAW테이블을 통해 작업할 수 있기 떄문이다 . 

 

어떻게 가공할지

 여기부터가 진짜 시작이다. DB설계를 할 때 정규화등을 고려하여 테이블을 만들지만 , DW, DM은 좀 다르다. 최대한 반정규화 , 그렇니까 한 테이블에 분석가가 필요한 컬럼들이 다 담기는 것이 좋다. 매번 조인을 해서 ( 많은시간이 소요) 테이블을 조회해야한다면 불편하기 때문.

또한 테이블의 주 사용자인 데이터분석가의 니즈를 반영하는게 가장 기본적인듯. 

 테이블을 설계하는 마인드에 대해서는 위처럼 적어봤고. 일반적으로 설계할때는 Fact table , Dimension Table 형태로 분리하여 설계하는 것이 국룰? 이다.

DB에서 가져온 RAW 테이블 (fact table) 에서 확인할수 있는 각 column들 = 각 Dimension에 대해서 count ,sum 등 집계를 통해서 유의미한 테이블들을 만든다 . 유의미하다는 것이 사실 데이터분석가입장에서 유의미한테이블이기에 데이터분석가와 논의해서 만드는것이 가장 좋긴 할 것이다 .

 그리고 이렇한 테이블을 만들때 증분 방식, 전체 복사 방식 중에 고민을 해야하는데. 테이블이 확장될 가능성이 다분하다면 증분방식, 그게 아니면 쉽게 접근할수 있는 복사 방식이 나은것 같다. 빨리 구축을 해야한다면 복사 방식으로 접근하는 것이 좋긴 하다.

2. DS

RAW

우선 DB에 적재된걸 가져와서 가공하는 BI와 다르게 에초에 저장을 시작하는 단계부터 HDFS , S3 에 그대로 저장되는 경우도

많다. ( 고객이탈예측 이런거는 아니긴하다. 여기서 말하는건 이미지나 텍스트 데이터등)  

이런 것들은 에초에 데이터를 넣어줄 때에 포맷을 잡고 넣주면 됨. 다시 긁는 짓은 굳이??.. 라는 생각이 든다. 

어떻게 가공할지

DS, 즉 feature들도 우선 기본적으로 주 소비자인 DS들과 협의해서 적재하는 것은 필수이다. BI와 다르게 DS가 가공한 feature , column등이 생길텐데 혹은 Embedding 형태의 데이터. 마찬가지로 속도가 중요하지 않은 (historical feature) 라면 그대로 hdfs를 이용하는 것이 괜찮다고 생각하되 혹시 조회 + 간단한 연산이 빈번하거나 임베딩형태라면 Elastic Search 혹은 vector database( 종류가 엄청 많은데 뭐가 best인지는 아직 잘 모르겠음. Redis 도 지원을 한다고 한다 . ) 를 쓰는 것도 나쁘지 않다.

 여기서 DW에 추가적으로 (정확히 DW 관련은 아니지만) feature의 재사용성 , 추출의 편리성등을 위해  featrue store(feast) 를 고려해 주는 것이 중요함.

 또한 feature들을 저장할때 날짜와 함께 버전을 관리해주는 것 정도가 필수적이라고 생각한다 .