[feat] Add ELT scripts

[ourjune21]

ELT 스크립트 추가

📑 작업 개요

이번 작업에서는 두 가지를 진행했습니다.

1. Data Lake에서 Data Warehouse로 원시 데이터 수집

ETL 과정에서 Data Lake(AWS S3)로 수집된 파일들을 COPY INTO 명령어를 사용하여 Data Warehouse(Snowflake)로 로드했습니다.

2. 다각도로 분석하기 쉽게 Data Warehouse에 기반 데이터 구성

데이터를 다양한 관점에서 분석하기 쉽도록 스타 스키마를 적용하여 Data Warehouse 내에 테이블들을 설계, 생성하고 데이터를 적재했습니다.

🛠 주요 변경 사항 (Changes)

• 스키마 생성, 데이터 추가를 위한 스크립트를 sql_scripts 디렉터리에 추가했습니다.
  • create_schema.sql: 데이터베이스의 초기 스키마를 생성하여 데이터 구조 정의
  • load_row_data.sql: S3의 원시 데이터를 Data Warehouse로 복사
  • create_dimensions.sql: 다각도로 분석하기 위한 차원 테이블(dimension table) 생성
  • create_facts.sql: 핵심 분석을 위한 사실 테이블(fact table) 생성
• 기타 작업
  • 파일 명명 규칙을 통일하여 전체 스크립트의 일관성과 가독성 향상

✅ 확인 사항 (Checklist)

• 코드가 정상적으로 동작하는지 확인
  스크립트 실행 결과, 아래 세 가지 사항이 정상적으로 진행된 것을 확인하였습니다.

  • 4개 스키마(analytics, raw_data, reporting, test) 생성
  • 10개 테이블(analytics 스키마 하위 7개, raw_data 스키마 하위 3개) 생성
  • 10개 테이블에 데이터 추가
  

• 타깃 브랜치가 올바르게 설정되었는지 확인 (예: develop ← feature/브랜치명)

👀 리뷰 요청 사항 (Review Requests)

• 파일 구분의 적절성
  현재는 SQL 쿼리문을 스키마 생성, 원시 데이터 로드, 차원 테이블 생성, 사실 테이블 생성이라는 작업별로 네 개의 파일로 구분해두었습니다. 이 구성이 쿼리문을 이해하고, 유지보수하는 데 있어 효과적인 방식인지에 대한 피드백을 부탁 드립니다. 혹시 더 효율적인 구분 방식에 대한 조언이 있으시다면, 함께 제안해주시면 큰 도움이 될 것 같습니다.

• 에러 및 엣지 케이스
  스크립트 실행 시 정상적으로 동작하는 것을 확인했지만, 저희가 미처 고려하지 못한 에러나 엣지 케이스가 발생할 가능성도 있을 것 같습니다. 혹시 우려될 만한 문제 상황에 대해 조언해주실 수 있을까요?

• SQLFluff
  팀원 간 코드 스타일을 일관되게 유지하기 위해 SQLFluff 도구를 적용해보았습니다. 다만, 현재는 팀원들이 코드 스타일 검사를 매번 수동으로 실행해야 하는 상황인데요. 이를 자동화하고 효율적으로 관리할 수 있는 방법이 있을지 의견을 여쭙고 싶습니다.

📌 추가 정보 (Additional Information)

• SQL 코드의 일관성을 유지하고, 품질을 높이기 위해 sqlfluff 라이브러리를 추가했습니다.
  아래 명령어를 실행시켜, 해당 패키지를 설치한 후 사용하실 수 있습니다.

pip install -r requirements.txt

[EunjiYi]

잘한 점:
코드가 정상적으로 동작하는지 확인한 것
PR discription을 상세히 작성한 것
코드 리뷰를 요청한 파일이 어떤 파일인지 설명한 것
SQLFluff을 사용해본 것 - 주의할 점 SQLFluff 라는 툴을 사용했다는 자체가 좋은 점이라는 것이 아니고, '팀원 간 코드 스타일을 일관되게 유지하기 위해' 고민을 했고, 그 흔적으로 SQLFluff를 사용해보려고 한 점을 칭찬합니다.

아쉬운 점:
python 등의 언어가 아닌 쿼리만 리뷰하는 것
spark나 pandas, python 등을 사용하지 않고 sql로만 스키마 생성, 원시 데이터 로드, 테이블 생성한 것

리뷰 요청 사항 답변
쿼리를 어떤식으로 실행시키는지, 실행 주체 등이 표현되어 있지 않아 아쉽습니다.
쿼리문 자체는 이해할 수 있으나, 유지보수 측면에서 효과적이라고는 말하기 어려워 보입니다.
쿼리의 모든 변수(테이블명, 데이터베이스명 등)가 하드코딩 되어 있습니다. 이 경우 한가지의 스키마만 변경되어도 에러가 발생하는데, 어떤 에러인지 logging도 어렵습니다.
그리고 스키마 등 변경 시 코드를 일일이 수정해야하므로 휴먼에러가 발생하기 쉽습니다.
데이터 삽입에서 데이터가 하드코딩으로 들어가는데, 이 서비스가 실제 서비스라고 할 때 어떻게 구현할 것인지 고민해보세요.

자동화 측면
Github Action이라는 것이 있습니다.
hint: 쉽게 말하면, git으로 특정 행동(commit, push, merge 등)을 하면 어떤 행위가 실행되게 한다! 라는 것인데요. sql 파일을 생성했을 때 github action이 실행되어 검사할 수 있도로 보세요.

[EunjiYi]

데이터베이스 이름만 보고도 무엇을 담고 있는 것인지 알 수 있게 작성해주세요.

[EunjiYi]

EOF(End Of File) 챙겨주세요.
hint: 저 빨간 동그라미 안에 줄이 그어져 있는 것이 무슨 의미인지 확인해보세요