[TIL 21일자] 데브코스 데이터엔지니어링

📚 오늘 공부한 내용

1. SQL의 중요성

• 데이터 관련 직군은 크게 세 개가 있다.
  • 데이터 엔지니어: 파이썬, 자바/스칼라, SQL, 데이터베이스, ETL/ELT (Airflow, DBT), Spark, Hadoop
  • 데이터 분석가: SQL, 비지니스 도메인에 대한 지식, 통계 (AB 테스트 분석)
  • 데이터 과학자: 머신러닝, SQL, 파이썬, 통계

모든 데이터 관련 직군에서 공통적으로 필요한 스킬이 바로 SQL이다. 다만 Front-end와 Back-end에서 SQL을 사용하는 것과 달리 데이터 관련 직군에서는 큰 데이터들을 프로세싱해서 작은 데이터로 요약하거나 데이터를 분석하기 위해 SQL을 사용한다.

2. 관계형 데이터베이스란?

• 데이터를 분석하는 관점에서 보면 우리가 분석한 데이터들은 모두 구조화되어 있다. 관계형 데이터베이스는 이런 구조화된 데이터를 기반으로 작업을 할 때는 가장 좋은 기술이 된다.
• 이때 사용되는 프로그래밍 언어가 SQL이다.
• 구조화된 데이터를 저장하고 그 저장된 데이터의 질의를 할 수 있도록 해 주는 스토리지(저장 장소)
  • 엑셀 스프레드 시트 형태의 테이블(컬럼/열, 레코드/행)로 데이터를 정의하고 저장
  • 테이블 스키마를 정하고 테이블 스키마에 맞춰서 레코드를 추가할 수 있음
• 테이블 정의를 위한 DDL (Data Definition Language)
• 테이블 데이터 조작/질의를 위한 DML (Data Manipulation Language)

📌 대표적 관계형 베이스는 어떤 것이 있는가?

• 프로덕션 데이터베이스 (OLTP: OnLine Transaction Processing)
  • 웹 서비스나 모바일 앱과 바로 연동이 돼서 해당 서비스에 필요한 정보들을 저장 및 조회해 오는 데이터베이스
  • 빠른 속도가 매우 중요
  • MySQL, PostgreSQL, Oracle 등
    
    
• 데이터 웨어하우스 (OLAP: OnLine Analytical Processing)
  - 처리 데이터의 크기가 클 때 사용하며 처리 데이터의 크기에 집중
  - 데이터 관련 직군의 사람들은 보통 데이터웨어하우스를 사용
  • 데이터 분석하거나 데이터 모델링을 할 때 필요한 데이터를 저장할 때 사용
  • Redshift, Snowflake, BigQuery, Hive 등

📌 프로덕션 데이터베이스만 사용하는 회사에서 데이터 직군이 겪는 어려움?

• 필요한 데이터를 사용하고자 할 때 SQL 실행을 통해 프로덕션 데이터베이스에 접근해야 하는데 이 데이터베이스가 실제 서비스와 연동되어 있기 때문에 큰 쿼리를 날려 데이터베이스가 느려지면 이것이 전체 서비스에 영향을 끼치게 된다.
• 그래서 데이터 직군을 위한 별도의 데이터 웨어하우스가 필요하다.

3. 관계형 데이터베이스의 구조

• 관계형 데이터베이스는 2단계로 구성된다.
• 데이터베이스(혹은 스키마)라는 폴더 밑에 테이블을 관리하는 형식으로 구성된다.
• 테이블 구조 (테이블 스키마라고 부름)
  - 테이블은 레코드들로 구성된다. (행)
  - 레코드는 하나 이상의 필드(컬럼)로 구성된다. (열)
  - 필드(컬럼)는 이름과 타입, 속성(Primary key)으로 구성된다. (Primary key의 값은 유일해야 함.)
  
• 다음과 같이 상단의 그림인 테이블 구조를 스키마라고 한다. 환자 정보를 담는 테이블을 예시로 만들어 보았다. 이때 환자 번호는 환자의 고유 값이 되기 때문에 해당 레코드를 구분해 주는 유일한 값이 된다. 우리는 이를 Primary Key로 설정해 줄 수 있다.

