관계형 데이터 베이스
구조화된 데이터를 저장하는데 사용되는 관계형 데이터베이스가 무엇인지 알아보자
구조화된 데이터를 저장하고 질의할 수 있도록 해주는 스토리지
테이블 정의를 위한 DDL(Data Definition Language)
테이블 데이터 조작/질의를 위한 DML(Data Manipulation Language)
production database
- MySQL, PostgreSQL, Oracle
OLTP(online transaction processing)
빠른 속도에 집중(아니면 사용자가 기다림), 서비스에 필요한 정보 저장
데이터 웨어하우스 RedShift, Snowflake, BigQuery, Hive
- OLAP(online analytical processing)
처리 데이터 크기에 집중. 데이터 분석 혹은 모델 빌딩등을 위한 데이터 저장
보통 프로덕션 데이터 베이스를 복사해서 데이터 웨어하우스에 저장.
RDBMS의 구조
- 2단계로 구성됨
- 가장 밑단에는 테이블들이 존재(테이블은 엑셀의 시트에 해당)
- 테이블들은 데이터베이스 라는 폴더 밑으로 구성
테이블의 구조(테이블의 스키마)
- 테이블은 레코드들로 구성
- 레코드는 하나 이상의 필드로 구성
- 필드는 이름과 타입과 속성(primary key)으로 구성됨
SQL
structured Query Language
모든 대용량 데이터 웨어하우스는 SQL 기반
구조화된 데이터를 다루는 한 SQL은 데이터 규모와 상관없이 쓰인다.
단점
구조화된 데이터를 다루는데 최적화가 되어있음
정규표현식을 통해 비구조화된 데이터를 어느 정도 다루는 것은 가능하나 제약이 심함
많은 관계형 데이터베이스들이 플랫한 구조만 지원함
구글 빅쿼리는 nested structure를 지원함
비구조화된 데이터를 다루는 spark, hadoop과 같은 분산 컴퓨팅 환경이 필요해짐
관계형 데이터베이스마다 sql 문법이 조금씩 상이
데이터 인프라
- 데이터 웨어하우스
- ETL 프로세스
- 분산 처리 환경
Production db 와 데이터 웨어하우스의 차이
star schema
production db용 관계형 데이터베이스에서는 보통 스타 스키말ㄹ 사용해 데이터를 저장
데이터를 논리적 단위로 나눠 저장하고 필요시 조인. 스토리지의 낭비가 덜하고 업데이트가 쉬움
-> 다른 테이블의 디테일을 보기 위해서는 다른 테이블을 키를 통해 조인해야함.
매칭하는데 리소스도 필요함.
denormalized schema
데이터 웨어하우스에서 사용하는 방식
단위 테이블로 나눠 저장하지 않음으로 별도의 조인이
스토리지를 더 사용하지만 조인이 필요 없기에 빠른 계산이 가능
데이터웨어하우스에 적합 -> 스토리지 크기에 영향을 받지 않음
데이터웨어하우스
- 회사에 필요한 모든 데이터를 저장
프로덕션 데이터베이스와 분리 되어야 한다. 분석 쿼리를 날리다 보면 서버 불안 등, 문제가 생길 수 있다. 이상한 쿼리를 날리더라도 회사 서비스 자체의 안전성에는 문제가 생기지 않음.
여전히 SQL 기반의 관계형 데이터베이스
-
프로덕션 데이터베이스(ex. MySQL)와는 별도이어야 함.
-
프로덕션 디비의 복사본을 가지고 그 이외의 데이터들을 복사하여 가지고 있어야함
-
여기서 제일 중요한 데이터는 프로덕션 디비에 있는 데이터 들임.
-
OLAP(online analytical processing) = 데이터 웨어하우스
-
OLTP(Online Transaction Processing) = 프로덕션 디비
AWS - redshift : 고정 비용
GCP - Big query : 쿼리당
Snowflake : 쿼리당
데이터 웨어하우스는 고객이 아닌 내부 직원을 위한 데이터베이스
- 처리속도가 아닌 처리 데이터의 크기가 더 중요해짐
ETL 혹은 데이터 파이프라인
- 외부에 존재하는 데이터를 읽어다가 데이터 웨어하우스의 테이블로 저장해주는 것이 필요해지는데 이를 데이터 파이프라인 혹은 ETL이라고 부른다.
데이터 인프라란?
데이터 엔지니어가 관리함
- 여기서 한단계 발전하면 spark와 같은 대용량 분산처리 시스템이 일부로 추가됨
서비스에서 직접 생기는 데이터와 써드파티를 통해 생기는 간접 데이터
-> (ETL -> 데이터 웨어하우스 : 데이터 Infra)
데이터 팀의 관점에서는 데이터 인프라가 첫번째 단계이다.
데이터 순환 구조
-> 사이트 방문 트래픽과 외부 데이터 -> 데이터팀(인프라 구축) -> 비즈니스 인사이트 -> 개인화등을 통한 제품 서비스 개선(데이터 사이언티스트) ->
Cloud와 Aws 소개
클라우드의 정의
- 컴퓨팅 자원을 네트웍을 통해 서비스 형태로 사용하는 것
키워드
- No provising - 준비할 필요가 없어요
- Pay As you go
필요한 만큼 실시간으로 할당하여 사용한만큼 지불
- 탄력적으로 필요한 만큼의 자원을 유지하는 것이 중요
만약 클라우드 컴퓨팅이 없었다면??
-
서버/네트워크/스토리지 구매와 설정등을 직접 수행
-
데이터센터 공간을 직접 확보(co-location)
-
확장이 필요한 경우 공간을 먼저 더 확보해야함
그 공간에 서버를 구매하여 설치하고 네트웍 설정 -
보통 서버를 구매해서 설치하는데 적어도 두세달을 걸림
-
또한 peak time을 기준을 Capacity planning을 해야한다.
-> 블랙프라이데이등에 자원을 맞추다보니 노는 자원이 있는 현상 발생 -
직접 운영비용 vs 클라우드 비용
기회비용 비교
클라우드 컴퓨팅의 장점
초기 투자 비용이 크게 줄어듬
-
CAPEX(Capital Expenditure) vs OPEX(operating Expencse)
초기 비용 vs 운영 비용 -
리소스 준비를 위한 대기시간 대폭 감소
short time to market -
노는 리소스 제거로 비용 감소
-
글로벌 확장 용이
-
소프트웨어 개발 시간 단축
-
managed service (SaaS)이용
AWS 소개
가장 큰 클라우드 컴퓨팅 서비스 업체
2002 아마존 상품데이터를 api로 제공하면서 시작
현재 100여개의 서비스를 전세계 15개의 지역에 제공
EC2 - Elastic Compute Cloud(1)
AWS의 서버 호스팅 서비스
- 리눅스 혹은 윈도우 서버를 론칭하고 어카운트를 생성하여 로그인 가능
- 가상 서버들이라 전용 서버에 비해 성능이 떨어짐
On-Demand : 시간당
Reserved : 연간 구독 디스카운트
Spot Instance : 일종의 경매 방식을 놀고 있는 리소스들을 비용으로 사용할 수 있는 옵션
S3 - simple storage service
- 아마존이 제공하는 대용량 클라우드 스토리지 서비스
- s3는 데이터 저장관리를 위해 계층적 구조를 제공
기타 중요 서비스 - Database Services
RDS
- MysQL, postgre, aurora
- oracle, ms sql service
DynamoDB
Redshift
ElasticCache
Nepture
MongoDB
SageMaker
- Deeplearning and machine learning end to end framework
Lex
- Conversational Interface
Polly
- Text to Speech Engine
Rekognition
- Image Recognition Service
Amazon Alexa
Amazon Connect
Lambda
Event driven serverless computing engine
- 서비스 구현을 위해서 ec2를 론치할 필요가 없음
- gcp 에서는 cloud function
- azure 에는 azure function
Redshift : Scalable Sql 엔진
2pb 까지 지원
still OLAP
- 응답속도가 빠르지 않기 때문에 프로덕션 데이터베이스로 사용불가
Columnar storage
- 컬럼별로 저장됨, record by record로 저장하는 것이 아님
- 컬럼별 압축이 가능
컬럼을 추가하거나 삭제하는 것이 아주 빠름
벌크 업데이트 지원
- 레코드가 들어있는 파일을 s3로 복사후 copy 커맨드로 redshift로 일괄 복사
고정 용량/비용 sql 엔진 vs snowflake, bigquery
다른 데이터 웨어하우스처럼 Primary key uniqueness를 보장하지 않음
- 프로덕션 데이터베이스들은 보장한다.
Redshift는 postgresql 8.x와 sql이 호환됨
하지만 postgresql 8.x의 모든 기능을 지원하지는 않음
예를 들어 text타입이 존재하지 않음
postgresql 8.x를 지원하는 툴이나 라이브러리로 엑세스 가능
JDBC/ODBC
다시한번 SQL이 메인 언어라는 점 명심
- 그러기에 테이블 디자인이 아주 중요
Redshift를 하나를 론칭을 했다면
안에 하나의 폴더를 구성 (schema를 구성)
폴더의 테이블의 특성에 맞게 테이블 분류
이러한 폴더들은 관계형 데이터베이스에 따라서 부르는 이름이 다른데,
스키마 혹은 데이터베이스라고 지칭함.
postgres, redshift는 스키마라고 함.
sql을 통해서 스키마 생성
ex)
Dev
-
raw data 폴더
외부에서 받아온 데이터
엔지니어팀이 관리 -
analytics 폴더
분석 및 인사이트 추출, 대시보드 작성
데이터 분석팀이 이용 -
adhoc
테스트용
개발자들이나 데이터일을 하는 사람들이 테스트 이용시 테이블을 작성
아무도 관리하지 않음
Redshift 엑세스 방법
postgresql 8.x와 호황되는 모든 툴과 프로그래밍 언어르 ㄹ통해 접근 가능
- SQL workbench
