Spotify Project 07. Spotify - 분석 파이프라인 구축(프로젝트 완료)

약 1달 반정도의 사이드 프로젝트를 마치고자 한다.

우선, 프로젝트를 시작하기에 앞서 구상했던 파이프라인이다.

우선 spotify 의 데이터를 가져오는 데이터 파이프라인을 구현하기에 앞서 위의 파이프라인을 구상했다.

구상할 때 고려했던 조건은 1가지이다.

 

1. 데이터의 특성을 고려한 DB 선정

처음에 가져오려했던 artists, genres 데이터의 경우에는 필요한 데이터만 저장을 하고 사용할 데이터이다.

즉, 확장을 하더라도 컬럼이 늘어나는 것이 아닌 artists 와 genres 이 두개의 그룹에 속하는 rows 만 증가하는 것이기

때문에 데이터 량의 증가에 있어서 충분히 대응할 수 있는 RDBS 의 MySQL 을 선택했다.

 

그 다음은 DynamoDB 선택한 이유인데, 해당 DB 의 경우 NoSQL 계열의 DB로서 확장성이 좋고, 대용량의 데이터를 

빠르고 효율적으로 다룰 수 있는 장점이 존재한다. 그러한 이유 덕분에 추후 계획하고 있는 챗봇 서비스에서

유저와의 커뮤니케이션으로 발생하는 데이터들을 저장하는 데 문제 없으리라고 한단하여서 

DynamoDB 를 선택했다.

 

마지막으로는 AmazonS3  이다. S3 의 경우에는 RDB 또는 NoSQL에 사용될 raw 데이터들을 

저장하는 용도로 사용했다. 파이프라인을 구축하는데 있어서 확장성의 한계가 명확한 RDB보다

확장성에 있어 매우 유연한 S3 를 사용했다.

NoSQL 계열인 DynamoDB 를 사용할 수 있었지만, Dynamo 는 추후, 챗봇 서비스에 사용하게 될 예정이며, DB에 과부하를 주어선 안된다고 판단했다.

또, S3 자체로도 AWS 에서 가장 접근이 쉽고, 많은 데이터 플로우에도 충분히 

과부하가 안걸리고 충분히 데이터 레이크를 만들어 안정적으로 서버를 운영할 수 있다는 신뢰가 있었기에 

S3 를 데이터 레이크로 사용을 했다.

 

데이터 레이크에 대한 설명은 추후 아래의 링크를 참고할 예정이다

https://brunch.co.kr/@pubjinson/52

데이터 레이크 

 

데이터 파이프라인을 구축할 때, 가장 중요한 것이 DB 설계라고 본다.

필요한 데이터를 가져오는 Process 를 구축하여  rest API  등에서 데이터를 가져와서 가공하는 것도 중요하지만,

어떤 DB를 선택하느냐에 따라, 추후 설계할 서비스의 성능이 결정되기 때문이다.