4. SQL이란?

1) SQL의 개념

• Structured Query Language
• 관계형 데이터베이스에 있는 테이블을 질의하거나 조작할 수 있도록 해 주는 프로그래밍 언어이다.
• DDL(Data Definition Language)로 테이블의 구조를 정의하고, DML(Data Manipulation Language)로 원하는 레코드를 조회하거나 추가, 삭제, 갱신할 수 있는 언어이다.
• SQL는 데이터 규모와 상관없이 쓰이며 빅데이터 세상에서도 중요하다.
• 모든 대용량 데이터 웨어하우스는 SQL 기반이다.
• Spark나 Hadoop도 예외는 아님. SparkSQL과 Hive라는 SQL 언어가 지원됨.

2) SQL의 단점

• 구조화된 데이터를 다루는 데 최적화가 되어 있다.
  • 정규표현식을 통해 비구조화된 데이터를 다루는 데 제약이 심함.
  • Spark, Hadoop과 같은 분산 컴퓨팅 환경이 필요해짐.
• 관계형 데이터베이스마다 SQL의 문법이 조금씩 다르다.

5. 데이터를 어떻게 표현할 것인가? (데이터 모델링)

1) Star schema

그림 출처: https://www.jamesserra.com/archive/2011/10/denormalizing-dimension-tables/

• Production DB에서 사용하는 방식이다.
• 논리적 단위에 따라 각각 테이블을 나누고, 필요 시 테이블을 조인한다.
• 스토리지의 낭비가 줄어들며 데이터를 업데이트하기가 쉽다.
• 현재 그림을 예시로 들어서 만약 제품명을 업데이트한다고 하면 Denormalized schema에서는 업데이트를 위해 이전 제품명을 모두 찾아 업데이트해 주어야 하는데 Star schema에서는 Product 테이블에 해당되는 제품명만 수정하면 된다.

2) Denormalized schema

그림 출처: https://www.jamesserra.com/archive/2011/10/denormalizing-dimension-tables/

• 데이터 웨어하우스에서 사용하는 방식이다. 왜냐하면 데이터 웨어하우스는 스토리지 크기의 제약이 없기 때문이다.
• 필요한 정보들을 하나의 테이블에 다 포함한다.
• 스토리지를 더 사용하는 방법이긴 하지만 조인이 필요 없기 때문에 빠른 계산이 가능하다.

6. 데이터 웨어하우스란?

• SQL 기반의 관계형 데이터베이스지만 프로덕션 데이터베이스와는 별도
• AWS의 Redshift, Google Cloud의 Big Query,Snowflake 등이 있다.
  • Redshift는 고정 비용 옵션이고 Big Query와 Snowflake는 가변 비용 옵션이다.
  • Big Query와 Snowflake가 더 대용량 데이터를 다루는 데 적합하다.
  • 실제 사용법 자체에는 큰 차이가 없다.
• 회사에 필요한 모든 데이터들을 저장
• 고객이 아닌 내부 직원(데이터 팀원)을 위한 데이터베이스
  • 그렇기 때문에 처리 속도가 그렇게 중요하지 않고 오히려 처리 데이터의 크기가 중요하다.
• 외부에 존재하는 데이터를 읽어다가 데이터 웨어하우스로 저장해 주는 코드가 필요해진다. -> ETL(추출 Extract, 변환 Transform, 로드 Load) 혹은 데이터 파이프라인

📌 데이터 인프라란?

• 데이터 엔지니어가 관리한다.
• ETL과 데이터 웨어하우스를 포함한 것을 말하며 이 단계에서 한 단계 발전하면 Spark와 같은 대용량 분산 처리 시스템이 일부 추가된다.
• 데이터 인프라는 데이터 팀의 업무에 시작 단계에 해당한다.

7. 클라우드(Cloud)

1) 클라우드 컴퓨팅이란?

• 컴퓨팅 자원을 네트워크를 통해 서비스 형태로 사용하는 것
• No Provisioning
• Pay As You Go
• 자원을 필요한 만큼 실시간으로 할당해 사용한만큼 돈을 지불한다. 탄력적으로 필요한만큼의 자원을 유지하여야 한다.

