📌 학습목표
1. SQL의 중요성
2. 관계형 데이터베이스 (RDB)
3. SQL
4. 데이터 웨어하우스
5. 클라우드
6. AWS
7. Redshift
SQL의 중요성
데이터 관련 3개의 직군(데이터 엔지니어, 데이터 분석가, 데이터 과학자)에서 공통적으로 필요한 툴이다.
- 데이터 요약 : 큰 데이터를 프로세싱 해서 작은 데이터로 변환할 때 사용
- 데이터 분석 : 주어진 문제를 답하기 위해서 데이터 분석을 할 때 사용
데이터 엔지니어에게 필요한 지식
- Python, Java, Scala
- SQL
- 데이터베이스
- ETL/ELT (Airflow, DBT)
- Spark, Hadoop
데이터 분석가에게 필요한 지식
- SQL
- 비즈니스 도메인에 대한 지식
- 통계 지식 (for A/B 테스트 분석)
데이터 과학자에게 필요한 지식
- 머신러닝
- SQL
- Python
- 통계 지식
관계형 데이터베이스 (Relational Database)
: 구조화된 데이터를 저장하고 질의하는데 사용되는 스토리지
- 즉, 비구조화된 데이터는 관계형 데이터베이스에 저장할 수 없음
- 엑셀 스프레드시트 형태의 '테이블'로 데이터를 정의하고 저장
- 컬럼(열)과 레코드(행)의 형태로 존재
1. 관계형 데이터 베이스 유형
a. 프로덕션 데이터베이스 (OLTP; OnLine Transaction Processing)
- 응답 속도가 빠르다.
(웹 서비스나 모바일 앱에 연동해서 서비스에 필요한 정보를 바로 저장해서 쓰이는 데이터베이스이기 때문에 빠르게 응답해야한다. 응답 속도가 느려지면 사용자 방문 빈도수가 감소한다.)
- ex) MySQL, PostgreSQL, Oracle 등
★ Star schema
- 프로덕션 데이터베이스용 관계형 데이터베이스에서 데이터 저장에 사용되는 스키마
- 데이터를 논리적 단위로 나누어 별도의 테이블로 저장하고(각 테이블마다 일련번호가 붙음), 필요시 JOIN한다.
- 스토리지의 낭비가 덜하고 업데이트가 쉽다.
b. 데이터 웨어하우스 (OLAP; OnLine Analytical Processing)
- 처리하는 데이터 크기가 크다.
- 데이터 분석 혹은 모델 빌딩 등에 필요한 데이터를 저장하는데 쓰이는 데이터베이스
- 회사 규모가 작을 경우 프로덕션 데이터베이스만 있는 케이스가 많다. 이런 경우, 데이터 직군을 채용하면 프로덕션 데이터베이스의 SQL을 실행하게 된다. 프로덕션 데이터베이스는 서비스와 연동된 데이터베이스이기 때문에 만약 큰 쿼리를 사용해서 데이터베이스 속도가 느려지면 전체 서비스의 속도 또한 느려진다.
- ex) Redshift, Snowflake, BigQuery, Hive 등
★ Denormalized schema
- 단위 테이블로 나누어 저장하지 않기 때문에 별도의 JOIN연산이 필요없는 데이터 웨어하우스에서 사용되는 스키마
- 스토리지를 더 사용하지만 JOIN 연산이 필요 없어서 계산 속도가 빠르다.
2. 관계형 데이터베이스의 구조
1단계 : 데이터베이스(혹은 스키마)라는 폴더가 존재 (엑셀의 '파일'에 해당)
2단계 : 데이터베이스 밑에 테이블들이 존재 (엑셀의 '시트'에 해당)
테이블의 구조 (=테이블 스키마)
- 테이블은 각각의 레코드(행)들로 구성
- 레코드(행)는 하나 이상의 필드(컬럼=열)로 구성
- 필드(컬럼=열)는 이름, 타입, 속성(primary key)으로 구성
★ 속성(primary key)
- 하나의 필드, 하나 이상의 컬럼이 조합되어 primary key를 생성한다.
- pk로 지정된 컬럼은 그 값이 유일(unique)해야 한다. (= 동일한 값을 갖는 레코드가 1개만 존재해야 한다.)
- 특정 컬럼들의 값이 중복되는 값이 존재하면 안되는 경우가 있을 수 있다. 이러한 경우, 테이블 스키마를 정의할 때 해당 컬럼의 속성을 pk로 지정해주면 관계형 데이터베이스가 pk로 지정된 필드에 값이 유일하다는 것을 보장해준다. = 같은 값을 갖는 레코드가 추가되면 이를 reject 한다.
SQL (Structured Query Language)
: 관계형 데이터베이스에 있는 구조화된 데이터(테이블)를 질의하거나 조작하는데 사용되는 프로그래밍 언어
1. SQL의 유형
a. DDL(Data Definition Language)
: 테이블의 구조를 정의하는 언어
b. DML(Data Manipulation Language)
: 테이블 조작/질의어
- 테이블에서 원하는 레코드를 읽어오는 질의 언어
- 테이블에 레코드를 추가/삭제/갱신하는데 사용됨
2. 빅데이터에서도 활용되는 SQL의 중요성
- 구조화된 데이터를 다루는 한, SQL의 문법 자체는 데이터의 크기와 상관없이 사용된다.
- 모든 대용량 데이터 웨어하우스는 SQL 기반이다. (ex. Redshift, Snowflake, BigQuery, Hive 등)
- Spark에서는 SparkSQL, Hadoop에서는 Hive라는 SQL 언어가 지원된다.
3. SQL의 단점
- 비구조화된 데이터를 다루는 데 제약이 심하며, 이를 다루는데 Spark, Hadoop과 같은 '분산 컴퓨팅 환경'이 필요해진다.
- 많은 관계형 데이터베이스들이 플랫한 구조만 지원한다. (no nested like JSON)
- 관계형 데이터베이스 종류마다 SQL문법이 상이하다.
데이터 웨어하우스 (Data Warehouse)
: (프로덕션 데이터베이스와는 별도) SQL 기반의 관계형 데이터베이스
- OLAP (OnLine Analytical Processing)
- 프로덕션 데이터베이스의 복사본은 보유하고 있어야 함
- 제품/서비스를 사용하는 고객이 아닌 내부 데이터 팀을 위한 데이터베이스 → 처리 속도가 중요한 포인트가 아님!
- 중요한 것은 "데이터 크기와 관계없이 원하는 데이터 분석을 수행할 수 있는가?"
- 대표적 데이터 웨어하우스 : AWS의 Redshift, Google Cloud의 Big Query, Snowflace 등
★ ETL(Extract Transform Load; 데이터 파이프라인)
: 외부(프로덕션 DB 등) 데이터를 읽어와서 데이터 웨어하우스에 테이블로 저장해주는 프로세스(코드)
- Extract : 외부 데이터를 추출하는 과정
- Transform : 추출한 데이터를 원하는 포맷으로 변환하는 과정
- Load : 변환된 데이터를 데이터 웨어하우스에 테이블로 저장하는 과정
★ 데이터 인프라 (Data Infra)
- 데이터 엔지니어가 관리함
- 서비스에서 직접 생기는 데이터와 써드 파티를 통해 생기는 간접데이터를 ETL로 데이터 웨어하우스에 적재하는 구조
- 여기서 더 발전하면 Spark와 같은 대용량 분산처리 시스템이 일부 추가됨
- 데이터 팀 관점에서는 데이터 인프라가 첫번째 단계이다.
★ 데이터 순환 구조
1) 내/외부의 다양한 소스에서 데이터가 발생한다. (사이트 방문 트래픽과 외부 데이터)
2) 데이터 엔지니어가 ETL(데이터 파이프라인)을 통해서 데이터 웨어하우스에 테이블로 저장한다.
3) 데이터 분석가는 중앙에 저장된 데이터들을 통합해서 일종의 요약본을 기반으로 지표를 정의하고 시각화하면서 다양한 데이터 분석이 가능해진다. 이것으로부터 비즈니스 인사이트를 도출할 수 있다.
4) 데이터 과학자가 회사의 서비스를 머신러닝, 딥러닝의 형태로 개인화 등을 통해서 제품 및 서비스를 개선한다.
클라우드 (Cloud)
: 컴퓨팅 자원(HW, SW 등)을 네트워크를 통해 서비스 형태로 사용것으로, 자원을 필요한만큼 (거의)실시간으로 할당하여 사용한 만큼 지불하는 형태
클라우드 관련 키워드
1) No Provisioning : 사용자가 따로 준비할 필요가 없다.
2) Pay As You Go : 사용자가 쓴 만큼 돈을 지불한다.
클라우드의 장점
- 서버/네트워크/스토리지 구매 및 설정 등을 직접 수행할 필요가 없다.
- 데이터센터의 공간을 직접 확보할 필요가 없다.
- (이커머스 측면에서 트래픽이 가장 높은 시간대인) Peak time을 기준으로 Capacity Planning을 할 필요가 없다.
→ 놀고있는 리소스를 제거해서 비용이 감소한다.
- 기회비용 측면에서 재무제표에 나타나지 않는 장점이 있다.
- 초기 투자 비용이 크게 줄어든다. → CAPEX(Capital Expenditure) vs. OPEX(Operating Expense)
- 리소스 준비에 필요한 대기시간이 단축된다.
- 글로벌 확장에 용이하다.
- 소프트웨어 개발 시간이 단축된다. (Managed Service SaaS 이용)
AWS (Amazon Web Service)
- 가장 큰 클라우드 컴퓨팅 서비스 업체
- 2002년 아마존의 상품데이터를 API로 제공하면서 시작됐다.
- 다양한 종류의 소프트웨어/플랫폼 서비스를 제공
- 다양한 ML/AI 관련 서비스들도 출시하기 시작했다. (ex. Amazon SageMaker)
EC2 (Elastic Compute Cloud)
- AWS의 서버 호스팅 서비스
- 구매 옵션 유형 :
| 구매 옵션 | 설명 |
| On-Demand | 시간당 비용을 지불하는 옵션 (가장 많이 사용) |
| Reserved | 1년 혹은 3년간 사용을 보장하고 1/3 정도에서 40% 할인을 받는 옵션 |
| Spot Instance | 일종의 경매방식으로 놀고있는 리소스에 대해 비용으로 사용할 수 있는 옵션 |
S3 (Simple Storage Service)
- AWS의 대용량 클라우드스토리지 서비스 (웹 하드디스크의 개념)
- 버킷(Bucket; 최상위 저장소)을 바탕으로 서브 폴더 및 디렉토리를 업로드하는 것이 가능
- 버킷별로 접근 권한 설정이 가능하다.
기타 Database 서비스
- MySQL, PostgreSQL, Aurora, Oracle, MS SQL Server (RDS; Relational Database Service)
- DynamoDB
- Redshift
- ElasticCache
- ElasticSearch
- Neptune (Graph database)
- MongoDB
기타 AI&ML 서비스
- SageMaker : 딥러닝/머신러닝을 통해서 모델을 생성 → 테스트 → API형태로 배포하는 과정을 자동화하는 프레임워크
- Lex : 챗봇 서비스를 만드는데 사용
- Polly : 텍스트를 입력하면 음성으로 변환하는데 사용
- Rekognition : 이미지를 인식하는데 사용
기타 중요 서비스
- Amazon Alexa : 음성봇 플랫폼
- Amazon Connect : 콜센터 솔루션으로, 콜센터 구현이 매우 쉬워짐
- Lambda : 서버리스 컴퓨팅 엔진
Redshift
: Scalable SQL 엔진인 데이터 웨어하우스
- 최대 2PB까지 지원
- 데이터 웨어하우스로, 응답속도가 빠르지 않기 때문에 프로덕션 데이터 베이스로는 사용할 수 없음
- Columnar storage : 컬럼별로 저장하기 때문에 컬럼별 압축이 가능하고 컬럼 추가/삭제 속도가 빠름
- 벌크 업데이터 지원 : 레코드가 들어있는 파일을 웹 스토리지인 S3에 저장하고, COPY 명령으로 Redshift에 일괄적으로 복사
- 고정 용량 & 고정 비용 SQL 엔진 : 예산 측정이 가능하지만, 사용을 안해도 돈이 나가는 단점 존재
↔ 가변 용랑 & 가변 비용 SQL 엔진 : 사용한 만큼 비용을 지불할 수 있지만, 예산 측정이 불가한 단점 존재 (ex. Snowflake, BigQuery)
- 타 DW처럼 Primary key Uniqueness를 보장하지 않음 (But, 프로덕션 DB는 보장한다.)
- PostgreSQL 8.x와 일부 호환됨
- SQL이 메인 언어이기 때문에 테이블 디자인이 매우 중요함
Redshift Schema의 구조
- 폴더(데이터베이스, 스키마)로 구성된다.
- DEV라는 폴더 밑에 raw_data, analytics, adhoc 폴더 생성해서 관련 테이블 만듦
-- 폴더 생성 (Redshift의 Admin 권한을 갖고있는 사람만 수행 가능한 쿼리)
CREATE SCHEMA raw_data; -- 원본 데이터
CREATE SCHEMA analytics; --
CREATE SCHEMA adhoc; -- 개발자, 데이터 팀이 테스트를 할 때 테이블을 만들 수 있는 공간
Redshift 액세스 방법
- 수업에서는 Google Colab 사용할 예정
- 그 외, PostgreSQL 8.x와 호환되는 모든 툴과 프로그래밍 언어를 통해 접근 가능
