프로그래머스[데이터 엔지니어링 스타터 키트] 필기 : AWS&Cloud&Redshift 간단한 개념

Cloud computing란?

내가 필요한 하드웨어나 소프트웨어가 있는경우, 이를 준비할때 시간이 많이 걸리는데 클라우드 업체가 미리 준비해놓음으로써 아주 쉽게 사용할 수있고 사용한만큼 돈을 낸다. 

시기를 미리 예측해서, 필요한 서버나 데이터베이스를 미리 구축해둔다. 따라서 트래픽이 갑자기 늘어도 대응을 잘 할 수 있다.

AWS가 대표적

 

* airflow는 기존의 아파치 꺼를 쓰는게 좋다. AWS의 서비스는 오픈소스 작업을 할 수 없다. AWS내의 소스들만 활용 가능하다.

 

AWS Redshift

데이터 웨어하우스란?

• 분리된 데이터베이스이다. 기존 프로덕션 데이터베이스에서 작업을 하면 실제 서비스에 영향을 미친다. 이런 이유로 분리한 데이터 베이스인 데이터 웨어하우스는 데이터용으로만 활용된다.
• SQL(관계용 데이터베이스용 프로그래밍 언어)은 여전히 중요하다. 잠깐 하둡이 떴을때 맵리듀스프로그래밍이 떴었다. 하지만 직관적이지 않고 모든것을 키밸류 값으로 변환해야 해서 불편하다. 생산성이 낮다. 맵리듀스위에 SQL을 얹은 것이 Hive이다. 기존 맵리듀스만 쓸때보단 속도는 떨어지지만 생산성이 올라가고 SQL을 알고 잇으면 그대로 사용 가능하다. 현재는 구조화된 데이터는 SQL언어로 다 프로세싱한다. (Hive, Spark, Presto 등...)
• 내부화된 데이터베이스이므로, 속도보단 양이다. 엄청난 양의 데이터를 합리적으로 잘/정확하게 처리할 수 있느냐이다.
• 최종적으로는 DW 위에 summary table을 만들어서 목적에 따라서 summary table만 사용하도록 한다.
  ->매출용 요약테이블, 마케팅용 요약테이블
• 데이터 엔지니어가 아닌 이상, raw data에 접근할 수 없도록 한다.(일관성을 유지할 수 있다.)
• redshift는 고정비용이다. snowflake와 빅쿼리는 사용하는 만큼 내는 거다. 차후에 데이터양이 많아지면 오히려 후자가 더 나아질 수 있다. 왜냐면 데이터가 엄청 많아졌을 경우, redshift가 감당하지 못한다.(보통 스타트업 시리즈  C,D까진 괜찮다)
  -> 오히려 빅쿼리일수록 쿼리를 잘짜야 한다. 왜냐면 비효율적인 쿼리라도 비용 부담이 다 되기 때문에,
• primary key uniqueness를 보장하지 않는다.(보장하면 벌크업하기 힘들어지기 때문이다.)
  -> 따라서 잘 코딩해야 primary key를 보장할 수있다.
• 테이블 디자인이 매우 중요하다.
  -> 어느 필드가 distribution key인지를 임의로 지정해줘야한다. 이것이 중요한 이유는, redshift 내에서 노드를 늘려나가면, 후에 데이터를 저장할 때 어느 노드에 저장할 지를 결정해주는 것이기 때문이다.
• redshift spectrum은 redshift의 약점을 보완해주는거긴 한데 실제로 그렇게 좋진 않다. ELT에 해당
• JSON, TEXT 타입이 없다. (너무 긴 텍스트는 알아서 잘라서 저장된다.)

-> 테이블에 레코드를 넣어줄 때 다른 경우처럼 건바이건으로 넣으면 너무 오래걸린다. 따라서 bulk insert를 한다.

-> datasource에서 파일을 읽고 ETL스케줄러에서 S3에 파일을 전체적으로 업로드하고,  S3에서 이 파일을 전체적으로 DW에 bulk update를 한다. 

 

 

 

redshift에 access 하는 방법

• 보통 postgres 접근 가능한 툴로는 모두 접근 가능하다/ JDBC, ODBC 라이브러리 활용
• 파이썬에서는 psycopg2모듈로 접근
• sql editor에서는 Postico/SQL workbench/python notebook로 접근가능

 

database management practice

1. SQL필수로 해서 데이터에 접근

2. 데이터 보관 기한(로그데이터는 모든것을 보관하지 않아도된다. 데이터 용량으로 적절히 삭제해주어야 한다. 매출데이터는 영구보관) -> 물론 삭제한다고 삭제는 아니고 어딘가에 백업한다.

3. 스키마 구조가 중요하다. 테이블을 세종류로 나눠서 저장한다.

->raw data(어디에선가 읽어온 데이터) / analytics(외부 데이터를 정리한 데이터) / adhoc(모두가 접근 가능한 데이터)

4. naming도 중요하다

5. 프로덕션 테이블에서 복사해오는 과정에서도 프로덕션 테이블에 무리를 준다. 따라서 master-slave를 데이터팀 전용으로 만들어서 데이터팀은 이 slave를 복사해온다.

6. 데이터 양이 많아지면 이제 매번 모두 읽는거는 힘들어진다. 새로운 데이터만 읽을 수 있도록 해야하는데 이것 또한 복잡하지만 중요

7. 읽어온 데이터가 너무커서 매번 읽기가 힘들다. 따라서 바뀐거만 업데이트하는 것.(incremental update)

8. 업데이트 주기는 일단 매일매일 주기로 업데이트 하다가 시간 분단위로 줄이다가, 더 주기를 줄이기 위해서는 kafka 등으로 스트림처리를 해야한다.

 

-> 권한 지정을 한명씩 하는게 아니라 왼쪽 쿼리를 참고해서 보면 그룹을 지어서 권한을 부여한다.