2) 클라우드 컴퓨팅이 없었다면?

• 서버, 네트워크, 스토리지 구매와 설정 등을 직접 수행해야 함
  -데이터 센터 공간을 직접 확보해야 함.
• 서버를 구매하에 설치하고, 네트워크를 설정해야 함. 직접 서버를 구매하고 설치하는 데 적어도 두세 달은 걸리게 된다.
• Peak Time 기준으로 Capacity Planning을 해야 함.
• 기다릴 필요가 없기 때문에 직접 운영하는 비용보다 기회 비용이 생김.

3) 클라우드 컴퓨팅의 장점

• 초기 투자 비용이 크게 줄어듦.
• 리소스 준비를 위한 대기 시간이 대폭 감소. 기회 비용 측면에서 굉장한 이점이 생김.
• 노는 리소스 제거로 비용 감소.
• 글로벌 확장에 용이함. (대부분의 클라우드 프로그램이 전세계에 데이터 센터가 존재하기 때문에)
• 소프트웨어 개발 시간 단축. Managed Service (SaaS) 이용.

4) AWS

* EC2 - Elastic Compute Cloud

• AWS의 서버 호스팅 서비스
• 리눅스 기반의 운영 체제와 윈도우, 애플의 맥 운영 체제까지 지원하고 있다.
• 세 가지 구매 옵션
  • On Demand: 시간당 비용이 지불되며 가장 흔히 사용하는 옵션
  • Reserved: 1년이나 3년간 사용 보장하고 40 %의 할인을 받는 옵션
  • Spot Instance: 일종의 경매 방식으로 놀고 있는 리소스들을 더 저렴한 비용으로 사용할 수 있는 옵션 -> 문제는 어느 순간이라도 더 높은 가격에 경매한 사람이 있다면 그 사람에게 서버가 모두 넘어가게 된다.

* S3 - Simple Storage Service

• 기본적으로 저렴하다.
• 1TB per month
  • Standard storage: $23
  • Glacier storage: $4 (접근 속도가 굉장히 오래 걸림.)

* 기타 중요 서비스 - Database Services

• RDS (Relational Database Service): MySQL, PostgreSQL, Aurora, Oracle, MS SQL Server
• DynamoDB
• RedShift
• ElasticCache
  -Neptune (Graph Database)
• ElasticSearch
• MongoDB

* 기타 중요 서비스 - AI & ML Services

• SageMaker: 머신 러닝과 딥러닝 End-to-End Framework
• Lex: Conversational Interface (챗봇)
• Polly: Text to Speech
• Rekognition: Image Recognition

* 기타 중요 서비스

• Amazon Alexa: voice bot 플랫폼
• Amazon Connect: 콜센터 Solution, 콜센터의 구현을 쉬워지게 함.
• Lambda: Serverless Computing Engine. 서비스 구현을 위해 EC2를 론치할 필요가 없어짐. API 로직만 구현하면 탄력적인 운영을 아마존에서 대신해 줌. Google에서는 Cloud Function 서비스가 있음.

8. Redshift

• Scalable SQL 엔진
• 2 PB까지 지원. (보통 2 PB에 달하기 전까지 이슈가 발생하기 때문에 명확한 수치는 아니다.)
• OLAP(OnLine Analytical Processing)
• 응답 속도가 빠르지 않기 때문에 프로덕션 데이터베이스로 사용하면 안 된다.
• Columnar storage 컬럼별로 압축이 가능하고 컬럼 추가와 삭제가 매우 빠르다.
• 벌크 업데이트를 지원한다. 레코드가 들어 있는 파일을 S3로 복사 후 copy command로 Redshift로 일괄 복사
• 고정 용량/비용 SQL 엔진
• 다른 데이터 웨어하우스처럼 primary key uniqueness를 보장하지 않는다. 데이터 웨어하우스에서 보장해 주지는 않고 개발자가 보장해 주어야 한다.
• Postgresql 8.x와 SQL이 호환됨. 모든 기능을 지원하지는 않고, Postgresql에서 지원하는 툴이나 라이브러리도 접근이 가능하다.
• SQL이 메인 언어이기 때문에 구조화된 테이블이 매우 중요하다.

Redshift Schema 구성

1. raw_data: 가공하지 않은 외부에서 가지고 온 데이터, 날것의 데이터를 담는 테이블.
2. analytics: 분석용 데이터를 담는 테이블.
3. adhoc: 테스트를 위한 테이블. 따로 관리자가 존재하지 않음.

-- schema를 선언하는 쿼리
CREATE SCHEMA raw_data;
CREATE SCHEMA analytics;
CREATE SCHEMA adhoc;

🔎 어려웠던 내용 & 새로 알게 된 내용

1. DATABASE(데이터베이스)과 Schema(스키마)의 차이

• 이 부분은 DBMS마다 의미가 다르다.
• 보통 데이터베이스의 계층이 3 계층이냐, 4 계층이냐에 따라서 이 개념이 달라지는 것으로 보인다.
  
• 먼저 3 계층인 경우 DATABASE가 따로 존재하지 않으며 스키마와 데이터베이스를 동의어로 취급한다. MySQL이 이와 같은 경우에 해당한다.
  
• 4 계층의 경우 다음과 같은 구조가 되는데 이때는 DATABASE가 스키마의 상위 개념이 된다. ANSI가 정한 표준 SQL에서는 4 계층으로 정의를 하는 것이 맞으며 이 구조를 충실하게 지킨 것이 PostegreSQL, MSSQL(SQL Server)이다. Oracle 역시 4 계층으로 이루어져 다음과 같은 개념이 적용이 되지만 인스턴스 아래에 데이터베이스를 한 개만 만들 수 있다는 제약이 있다.

2. 벌크 업데이트(Bulk Update)란?

• 대용랑의 데이터를 업데이트하는 빠른 방식
• 데이터의 한 건씩을 넣는 게 아니라 파일 전체를 Insert 해서 빠르게 수행이 가능
• SQL 쿼리로 벌크 업데이트를 작성하면 다음과 같이 작성할 수 있다.

-- 1. 원본 테이블과 똑같은 임의의 테이블 생성 
-- ORD_TABLE이 원본 테이블이며 TMP_TABLE이 원본 테이블을 복사할 임의 테이블이 된다.
CREATE TEMPORARY TABLE TMP_TABLE 
  LIKE ORG_TABLE
-- 2. 임시 테이블에 모든 데이터를 저장
INSERT TMP_TABLE 
VALUES (DATA들);
-- 3. 원본 테이블 BULK UPDATE
    UPDATE ORG_TABLE O
INNER JOIN TMP_TABLE T
	    ON O.COL1 = T.COL1
        OR O.COL2 = T.COL2;     
-- 4. 임시 테이블 삭제
DROP TEMPORARY TABLE TMP_TABLE;

✍ 회고

- 내가 회사에서 개발을 할 때 썼던 것은 프로덕션 데이터베이스였는데 프로덕션 데이터베이스와 데이터 웨어하우스의 차이와 개념을 확실하게 알 수 있어서 좋았다. 두 데이터베이스 환경에 따라 데이터를 사용하는 목적이 다르기 때문에 테이블의 구조도 달라진다는 점이 흥미로웠다. 프로덕션 데이터베이스를 사용할 때는 논리적인 개념에 따라 각 테이블을 나누되 서로 연관된 정보들은 언제든지 조인하여 조회할 수 있는 환경을 만드는 것이 테이블을 구상할 때 중요했는데 이 방법이 Star Schema라는 것을 알게 되었다.

- 한기용 강사님의 강의를 듣다 보면 학습 곡선에 관한 이야기나 정체기에 빠졌을 때 어떻게 극복해 나가야 할지에 대해 많이 조언을 해 주시는데 가끔 내 스스로가 더디다고 생각할 때면 계속 그 말을 되뇌이게 되는 것 같다. 내가 무엇 때문에 더딘 상태가 되었는지에 대해 나에게 끊임없이 자문하고 이를 해결하기 위해 어떻게 해야 하는지 생각하며 원래 학습은 어느 순간에 솟아오르는 것이라는 것을 인지하다 보면 그 상황이 나아가야 할 상황이지 좌절할 상황이 아니라고 생각하게 된다.